Re: [aspectj-users] Memory consumption problems

[Tim Schraepen <sch3lp@xxxxxxxxx>]

Hey Andy

Thanks for the quick reply.
We're seeing classes being loaded into the World that shouldn't.
I've been toying around with all sorts of regexp patterns, but nothing
seemed to work.

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.
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.
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.
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).

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

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).

Do you think maybe the placement of the aop.xml, and/or the placement of
aspectjweaver.jar may be the cause?
I tried adding an aop.xml with restrictions in the actual aspectJWeaver.jar
that is included as a jvm argument too, but that didn't seem to work either.

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.

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


Andy Clement wrote:
> 
> Hi Tim,
> 
> Yes, the inclusions/exclusions define what gets pulled into the world
> map for weaving, but they (and related weaver state for them) do still
> consume a bunch of space.  Any types pulled in during analysis of the
> types for weaving is temporarily in the world but discarded later (or
> rather orphaned later, for GC).  Things are improved in AspectJ 1.6.7.
>  In 1.6.7, after a weave we more aggressively chuck away (orphan)
> types that were not affected by ITDs.  Basically trying to discard
> anything which can easily/cheaply be discovered again later.  If the
> world is still too large then having a hook so we can be told we are
> no longer needed (a shutdown type call) may be the 'final solution'.
> 
> More details on the strategy that is now turned on by default are in
> this article:
> http://andrewclement.blogspot.com/2009/04/aspectj-load-time-weaving-and-memory.html
> In the article it is called type demotion and had to be switched on
> prior to 1.6.7, but in 1.6.7 it is the default behaviour.
> 
> cheers,
> Andy
> 
> 2009/12/2 Tim Schraepen <sch3lp@xxxxxxxxx>:
>>
>> Why don't you just use the inclusion and exclusion rules in the aop.xml
>> files
>> to decide which classes actually get loaded into the World map?
>>
>>
>> Andy Clement wrote:
>>>
>>> Given that doing the right thing with freeing memory is non trivial, I
>>> was
>>> thinking just now about an interim measure.  A user callable API where
>>> you
>>> could indicate to the AspectJ infrastructure that you *knew* the
>>> classloader
>>> had finished loading everything you wanted it to.  Upon making the API
>>> call
>>> we would immediately discard the whole weaver *but* keep a note of the
>>> classloader so that any future attempts to load classes that would have
>>> been
>>> woven will receive suitable warning/error messages.  I'll take any
>>> comments
>>> anyone has on doing something like that... I'm not sure how easy it is
>>> for
>>> you to determine when you know everything has been loaded..
>>>
>>> Cheers
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Memory-consumption-problems-tp18649090p26607167.html
>> Sent from the AspectJ - users mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
> _______________________________________________
> 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-tp18649090p26613501.html
Sent from the AspectJ - users mailing list archive at Nabble.com.