Community
Participate
Working Groups
If you weave (post-compile time) a large number jars within the same ant invocation (without forking) you will reliably get a "java.lang.OutOfMemoryError: PermGen space". I This was tested with Java 1.5.0_09-b01, AspectJ nightly from 10-11-2006 and 1.5.2. Test case is an ant build script that just weaves a jar (log4j.jar) and then deletes the output jar in a loop. After 31 iteration I get the OutOfMemory error. The aspect that I'm weaving is just a simple tracer aspect with a join point doesn't even match the classes in the log4.jar.
Created attachment 52072 [details] zip file that contains scripts to reproduce Contains a zip file with an ant build script that will continually weave a jar and cause an OutOfMemory error. See contained readme.txt for other instructions.
Permgen problems indicate leaking classloaders holding onto classes. If I turn on -verbose:class and run your build.xml then I can see all the AspectJ classes are loaded many times (if we crash on the 15th iteration, I see they've been loaded 15times). If I remove the <antcall> in your xml and inline the iajc call at that point, I see the classes loaded once and the jar is woven fine any number of times (it is much faster too). This is all because <antcall> spawns a new classloader that is causing the reload of the whole compiler/weaver. The problem is I can't determine if it is AspectJ that has an anchored classloader reference in static somewhere - I can't see how we could leak classloader references when not loadtime weaving.
So is it an Ant bug that after the antcall invocation the new classloader isn't released? As an aside, knowing that it's the <antcall> that's was causing the problem, I was able to "inline" the <iajc> invocation by using the ant <macrodef> tag (learn something every day). As a further aside, the way we're using a iajc is to do post-compile time weaving of numerous jars that have already been built. Right now there isn't a way with iajc to provide a list of jars and have each jar be woven in place.
investigate for 1.5.4 - whether there is something to document here or a particular level of Ant to prereq.
looks fixed in Ant 1.7.0 - your test program runs with that level. Possibly related blog post: http://www.mailinglistarchive.com/dev@ant.apache.org/msg04776.html
