FAQ

Back to Contents

FAQ

Getting Started - using sample file

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'.

Once you've exhausted the possibilities of these 12 objects, get a heap dump (see IBM Java SDK Diagnostics Guides on developerWorks) of one of your Java apps.

This is all very nice, but I've got a real dump, what should I do first ?

I would suggest running the 'ts' command to see what types of objects (e.g. 400,000 instance of 'java/util/HashMap') are using up the most space in the (JVM garbage collected) heap. You can use the 'os' command to look for any individually big objects (like an Object[] or int[]) or to look at any objects which interest you.

Take a look at the example in the 'Dump from Roots' section.

What platforms does HeapRoots/Heap dump work on?

HeapRoots will work on just about any Java VM and operates virtually the same on any platform. Typically it is used on IBM platforms because these are where 'Heap dumps' are usually available. See the Links/Resources section.

What are the limitations of HeapRoots

64bit dumps won't yet work, but then I haven't yet tried to get a 64bit heap dump either.
Lack of GUI.

What are the limitations of Heapdumps ?

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.

What is creating all of these objects ?

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 3rd party tools available. See the Links section of the documentation.

Indeed, there is an "experimental" HPROF tool built-in to many JVM's - see the JVMPI section of the IBM Java SDK Diagnostics Guides.

How can I compare two dumps to track a leak ?

Currently HeapRoots doesn't offer any kind of mechanism to compare 2 dumps (other than running the same commands on each ,e.g. try '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 see a difference in how much heap is actually in use by the application. This will depend on the JVM - see the IBM Java SDK Diagnostics Guides.

You can also look for a suspect data collection and see if it's grown. The data collection (e.g. 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 will be at the same location in the reference tree ('d' command).

Out Of Memory / java.lang.OutOfMemoryError

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 512mb and this is okay 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.

Can I redirect output to a file ?

Yes, use '>' or '>>' after the command and arguments. See the 'User Interface' section in the documentation.

Exception while Loading heapdump / StringIndexOutOfBoundsException

Typically caused by a truncated heap dump or invalid heap dump format. You may get given a line number in the heap dump and/or running with '-v' may give more information. Check for incomplete lines in the dump. First test would usually be for a correct End-Of-File marker (if you've got this on your system) 'tail <filename>'.

What's the difference between 'Heap usage' and 'Total object range' ?

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 - n.b. 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.

What are dump 'flags' ?

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.

Invalid parameter / java.lang.NumberFormatException

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)

Loading a saved state - 'java.lang.ClassNotFoundException: int'

This may be caused by a JVM defect and I've generally found this to occur only on earlier JVM's. The problem disappears in 'IBM Windows 32 build cn131-20021102' and later JVM's.

Could not load file state 'hd.txt.sgz' :java.io.InvalidClassException

You may get a message like: 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 (available from 2.0.5) on the old version of HeapRoots to create a replica of the heap dump on disk to load into the newer version.

Incorrect Java version number reported while parsing dump

e.g. generated by Java VM 'IBM 1.2.2' or VM 'Unknown'

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.

Top