static variable org.aspectj.weaver.loadtime.Aj$WeaverContainer.weavingAdaptors
that is the map from classloader to weaver instance. To do anything further I would need to know who is holding on to the WeaveClassLoader instances. If it is AspectJ code, I can fix it - if it is Ant code, I cannot. Can you tell that from the profiler you are using? Andy. 2008/7/22 Anfernee Xu <[EMAIL PROTECTED]>: > Thanks Andy for your information. > > I tried the API call > org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true) > > but it does not help, the memory still bloats, I ran a profiler to monitor > the possible memory leak, > between two time slides, I can see the following instances constantly going > up. > > static variable > org.aspectj.apache.bcel.util.ClassLoaderRepository.sharedCache > > and > > static variable > org.aspectj.weaver.loadtime.Aj$WeaverContainer.weavingAdaptors > > Hope it can help you find out what's going wrong. > > If you need any further information, feel free to ask me. > > Thanks for your help. > > Anfernee > > > On Wed, Jul 23, 2008 at 1:33 AM, <[EMAIL PROTECTED]> > wrote: > >> Send aspectj-users mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> or, via email, send a message with subject or body 'help' to >> [EMAIL PROTECTED] >> >> You can reach the person managing the list at >> [EMAIL PROTECTED] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of aspectj-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Error building project with Eclipse+AJDT 1.5.2 (Andy Clement) >> 2. Re: LTW (load time weaving) with Aj throws OutOfMemoryError >> (Andy Clement) >> 3. Static Analysis, BCEL and aspectj (100ji) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 22 Jul 2008 10:18:52 -0700 >> From: "Andy Clement" <[EMAIL PROTECTED]> >> Subject: Re: [aspectj-users] Error building project with Eclipse+AJDT >> 1.5.2 >> To: [email protected] >> Message-ID: >> <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi Walter, >> >> 2008/7/22 Walter Cazzola <[EMAIL PROTECTED]>: >> >> > Hi Andy, >> > thanks a lot for the answer >> > >> > On Mon, 21 Jul 2008, Andy Clement wrote: >> > >> > There is a 64k size limit for methods in Java. Sometimes if an >> >> already large method contains many join points that match then during >> >> weaving the size will grow past 64k. AspectJ does not do any >> >> splitting of the woven code into multiple methods in this case but >> >> just reports that it cannot weave that method. >> >> >> > >> > We was imaging something like this. Is there a way to work around this >> > problem? >> > >> >> Only the workarounds you might imagine, there is no magic solution: >> - use withincode() to avoid weaving the method that will get too large >> with >> your general aspect and write specific advice for relevant join points >> within it. >> - use execution() matching advice rather than call() which might advise >> fewer places >> - turn off advice inlining if using around advice, to reduce code inserted >> into advised methods >> - don't use non-static information available at the join point since that >> must be packaged up and passed to the advice every time >> >> >> > >> > We are going to weave our aspects on third part applications and we >> > don't want to refactor their code since our aspects have the intent to >> > determine what can be extracted and encapsulated in aspects (aspect >> > mining) but this sounds as a recursive problem. >> >> >> The correct solution is breaking the advised method into pieces when it >> gets >> too large, but so far it happens infrequently enough that fixing it hasn't >> become a priority for us I'm afraid. In fact I don't even think we have >> an >> open bug request to address it - feel free to raise one but I'm not sure >> we'll get to it soon. >> >> cheers, >> Andy. >> >> >> >> > >> > >> > Cheers >> > Walter >> > >> > -- >> > Walter Cazzola, PhD - Assistant Professor, DICo, University of Milano >> > E-mail [EMAIL PROTECTED] Ph.: +39 02 503 16300 Fax: +39 02 503 >> 16100 >> > · · · ---------------------------- · · · ---------------------------- · >> · · >> > ... recursive: adjective, see recursive ... >> > · · · ---------------------------- · · · ---------------------------- · >> · · >> > _______________________________________________ >> > aspectj-users mailing list >> > [email protected] >> > https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/93aa98b5/attachment.html >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 22 Jul 2008 10:28:14 -0700 >> From: "Andy Clement" <[EMAIL PROTECTED]> >> Subject: Re: [aspectj-users] LTW (load time weaving) with Aj throws >> OutOfMemoryError >> To: [email protected] >> Message-ID: >> <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> > My Ant task will destroy the classloader which creates Aj after each >> processing. It looks to me the >> > loaded/transformed classes is not clean up when the classloader is >> destroyed. >> > I used the latest AspectJ relase, 1.6.1 >> >> I specifically tested that tidy up is occurring with 1.6.1 and all my >> scenarios confirm it - however that is doing loadtime weaving the regular >> way. I have seen problems with Ant where classloaders have not been >> released, even when you think they must have. Can you run your >> classloader >> in a regular Java scenario outside of Ant and confirm whether it behaves? >> >> There is an API call >> >> org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true) >> >> that will attempt to remove weavers attached to stale classloaders. Try >> calling that and seeing what output you get - if they cannot be tidied up >> then the classloaders have not been orphaned. In that case collect some >> hprof profiling output and use something like (j)hat to see who is holding >> on to references to them. If it is the weaver then I have a bug to fix. >> >> What is still a problem is that over time the weaver instances will get >> larger and larger and never shrink - we have an open bug report for that. >> But if you are constantly using different classloaders (and so different >> weaver instances) then they will come and go and never grow out of >> control. >> >> Andy. >> >> >> 2008/7/22 Anfernee Xu <[EMAIL PROTECTED]>: >> >> > Hi, >> > >> > I'm developing an Ant task which will use LTW to enhance the classes >> > specified in <classpath> nested element of my Ant task. Basically, I >> create >> > a subclass of AntClassLoader, the classloader is at the bottom of >> > classloader tree. and use org.aspectj.weaver.loadtime.Aj to perform LTW, >> > here's my ClassLoader code snippet, >> > >> > class WeaveClassLoader extends AntClassLoader { >> > >> > // aspectj byte-code transformer >> > protected Aj transformer = null; >> > >> > // whether need byte-code transformer. >> > protected boolean isAjOn = false; >> > >> > @Override >> > protected final Class defineClassFromData(File container, byte[] >> > classData, >> > String classname) throws IOException { >> > >> > byte[] classBytes = transform(classname, classData, this); >> > return super.defineClassFromData(container, classBytes, classname); >> > >> > } >> > >> > protected byte[] transform(String classname, byte[] byteCode, >> > ClassLoader classloader) { >> > if (isTransformerTurnOn() && isWeavedClass(classname)) >> > return transformer.preProcess(classname, byteCode, this); >> > return byteCode; >> > } >> > >> > >> > @Override >> > protected synchronized Class loadClass(String classname, boolean >> resolve) >> > throws ClassNotFoundException { >> > Class theClass = findLoadedClass(classname); >> > if (theClass != null) { >> > return theClass; >> > } >> > if (isSplit(classname) || isAspect(classname)) { >> > theClass = findClass(classname); >> > if (resolve) { >> > resolveClass(theClass); >> > } >> > >> > } else { >> > theClass = super.loadClass(classname, resolve); >> > } >> > >> > return theClass; >> > } >> > >> > The function run pretty well, but over time, it consumed more memory and >> > eventually threw OutOfMemory and aborted. >> > >> > The stacktrace is as follows, >> > >> > testErrorHandling_exceptiontype: >> > Jul 20, 2008 2:36:10 PM org.aspectj.weaver.tools.Jdk14Trace error >> > SEVERE: junit.framework.Test >> > java.lang.OutOfMemoryError: CG(q0) >> > [org/aspectj/apache/bcel/Constants.<clinit>()V] [EMAIL >> > PROTECTED](src/jvm/code/codemanager.c:693). >> Java heapsize=604577792, pa >> > at >> > >> org.aspectj.apache.bcel.classfile.Attribute.readAttribute(Attribute.java:177) >> > at >> > >> org.aspectj.apache.bcel.classfile.FieldOrMethod.<init>(FieldOrMethod.java:111) >> > at org.aspectj.apache.bcel.classfile.Field.<init>(Field.java:83) >> > at >> > >> org.aspectj.apache.bcel.classfile.ClassParser.readFields(ClassParser.java:280) >> > at >> > >> org.aspectj.apache.bcel.classfile.ClassParser.parse(ClassParser.java:172) >> > at >> > >> org.aspectj.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:288) >> > at >> > org.aspectj.weaver.bcel.BcelWorld.lookupJavaClass(BcelWorld.java:369) >> > at >> > org.aspectj.weaver.bcel.BcelWorld.resolveDelegate(BcelWorld.java:338) >> > at >> org.aspectj.weaver.ltw.LTWWorld.resolveDelegate(LTWWorld.java:97) >> > at org.aspectj.weaver.World.resolveToReferenceType(World.java:378) >> > at org.aspectj.weaver.World.resolve(World.java:271) >> > at >> > org.aspectj.weaver.bcel.BcelWeaver.addLibraryAspect(BcelWeaver.java:165) >> > at >> > >> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerAspects(ClassLoaderWeavingAdaptor.java:399) >> > at >> > >> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerDefinitions(ClassLoaderWeavingAdaptor.java:240) >> > at >> > >> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:152) >> > at >> > >> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151) >> > at >> > >> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:156) >> > at >> > org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122) >> > at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73) >> > ..... >> > Jul 20, 2008 2:36:10 PM org.aspectj.weaver.tools.Jdk14Trace info >> > INFO: Dumping to .\ajcore.20080720.143610.453.txt >> > 302 >> > >> tests.functional.webapp.servlet25.clarifications.client.TestClarifications.testClarifications >> > (junit) >> > testErrorHandling_errorcode: >> > Jul 20, 2008 2:36:12 PM org.aspectj.weaver.tools.Jdk14Trace error >> > SEVERE: junit.framework.Test >> > java.lang.OutOfMemoryError: class allocation, 967086156 loaded, >> 893648896 >> > footprint [EMAIL PROTECTED] (src/jvm/model/classload/classalloc.c:118). >> 5841 >> > bytes >> > at java.lang.ClassLoader.defineClass1(Native Method) >> > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) >> > at >> > >> org.apache.tools.ant.loader.AntClassLoader2.defineClassFromData(AntClassLoader2.java:78) >> > at >> > >> org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1090) >> > at >> > >> org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1154) >> > at >> > org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:984) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) >> > at >> > >> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:140) >> > at >> > >> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151) >> > at >> > >> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:157) >> > at >> > org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122) >> > at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73) >> > >> > >> > >> > My Ant task will destroy the classloader which creates Aj after each >> > processing. It looks to me the loaded/transformed classes is not clean >> up >> > when the classloader is destroyed. >> > I used the latest AspectJ relase, 1.6.1 >> > >> > Any help is appreciated. >> > >> > Anfernee >> > >> > _______________________________________________ >> > aspectj-users mailing list >> > [email protected] >> > https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/a6de41b0/attachment.html >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 22 Jul 2008 13:32:56 -0400 >> From: 100ji <[EMAIL PROTECTED]> >> Subject: [aspectj-users] Static Analysis, BCEL and aspectj >> To: [email protected] >> Message-ID: >> <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hi all, >> >> I have a few novice questions about aspectj. >> >> 1) Why can't aspectj be used to perform *some* forms of static >> analysis? For example, for a given source code, I need to find if the >> code has any calls to java.io.ObjectInputStream.readObject and the >> type of object being read if any calls exist. I can use a static >> analysis tool like PMD to find this out, but writing a tree walker is >> extra work when aspectj knows how to do it. Why can I not write >> something like a compile_time_pointcut and compile_time_advice to >> specify this? Since aspectj already knows how to match patterns it can >> give me the points I am interested in during compile time and run the >> compile_time_advice. I understand that this approach is not as >> powerful as one would like it to be, but this seems like a better >> approach then the existing tools. I am not aware if any of the static >> analysis tools can match patterns using a pointcut like syntax, so >> this seemed like a useful addition. >> >> 2) Why is there no support for join points at a line level? For >> example, I want to write an advice before or after the true condition >> block of the if clause. Is there any fundamental reason why this is >> not possible in aspectj? IIRC I can do this using BCEL or other byte >> code engineering libraries. But, I heard that using 2 instrumentation >> tools on the same code is a bad idea (ex: aspectj and BCEL) since >> either of them may not understand the instrumentation made by the >> other. What do people do when they have to instrument code at a low >> level and still have to use aspectj. What libraries should I use, if >> I want to do some bytecode level engineering and still use aspectj? >> >> TIA, >> -S- >> >> >> ------------------------------ >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> >> End of aspectj-users Digest, Vol 41, Issue 34 >> ********************************************* >> > > > > -- > --Anfernee > > _______________________________________________ > 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
