RE: Garbage collection

["Nick Trout" <ntrout@...>]

> Andrew Brownsword:
> The main issue is that the PS2 is a fairly low clock rate by 
> today's standards, and it has a small L1 cache, no L2 cache, 
> and the memory is high latency RamBus memory.  Walking many 
> data structures is therefore a rather expensive operation, 
> and this is my single greatest point of concern about using 
> Lua on this platform.  

Perhaps someone will write VU-Lua! Still wont fix your GC cache woes
though. The generational GC will help as the walks won't be so long.
>From what I've read a very high percentage of the objects that get
deleted are newer ones, so if you minimise object creation your code and
call the GC regularly perhaps this will deal with this issue.

> What are the 
> caveats to the reference counting scheme David mentioned?

Cyclic referencing could cause some objects never to be deleted if they
become isolated. Mark and sweep avoids this problem. Python is reference
counted and has to have a separate library to find cyclic references.

It slightly complicates object management from the C side because you
have to manage the reference count to Lua objects when you want to
reference them. There is potential for error here if don't reference and
unreference them correctly. You may be able to hide all of this in the
Lua API though, instead of handling the reference counts directly as you
do in Python. The Boost library has features to hide this functionality
for Python.


If I understand the problem, a danger with the generational method is
that objects will jump write barrier after a certain age and eventually
the older objects will need to be sweeped. This will lead to the same
problem that we have now ie. The GC taking too long. I wonder if Lua had
an explicit object release/destroy function if this would removed the
necessity for the "older sweep". eg.

obj = {}
destroy(obj) -- this sets obj to nil and frees the table object
associated with it.

There is a danger here that this will leave dangling pointers/references
from other objects so perhaps to compliment this you could have a
reference count method which counts the number of references to an
object. Eg.

obj = {}
-- count the number of references to the object referenced by obj
-- which will include obj itself.
assert( refcount(obj)==1 ) 
destroy(obj)

There may be many circumstances where you have objects which you know
you can delete and don't need the GC to pick these up. Obviously if you
let the GC handle everything then there is less chance of error, this is
an optimisation, which is optional. The benefit is the GC could be
called less often and in conjunction with a generation GC may provide
efficient GC without the need for a complicated incremental system
(which would scan everything and may be less efficient, but
distributed).

Regards,
Nick