First of all, thanks for your reply.
Regarding the "scanvenge_phase":
Your explanation confirmed an idea that I already had but could'n confirm
by looking at the code. In other words, the "scavenge_phase" corresponds
to the second phase of Cheney's algorithms: the scanning of the grey nodes
in "tospace" after the copy of the roots. [Jones96, Ch 6]. Once again,
thanks.
Regarding the "Relocation fix-up":
The explanation in the book is very clear and I thought I understood it.
It was only after seeing the code that I was confused because
the "copy_object_simple" "seems" to fix-up the references already. Forgive
me for making this email a little lenghtier by pasting the code: see my
comment "REFERENCE UPDATE ???"
---- BEGIN CODE ----
void
gc_heap::copy_object_simple (BYTE** po)
{
BYTE* o = *po;
if (gc_mark1 (o))
{
if (!pinned (o))
{
//allocate space for it
BYTE* no = allocate_in_older_generation (size (o));
dprintf (3, ("Copying %p to %p", o, no));
//copy it
memcopy (no - plug_skew, o - plug_skew, Align(size
(o)));
//forward
(header(o))->SetRelocation(no);
*po = no; // <- REFERENCE UPDATE ???
}
else
{
dprintf (3, ("%p Pinned", o));
}
}
else
{
*po = header(o)->GetRelocated (); // <-REFERENCE UPDATE ???
dprintf (3, ("%p Already copied to %p", o, *po));
}
}
---- END CODE ----
I'm sure that I'm making a mistake somewhere, but I can see where. An help
would be welcomed.
Thanks
P. Felix
References
[Jones96] Jones and Lins, "Garbage Collection", Wiley, 1996
-----Original Message-----
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of David Stutz
Sent: ter�a-feira, 17 de Junho de 2003 19:46
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] rotor GC
copy_object_simple copies the object and sets a forwarding pointer. To
avoid leaving dangling refs, you must make a scan after all copying is
done and fix-up any references that still point to old locations. The scan
that does fix-up occurs after all objects have been moved, using
get_copied_object rather than copy_object_simple. In the book, the section
entitled "Relocation Fix-up" gives a brief account of this - sorry it
wasn't more clearly explained.
With regards to question #2, I certainly agree that the scavenging code is
very convoluted. Remember that in gen1, a first fit algorithm is used for
allocation. While objects are being promoted into gen1 freespace in the
copy phase, space that is allocated is remembered by threading a "scavenge
list" together, stashing the next pointer directly in the object's memory.
(This is what thread_scavenge_list is doing, which is called from
allocate_in_older_generation, which in turn is called from
copy_object_simple.) scavenge_phase goes through this list once all of the
top-level objects have been copied, clearing marked and pinned bits and
calling copy_object_simple for any object references that are contained
inside the already copied objects. Of course, this results in more calls
on allocate_in_older_generation, which causes more references to be
stashed in the scavenge list...you get the idea... To make matters worse,
once the entire set of refs has been scavenged, a new scavenge list can be
created by the checks on the finalization queue and the handle table.
-- David
