lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.