You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Fursov <mi...@gmail.com> on 2007/04/11 16:32:31 UTC
[drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
All,
I think we need an additional method in JIT<->VM interface to check if a
vm-helper is GC suspension point or not.
Does anybody mind if I add it?
Please read this JIRA with detailed problem description:
http://issues.apache.org/jira/browse/HARMONY-3626
+ I would not mind if someone helps me with this task on VM side :)
--
Mikhail Fursov
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Xiao-Feng Li <xi...@gmail.com>.
Ok, I'll assign it to myself. Thanks. xiaofeng
On 4/14/07, Rana Dasgupta <rd...@gmail.com> wrote:
> The combined patch looks good and enriches the JIT/VM interface(
> thanks Mikhail ).
>
> Calling convention may be a seperate discussion, imho.
>
> Xiaofeng, Could you please commit this when you have some time?
>
> 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.
> >
> > 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][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Rana Dasgupta <rd...@gmail.com>.
The combined patch looks good and enriches the JIT/VM interface(
thanks Mikhail ).
Calling convention may be a seperate discussion, imho.
Xiaofeng, Could you please commit this when you have some time?
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.
>
> 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
>
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Mikhail Fursov <mi...@gmail.com>.
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.
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
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Alexey Varlamov <al...@gmail.com>.
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
>
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by 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.
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
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Rana Dasgupta <rd...@gmail.com>.
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
>
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Xiao-Feng Li <xi...@gmail.com>.
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
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Rana Dasgupta <rd...@gmail.com>.
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
>
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Mikhail Fursov <mi...@gmail.com>.
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
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Rana Dasgupta <rd...@gmail.com>.
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.
Thanks,
Rana
> >
> > On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > > All,
> > > I think we need an additional method in JIT<->VM interface to check if a
> > > vm-helper is GC suspension point or not.
> > > Does anybody mind if I add it?
> > >
> > > Please read this JIRA with detailed problem description:
> > > http://issues.apache.org/jira/browse/HARMONY-3626
> > >
> > > + I would not mind if someone helps me with this task on VM side :)
> > >
> > >
> > > --
> > > Mikhail Fursov
> > >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Xiao-Feng Li <xi...@gmail.com>.
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.
Thanks,
xiaofeng
> Thanks,
> Rana
>
> On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> > All,
> > I think we need an additional method in JIT<->VM interface to check if a
> > vm-helper is GC suspension point or not.
> > Does anybody mind if I add it?
> >
> > Please read this JIRA with detailed problem description:
> > http://issues.apache.org/jira/browse/HARMONY-3626
> >
> > + I would not mind if someone helps me with this task on VM side :)
> >
> >
> > --
> > Mikhail Fursov
> >
>
--
http://xiao-feng.blogspot.com
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Rana Dasgupta <rd...@gmail.com>.
A silly question possibly. But other than inlined fastpaths, why not
gcm treat all helper calls as interruptible?
Thanks,
Rana
On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> All,
> I think we need an additional method in JIT<->VM interface to check if a
> vm-helper is GC suspension point or not.
> Does anybody mind if I add it?
>
> Please read this JIRA with detailed problem description:
> http://issues.apache.org/jira/browse/HARMONY-3626
>
> + I would not mind if someone helps me with this task on VM side :)
>
>
> --
> Mikhail Fursov
>
Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Posted by Xiao-Feng Li <xi...@gmail.com>.
Mikhail, good point. If I understand it correctly, this is actually
the known "uninterruptible" semantic in Java-written JVM like
JikesRVM. Seems like it's time for DRLVM to consider this issue as
well...
Thanks,
xiaofeng
On 4/11/07, Mikhail Fursov <mi...@gmail.com> wrote:
> All,
> I think we need an additional method in JIT<->VM interface to check if a
> vm-helper is GC suspension point or not.
> Does anybody mind if I add it?
>
> Please read this JIRA with detailed problem description:
> http://issues.apache.org/jira/browse/HARMONY-3626
>
> + I would not mind if someone helps me with this task on VM side :)
>
>
> --
> Mikhail Fursov
>
--
http://xiao-feng.blogspot.com