Java 7 Update 1的性能和稳定性测试

发表于:2011-12-28来源:未知作者:娃娃点击数: 标签:java
Oracle于10月18日发布了Java 7 Update 1,给Java 7 带来了迫切需要增强的稳定性,并且修复了我们以前报道过的HotSpot编译器的性能优化问题,这个问题偶尔会导致错误结果甚至导致SIGSEV崩溃。JDK 6 Update 29在使用不推荐用于生产服务器的参数XX:+AggressiveOp

  Oracle于10月18日发布了Java 7 Update 1,给Java 7 带来了迫切需要增强的稳定性,并且修复了我们以前报道过的HotSpot编译器的性能优化问题,这个问题偶尔会导致错误结果甚至导致SIGSEV崩溃。JDK 6 Update 29在使用不推荐用于生产服务器的参数XX:+AggressiveOpts或者-XX:+OptimizeStringConcat时,也存在相同的问题,这在此次更新中也得到了修复。

  在Java HotSpot虚拟机性能增强文档中,Oracle 描述了其他一些与性能相关的特性。这份简短的文档只包含一项改进:-XX:+TieredCompilation。

  分层编译在早先编译器的混合模式行为上增加了额外的一步。服务器会先对JVM分级,然后Java 7才会在解释模式下运行代码。然后代码只会在“热”的时候才被编译和优化,并被HotSpot VM标记,比如说有较高的执行次数。解释模式无论如何都比运行编译后的代码慢很多。-XX:+TieredCompilation让虚拟机可以在已经运行编译后代码的同时,收集用于优化的统计信息。

  尽管这项改变可能会减少高动态性系统的预热时间,其中节点会不断地与服务器连接,但是它带来的改进并不十分明显,就像桌面或者applet程序的启动没那么重要一样。

  以下列出的针对JVM 7的改进对于Java 6都已经生效:

  Compressed Oops自Java 6 Update 14有效,自Update 23成为默认设置(仅64位)

  Escape Analysis自Java 6 Update 14有效,自Update 23成为默认设置

  非统一内存访问垃圾回收(Non Uniform Memory Access Garbage Collection)自Java 6 Update 2有效

  Compressed Oops会为64位地址的JVM节省内存。JVM将使用更简短的地址来引用与堆起点相关的对象,而不是从操作系统获得64位内存地址。由于减少了对象引用的内存使用,大多数程序都会受益于这项特性。

  Escape Analysis会查明新分配内存的对象是否要“脱离”当前方法的作用域。如果不是那样,那么该对象就可能会被分配在方法栈上,甚至同步可能会被移除(锁省略)。Heinz Kabutz就该项优化的效果有一篇全面的文章。

  非统一内存访问垃圾回收是一项很有意义的改进,其实已经存在很长一段时间了。在现代内存架构中,有一些内存区比别的内存区的读写操作快。特别是在多核系统中,有些内存是专为个体CPU保留的。感兴趣的读者可以从Ulrich Drepper优秀的文章中更多地了解这些内存区。JVM将尝试在执行分配内存线程的核所使用的内存中分配对象的内存。该性能改进要求很高(特别是在Solaris机器上),但是-XX:+UseNUMA选项从来都不是默认的。

  随着大部分改进在Java 6 Updates上可用(乃至成为默认项),Java 7由于性能方面的原因依然没有吸引我们升级的亮点。

原文转自:http://www.ltesting.net