harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Date Tue, 17 Apr 2007 16:28:42 GMT
I may have misunderstood the intent of this thread.

The jit needs to know which helpers are uninterruptible for several
reasons, and it is convenient for it to ask the VM in one place rather
than hardcode. So the interface change on both sides is good and
commitable ( if tests pass etc. )

However, there is still some triage needed on which helper is
uninterruptible and which is not and why. Is that going to happen over
time and the interface method will be updated?

Thanks,
Rana


On 4/17/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> Thanks, I will check it today.
>
> On 4/17/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> >
> > 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
> >
> >
>
>
> --
> Mikhail Fursov
>

Mime
View raw message