|
Replies:
4
-
Last Post:
Jun 12, 2007 2:35 PM
by: smoov
|
|
|
|
|
|
|
Memory leak analysis with Jhat
Posted:
Apr 30, 2007 6:54 AM
|
|
|
I've been using the new jmap+jhat Java 6 tools for heap analysis, which I've found to be a massive step improvement over UI-based memory profilers for memory leak analysis.
For an overview of this see:
http://weblogs.java.net/blog/jfarcand/archive/2006/02/using_mustangs.html for an overview
and
http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/tooldescr.html#gblfj
One query I always want to do, which I've been unable to figure out, is to find out which object instance(s) is the memory leak, when all I know is that process memory is going up over time.
So when you have a huge tree of objects (say 4000 non-system classes and a 500mb heap), some of which are valid (the "valid subtree"), and some of which should be available for garbage collection but aren't (the "invalid subtree"), I want to find out which object is the guilty party.
The "guilty" object, in the chain of strong references to the root, is the link between the valid subtree and the invalid subtree. (I'm sure "tree" is incorrect terminology here)
The way I do this at present is to guess a class that might take up a lot of memory, find the instances of this class, and for each, find the chain of references to the root. I follow it up until I see the reference that shouldn't still exist (e.g. an event listener that should have been removed).
But what if I can't think of the object that is taking up a lot of space? What if I just know that the process memory usage is going up over time? Or what if there's a memory leak which takes a long time to build up?
What I really want to do is find out, for each strongly-reachable object X in the heap, the set (sub-tree) of objects Y that depend on object X. These Y would be eligible for GC if X became only weakly reachable.
Then I want to find out how much memory Y consume. Then I want to sort by this, and look at the largest ones. This would give me a simple way of identifying the problematic areas. I could also compare two heaps (old and new).
Is this possible? Or am I missing a better way of analysing a memory leak?
I have experimented with using OQL in JHAT. For example, if I have identified MyClass objects tend to take up a lot of memory, I might look for leaking references to MyClass objects using:
select o from instanceof com.xyz.MyClass myObject
where length(heap.livepaths(myObject))>0
But this only helps if I have an idea what objects are taking up most of the space in the heap. If I don't, this doesn't help. Also this won't help find small memory leaks, the sort that just creep up slowly over a long period of time. Also these sorts of query take a prohibitive amount of time (read "forever") to execute.
According to the linked article, you can find the instance count by class using
http://localhost:7000/showInstanceCounts/includePlatform/
- but this would not work because no individual class is known to have a large number of instances; instead, a collection of objects are the memory leak, and it is the overall size of those objects that I want to see.
|
|
|
|
|
|
|
Re: Memory leak analysis with Jhat
Posted:
May 1, 2007 3:31 PM
in response to: mrsteve
|
|
|
You might want to look at the NetBeans Profiler, especially the Surviving Generations metrics. http://www.netbeans.org/kb/articles/nb-profiler-uncoveringleaks_pt1.html
But if you really don't like those UI based profilers as you said, then with jhat you can compare a baseline heap dump to a later heap dump file with the following syntax: jhat -baseline <file1> <file2>
This will at least give you a smaller haystack to search through.
One shortcut technique I've used is to also create text along with the default binary dump files. Use the text file to search for OBJ or ARR references with large "sz=n," signatures. This is easy when the object references are large compared to the rest of the heap, otherwise, you might end up with a number of possible unintentional object retentions to investigate. Take the information you found here by hand and then fire up a jhat baseline comparison to get more information about the references.
Also, not sure if it is documented or not, but I got a considerable increase in performance from jhat by adding the following arg to the command line: -J-XX:MaxDirectMemorySize=<size>
Set size a little larger than the heap file you are working with, for example 700MB binary dump file, set size to '1g'.
Good luck,
-Ken
|
|
|
|
|
|
|
|
|
|
|
|
Re: Memory leak analysis with Jhat
Posted:
Jun 12, 2007 2:35 PM
in response to: vedranlerenc
|
|
|
Bravo to the SAP Memory Analyzer team. I downloaded it and opened a 2GB heap dump on 32-bit Windows (not possible with Jhat) within minutes.
Also, the tool was exceedingly easy to use and quickly exposed an object retention problem we had been struggling to find. Thanks!
|
|
|
|
|
java.net RSS
