At 03:14 PM 12/6/00 -0500, Sam Tregar wrote:
>On Wed, 6 Dec 2000, Dan Sugalski wrote:
>
> > What I'm thinking is that we'll have a scoped destruct stack that gets
> > pointers to variables that explicitly need destruction, and as we exit
> > levels of scope we call the destructors of those variables that need it.
> > (They can still be GC'd later to pick up their now-free memory) Most things
> > won't get tossed on there, since most variables don't have any destruction
> > behaviour.
>
>If you don't reference count how do you protect yourself from DESTROYing
>objects that are still referenced:
>
> my $new_dog;
> {
> my $dog = new Dog;
> $new_dog = \$dog;
> }
That would hoist the Dog reference into an outer level of scope--in this
case the one containing $new_dog. Or so my thinking goes at the moment,
though there may be (almost inevitably are) problems with that.
>Did $dog just get erroneously collected by your destruct stack? No?
>Without reference counting?
>
>Frankly these hybrid GC schemes look more like the *worst* of both worlds
>than best - all the predictable performance problems of reference counting
>with the unpredictable performance problems of mark and sweep!
Modern GC schemes are better than what you're probably thinking of with
naive mark and sweep. Generational garbage collection can take care of a
lot of that, as can some partitioning techniques. There's evidence in the
literature that switching from reference counting to a more sophisticated
GC scheme can also save us 5-10% in CPU overhead. (Though that's not a
guarantee--LISPlike languages likely have different GC performance
characteristics than perl does)
Object destruction, FWIW, is a separate problem from garbage collection,
and the two only have to mildly overlap. The only reason they do so much in
perl 5 is the destruction scheme piggy-backs on the GC scheme.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
