harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Date Tue, 17 Apr 2007 11:12:01 GMT
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 <mike.fursov@gmail.com> wrote:
>> Let's commit it.
>>
>> On 4/17/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> >
>> > On 4/14/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> > > On 4/13/07, Mikhail Fursov <mike.fursov@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 <alexey.v.varlamov@gmail.com> wrote:
>> > > > >
>> > > > > 2007/4/13, Mikhail Fursov <mike.fursov@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 <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
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Mikhail Fursov
>> > > >
>> > >
>> > >
>> > > --
>> > > http://xiao-feng.blogspot.com
>> > >
>> >
>> >
>> > --
>> > http://xiao-feng.blogspot.com
>> >
>>
>>
>>
>> -- 
>> Mikhail Fursov
>>
> 
> 


-- 
Gregory


Mime
View raw message