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