Java remote debugging, how does it work technically?

Question

I really like the remote JVM debugging tools. But I wonder how it works internally.

My guess: this is done using a JVM function in which a running process downloads / uses source code from a connected remote debugger (like an IDE). He knows the line of the current stack trace and then can go to the corresponding IDE breakpoint. The transfer of the stack trace and introspection of the application state is performed either through sockets or shared memory (setting up a remote debugger).

Does anyone have any interesting links / resources?

Answer 1

JVM debugging features are provided through the Java Debugger Architecture (JPDA) .

JPDA itself consists of the following:

• The Java Virtual Machine Interface (JVM TI) is a proprietary programming interface for using tools. This interface allows state verification and helps control the flow of execution within the debuggee.
• Java Debug Wire Protocol (JDWP) - used to determine the relationship between the debugger and debuggee processes.
• Java Debug Interface (JDI) - This interface allows tool developers to write remote debugger applications.

The diagram in the JPDA architecture structure is a good starting point. Additional places to search will be the guides listed on the JPDA page .

Answer 2

The Java debugging architecture is called JPDA. You will probably want to read the JPDA documentation. In particular, the Walkthrough section gives an example of an IDE interface with JDI to get the value on the stack.

Answer 3

Eclipse debugging begins with what is called an agent.

The JVM, which runs subordinate ".class" sources, has a function that allows you to insert external libraries (written in Java or C ++) into the JVM at run time. These external libraries are called agents, and they have the ability to modify the contents of .class files. These agents have access to JVM functionality that is not available from regular Java code running inside the JVM, and they can be used to create interesting things, such as injecting and modifying source code, profiling, etc. Some tools, such as JRebel (used for hot-swapping code) use this functionality to achieve their magic.

And to pass Lib Lib to the JVM, you do this with start arguments, using

agentlib:libname[=options] 

We actually passed the Lib agent named jdwp to the JVM working with Tomcat. Jdwp is a specific JVM, an optional implementation of JDWP (Java Debug Wire Protocol), which is used to determine the relationship between the debugger and the running JVM. Its implementation, if present, is provided as a native JVM library like jdwp.so or jdwp.dll

And what is he doing? Simply put, the jdwp agent we pass in mainly serves as a communication function between the JVM instance that launches the application and the debugger (which can be located either remotely or locally). Since this is an agent library, it has the ability to intercept running code, create a bridge between the JVM and the debugger, and use the functionality of the debugger applied to the JVM. Since in the JVM architecture the debugging functionality is not found in the JVM itself, but is distracted by external tools (which are called debuggers), these tools can either be located on the local machine where the JVM is debugged, or it can be started from am by the external machine. It is this unrelated modular architecture that allows us to have a JVM running on a remote machine and using JDWP, to have a remote debugger that can communicate with it.

Thus, the Eclipse debugger works shorter.