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
