[TechNote] Getting Heapdumps on the Solaris platform

Getting Heapdumps on the Solaris platform

Technote (troubleshooting)

Problem(Abstract)

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.

Resolving the problem

SDK 1.6.0
SDK 1.5.0_16 or later
SDK 1.5.0_07 to 1.5.0_15
SDK 1.5.0 GA to 1.5.0_06
SDK 1.4.2_12 or later
SDK 1.4.2_09 to 1.4.2_11

Where to add JVM Arguments

1.6.0

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

Back to top

SDK 1.5.0_16 or later

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

Back to top

SDK 1.5.0_07 to 1.5.0_15

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

Back to top

SDK 1.4.2_12 or later

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

Back to top

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'sHAT 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:

• Document serviceability fixes in 1.4.2_09 release notes on sun.com
• jmap - Memory Map man page on sun.com

Back to top

Change history
Last Updated:18 June 2010

• 18 June 2010: Added WebSphere Application Server 7.0 (Java 6) information.