Hi Ashley,
Loadtime weaver instances attached to classloaders are still heavier than I would like them to be. I've done a lot of work in 1.6.1 to ensure that once the loader is available for GC then the weaver is also available for GC - and that is working fine. The problem remaining is covered in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=227484 and that relates to weavers not shrinking over time once they have done their job. Yes, as you put it:
> Hopefully then, those bcel instances
are just transitory in the LTW process and are immediately
> ready for garbage collection when the
new class bytecode is produced.
that should be true but it isn't always. Sometimes for a good reason (we hang onto aspects as we may need their bcel bytecode representation later, perhaps to inline into some class that gets loaded later). Sometimes for a bad reason - where we have a poor implementation of equality that requires identity equality (==) rather than supporting equals() properly. In this latter situation we can't currently discard some things because if they are needed again sometime later we cannot recover the identical previous object. This situation is what bug 227484 is about - I would have liked to fit it into 1.6.1 but it did not have sufficient testing.
>
Without knowing more about
them and if they will consume more memory with time, we can't proceed any
further.
There is no reason why it should consume more memory over time - unless you load more classes. Once all your classes are loaded and have been woven, the weaver has no reason to get involved in anything further, it will just sit there on the 'off chance' that you might load a class further down the line. As you will see in bug 227484 what should happen is that the memory is recovered from the weaver over time as it is required elsewhere in the VM.
Ashley said:
> The aspect we have created contains
a stopwatch implementation and a logger and its cardinality is percflow
so we get
> one per service method call on our server. I was under the impression
though that as soon as the method call is finished
> any aspectj resources
associated are eligable for garbage collection.
Ken said:
> I'd be very surprised if it's aspectj holding references on percflow
> -- it'd be a bug. Otherwise there'd be a large warning on it's use.
yes, cflows are implemented using ThreadLocal, there is no magic. If AspectJ was leaking memory through instances via percflow you would gradually run out of memory as the code was exercised and it would be a huge bug. However, all the types on your list are nothing to do with runtime behaviour of the woven code, they only relate to the weaving process - which is what gives me the confidence to say the weaver footprint' won't get larger over time.
> I have no idea how aspectj works under
the hood and I can't find much info through google either.
There is a paper by Jim and Erik but it is quite old now. I haven't had time to write more detailed notes on the internals just due to too much to do with upgrading to Java 6 and fixing open issues.
> Since we are using LTW, my guess is
that the aspectj class loading interceptor uses bcel to filter the
> class files according to our aspects
and in doing so creates the bcel instances below.
Yep. But although AspectJ does use bcel - it uses a highly optimized derivate variant of what is on the public bcel page. So you can't really rely on that doc to give you much info.
> However this is pure speculation based
on 5 minutes at the bcel website and therefore
> would like to find out a little more.
I would definitely recommend at least one prominent
> page on this sort of thing at eclipse.org,
since surprises like this, even if it is benign, can
> cause panic in organizations at the
early adoption stage for aspectj.
Discussion of weaver footprint comes up on the list periodically - and is what gave rise to bug 227484. I try to talk about major changes in memory usage in the readme for releases (see the 1.6.1 readme, for example,
http://www.eclipse.org/aspectj/doc/released/README-161.html ) but I'll admit I haven't typically highlighted the current bugs that are open to cover future memory optimizations. I don't typically like to add FAQ entries for bugs, which is what the large latent footprint is, but I know it is taking me a while to getting around to addressing it so perhaps it deserves one.
> I would appreciate it if somebody could
shed some light on this.
Well I've had a first stab, if you need more info please ask away. If you want to get an updated driver for 227484 and help me test whether it works, that would be great ! Also, I can't see mention of what version you are on, I hope you are on 1.6.1 due to all the ltw enhancements and fixes.
cheers,
Andy.2008/7/25 Ashley Williams
<ashley.williams@xxxxxx>
Hi,
We were looking forward to going to
production with our profiling aspect however when we ran our app through
jmap we got the chart pasted below. So it looks like some aspectj objects
are responsible for a sizable share of memory. Without knowing more about
them and if they will consume more memory with time, we can't proceed any
further.
The aspect we have created contains
a stopwatch implementation and a logger and its cardinality is percflow
so we get one per service method call on our server. I was under the impression
though that as soon as the method call is finished any aspectj resources
associated are eligable for garbage collection.
I would appreciate it if somebody could
shed some light on this.
Cheers
- Ashley Williams
Size
Count Class
163466352 2149652 char[]
102393424 609786 byte[]
92017240 2300431 java.lang.String
43706328 114013 java.lang.Object[]
38792736 808182 java.util.HashMap$Entry
32742008 201623 int[]
32662680 269046 java.util.HashMap$Entry[]
31770768 234338 * ConstMethodKlass
26740224 417816 java.util.TreeMap$Entry
24387008 762094 org.aspectj.apache.bcel.classfile.ConstantUtf8
24380640 234338 * MethodKlass
18097728 188518 org.jboss.jms.message.JBossObjectMessage
17139712 267808 java.util.HashMap
16629528 13554 * ConstantPoolKlass
16087896 182817 org.aspectj.apache.bcel.classfile.Method
15182816 172532 org.aspectj.apache.bcel.classfile.Code
14216368 402768 org.aspectj.apache.bcel.classfile.Attribute[]
12472208 82054 java.lang.reflect.Method
11550800 13554 * InstanceKlassKlass
10796824 8196 org.aspectj.apache.bcel.classfile.Constant[]
10261296 199361 * SymbolKlass
---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
