[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Re: state of the Lua nation on resource cleanup
- From: Mark Hamburg <mark@...>
- Date: Sun, 31 May 2009 09:36:17 -0700
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
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.