Re: Heap fragmentation (Was: Debugging "Leaks" With Boehm-GC)

[Martin Egholm Nielsen <martin at egholm-nielsen dot dk>]

Hi Hans,

> > > Just stumpled across this old thread - seems that I'm beginning to run
> > > into fragmentation problems - bot being able to allocate memory for some
> > > things.
> > > I have set GC_MAXIMUM_HEAP_SIZE to 14000000 (14mb), but I wonder where I
> > > can configure GC_free_space_divisor? In "alloc.c" it seems - but there
> > > it's set to 3, whereas "gc.h" says it's initially 4?!
> > We set GC_free_space_divisor before calling JvRunMain.  I don't know
> > what happens if you call it after the runtime is already started.
> That should be OK.  It should control future GC/heap expansion decisions.
Good to know!

> > > Moreover, is 20 a super value? Or is this trial-and-error?
> > Trial and error.
> >
> > The larger the divisor, the more time spent in GC, but the less likely
> > you are to end up in the pathological situation where there is plenty of
> > free memory, but it is all in pools for objects of a size other than you
> > are trying to allocate.
> >
> > I think the default value is probably appropiate for cases where there
> > is no upper bound on memory size.  For bounded memory size, we have
> > found that a larger divisor is needed.
> If the issue here is really fragentation, it would be nice to understand it
> better.  A call to GC_dump() or setting the GC_DUMP_REGULARLY environment
> variable should tell you what's in the heap.  

No, do you recall:
http://gcc.gnu.org/ml/java/2005-12/msg00083.html
setting GC_DUMP_REGULARLY doesn't affect anything - what should happen?

> Really fragmentation per
> se can only occur if either:
>
> 1) The application drastically changes the object size mix it needs for
> different phases, and some other things go wrong.  And even then, things
> shouldn't get too bad.  Or
>
> 2) The problem occurs due to frequent allocation of large objects.
By "large" I guess mean some that takes "relatively" much of the free 
memory?

I'm doing many ~20kb - and suddenly a ~200-400kb

> On the other hand, there is a known problem with large root sizes causing
> the collector to grow the heap to better amortize the GC overhead.

// Martin