|  |
HeapRoots
A tool for debugging memory leaks in Java applications through analysis of "heap dumps."
Date Posted: October 23, 2003
|
|
|
|
|
|
Have a look at the start of the "User Interface" documentation page. This will tell you how to load HeapRoots using the example heap dump file supplied in the .zip file. Once you've exhausted the possibilities of these 12 objects, get a heap dump (see IBM JVM Diagnostics Guide on developerWorks) of one of your Java™ apps.
| | |
|
I would suggest running the "ts" command to see what types of objects (for example, 400,000 instances of java/util/HashMap) are using up the most space in the heap. You can use the "os" command to look for any individually big objects (such as an Object[] or int[]) or to look at any objects that interest you. Take a look at the example in the "Dump from Roots" section.
| | |
|
HeapRoots will work on just about any Java VM and operates in virtually the same manner on any platform. Typically it is used on IBM platforms because these are where heap dumps are usually available. See the Links/Resources section in the included documentation.
| | |
|
- 64-bit dumps won't yet work, but then I haven't yet tried to get a 64-bit heap dump either.
- Lack of a GUI.
| | |
|
The processing is only as good as the data given ("GIGO" and all that). Any possible dump is, only at best, a snapshot of the application's state at a single point in execution. This doesn't say anything about the threads and their stacks. Furthermore, since many operations on references and Java objects are happening at any point, the dump will probably not represent a 100%-reliable snapshot of the Java application.
Heapdumps tell you "what;" they don't always tell you "why" or "who" (see below).
| | |
|
The best method is to catch the culprit in the act! For this, HeapRoots is not the tool; you need a profiling/tracing tool. There are many third-party tools available. Please see the "Links" section of the documentation.
Indeed, there is an "experimental" HPROF tool built in to many JVMs; please see the JVMPI section of the IBM JVM Diagnostics Guide.
| | |
|
Currently HeapRoots doesn't offer any kind of mechanism for comparing two dumps (other than running the same commands on each, such as "ts").
Comparing two dumps is really effective if garbage collection runs before each dump, so that each dump contains only live/reachable objects. Then you will be able to see a difference in how much heap is actually in use by the application. This will depend on the JVM; please see the IBM JVM Diagnostics Guide.
You can also look for a suspect data collection and see if it's grown. The data collection (such as a java.util.Vector) may or may not be at the same location in the heap due to compaction or copying of the collection, but it will be at the same location in the reference tree ("d" command).
| | |
|
Try increasing the -Xmx value to give the JVM more memory. Performance will rapidly disintegrate if you allocate more memory than physical memory on your machine. At this point, the solution is to buy more RAM or go and have a long coffee break.
I've got 512 MB and this is OK for good performance with all but the largest dumps from servers that I've seen. Saving the state once parsed is the best thing to do. Also see the section on memory usage in the documentation.
| | |
|
Yes, use ">" or ">>" after the command and arguments. Please see the "User Interface" section in the documentation.
| | |
|
This error is typically caused by a truncated heap dump or invalid heap dump format. You may be given a line number in the heap dump; running with "-v" may give more information. Check for incomplete lines in the dump. The first test should usually be for a correct end-of-file marker (if you've got this on your system): "tail <filename>".
| | |
|
The heap usage is the sum of the sizes of all the objects in the heap dump. So it's the total amount of heap space used. Note: Heap dumps aren't guaranteed to show absolutely everything in the heap.
The total object range is the size in bytes from the start of the first object to the end of the last object. This gives you an idea of the address range of the objects in the heap. Note that, depending on JVM, there may be multiple heaps, or the heap may not be a contiguous block of address space.
| | |
|
A flag is simply an additional piece of object meta-data. If a dump has flags, then it simply stores an extra string against each object. Objects can then be filtered on these flags in the "o" command. The flags are entirely dependant on the JVM that produces the heap dump.
| | |
|
The cause is likely to be a numeric parameter in an invalid format or data range. An example of such input is below:
Enter 0x<addr> to dump from one address or any value for all roots [NONE]
0xabcdefgh
Possible invalid input format : java.lang.NumberFormatException: abcdefgh
(Characters g and h make the given address invalid as a hexadecimal address.)
| | |
|
This may be caused by a JVM defect and I've generally found this to occur only on earlier JVMs. The problem disappears in IBM Windows 32 build cn131-20021102 and later JVMs.
| | |
|
You may get a message such as "stream classdesc serialVersionUID=201 local class serialVersionUID=202", and usually this is caused by loading a saved dump created by one version (here 2.0.1) of HeapRoots in another version (here 2.0.2).
You can use the "save-txt" command on the older version of HeapRoots to create a replica of the heap dump on disk (available from 2.0.5).
| | |
|
Don't worry about this; it won't affect the results. HeapRoots attempts to detect the version of the SDK that produced the heap dump from the dump's header. This isn't 100% accurate and is no longer important for HeapRoot's operation.
| |
|
|
|
|
| |
|
