hha*_*fez 23 debugging jvm release-management
我想在调试模式下重新发布Java应用程序,以便在客户端随机或难以重现问题时更容易调试.
但是,我想要了解这样做的潜在副作用？从Java HotSpot文档中可以看出,应该没有性能损失.
从链接
全速调试
Java HotSpot VM现在使用全速调试.在以前版本的VM中,启用调试时,程序仅使用解释程序执行.现在,即使使用已编译的代码,HotSpot技术的全部性能优势也可用于程序.性能的提高使得长时间运行的程序更容易调试.它还允许测试以全速进行.一旦出现异常,调试器就会启动代码源的完全可见性.
这是准确的还是有隐藏的警告,内存占用情况如何,使用调试模式时还有其他隐藏的问题.
PS:我发现AMD的这篇文章证实了我最初的怀疑,即oricale的原始文章没有显示完整的故事.
Tre*_*ald 16
我不能代表HotSpot,并且不会正式代表IBM,但我会说,如果在它们中间需要反编译,那么肯定有合法的优化是不可能完全撤消的,因此不是'在您可能使用的生产JVM中要求调试时启用.
想象一下,优化器发现程序的一部分可能不是必需的情况,并且各种语言规则(包括JSR 133)合法删除,JVM将希望摆脱它.一个问题是调试:删除代码看起来很奇怪人类踩过它(变量没有更新,可能不会在步进时停在行上)所以选择是在这些情况下禁用所述优化.对于像堆栈分配的对象等opts也是如此.所以当JVM说它是"全速"时,它实际上更接近"几乎全速,一些无法完全删除的有趣的选择" .
这个问题很老，但在我搜索任何性能影响时出现，如果您只是将 -agentlib:jdwp... 打开但没有积极调试。
总结：从调试选项开始但不连接现在应该不会影响速度（Java 7+）。
在 java 6 (ish) 之前，您使用了 -Xdebug，这产生了一定的影响，它关闭了 JIT！
在 java 6 中，他们将其更改为 -agentlib 并使其更好。有一些错误虽然确实导致了性能损失。这是针对 openjdk 提交的错误之一，我的猜测是 oracle/sun 版本存在类似问题：https : //bugs.openjdk.java.net/browse/JDK-6902182
但是请注意，声明的目标是通过打开端口来启用调试不会导致任何性能损失。
看起来，至少在 openjdk 中，这些错误已被 Java 7 清除。在那之后我没有看到任何有关性能影响的信息。
如果您进一步研究并发现负面结果，请注意进行测试的 Java 版本——我看到的所有内容都指的是 7 之前的版本。
我很想知道是否有人在最近的 VM 中遇到性能问题，只是让端口处于启用状态。