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:
- The data representations, which need to be
known so that the collector can manipulate and scan objects.
- The offsets of certain slots in the globals
vector, through which the collector publishes pointers into
collector-internal data structures.
- The obscure fact that code vectors are bytevectors with a header subtag
equal to 0, which allows the collector to avoid instruction-cache
flushing for other bytevectors, on architectures where instruction-cache
flushing is required.
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