Generational GC (was Re: A review of changes between 5.1 and 5.2-work3)

[Mark Hamburg <mark@...>]

On May 21, 2010, at 9:30 AM, Mike Pall wrote:

> About point 14: the experimental generational collector in Lua 5.2
> is not enabled by default. And it's non-incremental, which means
> it's less applicable to apps with a need for low-latency GC (games).

Thinking about generational GC, presumably the goal is to reduce memory consumption, correct?

I would (naively) think that one could run essentially two incremental GC's. The nursery gets collected at a rate based on allocation. The older generation gets collected at a rate based on tenuring. There is probably a need for an adolescence phase in which an object in the nursery has been marked to be tenured because it is now referenced from a tenured object but we haven't unthreaded it from the nursery object list. This would get cleaned up during the scan of the nursery along with tenuring any objects that had survived enough cycles in the nursery.

To reduce memory consumption, one then runs the old generation collector at a faster multiplier than usual so that it collects faster. But this is offset by only running it in response to objects getting tenured.

On a broader front, the places where I find myself most wanting a generational collector are for things like parameter tables for function calls and closures passed as arguments to functions. Making these cases cheaper, which may also require a suballocator, would make various programming idioms more comfortable to use from a performance standpoint.

Mark