JRockit读书笔记I ― Java代码的高效执行

《OracleJRockit:TheDefinitiveGuide》一书是由OracleJRockit的两位资深开发人员写的，其中的MarcusHirt更是JRockitMissionControl的leader，这本书详细的对OracleJRockit进行了介绍，最突出的特点非常系统化的介绍了一个JVM通常是如何实现的，而JRockit这样一个极为优秀的JVM又是做了哪些优化，为什么做这些优化，这本书对于对JVM感兴趣的同学而言应该是必读的一本书，其实即使对于JVM兴趣不强的同学，里面的优化思路的介绍也是值得学习，本系列的blog主要是总结看这本书得到的一些收获，由于书中知识量巨大，因此得分成多篇blog来总结了。

书的第二章为：AdaptiveCodeGeneration，在这章中作者向我们讲解了一个优秀的JVM是如何来实现代码的高效执行的，感兴趣的同学其实可以在不看下面blog内容之前，先考虑下如果是你做的话，你会怎么做来实现Java代码的高效执行呢，然后再对比下这章的内容，我想你能学到很多的，:)

用过Java的同学都知道，Java是通过javac将Java源码编译为class文件，然后通过ClassLoader装载此class文件，之后就可执行此class了，要最高效的执行这个class，最好的方法莫过于class文件直接就是机器码，这样直接执行就可以了，但Java是跨平台的，因此class文件就不能是机器码了。

由于class文件不是直接的机器码，要执行它最简单的方法就是采用纯粹的解释方式，解释方式由于每次都得将class文件中的指令翻译为对应的机器环境的指令，效率是很低的。

为了能更高效的执行，同时又保持跨平台的特性，另外一个方法就是在执行class时再将其翻译为对应的机器码，这个方法是比较靠谱的，因此无论是Hotspot、还是JRockit，都采用了这种方式，也就是大家熟知的JIT(JustInTime)Compiler。

OK，既然觉得在装载class后翻译成机器码去执行可以比较高效，那这个时候又会出现两种状况，是执行class的时候就立刻翻译成机器码，还是先用解释模式执行，然后到一定时机再翻译成机器码呢，之所以出现这两种状况，原因在于将class翻译为机器码是需要消耗时间的，因此如果执行class的时候就立刻翻译成机器码的话，也就会导致Java程序启动速度会比较慢，JRockit是这么认为的，JRockit的服务对象是server级应用，这类应用的特点是没那么在乎启动速度，而更在乎的是执行时的高效，而且如果执行的时候就立刻翻译成机器码的话，就意味着压根不需要实现解释器，因此JRockit采取的方法是在执行class时直接编译为机器码，而Hotspot由于需要同时支持client和server应用，对于client应用而言，启动速度非常重要，因此Hotspot采用的是先解释执行，到了一定时机后再翻译成机器码。

如果认为就这样就完成了Java代码的执行的实现，那就太小看JVM了，由于JVM能够知道代码运行的全部状况，自然还可以做出更多更出色的提升代码执行速度的优化，例如标量替换、更好的inline等，后面再来细说，因此这样就出现了一个状况，什么时候对哪些代码来做这些更猛的优化呢。

真正值得做更猛的优化的代码自然是所谓的”热点”代码，如何来发现哪些代码是热点代码呢，通常有三种方法：
1、方法调用计数器
方法调用计数器是常见的方式，hotspot采用的即为这种，这种方式不好的地方就在于计数器本身经常是cpucachemisses的，因此稍微会有点影响性能。
2、对线程进行采样
可采用软件或硬件方式来实现，软件方式实现不好的地方在于采样的时候需要暂停线程，好处是因为是采样，不需要对所有方法进行计数，硬件方式自然是最好的，但不是所有的硬件都支持的，支持的硬件中最典型的是intelIA-64的CPU。

在有了发现热点代码的方法后，接下来需要做的就是更猛的优化，有很多种，例如Java的代码中，通常会是接口方式的调用，但因为是接口方式的调用，所以其实默认情况下是不好做inline处理的，但JVM为了更高效的执行代码，如发现这代码为热点代码，那么就会做一些激进的优化，例如会假设这个接口只有一个实现，然后就可以直接将此实现对应的代码inline进来了（至于为什么inline后效率更高，这个请参考编译原理之类的书），这些激进优化同样适合于if、抛异常这些状况，当然，当激进优化的条件失效时，就会逆优化回到之前基本编译的代码。
而其他的更猛的优化还包括根据线程执行路径进行逃逸分析等，后面再专门写一篇blog来讲解下一些翻译为机器码的优化吧，其实大多都是编译原理的一些东西。

书中在介绍JRockit如何实现自己的JITCompiler时，提到了Bytecode混淆以及bytecode优化，JRockit的态度是bytecode混淆时将name进行混淆是靠谱的，但如果对controlflow进行混淆，就不太好了，因为这有可能会导致jitcompile时的有些优化也做不了了，而bytecode优化，JRockit的态度是应该避免，因为没什么太大的意义，更主要的优化还是得靠jitcompiler。

JRockit的JITCompiler的实现和Hotspot另外一个很大的不同在于JRockit并未采用on-stackreplacement，据JRockit的研究，这个没有太大必要，当然，对于编写benchmark代码时则要注意这个不同。

JITCompiler在compile时还需要考虑的几个重点问题：
1、为GC提供必要的信息；
2、为查错提供必要的信息，例如代码的行数、变量名等；

从这章的内容可以看到，JRockit为了能够让Java代码能够高效的执行，是做出了非常多的努力的，也可以看到很多JRockit与Hotspot不同的地方，甚至可以看出Java代码的执行比C代码的执行高效都是有可能的，:)。