harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][jit] New method in VM-JIT interface: check if vm helper is GC suspension point
Date Fri, 13 Apr 2007 05:26:48 GMT
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 <rdasgupt@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 <xiaofeng.li@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 <rdasgupt@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 <mike.fursov@gmail.com> wrote:
> > > > On 4/12/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> > > > >
> > > > > On 4/11/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > > > > On 4/12/07, Rana Dasgupta <rdasgupt@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message