[gclist] What wrong with the GC in xemacs

[Erik Naggum]

|   - Emacs goes to great lengths to ensure that it can give memory back to
|     the operating system when possible.  It will even move entire buffers
|     around in memory so that it can call sbrk(-whatever).  This is a
|     cause of great performance loss, but I suspect Stallman wouldn't be
|     interested in any replacement gc that didn't do something similar.

Emacs does not return Lisp storage to the system, only buffer space, which
are allocated differently from Lisp storage.  buffers are not GC'ed -- the
buffer space is released and others possibly relocated as soon as the
buffer is killed.  (the Lisp buffer object is gc'ed.)

|   - Remember, Emacs still contains a whole lot of ugly code that supports
|     efficient redisplay for the likes of elderly Ann Arbor terminals.
|     Stallman won't be interested in a gc that isn't portable and "right"
|     for the same reason that he won't toss out the old redisplay code,
|     even though it's a dog on windowing systems.

(are you talking about Emacs 19?)  the redisplay engine depends on the
value of the `baud-rate' variable.  it should be very high for very fast
display systems, such as 16777216, but Emacs trusts the stupid terminal
interface on Unix, which has no tty speed for "memory-mapped".

I'm not so sure about Stallman's lack of interest in a new GC.  there are a
number of things in Emacs that are highly system-dependent, but it sure
would be a lot of work to revamp the internals to use a different GC.  on
the other hand, the GC protection scheme used (to make objects not move) is
inefficient and a source of some incredibly hard bugs when done wrong.

#<Erik>