llvm dev - Mar 2012 - [LLVMdev] Performance degradation when repeatedly exchanging JITted functions

On 3/6/12 5:28 PM, Joerg Sonnenberger wrote:
> Advantage of using the latest address: one saved jmp per call.
Per newly JITted call ;)
> Advantage of using the initial address: easier G/C of intermediate
> versions, less things to keep track of.
I still think both versions require larger changes. When using the 
latest address, you have to keep track of all JITted functions per 
Function in order to update them. And their number increases linearly, 
so the time needed for exchanging a function increases as well.

When using the initial address, you also have to patch all places in 
LLVM that rely on the global mapping being updated, which are more than 
I initially thought. That's why I stopped working on that.


I don't think that a patch implementing any of those approaches would be 
accepted, that's why I am tending towards implementing it outside of LLVM.

Cheers,
Clemens

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6392 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120306/7ba10b6c/attachment.bin>

> I don't think that a patch implementing any of those approaches would
be
> accepted, that's why I am tending towards implementing it outside of
LLVM.
Why not? If they make LLVM better and aren't hacks, why wouldn't they be
accepted?
________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf
Of Clemens Hammacher [hammacher at cs.uni-saarland.de]
Sent: 06 March 2012 16:39
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Performance degradation when repeatedly exchanging JITted
functions

On 3/6/12 5:28 PM, Joerg Sonnenberger wrote:
> Advantage of using the latest address: one saved jmp per call.
Per newly JITted call ;)
> Advantage of using the initial address: easier G/C of intermediate
> versions, less things to keep track of.
I still think both versions require larger changes. When using the
latest address, you have to keep track of all JITted functions per
Function in order to update them. And their number increases linearly,
so the time needed for exchanging a function increases as well.

When using the initial address, you also have to patch all places in
LLVM that rely on the global mapping being updated, which are more than
I initially thought. That's why I stopped working on that.


I don't think that a patch implementing any of those approaches would be
accepted, that's why I am tending towards implementing it outside of LLVM.

Cheers,
Clemens


-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.

On 3/6/12 6:48 PM, James Molloy wrote:
>> I don't think that a patch implementing any of those approaches
would be
>> accepted, that's why I am tending towards implementing it outside
of LLVM.
>
> Why not? If they make LLVM better and aren't hacks, why wouldn't
they be accepted?
Okay, that motivated me to work on the patch again. I think I found a 
compromise of the discussed approaches.
The original stub (which is being hold by the JITResolver anyway) is 
updated to point to the new version in any case.
Additionally you can set a flag in the ExecutionEngine to always use the 
stub when calling a function. If this flag is set, a 
recompileAndRelinkFunction does *not* patch the old function pointer to 
jump to the new function, since all calls use the stub anyway.

Since - as I wrote - several places in the JIT rely on the global 
mapping being updated to the start of the newly jitted function, I 
didn't change that. Instead, after jitting a function, the mapping is 
changend back to the stub, if the KeepStubs flag is set.
The only drawback of this is that *directly* recursive calls still 
bypass the stub and jump back directly to the function pointer. But 
since exchanging a function while another thread is executing it is 
unsafe anyway, this shouldn't matter. Even exchanging a function running 
in the same thread (e.g. from a callback into the VM) is unsafe in the 
current implementation, since you would overwrite the original function 
code at the start of the method.

So I think this should be fine.

I attached a patch implementing this, and a test case for the new flag. 
Both apply to trunk.

Should I send them to the commits list, or does anyone with commit 
rights find them here?
If so, that person can also apply the fix and testcase for bug 12197, 
which I stumbled across and is slightly related to this one.
http://llvm.org/bugs/show_bug.cgi?id=12197

Cheers,
Clemens
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: implement_KeepStubs.patch
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120307/d709bfdb/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testcase_KeepStubs.patch
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120307/d709bfdb/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6392 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120307/d709bfdb/attachment.bin>