Generational Garbage Collection for Lazy Functional Languages without Temporary Space Leaks

Generational garbage collection is an established method for creating eecient garbage collectors. Even a simple implementation where all nodes that survive one garbage collection are tenured, i.e., moved to an old generation, works well in strict languages. In a lazy language, however, such an implementation can create severe temporary space leaks. The temporary space leaks appear in programs that traverse large lazily built data structures, e.g., a lazy list representing a large le, where only a small part is needed at any time. A simple generational garbage collector can not reclaim the memory, used by the lazily built list, at minor collections. The reason is that at least one of the nodes in the list belongs to the old generation, after the rst minor collection, and will hold on to the rest of the nodes in the list until the next major collection takes place. To completely abandon the idea with generational garbage collection for lazy languages is however an overkill since the fundamental idea behind generational garbage collection, that the mortality of young nodes are higher than for old nodes, is valid also for lazy languages. Implementations of lazy languages create large amount of short lived nodes that represent suspended computations. A generational garbage collector concentrates on these young nodes, which have high mortality, and can therefore reclaim more memory with less work compared to a non-generational collector. This paper describes a generational garbage collector that avoids many of the temporary space leaks introduced by a simple generational collector. The main diierences between this generational collector and other generational collectors are; that no test is needed before updating nodes, and the way ageing of nodes are handled. The latter makes it very easy to have diierent tenure policy for nodes with diierent types. The former makes it possible to change between non-generational and generational garbage collection at runtime. This is an advantage as the choice of garbage collector often depends on the amount of memory available when runing the program. The garbage collector is implemented for the Chalmers LML/Haskell compiler, and is compared with the original two-space copying garbage collector and a simple generational garbage collector that tenures all nodes that survive one collection.