[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: Mark Wielaard
Subject: Re: memory behavior to expect with gjdoc-0.7.6
Date: Wed, 07 Dec 2005 02:06:31 +0100

[Sorry for the duplicate message, trouble with my primary email account]


On Mon, 2005-12-05 at 18:52 +0100, Mark Wielaard wrote:
> 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 :)

It gives us a hint (thanks for review help from Sven on irc) that we are
pushing huge Strings through the encoders. In particular gjdoc creates a
full String for each XHTMLified/pretty-printed/color-coded/etc source
file in Although all the rest of the generated pages
are "streamed" to disk the actual source code formating is done in one

  String result = java2xhtml.makeHTML(sourceBuffer.getBuffer(),

Which is then written to disk in one go. For the larger source files
this can be pretty big. So a quick workaround for now would be to not
include the -linksource flag to gjdoc.

If someone wants a nice hacking task then they could look into making
java2xhtml take a Reader to read the source from and a HtmlPage to
output to instead of creating one huge String.



reply via email to

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