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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Mikhail Fursov
