[gclist] memory leaks and the Boehm collector
Thu, 15 Jul 1999 13:33:38 -0700
Al Demers pointed out an easier way to build a memory reachability tracing
In the debugging allocator, reserve space for one one extra pointer in the
header. When the collector first marks such an object, write a pointer to the
referencing object in that field. You can then determine the reason for the
retention by following these back pointers.
This looks trivial to add to the collector. It will only work if the debugging
allocation primitives are used, but I assume that's possible in this and most
cases. It avoids some of the sticky problems with determining this in a
separate pass, since you don't have the issues of the stack of the tracer
perturbing the results, etc.
I propose to add this to the 5.0 alpha collector in the next few days. Perhaps
Fergus or someone else can volunteer to generate some code for displaying the
data, or to hook it upt to an exisitng tool (e.g. the one from IBM?) I've been
meaning to do this for a long time, but haven't found the cycles.
It doesn't follow that this problem is related to conservative GC. Though that
is a distinct possibility, based on what I've heard, I'd give better than even
odds that it is either:
1) An infinitely growing data structure in the client, e.g. a cache that never
discards any entries, or
2) A bug in the collector.
My impression was that the same phenomenon occurred with the JDK 1.1 collector:
Its conservativism was often blamed for leaks, but I have yet to see a single
case in which a leak was traced to the conservativism of the collector,
although I have heard of complaints about about 1.1 memory use. Does anybody
know of such cases? (I do hear about lots of the complaints about SGIs
versions of the JDK, so this observation is based on a reasonable sample.)
Indeed, if you believe the argument in
http://reality.sgi.com/boehm/bounds.html, scanning the stack conservatively can
cause a growing leak only in pretty clearly defined cases.