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] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Date Fri, 06 Oct 2006 12:30:51 GMT
Ivan,
I'm agree that the problem we have is more complicated then my example. And
I'm glad to hear that there are no problem with the scenario from my example
today.

Jitrino.OPT uses  3 interface methods to report GC root set:

1. VMEXPORT void vm_enumerate_root_reference(Managed_Object_Handle *ref,
Boolean is_pinned);
2. VMEXPORT void vm_enumerate_root_interior_pointer(void **slot, int offset,
Boolean is_pinned);
3. VMEXPORT void vm_enumerate_root_interior_pointer_with_base(void
**slot_root, void **slot_base, Boolean is_pinned);

The method 1 is used for bases
The method 2 is used for mptrs with offset known at compilation time
The method 3 is used for mptrs with dynamic offset that is computed only in
runtime

In our case JIT reports the pair: new_base and old_mptr.
JIT does not report offset here. So if you could process this situation with
'forwarding' pointer we have the half of the problem solved.

The other half of the problem is finding a base for the mptr with unknown
offset.
The current implementation in JIT looks for a base right before reporting
the mptr: it selects the nearest one. So if base pointer was updated by GC
the search will produce incorrect results.

I see the following solutions in our problem
1) Fix in GC and JIT: GC is learned how to deal with mptrs reported with
outdated base + fix in JIT in base searching algorithm (here we have a lot
of variants)
2) Fix in JIT only: precache all offsets and then report. In this case JIT
will always use only method1 and method2.

I vote for the item 2 and can provide a fix in a day.
But in this case I propose to remove the method3 from GC-JIT interface at
all, as deprecated.


On 10/6/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
>
> This is not the same. In your example, if the second reference points
> to previous position of object it will be automatically updated
> according to installed forwarding pointer.
>
> We have different problem. The reported offset within object is
> incorrect, as the base is taken from new location of object, but
> interior pointer points to old object location.
>
> Here is algorithm.
> before GC:
> *interior_pointer == base + offset
> after GC:
> *interior_pointer_updated == new_base + offset
>
> Reported offset should be: offset = *interior_pointer - base;
> But we have: offset' = *interior_pointer - new_base;
>
> After GC interior_pointer should be updated:
>   *interior_pointer_updated = new_base + offset
> But in our case it will be:
> *interiour_pointer_updated' = new_base + offset' = new_base +
> *interior_pointer - new_base = *interior_pointer
>
> So, interior_pointer will not be updated.
> --
> Ivan
>
> On 10/6/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > Ivan,
> > the problem is described in the example in H1682, I can add it to the
> email
> > thread to invite other GC/JIT gurus to participate in the discussion.
> >
> > The example:
> > JIT has 2 references to report. Both of them point to the same object.
> JIT
> > expects that both references are updated when GC moves object.
> > 1) JIT reports reference 1
> > 2) GC moves object and updates reference 1.
> > 3) JIT reports reference 2, but the reference points to the old place
> where
> > the object was.
> >
> > This is almost the same situation we have today.
> >
> >
> >
> >
> > On 10/6/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > >
> > > Why don't we update roots just when it was reported? Thus we don't
> need to
> > > keep large array of roots and it can also have positive influence on
> > > d-cache utilization (need to proof this).
> > >
> >
> > --
> > 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
>
>


-- 
Mikhail Fursov

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