RE: GC order

["Bilyk, Alex" <ABilyk@...>]

Thanks,

As I said I didn't make any assumptions on the order in my code but was wondering if garbage collection has any other rules similar to that on the order of user data collection. Your response clearly indicates that no other rules can be assumed and/or used for making code dependant on them. The thing I wanted to do is this (still want but not as much). Given a co-routine I would like to associate a user data object with it that would get collected before the co-routine itself does. In other words, given a co-routine with no outstanding references to it I would like for some designated user data get garbage collected/finalized before the co-routine itself does. 

Alex

 -----Original Message-----
From: 	RLake@oxfam.org.uk [mailto:RLake@oxfam.org.uk] 
Sent:	Thursday, May 08, 2003 9:40 AM
To:	Multiple recipients of list
Subject:	RE: GC order


[chop-chop]
-----

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.

Totally agree.

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