Re: Thinking about Lua memory management

[David Jones <djones@...>]

In message <Pine.SOL.4.33.0109191331460.21027-100000@smartius.cs.uiuc.edu>, Rob
erto Ierusalimschy writes:
> Currently we are considering a change in the garbage collection algorithm
> of Lua. But we do not want to slow down the interpreter, so the two schemes
> discussed here (reference count and incremental collectors) do not seem very
> atractive to us.
> 
> Instead, we are thinking about a generational collector, with a
> write-barrier on tables. With a generational collector, we may be able to
> have much shorter stops for most collecting cicles, and this savings may
> compensate the overhead for the write barrier. So, maybe we could get not
> only shorter gc cicles, but also an overall performance improvement.

A generational GC sounds very sensible.  I have a few questions, mostly
out of idle curiosity.

Have you read, Wilson excellent survey paper "Uniprocessor Garbage
Collection Techniques"?  (online at 
ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps
)

Are you planning to move objects?

How are you going to represent generations?

I assume you are using a write barrier to implement "remembered sets" -
pointers from objects in old generations to objects in younger
generations?  How are you planning on representing your remembered sets?

If you set things up right then now would be a good time to separate out
pointerless objects from pointerfull objects.  As I understand it, only
tables have pointers, and the only other sort of object that is
allocated on the heap is an interned string.  Perhaps you already don't
scan strings during GC...

djones