Sun公司的Kohsuke Kawaguchi考察了Hotspot JIT在JDK6 u10 b14 debug版中产生的汇编代码，并将其记录在博客中。该博文着重阐述了Java优化的程度。
Kawaguchi 将重点放在两个主要的地方。首先是循环展开（loop unrolling），它是这样一种技术：复制循环的每次迭代所调用的指令以构成一个序列。通过减少循环中计算机需要执行的指令，节省了执行时间。JIT 将其与预处理和事后分析相结合，同时Kawaguchi对此的补充也说明了这样的事实：编译器已从循环的快速执行部分当中移除了一个冗余的数组索引检查。此外，结果汇编代码证明了特定于处理器的优化程度如何。例如，Kawaguchi谈到了下面的代码：
private static byte[] foo() { byte[] buf = new byte[256]; for( int i=0; i buf[i] = 0; return buf; }
所产生的汇编结果使用了特定于AMD64芯片的R8-R15通用寄存器汇编代码。
其次是围绕着锁（locks）而进行的优化。在Java中非竞态锁的获取在不断地改进，而竞态锁的获取却一直存在问题。这个领域的工作还在持续进行中，但是Kawaguchi的工作却说明了几个已经得到改进的地方。
这篇文章展示了该Hotspot编译器很多其他的特性，包括强大的内联——James Gosling注意到一篇相关的博文中说“甚至连存储分配和初始化都需要内联”。这一层级的侵略性（aggression）是可能存在的，部分原因在于 JVM会在必要时做一些潜在不安全的优化。Charles Nutter在今年初参加Lang.NET大会时曾对此提出了一个很好的解释。他也强调了这项工作与JRuby的关系，以及与任何面向JVM的语言的关系。
“过去JVM有多种不同的能力去动态优化和再优化代码……或许最重要的是必要时的动态“逆优化（deoptimize）”。在处理性能问题时，逆优化（Deoptimization）令人非常兴奋，因为这意味着你可以进行更多的侵略性优化——对整个应用不确定的未来的潜在的不安全的优化——知道你可以在安全的路径上回退。一旦你几次遇到相同的路径，你就可以内联整个调用路径。除非明显需要，你可以忽略同步保护。你还可以在发现问题之后改变使用的优化集……本质上，在运行过程中你可以安全的“出错”并且从错误中学习。这就是为什么在特定的基准上Java超越了C和C++以及最终在几乎所有基准上它都能将超越C和C++的主要原因。同时这也是我们的JRuby与微软的IronPython和DLR相比，只需要做很少的事情就可以获得可接受的性能的一个关键原因。”
从理论上讲，像Java这样的解释型语言的性能很有可能最终将超越编译型语言，因为它可以在运行时基于现有硬件进行优化，同时Java中不断提高的对特定于处理器的优化确实令人非常兴奋。对于面向Java平台的开发者来说，一个额外的好处在于随着新版本 Java编译器的发布，代码的性能会不断改进，而无需对应用的源码做任何更改。
英文原文： http://www.infoq.com/news/2008/05/hotspot_performance
国内最棒的Google Android技术社区（eoeandroid），欢迎访问！
《银河系列原创教程》发布
《Java Web开发速学宝典》出版，欢迎定购
Kawaguchi 将重点放在两个主要的地方。首先是循环展开（loop unrolling），它是这样一种技术：复制循环的每次迭代所调用的指令以构成一个序列。通过减少循环中计算机需要执行的指令，节省了执行时间。JIT 将其与预处理和事后分析相结合，同时Kawaguchi对此的补充也说明了这样的事实：编译器已从循环的快速执行部分当中移除了一个冗余的数组索引检查。此外，结果汇编代码证明了特定于处理器的优化程度如何。例如，Kawaguchi谈到了下面的代码：
private static byte[] foo() { byte[] buf = new byte[256]; for( int i=0; i buf[i] = 0; return buf; }
所产生的汇编结果使用了特定于AMD64芯片的R8-R15通用寄存器汇编代码。
其次是围绕着锁（locks）而进行的优化。在Java中非竞态锁的获取在不断地改进，而竞态锁的获取却一直存在问题。这个领域的工作还在持续进行中，但是Kawaguchi的工作却说明了几个已经得到改进的地方。
这篇文章展示了该Hotspot编译器很多其他的特性，包括强大的内联——James Gosling注意到一篇相关的博文中说“甚至连存储分配和初始化都需要内联”。这一层级的侵略性（aggression）是可能存在的，部分原因在于 JVM会在必要时做一些潜在不安全的优化。Charles Nutter在今年初参加Lang.NET大会时曾对此提出了一个很好的解释。他也强调了这项工作与JRuby的关系，以及与任何面向JVM的语言的关系。
“过去JVM有多种不同的能力去动态优化和再优化代码……或许最重要的是必要时的动态“逆优化（deoptimize）”。在处理性能问题时，逆优化（Deoptimization）令人非常兴奋，因为这意味着你可以进行更多的侵略性优化——对整个应用不确定的未来的潜在的不安全的优化——知道你可以在安全的路径上回退。一旦你几次遇到相同的路径，你就可以内联整个调用路径。除非明显需要，你可以忽略同步保护。你还可以在发现问题之后改变使用的优化集……本质上，在运行过程中你可以安全的“出错”并且从错误中学习。这就是为什么在特定的基准上Java超越了C和C++以及最终在几乎所有基准上它都能将超越C和C++的主要原因。同时这也是我们的JRuby与微软的IronPython和DLR相比，只需要做很少的事情就可以获得可接受的性能的一个关键原因。”
从理论上讲，像Java这样的解释型语言的性能很有可能最终将超越编译型语言，因为它可以在运行时基于现有硬件进行优化，同时Java中不断提高的对特定于处理器的优化确实令人非常兴奋。对于面向Java平台的开发者来说，一个额外的好处在于随着新版本 Java编译器的发布，代码的性能会不断改进，而无需对应用的源码做任何更改。
英文原文： http://www.infoq.com/news/2008/05/hotspot_performance
国内最棒的Google Android技术社区（eoeandroid），欢迎访问！
《银河系列原创教程》发布
《Java Web开发速学宝典》出版，欢迎定购
