Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Memory consumption problems

Hi Tim,

I didn't realise you were actually having real issues right now.  So
let's see what we can do about it.  I've raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=296734 to track this
problem.

> We're running on a SunApp, and we include the aspectJWeaver.jar as a JVM
> argument, so as to have the agent for LTW. But what I think is happening, is
> that because we include it as a JVM argument, the adaptor (I think?) is
> loading _all_ classes loaded by the classloader in which AspectJWeaver.jar
> is loaded into, get loaded.

The weaver agent has an option to 'see' all the classes loaded by the
loader it is attached too.  And running with -javaagent, nearly all
classloader instances in the system will get a weaver, except for
instances of:

sun.reflect.DelegatingClassLoader

(we don't want to instrument things that loads).

includes/excludes are respected according to the set of aop.xml files
that can be 'seen' from the classloader in question.  If running with
debug the weaver instance will tell you which aop.xmls it has seen.

> And since our aop.xml file with inclusions and exclusions is only in a child
> classloader (en EJB or Web), the filtering isn't going on.
> When we look at the GC graph, it keeps adding and removing about 600mb of
> memory every minute or so.
> And eventually leads to FullGC's and PermGen crash.

That seems a lot...but regardless of how much it is, after the weave
of any particular type a whole ton of it should be orphaned for
potential GC (held onto via weak references).

> Analyzing the heapdumps so far has also pointed out a lot of AspectJ classes
> taking up a LOT of memory.
> There are even BcelObjectTypes referring to compiled jsp's.

In a heap dump it is important to look at those types anchored via
hard references from root and not just look at the heap as a whole and
look how many BcelObjectTypes there are, since many may be weakly
referenced - are all the BcelObjectTypes anchored from root?

> My theory is the map just keeps growing along with how many classes are
> loaded, and then the memory just isn't enough for loading in everything and
> crashes.
>
> I have been suspecting aop.xml merging for this behaviour, but sort of ruled
> it out by getting rid of aop.xml in spring-agents.jar (which is found in the
> web-inf/lib of one of our modules deployed on the appserver, along with a
> sub-module jar that contains _our_ aop.xml with the correct inclusions and
> exclusions).

I see.  The spring aop.xml does define some sophisticated aspects that
may well be getting into the mix here.

> Documentation I was able to dig up anywhere on the internet was helpful, but
> I still feel like a total idiot about AspectJ.

Me too sometimes :)  I didn't write the original LTW stuff so am not a
100% expert on it (yet).

> I had found your blog post about the performance gain in 1.6.7 and was
> hopeful, but it didn't solve our problem (loading classes that should be
> excluded).

So you tried running on a very recent 1.6.7 dev build?  If you want
to, I am more than willingly to work with you on this issue - if you
are running with a very recent AspectJ dev build and were able to
share dumps with me, I'll sort it out.  Either email them to me or
zip/attach them to that bug report.  yourkit is my preferred format,
but I can deal with pretty much anything.  It would be interesting to
know if you are using a lot of ITDs, or simply advice? Since that
makes a difference on what gets held onto in a World.

> Do you think maybe the placement of the aop.xml, and/or the placement of
> aspectjweaver.jar may be the cause?

It could be the aop.xml merges causing you a headache, or it could
simply be the inability to say "I DONT WANT A DAMN WEAVER FOR THOSE
JSP CLASSLOADERS" :) An ability to filter which classloaders you want
a weaver for has been talked about before but there is currently no
mechanism.  Do you believe you want to weave the result of JSP
compilation?  I think there can be a ton of jsp classloaders in a
system, coming and going regularly.  However, although a lot of memory
may be getting used, I don't understand why you are eventually running
out since care has been taken that once loaders go then weavers
attached to them also vanish.  AspectJ shouldn't really be able to
cause PermGen issues by itself as it doesn't create and manage
classloaders itself, however *if* there is a bug and it is anchoring a
classloader that the system has already discarded, that could lead to
a permgen problem.  In your heap dump, take a look for classloader
instances and whether any are being hard referenced through AspectJ.

> I feel like I've tried everything, so today I was converting all our modules
> to compile time weaving. Which impacts our development process and increases
> build-time and what not. But it works, and just loads the strictly necessary
> woven classes.

Latest aspectj has really improved some build times due to improved
matching algorithms.  I heard AJDT build time was down from 55 seconds
to 38 seconds - both of which are low, but that saving should scale up
to any size system that is doing a decent amount of weaving.

> I also feel like I'm kind of hi-jacking this thread. Whoopsie.

No problem - we can continue this discussion on the mailing list, in
bugzilla or on email.  up to you :)

cheers,
Andy


Back to the top