How to develop a Debugger?- Introduction to Java Platform Debugger Architecture

If you heard the word ‘Debug’, what will come to your mind. Definitely it will be “ De+bug”. Yes, you are correct.

Debugger is a computer program that used to test and find bugs in other programs/applications. It may use instruction set simulators to stop or halt the program according to specific conditions. Simulators allow a higher level control over programs execution. However, use of simulators reduce execution speed of program.

Let’s see the architecture we use for developing a debugger.

Java Platform Debugger Architecture(JPDA) is multi-tiered debugging architecture that allows developers to create portable debugger applications. In this post, I’ll explore JPDA and how it is structured.

Java Platform Debug Architecture

As I mentioned above, JPDA considered as a multi-tiered debugging architecture. It means JPDA allows tools to create debugger applications which run on different platforms, virtual machines and JDK versions.

JPDA consists of three layers:

1. Java Debug Interface(JDI)
2. Java Debug Wire Protocol(JDWP)
3. Java Virtual Machine Tool Interface(JVM TI)

JPDA provides set of APIs and protocols at these three layers.

These three layers structured as follows.

Let’s move on to more details relevant to three layers of JPDA.

1. Java Debug Interface(JDI)- Among three layers, JDI is the highest layer of the JPDA and it is a pure java interface for debugging processes. A debugger built with JDI can debug applications running in any Java Virtual Machine(JVM) which supports JPDA. It has the ability to access the JVM and its state along with access to variables of the debuggee. At the same time, it allows suspend and resume threads, class loading, set breakpoints, stepping and watch points. JDI implements on the front-end of debugger applications(IDE, Tracer).

JDI has two classes of activity.

• Requests — requests according to queries for information, setting of state changes in remote VM application, setting debugging states.
• Events — act according to the requests.

Requests work as follows.

When user requested to do a task(ex:get value of a local variable ), IDE uses JDI to do the task(get value ). JDI front-end passes the request through communication channel(socket/shared memory) to back-end. JDWP formats this requests into a byte stream and transferred to the back-end. Back-end responses to that requests by releasing the response packet(formatting according to JDWP). Then front-end analyses response packet and return the result(value). After that IDE displays the result.

Events generate as follows.

Back-end set the event handling functions(passing the breakpoints) and sends an event across JVM TI to JDWP socket. Using the command packets that transfer the events to JDI. After taking the events, JDI decodes and processes those events and eventually generate events in the event queue. Finally IDE gets the events by removing from the event queue.

2. Java Virtual Machine Tool Interface(JVM TI)- JVM TI is used to do the communication between the back-end and the debuggee VM. It defines the services that a VM must provide for debugging which include requests for information (ex: current stack frame), actions(ex: set a break point), and notification (ex: when a break point has been hit).

3. Java Debug Wire Protocol(JDWP)- JDWP makes communication between debuggee process and debugger front-end. It means define the format of information, requests transferred between the debuggee(JVM to be debug) and debugger processes. A JDWP implementation can be designed to accept different transport mechanisms through a simple API. Communication starts from the establishment of transport connection. A transport is implemented as a series of functions. Functions relevant to connection management, input/output, error management. Then occurs a handshake between the debugger side and debuggee side.

For the communication between debugger and debuggee(target VM) there should be an established connection and transport. There are two mechanisms to enable the connection and transport implementations to be developed and deployed.

1. Create Service provider interface in the JDI- It enables the Connector and TransportService implementations to be developed and deployed. The TransportService class represents the underlying transport service used by a Connector and is used to establish connections and transport JDWP packets between a debugger and a target VM.
2. Use transport library called “Java Debug Wire Protocol Transport Interface”- This is a native interface to allow the development and deployment of transport libraries. On the target VM there is an agent supporting the JDWP is used to communicate with the debugger. A transport library is loaded by the debuggee-side JDWP agent and is used to establish a connection to the debugger and to transport JDWP packets between the debugger and the VM.

To establish the connection between debugger and target VM, use connectors. Connector is a JDI abstraction. There are several connectors provided by reference implementation which map to the available transport types modes of connection such as attaching, listening and launching.

There are two transport implementations with the reference implementations.

1. Socket transport — Uses TCP/IP connection between the JDI and the target VM. It allows connection between JDI and target VM on different machines. This transport implementation provides for Linux, Solaris and Microsoft Windows platforms.
2. Shared memory — This implementation provides shared memory region for the exchange the JDWP packets. In this case, both target VM and debugger must reside on the same machine. Shared memory transport implementation provides for Microsoft Windows platform.

Transport implementation differ according to use cases.

In this blog post I have described about what is Java Platform Debugger Architecture and the structure of Java Platform Debugger Architecture. When we developing a debugger we’ll follow this architecture. I hope to write about how build a debugger as next blog post.

Reference

https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/architecture.html#jdi