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