[svn:parrot] r41507 - in branches/remove-next_for_GC: docs/dev src

[darbelo at svn.parrot.org]

Author: darbelo
Date: Sun Sep 27 01:53:39 2009
New Revision: 41507
URL: https://trac.parrot.org/parrot/changeset/41507

Log:
Remove reference to next_for_GC from the docs.

Modified:
   branches/remove-next_for_GC/docs/dev/pmc_freeze.pod
   branches/remove-next_for_GC/src/pmc_freeze.c

Modified: branches/remove-next_for_GC/docs/dev/pmc_freeze.pod
==============================================================================
--- branches/remove-next_for_GC/docs/dev/pmc_freeze.pod	Sun Sep 27 00:47:57 2009	(r41506)
+++ branches/remove-next_for_GC/docs/dev/pmc_freeze.pod	Sun Sep 27 01:53:39 2009	(r41507)
@@ -82,27 +82,10 @@
 to the desired functionality. It gets passed on to all vtable methods and
 callback functions.
 
-=head2 Working loops
-
-These are labeled B<visit_loop_*>. There are currently two schemes to handle
-the B<todo_list>.
+=head2 Working loop
 
 =over 4
 
-=item next_for_GC
-
-All PMCs that can contain other PMCs have the B<next_for_GC> pointer in the
-PMC's extended data area. The B<todo_list> gets built by appending (or        
-prepending) the current PMC to a B<mark_ptr>, which then points to the current
-PMC, forming a linked list of items.
-
-This pointer is also used during GC's B<mark()> functionality, so that
-GC has to be turned off during operations using this scheme.
-
-As the B<next_for_GC> pointer is inside the PMC, this scheme isn't thread-safe
-at low-level, because shared PMCs also would share this pointer, so that there
-can be only one operation at a time.
-
 =item todo list
 
 A B<List> called B<todo> holds items still to be worked on. This method is
@@ -151,41 +134,6 @@
 overhead, 32-bit system assumed). Hash lookups also take a considerable
 amount of time.
 
-=item B<next_for_GC>
-
-The pointer used for the B<todo_list> handling itself can serve as a marker
-that this item was already processed. There are some issues with this though:
-Plain scalars (not being able to contain other PMCs) don't have a
-B<next_for_GC> pointer. This is an optimization reducing the size of scalars
-and increasing performance considerably.
-
-Second, the B<next_for_GC> pointers have to be cleared beforehand. GC uses
-only a nibble-sized flag area located inside the PMCs arena to manage, if a PMC
-was seen already by checking the live bit. The B<next_for_GC> pointer is just
-set and never cleared to avoid touching a PMCs memory and polluting caches when
-possible.
-
-Finally, generating a PMC's B<id> isn't as simple as just incrementing a
-counter used with the B<seen> hash approach.
-
-=item PMC B<id>s
-
-We could of course use the PMC's address as its own B<id>, since we know it is
-unique. However, this is suboptimal for thawing.  To manage duplicates during
-B<thaw> we basically need a mapping B<PMC_in_image =E<gt>
-newly_constructed_PMC>. When now the B<PMC_in_image> (the B<id>) is the
-address, we have to use a hash again, for B<thaw()> with all the negative
-impact on resources and speed.
-
-So both schemes are using small B<id> values and the seen handling inside
-B<thaw> is done via a list lookup, which is a lot faster and takes less
-resources.
-
-The B<seen> hash approach just has a counter for PMC B<id>s, the B<next_for_GC>
-approach calculates the B<id> from the address of the PMC in its arena, again
-yielding a small and unique number. The two low bits of PMC B<id>s are used as
-flags.
-
 =back
 
 =head2 The actual action

Modified: branches/remove-next_for_GC/src/pmc_freeze.c
==============================================================================
--- branches/remove-next_for_GC/src/pmc_freeze.c	Sun Sep 27 00:47:57 2009	(r41506)
+++ branches/remove-next_for_GC/src/pmc_freeze.c	Sun Sep 27 01:53:39 2009	(r41507)
@@ -8,11 +8,6 @@
 
 =head1 DESCRIPTION
 
-Freeze uses the C<next_for_GC pointer()> to remember seen PMCs. PMCs are
-written as IDs (or tags), which are calculated from their arena address.
-This PMC number is multiplied by four. The 2 low bits indicate a seen
-PMC or a PMC of the same type as the previous one respectively.
-
 Thawing PMCs uses a list with (maximum) size of the amount of PMCs to
 keep track of retrieved PMCs.