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

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?

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150317/2e01bc67/attachment.html>

[+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>

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>
wrote:
> [+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/20150319/38d37b09/attachment.html>

On Mar 17, 2015, at 12:13 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 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 couldn't reproduce that behavior. I just wrote a small program to

1. mmap one page read/write,
2. write mov eax, 0x12345678; ret to it,
3. mprotect it to read/exec,
4. call the instructions and print the result,
5. mprotect it to read/write,
6. change 0x12345678 to 0x55aa,
7. mprotect it to read/exec, and
8. call the instructions and print the result.

steve$ ./a.out
0x12345678
0x55aa

I just tested this on OS X 10.9.5 and 10.10.1.

-- 
Stephen Checkoway



-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.c
Type: application/octet-stream
Size: 806 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150320/170eceb4/attachment.obj>
-------------- next part --------------