FYI Pier ------ Forwarded Message From: Neal M Gafter <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Fri, 20 Jul 2001 20:46:51 -0700 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [javax_compiler] Re: sun.tools.javac.Main will be removed from JDK1.4 > > Craig R. McClanahan wrote: > > > An additional note of interest to Ant developers - there is evidence that > > > running the compiler (either old or new) leaves a fair amount of cruft > > > lying around in static variables, after the compile has completed. The > > > recommended solution is to load the compiler itself in its own class > > > loader, so that you can throw it all away afterwards. That's the approach > > > we'll take when modifying Jasper. I was part of the source for this rumor, but I'd like to comment. There was a bug in the internal version of javac for the past month or two in which the compiler failed to clean up after itself. I fixed that today. The symbol tables, trees, etc are definitely cleaned up now. If you're a source licensee getting weekly releases of Merlin (1.4) your most recent versions will definitely have this bug. It may be a couple of weeks before this fix gets back to you. There are two categories of things that are NOT cleaned up between compiles: (1) Objects that are essentially constants, like symbol table entries for the root package, built-in types, etc. While its true that these stick around, its better that they do because javac runs faster the second time. These are fixed size. (2) Names in the name table. javac maintains its own version of an interned string table, and all the names that it sees are entered into it and remain in it forever. The representation was custom designed for the compiler and it's much more compact than strings. This table does appear to approach an asymptotic limit when you use the compiler repeatedly; when all of JDK (1.2) was compiled using javac this table reaches a maximum of about 500K. I have to admit a likely third category - bugs in the compiler. But if you find any, tell me and I'll fix it. In short, I don't think it's necessary to load the compiler into its own class loader in most circumstances, but you're welcome to try it either way you please. If you try it both ways and can share some data on the relative performance (space and time) I'd love to hear from you. I plan to try an experiment replacing the name table with actual interned String objects. That will probably slow things down a bit and use more space, but it has the advantage that otherwise unreachable interned strings are reclaimed, so this would remove a "leak" from the compiler. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------ End of Forwarded Message