System dumps, often known as core dumps, are platform-specific and contain a raw binary dump of the process memory. This type of dump has a complete copy of the Java heap, including the contents of all Java objects in the application.
Obtaining system dumps
System dumps are produced in response to specific events. To discover which events generate a dump, run the
-Xdump:what command. The following output captures the information shown for a system dump:
-Xdump:system: events=gpf+abort+traceassert+corruptcache, label=/home/user/core.%Y%m%d.%H%M%S.%pid.%seq.dmp, range=1..0, priority=999, request=serial
This output shows that events such as a general protection fault (gpf) or native
abort() call can trigger a system dump. For more information about controlling the behavior of dump agents, see Dump agents.
Enabling a full system dump (AIX, Linux, and macOS)
If you require a system dump that contains details of all the native threads that are running, you must change the resource limits for your operating system. Otherwise, the native thread details that are stored in the dump are only for the native thread that was running when the VM ended.
Set the system resource limits by running the following commands:
ulimit -c unlimited; ulimit -n unlimited; ulimit -d unlimited; ulimit -f unlimited;
-csets core files
-nsets the number of open files
-dsets the data limit
-fsets the file limit
- For AIX systems, use the system management interface tool (SMIT) to enable a full CORE dump that is not a pre-430 style CORE dump. You can also set this configuration with the following command line option:
chdev -l sys0 -a fullcore='true' -a pre430core='false'
Analyzing a system dump
If you want to use MAT to analyze your system dump, you must install the Diagnostic Tool Framework for Java (DTFJ) plugin in the Eclipse IDE. Select the following menu items:
Help > Install New Software > Work with "IBM Diagnostic Tool Framework for Java" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java