[gclist] controlling heapsize in BDW collector

[Michael Hicks]

Hi all.

I wonder if anyone can provide some input on how to correctly set the
heapsize for the BDW collector.  I'm trying to do some performance
comparisons between GC and non-GC'ed apps, and in particular I want to
examine the tradeoff between memory footprint and latency in a GC'ed
setting.  The idea is that the more memory you're willing to allow, the
less latency impact there will be with GC, since you'll collect less
often.  And the converse is also true.

So, I have an application that has about a 128K footprint when using
GC_malloc and GC_free, and about a 348K footprint when removing the
GC_free's so that the collector is used.  What I'd like to do is force
the heapsize to be somewhere between 128K and 348K (as close to 128K as
possible) while still using the collector, so that garbage collections
occur more often.  Then I can assess the latency impact.  However, when
I do this by calling GC_set_max_heap_size(max_heap_size), GC_malloc
returns NULL in basically every case unless I set max_heap_size to be
roughly 348K.  I also set the GC_use_entire_heap flag to be true, with
the same result.

Why would this be happening?  When using GC_free, the heap usage never
rises above 100K, so it's not that I'm allocating a lot of batched
objects and then freeing them all at once.  By the same token, I'd be
really surprised if this was some kind of fragmentation overhead (2/3 of
the heap is fragmentation!!!???).  The objects being allocated are
relatively large, ranging from 2K to 15K.  Finally, spurious retention
also seems unlikely: to be safe I NULL all of the objects that are
allocated (these are packets being forwarded by a proxy), and the
results are the same.

If this is not some kind of limitation with the collector, can anyone
suggest how I would go about debugging this behavior?  Turning off
-DSILENT has not been too helpful.  Has anyone had success setting the
maximum heapsize to something below what the collector would naturally
come to?

Thanks in advance,
Mike