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

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

Thread Previous | Thread Next
Dan Sugalski
February 14, 2001 07:38
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Message ID:
At 10:12 AM 2/14/2001 -0300, Branden wrote:
>David Mitchell wrote:
> > James Mastros <> wrote:
> > > ... do refcounting (or somthing like it) for DESTROY to get called at
>the right
> > > time if the class (or any superclass) has an AUTOLOAD, which is
> > ... the above seems to imply a discussion that you only need to do
> > ref-counting (or whatever) on objects which have a DESTROY method.
> > However, since you dont know in advance what class(es), if any, a thinngy
> > will be blessed as, you always have to ref-count (or whatever technique is
> > chosen) just to be sure:
>I agree. Mixing ref-counting and whatever won't work (or will work and will
>be worse than only ref-counting). Either we stick with ref-counting (and
>maybe add something for breaking circular references) or we forget about
>this fallacy of having DESTROY called at a predictable time.

Perl's never been able to guarantee that DESTROY would be called at a 
predictable time. Ever. Sticking with refcounts won't make that any better, 
since that's what happens now.

The question isn't "will we keep predictable object destruction" since 
generally speaking we don't have it. The question is "will it get less or 
more predictable, and at what cost".

>Afterall, why do we need DESTROY to get called at the right time? Afterall,
>Java does live without it, and if Perl is supposed to run on the JVM, we
>won't have it there anyway! I think with .NET (Microsoft's C# VM) the
>situation is the same.

*) People like it
*) Scarce external resources (files, DB handles, whatever) don't get 
unnecessarily used
*) People like it
*) Saves having to write explicit cleanup code yourself
*) People like it

>If resource exhaustion is the problem, I think we can deal with that when we
>try to allocate a resource and we get an error, then we call the GC
>explicitly (one or more times if needed) to see if we can free some
>resources with it. Resource exhaustion would be a rare situation (I think),
>and doing some expensive treatment when it happens is OK for me.

The point of DESROY isn't resource exhaustion per se, at least not anything 
the garbage collector will care about, since it only cares about memory.

>Also, I think it would be valid for the programmer to explicitly say ``I
>would like to DESTROY this object now'', and have the DESTROY method called
>in that time, even if the memory would be reclaimed only later.

So you undef your object reference. If the object doesn't go away, it means 
that something else probably still has a handle on it somewhere.

Plus there's nothing stopping you from having $obj->DESTROY in your own 
code, though it may be inadvisable.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

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