llvm dev - Apr 2011 - [LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler

On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at apple.com>
wrote:
>>
>>
>> Then we would always have the location of the br B instruction in A, as
it is pushed onto the stack or saved in link register when A calls B.
>>
>
> Right, unless you wanted to go with direct calls in the JIT. I don't
know that inspecting a running program's stack for return values while
compiling on a separate thread is sane :)
>
> That said, the adaptive compilation strategy can always enforce the use of
a stub for calls into jitted functions.
I think you said what I was going to say, but here's how I see it:

getPointerToFunction always returns the address of the stub, so any
indirect calls to the function hit the stub.  The stub will attempt to
backpatch the callsite, and should fail if it is a) outside the JIT or
b) an indirect call.  Indirect calls will always go through the stub.
Direct calls can be backpatched.

Alternatively, everything would go through the stub.

Finally, you have to be careful about the memory model of the
architecture you're dealing with if you care about threads.  On x86,
if you can align the operand of the call instruction, you can do an
atomic update.  You will also have to make sure you don't free the old
machine code while there are still functions executing in it.  An easy
(yet inefficient) way to deal with this is to update a refcount on
function entry/exit.

Reid

On Apr 1, 2011, at 9:38 AM, Reid Kleckner wrote:
> On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at
apple.com> wrote:
>>> 
>>> 
>>> Then we would always have the location of the br B instruction in
A, as it is pushed onto the stack or saved in link register when A calls B.
>>> 
>> 
>> Right, unless you wanted to go with direct calls in the JIT. I
don't know that inspecting a running program's stack for return values
while compiling on a separate thread is sane :)
>> 
>> That said, the adaptive compilation strategy can always enforce the use
of a stub for calls into jitted functions.
> 
> I think you said what I was going to say, but here's how I see it:
> 
> getPointerToFunction always returns the address of the stub, so any
> indirect calls to the function hit the stub.  The stub will attempt to
> backpatch the callsite, and should fail if it is a) outside the JIT or
> b) an indirect call.  Indirect calls will always go through the stub.
> Direct calls can be backpatched.
> 
> Alternatively, everything would go through the stub.
> 
> Finally, you have to be careful about the memory model of the
> architecture you're dealing with if you care about threads.  On x86,
> if you can align the operand of the call instruction, you can do an
> atomic update.  You will also have to make sure you don't free the old
> machine code while there are still functions executing in it.  An easy
> (yet inefficient) way to deal with this is to update a refcount on
> function entry/exit.
Well said :)

-eric

On Fri, Apr 1, 2011 at 1:26 PM, Eric Christopher <echristo at apple.com>
wrote:
>
> On Apr 1, 2011, at 9:38 AM, Reid Kleckner wrote:
>
> > On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at
apple.com>
> wrote:
> >>>
> >>>
> >>> Then we would always have the location of the br B instruction
in A, as
> it is pushed onto the stack or saved in link register when A calls B.
> >>>
> >>
> >> Right, unless you wanted to go with direct calls in the JIT. I
don't
> know that inspecting a running program's stack for return values while
> compiling on a separate thread is sane :)
> >>
> >> That said, the adaptive compilation strategy can always enforce
the use
> of a stub for calls into jitted functions.
> >
> > I think you said what I was going to say, but here's how I see it:
> >
> > getPointerToFunction always returns the address of the stub, so any
> > indirect calls to the function hit the stub.  The stub will attempt to
> > backpatch the callsite, and should fail if it is a) outside the JIT or
> > b) an indirect call.  Indirect calls will always go through the stub.
> > Direct calls can be backpatched.
> >
> > Alternatively, everything would go through the stub.
> >
> > Finally, you have to be careful about the memory model of the
> > architecture you're dealing with if you care about threads.  On
x86,
> > if you can align the operand of the call instruction, you can do an
> > atomic update.  You will also have to make sure you don't free the
old
> > machine code while there are still functions executing in it.  An easy
> > (yet inefficient) way to deal with this is to update a refcount on
> > function entry/exit.
>
> Another way to do the patching is to first atomically inserted a self-loop
jump -2 atomically (jump -2 takes 2 bytes and 2 bytes writing is atomic on
x86 )  into the old branch address on x86 such that it stops all threads
reaching this point. copy in the new compiled function address.  and then
re-patch the jump -2 with the correct binary.

Well said :)
>
> -eric
>


-- 
Kind Regards

Xin Tong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110403/7ea033f6/attachment.html>