[svn:ponie] r388 - trunk
[email protected] 31 Jan 2006 21:14:31 -0000
| Newsgroups | perl.ponie.changes |
|---|---|
| Message-ID | <[email protected]> |
Author: nicholas Date: Tue Jan 31 13:14:30 2006 New Revision: 388 Modified: trunk/Roadmap Log: Revise timing estimates on the basis of experience, particularly with the reference counting task. Modified: trunk/Roadmap ============================================================================== --- trunk/Roadmap (original) +++ trunk/Roadmap Tue Jan 31 13:14:30 2006 @@ -249,14 +249,14 @@ via a function call, it is possible to m point assume set flags (NOK,pNOK) and morph the scalar to a larger type if any code requests the flags value read/write. -4 days +5 days =item * Replace the complex SV copying code in C<sv_setsv> with copying code encapsulated within the PMC. -5 days +6 days =item * @@ -282,7 +282,7 @@ iCow. (mostly done in blead, partially m Make read only look ups such as C<SvNV()> call the appropriate PMC method. -2 days +3 days =item * @@ -293,10 +293,12 @@ and C<SvNV>, and internals-aware direct C<SvNVX>. The former expect magic to be called for them, the latter expect direct access and will handle magic themselves. -4 days +5 days =item * +aMake a code distinction between readonly and read-write accesses to strings (2 days) + Refactor the core to use a new C<SvPVX_readonly()> macro when requesting a pointer to a scalar's string that isn't going to be modified. Consider whether this also shouldn't return a C<'\0'> terminated string, or whether @@ -329,6 +331,10 @@ Refactor the Perl core code to avoid usi think that this is possible, and Dave suspects that there may be speed benefits from removing all the special case code that deals with the stack. +This change is risky, but Arthur and I believe it's the only way to get +destruction right when Ponie's aggregate PMCs are passed out to unsuspecting +Parrot code. + This involves =over 4 @@ -365,14 +371,14 @@ There's a comment in F<sv.c> about fake 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 +12 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 +2 days =item 3 @@ -385,35 +391,32 @@ Registering PMCs held in Perl globals. Amending the reference, array and hash code to properly mark the contained PMCs as "in use". -2 days +3 days =item 5 Replacing C<SvREFCNT_inc()> and C<SvREFCNT_dec()> macros with null -operations inside the core. (Unaware XS code would still use them) +operations inside the core. (Unaware XS code would still use them - time is +needed for actually testing that this boundary works) -5 minutes +1 day =item 6 Experimenting to find out how much of the special case code for the Perl stack and C<@_> can be removed. -3 days +4 days =item 7 Calling a high priority DOD run at every freetmps point. (Roughly every semicolon) -2 days +3 days =back -This change is risky, but we suspect it's the only way to get destruction -right when Ponie's aggregate PMCs are passed out to unsuspecting Parrot -code. - =item * Refactor stashes to be a derived type of hashes. This means that Perl's hashes