Re: ROTOR GC

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