[gclist] conservative gc

Eliot Moss moss@rhea.cs.umass.edu
Fri, 16 Jan 1998 13:55:32 -0500 (EST)

I'm responding to Michael Sperber's request for accounts comparing
conservative and other techniques. I do not have precisely the kind of
information he is indicating (though I expect we may be gathering it in the
future to round out an existing paper submitted for conference publication). I
described all this a little while ago on this same list, so I'll be brief on
this occasion.

Ole Agesen and Dave detlefs of Sun Microsystems Laboratories, along with me,
added a live variable analysis to an accurate Java collector. We found that
eliminating the tracing the live variables reduced average heap size
(time/space product, geometric average of the ratio of with and without the
analysis) by about 8%. That, of itself, may not be terribly exciting. There
are two points that I think are more interesting:
  1) EVERY program showed SOME improvement.
  2) SOME programs showed DRAMATIC improvement.
In connection with this, I observe that conservative techniques will NEVER
ignore dead variables. We also found that one cannot always get rid of the
problem by setting a variable to nil after its last use, at least for Java. If
the last use is as an argument to a call, there is no way to "slip in" the
assignment of nil between passing the variable as an argument and making the

Our actual paper is STILL not authorized for general distribution, but
apparently because we were not "careful enough" to use the magic J word in
exactly the corporate approved ways. As soon as we get clear guidance on that
and clearance from Sun on the paper, we'll make the draft more widely
available. For now, I am restricted to general discussion of the contents

My personal reaction is that if there is already investment in an accurate gc
infrastructure, then I am inclined to maintain and use it, precisely because
emacs is so widely used and its space consumption and lack of leaks are
important properties. I sympathize with the debugging problem, but it might be
possible to build a tool to help with that. For example, something that would
compare a conservative scanners root set with the accurate scanners root set
to generate candidates for inclusion in an accurate scan. Obviously such a
tool cannot be PERFECT, but it might reduce the labor required to find and fix
such problems, and would make testing for them easier prior to release ....

Regards --							Eliot Moss
J. Eliot B. Moss, Associate Professor      http://www.cs.umass.edu/~moss   www
Computer Science Department, LGRC          +1-413-545-4206               voice
University of Massachusetts, Box 34610     +1-413-545-1249                 fax
Amherst MA  01003-4610  USA                moss@cs.umass.edu             email