The output of console shows [EMAIL PROTECTED] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT [EMAIL PROTECTED] info register classloader [EMAIL PROTECTED] [EMAIL PROTECTED] info using configuration file:/D:/test/aj-transformer.jar!/META-INF/aop.xml [EMAIL PROTECTED] info register aspect com.ctc.aspects.TransformerAspect
Transforming class ... Weaver adaptors before queue processing: [EMAIL PROTECTED] = [EMAIL PROTECTED] Weaver adaptors after queue processing: [EMAIL PROTECTED] = [EMAIL PROTECTED] Weaver adaptors before queue processing: [EMAIL PROTECTED] = [EMAIL PROTECTED] Weaver adaptors after queue processing: [EMAIL PROTECTED] = [EMAIL PROTECTED] Anfernee On Wed, Jul 23, 2008 at 11:25 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: LTW (load time weaving) with Aj throws OutOfMemoryError > (Andy Clement) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Jul 2008 20:25: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" > > Also, you didn't tell me the output produced for making that API call. > Passing 'true' means it should tell you the size of the weaveradaptor set > and whether it is managing to clean it up? (to stdout) > > 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 11:03 AM, Anfernee Xu <[EMAIL PROTECTED]> > > wrote: > > > >> 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 > >> > > > > > > > > -- > > --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/7a64227c/attachment.html > > ------------------------------ > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > End of aspectj-users Digest, Vol 41, Issue 38 > ********************************************* > -- --Anfernee
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
