Java VM调整-Xbatch和-Xcomp

裘光启

2023-03-14

问题内容：

我正在查看用于运行Alfresco的JVM配置选项，主要是Alfresco
Wiki
上的此文档。建议之一是使用JVM标志和。这样做的理由是：-Xcomp``-Xbatch

如果希望Hotspot预编译这些类，则可以添加[-Xcomp和-
Xbatch]。但是，这将显着增加服务器的启动时间，但会突出显示缺少的依赖关系，这些依赖关系可在以后找到。

从我在其他地方阅读过的有关-Xcomp和-Xbatch标志的信息，我想知道它们是否真的提供了任何好处。

-Xcomp 使HotSpot能够以最大的优化事先编译所有代码，从而避免了VM将通过系统的标准运行进行的任何分析。
-Xbatch停止后台编译，这意味着导致代码被编译的线程阻塞，直到编译完成。但是，在编译完成之后，先前阻塞的线程 将不会运行已编译的代码 ，而是仍将运行已解释的代码。这是Java 6（Mustang）的一个变化–在Mustang之前，-Xbatch确保在存在编译标志的情况下，由于存在标志而被阻塞的线程可以在已编译的代码中运行。因此，我猜测该-Xbatch标志的建议是在较旧的VM上运行Alfresco的遗留物。

有人有想法吗？我的倾向是摆脱这两个标志，并依靠VM来使事情变得正确。

我想补充两点，首先，我还没有访问Alfresco实例的能力，其次，除了查看其他设备，我真的不知道托管Alfresco的计算机规格是什么。配置选项，它必须是64位VM。尽管如此，我还是希望社区能够从HotSpot总体调整的角度获得一些有用的意见。

问题答案：

一般来说，让HotSpot编译器自行调整总是可取的。对于64位和某些“服务器级”计算机，甚至默认使用服务器VM（-server）。

-Xbatch主要用于调试，如您所指出的Steve Goldman的博客所述：

因此-Xbatch开关即使在穆斯林时代之前也不是特别有用的开关。对于jvm开发人员而言，它有些有用，因为它会使运行更加可预测和可重复。

-Xcomp删除了收集信息以进行有效编译的能力。从Alex Turner的帖子中：

从性能的角度来看，可能有人认为-
Xcomp是一个好主意。但是，事实并非如此！JIT编译器在编译之前使用了这1000次迭代来收集有关应如何编译该方法以获得最佳效率的信息。-Xcomp删除了这样做的能力，因此我们实际上可以看到性能下降。

没有性能考虑，我从来没有见过使用这些标志来检测丢失的依赖项（如果仍然解释了某些代码，它可能行不通），所以恕我直言，我会摆脱这两种情况。