[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 18:10:10 +0000 |
On 12/5/05, Robert Lougher <address@hidden> wrote:
> Hi,
>
> On 12/5/05, Mark Wielaard <address@hidden> wrote:
> > Hi Fred,
> >
> > On Mon, 2005-12-05 at 12:32 -0500, address@hidden wrote:
> > > > Could you also run JamVM with -verbose:gc and send me the output?
> > > >
> > > Attached.
> >
> > Thanks. This seems to point out two things:
> >
> > 1) There is a huge allocation (2MB+):
> > <GC: Alloc attempt for 2209016 bytes failed.>
> > at this point in the code:
> >
> > // REVIEW: Using max instead of average may allocate a very large
> > // buffer. Maybe we should do something more efficient?
> > int remaining = in.remaining ();
> > int n = (int) (remaining * maxBytesPerChar ());
> > ByteBuffer out = ByteBuffer.allocate (n);
> >
> > I believe that REVIEW note gives us a hint :)
> >
> > 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...
>
On second thoughts, it may have been rejected by gmail if the
attachment was too big (how big was it?). Could you try compressing
it (if it wasn't)?
Thanks,
Rob.
> Rob.
>
> > Cheers,
> >
> > Mark
>