WebSphere® Application Server Version 8 Fix Pack 2 ships with IBM® Java 6 R26 on supported operating systems. In this version, the default behavior for OutOfMemory (OOM) exceptions has changed.
By default in IBM Java 5 and later, the first four OOM exceptions for the lifetime of a Java process produce a PHD-formatted heap dump, a Java dump file (javacore), and a snap dump file. By default in IBM Java 6 R26 and later, the first OOM for the lifetime of a Java process produces a PHD-formatted heap dump, a Java dump file, a snap dump file, and an operating system dump—core file on Linux, AIX®, and IBM i (not to be confused with a javacore), user-mode minidump with full memory on Windows operating systems, and SYSTDUMP on z/OS®. The second, third, and fourth OOM exceptions produce only a PHD-formatted heap dump and a Java dump file. Therefore, the change in default behavior is an additional system dump on the first OOM exception.
A system dump is a superset of a PHD heap dump. A system dump also includes memory contents (strings, primitives, variable names, and so on), thread and frame local information, some native memory information, and more. For more information, go to http://www.ibm.com/developerworks/opensource/library/j-memoryanalyzer/index.html. This added information can solve a larger class of problems, provide more general insight into a running JVM, and ultimately reduce the time that it takes to solve a problem. In IBM Java 5 R12 or earlier and IBM Java 6 R9 or earlier, a system dump had to be post-processed using the jextract tool. With recent versions of IBM Java, however, including the one that ships with this new OOM behavior, a system dump can be directly loaded by a DTFJ-capable tool such as the Memory Analyzer Tool without any post-processing for OOMs (just like a PHD heap dump). For crashes, however, jextract should still be used.
# java -version -Xdump:what Registered dump agents ... -Xdump:system: events=systhrow, filter=java/lang/OutOfMemoryError, label=... core.&Y&m&d.&H% M% S.% pid.% seq.dmp, range=1..1, priority=999, request=exclusive+compact+prepwalk ... -Xdump:heap: events=systhrow, filter=java/lang/OutOfMemoryError, label=... heapdump.% Y% m% d.% H% M% S.% pid.% seq.phd, range=1..4, priority=500, request=exclusive+compact+prepwalk, opts=PHD ... -Xdump:java: events=systhrow, filter=java/lang/OutOfMemoryError, label=... javacore.% Y% m% d.% H% M% S.% pid.% seq.txt, range=1..4, priority=400, request=exclusive+preempt ... -Xdump:snap: events=systhrow, filter=java/lang/OutOfMemoryError, label=... Snap.% Y% m% d.% H% M% S.% pid.% seq.trc, range=1..4, priority=300, request=serial
-Xdump:system:file=/var/dumps/core.% Y% m% d.% H% M% S.% pid.% seq.dmp
You might also consider using the -Xdiagnosticscollector generic JVM argument, which will print a warning to native_stderr.log if the JVM detects that ulimits are set incorrectly on startup. For more information, go to http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.diagnostics.60/diag/tools/verifyingyourjavadiagnosticsconfiguration.html