Hi, On 12/5/05, Robert Lougher <[EMAIL PROTECTED]> wrote: > Hi, > > On 12/5/05, Mark Wielaard <[EMAIL PROTECTED]> 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 > _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
