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][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Date Tue, 17 Apr 2007 10:31:13 GMT
There is a break in Linux64 build. I will commit it after the SVN is ok.

Thanks,
xiaofeng

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
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message