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

[Lang Hames]

Hi Sanjoy,

> You need the hijack-return-pc approach *in addition* to a call-site
> patching approach.  Modifying the return PC lets you guarantee that
> nothing will *return* into the old generated code. To guarantee that
> nothing will *call* into it either you could use a double indirection
> (all calls go through a trampoline) or patchpoints.

You need to hijack the return addresses if you want to delete the original
function body immediately, but what if you just leave the original in-place
until you return through it? That is the scheme that Pete and I had been
talking about. On the one-hand that means that the old code may live for an
arbitrarily long time, on the other hand it saves you from implementing
some complicated infrastructure. I suspect that in most JIT use-cases the
cost of keeping the duplicate function around will be minimal, but I don't
actually have any data to back that up. :)

It's worth noting that, as per its design goals, Orc is agnostic about all
this. Either scheme, or both, should be able to be implemented in the new
framework. It's just that nobody has implemented it yet.

- Lang.

On Fri, Mar 20, 2015 at 4:55 AM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> > That all makes sense. What are your thoughts on the trade-offs of this vs
> > the patchpoint approach though? If you can modify previously executable
> > memory it seems like the patchpoint approach would have lower overhead,
> > unless you have a truly huge number of callsites to update?
>
> You need the hijack-return-pc approach *in addition* to a call-site
> patching approach.  Modifying the return PC lets you guarantee that
> nothing will *return* into the old generated code. To guarantee that
> nothing will *call* into it either you could use a double indirection
> (all calls go through a trampoline) or patchpoints.
>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150320/fabfa31d/attachment.html>