harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@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 02:46:41 GMT
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

Mime
View raw message