RE: Lua gc in games

["Josh Jensen" <joshj@...>]

> From: Reuben Thomas [mailto:rrt@dcs.gla.ac.uk] 
> > > ...or Lua could use a generational garbage collector...
> >
> > Do you have one laying around we could just plug in?
> >
> > Seriously though, you make it sound so simple. I believe the work 
> > required from the Lua point of view is about the same given the 
> > incremental or generational solution. Both must still know whenever 
> > references change.
> >
> > I guess a generation GC works similarly to the const data idea of 
> > mine, but the GC must be smart enough (and have the 
> cooperation of the 
> > VM) to figure out when something in the const data changes and must 
> > then be walked during the next GC. Perhaps there is a 
> simple way to do 
> > this that I am not aware of?
> 
> The idea is more that you only collect the "young" generation 
> most of the time (a "minor" collection), and then collect the 
> "old" generation when you're really running out of heap (a 
> "major" collection).
> 
> Hopefully, things work out so that in a game you can wait to 
> do a major collection until you have the time to walk the 
> entire heap, and the "young" generation quickly empties, so 
> that only transient data structures are held there.

This would be a good answer to Amped's garbage collection problems.
Before my most recent Lua optimization pass, small tables were getting
created and destroyed each frame.  They weren't getting garbage
collected, though, so memory usage increased quickly.  I have since
broken the tables out into global form, so they are created only once,
but I would like to not have to make hacks like that.

My small local tables would easily fit into the "young" generation
pattern.  The "old" generation, all the data they reference, rarely
changes.

Thanks,
Joshua Jensen
Amped: Freestyle Snowboarding 
http://www.xbox.com/Games/sports/amped.htm