Java 7 JVM比JRockit 6慢？
Sam*_*erg 4 java performance jrockit
我对升级到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套接字读取消息,运行业务逻辑以及在另一个套接字上写入消息的微秒.每条消息都是相同的,并且没有为任何消息输入新的代码路径.
Mar*_*cus 10
JRockit是它自己的(纯C)代码库,不同于OpenJDK.它包含不同的垃圾收集器,以及完全不同的JIT编译器.BEA拥有的一个大型货币供应商是低延迟GC,即使在非商业版本中也是如此.JRockit花费了大量时间作为一个洁净室vm实现.正如在评论中所说的那样,并不是在HotSpot代码库中重新实现内容的合并问题.这是远离一个快速的过程和一些事情在他们的JRockit的形式在所有那里,至少在他们的.如果没有一些锉边缘,拼图块就不容易贴合,可以这么说.JDK7 Hotspot,擅长其他东西,或类似系统的不同版本,但这可能会弥补你失去的一些性能.其他应用程序可能比JRockit 6运行得更快.
如果您有兴趣了解有关JRockit(或任何JVM)内部的更多信息,那么强烈推荐阅读"Oracle JRockit权威指南"一书.完全披露,我可能会在每个版税的版税中获得约2美元,并将用它来购买浓缩咖啡.:)
这个问题的主要内容是,所有其他条件相同(包括JVM args)为什么使用Hotspot 7 JVM时,相同的JAR Java代码运行速度比使用JRockit 6和Hotspot 6要慢得多.
这引起了一些关注时间是否正确完成的反应(显然是由于人们怀疑JVM之间确实会有这样不同的结果).基于众多测试,我认为测量结果是正确的.
我认为可能的答案是:
- Java 7 JVM不会像在Java 7下编译的代码一样快地运行在Java 6下编译的代码
- Java 7需要新的JVM args才能在大多数优化模式下运行
- 其他人已经针对JRockit 6对Java 7进行了基准测试,并且看到了与我相同的结果
事实上,新的Java 7 JVM行为与我们的应用程序非常不同,所有其他条件都相同.唯一的解决方案是针对Java 7 VM分析代码,以发现代码中慢点的位置.(也许在那时,很清楚Java 6 JVM和Java 7 JVM之间的实际差异是什么).
我感谢大家的评论,并对我无法提供足够详细的清晰分析/解决方案表示歉意.
| 归档时间： |
|
| 查看次数： |
6374 次 |
| 最近记录： |