At 03:54 PM 12-06-2000 -0500, Sam Tregar wrote:
>On Wed, 6 Dec 2000, Dan Sugalski wrote:
>
> > Non-refcounting GC schemes are more expensive when they collect, but less
> > expensive otherwise, and it apparently is a win for the non-refcount
> > schemes.
>
>Which is why GC is intimately tied to DESTROY consideration in terms of
>Perl. If we intend to honor predictable DESTROY timing, and I think we
>should, then we will need to reference count. No ifs, elses or
>alternations. Anyone care to refute?
This is not a complete refutation, but...
It seems to me that there are three types of thingies[1] we are concerned
about, conceptually:
A) Thingies with no DESTROY considerations, which don't need refcounts.
B) Thingies with DESTROY methods, but aren't timing-sensitive. They can be
destroyed anytime after they die. These don't really need refcounts either.
C) Thingies with DESTROY methods which need to be DESTROYed as soon as they
die. These would seem to need refcounts.
I think that distinguishing between B and C is a syntax issue out of scope
here. Although B could be lumped with A if we could tell B and C apart,
I'll assume that we must lump B and C together.
If we could refcount only C for destruction, and let the GC-of-your-choice
handle the actuall memory reclaimation, then the expense of refcounting
should only affect C thingies. I am uncertain what the ratio of C thingies
to A thingies is, so I can't judge how big a win it is.
Theoretically, a non-refcount GC should never find any C thingies that
would have a refcount>0, so the non-refcount GC shouldn't have to worry
about it.
>If we're going to be ref-counting anyway then the performance gain of a
>non-refcounting GC, avoiding counting, is basically moot. If we're
>ref-counting for DESTROY timing then we may as well use that data in the
>GC.
But we only care about the ref-count for DESTROY timing. If we can avoid
counting for DESTROY timing insensitive thingies, we may still have a net
performance gain.
>I'm not some kind of ref-count true-believer - if you think we should put
>this discussion of to a later date then I'm cool. I'm just spoiling for
>some Perl 6 work to do and this area seemed ripe for critical development.
>
>-sam
