[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory behavior to expect with gjdoc-0.7.6

From: Robert Lougher
Subject: Re: memory behavior to expect with gjdoc-0.7.6
Date: Mon, 5 Dec 2005 19:20:47 +0000


On 12/5/05, Robert Lougher <address@hidden> wrote:
> Hi,
> On 12/5/05, Mark Wielaard <address@hidden> wrote:

> > 2) JamVM has fragmented its heap so much that it cannot allocate such a
> >   block of data even though there is enough space in total:
> >   <GC: Largest block is 2087448 total free is 778822576 out of
> >    943718392 (82%)>
> >
> >   Or am I reading the output incorrectly?
> >
> This is what I was afraid of.  JamVM doesn't use handles so compaction
> is a non-trivial exercise.  However, I'd like to analyse the gc output
> myself, but I don't seem to have been sent it...

If I remember correctly, gcc/gij uses the Boehm GC?  This doesn't do
compaction either, but it does maintain different size free-lists,
enabling it to use an approximate best fit algorithm.  JamVMs
allocator uses a next-fit allocation strategy -- the rationale here is
to try and keep objects created together in time close together in the
heap, as objects tend to die together as well (and locality of
reference means it may exhibit better cache behaviour).  However, it's
obviously performing appallingly here.  I'll have a look at changing
the allocation strategy and see if it improves things.



> > Cheers,
> >
> > Mark

reply via email to

[Prev in Thread] Current Thread [Next in Thread]