[svn:ponie] rev 307 - trunk

Author: nicholas
Date: Fri Jul  1 08:34:12 2005
New Revision: 307

Modified:
   trunk/   (props changed)
   trunk/Roadmap
Log:
 r25980@ship-in-a-bottle:  nick | 2005-07-01 16:30:45 +0100
 Update the Roadmap with the new task (finding hidden cross references)


Modified: trunk/Roadmap
==============================================================================
--- trunk/Roadmap	(original)
+++ trunk/Roadmap	Fri Jul  1 08:34:12 2005
@@ -333,38 +333,73 @@ This involves
 
 =item 1
 
+Chase down all the places in the perl core that hold pointers to referenced
+counted objects but don't hold a reference. We need to know where these are so
+that they can either become part of the GC marking code, or so that they can
+hold an "external" reference which the GC is aware of.
+
+So far I'm aware of
+
+=over 4
+
+=item *
+
+C<CvSTASH>, C<CvGV>
+
+=item *
+
+C<GvEGV>
+
+=item *
+
+GV pointers in the optree.
+
+=item *
+
+There's a comment in F<sv.c> about fake dirp (rsfps).
+
+=back
+
+The comments in C<sv_dup> and the associated ithreads cloning routines in
+F<sv.c> are the best clues as to what needs to be done.
+
+10 days. (Partially done - chased down the reference loop between symbol tables
+and typeglobs)
+
+=item 2
+
 Making Parrot's GC walk the Perl 5 C stack.
 
 1 day
 
-=item 2
+=item 3
 
 Registering PMCs held in Perl globals.
 
 2 days
 
-=item 3
+=item 4
 
 Amending the reference, array and hash code to properly mark the contained
 PMCs as "in use".
 
 2 days
 
-=item 4
+=item 5
 
 Replacing C<SvREFCNT_inc()> and C<SvREFCNT_dec()> macros with null
 operations inside the core. (Unaware XS code would still use them)
 
 5 minutes
 
-=item 5
+=item 6
 
 Experimenting to find out how much of the special case code for the Perl stack
 and C<@_> can be removed.
 
 3 days
 
-=item 6
+=item 7
 
 Calling a high priority DOD run at every freetmps point. (Roughly every
 semicolon)
@@ -427,7 +462,7 @@ To be useful this task depends on the re
 
 =back
 
-65 days, plus 3 if Pads need migrating.
+75 days, plus 3 if Pads need migrating.
 
 =head3 Migrating complexity from Ops to PMCs
 
@@ -686,9 +721,9 @@ If this process averages out at 2 hours 
 
 =head2 Release!
 
-The estimate is that this takes 261 days. This is a lot.
+The estimate is now that this takes 271 days. This is a lot.
 
-About 50 days of the first 60 can't be parallelised easily. Later work is
+About 50 days of the first 70 can't be parallelised easily. Later work is
 more parallelisable, less dependent, shorter, and far more suitable for
 others to work on.