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

Lang Hames
Thu, 19 Mar 2015 22:28:02 -0000

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>