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][jit][jet][x86_64] Lazy resolution for JET
Date Sat, 26 Jan 2008 14:21:45 GMT
On Jan 26, 2008 1:51 AM, Gregory Shimansky <gshimansky@apache.org> wrote:

> On 25 January 2008 Mikhail Fursov wrote:
> > > > Another problem here: in lazy resolution mode we need to 'vpark' all
> > > > registers for CCONV_HELPERS calls too.
> > >
> > > Hmm... I am not yet experienced with JIT well enough to understand
> this.
> > >  I have seen vpark calls in many places but I don't know what it does
> > > and why it is inserted. Could you please explain in a few words? BTW
> > > vpark is done at the beginning of the gen_invoke for the CallSig of
> the
> > > method.
> >
> > vpark(AR) moves data from AR to memory. Doing this for CCONV_MANAGED we
> > ensure that all registers that are required by calling convention to
> > perform a managed call do not contain any information. But in lazy mode
> we
> > perform not only managed method call, but also a helper call to resolve
> the
> > address of the method. So, CCONV_HELPERS registers are also must be
> freed.
> > The crash can be reproduced only when calling conventions of these
> methods
> > use different sets of registers.
> I see. I added vpark() before helper calls in the patch yesterday. I hope
> it
> was placed in the right places (this is one thing I doubt about).
> I vaguely remember that there were some tests on lazy resolution in some
> test
> suite. Could you please give me a pointer? So far I found only one bug
> when
> rth_checkcast_withresolve is called from managed code with corrupted
> object
> argument. I am working on it. But I would also like to run any other
> possible
> tests on lazy resolution before I can say that it seems to work.

check this issue: the suite is not integrated

Another good test is to make JIT work in lazy mode for all types regardless
if it's resolved or not. AFAIR the most simple way to do it today is to
return false from "class_is_cp_entry_resolved".

BTW we can make a cmd-line option to allow such a mode without
recompilation. I've found that this option could be useful to look for GC
enumeration issues, because lazy resolution helpers do always check object
for validity.

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message