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


Andy Clement wrote:
>> 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?

I'll try and gmail you the heap dump we took with jmap.
The way we "analyzed" it with  http://www.eclipse.org/mat/ MAT , is we got
references to BcelObjectTypes, and then showed path to gc root excluding
weak/phantom references.
I'm very new to all this stuff, so chances are I'm wrong about my Full GC
theory :)

Andy Clement wrote:
>> 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).
>> 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 see.  The spring aop.xml does define some sophisticated aspects that
> may well be getting into the mix here.
>> 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.
I did, and the heap size even increased compared to a version of 1.6.6.
The Full GC issues we're having right now are with version 1.6.2.

What are ITD's?

For one module we're just using @Configurable and Spring aspects on domain
For another module we have aspects for logging and accounting and stuff.
We can see the symptoms when we just deploy the module with @Configurable
It just gets worse when other modules are deployed (because this just means
more classes to be contained in the World map I think)

Andy Clement wrote:
>> 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
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

View this message in context: http://old.nabble.com/Memory-consumption-problems-tp18649090p26623594.html
Sent from the AspectJ - users mailing list archive at Nabble.com.