Re: memory behavior to expect with gjdoc-0.7.6

[Mark Wielaard]

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

Hi,

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 HtmlDoclet.java. Although all the rest of the generated pages
are "streamed" to disk the actual source code formating is done in one
go:

  String result = java2xhtml.makeHTML(sourceBuffer.getBuffer(),
                                      sourceFile.getName());

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.

Cheers,

Mark