Re: garbage collection (4.0.1)

["David Burgess" <db@...>]

Sincere thanks.

----- Original Message -----
From: <RLake@oxfam.org.uk>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Tuesday, July 09, 2002 1:22 AM
Subject: Re: garbage collection (4.0.1)


>
>
> > Does anyone know -
>
> > Is there a document that describes what the
> > Lua garbage collector collects?
>
> I don't know of one. However, a document is probably not necessary. It
> collects anything that it can prove is not in use.
>
> > How does it define "in use"?
>
> It is the transitive closure of "references" starting with the globals
> table, the stack, the reference table, and perhaps a few other things that
> I have forgotten. In other words, if there is a reference to an object, it
> is in use and so is everything that it references.
>
> > Is it true that unreferenced userdata that has
> > a gc method always called during a collection cycle?
>
> I don't think you can count on that. It might be *logically* unreferenced,
> but not actually garbage collectable yet (for example, it might be
> referenced by a local on the stack which will never be used again, but the
> garbage collector doesn't know that so it won't be garbage collected until
> the stack slot is reused or the stack frame is cleared by the function
> returning.)
>
> However, if there is a gc method, it will be called before the object is
> deleted.
>
> > Does lua_close call the gc method for user data
> > regardless of whether it is  referenced?
>
> Yes. lua_close systematically deletes every allocated object, calling gc
> methods if defined. However, in this case you cannot rely on the order of
> collection to guarantee that gc methods will be called in the order you
> think is logical. (The order is logical, but it might not accord with your
> idea of your data, so it is unwise to count on this.) In particular, there
> is no way to guarantee that objects will be garbage collected before
> anything they reference has been garbage collected. There is no way to do
> this because there might be circular references.
>
>
>
>