This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



On Sat, 14 Jan 2006, David Daney wrote:

> Martin Egholm Nielsen wrote:
> >
> > 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.
>
> > 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.
>
> David Daney
>
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.  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.

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.

Hans


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]