IBM User Guide for Java V7 on Windows > Troubleshooting and support > Using diagnostic tools > Tracing Java applications and the JVM
Default tracing
By default, the equivalent of the following trace command line is always available in the JVM:
-Xtrace:maximal=all{level1},exception=j9mm{gclogger}The data generated by those tracepoints is continuously captured in wrapping, per thread memory buffers. (For information about specific options, see Detailed descriptions of trace options.)
You can find tracepoint information in the following diagnostics data:
- System memory dumps, extracted by using jdmpview.
- Snap traces, generated when the JVM encounters a problem or an output file is specified. Using dump agents describes more ways to create a snap trace.
- For exception trace only, in Javadumps.
Default memory management tracing
The default trace options are designed to ensure that Javadumps always contain a record of the most recent memory management history, regardless of how much work the JVM has performed since the garbage collection cycle was last called.
The exception=j9mm{gclogger} clause of the default trace set specifies that a history of garbage collection cycles that have occurred in the JVM is continuously recorded. The gclogger group of tracepoints in the j9mm component constitutes a set of tracepoints that record a snapshot of each garbage collection cycle. These tracepoints are recorded in their own separate buffer, called the exception buffer. The effect is that the tracepoints are not overwritten by the higher frequency tracepoints of the JVM.
The GC History section of the Javadump is based on the information in the exception buffer. If a garbage collection cycle has occurred in a traced JVM, the Javadump probably contains a GC History section.
Default assertion tracing
The JVM includes assertions, implemented as special trace points. By default, internal assertions are detected and diagnostics logs are produced to help assess the error.
Assertion failures often indicate a serious problem, and the JVM usually stops immediately. Send a service request to IBM, including the standard error output and any diagnostic files that are produced.
When an assertion trace point is reached, a message like the following output is produced on the standard error stream:
16:43:48.671 0x10a4800 j9vm.209 * ** ASSERTION FAILED ** at jniinv.c:251: ((javaVM == ((void *)0)))This error stream is followed with information about the diagnostic logs produced:
JVMDUMP007I JVM Requesting System Dump using 'core.20060426.124348.976.dmp' JVMDUMP010I System Dump written to core.20060426.124348.976.dmp JVMDUMP007I JVM Requesting Snap Dump using 'Snap0001.20060426.124648.976.trc' JVMDUMP010I Snap Dump written to Snap0001.20060426.124648.976.trcAssertions are special trace points. They can be enabled or disabled by using the standard trace command-line options. See Controlling the trace for more details.
Assertion failures might occur early during JVM startup, before trace is enabled. In this case, the assert message has a different format, and is not prefixed by a timestamp or thread ID. For example:
** ASSERTION FAILED ** j9vmutil.15 at thrinfo.c:371 Assert_VMUtil_true(( publicFlags & 0x200))Assertion failures that occur early during startup cannot be disabled. These failures do not produce diagnostic dumps, and do not cause the JVM to stop.
Parent: Tracing Java applications and the JVM
Error 404 - Not Found Error 404 - Not Found
The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.