[Gc] How to quickly diagnosis heap fragmentation

Boehm, Hans hans.boehm at hp.com
Fri Oct 12 16:21:45 PDT 2007


It's usually much easier to look at GC_dump() output.

But looking at the full output, I don't much like _large_allocd_bytes
and _max_large_allocd_bytes.  Certainly the former, and probably the
latter should be less than the heap size.  It looks like it is regularly
failing to get decremented.  Looking at the code, I think there is a
bug, in that GC_free does not adjust this value when deallocating a
large block.  It no doubt should.  Are you explicitly deallocating a lot
of large (> 1 page) blocks?

Unfortunately, I'm very short on time at the moment.  But can you try
the attached, hurriedly generated, patch?  This ws generated for 7.0,
and hence may need tweaking.

If this works, but doesn't solve the underlying problem, please post
GC_dump output.

Thanks.

Hans 

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Alec Orr
> Sent: Friday, October 12, 2007 1:46 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] How to quickly diagnosis heap fragmentation
> 
> Good day all,
> 
> We use GC 6.8. pthread support.
> Built on Redhat Linux release 9 (Shrike) Running on Red Hat 
> Enterprise Linux ES release 4 (Nahant Update 5)
> 
> We have an application with a rather large heap that grows 
> over time when certain multithreaded operations (which make 
> use of GC allocated objects) execute.  My current contention 
> is the large heap is due to heap fragmentation over time due 
> to the following values acertained from the GC_arrays:
> 
> #0  0x00137d4e in ?? ()
> (gdb) print GC_arrays._heapsize
> $1 = 493109248
> (gdb) print GC_arrays._large_free_bytes
> $2 = 435576832
> 
> Attached is the entire GC_arrays structure from gdb.  
> Hopefully I have isolated the relevant 2 variables.  I am 
> concerned that the free bytes and heapsize are so close.
> 
> Thanks for any input,
> Alec
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloc.c.diff
Type: application/octet-stream
Size: 913 bytes
Desc: malloc.c.diff
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20071012/df8bd8f4/malloc.c.obj


More information about the Gc mailing list