Sun Java Solaris Communities My SDN Account Join SDN
 
White Paper

The Java HotSpot Virtual Machine, v1.4.1

 

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

Chapter 3
Debugging Support
Overview

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

  • Provide standard interfaces which enable Java 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 or client of an interface can be different than the reference implementation, or different from the JPDA component.

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

Java Virtual Machine Debugger Interface (JVMDI)

The JVMDI describes the functionality provided by a VM 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 (set a breakpoint), and notification (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 that do not adhere to this interface can still provide access via the Java Debug Wire Protocol (JDWP).

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 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 (such as Java technology). 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

Java Debug Interface (JDI)

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

In JPDA, the JDI offers 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 so on) 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, plus 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).

Full Speed Debugging

The Java HotSpot VM now uses full-speed debugging. In previous version of the 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.

HotSwap Class File Replacement

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

HotSwap adds functionality to the JPDA, allowing 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 that has been redefined to be reexecuted.

In the reference implementation, this functionality is implemented at the JVMDI layer and made available through the higher layers of JPDA - the JDWP and the JDI.

VMDeathRequests

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 that 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.

Logging

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 preceded 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]