Re: Re[2]: state of the Lua nation on resource cleanup

[Mark Hamburg <mark@...>]

You can't just reference count some of the items, however, and have  
rapid (a.k.a. deterministic) destruction. If a traced rather than  
reference counted object refers to a reference counted object, then  
the reference counted object won't go away until the traced object does.

Reference counting could speed destruction in some cases, but not all  
of them. If rapid destruction really matters -- and recycling memory  
faster might make it appealing even for conventional objects -- I've  
speculated about whether there's a design that distinguishes between  
items referenced only from the stack and items with global references.  
Reference counting stack references is generally pretty expensive, so  
instead I've been thinking about associating pools of objects with  
particular stack levels. Passing an object as a parameter doesn't need  
to do anything. Returning it as a result moves its lifetime up to the  
next level on the stack. A further variant could distinguish between  
young objects referenced only from the stack and other young objects  
and old objects that don't meet this criterion. Storing a pointer  
could then force marking a large structure as old instead of young,  
but this would probably be rare and isn't particularly worse than the  
atomic destruction of large structures that some reference counting  
schemes lead to.

But all of this will only get one faster recycling of some memory and  
other resources and it isn't clear what the runtime cost to support it  
would be.

I think the current policy that says essentially, "if you know the  
lifetime of the resource usage, then close it explicitly and have the  
resource throw errors if you use it after closure; if you don't know  
the lifetime, then live with GC" is a reasonable compromise. It is  
interesting to look at ways to make the explicit close path easier to  
write and implement, but that's not essential.

Mark