[gclist] What wrong with the GC in xemacs

[Jim Blandy]

GNU Emacs uses a simple mark/sweep algorithm.  It does segregate
strings according to size, and compact all strings deemed "small".
Stallman says he wrote the lisp interpreter over a weekend; although
he did add the bytecode interpreter, it seems he never went back to
improve the GC much.  I've heard Emacs called "Our Lady of Perpetual
Garbage Collection."

Emacs's GC is not a conservative algorithm; it uses a linked list to
track pointers from the C stack into the lisp heap.  This is a pretty
serious bug source.  The programmer must remember to invoke the macros
that maintain the list properly; forgetting to protect a variable or
unwind the list before returning from a function results in
hard-to-find intermittent bugs.  Emacs's handling of this situation is
worse than it needs to be, but I still think it's a beautiful case
study of why conservative collection is valuable when the compiler
doesn't support GC.

In the long term, the FSF plans to replace Emacs's lisp interpreter
with the scheme intepreter SCM, and then use a translator to run Emacs
Lisp.  This means that changes made to the current GC are probably
wasted; one would be better off improving SCM.  SCM uses a
conservative GC, so at least the maintenance problems mentioned above
will go away.

I think GNU Emacs would benefit greatly from the increased locality of
reference possible with generational copying GC's, but it seems to me
that copying GC's are incompatible with conservative collection
techniques; since you can't be sure you're looking at a pointer, you
can't change it to point to the object's new location, so you'd better
not move the object at all.  Is this correct?