Re: a question on the overhead of Boehm-gc

By default, on most platforms the GC uses 4K allocation blocks. For
small objects the blocks are subdivided into equal sized objects. For
objects larger than 4K the GC needs to find multiple contiguous 4K
blocks. This can often be difficult (external fragmentation problem)
and cause heap expansion. Also, the remainder of the last 4K block is
wasted (internal fragmentation problem), as you've seen.

Writing any non-moving memory allocater (whether GC or malloc style)
is always an imperfect tradeoff between internal and external
fragmentation. http://en.wikipedia.org/wiki/Fragmentation_(computing)
may be helpful.

If your application really needs to allocate so many objects with this
strange 5KB size that overhead is an issue then I'd suggest that you:

1) recompile the GC with a 1 KB block size by defining HBLKSIZE=1024
in your cflags

2) if these large objects will be garbage collected, and other objects
the same size allocated later, then ensure that GC_use_entire_heap is
set to false, so that the contiguous groups of blocks are less likely
to be split up for use by smaller objects. (This is the default in
recent versions of the GC)

But the better strategy, in my opinion, is to structure your
application so that you either use data structures that don't require
such large contiguous allocations, or at the very least keep them in
multiples of the 4K block size and then use the entire contents.

Objects of two or three times the page size won't usually cause
serious external fragmentation problems, but transient megabyte-size
objects are definitely nasty, whether you're using standard
malloc/free or the GC.

On Wed, Feb 5, 2014 at 7:57 AM, Bostjan Vilfan <[email protected]> wrote:
> Hello,
> I'm planning to use Boehm-gc in a project, and I have done some preliminary
> testing in the course of which I stumbled on a question that I don't know
> how to answer. I wonder if I can get some comments.
>
> Attached is a small C program that simply allocates memory in chunks of 5000
> bytes, and after each 10 such allocations the used memory is printed out
> (heap size - free bytes). When used memory decreases, indicating garbage
> collection, that fact is noted. Now the question. According to the previous
> description each printout corresponds to an increase of used memory by 50000
> bytes; however, the actual printout indicates an increase by more than 80000
> bytes (the program was tested on Debian 7). This seems like a lot of
> overhead. Could someone, please, explain.
> Regards,
> bv
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> _______________________________________________
> Gc mailing list
> Gc-V9/[email protected]
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/