Hi Arvind, let's start with a consideration first. It does not matter how much ram you give a JVM, it will use it completely. If you start it with -Xmx500M it will use those 500 mb completely, and then clean up when it is nearly full. Unfortunately not all JRE implementations also release that RAM to the unerlying OS, so once it has needed 200Mb for 4/5 seconds, it will keep those 200Mb of RAM also if it does not need it anymore.
As you said, as long as performing GC cleans up, there is no leak. Eden space is where short-lived objects are created, those objects that are nearly immediately available for garbage collection, and it's normal for it to go up and down quickly. Obviously AspectJ is another component in your webapp, so it will consume some more RAM. There are a few considerations : - It seems like you are using load time weaving, using the agent I suppose. This means that AspectJ will perform weaving while classes are loaded, so the weaver gets loaded as well in the webapp RAM, and it uses quite some ram. You are talking about 100 Mb, before recent AspectJ versions that employ weak references, 100 Mb were not enough even for a simple application when using LTW. You could try performing compile time weaving, that will reduce memory footprint a lot cause only the AspectJ runtime will be loaded in the webapp RAM. You can easily detect if this is the case because you'll see RAM usage go up fast during the first few requests, and then stabilize or even go down and stabilize a lot lower (it's quite common for me to see peaks of 150Mb when using LTW, and then see the app stay around 40/60Mb after classes are loaded and no more weaving is in progress). - Some advice/pointcuts consume nearly no ram at all (except for the singleton instance of the aspect, that could use some bytes, maybe kilobytes, not more), some others instead "consume" more ram (usually in the eden space) because they create instances. ... cflow, cflowbelow will save a small object in a thread local, which does not consume much ram per se, but if you use a cflow that matches a lot of places, it can spawn and then recollect a lot of these small objects. ... Around advices instantiate a "Closure" object, which is usually quite small, but "Object around() : execution(* *.*(..)) " could cause quite a lot of closures to be created and then eventually garbage collected. ... Different aspect instantiation strategies can consume more ram. By default aspects are singleton, so only one instance of each aspect is in ram, however pertype, percflow etc.. will instantiate many instances, which are not a leak but still consume ram that will have to be garbage collected. ... thisJoinPoint (as opposed to thisJoinPointStaticPart) is an instance, more or less each time you use it inside an advice an instance is created. The instance will be then garbage collected, but still allocate RAM. Using pointcuts like args(), this(), target() etc.. to extract context where possible instead of accessing to thisJoinPoint directly can save some RAM. - If you redeploy your webapplication in tomcat, then you could be hitting a number of memory leaks. I don't think this is your case, otherwise you'd be getting serious exceptions. however, it's not Tomcat itself leaking, but if your webapp starts a thread or registers something in core java SPI systems (like a JDBC driver), a leak will prevent the entire "old" webapplication from being garbage collected. The Tomcat team is working hard to at least detect these leaks. AspectJ could in these case cause a leak when cflow is in use, Andy already has a fix for this which is under test. Hope this helps, Simone 2010/5/13 Ashank <[email protected]> > > Hello! > > > I've been having heap space build up issue when using AspectJ with my web > application in tomcat. I am new to memory profiling. I used JConsole and > jmx > to monitor my web application and see the eden space regularly build up and > fall down (may be normal behavior). As and when I use my web application, > browse some JSP pages in it and execute some classes, I monitor the process > in windows TaskManager and the memory used builds up steadily until it is 4 > times that of what it takes without AspectJ; even taking more than 100MB > from -Xmx option to java. It does not seem to behave like a leak. If I > manually perform GC, the used heap memory comes down to acceptable levels > whereas the committed memory and process memory (in windows task manager) > stays the same. I created some heap dumps in various stages and studied > them > using IBM heap analyzer and I regularly see the ApplicationShutdownHooks > object occupy atleast 75% of the heap space. I have included some excerpts > from the heap analyzer tree view for illustration. > > It starts off like this.... > > 46,663,513 (87%) [76] 2 class java/lang/ApplicationShutdownHooks 0x10192a08 > 46,663,437 (87%) [36] 1 java/util/IdentityHashMap 0x143491d0 > 46,663,401 (87%) [256] 4 array of [Ljava/lang/Object; 0x143491f8 > 46,662,794 (87%) [108] 6 java/util/logging/LogManager$Cleaner 0x14349308 > 34,055,487 (63%) [43] 4 java/lang/ThreadGroup 0x14110738 > 33,121,075 (61%) [43] 3 java/lang/ThreadGroup 0x14110768 > 33,113,794 (61%) [32] 8 array of [Ljava/lang/Thread; 0x14110798 > 33,089,033 (61%) [104] 7 java/lang/Thread 0x172b1628 > 33,088,750 (61%) [146] 27 > org/apache/catalina/loader/WebappClassLoader 0x144298b0 > 29,174,994 (54%) [21] 1 java/security/AccessControlContext > 0x1442a9a8 > 29,174,973 (54%) [8] 2 array of [Ljava/security/ProtectionDomain; > 0x1442a9c0 > 29,173,778 (54%) [26] 4 java/security/ProtectionDomain 0x1413d6d0 > 29,172,921 (54%) [105] 18 > org/apache/catalina/loader/StandardClassLoader 0x1413d860 > 28,822,272 (53%) [24] 1 java/util/Vector 0x1413e0b0 > 28,822,248 (53%) [1,280] 289 array of [Ljava/lang/Object; > 0x14575ea0 > > > The following sections show some aspectj classes deep down in the same heap > dump tree view > > 4,027,262 (7%) [128] 14 org/apache/tomcat/util/threads/ThreadWithAttributes > 0x146c5720 > 3,634,063 (6%) [20] 1 java/lang/ThreadLocal$ThreadLocalMap 0x1566f1b8 > 3,634,043 (6%) [128] 14 array of > [Ljava/lang/ThreadLocal$ThreadLocalMap$Entry; 0x15e60a78 > 1,633,532 (3%) [28] 3 java/lang/ThreadLocal$ThreadLocalMap$Entry > 0x1566f210 > 1,633,504 (3%) [16] 1 org/aspectj/weaver/tools/WeavingAdaptor$1 > 0x1427cad8 > 1,633,488 (3%) [122] 24 > org/aspectj/weaver/loadtime/ClassLoaderWeavingAdaptor 0x1427cae8 > 1,574,501 (2%) [171] 18 org/aspectj/weaver/ltw/LTWWorld 0x1427cb68 > 1,263,000 (2%) [61] 9 org/aspectj/weaver/CrosscuttingMembersSet > 0x142b3e50 > 1,262,519 (2%) [40] 3 java/util/HashMap 0x142b3e90 > 1,262,455 (2%) [64] 8 array of [Ljava/util/HashMap$Entry; > 0x142b3ed8 > 319,167 (0%) [24] 2 java/util/HashMap$Entry 0x142b3f28 > 318,128 (0%) [133] 13 org/aspectj/weaver/ReferenceType 0x142b0148 > 303,121 (0%) [140] 17 org/aspectj/weaver/bcel/BcelObjectType > 0x148b9be0 > 284,449 (0%) [97] 12 org/aspectj/weaver/bcel/LazyClassGen > 0x148be6e8 > 15,058 (0%) [94] 11 org/aspectj/apache/bcel/classfile/JavaClass > 0x148b9e20 > 2,457 (0%) [4] 1 array of > [Lorg/aspectj/weaver/ResolvedPointcutDefinition; 0x148cfa10 > 228 (0%) [16] 2 org/aspectj/weaver/SourceContextImpl 0x148b9d30 > 201 (0%) [25] 2 org/aspectj/weaver/WeaverStateInfo 0x148d0680 > 180 (0%) [24] 1 java/lang/String 0x148b9c70 > 98 (0%) [24] 1 java/lang/String 0x148b9fc0 > 60 (0%) [20] 1 java/util/ArrayList 0x148d0820 > 60 (0%) [20] 1 java/util/ArrayList 0x148d07d0 > 58 (0%) [50] 5 org/aspectj/weaver/patterns/PerFromSuper > 0x148d0778 > 32 (0%) [32] 8 array of [Lorg/aspectj/weaver/ResolvedMember; > 0x148cf9c8 > 24 (0%) [24] 1 java/lang/String 0x148b9fa8 > 24 (0%) [24] 2 java/lang/ref/WeakReference 0x148d0870 > 24 (0%) [24] 2 java/lang/ref/WeakReference 0x148d0888 > 20 (0%) [20] 0 org/aspectj/weaver/AjAttribute$WeaverVersionInfo > 0x148cf9f8 > 8 (0%) [8] 2 array of [Lorg/aspectj/weaver/ResolvedMember; > 0x148cf9b0 > 318,128 (0%) [133] 13 org/aspectj/weaver/ReferenceType > 0x142b0148 > 14,514 (0%) [65] 14 org/aspectj/weaver/CrosscuttingMembers > 0x142b0320 > > > Here is another excerpt branching off from the above tree > > 319,167 (0%) [24] 2 java/util/HashMap$Entry 0x142b3f28 > 318,128 (0%) [133] 13 org/aspectj/weaver/ReferenceType 0x142b0148 > 303,121 (0%) [140] 17 org/aspectj/weaver/bcel/BcelObjectType 0x148b9be0 > 284,449 (0%) [97] 12 org/aspectj/weaver/bcel/LazyClassGen 0x148be6e8 > 276,289 (0%) [20] 1 java/util/ArrayList 0x148c07a8 > 276,269 (0%) [40] 8 array of [Ljava/lang/Object; 0x148c07c0 > 270,593 (0%) [83] 8 org/aspectj/weaver/bcel/LazyMethodGen 0x148c0cf0 > 269,153 (0%) [24] 3 org/aspectj/apache/bcel/generic/InstructionList > 0x148c0f80 > 268,717 (0%) [28] 3 > org/aspectj/apache/bcel/generic/InstructionHandle 0x148c0f98 > 268,491 (0%) [28] 4 > org/aspectj/apache/bcel/generic/InstructionHandle 0x148c0fb8 > After this there is a big list of the above the BCEL InstructionHandle > objects. > > I am not sure what to make of the above data. Is this connected to aspectJ? > As I've mentioned, I notice this only when I enable aspectj in my web > application and include my aspects (which are not carelessly written). > Please help me out as such a memory performance will be a show stopper if > there is no way around! Thanks a lot in advance. > > -Arvind > -- > View this message in context: > http://aspectj.2085585.n4.nabble.com/please-help-heap-space-ballooning-when-I-use-aspectJ-with-my-webapplication-tp2197371p2197371.html > Sent from the AspectJ - users mailing list archive at Nabble.com. > _______________________________________________ > 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
