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, <
aspectj-users-request@xxxxxxxxxxx> wrote:
Send aspectj-users mailing list submissions to
aspectj-users@xxxxxxxxxxx
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
aspectj-users-request@xxxxxxxxxxx
You can reach the person managing the list at
aspectj-users-owner@xxxxxxxxxxx
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" <andrew.clement@xxxxxxxxx>
Subject: Re: [aspectj-users] Error building project with Eclipse+AJDT
1.5.2
To: aspectj-users@xxxxxxxxxxx
Message-ID:
<689d61aa0807221018n5ae0ed10r9fa295ca26db2a41@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
Hi Walter,
2008/7/22 Walter Cazzola <cazzola@xxxxxxxxxxxxx>:
> 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 cazzola@xxxxxxxxxxxxx Ph.: +39 02 503 16300 Fax: +39 02 503 16100
> · · · ---------------------------- · · · ---------------------------- · · ·
> ... recursive: adjective, see recursive ...
> · · · ---------------------------- · · · ---------------------------- · · ·
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> 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" <andrew.clement@xxxxxxxxx>
Subject: Re: [aspectj-users] LTW (load time weaving) with Aj throws
OutOfMemoryError
To: aspectj-users@xxxxxxxxxxx
Message-ID:
<689d61aa0807221028y34115351r26c54fa85a214179@xxxxxxxxxxxxxx>
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 <anfernee.xu@xxxxxxxxx>:
> 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] JVM@cgFail(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 JVM@check_alloc (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
> aspectj-users@xxxxxxxxxxx
> 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 <itz100ji@xxxxxxxxx>
Subject: [aspectj-users] Static Analysis, BCEL and aspectj
To: aspectj-users@xxxxxxxxxxx
Message-ID:
<496ed55f0807221032p37836435je1515b6755d80af9@xxxxxxxxxxxxxx>
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
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
End of aspectj-users Digest, Vol 41, Issue 34
*********************************************
--
--Anfernee
