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 16:21:12 GMT
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?


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

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