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