[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: GC order
- From: RLake@...
- Date: Thu, 8 May 2003 11:40:16 -0500
Alex Bilyk escribió:
> 1. Lua objects are collected in the order exactly reverse to the order of
their creation.
That strikes me as being unreasonably rigid; it would severely restrict
options for efficient garbage collection. In particular, implementing Lua
on top of a system which already features garbage collection may not be
possible, or at least it may not be possible to take advantage of native
garbage collection.
In any case, I cannot think of a good reason for this requirement. I
suspect that what you actually want is for userdata finalisation to be
called in the reverse order to creation; that is documented as current Lua
behaviour. Since you cannot put __gc methods on Lua objects other than
userdata, the order of destruction of non-userdata objects is irrelevant.
> 2. In weak tables with both keys and values being weak a key gets
collected
> prior to its value or in reverse but always the same way regardless of
their object types.
This requirement is unclear. What if an object is both a key and a value of
different weak tables (or even the same weak table)? What if this
requirement contradicts requirement 1? Which takes priority?
Again, I suspect you are looking for something different: the requirement
is likely to be that the key is deleted from the table before the value (or
vice versa), and when that happens with respect to running finalisers. It
is clear that every object must be deleted from every weak table prior to
the object actually being reaped, but it may or may not be deleted prior to
being finalised.
-----
Finalisers are controversial in every garbage collection system; there are
too many implementation options and the precise choice taken can affect
program behaviour in very subtle ways. My rule of thumb is that if a
finaliser depends on such implementation decisions, the program design
needs to be looked at again three times.
Objects with finalisers are in a sort of limbo after being collected; they
still exist but they are in heaven's antechamber, as it were. The finaliser
runs in a sort of grey world filled with phantoms; it has access to objects
not visible to the naked eye. In this curious world, objects can disappear
without notice; but they can also be resurrected and given a new lease of
life. I think that what you are looking for is to put a bit of order in
this murky reality, but one must always take care when moving through the
netherworld.
In any event, the current Lua implementation appears to be the following:
1) unmarked weak values are deleted from both weak-value and weak-key-value
tables.
2) finalisers are run on deletable userdata with finalisers (i.e. __gc
metamethods) in reverse creation order.
3) all weak tables have all deletable nodes removed. (i.e. <key,value>
pairs where either the key or the value is nil, or the key or value is weak
and unmarked.)
4) all deletable objects are actually deallocated. (Note: an object which
was finalised at step 2 is not deletable at this point. It will be
deletable on the next GC cycle if it was not resurrected. This is also true
of the strong partner of a weak member of a weak-table node; this latter
fact can create memory leaks.)
I believe that any order for steps (1), (2), and (3) could have been
chosen; the only difference it makes is the number of phantoms available to
finalisers. I don't suppose that it would be problematic for the Lua
specification to choose and document one particular order, but it hasn't.
For what it's worth, I think I would have chosen order (2), (1;3), which
seems to be slightly more predictable, and possibly more useful than (1;3),
(2). (steps 1 and 3 can be done simultaneously if step 2 doesn't
intervene.) But as I said, relying on this particular behaviour is likely
to end in tears.
I would also have thought that, since only userdata can have finalisers,
that an API lua_setfinaliser(L, <userdata>) would be easier for both Lua
and Lua-integrators alike, and more efficient as well. Perhaps that could
be considered for Lua 5.1
Rici