Debugging memory leak.

[Frits van Bommel]

David Brown wrote:
> On Mon, Oct 08, 2007 at 10:23:17PM -0700, David Brown wrote:
> 
>> I seem to have something else in my program that is making lots of stray
>> pointers for the GC to follow.  My program consistently leaks memory 
>> until
>> it is killed by running out of address space (or I kill it because it is
>> trying to swap my machine to death).
> 
> I think I found my problem.  I have something like this:
> 
>   class Foo {
>     ubyte[20] hash;
>     ...
>   }
> 
> and a _lot_ of these are alive at any given time.  The hash is a sha1 hash,
> and so tends to be evenly distributed.
> 
> It appears that heap objects only have a single flag indicating whether or
> not they have pointers, and since classes do have pointers, the GC will

Yeah, it's just a single bit currently. The vtable and monitor pointers 
don't count though (the first points to static memory and the second to 
malloc()ed (non-gc) memory), so class bodies only gets tagged as 
containing pointers if it has explicit pointer/reference/dyn. 
array/assoc.array members.

> look at the "pointers" in the hash to see if they hit anything.  Build up a
> reasonable set of these and something will point to almost everything.
> 
> It's going to take me a little while to change the code to not do this (it
> isn't quite as simple as my example).  I was concerned about having 20
> bytes living in its own gc allocation being wasteful, but leaking nearly
> everything is much more wasteful :-)

A precise GC (or at least something more in that direction) would really 
help in these kinds of situations...