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

[Hayden Livingston]

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>