JDWP and JDI

JVM TI - Java VM Tool Interface Defines the debugging services a JVM provides. JDWP - Java Debug Wire Protocol Defines the communication between debuggee and debugger processes. JDI - Java Debug Interface Defines a high-level Java language interface which tool developers can easily use to write remote debugger applications.

the modern JDWP agent was embeded in JVM since 1999, java 1.2.2, nearly twenty years ago, with minor changes to support languange features in each java versions, it is developed using c++ languange and it supports transporting data using sockets and shared memories. It has nearly 90 commands each of them is designed to fullfill a very simple task, for example: get the thread name for a specifed thread id. JDI is a serries of interfaces and JDK has also a standard implementation of it, eclipse has also another implementation of it, using JDI, you are free of constructing JDWP requests and decoding JDWP reponses. You might not know that the JDWP agent is single threaded with a request buffer and a repsonse buffer, both the JDI implementations are using sync mode because async is not invented by the the time, that means each JDWP command will need to wait for the response of previous request even when there is no depenceny between them. Sync mode and fragmented request/response make the major latency issue of java remote debugging over the internet.

                /    |--------------|
               /     |     JVM      |
 target   ----(      |--------------|  <------- JVM TI - Java JVM Tool Interface
               \     |   back-end   |
                \    |--------------|
                /           |
 comm channel -(            |  <--------------- JDWP - Java Debug Wire Protocol
                \           |
                     |--------------|
                     | front-end    |
                     |--------------|  <------- JDI - Java Debug Interface
                     |      UI      |
                     |--------------|

J2SE 1.2.2 Cricket 蟋蟀 1999-07-08
J2SE 1.3 Kestrel 美洲红隼 2000-05-08
J2SE 1.3.1 Ladybird 瓢虫 2001-05-17
J2SE 1.4.0 Merlin 灰背隼 2002-02-13
J2SE 1.4.1 grasshopper 蚱蜢 2002-09-16
J2SE 1.4.2 Mantis 螳螂 2003-06-26
J2SE 5.0 (1.5.0) Tiger 老虎 2004-10
J2SE 6.0 (Beta) Mustang 野马 2006-04

On the contrary, the node.js and c# debug protocol has polished the debug protocol for remote debugging, and we have proven vscode protocol is more efficient to fullfill debug needs. Let me give a comparasion of these two protocols using a typical spring boot application on four typical scenarios.

Case 1: set on breakpoint

Case 2: threads

Case 3: get stack trace

Case 4: evaluation on 'this.hashCode()'

As a conclusion, the overall JDWP request/response numbers is over 50 times as vscode, the overall JDWP request/response body is 3 times as vsocde, producing overy 40 times of lentency of each operation. The solution is to replace the JDWP protocol over the internet with vscode protocol. In order to archive this, we make a minior change on the archecture diagram, we move the debug core module which is to comunicate with JVM from local to the remote container or vm where the JVM runs at, we call it debug agent server, we also use a agent client at local to communicate with debug agent server using vscode debug protocol.

Now let me demo the debug experience using debug agent. I have setup a spring boot application, set a breakpoint, now let me start the debug session, we can see that the breakpoint is hit, step over and over, we can see that the operation can be completed in less than 1 seconds.

Problems

1. We need to brand new a debug server supporting this archetecture. Because one vscode debug operation like set breakpoint also needs to interact with JDT language server and local project file by debug provider described before, it is hard to have one debug server which supports both local debug and agent debug.
2. We cannot easily implement evaluation and HCR, because the evaluation/hcr provider needs the project support to generate java bytecode instructions, so it cannot be moved to remote together with debug core, it requires us to extends vscode protocol for transport java bytecode instructions. All reasons above will result in a huge change to our code, then why we cannot move the entire debug server to remote? That is because the debug server depends on JDT language server for project support, if we move all debug server to remote, we also need to setup the project remote the same as the local ones, which means your project in remote must have the exact same path as your local machine, and you cannot move/rename your local project, the jdk version and location must be same too and the third-party librairies.