How to analyze JVM Heap dump

When Neo realizes he is the one. [Matrix]

Below is one example of analyzing heap dump to know which objects are responsible for JVM out of memory.

How to get JVM Heap dump?

One way is to have java option option — XX:+HeapDumpOnOutOfMemoryError which trigger heap dump when JVM is out of memory

Another way is to use jmap (available from jdk 1.6 but can also be used on jvm with 1.4+). First find the java process id using jps

bash-4.1$ jps
24437 Jps
11036 WrapperSimpleApp

or you can also use ps -ef to get the java process id.

-bash-4.1$ ps -ef | grep java
app      11036 11034  3 05:07 ?        00:26:49 /usr/lib/jvm/jdk1.6.0_151/bin/java -Xms6g -Xmx6g -XX:NewSize=3g -XX:MaxNewSize=3g -XX:PermSize=512m -XX:MaxPermSize=512m -XX:ThreadStackSize=512 -Duser.timezone=US/Central -XX:SurvivorRatio=8 ... 

Once you know the process id, use below command to generate heap dump.

jmap -J-d64 -dump:format=b,file=<filename>.hprof <jvm-process-id>
bash-4.1$ jmap -J-d64 -dump:format=b,file=heapdump`date +%m%d%y%H%M%S`.hprof 11036

Analyzing heap dump using Eclipse Memory Analyzer

Download Eclipse Memory Analyzer (For 64-bit OS get 64 bit version) — http://eclipse.org/mat/
Depending on the heap size dump you need to increase the vm size of Eclipse MAT
To increase size in Mac OS X, Right click on MemoryAnalyzer (application) then “Show Package Contents”.
Edit — MemoryAnalyzer.app/Contents/MacOS/MemoryAnalyzer.ini

In below example — size of heap dump is 1.8 GB and Eclipse MAT vm size is “3048m” and instance vm size (from which the heap dump is generated) is 2560m.

Open heap dump -

Note: If you have seen below error while importing the heap dump, then add -DhprofStrictnessWarning=true in MemoryAnalyzer.ini.

Once the heap dump is loaded in Eclipse Memory Analyzer
Open dominator tree.

Open dominator tree.

Select “Group by class”

Select “Group by class”

By here you can know what type of objects occupied much of heap dump.

For example — In below scenario, GSAItem objects occupy 41% of heap dump (788 MB of 1.8 GB)

To further know which item’s are responsible for 41%

Right click on atg.adapter.gsa.GSAItem -> List objects -> with outgoing references

Once the objects are listed. To know what type of items.

In GSAItem object, mItemDescriptor.mItemDescriptorName will give the name of the GSAItem.

We need to group by value “mItemDescriptor.mItemDescriptorName” on Class atg.adapter.gsa.GSAItem (in dominator_tree).

So go back to dominator_tree tab, right click on atg.adapter.gsa.GSAItem -> Java Basics -> Group By Value.

In Group By Value window, fill field with “mItemDescriptor.mItemDescriptorName” and click finish.

This will take time depending on the number of objects it needs to parse.

Once it is done, you can see which type of items (GSAItems) take more space in jvm heap space. (sort it by Retained Heap)

In below scenario, ss-sku items took 333 MB of jvm heap space and number of ss-sku items in memory are 35,465 (i.e 35,465 items are cached in memory)

Let’s take example — another heap dump, 1570 SamsSessionComponent Objects took 49%. (1.8 GB of 3.4 GB)

You can also check in each of that object, which property (or references) are taking much space. In below example, each SamsSessionComponent object took 7 MB, out of that 2 MB is taken by evalueCpns property.

In above way, we can identify which objects are responsible for taking up much memory in JVM.