动态反优化(deoptimization)

许多标准的优化只能在“基本块”内执行，所以内联方法调用对于达到好的 优化通常很重要。通过内联方法调用，不仅方法调用的开支被清除，而且给优化 器提供了更大的优化块可以优化，会带来相当大的死代码优化机会。

清单 2 显示了一个通过内联实现的这类优化的示例。outer() 方法用参数 null 调用 inner()，结果是 inner() 什么也不做。但是通过把 inner() 的调 用内联，编译器可以发现 inner() 的 else 分支是死的，因此能够把测试和 else 分支优化掉，在某种程度上，它甚至能把整个对 inner() 的调用全优化掉 。如果 inner() 没有被内联，那么这个优化是不可能发生的。

清单 2. 内联如何带来更好的死代码优化

public class Inline { 　 public final void inner(String s) { 　　 if (s == null) 　　　 return; 　　 else { 　　　 // do something really complicated 　　 } 　 } 　 public void outer() { 　　 String s=null; 　　 inner(s); 　 } }

但是不方便的是，虚方法对内联造成了障碍，而虚函数调用在 Java 中要比 在 C++ 中普遍。假设编译器正试图优化以下代码中对 doSomething() 的调用：

　Foo foo = getFoo(); 　 foo.doSomething();

从这个代码片断中，编译器没有必要分清要执行哪个版本的 doSomething() —— 是在类 Foo 中实现的版本，还是在 Foo 的子类中实现的版本？只在少数 情况下答案才明显 —— 例如 Foo 是 final 的，或者 doSomething() 在 Foo 中被定义为 final 方法 —— 但是在多数情况下，编译器不得不猜测。对于每 次只编译一个类的静态编译器，我们很幸运。但是动态编译器可以使用全局信息 进行更好的决策。假设有一个还没有装入的类，它扩展了应用程序中的 Foo。现 在的情景更像是 doSomething() 是 Foo 中的 final 方法 —— 编译器可以把 虚方法调用转换成一个直接分配（已经是个改进了），而且，还可以内联 doSomething()。（把虚方法调用转换成直接方法调用，叫做 单形 (monomorphic)调用变换。)

请稍等 —— 类可以动态装入。如果编译器进行了这样的优化，然后装入了 一个扩展了 Foo 的类，会发生什么？更糟的是，如果这是在工厂方法 getFoo() 内进行的会怎么样？ getFoo() 会返回新的 Foo 子类的实例？那么，生成的代 码不就无效了么？对，是无效了。但是 JVM 能指出这个错误，并根据目前无效 的假设，取消生成的代码，并恢复解释（或者重新编译不正确的代码路径）。

结果就是，编译器要进行主动的内联决策，才能得到更高的性能，然后当这 些决策依据的假设不再有效时，就会收回这些决策。实际上，这个优化如此有效 ，以致于给那些不被覆盖的方法添加 final 关键字（一种性能技巧，在以前的 文章中建议过）对于提高实际性能没有太大作用。

Java理论与实践: 动态编译与性能测量(5)

奇怪的结果

清单 3 中包含一个代码模式，其中组合了不恰当的预热、单形调用变换以及 反优化，因此生成的结果毫无意义，而且容易被误解：

清单 3. 测试程序的结果被单形调用变换和后续的反优化歪曲

public class StupidMathTest { 　　 public interface Operator { 　　　　 public double operate(double d); 　　 } 　　 public static class SimpleAdder implements Operator { 　　　　 public double operate(double d) { 　　　　　　 return d + 1.0; 　　　　 } 　　 } 　　 public static class DoubleAdder implements Operator { 　　　　 public double operate(doubl

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!