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

问题描述

我想在调试模式下发布一个 Java 应用程序，以便在客户端出现随机或难以重现的问题时更轻松地进行调试.

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.

但是，我想了解一下这样做的潜在副作用?从 Java HotSpot 文档看来，应该没有性能损失.

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.

来自链接

全速调试

Java HotSpot VM 现在使用全速调试.在以前VM 的版本，调试时启用，程序使用执行只有口译员.现在，全HotSpot 的性能优势技术可用于程序，即使使用已编译的代码.改进的性能允许长时间运行程序更容易调试.它还允许测试在全速.一旦有一个异常，调试器启动对代码源的完全可见性.

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:我发现 这篇文章来自 AMD，它证实了我最初的怀疑，即来自 oricale 的原始文章没有显示完整的故事.

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

推荐答案

我不能代表 HotSpot，也不会正式代表 IBM，但我会说肯定有合法的优化类型是不可能的如果在它们中间需要反编译，则完全撤消，因此在您可能使用的生产 JVM 中要求调试时不会启用.

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.

假设优化器发现程序的一部分可证明是不需要的，并且根据各种语言规则(包括 JSR 133)可以合法删除，JVM 会想要摆脱它.一个问题是调试:删除代码对于单步执行的人来说看起来很奇怪(变量不更新，单步执行时可能不会在线停止)，因此选择是在这些情况下禁用所述优化.对于诸如堆栈分配对象等选项也是如此.因此，虽然 JVM 说它是全速"，但实际上更接近几乎全速，一些无法完全撤消的更时髦的选项被删除".

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屋！