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

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

Thread Previous | Thread Next
Buddha Buck
February 12, 2001 08:37
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Message ID:
At 01:45 PM 02-12-2001 -0300, Branden wrote:
>I think having both copying-GC and refcounting-GC is a good idea. I may be
>saying a stupid thing, since I'm not a GC expert, but I think objects that
>rely on having their destructors called the soonest possible for resource
>cleanup could use a refcount-GC, while other objects that don't need that
>could use a copy-GC. I really don't know if this is really feasible, it's
>only an idea now. I also note that objects that are associated to resources
>aren't typically the ones that get shared much in Perl, so using refcount
>for them wouldn't be very expensive...
>Am I too wrong here?

It's... complicated...

Here's an example of where things could go wrong:

sub foo {
         my $destroyme1 = new SomeClass;
         my $destroyme2 = new SomeClass;
         my @processme1;
         my @processme2;
         push @processme1, $destroyme1;
         push @processme2; $destroyme2;
         return \@processme2;

At the end of &foo(), $destroyme1 and $processme1 are dead, but $destroyme2 
is alive.

If $destroyme1 and $destroyme2 are ref-counted, but @processme1 and 
@processme2 are not, then at the end of &foo(), both objects will have 
ref-counts of 1 ($destroyme1 because of the ref from @processme1, which is 
a spurious ref-count; $destroyme2 because of the ref from @processme2, 
which is valid).  $destroyme1 won't be destroyed until @processme1 is 
finalized, presumably by the GC, which could take a long time.

That ref-count from @processme1 is necessary because if @processme1 escapes 
scope (like @processme2 did) then $destroyme1 is still alive, and can't be 

Going with full ref-counts solves the problem, because when @proccessme1 
goes out of scope, it's ref-count drops to 0, and it gets finalized 
immediately, thus dropping $destroyme1 to 0, and it gets finalized.  But 
with @processme2, its refcount drops from 2 to 1, so it survives and so 
does $destroyme2.

Full ref-counting has a potentially large overhead for values that don't 
require finalization, which is likely the majority of our data.

Going with partial ref-counts solves the simple case when the object is 
only referred to by objects with ref-counts, but could allow some objects' 
finalization to be delayed until the GC kicks in.

Going with no ref-counts doesn't have the overhead of full refcounting, but 
unless some other mechanism (as yet undescribed) helps, finalization on all 
objects could be delayed until GC.

>- Branden

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