Re: [aspectj-users] iajc ant task - out of memory

["Andy Clement" <andrew.clement@xxxxxxxxx>]

Hi again,

> java.lang.StackOverflowError
>         at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:269)
>         at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
>         at java.util.WeakHashMap.get(WeakHashMap.java:341)
>         at org.aspectj.weaver.World$TypeMap.get(World.java:967)
>         at org.aspectj.weaver.World.resolve(World.java:250)
>         at org.aspectj.weaver.World.resolve(World.java:191)
>         at org.aspectj.weaver.UnresolvedType.resolve(UnresolvedType.java:662)
>         at org.aspectj.weaver.ReferenceType.getRawType(ReferenceType.java:550)

This problem was talked about on the list a long time ago - but it was
seen when load-time weaving rather than using iajc:
http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg07702.html

Unfortunately the end result in that thread isn't great.  I agree with
the suggestions in the thread that it is probably an issue with
AspectJ's handling of generics - the:

       at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:276)
       at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:292)
       at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:276)

suggests as much.  But no-one has ever been able to reliably recreate
it for debugging purposes.
I have fixed some serious issues with generics handling in 1.5.4, you
ought to pick up the latest 1.5.4rc1 that is available as that
includes them.  It is possible that since the issues hasn't reared its
head since that post at the end of March that it was resolved by one
of the other generics changes that went in (there were some pretty
serious fixes I put in).

> the second issue, is (I think) a known *nix JVM issue (and is not likely related to iacj):
>
> java.lang.OutOfMemoryError
>         at java.util.zip.ZipFile.open(Native Method)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:203)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:234)
>         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:92)
>         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.<init>(FileSystem.java:71)

We once had a problem where the classpath passed to ajc had 8000 jar
files on it and I reworked all of the code in the ClasspathJar class
to cope with that.  But I don't think the problem here is too many
jars.  I'm concerned here because that control flow through the code
is done early on during compilation, we shouldn't already be short on
memory by that point.

> >I presume you are just doing straight compiles rather than using iajc
> >in its incremental compilation mode?  Are you building entirely from
> >source, or are you building source then using iajc as a binary weaving
> >step in the build?
> We don't use incremental. This is our ant call:
> <iajc destdir="@{destination}" source="1.5" failonerror="true" fork="true"
>             Xlint="none" maxmem="${iajc.maxmem}" sourceRootCopyFilter="**/*.java">
>             <sourceroots refid="@{source}"/>

That looks ok to me.

> Thanks again for your help. Maybe we shouldn't give up on AspectJ just yet.

Well I'm here to help any way I can.  My first suggestion would be to
use 1.5.4rc1 (1.5.4 should be out before Christmas).  If you are
interested we can take this off list and discuss more specifics and
maybe I can give you some debug or optimized drivers to try and fix
this properly.

Andy.