harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Date Fri, 06 Oct 2006 18:36:04 GMT
On 10/6/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
>
> On 10/6/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > On 10/6/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > >
> > >
> > > I would like to have second variant implemented and corresponding
> > > (method3) interface removed as unused anymore. But, I'm not sure if
> > > this is possible. Thread stack enumeration  is just a part of root set
> > > enumeration process. Roots can be already reported (and moved) even
> > > before the jitrino enumeration starts. Will the second variant work
> > > despite of this?
> >
> >
> > Why do you think it will not work?
> > Here is the algorithm
> > JIT reports 2 types of items: 1) bases 2) mptrs + offsets
> >  1)  Once JIT report base GC uses the same algorithm as before: it moves
> the
> > object and for subsequent reports of the same base it uses 'forwarding
> > pointer' as you mentioned before:
> > " if the second reference points  to previous position of object it will
> be
> > automatically updated  according to installed forwarding pointer."
> >
> > 2) When JIT reports mptr + offset, GC deduce the old object location,
> and
> > uses the same 'forwarding pointer' to adjust the mptr
> >
> > What is wrong with this schema?
>
> If it is possible to get somehow valid offset within object then it is
> great! I would be happy to see this solved this way. Waiting for your
> patch.


Good idea!  I like it!

If I understand this completely, I agree with using only one API to report
interior pointers.  That is #2 in Mikhail's email above.  It looks like:

2. VMEXPORT void vm_enumerate_root_interior_pointer(void **slot, int offset,
Boolean is_pinned);

And remove #3 which reports object base and interior pointer from the JIT/GC
interface.

#3 might have originally been put in the JIT/GC interface because the JIT
developers liked it.  I can't think of a reason why a GC would prefer this
interface over #2 above.

Mikhail,
Can you ask other JIT developers if it will hurt code optimization if we
drop #3?  Maybe its a performance hit carrying around offset instead of
interior pointer??


For, now I have attached to JIRA HARMONY-1682 the pessimistic variant
> of fix for those who may not be interested in the discussion and wants
> to have the problem fixed (workarounded?) anyhow.
> --
> Thanks,
> Ivan
>
> >
> >
> > There is one more way to make this work. Do the same as gc_v4 does:
> > > get full root set and then do the modifications to heap.
> > >
> >
> > Yes this is the most pessimistic variant we have if all other variants
> > failed
> >
> > --
> > Mikhail Fursov
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

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