IBM Support

Getting Heapdumps on the Solaris platform

Troubleshooting


Problem

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.8.0
SDK 1.7.0
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 or higher
To produce a heapdump in the event of an OutOfMemoryError:
-XX:+HeapDumpOnOutOfMemoryError

Heapdumps can be taken on demand by using the jmap tool, which uses the built in heapdumper code (unlike the jmap tools in 1.4.2 and 5.0). 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




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



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




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





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.

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Out of Memory","Platform":[{"code":"PF027","label":"Solaris"}],"Version":"9.0;8.5.5;8.5;8.0;7.0","Edition":"Network Deployment","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSNVBF","label":"Runtimes for Java Technology"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Java SDK","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
15 June 2018

UID

swg21242314