develooper Front page | perl.perl6.internals | Postings from February 2001

Please shoot down this GC idea...

Thread Next
Buddha Buck
February 14, 2001 08:03
Please shoot down this GC idea...
Message ID:
Why won't this work:

As I see it, we can't guarantee that DESTROYable objects will be DESTROYed 
immediately when they become garbage without a full ref-counting scheme.  A 
full ref-counting scheme is potentially expensive.

Even full ref-counting schemes can't guarantee proper and timely 
destruction in the face of circular data structures, which ref-counting 
schemes leak.

Partial ref-counting is very difficult to get right, and is likely to be 
even more expensive than full ref-counts.

I haven't seen another possible problem with DESTROY-by-GC brought 
up:  non-refcounting GCs can be fast because they don't have to look at the 
garbage, only the non-garbage.  If we want it to DESTROY garbage that needs 
to be DESTROYed, they will have to look at the garbage to find the 
DESTROYable garbage -- which negates the advantage of just looking at 

So, here's an idea:

1. Maintain a list of DESTROYable objects.  This list is automagically 
maintained by bless and DESTROY.

2. If the compiler can determine that an object is DESTROYable and garbage, 
the compiler can automatically insert a call to DESTROY at the appropriate 


{ $fh = new Destroyable; $fh->methodcalls(); }

could be transformed to:

{ $fh = new Destroyable; $fh->methodcalls(); $fh->DESTROY(); }

This step may not be always possible -- can the compiler determine that 
$fh->methodcalls doesn't do anything to keep $fh alive?  If not, it can't 
do this step.

3. After finding live objects, the GC would walk the DESTROYed list looking 
for objects not found alive.  If/when it finds them, it DESTROYs them.  It 
needs to do this before it rewrites over the reclaimed space, so that the 
data necessary for the DESTROY is still available.

I feel that the number of objects that need to be DESTROYed will likely be 
small compared to the total number of Perl objects, so the DESTROYables 
list will be relatively small and fast to walk.  The automagically 
detecting of when an object can be DESTROYed (if possible) should also help 
in keeping the DESTROYables list short.

I'm sure this idea has flaws.  But it's an idea.  Tell me what I'm missing.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About