Java 7 的 JVM 比 JRockit 6 慢吗?

5

我对升级到Java 7(出于自己的编码原因)非常感兴趣。然而,我们有些用户对延迟非常敏感(每件事都需要在毫秒级别内完成)。我对3种不同的JVM进行了简单的性能比较测试,并发现Java 7要慢得多。该测试通过我们的应用程序传递了一些简单的消息。这个测试是一个低负载、低容量的测试,每隔几秒钟就会推送一条单一的消息。结果如下(以微秒为单位):

 - Hotspot 6 (build 24): msgs= 23 avg= 902 
 - JRockit 6 (R28 b 29): msgs= 23 avg= 481 
 - Hotspot 7 (build 04): msgs= 34 avg=1130

Oracle的策略是从Java 7开始合并JRockit和Hotspot(因此JRockit 6是最后一个可用版本)。有人知道为什么性能会差那么多吗?(需要注意的一点是,代码是在Java 1.6下编译的。不确定是否可以解释这个问题...)
更新:我投票关闭了自己的问题,因为我可以从评论中看出我没有足够的信息来使这个问题变得有建设性。感谢所有评论过的人。
更新:根据更多的反馈,我想提供更多的信息。测试总是在重新启动后进行。每次测试所有因素都相等。唯一改变的是JVM。重复多次测试结果一致。任何测试迭代中都没有发生GC。
以下是其中一个测试运行的图形化值。对于JRockit和Hotspot 7,第一个延迟值被抛弃。JRockit有一个巨大的第一个值,但很快优化并趋向于平均值。Hotspot 7需要更长时间来优化,并且从未降至像JRockit那样低的平均值。每个数据点表示从TCP/IP套接字读取消息、通过业务逻辑运行并将消息写入另一个套接字所需的微秒数。每条消息都是相同的,没有进入任何新的代码路径。

3
有没有像“-server”这样的JVM标志?Java 7不太可能慢到那个地步。您确定遵守了JVM微基准测试规则吗? - Petr Janeček
2
你的测试中有进行过垃圾回收吗?我相信 Java 7 默认使用不同的算法。即时编译器(JIT)是否同时出现?JVM 是否以相同的方式预热?等等。 - assylias
1
平均值不是这种工作的好指标,你需要一系列的值(平均值、中位数、90/95/99百分位数、最大值),这样你才能真正看清发生了什么。20-30个值也不多。因此,我认为这看起来很可疑,肯定需要调查(如果你有一个亚毫用户社区),但你的方法首先需要改进。 - Matt
1
@SamGoldberg JRockit没有与Java7合并。 Java7基本上是带有一些新功能和一些改进的Java6。其中一些可能对您有好处,而其他一些则不会。就我听到的两个团队而言,Oracle主要试图将JRockit的仪器特性引入热点(向前推进),因此我不会期望Oracle JVM "像JRockit一样快速",仅仅因为它们进行了合并。正如其他人所指出的那样,您需要提供更多信息才能得出良好的猜测。您对我们的代码,预热甚至获取时间戳的方式毫无头绪。 - Fredrik
1
@SamGoldberg,为什么不发一个样本基准测试来给出数据,而不是让问题关闭呢?对于我们大多数人来说,找出问题所在会相当有趣。 - Fredrik
显示剩余16条评论
2个回答

11
JRockit是一种与OpenJDK不同的纯C代码库,它包含不同的垃圾收集器和完全不同的JIT编译器。在BEA拥有它时,一个重要的盈利点是低延迟GC,即使在非商业版本中也相当先进。JRockit已经花费了大量时间作为干净的vm实现。正如评论中所说,这不是合并的问题,而是在HotSpot代码库中重新实现的问题。这远非快速过程,有些事情可能根本无法到达那里,至少不会以它们的JRockit形式出现。可以说,谜题的碎片不能轻易地契合,需要进行一些边缘修整。 JDK7 Hotspot将擅长于其他方面,或者类似系统的不同版本,但这可能会弥补一些性能损失。其他应用程序可能比JRockit 6运行得更快。
如果您想了解更多关于JRockit(或任何JVM)内部的信息,强烈推荐阅读《Oracle JRockit权威指南》一书。全面披露,我可能会因每一本书获得约2美元的版税并用它来购买浓缩咖啡。 :)

我从2010年的Oracle博客文章中获取了有关Hotspot7的信息,其中写道:“我们所做的绝大部分JVM工作都将进入OpenJDK(包括来自JRockit的所有性能特性)”。进一步阅读使人感觉将JRockit集成到OpenJDK中是策略 - Sam Goldberg

5
这个问题的主要焦点是,在所有其他条件相同的情况下(包括JVM参数),为什么使用Hotspot 7 JVM的相同Java代码JAR文件运行速度比JRockit 6和Hotspot 6慢得多。这引起了一些回应,涉及到是否正确进行了计时(显然由于人们对JVM之间可能存在如此不同的结果持怀疑态度)。根据众多测试,我毫不怀疑测量结果的准确性。
可能的答案有:
- Java 7 JVM不能像在Java 6下编译的同样的代码那样快速运行。 - 需要新的JVM参数才能使Java 7以最优化的模式运行。 - 其他人已经将Java 7与JRockit 6进行了基准测试,并看到了与我相同的结果。
因此,事实是,新的Java 7 JVM行为与我们的应用程序非常不同,在所有其他条件相同的情况下。唯一的解决办法是针对Java 7 VM对代码进行分析,以发现代码中的慢点。(也许在那时,Java 6 JVM和Java 7 JVM之间的实际差异就会变得清晰明了。)
我感谢每个人的评论,并为没有提供足够的细节进行清晰的分析/解决而道歉。

据我回忆,Java 7 的主要性能版本是从r41开始的。Java 7 发布版本中的大部分变化都与性能有关,因此看看后来的版本是否发生了反转会很有趣。 - Chaffers

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接