Re: memory behavior to expect with gjdoc-0.7.6

[Robert Lougher]

Hi,

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.

Thanks,

Rob.

> > Cheers,
> >
> > Mark
>