Java technology, IBM style: monitoring and judgment issues

Over time, IBM has developed a number of monitoring and troubleshooting facilities for its Java runtime implementations. With these tools, IBM support Teams, Java application developers, and production operators can diagnose and resolve problems encountered in Java development.

This article discusses three major facilities, as they are implemented in the latest version of the IBM implementation of Java technology: The tracking engine, the dump engine, and the DTFJ tool API. They all help Java developers to determine the root cause of the problem.

Tracking engine

Tracking information is a powerful tool when judging software issues: it can be used to effectively study problem scenarios (such as functional errors, competitive States, and performance issues), and it is very helpful in understanding the process of a program.

IBM introduced the tracking engine for the first time in its Java runtime implementation in the SDK 1.2.2 to help the IBM development team diagnose the flaws in the Java Virtual Machine (JVM). The purpose of this tracking facility is to provide a low cost, high-performance, configurable tracking mechanism for the virtual machine itself. In subsequent releases, significant adjustments and improvements were made; The current version of the IBM SDK provides a high-performance engine that captures the JVM, Java Class Libraries (JCL), and trace data from any Java application code deployed to the runtime. Without the need for any other facilities.

Activating and controlling tracing

The tracking engine can be activated and controlled through a variety of mechanisms:

-xtrace by command line options

Using the trace properties file

Using Java code for dynamic control via the Com.ibm.jvm.Trace API

Using Trace Trigger Events

Using a C-based JVM RAS Interface (JVMRI) from an external agent

The primary way to control tracing is to use the command-line option-xtrace, or to use an optional trace property file if the option set is longer or more complex.

The-xtrace option consists of a series of flags or flag-value pairs that determine whether the trace should be written to a stderr, an internal buffer, or a binary file, whether to enable method tracing, JVM tracing, or both, which trace points should be tracked, and to track any modifications to the trace points, or trigger the dump when an event occurs.

Basic knowledge of activating tracing

The first thing to decide when using IBM's tracking facilities is where to direct the trace output. Table 1 briefly describes these destinations and how many trace point data will be sent to it. For example, print directs all trace data to Stderr,minimal to direct the subset of data for each trace point to a memory buffer, and then you can use the output option to capture the data in those buffers to a file.

Table 1. Track destinations

keyword	features
minimal
maximal
count	statistics in the lifetime of the JVM The number of times the selected trace point is called within.
print
iprint
external	to orient the selected trace point to the JVMRI listener.
exception the