harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Date Fri, 06 Oct 2006 15:41:55 GMT
On 10/6/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> 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.

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?

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.

-- 
Ivan
Intel Middleware Products Division

---------------------------------------------------------------------
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


Mime
View raw message