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 <[email protected]>: >> >> 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 >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > _______________________________________________ > aspectj-users mailing list > [email protected] > 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. _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
