Front page | perl.perl6.internals |
Postings from February 2001
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
finalized.
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