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][vm] New method in VM-JIT interface (was: [drlvm][jit]...)
Date Tue, 17 Apr 2007 12:06:33 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message