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:28:25 GMT
I forgot to say: check lazy1.zip file in original lazy resolution JIRA. The
tests were only in the first patch

On Jan 26, 2008 8:21 PM, Mikhail Fursov <mike.fursov@gmail.com> wrote:

> 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
> http://issues.apache.org/jira/browse/HARMONY-3940
>
> 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




-- 
Mikhail Fursov

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