[gclist] conservative stack scanning in Emacs

[Bryan O'Sullivan]

d> Emacs does appear to fail to reclaim space for some reason that
d> needs investigating, but it's an old effect, unrelated to the GCPRO
d> mechanism, and possibly not related to GC.

I haven't looked at this in years, but here's my recollection of what
used to happen circa 1992.  Emacs has a relocating buffer allocator;
when a buffer is killed, it is shuffled to the end of the heap, and
brk() is used to return its memory to the OS.

The Lisp heap, however, is not shrunk in this way, so the combination
of maximum heap size and the set of long-lived buffers (if you use
Emacs for email and Usenet, for example) determines the overall size
of the process.

	<b