Re: a question on the overhead of Boehm-gc

Thanks a lot for your exhaustive explanation. I repeated the test  with
more "normal" values of chunk size (60), and indeed found that there was
practically no overhead. I think that for the time being I won't be needing
any adjustments of GC parameters since my application is entirely
conventional (a compiler); my test was made simply to get a feeling for
Boehm-gc.
Regards,
Bostjan Vilfan


On Tue, Feb 4, 2014 at 10:31 PM, Bruce Hoult <[email protected]> wrote:

> 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/
>

_______________________________________________
Gc mailing list
Gc-V9/[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/