Eclipse MAT: Understand Incoming and Outgoing References

In [1], we have shown how to use OQL to query String instances starting with a specified substring (i.e., our objects of interest) from a heap dump.^[7,8] To determine who is creating these objects, or find out what the purpose of some structures are, an object's incoming and outgoing references become handy.

In this article, we will examine the following topics:

• What are incoming references or outgoing references of an object?

Then look at three topics related to incoming references:

• Garbage Collection Roots (GC Roots)
• Path To GC Roots
• Immediate Dominators

Outgoing references for the 1st String instance

Outgoing References

Using the following OQL statement, we have identified total 7 entries (see Figure above) as our objects of interest:

SELECT * FROM java.lang.String WHERE toString().startsWith("http://xmlns.oracle.com/apps/fnd/applcore/log/service/types")

After expanding the first entry, it shows two outgoing references:

1. a reference to the Class instance for the String object
2. a reference to an array of char values

Outgoing References show the actual contents of the instances, helping to find out their purpose. In our String instance, it holds two references. The memory overhead of this String instance is shown in two values: ^[3]

• Shallow Heap
• Is the memory consumed by that object alone
• Retained Heap
• Is the sum of shallow sizes of all objects in the retained set of that object

These sizes of String instances depends on the internal implementation of the JVM. Read [2,4] for more details.

Incoming References

To get incoming references of the first entry, choose List Objects with Incoming References from the context menu.

Now a tree structure is displayed, showing all instances with all incoming references (note the different icon highlighted in red). These references have kept the object alive and prevented it from being garbage collected.  

Incoming references for String object are from QName object whose incoming references are, in turn, from HashMap.Entry object and class WebServiceOperation object.  See [9] for more details.

Immediate Dominators

Similarly, from the context menu, you can display immediate dominators of the first entry (see Figure below). An Object X is said to dominate an Object Y if every path from the GC Root to Y must pass through X. So, immediate dominators is a very effective way to find out who is keeping a set of objects alive. For example, the immediate dominators of our first String entry in the OQL query (note that we have used "java.*|com\.sun\..*" as our filter) is:

• oracle.j2ee.ws.server.deployment.WebServiceEndpoint

The immediate donimator of String instance is WebServieEndpoint instance

Garbage Collection Roots (GC Roots)

GC roots are objects accessible from outside the heap. GC algorithms build a tree of live objects starting from these GC roots.

The below list shows some of the GC roots: ^[9,10]

• System Class
• Class loaded by bootstrap/system class loader.
• Thread Block
• Objects referred to from currently active thread blocks
• Basically all objects in active thread blocks when a GC is happening are GC roots
• Thread
• Active Threads
• Java Local
• All local variables (parameters, objects or methods in thread stacks)
• JNI Local
• Local variable or parameter of JNI method
• JNI Global
• Global JNI reference
• Monitor Used
• Objects used as a monitor for synchronization

Path To GC Roots

From context menu, you can also show "Path to GC Roots" of the first entry (see Figure below). Path to GC Roots shows the path to GC roots which should be found for a given object. As you can expect, its immediate dominators must also be on this path. Note that, when you display Path to GC Roots, you can specify which fields of certain classes to be ignored when finding paths. For example, we have specified that paths through Weak or Soft Reference referents to be excluded.

GC root of instance of class String is the HashMap.Entry

Live Data Set

Now we know

• oracle.j2ee.ws.server.deployment.WebServiceEndpoint

is keeping our String instance alive. Instead of viewing Path to GC Roots, it is easier to see it the other way around. So, we have chosen to display the outgoing references of WebServiceEndpoint instance (see Figure below). As you can see, our String instance is displayed as the leaf node of the tree structure.

References

1. Eclipse MAT: Querying Heap Objects Using OQL (Xml and More)
2. Java memory usage of simple data structure
3. Shallow vs. Retained Heap
4. Create and Understand Java Heapdumps (Act 4)
5. Diagnosing Java.lang.OutOfMemoryError (Xml and More)
6. I Bet You Have a Memory Leak in Your Application by Nikita Salnikov-Tarnovski
• Classloader leak is the most common leak in web applications
7. How to analyze heap dumps
• Leak can be induced
• Per call (or a class of objects)
• Per object 
8. Diagnosing Heap Stress in HotSpot (Xml and More)
9. Basic Concepts of Java Heap Dump Analysis with MAT (good)
10. What are the GC roots?

