You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/04/14 04:11:50 UTC
[drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
On 4/13/07, Mikhail Fursov <mi...@gmail.com> wrote:
> I've attached combined JIT+VM patch to JIRA. The test failed before passes
> now.
> VM-guru, please check VMEXPORT Boolean
> vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this patch.
VM gurus, please help checking this method in H3626. Thanks, xiaofeng
> On 4/13/07, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > 2007/4/13, Mikhail Fursov <mi...@gmail.com>:
> > > Rana,
> > > thank you for the fast update.
> > > I'll integrate this function usage into JIT and report if the problem I
> > have
> > > disappeares today.
> > >
> > > >>BTW, how does the jit knows which helpers throw exceptions?
> > > JIT generates stack info for every call instruction. So we can
> > > unwind stack frame from every call.
> > > Actually this is not enough: JIT must generate stackinfo for every push
> > inst
> > > also to handle SOE correctly. But this is one of the TODO list items.
> > >
> > >
> > > Another problem with helper calls I know is their calling conventions.
> > > Now the calling convention of every helper is hardcoded to JIT.
> > > I think it worth creating another JIRA to solve the problem one day.
> > Today I
> > > know no bugs about it, so it's design only issue.
> >
> > There is one already: HARMONY-2702. Actually Jitrino provides such
> > interface internally,
> > CompilationInterface::getRuntimeHelperCallingConvention(), so fix
> > should be easy enough (yet is blocked by HARMONY-3553).
> >
> > >
> > >
> > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > >
> > > > Yes, that make sense. I'll wait a bit to see if Mikhail has any more
> > > > suggestions and change it to is_gc_interruptible.
> > > >
> > > > On 4/12/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > Agree that this information better be provided by VM than JIT
> > internals.
> > > > >
> > > > > Rana, Thanks for the quick work. A minor comment:
> > > > >
> > > > > The interface name might be better use "has_gc_safepoint" or
> > > > > "is_gc_interruptible" than "is_suspension_point", since the helper
> > is
> > > > > a function (not a point), and "suspension" is implementation detail.
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > Mikhail,
> > > > > > I extended the vm-jit interface with a function:
> > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f)
> > > > > >
> > > > > > and attached it to your JIRA.
> > > > > >
> > > > > > Right now it returns true for almost every helper. But you may
> > want
> > > > > > to update this instead of hardcoding in the jit. At some point, we
> > > > > > need some analysis to determine which helpers are interruptible.
> > > > > >
> > > > > > BTW, how does the jit knows which helpers throw exceptions?
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On 4/11/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > > > A silly question possibly. But other than inlined
> > fastpaths,
> > > > why not
> > > > > > > > > > gcm treat all helper calls as interruptible?
> > > > > > > > >
> > > > > > > > > I think this needs case by case study to decide which ones
> > can
> > > > be
> > > > > > > > > interruptible. In most cases, the helper is only an
> > extension of
> > > > a
> > > > > > > > > certain bytecode operation, which can be virtually treated
> > as a
> > > > > > > > > bytecode (or part of a bytecode semantics). Normally, the
> > > > safepoint
> > > > > > > > > can be before or after it, but not in middle of it. If we
> > think
> > > > of the
> > > > > > > > > stack map info, the helper itself may not stand for a formal
> > > > method
> > > > > > > > > frame for GC or exception handling.
> > > > > > > >
> > > > > > > > This is a good way to look at helper calls. My point,
> > > > however, was
> > > > > > > > not really that helper calls should be interruptible. But that
> > > > other
> > > > > > > > than the fastpath for which the JIT sees the IR, why not treat
> > the
> > > > > > > > calls themselves as ineligible for code motion etc. like other
> > > > > > > > operators with side effects? Is the cost too high?
> > > > > > > > Implementing the interface extension is not hard for the VM,
> > but
> > > > looks
> > > > > > > > like implementation dependant info passed from the VM to the
> > JIT.
> > > > > > > >
> > > > > > > > Here is more details:
> > > > > > > The example of a helper that can be moved by GCM are number
> > > > conversion helpers.
> > > > > > > 'i2d' never throws exceptions and this knowledge is hardcoded in
> > > > HLO. On the
> > > > > > > other hand this HIR opcode is translated into LIR vm-helper
> > call, so
> > > > instead
> > > > > > > of simple Java opcode it becomes a
> > > > > > > call. I can hardcode which vm-helper call is interruptable and
> > which
> > > > is
> > > > > > > not on the
> > > > > > > JIT side, but think retrieving this information from VM is a
> > better
> > > > solution.
> > > > > > > Another example of uninterruptable vm-helper is
> > > > > > > TLS accessor. This helper is placed into the middle of the
> > inlined
> > > > > > > 'alloc' helper body because 'alloc' reqires TLS access.
> > > > > > > Now managed<->unmanaged convertion checker in GCMap pass has
> > > > hardcoded
> > > > > > > knowledge that TLS access will never be suspended.
> > > > > > >
> > > > > > > JET compiler uses different code then OPT and maintains special
> > > > > > > GC-bitmasks for object operands runtime.
> > > > > > > The per-call gc-mask maintainance is not free and can also be
> > > > > > > optimized if VM provides a method to describe which call is real
> > > > > > > suspension point and which is not.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > + Suspension and exception throwing are different attributes.
> > SOE
> > > > can be
> > > > > > > thrown even if method is not a suspension point. So JIT must
> > prepare
> > > > stack
> > > > > > > info for every call it generates to be able to unwind the
> > frame.
> > > > > > >
> > > > > > > --
> > > > > > > Mikhail Fursov
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://xiao-feng.blogspot.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Mikhail Fursov
> > >
> >
>
>
>
> --
> Mikhail Fursov
>
--
http://xiao-feng.blogspot.com
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/18/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > >
> > > > Mikhail,
> > > > I have no problem with the ones you updated, but some questions...
> > > >
> > > > Is VM_RT_WRITE_BARRIER_FASTCALL in use?
> > >
> > >
> > > This helper is dead code today. AFAIR gcv5 uses VM_RT_GC_HEAP_WRITE_REF
> > > today.
> >
> > OK thanks. We need to get rid of the dead gcv4 code. This is probably
> > what refers to the old barrier helper.
> > >
> > > And are the monitor enter/exit functions all interruptible?
> > > >
> > >
> > > I think monenter is must be. Thread can stall for a long period of time
> > on
> > > monenter. And I do not know if monexit is. At least it can throw
> > > IllegalState-like exception in theory.
> >
> > Yes right, both throw exceptions like nullpointer, illegalmonitorstate
> > etc. But these are supposed to be thrown lazily.
> >
>
> Actually I have never seen an exception thrown from monexit. JIT generates
> endless loop for an exception thrown from monexit and never let it go until
> monexit is called without exceptions.
Is this the case? If monitorExit meets a lock that is owned by other
thread, it has no way to exit but to throw an exception.
> --
> Mikhail Fursov
>
--
http://xiao-feng.blogspot.com
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
>
> On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > >
> > > Mikhail,
> > > I have no problem with the ones you updated, but some questions...
> > >
> > > Is VM_RT_WRITE_BARRIER_FASTCALL in use?
> >
> >
> > This helper is dead code today. AFAIR gcv5 uses VM_RT_GC_HEAP_WRITE_REF
> > today.
>
> OK thanks. We need to get rid of the dead gcv4 code. This is probably
> what refers to the old barrier helper.
> >
> > And are the monitor enter/exit functions all interruptible?
> > >
> >
> > I think monenter is must be. Thread can stall for a long period of time
> on
> > monenter. And I do not know if monexit is. At least it can throw
> > IllegalState-like exception in theory.
>
> Yes right, both throw exceptions like nullpointer, illegalmonitorstate
> etc. But these are supposed to be thrown lazily.
>
Actually I have never seen an exception thrown from monexit. JIT generates
endless loop for an exception thrown from monexit and never let it go until
monexit is called without exceptions.
--
Mikhail Fursov
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Rana Dasgupta <rd...@gmail.com>.
On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > Mikhail,
> > I have no problem with the ones you updated, but some questions...
> >
> > Is VM_RT_WRITE_BARRIER_FASTCALL in use?
>
>
> This helper is dead code today. AFAIR gcv5 uses VM_RT_GC_HEAP_WRITE_REF
> today.
OK thanks. We need to get rid of the dead gcv4 code. This is probably
what refers to the old barrier helper.
>
> And are the monitor enter/exit functions all interruptible?
> >
>
> I think monenter is must be. Thread can stall for a long period of time on
> monenter. And I do not know if monexit is. At least it can throw
> IllegalState-like exception in theory.
Yes right, both throw exceptions like nullpointer, illegalmonitorstate
etc. But these are supposed to be thrown lazily.
>
> --
> Mikhail Fursov
>
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
>
> Mikhail,
> I have no problem with the ones you updated, but some questions...
>
> Is VM_RT_WRITE_BARRIER_FASTCALL in use?
This helper is dead code today. AFAIR gcv5 uses VM_RT_GC_HEAP_WRITE_REF
today.
And are the monitor enter/exit functions all interruptible?
>
I think monenter is must be. Thread can stall for a long period of time on
monenter. And I do not know if monexit is. At least it can throw
IllegalState-like exception in theory.
--
Mikhail Fursov
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Rana Dasgupta <rd...@gmail.com>.
Mikhail,
I have no problem with the ones you updated, but some questions...
Is VM_RT_WRITE_BARRIER_FASTCALL in use?
And are the monitor enter/exit functions all interruptible?
Rana
On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> On 4/17/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> > However, there is still some triage needed on which helper is
> > uninterruptible and which is not and why. Is that going to happen over
> > time and the interface method will be updated?
> >
> > I hope I did no mistakes marking some helpers as uninterruptible. So I see
> no reason to update this method in the future.
>
>
> --
> Mikhail Fursov
>
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/17/07, Rana Dasgupta <rd...@gmail.com> wrote:
>
> However, there is still some triage needed on which helper is
> uninterruptible and which is not and why. Is that going to happen over
> time and the interface method will be updated?
>
> I hope I did no mistakes marking some helpers as uninterruptible. So I see
no reason to update this method in the future.
--
Mikhail Fursov
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Rana Dasgupta <rd...@gmail.com>.
I may have misunderstood the intent of this thread.
The jit needs to know which helpers are uninterruptible for several
reasons, and it is convenient for it to ask the VM in one place rather
than hardcode. So the interface change on both sides is good and
commitable ( if tests pass etc. )
However, there is still some triage needed on which helper is
uninterruptible and which is not and why. Is that going to happen over
time and the interface method will be updated?
Thanks,
Rana
On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> Thanks, I will check it today.
>
> On 4/17/07, Gregory Shimansky <gs...@gmail.com> wrote:
> >
> > Xiao-Feng Li wrote:
> > > There is a break in Linux64 build. I will commit it after the SVN is ok.
> >
> > It should be fixed now in rev 529560.
> >
> > > On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > >> Let's commit it.
> > >>
> > >> On 4/17/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > >> >
> > >> > On 4/14/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > >> > > On 4/13/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > >> > > > I've attached combined JIT+VM patch to JIRA. The test failed
> > before
> > >> > passes
> > >> > > > now.
> > >> > > > VM-guru, please check VMEXPORT Boolean
> > >> > > > vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this
> > >> patch.
> > >> > >
> > >> > > VM gurus, please help checking this method in H3626. Thanks,
> > xiaofeng
> > >> >
> > >> > Mikhail, how would you like to proceed with this patch? Thanks.
> > >> >
> > >> > > > On 4/13/07, Alexey Varlamov <al...@gmail.com> wrote:
> > >> > > > >
> > >> > > > > 2007/4/13, Mikhail Fursov <mi...@gmail.com>:
> > >> > > > > > Rana,
> > >> > > > > > thank you for the fast update.
> > >> > > > > > I'll integrate this function usage into JIT and report if the
> > >> > problem I
> > >> > > > > have
> > >> > > > > > disappeares today.
> > >> > > > > >
> > >> > > > > > >>BTW, how does the jit knows which helpers throw exceptions?
> > >> > > > > > JIT generates stack info for every call instruction. So we
> > can
> > >> > > > > > unwind stack frame from every call.
> > >> > > > > > Actually this is not enough: JIT must generate stackinfo for
> > >> every
> > >> > push
> > >> > > > > inst
> > >> > > > > > also to handle SOE correctly. But this is one of the TODO
> > list
> > >> > items.
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > Another problem with helper calls I know is their calling
> > >> > conventions.
> > >> > > > > > Now the calling convention of every helper is hardcoded to
> > JIT.
> > >> > > > > > I think it worth creating another JIRA to solve the problem
> > one
> > >> > day.
> > >> > > > > Today I
> > >> > > > > > know no bugs about it, so it's design only issue.
> > >> > > > >
> > >> > > > > There is one already: HARMONY-2702. Actually Jitrino provides
> > >> such
> > >> > > > > interface internally,
> > >> > > > > CompilationInterface::getRuntimeHelperCallingConvention(), so
> > fix
> > >> > > > > should be easy enough (yet is blocked by HARMONY-3553).
> > >> > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > >> > > > > > >
> > >> > > > > > > Yes, that make sense. I'll wait a bit to see if Mikhail
> > >> has any
> > >> > more
> > >> > > > > > > suggestions and change it to is_gc_interruptible.
> > >> > > > > > >
> > >> > > > > > > On 4/12/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > >> > > > > > > > Agree that this information better be provided by VM
> > >> than JIT
> > >> > > > > internals.
> > >> > > > > > > >
> > >> > > > > > > > Rana, Thanks for the quick work. A minor comment:
> > >> > > > > > > >
> > >> > > > > > > > The interface name might be better use
> > >> "has_gc_safepoint" or
> > >> > > > > > > > "is_gc_interruptible" than "is_suspension_point", since
> > the
> > >> > helper
> > >> > > > > is
> > >> > > > > > > > a function (not a point), and "suspension" is
> > >> implementation
> > >> > detail.
> > >> > > > > > > >
> > >> > > > > > > > Thanks,
> > >> > > > > > > > xiaofeng
> > >> > > > > > > >
> > >> > > > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > >> > > > > > > > > Mikhail,
> > >> > > > > > > > > I extended the vm-jit interface with a function:
> > >> > > > > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f)
> > >> > > > > > > > >
> > >> > > > > > > > > and attached it to your JIRA.
> > >> > > > > > > > >
> > >> > > > > > > > > Right now it returns true for almost every helper.
> > >> But you
> > >> > may
> > >> > > > > want
> > >> > > > > > > > > to update this instead of hardcoding in the jit. At
> > some
> > >> > point, we
> > >> > > > > > > > > need some analysis to determine which helpers are
> > >> > interruptible.
> > >> > > > > > > > >
> > >> > > > > > > > > BTW, how does the jit knows which helpers throw
> > >> > exceptions?
> > >> > > > > > > > >
> > >> > > > > > > > > Rana
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > On 4/11/07, Mikhail Fursov <mi...@gmail.com>
> > wrote:
> > >> > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > On 4/11/07, Xiao-Feng Li <xi...@gmail.com>
> > >> wrote:
> > >> > > > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com>
> > >> wrote:
> > >> > > > > > > > > > > > > A silly question possibly. But other than
> > inlined
> > >> > > > > fastpaths,
> > >> > > > > > > why not
> > >> > > > > > > > > > > > > gcm treat all helper calls as interruptible?
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > I think this needs case by case study to decide
> > >> which
> > >> > ones
> > >> > > > > can
> > >> > > > > > > be
> > >> > > > > > > > > > > > interruptible. In most cases, the helper is only
> > an
> > >> > > > > extension of
> > >> > > > > > > a
> > >> > > > > > > > > > > > certain bytecode operation, which can be
> > virtually
> > >> > treated
> > >> > > > > as a
> > >> > > > > > > > > > > > bytecode (or part of a bytecode semantics).
> > >> Normally,
> > >> > the
> > >> > > > > > > safepoint
> > >> > > > > > > > > > > > can be before or after it, but not in middle of
> > >> it. If
> > >> > we
> > >> > > > > think
> > >> > > > > > > of the
> > >> > > > > > > > > > > > stack map info, the helper itself may not stand
> > >> for a
> > >> > formal
> > >> > > > > > > method
> > >> > > > > > > > > > > > frame for GC or exception handling.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > This is a good way to look at helper calls. My
> > point,
> > >> > > > > > > however, was
> > >> > > > > > > > > > > not really that helper calls should be
> > interruptible.
> > >> > But that
> > >> > > > > > > other
> > >> > > > > > > > > > > than the fastpath for which the JIT sees the IR,
> > >> why not
> > >> > treat
> > >> > > > > the
> > >> > > > > > > > > > > calls themselves as ineligible for code motion
> > >> etc. like
> > >> > other
> > >> > > > > > > > > > > operators with side effects? Is the cost too high?
> > >> > > > > > > > > > > Implementing the interface extension is not hard
> > >> for the
> > >> > VM,
> > >> > > > > but
> > >> > > > > > > looks
> > >> > > > > > > > > > > like implementation dependant info passed from the
> > >> VM to
> > >> > the
> > >> > > > > JIT.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Here is more details:
> > >> > > > > > > > > > The example of a helper that can be moved by GCM are
> > >> > number
> > >> > > > > > > conversion helpers.
> > >> > > > > > > > > > 'i2d' never throws exceptions and this knowledge is
> > >> > hardcoded in
> > >> > > > > > > HLO. On the
> > >> > > > > > > > > > other hand this HIR opcode is translated into LIR
> > >> > vm-helper
> > >> > > > > call, so
> > >> > > > > > > instead
> > >> > > > > > > > > > of simple Java opcode it becomes a
> > >> > > > > > > > > > call. I can hardcode which vm-helper call is
> > >> interruptable
> > >> > and
> > >> > > > > which
> > >> > > > > > > is
> > >> > > > > > > > > > not on the
> > >> > > > > > > > > > JIT side, but think retrieving this information from
> > >> VM is
> > >> > a
> > >> > > > > better
> > >> > > > > > > solution.
> > >> > > > > > > > > > Another example of uninterruptable vm-helper is
> > >> > > > > > > > > > TLS accessor. This helper is placed into the middle
> > >> of the
> > >> > > > > inlined
> > >> > > > > > > > > > 'alloc' helper body because 'alloc' reqires TLS
> > access.
> > >> > > > > > > > > > Now managed<->unmanaged convertion checker in GCMap
> > >> pass
> > >> > has
> > >> > > > > > > hardcoded
> > >> > > > > > > > > > knowledge that TLS access will never be suspended.
> > >> > > > > > > > > >
> > >> > > > > > > > > > JET compiler uses different code then OPT and
> > maintains
> > >> > special
> > >> > > > > > > > > > GC-bitmasks for object operands runtime.
> > >> > > > > > > > > > The per-call gc-mask maintainance is not free and
> > >> can also
> > >> > be
> > >> > > > > > > > > > optimized if VM provides a method to describe which
> > >> call
> > >> > is real
> > >> > > > > > > > > > suspension point and which is not.
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > > > + Suspension and exception throwing are different
> > >> > attributes.
> > >> > > > > SOE
> > >> > > > > > > can be
> > >> > > > > > > > > > thrown even if method is not a suspension point. So
> > JIT
> > >> > must
> > >> > > > > prepare
> > >> > > > > > > stack
> > >> > > > > > > > > > info for every call it generates to be able to
> > >> unwind the
> > >> > > > > frame.
> > >> > > > > > > > > >
> > >> > > > > > > > > > --
> > >> > > > > > > > > > Mikhail Fursov
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > --
> > >> > > > > > > > http://xiao-feng.blogspot.com
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > --
> > >> > > > > > Mikhail Fursov
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Mikhail Fursov
> > >> > > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > http://xiao-feng.blogspot.com
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > http://xiao-feng.blogspot.com
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Mikhail Fursov
> > >>
> > >
> > >
> >
> >
> > --
> > Gregory
> >
> >
>
>
> --
> Mikhail Fursov
>
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Mikhail Fursov <mi...@gmail.com>.
Thanks, I will check it today.
On 4/17/07, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Xiao-Feng Li wrote:
> > There is a break in Linux64 build. I will commit it after the SVN is ok.
>
> It should be fixed now in rev 529560.
>
> > On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> >> Let's commit it.
> >>
> >> On 4/17/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >> >
> >> > On 4/14/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >> > > On 4/13/07, Mikhail Fursov <mi...@gmail.com> wrote:
> >> > > > I've attached combined JIT+VM patch to JIRA. The test failed
> before
> >> > passes
> >> > > > now.
> >> > > > VM-guru, please check VMEXPORT Boolean
> >> > > > vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this
> >> patch.
> >> > >
> >> > > VM gurus, please help checking this method in H3626. Thanks,
> xiaofeng
> >> >
> >> > Mikhail, how would you like to proceed with this patch? Thanks.
> >> >
> >> > > > On 4/13/07, Alexey Varlamov <al...@gmail.com> wrote:
> >> > > > >
> >> > > > > 2007/4/13, Mikhail Fursov <mi...@gmail.com>:
> >> > > > > > Rana,
> >> > > > > > thank you for the fast update.
> >> > > > > > I'll integrate this function usage into JIT and report if the
> >> > problem I
> >> > > > > have
> >> > > > > > disappeares today.
> >> > > > > >
> >> > > > > > >>BTW, how does the jit knows which helpers throw exceptions?
> >> > > > > > JIT generates stack info for every call instruction. So we
> can
> >> > > > > > unwind stack frame from every call.
> >> > > > > > Actually this is not enough: JIT must generate stackinfo for
> >> every
> >> > push
> >> > > > > inst
> >> > > > > > also to handle SOE correctly. But this is one of the TODO
> list
> >> > items.
> >> > > > > >
> >> > > > > >
> >> > > > > > Another problem with helper calls I know is their calling
> >> > conventions.
> >> > > > > > Now the calling convention of every helper is hardcoded to
> JIT.
> >> > > > > > I think it worth creating another JIRA to solve the problem
> one
> >> > day.
> >> > > > > Today I
> >> > > > > > know no bugs about it, so it's design only issue.
> >> > > > >
> >> > > > > There is one already: HARMONY-2702. Actually Jitrino provides
> >> such
> >> > > > > interface internally,
> >> > > > > CompilationInterface::getRuntimeHelperCallingConvention(), so
> fix
> >> > > > > should be easy enough (yet is blocked by HARMONY-3553).
> >> > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >> > > > > > >
> >> > > > > > > Yes, that make sense. I'll wait a bit to see if Mikhail
> >> has any
> >> > more
> >> > > > > > > suggestions and change it to is_gc_interruptible.
> >> > > > > > >
> >> > > > > > > On 4/12/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >> > > > > > > > Agree that this information better be provided by VM
> >> than JIT
> >> > > > > internals.
> >> > > > > > > >
> >> > > > > > > > Rana, Thanks for the quick work. A minor comment:
> >> > > > > > > >
> >> > > > > > > > The interface name might be better use
> >> "has_gc_safepoint" or
> >> > > > > > > > "is_gc_interruptible" than "is_suspension_point", since
> the
> >> > helper
> >> > > > > is
> >> > > > > > > > a function (not a point), and "suspension" is
> >> implementation
> >> > detail.
> >> > > > > > > >
> >> > > > > > > > Thanks,
> >> > > > > > > > xiaofeng
> >> > > > > > > >
> >> > > > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >> > > > > > > > > Mikhail,
> >> > > > > > > > > I extended the vm-jit interface with a function:
> >> > > > > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f)
> >> > > > > > > > >
> >> > > > > > > > > and attached it to your JIRA.
> >> > > > > > > > >
> >> > > > > > > > > Right now it returns true for almost every helper.
> >> But you
> >> > may
> >> > > > > want
> >> > > > > > > > > to update this instead of hardcoding in the jit. At
> some
> >> > point, we
> >> > > > > > > > > need some analysis to determine which helpers are
> >> > interruptible.
> >> > > > > > > > >
> >> > > > > > > > > BTW, how does the jit knows which helpers throw
> >> > exceptions?
> >> > > > > > > > >
> >> > > > > > > > > Rana
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > On 4/11/07, Mikhail Fursov <mi...@gmail.com>
> wrote:
> >> > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> >> > > > > > > > > > >
> >> > > > > > > > > > > On 4/11/07, Xiao-Feng Li <xi...@gmail.com>
> >> wrote:
> >> > > > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com>
> >> wrote:
> >> > > > > > > > > > > > > A silly question possibly. But other than
> inlined
> >> > > > > fastpaths,
> >> > > > > > > why not
> >> > > > > > > > > > > > > gcm treat all helper calls as interruptible?
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > I think this needs case by case study to decide
> >> which
> >> > ones
> >> > > > > can
> >> > > > > > > be
> >> > > > > > > > > > > > interruptible. In most cases, the helper is only
> an
> >> > > > > extension of
> >> > > > > > > a
> >> > > > > > > > > > > > certain bytecode operation, which can be
> virtually
> >> > treated
> >> > > > > as a
> >> > > > > > > > > > > > bytecode (or part of a bytecode semantics).
> >> Normally,
> >> > the
> >> > > > > > > safepoint
> >> > > > > > > > > > > > can be before or after it, but not in middle of
> >> it. If
> >> > we
> >> > > > > think
> >> > > > > > > of the
> >> > > > > > > > > > > > stack map info, the helper itself may not stand
> >> for a
> >> > formal
> >> > > > > > > method
> >> > > > > > > > > > > > frame for GC or exception handling.
> >> > > > > > > > > > >
> >> > > > > > > > > > > This is a good way to look at helper calls. My
> point,
> >> > > > > > > however, was
> >> > > > > > > > > > > not really that helper calls should be
> interruptible.
> >> > But that
> >> > > > > > > other
> >> > > > > > > > > > > than the fastpath for which the JIT sees the IR,
> >> why not
> >> > treat
> >> > > > > the
> >> > > > > > > > > > > calls themselves as ineligible for code motion
> >> etc. like
> >> > other
> >> > > > > > > > > > > operators with side effects? Is the cost too high?
> >> > > > > > > > > > > Implementing the interface extension is not hard
> >> for the
> >> > VM,
> >> > > > > but
> >> > > > > > > looks
> >> > > > > > > > > > > like implementation dependant info passed from the
> >> VM to
> >> > the
> >> > > > > JIT.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Here is more details:
> >> > > > > > > > > > The example of a helper that can be moved by GCM are
> >> > number
> >> > > > > > > conversion helpers.
> >> > > > > > > > > > 'i2d' never throws exceptions and this knowledge is
> >> > hardcoded in
> >> > > > > > > HLO. On the
> >> > > > > > > > > > other hand this HIR opcode is translated into LIR
> >> > vm-helper
> >> > > > > call, so
> >> > > > > > > instead
> >> > > > > > > > > > of simple Java opcode it becomes a
> >> > > > > > > > > > call. I can hardcode which vm-helper call is
> >> interruptable
> >> > and
> >> > > > > which
> >> > > > > > > is
> >> > > > > > > > > > not on the
> >> > > > > > > > > > JIT side, but think retrieving this information from
> >> VM is
> >> > a
> >> > > > > better
> >> > > > > > > solution.
> >> > > > > > > > > > Another example of uninterruptable vm-helper is
> >> > > > > > > > > > TLS accessor. This helper is placed into the middle
> >> of the
> >> > > > > inlined
> >> > > > > > > > > > 'alloc' helper body because 'alloc' reqires TLS
> access.
> >> > > > > > > > > > Now managed<->unmanaged convertion checker in GCMap
> >> pass
> >> > has
> >> > > > > > > hardcoded
> >> > > > > > > > > > knowledge that TLS access will never be suspended.
> >> > > > > > > > > >
> >> > > > > > > > > > JET compiler uses different code then OPT and
> maintains
> >> > special
> >> > > > > > > > > > GC-bitmasks for object operands runtime.
> >> > > > > > > > > > The per-call gc-mask maintainance is not free and
> >> can also
> >> > be
> >> > > > > > > > > > optimized if VM provides a method to describe which
> >> call
> >> > is real
> >> > > > > > > > > > suspension point and which is not.
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > + Suspension and exception throwing are different
> >> > attributes.
> >> > > > > SOE
> >> > > > > > > can be
> >> > > > > > > > > > thrown even if method is not a suspension point. So
> JIT
> >> > must
> >> > > > > prepare
> >> > > > > > > stack
> >> > > > > > > > > > info for every call it generates to be able to
> >> unwind the
> >> > > > > frame.
> >> > > > > > > > > >
> >> > > > > > > > > > --
> >> > > > > > > > > > Mikhail Fursov
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > --
> >> > > > > > > > http://xiao-feng.blogspot.com
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Mikhail Fursov
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Mikhail Fursov
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > http://xiao-feng.blogspot.com
> >> > >
> >> >
> >> >
> >> > --
> >> > http://xiao-feng.blogspot.com
> >> >
> >>
> >>
> >>
> >> --
> >> Mikhail Fursov
> >>
> >
> >
>
>
> --
> Gregory
>
>
--
Mikhail Fursov
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Gregory Shimansky <gs...@gmail.com>.
Xiao-Feng Li wrote:
> There is a break in Linux64 build. I will commit it after the SVN is ok.
It should be fixed now in rev 529560.
> On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
>> Let's commit it.
>>
>> On 4/17/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>> >
>> > On 4/14/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>> > > On 4/13/07, Mikhail Fursov <mi...@gmail.com> wrote:
>> > > > I've attached combined JIT+VM patch to JIRA. The test failed before
>> > passes
>> > > > now.
>> > > > VM-guru, please check VMEXPORT Boolean
>> > > > vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this
>> patch.
>> > >
>> > > VM gurus, please help checking this method in H3626. Thanks, xiaofeng
>> >
>> > Mikhail, how would you like to proceed with this patch? Thanks.
>> >
>> > > > On 4/13/07, Alexey Varlamov <al...@gmail.com> wrote:
>> > > > >
>> > > > > 2007/4/13, Mikhail Fursov <mi...@gmail.com>:
>> > > > > > Rana,
>> > > > > > thank you for the fast update.
>> > > > > > I'll integrate this function usage into JIT and report if the
>> > problem I
>> > > > > have
>> > > > > > disappeares today.
>> > > > > >
>> > > > > > >>BTW, how does the jit knows which helpers throw exceptions?
>> > > > > > JIT generates stack info for every call instruction. So we can
>> > > > > > unwind stack frame from every call.
>> > > > > > Actually this is not enough: JIT must generate stackinfo for
>> every
>> > push
>> > > > > inst
>> > > > > > also to handle SOE correctly. But this is one of the TODO list
>> > items.
>> > > > > >
>> > > > > >
>> > > > > > Another problem with helper calls I know is their calling
>> > conventions.
>> > > > > > Now the calling convention of every helper is hardcoded to JIT.
>> > > > > > I think it worth creating another JIRA to solve the problem one
>> > day.
>> > > > > Today I
>> > > > > > know no bugs about it, so it's design only issue.
>> > > > >
>> > > > > There is one already: HARMONY-2702. Actually Jitrino provides
>> such
>> > > > > interface internally,
>> > > > > CompilationInterface::getRuntimeHelperCallingConvention(), so fix
>> > > > > should be easy enough (yet is blocked by HARMONY-3553).
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > > > >
>> > > > > > > Yes, that make sense. I'll wait a bit to see if Mikhail
>> has any
>> > more
>> > > > > > > suggestions and change it to is_gc_interruptible.
>> > > > > > >
>> > > > > > > On 4/12/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>> > > > > > > > Agree that this information better be provided by VM
>> than JIT
>> > > > > internals.
>> > > > > > > >
>> > > > > > > > Rana, Thanks for the quick work. A minor comment:
>> > > > > > > >
>> > > > > > > > The interface name might be better use
>> "has_gc_safepoint" or
>> > > > > > > > "is_gc_interruptible" than "is_suspension_point", since the
>> > helper
>> > > > > is
>> > > > > > > > a function (not a point), and "suspension" is
>> implementation
>> > detail.
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > > xiaofeng
>> > > > > > > >
>> > > > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > > > > > > Mikhail,
>> > > > > > > > > I extended the vm-jit interface with a function:
>> > > > > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f)
>> > > > > > > > >
>> > > > > > > > > and attached it to your JIRA.
>> > > > > > > > >
>> > > > > > > > > Right now it returns true for almost every helper.
>> But you
>> > may
>> > > > > want
>> > > > > > > > > to update this instead of hardcoding in the jit. At some
>> > point, we
>> > > > > > > > > need some analysis to determine which helpers are
>> > interruptible.
>> > > > > > > > >
>> > > > > > > > > BTW, how does the jit knows which helpers throw
>> > exceptions?
>> > > > > > > > >
>> > > > > > > > > Rana
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
>> > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > On 4/11/07, Xiao-Feng Li <xi...@gmail.com>
>> wrote:
>> > > > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com>
>> wrote:
>> > > > > > > > > > > > > A silly question possibly. But other than inlined
>> > > > > fastpaths,
>> > > > > > > why not
>> > > > > > > > > > > > > gcm treat all helper calls as interruptible?
>> > > > > > > > > > > >
>> > > > > > > > > > > > I think this needs case by case study to decide
>> which
>> > ones
>> > > > > can
>> > > > > > > be
>> > > > > > > > > > > > interruptible. In most cases, the helper is only an
>> > > > > extension of
>> > > > > > > a
>> > > > > > > > > > > > certain bytecode operation, which can be virtually
>> > treated
>> > > > > as a
>> > > > > > > > > > > > bytecode (or part of a bytecode semantics).
>> Normally,
>> > the
>> > > > > > > safepoint
>> > > > > > > > > > > > can be before or after it, but not in middle of
>> it. If
>> > we
>> > > > > think
>> > > > > > > of the
>> > > > > > > > > > > > stack map info, the helper itself may not stand
>> for a
>> > formal
>> > > > > > > method
>> > > > > > > > > > > > frame for GC or exception handling.
>> > > > > > > > > > >
>> > > > > > > > > > > This is a good way to look at helper calls. My point,
>> > > > > > > however, was
>> > > > > > > > > > > not really that helper calls should be interruptible.
>> > But that
>> > > > > > > other
>> > > > > > > > > > > than the fastpath for which the JIT sees the IR,
>> why not
>> > treat
>> > > > > the
>> > > > > > > > > > > calls themselves as ineligible for code motion
>> etc. like
>> > other
>> > > > > > > > > > > operators with side effects? Is the cost too high?
>> > > > > > > > > > > Implementing the interface extension is not hard
>> for the
>> > VM,
>> > > > > but
>> > > > > > > looks
>> > > > > > > > > > > like implementation dependant info passed from the
>> VM to
>> > the
>> > > > > JIT.
>> > > > > > > > > > >
>> > > > > > > > > > > Here is more details:
>> > > > > > > > > > The example of a helper that can be moved by GCM are
>> > number
>> > > > > > > conversion helpers.
>> > > > > > > > > > 'i2d' never throws exceptions and this knowledge is
>> > hardcoded in
>> > > > > > > HLO. On the
>> > > > > > > > > > other hand this HIR opcode is translated into LIR
>> > vm-helper
>> > > > > call, so
>> > > > > > > instead
>> > > > > > > > > > of simple Java opcode it becomes a
>> > > > > > > > > > call. I can hardcode which vm-helper call is
>> interruptable
>> > and
>> > > > > which
>> > > > > > > is
>> > > > > > > > > > not on the
>> > > > > > > > > > JIT side, but think retrieving this information from
>> VM is
>> > a
>> > > > > better
>> > > > > > > solution.
>> > > > > > > > > > Another example of uninterruptable vm-helper is
>> > > > > > > > > > TLS accessor. This helper is placed into the middle
>> of the
>> > > > > inlined
>> > > > > > > > > > 'alloc' helper body because 'alloc' reqires TLS access.
>> > > > > > > > > > Now managed<->unmanaged convertion checker in GCMap
>> pass
>> > has
>> > > > > > > hardcoded
>> > > > > > > > > > knowledge that TLS access will never be suspended.
>> > > > > > > > > >
>> > > > > > > > > > JET compiler uses different code then OPT and maintains
>> > special
>> > > > > > > > > > GC-bitmasks for object operands runtime.
>> > > > > > > > > > The per-call gc-mask maintainance is not free and
>> can also
>> > be
>> > > > > > > > > > optimized if VM provides a method to describe which
>> call
>> > is real
>> > > > > > > > > > suspension point and which is not.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > + Suspension and exception throwing are different
>> > attributes.
>> > > > > SOE
>> > > > > > > can be
>> > > > > > > > > > thrown even if method is not a suspension point. So JIT
>> > must
>> > > > > prepare
>> > > > > > > stack
>> > > > > > > > > > info for every call it generates to be able to
>> unwind the
>> > > > > frame.
>> > > > > > > > > >
>> > > > > > > > > > --
>> > > > > > > > > > Mikhail Fursov
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > http://xiao-feng.blogspot.com
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Mikhail Fursov
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Mikhail Fursov
>> > > >
>> > >
>> > >
>> > > --
>> > > http://xiao-feng.blogspot.com
>> > >
>> >
>> >
>> > --
>> > http://xiao-feng.blogspot.com
>> >
>>
>>
>>
>> --
>> Mikhail Fursov
>>
>
>
--
Gregory
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Xiao-Feng Li <xi...@gmail.com>.
There is a break in Linux64 build. I will commit it after the SVN is ok.
Thanks,
xiaofeng
On 4/17/07, Mikhail Fursov <mi...@gmail.com> wrote:
> Let's commit it.
>
> On 4/17/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >
> > On 4/14/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > On 4/13/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > I've attached combined JIT+VM patch to JIRA. The test failed before
> > passes
> > > > now.
> > > > VM-guru, please check VMEXPORT Boolean
> > > > vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this patch.
> > >
> > > VM gurus, please help checking this method in H3626. Thanks, xiaofeng
> >
> > Mikhail, how would you like to proceed with this patch? Thanks.
> >
> > > > On 4/13/07, Alexey Varlamov <al...@gmail.com> wrote:
> > > > >
> > > > > 2007/4/13, Mikhail Fursov <mi...@gmail.com>:
> > > > > > Rana,
> > > > > > thank you for the fast update.
> > > > > > I'll integrate this function usage into JIT and report if the
> > problem I
> > > > > have
> > > > > > disappeares today.
> > > > > >
> > > > > > >>BTW, how does the jit knows which helpers throw exceptions?
> > > > > > JIT generates stack info for every call instruction. So we can
> > > > > > unwind stack frame from every call.
> > > > > > Actually this is not enough: JIT must generate stackinfo for every
> > push
> > > > > inst
> > > > > > also to handle SOE correctly. But this is one of the TODO list
> > items.
> > > > > >
> > > > > >
> > > > > > Another problem with helper calls I know is their calling
> > conventions.
> > > > > > Now the calling convention of every helper is hardcoded to JIT.
> > > > > > I think it worth creating another JIRA to solve the problem one
> > day.
> > > > > Today I
> > > > > > know no bugs about it, so it's design only issue.
> > > > >
> > > > > There is one already: HARMONY-2702. Actually Jitrino provides such
> > > > > interface internally,
> > > > > CompilationInterface::getRuntimeHelperCallingConvention(), so fix
> > > > > should be easy enough (yet is blocked by HARMONY-3553).
> > > > >
> > > > > >
> > > > > >
> > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > >
> > > > > > > Yes, that make sense. I'll wait a bit to see if Mikhail has any
> > more
> > > > > > > suggestions and change it to is_gc_interruptible.
> > > > > > >
> > > > > > > On 4/12/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > > Agree that this information better be provided by VM than JIT
> > > > > internals.
> > > > > > > >
> > > > > > > > Rana, Thanks for the quick work. A minor comment:
> > > > > > > >
> > > > > > > > The interface name might be better use "has_gc_safepoint" or
> > > > > > > > "is_gc_interruptible" than "is_suspension_point", since the
> > helper
> > > > > is
> > > > > > > > a function (not a point), and "suspension" is implementation
> > detail.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > xiaofeng
> > > > > > > >
> > > > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > > Mikhail,
> > > > > > > > > I extended the vm-jit interface with a function:
> > > > > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f)
> > > > > > > > >
> > > > > > > > > and attached it to your JIRA.
> > > > > > > > >
> > > > > > > > > Right now it returns true for almost every helper. But you
> > may
> > > > > want
> > > > > > > > > to update this instead of hardcoding in the jit. At some
> > point, we
> > > > > > > > > need some analysis to determine which helpers are
> > interruptible.
> > > > > > > > >
> > > > > > > > > BTW, how does the jit knows which helpers throw
> > exceptions?
> > > > > > > > >
> > > > > > > > > Rana
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On 4/11/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > > > > > > A silly question possibly. But other than inlined
> > > > > fastpaths,
> > > > > > > why not
> > > > > > > > > > > > > gcm treat all helper calls as interruptible?
> > > > > > > > > > > >
> > > > > > > > > > > > I think this needs case by case study to decide which
> > ones
> > > > > can
> > > > > > > be
> > > > > > > > > > > > interruptible. In most cases, the helper is only an
> > > > > extension of
> > > > > > > a
> > > > > > > > > > > > certain bytecode operation, which can be virtually
> > treated
> > > > > as a
> > > > > > > > > > > > bytecode (or part of a bytecode semantics). Normally,
> > the
> > > > > > > safepoint
> > > > > > > > > > > > can be before or after it, but not in middle of it. If
> > we
> > > > > think
> > > > > > > of the
> > > > > > > > > > > > stack map info, the helper itself may not stand for a
> > formal
> > > > > > > method
> > > > > > > > > > > > frame for GC or exception handling.
> > > > > > > > > > >
> > > > > > > > > > > This is a good way to look at helper calls. My point,
> > > > > > > however, was
> > > > > > > > > > > not really that helper calls should be interruptible.
> > But that
> > > > > > > other
> > > > > > > > > > > than the fastpath for which the JIT sees the IR, why not
> > treat
> > > > > the
> > > > > > > > > > > calls themselves as ineligible for code motion etc. like
> > other
> > > > > > > > > > > operators with side effects? Is the cost too high?
> > > > > > > > > > > Implementing the interface extension is not hard for the
> > VM,
> > > > > but
> > > > > > > looks
> > > > > > > > > > > like implementation dependant info passed from the VM to
> > the
> > > > > JIT.
> > > > > > > > > > >
> > > > > > > > > > > Here is more details:
> > > > > > > > > > The example of a helper that can be moved by GCM are
> > number
> > > > > > > conversion helpers.
> > > > > > > > > > 'i2d' never throws exceptions and this knowledge is
> > hardcoded in
> > > > > > > HLO. On the
> > > > > > > > > > other hand this HIR opcode is translated into LIR
> > vm-helper
> > > > > call, so
> > > > > > > instead
> > > > > > > > > > of simple Java opcode it becomes a
> > > > > > > > > > call. I can hardcode which vm-helper call is interruptable
> > and
> > > > > which
> > > > > > > is
> > > > > > > > > > not on the
> > > > > > > > > > JIT side, but think retrieving this information from VM is
> > a
> > > > > better
> > > > > > > solution.
> > > > > > > > > > Another example of uninterruptable vm-helper is
> > > > > > > > > > TLS accessor. This helper is placed into the middle of the
> > > > > inlined
> > > > > > > > > > 'alloc' helper body because 'alloc' reqires TLS access.
> > > > > > > > > > Now managed<->unmanaged convertion checker in GCMap pass
> > has
> > > > > > > hardcoded
> > > > > > > > > > knowledge that TLS access will never be suspended.
> > > > > > > > > >
> > > > > > > > > > JET compiler uses different code then OPT and maintains
> > special
> > > > > > > > > > GC-bitmasks for object operands runtime.
> > > > > > > > > > The per-call gc-mask maintainance is not free and can also
> > be
> > > > > > > > > > optimized if VM provides a method to describe which call
> > is real
> > > > > > > > > > suspension point and which is not.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > + Suspension and exception throwing are different
> > attributes.
> > > > > SOE
> > > > > > > can be
> > > > > > > > > > thrown even if method is not a suspension point. So JIT
> > must
> > > > > prepare
> > > > > > > stack
> > > > > > > > > > info for every call it generates to be able to unwind the
> > > > > frame.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Mikhail Fursov
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > http://xiao-feng.blogspot.com
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mikhail Fursov
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Mikhail Fursov
> > > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
>
> --
> Mikhail Fursov
>
--
http://xiao-feng.blogspot.com
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Mikhail Fursov <mi...@gmail.com>.
Let's commit it.
On 4/17/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> On 4/14/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > On 4/13/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > I've attached combined JIT+VM patch to JIRA. The test failed before
> passes
> > > now.
> > > VM-guru, please check VMEXPORT Boolean
> > > vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this patch.
> >
> > VM gurus, please help checking this method in H3626. Thanks, xiaofeng
>
> Mikhail, how would you like to proceed with this patch? Thanks.
>
> > > On 4/13/07, Alexey Varlamov <al...@gmail.com> wrote:
> > > >
> > > > 2007/4/13, Mikhail Fursov <mi...@gmail.com>:
> > > > > Rana,
> > > > > thank you for the fast update.
> > > > > I'll integrate this function usage into JIT and report if the
> problem I
> > > > have
> > > > > disappeares today.
> > > > >
> > > > > >>BTW, how does the jit knows which helpers throw exceptions?
> > > > > JIT generates stack info for every call instruction. So we can
> > > > > unwind stack frame from every call.
> > > > > Actually this is not enough: JIT must generate stackinfo for every
> push
> > > > inst
> > > > > also to handle SOE correctly. But this is one of the TODO list
> items.
> > > > >
> > > > >
> > > > > Another problem with helper calls I know is their calling
> conventions.
> > > > > Now the calling convention of every helper is hardcoded to JIT.
> > > > > I think it worth creating another JIRA to solve the problem one
> day.
> > > > Today I
> > > > > know no bugs about it, so it's design only issue.
> > > >
> > > > There is one already: HARMONY-2702. Actually Jitrino provides such
> > > > interface internally,
> > > > CompilationInterface::getRuntimeHelperCallingConvention(), so fix
> > > > should be easy enough (yet is blocked by HARMONY-3553).
> > > >
> > > > >
> > > > >
> > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > >
> > > > > > Yes, that make sense. I'll wait a bit to see if Mikhail has any
> more
> > > > > > suggestions and change it to is_gc_interruptible.
> > > > > >
> > > > > > On 4/12/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > Agree that this information better be provided by VM than JIT
> > > > internals.
> > > > > > >
> > > > > > > Rana, Thanks for the quick work. A minor comment:
> > > > > > >
> > > > > > > The interface name might be better use "has_gc_safepoint" or
> > > > > > > "is_gc_interruptible" than "is_suspension_point", since the
> helper
> > > > is
> > > > > > > a function (not a point), and "suspension" is implementation
> detail.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > xiaofeng
> > > > > > >
> > > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > Mikhail,
> > > > > > > > I extended the vm-jit interface with a function:
> > > > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f)
> > > > > > > >
> > > > > > > > and attached it to your JIRA.
> > > > > > > >
> > > > > > > > Right now it returns true for almost every helper. But you
> may
> > > > want
> > > > > > > > to update this instead of hardcoding in the jit. At some
> point, we
> > > > > > > > need some analysis to determine which helpers are
> interruptible.
> > > > > > > >
> > > > > > > > BTW, how does the jit knows which helpers throw
> exceptions?
> > > > > > > >
> > > > > > > > Rana
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On 4/11/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > > > > > A silly question possibly. But other than inlined
> > > > fastpaths,
> > > > > > why not
> > > > > > > > > > > > gcm treat all helper calls as interruptible?
> > > > > > > > > > >
> > > > > > > > > > > I think this needs case by case study to decide which
> ones
> > > > can
> > > > > > be
> > > > > > > > > > > interruptible. In most cases, the helper is only an
> > > > extension of
> > > > > > a
> > > > > > > > > > > certain bytecode operation, which can be virtually
> treated
> > > > as a
> > > > > > > > > > > bytecode (or part of a bytecode semantics). Normally,
> the
> > > > > > safepoint
> > > > > > > > > > > can be before or after it, but not in middle of it. If
> we
> > > > think
> > > > > > of the
> > > > > > > > > > > stack map info, the helper itself may not stand for a
> formal
> > > > > > method
> > > > > > > > > > > frame for GC or exception handling.
> > > > > > > > > >
> > > > > > > > > > This is a good way to look at helper calls. My point,
> > > > > > however, was
> > > > > > > > > > not really that helper calls should be interruptible.
> But that
> > > > > > other
> > > > > > > > > > than the fastpath for which the JIT sees the IR, why not
> treat
> > > > the
> > > > > > > > > > calls themselves as ineligible for code motion etc. like
> other
> > > > > > > > > > operators with side effects? Is the cost too high?
> > > > > > > > > > Implementing the interface extension is not hard for the
> VM,
> > > > but
> > > > > > looks
> > > > > > > > > > like implementation dependant info passed from the VM to
> the
> > > > JIT.
> > > > > > > > > >
> > > > > > > > > > Here is more details:
> > > > > > > > > The example of a helper that can be moved by GCM are
> number
> > > > > > conversion helpers.
> > > > > > > > > 'i2d' never throws exceptions and this knowledge is
> hardcoded in
> > > > > > HLO. On the
> > > > > > > > > other hand this HIR opcode is translated into LIR
> vm-helper
> > > > call, so
> > > > > > instead
> > > > > > > > > of simple Java opcode it becomes a
> > > > > > > > > call. I can hardcode which vm-helper call is interruptable
> and
> > > > which
> > > > > > is
> > > > > > > > > not on the
> > > > > > > > > JIT side, but think retrieving this information from VM is
> a
> > > > better
> > > > > > solution.
> > > > > > > > > Another example of uninterruptable vm-helper is
> > > > > > > > > TLS accessor. This helper is placed into the middle of the
> > > > inlined
> > > > > > > > > 'alloc' helper body because 'alloc' reqires TLS access.
> > > > > > > > > Now managed<->unmanaged convertion checker in GCMap pass
> has
> > > > > > hardcoded
> > > > > > > > > knowledge that TLS access will never be suspended.
> > > > > > > > >
> > > > > > > > > JET compiler uses different code then OPT and maintains
> special
> > > > > > > > > GC-bitmasks for object operands runtime.
> > > > > > > > > The per-call gc-mask maintainance is not free and can also
> be
> > > > > > > > > optimized if VM provides a method to describe which call
> is real
> > > > > > > > > suspension point and which is not.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > + Suspension and exception throwing are different
> attributes.
> > > > SOE
> > > > > > can be
> > > > > > > > > thrown even if method is not a suspension point. So JIT
> must
> > > > prepare
> > > > > > stack
> > > > > > > > > info for every call it generates to be able to unwind the
> > > > frame.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Mikhail Fursov
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > http://xiao-feng.blogspot.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Mikhail Fursov
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Mikhail Fursov
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Mikhail Fursov
Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/14/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 4/13/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > I've attached combined JIT+VM patch to JIRA. The test failed before passes
> > now.
> > VM-guru, please check VMEXPORT Boolean
> > vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this patch.
>
> VM gurus, please help checking this method in H3626. Thanks, xiaofeng
Mikhail, how would you like to proceed with this patch? Thanks.
> > On 4/13/07, Alexey Varlamov <al...@gmail.com> wrote:
> > >
> > > 2007/4/13, Mikhail Fursov <mi...@gmail.com>:
> > > > Rana,
> > > > thank you for the fast update.
> > > > I'll integrate this function usage into JIT and report if the problem I
> > > have
> > > > disappeares today.
> > > >
> > > > >>BTW, how does the jit knows which helpers throw exceptions?
> > > > JIT generates stack info for every call instruction. So we can
> > > > unwind stack frame from every call.
> > > > Actually this is not enough: JIT must generate stackinfo for every push
> > > inst
> > > > also to handle SOE correctly. But this is one of the TODO list items.
> > > >
> > > >
> > > > Another problem with helper calls I know is their calling conventions.
> > > > Now the calling convention of every helper is hardcoded to JIT.
> > > > I think it worth creating another JIRA to solve the problem one day.
> > > Today I
> > > > know no bugs about it, so it's design only issue.
> > >
> > > There is one already: HARMONY-2702. Actually Jitrino provides such
> > > interface internally,
> > > CompilationInterface::getRuntimeHelperCallingConvention(), so fix
> > > should be easy enough (yet is blocked by HARMONY-3553).
> > >
> > > >
> > > >
> > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > >
> > > > > Yes, that make sense. I'll wait a bit to see if Mikhail has any more
> > > > > suggestions and change it to is_gc_interruptible.
> > > > >
> > > > > On 4/12/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > Agree that this information better be provided by VM than JIT
> > > internals.
> > > > > >
> > > > > > Rana, Thanks for the quick work. A minor comment:
> > > > > >
> > > > > > The interface name might be better use "has_gc_safepoint" or
> > > > > > "is_gc_interruptible" than "is_suspension_point", since the helper
> > > is
> > > > > > a function (not a point), and "suspension" is implementation detail.
> > > > > >
> > > > > > Thanks,
> > > > > > xiaofeng
> > > > > >
> > > > > > On 4/13/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > Mikhail,
> > > > > > > I extended the vm-jit interface with a function:
> > > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f)
> > > > > > >
> > > > > > > and attached it to your JIRA.
> > > > > > >
> > > > > > > Right now it returns true for almost every helper. But you may
> > > want
> > > > > > > to update this instead of hardcoding in the jit. At some point, we
> > > > > > > need some analysis to determine which helpers are interruptible.
> > > > > > >
> > > > > > > BTW, how does the jit knows which helpers throw exceptions?
> > > > > > >
> > > > > > > Rana
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 4/11/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > > > > On 4/12/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > > > > > > A silly question possibly. But other than inlined
> > > fastpaths,
> > > > > why not
> > > > > > > > > > > gcm treat all helper calls as interruptible?
> > > > > > > > > >
> > > > > > > > > > I think this needs case by case study to decide which ones
> > > can
> > > > > be
> > > > > > > > > > interruptible. In most cases, the helper is only an
> > > extension of
> > > > > a
> > > > > > > > > > certain bytecode operation, which can be virtually treated
> > > as a
> > > > > > > > > > bytecode (or part of a bytecode semantics). Normally, the
> > > > > safepoint
> > > > > > > > > > can be before or after it, but not in middle of it. If we
> > > think
> > > > > of the
> > > > > > > > > > stack map info, the helper itself may not stand for a formal
> > > > > method
> > > > > > > > > > frame for GC or exception handling.
> > > > > > > > >
> > > > > > > > > This is a good way to look at helper calls. My point,
> > > > > however, was
> > > > > > > > > not really that helper calls should be interruptible. But that
> > > > > other
> > > > > > > > > than the fastpath for which the JIT sees the IR, why not treat
> > > the
> > > > > > > > > calls themselves as ineligible for code motion etc. like other
> > > > > > > > > operators with side effects? Is the cost too high?
> > > > > > > > > Implementing the interface extension is not hard for the VM,
> > > but
> > > > > looks
> > > > > > > > > like implementation dependant info passed from the VM to the
> > > JIT.
> > > > > > > > >
> > > > > > > > > Here is more details:
> > > > > > > > The example of a helper that can be moved by GCM are number
> > > > > conversion helpers.
> > > > > > > > 'i2d' never throws exceptions and this knowledge is hardcoded in
> > > > > HLO. On the
> > > > > > > > other hand this HIR opcode is translated into LIR vm-helper
> > > call, so
> > > > > instead
> > > > > > > > of simple Java opcode it becomes a
> > > > > > > > call. I can hardcode which vm-helper call is interruptable and
> > > which
> > > > > is
> > > > > > > > not on the
> > > > > > > > JIT side, but think retrieving this information from VM is a
> > > better
> > > > > solution.
> > > > > > > > Another example of uninterruptable vm-helper is
> > > > > > > > TLS accessor. This helper is placed into the middle of the
> > > inlined
> > > > > > > > 'alloc' helper body because 'alloc' reqires TLS access.
> > > > > > > > Now managed<->unmanaged convertion checker in GCMap pass has
> > > > > hardcoded
> > > > > > > > knowledge that TLS access will never be suspended.
> > > > > > > >
> > > > > > > > JET compiler uses different code then OPT and maintains special
> > > > > > > > GC-bitmasks for object operands runtime.
> > > > > > > > The per-call gc-mask maintainance is not free and can also be
> > > > > > > > optimized if VM provides a method to describe which call is real
> > > > > > > > suspension point and which is not.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > + Suspension and exception throwing are different attributes.
> > > SOE
> > > > > can be
> > > > > > > > thrown even if method is not a suspension point. So JIT must
> > > prepare
> > > > > stack
> > > > > > > > info for every call it generates to be able to unwind the
> > > frame.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Mikhail Fursov
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > http://xiao-feng.blogspot.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Mikhail Fursov
> > > >
> > >
> >
> >
> >
> > --
> > Mikhail Fursov
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
http://xiao-feng.blogspot.com