[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] please help: heap space ballooning when I use aspectJ with my webapplication
|
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
<k_arvind_shankar@xxxxxxxxx>
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
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
