By default, Sun's Java™ Virtual Machine (JVM) does not produce heapdumps for memory diagnostics. The required steps to enable this functionality (if supported) is dependant on what level of the JVM is installed.
To produce a heapdump in the event of an OutOfMemoryError:
-XX:+HeapDumpOnOutOfMemoryError
Heapdumps can be taken on demand from the new improved jmap tool which uses the built in heapdumper code (unlike the jmap tools in 1.4.2 and 5.0). The histogram option in Java™ 6 also uses a much improved built in mechanism. To manually create a heapdump, use the following command:
jmap -dump:live,format=b,file=
<heapdump_filename> [JVM PID]
To print class histograms, issuing a SIGQUIT - kill -3 [JVM PID] will trigger a class histogram to be written to
native_stdout.log:
-XX:+PrintClassHistogram
To force a heapdump by sending the Java Virtual Machine (JVM) a SIGQUIT - kill -3 [JVM PID]:
-XX:+HeapDumpOnCtrlBreak
To produce a heapdump in the event of an OutOfMemoryError:
-XX:+HeapDumpOnOutOfMemoryError
To print class histograms without using
jmap, issuing a SIGQUIT - kill -3 [JVM PID] will trigger a class histogram to be written to
native_stdout.log:
-XX:+PrintClassHistogram
Note: Manual generation of heapdumps is still not implemented. -XX:+HeapDumpOnCtrlBreak only works on 1.5.0_16 or later.
To produce a heapdump in the event of an OutOfMemoryError:
-XX:+HeapDumpOnOutOfMemoryError
To print class histograms without using
jmap, issuing a SIGQUIT - kill -3 [JVM PID] will trigger a class histogram to be written to
native_stdout.log:
-XX:+PrintClassHistogram
In 1.4.2_12, Sun implemented a built-in heapdump facility, with a new command line option.
To force a heapdump by sending the Java Virtual Machine (JVM) a SIGQUIT - kill -3 [JVM PID]:
-XX:+HeapDumpOnCtrlBreak
To produce a heapdump in the event of an OutOfMemoryError:
-XX:+HeapDumpOnOutOfMemoryError
To print class histograms without using
jmap, issuing a SIGQUIT - kill -3 [JVM PID] will trigger a class histogram to be written to
native_stdout.log:
-XX:+PrintClassHistogram
SDK 1.5.0 GA to 1.5.0_06
SDK 1.4.2_09 to 1.4.2_11 |
Note: Due to limitations using jmap, the most reliable solution for getting a heapdump will be to upgrade the JDK. Click
here for more information.
The
jmap executable is contained in the same directory as the Java executable (for example:
[path to JDK]/bin), and can be run in a number of ways:
The following produces a heapdump in the current working directory, named
heap.bin:
jmap -heap:format=b [JVM PID]
The following produces a heapdump in the same way as the previous command, but from a core file rather than a running process:
jmap -heap:format=b [Java executable] [core file]
The following produces a summary of the state of the heap, including details of the heap configuration (although this frequently seems to be incorrect):
jmap -heap [JVM PID] > heapsummaryfilename
The following walks the heap and produces a list of all object types, sorted by total size:
jmap -histo [JVM PID] > histofilename
The following produces classloader statistics for the permanent generation. Among other things, the results detail the size and number of classes loaded by each classloader:
jmap -permstat [JVM PID] > histofilename
kill -3 [JVM PID] (for example: The same as the trigger for a threaddump):
A thread dump is written to
native_stdout.log, after which you should see text similar to the following:
Dumping heap to java_pid21745.hprof.1146911952593 ...
Heap dump file created [288590804 bytes in 13.043 secs]
The heapdump file is written to the current working directory.
Notes:
The latest SDK and WSAS updates can be found here:
Recommended Fixes for WebSphere Application Server
1. The Heapdumps generated using any of the preceding methods can be processed using the latest version of
HeapAnalyzer.
2. The heapdumps produced are written in the
HPROF binary format and can also be examined using Sun's
HAT tool (or preferably
jhat, included with JDK 6.0).
3. Finally, the built-in heapdumper works for all types of heap apart from the parallel GC - throughput collector (-XX:+UseParallelGC)
Note: Support for the throughput collector is being targeted by Sun for 1.4.2_15, under
Sunbug 6452074
Additional notes on jmap:
Because
jmap attaches to the JVM, the JVM has no control over when the heapdump occurs. Therefore, the heapdumps produced by
jmap can be incomplete or inconsistent. They are also likely to contain "floating garbage" (for example: "dead" objects that will be collected in the next).
Jmap also has severe performance and stability issues. It can take an extremely long time (for example: an hour) to write a heapdump, especially if the object tree is deep and complex (as is often the case for our customers). The dump might fail completely if the heap is larger than approximately 500MB, due to flaws in the design of jmap (is uses a lot of native memory, which can lead to native OutOfMemoryErrors when the process size grows to approximately 4GB).
Finally,
jmap only works for standard heaps. For example, it cannot attach to heaps employing CMS.
For more details:
Change history
Last Updated:18 June 2010
- 18 June 2010: Added WebSphere Application Server 7.0 (Java 6) information.
