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

Hayden Livingston
Thu, 19 Mar 2015 21:51:08 -0000

Thanks for all the comments on this.

The concern for not using a trampoline is that it's very likely my language
will interpret for a while, then generate code, then generate better code,
etc. Much like the WebKit FLT JavaScript project. It seems like they will
be using patch points? I should probably use that for my perf use-case as
well.

However, I have an additional case that requires correctness to maintained
across threads, i.e. the code may be semantically different. In this case I
need either all callsites updated at once, or none. It can't be that half
of the
callsites are calling into a different function because there maybe real
differences.

I suppose an approach I can take is to use patch points for eventual
consistency and have an if check that has maintains the correctness and
will trampoline or execute code depending on if all call sites are done
being patched.

Or maybe I'm over complicating this for my language :-)

On Thu, Mar 19, 2015 at 10: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/20150319/898c692a/attachment.html>