The Garbage Must Go!

An important architecural issue in XEmacs is the garbage collector (GC). Here are some references on GC in general:

Much of XEmacs is written in C, a language that does not support GC by default. Nevertheless, the data allocated in the C part of XEmacs must also be subject to GC. The reasons why this is difficult to do for C are twofold:

GC needs access to all heap objects currently accessible from the running program (the live objects). C does not provide this information.
GC needs information about the layout of heap objects at run time. C does not provide run-time layout information.

There are two basic approaches for solving this problem:

The current, precise, approach: All objects on the heap are member of a special datatype which provides layout information. Furthermore, the C code contains hand-written annotations telling the GC which variables are live at any given time.
An alternative is conservative GC which makes two simplifying assumptions:
1. The set of live variables is a subset of all variables on the C stack and in the machine registers at any given time.
2. The set of all locations within a heap object are a superset of the locations pointing to other heap objects.
On the basis of this imprecise information, GC can work quite safely, but deals a superset of the live objects. Thus, it is easier to use than precise GC but also may retain unreachable garbage.

Here's an archive of a discussion on this on the GC mailing list.

Michael Sperber [Mr. Preprocessor]

Last modified: Mon Jun 30 17:31:57 MST 2003