Java VM调整-Xbatch和-Xcomp
我正在查看用于运行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删除了这样做的能力，因此我们实际上可以看到性能下降。
没有性能考虑，我从来没有见过使用这些标志来检测丢失的依赖项（如果仍然解释了某些代码，它可能行不通），所以恕我直言，我会摆脱这两种情况。
以上是 Java VM调整-Xbatch和-Xcomp 的全部内容， 来源链接： utcz.com/qa/422702.html