Eclipse MAT: Querying Heap Objects Using OQL

This article is a follow-up of [1]. Here we continue to explore on how to investigate memory leaks of an application using Memory Analyzer.^[2]

Querying Heap Objects (OQL)

Memory Analyzer allows you to query the heap dump^[3] with custom SQL-like queries (OQL). OQL represents classes as tables, objects as rows, and fields as columns:^[4]

SELECT *
FROM [ INSTANCEOF ] <class name="name">
[ WHERE <filter-expression> ]
</filter-expression></class>To open an OQL editor use the toolbar button :

For instance, we have used the following SQL statement:

select * from java.lang.String where toString().startsWith("http://xmlns.oracle.com/bpel")

to query String objects with a certain prefix (i.e., "http://xmlns.oracle.com/bpel") and calculate the total size of retained heap associated with the interested objects.  Note that you need to press red "!" button to execute the OQL.

Shallow vs. Retained Heap

As shown in the Figure, two sizes of an object are displayed in the Result area:

• Shallow heap
• Retained heap

Generally speaking, shallow heap of an object is its size in the heap and retained size of the same object is the amount of heap memory that will be freed when the object is garbage collected. In other words, retained heap of object X is the sum of shallow sizes of all objects in the retained set of X, the set of objects which would be removed by Garbage Collector when X is garbage collected.

As said in [6], while Shallow Heap can be interesting, the more useful metric is the Retained Heap. For example, you can benchmark retained sizes of interested objects before and after your code optimizations. Below, we will show how to compute the total retained size of our interested objects.

Exporting to CSV...

Analyzed data can be exported from the heap editor by:^[5]

• Using the toolbar export menu (you can choose between export to HTML, CSV, and TXT)

Let's say we have exported it to a CSV file named RetainedHeap.txt.

Importing CSV File into Excel

You can use Java code to parse the CSV file and compute the retained heap of interested objects. An alternative way is using Excel, which is demonstrated here.

First, you open RetainedHeap.txt and specify both comma and space as the delimiters of fields.

Then, select all "Retained Heap" fields (shown in red) and compute the Sum as shown below:

Finding Responsible Objects

To investigate your potential memory leaks, it will be important to answer the following question:

Who has kept these objects alive?

To answer that, you can use Immediate Dominators (an Object X is said to dominate an Object Y if every path from the Root to Y must pass through X) from the context menu. This query finds and aggregates all objects dominating a given set of objects on class level. It is very useful to quickly find out who is responsible for a set of objects. Using the fact that every object has just one immediate dominator (unlike multiple incoming references) the tool offers possibility to filter "uninteresting" dominators (e.g. java.* classes) and directly see the responsible application classes.

For example, if your interested objects are char arrays. The immediate dominators of all char arrays are all objects responsible for keeping the char[] alive. The result will contain most likely java.lang.String objects. If you add the skip pattern java.* , and you will see the non-JDK classes responsible for the char arrays.

  

Bonus OQL Example

In the above OQL example, it shows that two columns were selected:

• toString(s.sqlObject.actualSql)
• s.@retainedHeapSize

from oracle.jdbc.driver.T4CPreparedStatement (alias: s).  Also, a filter was added (highlighted in red):

• .*SELECT TerritoryResource.*

References

1. Diagnosing Java.lang.OutOfMemoryError (Xml and More)
2. Memory Analyzer Downloads
• The stand-alone Memory Analyzer is based on Eclipse RCP.
• Can find the update site here too.
3. Diagnosing Heap Stress in HotSpot (Xml and More)
4. Querying Heap Objects (OQL)
5. Export Data
6. 10 Tips for using the Eclipse Memory Analyzer
7. Analyzing a Heap Dump Using Object Query Language (OQL)
8. Basic Tutorial of MAT