Garbage Collection and Memory Management

We built Larceny in part so that we would have a modern, easily modifiable system that allows us to research garbage collection algorithms and implementation. From early on, the memory management subsystem has been largely decoupled from the rest of the run-time system, allowing us to "plug in" various garbage collectors without altering the rest of the system. Starting with version 0.26, there is a garbage collector framework in place that allows us to write new collectors with more ease than in previous versions.

This page describes the garbage collector framework, the existing collectors, and some possibilities the new framework gives us. Finally, the write barrier is described.

Garbage Collector Framework

Overview

The garbage collector is an object that manages some number of heap objects, each consisting of one or more generations. At present, heaps are totally ordered with heap number 0 being the young heap. The young heap may only contain a single generation. The heaps that are not the young heap are known as old heaps. There may optionally be a static heap, which holds objects that are not garbage collected -- typically, code and data from the heap image.

All storage allocation takes place in the youngest generation (which is in the youngest heap), and the youngest heap also maintains the run-time stack. Objects are allocated in an older generation only when promoted into this generation from a younger generation.

Write barriers are imposed on some of the generations in the old heaps, and for each of these generations the collector maintains a remembered set of objects in that generation that may contain pointers to objects in younger generations. The write barrier itself is outside the scope of the memory manager, but there is a two-way interface that allow the two to interact. This interface will be discussed below.

The collector framework maintains an arena of memory in an operating-system independent manner, and heaps allocate and free memory by interacting with the framework arena manager.

The garbage collectors are allowed to depend on the following aspects of the run-time system definition:

Young heaps

Old heaps

Stop-and-copy heap

Design notes

Static heaps

Pointers

Functional interface

Remembered Sets

The Arena Manager

Existing Garbage Collectors

Future Uses of the Framework

The Write Barrier

(This may deserve a note of itself.)


$Id: noteX-gc.html 87 1998-11-25 14:38:41Z lth $ larceny@ccs.neu.edu