Re: [aspectj-users] Memory consumption problems

[Tim Schraepen <sch3lp@xxxxxxxxx>]

We 

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
classes.
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
already.
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.