## 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