在调试模式下运行JVM的副作用 [英] Side Effects of running the JVM in debug mode

问题描述

我想在调试模式下重新启动Java应用程序，以便在客户端发生随机或难以重现的问题时更容易调试。

但是，我想要了解这样做的潜在副作用吗？从Java HotSpot文档来看，似乎应该没有性能罚款。

从链接

全速调试

Java HotSpot VM现在使用
全速调试。在以前的
版本的VM中，当调试启用
时，使用
执行的程序只有解释器。现在，HotSpot
技术的全部
性能优势可用于程序，
甚至编译代码。改进的
性能允许长时间运行的
程序更容易调试。
它还允许测试以
全速进行。一旦有
异常，调试器启动
完全可见的代码源。

这是准确的或者有隐藏的注意事项，使用调试模式时，内存占用量还有其他隐藏的问题。

PS：我发现本文，这证实了我最初的怀疑，原来的oricale文章没有显示完整的故事。

解决方案

我不能说HotSpot，不会正式为IBM，但我会说如果在其中间需要反编译，那么绝对可以合法地进行优化，如果需要在可能使用的生产JVM中进行调试，则不能完全撤消。 p>

想象一下优化器发现的情况该程序的一部分可以证明是不需要的，并且通过各种语言规则（包括JSR 133）是合法的删除，JVM将要摆脱它。一个皱纹是调试：删除代码将看起来是奇怪的人类步进通过它（变量不更新，可能不会停止在行上步进），所以选择是禁用在这些情况下的所述优化。对于像堆栈分配对象等的选择也是如此，所以当JVM说它是全速时，它实际上更接近于几乎全速，一些funkier选择不能被完全撤消 。

I'd like to realease a Java application in debug mode to allow for easier debugging when random or hard to reproduce problems occur on the customer side.

However, I want to get a heads up on potential side effects of doing this? From the Java HotSpot Documentation it seems that there should be no performance penalty.

From the link

Full Speed Debugging

The Java HotSpot VM now uses full-speed debugging. In previous version of the VM, when debugging was enabled, the program executed using only the interpreter. Now, the full performance advantage of HotSpot technology is available to programs, even with compiled code. The improved performance allows long-running programs to be more easily debugged. It also allows testing to proceed at full speed. Once there is an exception, the debugger launches with full visibility to code sources.

Is this accurate or are there hidden caveats, what about memory footprint and are there any other hidden gotchas while using debug mode.

PS: I found this article from AMD which confirmed my initial suspiciion that the original article from oricale doesn't show the full story.

解决方案

I can't speak for HotSpot, and won't officially for IBM, but I will say there are certainly legal kinds of optimization that aren't possible to undo fully should a decompilation be required in the middle of them, and thus aren't enabled when debug is being asked for in the production JVMs you are likely to use.

Imagine a situation where the optimizer discovers a part of the program is provably not required and by the various language rules (including JSR 133) is legal to remove, the JVM will want to get rid of it. The one wrinkle is debug: removing the code will look odd to the human stepping through it (variables not updating, possibly not stopping on lines when stepping) so the choice is to disable said optimizations in those cases. The same might also be true for opts like stack allocated objects, etc.. so while the JVM says it's "full speed" it's actually closer to "nearly full speed, with some of the funkier opts that can't quite be undone removed".

这篇关于在调试模式下运行JVM的副作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！