Ric*_*ich 33 java jvm jvm-hotspot jvm-arguments
我正在查看运行Alfresco的JVM配置选项,主要是Alfresco Wiki上的这个文档.其中一个建议是使用JVM标志和.这样做的理由是:-Xcomp-Xbatch
如果您希望Hotspot预编译类,可以添加[-Xcomp和-Xbatch].但是,这将显着增加服务器启动时间,但会突出显示以后可能遇到的缺失依赖项.
从我在其他地方读到的关于-Xcomp和-Xbatch旗帜的内容,我想知道它们是否确实提供了任何好处.
-Xcomp 获得HotSpot以预先编译所有代码并进行最大程度的优化,从而推导出VM将通过系统的标准运行获得的任何分析.-Xbatch停止后台编译,这意味着在编译完成之前导致代码被编译的线程.但是,在编译完成后,先前阻塞的线程将不会运行已编译的代码,它仍将运行解释的代码.这是Java 6(Mustang)的一个变化 - 在Mustang之前,由于-Xbatch标志的存在而被阻止编译的线程一旦编译完成就保证在编译的代码中运行.因此,我猜测-Xbatch标志的推荐是在较旧的VM上运行Alfresco的遗留物.有人有想法吗？我倾向于摆脱这两面旗帜并依靠虚拟机来解决问题.
我想添加两件事,首先是我还没有访问Alfresco实例来测试这个,其次我不知道什么样的机器托管Alfresco而不是通过查看其他配置选项它必须是64位VM.尽管如此,我希望社区将有一些有用的输入,可能来自一般的HotSpot调整观点.
fgl*_*lez 26
一般来说,让HotSpot编译器调整自身总是更好.即使使用服务器VM(-server)也是64位和一些"服务器级"机器的默认设置.
-Xbatch主要用于调试,如Steve Goldman的博客所述:
所以-Xbatch开关即使在野马前也不是特别有用的开关.它对于jvm开发人员来说有点用处,因为它倾向于使运行更具可预测性和可重现性.
-Xcomp删除了收集信息以进行高效编译的功能.来自Alex Turner的帖子:
从性能的角度来看,人们可能会认为-Xcomp是个好主意.但是,它不是!JIT编译器在编译之前使用这1000次迭代来收集有关如何编译方法以获得最佳效率的信息.-Xcomp删除了它的能力,因此我们实际上可以看到性能下滑.
如果没有性能,我从未见过使用这些标志来检测缺少的依赖项(如果某些代码仍然被解释,它可能无法工作)所以恕我直言,我会摆脱两者.
| 归档时间： |
|
| 查看次数： |
9505 次 |
| 最近记录： |