[gclist] Experience with conservative GC sought

Carl Bruggeman bruggema@ranger.uta.edu
Tue, 20 Jan 1998 10:43:49 -0600

> Both the Emacs and XEmacs development team have long-term plans to
> replace their Lisp engines.  One of the big design issues is whether
> to commit to conservative GC.  The present C substrates of these two
> editors presently use precise GC annotations which are a constant
> source of annoying bugs.  However, the present Emacsen have very small
> leakage which typically allows one invocation to stay up for weeks or
> even months.  Losing this property would be very undesirable.

If I were the on the development team, it would not be difficult 
to decide whether I want to spend more time now debugging a precise
collector where I have control over all aspects of the problem or
whether I want to spend much more time later trying to provide a way
to tweak that 1 in 1,000 heap that I have no control over (times a
million+ users) that leaks so bad you have to restart every hour... 
How will the documentation read for the section on restarting emacs
due to data-dependent space leaks?  "Try changing your text in ways
that do not really matter." "Usually just exiting the system and
restarting will change things enough that the problem will not
re-occur (at least in the same way)".

Has any imprecise collector been used in a production system
(10,000+ daily users today) that has as high an allocation rate
as emacs? 

Has anyone tried and given up?

Has anyone considered it for production systems and decided not to for
the type of reasons I suggested above?

Without this type information, you have no way of knowing whether you
are headed from the frying pan into the fire.

Note: I do not object to imprecise collectors in research and prototype
systems where their tradeoffs are reasonable, but production systems
have completely different economics.


Carl Bruggeman -- bruggema@cse.uta.edu -- Phone: (817) 272-3600 Fax: 272-3784
Computer Science and Engineering Department -- University of Texas at Arlington