[gclist] memory leaks and the Boehm collector

[Fergus Henderson]

On 14-Jul-1999, Kragen Sitaker <kragen@pobox.com> wrote:
> Since it's conservative, sometimes it thinks things are live that
> aren't, if your program computes with large numbers or byte strings.
> Depending on the way your data is linked together, this can be a minor
> problem or it can totally vitiate the collector.
> 
> In particular, if your dead objects are a dense forest of cycles, then
> even one false reference can keep huge amounts of stuff from being
> freed.  Since the non-freed stuff is fertile ground for more false
> references to spring up, this is a vicious cycle.

As it happens, my dead objects are all trees of one kind or another --
there's not a single cycle.  The language I'm programming in, Mercury,
is similar to a strict pure functional language, and although it does
provide features that let you create cycles, this program (the compiler)
does not use them.

My suspicion was that some pointers to the root of the tree were being
retained somewhere, but after changing the outer loop to explicitly clear
out the stacks (except for the part currently live, of course, but that
part should not contain any such root pointers) and the registers before
explicitly invoking the GC, and having the problem still occur, I think
that must not be the problem.  So currently I'm a bit stumped.
I guess I'll have to implement that reference-chain tracing tool...

> - the Boehm collector allows you to declare large blocks of memory as
> being pointer-free.

This program doesn't use any large blocks of memory, as it happens.
We do allocate strings and floats using GC_malloc_atomic() rather than
GC_malloc().  The remaining data structures are mostly trees, lists,
enumerations, and structures containing these.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.