[gclist] GC topics

[boehm.PARC@xerox.com]

"Indeed.  Alas, my job involves dealing with one of those occasions,
and I suspect that they are likely not to be so rare.  One component
of the system for which I am responsible is implemented using a
conservative collector (it's written in Scheme, hence the use of GC).
This component is a daemon which sits around, preferably for as long
as possible, and does things when prodded.  Unfortunately, it tends to
grow in size by about 6-10M every day, which means that it has to be
killed off and restarted every few days in order that it not thrash
the host on which it runs."

Would you care to be a bit more specific about the implementation, etc?  Our
experience, based on several years of moderately long running Cedar processes,
is that it is indeed rare, and very rare if you do things right.

The fact that a process is growing continuously does not mean the leak is due
to conservative pointer finding.  Garbage collectors don't make it impossible
to write programs with infinitely growing data structures.

The following also greatly affect the problem:
- How careful is the allocator about avoiding bogus pointers?   Does it avoid
allocating known bad areas of memory? Does it avoid scanning dead stack
regions?  Does it occasionally clear dead stack regions?
- Is the collector scanning essentially random bit patterns, typicaly in the
form of compressed bit maps or bignums?  This is typically very easy to avoid
by changing a couple of allocation calls, and can greatly affect performance.
- Is the application building infinitely growing data structures and gradually
dropping "the front" of the data structure?  This seems to be the major case in
which you want to explicitly clear pointers.  It seems quite rare, except for
programs written in a lazy functional style.  It's hard to get accumulating
leaks from anything else.

For details, see ftp://parcftp.xerox.com/pub/gc/papers/pldi93.ps.Z.


Hans