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

[David Blaikie]

[+Lang, keeper of JITs, designer of ORCs]

On Tue, Mar 17, 2015 at 1:27 AM, Hayden Livingston <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         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/20150317/16db5022/attachment.html>