[LLVMdev] [PATCH] Performance degradation when repeatedly exchanging JITted functions

James Molloy James.Molloy at arm.com
Wed Mar 7 08:57:27 PST 2012


Hi Clemens,

You should send to the commits list, as you suggest :)

Cheers,

James

-----Original Message-----
From: Clemens Hammacher [mailto:hammacher at cs.uni-saarland.de]
Sent: 07 March 2012 16:43
To: James Molloy; llvmdev at cs.uiuc.edu
Subject: [PATCH] Performance degradation when repeatedly exchanging JITted functions

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

-- 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.





More information about the llvm-dev mailing list