Re: [javax_compiler] Re: sun.tools.javac.Main will be removed from JDK1.4
> > Craig R. McClanahan wrote:I was part of the source for this rumor, but I'd like to comment.
> > > 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.
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.
> -----Original Message-----I am considering what will be involved in loading javac into its own
> From: neal@... [mailto:neal@...]On Behalf Of Neal M Gafter
> 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.
classloader. For this to be effective, I believe tools.jar cannot be on the
system classpath as the classloader will just delegate to the system loader.
We can play some tricks around that, I guess, but they are a little risky.
What I would like to know is whether there is any standard for where the
compiler classes are located. Are they always in tools.jar. Also is there
some standard for where to find tools.jar. I had the impression that on some
OSs (Mac OSX?), the compiler classes are in the boot classpath. Not sure