The Java HotSpot Virtual Machine, v1.4.0 Pg.3

Print-friendly Version

[Table of Contents/Page 1]  [Page 2]  [Page 3]  [Page 4]  [Page 5]  

The Java Platform Debugger Architecture (JPDA) consists of two interfaces (JVMDI and JDI), a protocol (JDWP), and two software components which tie them together (back-end and front-end). The intent is of this architecture is to:

• Provide standard interfaces which enable Java programming language debugging tools to be easily written without regard to platform specifics such as hardware, operating system and virtual machine implementation.

• Describe a complete architecture for implementing these interfaces, including remote and cross-platform debugging.

• Provide a reference implementation of this architecture.

• Provide a highly modular architecture where the implementation and/or client of an interface can be different than the reference implementation or different from the JPDA component.

Figure 3-3: Figure 3: The Java Platform Debugger Architecture Structure

Java Virtual Machine Debugger Interface (JVMDI)

The JVMDI describes the functionality provided by a VM in order to enable debugging of Java programming language applications running under this VM. In the reference implementation of JPDA, JVMDI is implemented by the Java HotSpot VM.

The JVMDI defines the services a VM must provide for debugging. The JVMDI includes requests for information (for example, current stack frame), actions (for example, set a breakpoint), and notification (for example, when a breakpoint has been hit). A debugger may make use of VM information other than this, such as the Java Native Interface (JNI), but the JVMDI is the source of all debugger specific information.

Specifying the VM Interface allows any VM implementor to plug easily into the debugging architecture. It also allows alternate communication channel implementations. VM implementations which do not adhere to this interface can still provide access via the Java Debug Wire Protocol (JDWP).

The JDWP defines the format of information and requests transferred between the process being debugged and the debugger front end, which implements the Java Debug Interface. It does not define the transport mechanism--socket, serial line, shared memory, and so on.

The specification of the protocol allows the process being debugged and debugger front-end to run under separate VM implementations and/or on separate platforms. It also enables the front-end to be written in a language other than Java, or the debuggee to be non-native (e.g. Java). Information and requests are roughly at the level of the JVMDI, but will include additional information and requests necessitated by bandwidth issues, such as information filtering and batching.

In the reference implementation, a module called the back-end runs as an agent of the HotSpot VM and receives JDWP packets from the debugger front end. This back-end code executes the commands it receives over the JDWP, calling into the HotSpot VM via JVMDI when necessary. Results are returned back to the debugger front end via JDWP.

Back to Top

The JDI provides a pure Java programming language interface for debugging Java programming language applications. The JDI is a high level Java API providing functionality that is needed by debuggers and similar systems that need to access and control the state of the virtual machine.

In JPDA, the JDI is a remote view in the debugger process of a virtual machine in the debuggee process. It is implemented by the front-end (above) while a debugger-like application (IDE, debugger, tracer, monitoring tool, and soon) is the client.

The JDI defines information and requests at the user code level. It provides introspective access to a running virtual machine's state, Class, Array, Interface, and primitive types, and instances of those types. The JDI also provides explicit control over a virtual machine's execution. JDI is the highest-layer of the Java Platform Debugger Architecture (JPDA).

The Java HotSpot Client VM now uses "full-speed debugging." In the previous version of the HotSpot VM, when debugging was enabled, the program executed using only the interpreter. Now, the full performance advantage of HotSpot technology is available to programs, even with compiled code. The improved performance allows long running programs to be more easily debugged. It also allows testing to proceed at full speed. Once there is an exception, the debugger launches with full visibility to code sources.

This new feature encapsulates the ability to substitute modified code in a running application through the debugger APIs. For example, one can recompile a single class and replace the old instance with the new instance.

HotSwap adds functionality to the Java Platform Debugger Architecture (JPDA) to allow a class to be updated while under the control of a debugger. The two central components of this functionality are RedefineClasses which replaces the class definitions and PopFrame which pops frames off the stack allowing a method which has been redefined to be re-executed.

In the reference implementation, this functionality is implemented at the Java Virtual Machine Debug Interface (JVMDI) layer and made available through the higher layers of JPDA - the Java Debug Wire Protocol (JDWP) and the Java Debug Interface (JDI).

Using class VMDeathRequest, a request can be made for notification when the target VM terminates. When an enabled VMDeathRequest is satisfied, an EventSet containing a VMDeathEvent will be placed on the EventQueue.

This request would typically be created so that a VMDeathEvent with a suspend policy of SUSPEND_ALL will be sent. This event can be used to assure completion of any processing which requires the VM to be alive (such as event processing). Even without creating a VMDeathRequest, a single unsolicited VMDeathEvent will be sent with a suspend policy of SUSPEND_NONE.

A new logging facility has been added to log garbage collection events from the virtual machine. The new -Xloggc:file option reports on each garbage-collection event, as with -verbose:gc, but logs this data to file. In addition to the information -verbose:gc provides, each reported event is preceeded by the time (in seconds) since the first garbage-collection event.

Back to Top

[Table of Contents/Page 1]  [Page 2]  [Page 3]  [Page 4]  [Page 5]