Object retention problem with javac

[Nick Reeves <Ni...@gtl.com>]

I noticed the memory usage of my Ant tasks was growing large so I ran Ant
with the Heap analysis tool and got the follow results.

Top Instance Counts of classes

28074 instances of class java.lang.String 
27532 instances of class [C 
24360 instances of class java.util.Hashtable$Entry 
15961 instances of class sun.tools.java.Identifier <--
3588 instances of class sun.tools.java.ClassType 
2904 instances of class sun.tools.java.MethodType 
2769 instances of class [Lsun.tools.java.Type; 
1044 instances of class java.lang.Class 
366 instances of class [Ljava.lang.Class; 
324 instances of class java.util.SimpleTimeZone 
253 instances of class java.util.HashMap$Entry 
250 instances of class [B 
239 instances of class [S 
171 instances of class java.lang.reflect.Method 
138 instances of class [Ljava.util.Hashtable$Entry; 
135 instances of class java.util.jar.Attributes$Name 
128 instances of class java.util.Hashtable 
...

Example root path to a sun.tools.java.Identifier

Static reference from sun.tools.java.Identifier.hash (from class
sun.tools.java.Identifier) :
--> java.util.Hashtable@0x18a59c05 (32 bytes) (field table:)
--> Instance of [Ljava.util.Hashtable$Entry;@0x088a1409 (192124 bytes)
(Element 28105 of Instance of [Ljava.util.Hashtable$Entry;:)
--> java.util.Hashtable$Entry@0xe8e1fd08 (16 bytes) (field value:)
--> sun.tools.java.Identifier@0x88e1fd08 (16 bytes) 


I deduce from this that sun.tools.java.Identifier has a static Hashtable
field called hash which maps identifier names as Strings to Identifier
objects, probably for interning.

The problem with this is that since javac runs in the same JVM it holds onto
4 objects (Hashtable entry, Identifier, String, char array) for every unique
Java language identifer ever seen since the build started.

Solution proposed: run calls to javac inside their own ClassLoader

Comments ?

Re: Object retention problem with javac

[Stefan Bodewig <bo...@apache.org>]

Nick Reeves <Ni...@gtl.com> wrote:

> Solution proposed: run calls to javac inside their own ClassLoader

I'm not sure this would work and not cause a load of classloader
problems (ClassCastExceptions you usually get for classes loaded via
different loaders) but sure worth a try.

A start would be to modify one of the Javac?? classes in the
.../taskdefs/compilers directory to load the compiler class via an
AntClassLoader instance. Could you give it a try and report back to
us?

Stefan

RE: Object retention problem with javac

[Joshua Davis <js...@bellatlantic.net>]

> -----Original Message-----
> From: Nick Reeves [mailto:Nick.Reeves@gtl.com]
> Sent: Friday, January 19, 2001 4:43 AM
> To: 'ant-dev@jakarta.apache.org'
> Subject: Object retention problem with javac
>
> I noticed the memory usage of my Ant tasks was growing large so I ran Ant
> with the Heap analysis tool and got the follow results.
> ... snip ...
>
> The problem with this is that since javac runs in the same JVM it
> holds onto
> 4 objects (Hashtable entry, Identifier, String, char array) for
> every unique
> Java language identifer ever seen since the build started.
>
> Solution proposed: run calls to javac inside their own ClassLoader
>
> Comments ?
>

Just a thought: A potential quick fix could be to run javac in it's on JVM.
Something like a 'fork' attribute on the <java> task.

Josh Davis
jsd2000@bellatlantic.net