Using HAT on NetBeansAuthor: Petr Nejedly, NetBeans
$Revision: 188.8.131.52 $
Document History:available in CVS
Note: Some easier ways how to generate heap dump are described in User's FAQ about OOME.
Combination of the hprof JVM profiler and the Heap Analysis Tool can be very helpfull for tracking memory issues. I'll try to outline several NetBeans specific use cases in this short article. A short generic HAT guide can be found here
Warning: JDK 1.4 and JDK 1.4.1 contains a bug in hprof. You cannot use these versions with HAT.
1. Tracking an unknown memory leakSometimes you get a report that the IDE have eaten up all the available memory and started throwing OutOfMemoryErrors. Sometimes you, while running with the memory toolbar on, realize that too much heap is consumed. In that situation you have to find the steps that raise the heap usage and perform them under the instrumented JVM. Because reproduction of the steps may be more complicated or the amount of work involved nontrivial, we need to not slow down the instrumented JVM too much. In this case I use the following command to start the NetBeans in the instrumented JVM:
runide.sh -J-Xrunhprof:heap=dump,format=b,file=nb.hprof,depth=0,doe=n -J-Dnetbeans.debug.heap=trueThe instrumentation will slow the IDE down about 5 times so you should be still able to work with it reasonably.
With such an IDE you can do the steps needed to exploit the memory leak
and when you're done, send the java process a SIGQUIT (Like when invoking
a thread dump, Ctrl+\ on unices, Ctrl-Break on Windows). Don't forget to
force several GC cycles before making a snapshot, the snapshot will contain
unreachable objects otherwise and it will only distract your focus.
The java process will show the thread dump and save the content of the memory
nb.hprof file. It takes a while thus I've disabled
the dump on exit (
doe=n) to have a possibility of a fast yet
clean exit of the tested NetBeans. You can also make more snapshots in one session
using SIGQUIT several times.
disables caches (such that are believed not to cause leaks) simplifying references graph analysis.
The tax for having quite fast VM during instrumentation is "
The hprof is able to log the methods where the memory was allocated but we're
turning this feature off.
When you have the snapshot, you can fed it to the HAT:
hat -stack=false nb.hprofThe HAT will start a webserver at localhost:7000 where you can walk the instances and the references between them. One of the key views is the "Instance Count" view reachable at localhost:7000/showInstanceCounts/. There you can look for suspicious things like too many FileObjects, DataObjects, strange Component subclass instances and so on, but you'll need a bit of experience how should the normal state look like.
To help you with this, you can use a difference between two snapshots. You can create one snapshot before you'll provoke the leak and another one after the leak has shown. You can then start the HAT using:
hat -stack=false -baseline=nb.hprof:1 nb.hprof:2The Instance Count view will get another column showing the count of the newly created instances of the class. You can then use the "N new" link to see which instances are new and inspect who is referencing them, like localhost:7000/newInstances/org.openide.filesystems.AbstractFileObject to see newly created AbstractFileObject instances.
Setting up and using the memory toolbar:
To enable the memory toolbar, right click in the toolbar area
and check the "Memory" checkbox.
You'll get an additional toolbar consisting of memory indicator
and a Garbage Collect button.|
The memory indicator's tooltip shows actual size of the heap and its usage. If you click on the indicator, it will place a mark of the actual usage so you can use it for visual comparisons.
The Garbage Collect button spawns a single