Re: [javax_compiler] Re: sun.tools.javac.Main will be removed from JDK1.4

[Neal M Gafter <Ne...@sun.com>]

> > 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.

FW: [javax_compiler] Re: sun.tools.javac.Main will be removed from JDK1.4

["Pier P. Fumagalli" <pi...@betaversion.org>]

FYI 

    Pier

------ Forwarded Message
From: Neal M Gafter <Ne...@sun.com>
Reply-To: javax_compiler@yahoogroups.com
Date: Fri, 20 Jul 2001 20:46:51 -0700
To: javax_compiler@yahoogroups.com
Cc: ant-dev@jakarta.apache.org
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:
javax_compiler-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


------ End of Forwarded Message