blocks|key|943186|text|Java的调试架构称为JPDA。您可能想要阅读JPDA+documentation。具体地说，Walk-through+section给出了一个集成开发环境与JDI接口以获取堆栈上的值的示例。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|943187|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/javase/technologies/core/toolsapis/jpda/index.jsp|1|http://download.oracle.com/javase/6/docs/technotes/guides/jpda/jpda.html#walk-through^0|S|D|0|1B|K|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

Java's debugging architecture is called JPDA. You probably want to read the JPDA <a href="http://java.sun.com/javase/technologies/core/toolsapis/jpda/index.jsp" rel="noreferrer">documentation</a>. In particular, the <a href="http://download.oracle.com/javase/6/docs/technotes/guides/jpda/jpda.html#walk-through" rel="noreferrer">Walk-through section</a> gives an example of an IDE interfacing with the JDI to obtain a value on the stack.

blocks|key|943266|text|Eclipse调试从所谓的代理开始。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|943267|运行编译后的".class“源代码的JVM有一个特性，允许在运行时将外部库(用Java或C%2B%2B编写)注入到JVM中。这些外部库称为代理，它们能够修改已运行的.class文件的内容。这些代理可以访问JVM的功能，这些功能不能从运行在JVM中的常规Java代码中访问，它们可以用来做一些有趣的事情，如注入和修改运行的源代码，分析等。一些工具，如JRebel(用于代码的热替换)利用这些功能来实现它们的魔力。|943268|要将代理库传递给JVM，您可以通过启动参数，使用-|943269|agentlib:libname[=options]|code-block|syntax|javascript|943270|我们实际上将一个名为jdwp的代理库传递给运行Tomcat的JVM。jdwp是特定于JVM的JDWP+(Java+Debug+Wire+Protocol)的可选实现，用于定义调试器和正在运行的JVM之间的通信。它的实现(如果存在)以jdwp.so或jdwp.dll的形式作为JVM虚拟机的本地库提供|943271|那么它能做什么呢？简而言之，我们传递的jdwp代理基本上是作为运行应用程序的JVM实例和调试器(可以位于远程或本地)之间的链接。由于它是一个代理库，因此它确实能够拦截正在运行的代码，在JVM和调试器之间创建一座桥梁，并在JVM上应用调试器的功能。由于在JVM体系结构中，调试功能不是在JVM本身内找到的，而是被抽象到外部工具(恰当地称为调试器)中，这些工具可以驻留在运行被调试的JVM的本地机器上，或者从外部机器运行。正是这种解耦的、模块化的体系结构使我们能够让JVM在远程机器上运行并使用JDWP，让远程调试器能够与其通信。|943272|简而言之，这就是Eclipse调试器的工作方式。|943273|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Eclipse debugging starts with what is referred to as Agents.

The JVM, which runs the complied ".class" sources has a feature that allows external libraries (written in Java or C++) to be injected into the JVM, during runtime. These external libraries are referred to as Agents and they have the ability to modify the content of the .class files been run. These Agents have access to functionality of the JVM that is not accessible from within a regular Java code running inside the JVM and they can be used to do interesting stuff like injecting and modify the running source code, profiling etc. Some tools like JRebel(used for hot replacement of code) makes use of this piece of functionality to achieve their magic.

And to pass an Agent Lib to a JVM, you do so via start up arguments, using the -

<pre><code>agentlib:libname[=options]
</code></pre>

We were actually passing an Agent Lib named jdwp to the JVM running Tomcat. The jdwp is a JVM specific, optional implementation of the JDWP (Java Debug Wire Protocol) that is used for defining communication between a debugger and a running JVM. It’s implementation, if present is supplied as a native library of the JVM as either jdwp.so or jdwp.dll

So what does it do? In simple terms, the jdwp agent we pass is basically serving the function of being a link between the JVM instance running an application and a Debugger (which can be located either remote or local). Since it is an Agent Library, It does have the ability to intercept the running code, create a bridge between the JVM and a debugger, and have the functionality of a debugger applied on the JVM. Since in the JVM architecture, the debugging functionality is not found within the JVM itself but is abstracted away into external tools (that are aptly referred to as debuggers), these tools can either reside on the local machine running the JVM being debugged or be run from am external machine. It is this de-coupled, modular architecture that allows us to have a JVM running on a remote machine and using the JDWP, have a remote debugger be able to communicate with it.

That is how Eclipse debugger works in short.

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

My assumption: It is done through a JVM feature where the running process is downloading/using the source-code from the attached remote-debugger (like IDE) It knows the line of the current stack-trace and then can jump to the respective IDE breakpoint. The communication of stack-trace and introspection of the application state is then done either through sockets or shared-memory (setting of remote debugger).

Has anybody interesting links/resources on that?

Java remote debugging, how does it work technically?

集成开发环境

远程调试

虚拟机

调试器

Eclipse

Java

我真的很喜欢JVM的远程调试功能。但我想知道它是如何在内部工作的。我的假设是:它是通过JVM特性完成的，其中运行的进程正在从附加的远程调试器(如IDE)下载/使用源代码，它知道当前堆栈跟踪的行，然后可以跳到相应的IDE断点。然后，通过套接字或共享内存(设置远程调试器)完成堆栈跟踪和应用程序状态自省的通信。有没有人有感兴...

问Java远程调试，它在技术上是如何工作的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java远程调试，它在技术上是如何工作的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java远程调试，它在技术上是如何工作的？
EN