[gclist] memory leaks & Boehm collector

[Ole Agesen - SunLabs]

> My application is using the Boehm (et al) collector.
> Unfortunately, it is leaking memory :-(
>  ...
> One possible possible problem is that Mercury uses its own stacks
> rather than using the C stack, and currently the collector does not
> zero them out, so there may be old references lying around.
> To avoid this, I added code to the outer loop to zero the Mercury stacks
> and then explicitly invoke GC_gcollect() to force a garbage collection.
> But I'm afraid that didn't help.

In a paper that I co-authored with Detlefs and Moss (PLDI98), a similar 
situation was described anecdotally. It is nice to have the scenario be 
confirmed as one that GC implementers need to worry about, but it is NOT 
nice to hear that it is giving you problems, of course. The solution that 
was applied in the case we reported on, I believe, was to "shred" the
data structures. So if you have a tree, for example, you would walk the
tree and NULL out all the pointers in the tree. This makes it difficult
for a small set of ambiguous roots to keep a large amount of data live.

> Any suggestions about how to go about debugging something like this?
> 
> I seem to recall Hans mentioning something about how it would be nice
> to have a tracing tool that would take an arbitrary address and, if the
> address was live, would give you back a trace showing the chain of
> pointers from one of elements of the root set to that address.  Did
> anyone ever get around to writing such a tool?

In ExactVM (JDK1.2 Production Release for Solaris), I implemented something
like this. It was not an arbitrary address you would start from but
rather an object in the heap. The tool will determine why that object
is live (i.e., why it is reachable from a root). In ExactVM we don't
have conservative GC, so the kinds of memory leaks that the tools is
used to locate are bugs in the Java code. We have a few cases where 
people have located memory leaks in very large programs composed out of
multiple independently developed libraries. With the tool, it has been
possible to find memory leaks in a very short time (like an afternoon),
so it is quite efffective.

Ole