On 10/6/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 10/6/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > On 10/6/06, Ivan Volosyuk <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
