Home Page
Motivation and Design Goals
Stability
The previous debugger implementation had a number of flaws we wanted to
fix. The most obvious of these was stability. Although the
Java® Development Kit 1.1.3 and 1.1.x fixes helped considerably,
jdb is still prone to deadlock and crashing.
Some amount of such problems are unavoidable because jdb uses
JavaTM programming language code
in-process in the debuggee VM as part of its implementation. To avoid
this, the new debugger
uses only native code in-process. We have chosen to concentrate on a small
feature set for the initial release, to ensure that those features work
reliably.
Features
The initial release targets a small feature set, namely:
-
Breakpoints
-
Single stepping
-
Exception handling
-
Thread and ThreadGroup monitoring/control
-
Examination of individual stack frames
-
Display of final fields, Assignment of non-final fields.
Display and assignment of variables.
-
Notification of class loading
-
Field Watchpoints
-
Method entry and exit events
Later releases may add more functionality, depending on feedback from licensees
and users.
Structure
We wanted to provide an architecture that was adaptable to
almost any conceivable
Java virtual machine (VM) implementation. To do this, we
split the architecture into three parts, each
of which is individually replaceable. They are the Java Virtual Machine
Debug Interface (JVMDI), the Java
Debug Wire Protocol (JDWP), and
the Java Debug Interface (JDI).
The lowest level api is the JVMDI. The JVMDI is intended to be implemented
entirely inside the VM and serves as the in-process access layer to the
VM.
The JDWP is implemented atop the JVMDI, and should be portable across
any VM that implements the JVMDI.
The JDI is implemented atop the JDWP, and it is this API that we expect
debugger implementors to use. The JDI provides high level debugging features,
insulating the user from VM specific idiosyncrasies.
There are several advantages in splitting up the API in this way. By
specifying a minimalistic VM API, we make it easy for new VM implementations
to support JVMDI and thus the JavaTM Platform Debugger Architecture.
Finally, the multi-layer approach allows VM implementors to choose
which level they wish to 'plug in' at. For specialized implementations,
it may be impractical to implement the JVMDI, or even the JDWP. Those VM's
may still provide JDI level access, using some part, or even none, of the
reference implementation.
Requirements for the JVMDI:
-
Must be easily and efficiently implementable across the range of VM types
(interpreters, jits, dynamic, ...) and implementations.
-
Should not overlap existing interfaces (e.g.. JNI).
-
Should be consistent with existing interfaces.
-
Round-trip time to the debugger should be as small as possible in order
to broaden the applicability of the interface.
-
Should provide a reasonable building block for the implementation of an
out-process debugger.
-
Should be as small and simple as possible, while providing standard functionality
and a consistent path to broader functionality.
-
Should not expose or depend-on VM implementation.