[Gc] GC_malloc bug?

Boehm, Hans hans.boehm at hp.com
Tue Dec 7 12:24:11 PST 2004


The log does look strange to me.

"Wasted" bytes are somehow allocated from the heap, but not
constructively used.  They are included as allocated bytes for
decisions about whether to expand the heap or trigger another
collection.

You are correct to be suspicious of the large values.  They look
wrong.  I think there are only two possible sources:

- The extra part of large blocks, which is required to make the
size a multiple of a page size.  I don't think this can be the
issue here, since it can be at most equal to the number of allocated
bytes, which is always zero after a while.

- Blocks which are effectively allocated and dropped because they are
known to be "referenced" by false pointers.  I don't quite understand
how this can get so large without intervening successful allocations.

As always, a small test case would be great.  Alternatively, it would be
useful to also define GC_DUMP_REGULARLY (the environment variable).  This
will generate much more voluminous output, which might be enlightening.

My guess is that part of the problem is that you have many "black-listed"
blocks, i.e. blocks referenced by known false pointers.  The GC_DUMP_REGULARLY
output should confirm that.  If that is the case, the ultimate cause
may be a large data structure containing essentially random (compressed?)
data.  If you can allocate that with GC_MALLOC_ATOMIC, odds are good
that that will work around the problem

Are you using a larger GC_free_space_divisor?  A non-default GC_max_retries?

Hans


More information about the Gc mailing list