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 <[EMAIL PROTECTED]> > > 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > >
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
