Throughout the code that makes up the JVM, there are numerous tracepoints. Each tracepoint maps to a unique id consisting of the name of the component containing the tracepoint, followed by a period (".") and then the numeric identifier of the tracepoint.
These tracepoints are also recorded in two .dat files (TraceFormat.dat and J9TraceFormat.dat) that are shipped with the JRE and the trace formatter uses these files to convert compressed trace points into readable form.
JVM developers and Service can use the two .dat files to enable formulation of trace point ids and ranges for use under -Xtrace when tracking down problems. The next sample taken from the top of TraceFormat.dat, which illustrates how this mechanism works:
The first line of the .dat file is an internal version number. Following the version number is a line for each tracepoint. Trace point j9bcu.0 maps to Trc_BCU_VMInitStages_Event1 for example and j9bcu.2 maps to Trc_BCU_internalDefineClass_Exit.
<component> <t> <o> <l> <e> <symbol> <template>where:
14:10:42.717*0x41508a00 j9bcu.0 - Trace engine initialized for module j9dynThe example given is fairly trivial. However, the use of tpnid ranges and the formatted parameters contained in most trace entries provides a very powerful problem debugging mechanism.
The .dat files contain a list of all the tracepoints ordered by component, then sequentially numbered from 0. The full tracepoint id is included in all formatted output of a tracepoint; For example, tracing to the console or formatted binary trace.
The format of trace entries and the contents of the .dat files are subject to change without notice. However, the version number should guarantee a particular format.