[LLVMdev] How will OrcJIT guarantee thread-safety when a function is asked to be re generated?
dblaikie at gmail.com
Tue Mar 17 09:13:57 PDT 2015
[+Lang, keeper of JITs, designer of ORCs]
On Tue, Mar 17, 2015 at 1:27 AM, Hayden Livingston <halivingston at gmail.com>
> 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
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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev