Front page | perl.perl6.language |
Postings from February 2001
David Mitchell wrote: > James Mastros <james@rtweb.net> 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 expensive. > ... the above seems to imply a discussion that you only need to do expensive > 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. 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. 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. Anyway, that data flow analysis that was being proposed could well be used to `avoid' or `delay' resource exhaustion in some cases. But I don't think any guarantees should be given about when the DESTROY method of an object would be called. 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. The problem I see with this is what if a programmer calls DESTROY on an object that was being used by others. The way I suggest to deal with this is set a flag if the object was already DESTROYed. Then if any other tries to use it, it raises an exception (dies) with a message about ``This object was already DESTROYed.''. This flag could be used also to signal to the GC system that the object already got its DESTROY method called, and it shouldn't be called again. Just an idea, but... - BrandenThread Previous | Thread Next