[LLVMdev] How will OrcJIT guarantee thread-safety when a function is asked to be re generated?

[Philip Reames]

We solve this by using MCJIT to generate the code, and then managing it 
ourselves.  We have an instance of MCJIT per compiler thread.  We use 
MCJIT to perform one compilation at a time, and then disconnect the 
generated code from MCJIT.

Our runtime has existing mechanisms for patching the call sites to point 
to the new version of the code.  We've been able to use those 
essentially without modification.  To put it differently, we consider 
that out of scope for MCJIT.

p.s. It's worth stating that this type of code life cycle management is 
*hard*.  If the older version is still valid when the new one is 
installed, it gets a bit easier, but if you have to invalidate before 
install, you need to build a sophisticated deoptimization mechanism.

Philip

On 03/18/2015 06:39 PM, Lang Hames wrote:
> Hi Hayden,
>
> Dave's answer covers this pretty well. Neither Orc nor MCJIT currently 
> reason about replacing function bodies. They may let you add duplicate 
> definitions, but how they'll behave if you do that isn't specified in 
> their contracts. They definitely won't replace old definitions unless 
> you provide a custom memory manager that's rigged to lay new 
> definitions down on top of old ones.
>
> I suspect that existing clients of MCJIT have tackled this by adding 
> thread safety into their wrappers around MCJIT, or into the JIT'd code 
> itself, but I'm just guessing. (CC'ing Keno and Philip, in case they 
> have insights).
>
> I think this would be cool to build in to Orc though. Two quick thoughts:
>
> (1) Replacing function bodies at the same address is impossible if the 
> function is already on the stack: You'd be replacing a definition that 
> you're later going to return through. So, if you want to replace 
> functions at the same address you'll have to have some sort of 
> safe-point concept where you know the function you want to replace 
> isn't on the stack.
>
> (2) Replacing function bodies at the same address isn't the only way 
> to avoid the overhead of a trampoline. I haven't implemented this yet, 
> but I really want to add llvm.patchpoint support to Orc. In that case 
> you can lay down your replacement definition at a different address, 
> update all your callsites, then delete your old definition after 
> you're done executing it. Relative to using trampolines this lowers 
> your execution cost (calls are direct rather than indirect), but 
> increases your update cost (you have to update many callsites, rather 
> than a single trampoline).
>
> Out of interest, why the desire to avoid trampolines? They do make 
> life a lot easier here. :)
>
> Cheers,
> Lang.
>
> On Wed, Mar 18, 2015 at 3:13 AM, David Blaikie <dblaikie at gmail.com 
> <mailto:dblaikie at gmail.com>> wrote:
>
>     [+Lang, keeper of JITs, designer of ORCs]
>
>     On Tue, Mar 17, 2015 at 1:27 AM, Hayden Livingston
>     <halivingston at gmail.com <mailto:halivingston at gmail.com>> wrote:
>
>         I've been playing with OrcJIT a bit, and from the looks of it
>         I can (like in the previous JIT I suppose?) ask for a function
>         to be re generated.
>
>         If I've given the address of the function that LLVM gave me to
>         an external party, do "I" need to ensure thread-safety?
>
>         Or is it safe to ask OrcJIT to re generate code at that
>         address and everything will work magically?
>
>
>     As I understand it, Orc won't regenerate the function at the same
>     location unless your memory manager returns the same memory twice
>     - so if you know you've successfully migrated all callers off a
>     certain chunk of allocated memory, you might be able to recycle it
>     back into Orc (but I think on MacOS, the way page permissions
>     work, this would be impossible - once a memory page is marked
>     executable, it's no longer writable and can't be set back - you
>     need a new page).
>
>         I'm thinking it won't because it's quite possible some thread
>         might be executing code, and we'll be asking LLVM to write
>         bytes there.
>
>         How does one generally go do such updates? I'm looking for
>         some guidance without adding a trampoline in front of it. Do
>         runtimes that support re-generation of code have an if check
>         or something before entering the method?
>
>
>     Without a trampoline you're probably going to have to be
>     constrained in some other ways - possibly (& I'm really out of my
>     depth at this point) the kind of safe/pause points used for GC -
>     but perhaps more constrained than that, such that you have safe
>     places where your JIT'd code (or at least the replaceable
>     functions) isn't running.
>
>     But again, still depends on platform - writing to executable
>     memory isn't possible on MacOS so far as I know (as mentioned
>     above) so there would be no way to replace a function there
>     without a trampoline or at least a global variable to load/jump to.
>
>     - David
>
>
>         _______________________________________________
>         LLVM Developers mailing list
>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>         http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150324/94329693/attachment.html>