[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 _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath