Unorthodox Uses of the Memory Leak Detection Tool - Part 1 (Migrated from the old BEA blog)

The JRockit Memory Leak Detection tool (henceforth abbreviated Memleak) is part of JRockit Mission Control 2.0, the JRockit tools suite. It has served many people quite well in hunting for memory leaks in Java, i.e. hunting for the cause to why objects that shouldn't be in use still have references to them.

How to hunt for these memory leaks using the Memleak tool has been discussed to death, so this blog entry is going to show you other fun filled uses of the tool. ;)

First off we'll explore how Memleak can help us look at how any given type is being used within the JVM.

Start Mission Control and hook it up to a JRockit doing pretty much nothing but sleeping. In my case I'm connecting it to a JRockit started on my local machine.

starting_memleak 

You may want to pause the updating of the trend table by pressing the pause button in the toolbar above the table, especially if JRockit is very busy.

After pausing the updating of the table, locate a class for which you want to explore the dependencies, say Hashtable entries (java.util.Hashtable$Entry), and select Show Referring Types from the context menues to see what is pointing to that particular type.

show_referring 

You'll find that, not surprisingly, the entries are pointed to by hashtable entry arrays. Click the plus sign to work your way backwards, and you'll find out that, again not very surprisingly, various hashtable clones are pointing to these arrays. Click Hashtable to expand who is using Hashtables. Woooah!? We get a funny arrow directly to Hashtable from our Entry, thus completing a cycle in our graph.

cycle 

Hmmm. Someone is obviously putting Hashtables into Hashtables. Now, who does that? Let's look at the instances that are taking part in that particular relationship. Bring up the context menu on the java.util.Hashtable$Entry, and select show instances. A dialog will pop up, prompting you to select for what relationship you want to list the instances. We select Hashtable, since we want to find out what entries that are pointing to hashtables. We get a list of entries, in my case 5 candidates.

relationships 

As we can see, there are four of them keeping alive more than 100 000 bytes of data. Let's pick the top one - bring up the context menu and select to show who's pointing to that particular instance (Show Referring Instances).

show_referring_instances 

Working our way backwards we see that it's the com.sun.jmx.mbeanserver.RepositorySupport holding on to a Hashtable that contains Hastables. We can now select the RepostiorySupport instance and verify that it indeed holds Hastables by bringing up the context menu and selecting "Inspect Instance".

hashtable_found

Summary:

In this example we used the Memory Leak Detector in Mission Control for looking at relations between various types and instances in our running JVM. In this particular case we followed up on where people are putting hashtables into hashtables.

Comments:

Post a Comment:
Comments are closed for this entry.
About

A blog focused on JVM technology and Mission Control

Search

Archives
« February 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
       
       
Today