[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] -XX MaxPermSize issue seen with ant: more data...
|
#: Ron Bodkin changed the world a bit at a time by saying (astral date: 4/27/2006 2:39 AM) :#
Andy,
You'll be interested to learn that I get the PermGen space error with the
1.5.0 version of AspectJ too. When I profiled it, I see the exact same
growth of non-heap memory, just a lot more heap memory in use, and a similar
number of class files being retained.
So it looks like none of the optimizations after 1.5.0 are the villain here
:-)
I would say that this is somehow good news Ron :-). At least we know that we are moving forward, and
that we probably hit this problem as the usage of AJ was growing.
trying to put some little optimism into this,
./alex
--
.w( the_mindstorm )p.
-----Original Message-----
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
Sent: Wednesday, April 26, 2006 12:31 AM
To: AspectJ developer discussions
Subject: Re: [aspectj-dev] -XX MaxPermSize issue seen with ant: more data...
Ron ... (you probably can't do this due to all the bugs fixed in
1.5.1a...) is it possible to try your build setup with AspectJ 1.5.0 ?
Does the problem occur? I'm interested in seeing whether it is a new
problem introduced recently, or a problem that has always been there
but we always used to run out of normal heap space before we ran out
of permgen?
Andy.
On 26/04/06, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:
We just ran into an interesting case that indicates that the AspectJ
compiler is also somehow implicated in the perm gen space out of memory
issue. We have an ant build that invokes iajc many times to weave jar
files.
We found that it ran out of memory if we didn't fork iajc. We tried
setting
-Xmx1024m with our ANT_OPTS and still got the out of memory error.
However,
I found that by using set ANT_OPTS=-Xmx256m -XX:MaxPermSize=128m it works.
So in this case I'm very confident that it is the AspectJ weaver that is
exhausting the permanent generation space. This is with a build of AspectJ
that is based on HEAD right after 1.5.1a with a patch for a single bug
report (https://bugs.eclipse.org/bugs/show_bug.cgi?id=136665).
Even better, this might help us diagnose the cause of this problem. I set
it
up to add the option X="set:activateLightweightDelegates=false" to ant.(*)
However, the same error occurrs, thus raising doubt that the problem is
caused by the new asm delegates, at least in this case.
I tried using the YourKit Java profiler but unfortunately it doesn't see
the
permgen memory use. It does show a steadily increasing amount of non heap
memory for the ant task from about 40 MB initially up to 74 MB when the
application dies. It also shows on system that there were 12,712 class
objects, which retained 12.2 million bytes, almost all of the memory. That
doesn't prove anything of course.
I found this article
http://wiki.caucho.com/Java.lang.OutOfMemoryError:_PermGen_space that
talks
about a relevant JVM bug that might have an impact here. Of course another
possibility is that there's a reference to the classes that should have
been
GC'd...
Any other ideas how to narrow this down from this reproducible version of
the bug?
Ron
(*) I discovered that the AjcTask doesn't support this, but after I
created
a patch <https://bugs.eclipse.org/bugs/show_bug.cgi?id=138540> to enable
-Xset: options for ant, I saw a message
info [activateLightweightDelegates=false] Disabling optimization to use
lightweight delegates for non-woven types, so I know this worked.
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
