编译器优化技术-公共子表达式消除和数组边界检查消除

编译器优化技术-公共子表达式消除和数组边界检查消除

公共子表达式消除

  公共子表达式消除是- -项非常经典的、普遍应用于各种编译器的优化技术，它的含义是： 如果一个表达式E之前已经被计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就称为公共子表达式。
  对于这种表达式，没有必要花时间再对它重新进行计算，只需要直接用前面计算过的表达式结果代替E。如果这种优化仅限于程序基本块内，便可称为局部公共子表达式消除( Local Common SubexpressionElimination ), 如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除 ( Global Common Subexpression Elimination )。 下面举个简单的例子来说明它的优化过程，假设存在如下代码：

int d = ( c * b ) * 12 + a + ( a + b * c )

  如果这段代码交给 Javac 编译器则不会进行优化，那么生成的代码将如下所示：

iload_2        // b
imul           // 计算 b * c
bipush 12      // 推入 12
imul           // 计算 ( c * b ) * 12
iload_1        // a
iadd           // 计算 ( c * b ) * 12 + a
iload_1        // a
iload_2        // b
iload_3        // c
imul           // 计算 b * c
iadd           // 计算 a + b * c
iadd           // 计算 ( c * b ) * 12 + a + a + b * c
istore 4

是完全按照遵照 Java 源码的写法直译而成的。

  当这段代码进人虚拟机即时编译器后，它将进行如下优化：编译器检测到 c * b 与 b * c 是一样的表达式， 而且在计算期间 b 与 c 的值是不变的。
因此这条表达式就可能被视为:

int d = E * 12 + a + ( a + E );

  这时候、编译器还可能(取决于哪种虚拟机的编译器以及具体的上下文而定)进行另外一种优化——代数化简 (Algebraic Simplification) ， 在E本来就有乘法运算的前提下， 把表达式变为:

int d = E * 13 + a + a;

表达式进行变换之后，再计算起来就可以节省一些时间了。

数组边界检查消除

  数组边界检查消除 ( Array Bounds Checking Elimination) 是即时编译器中的一项语言相关的经典优化技术。我们知道Java语言是一门动态安全的语言，对数组的读写访问也不像 C、C++ 那样实质上就是裸指针操作。如果有一个数组 foo[]，在Java语言中访问数组元素 foo[i] 的时候系统将会自动进行上下界的范围检查，即 i 必须满足 " i >= 0 && i < foo.length " 的访问条件，否则将抛出一个运行时异常: java.lang.ArrayIndexOutOfBondsException。这对软件开发者来说是一件很友好的事情，即使程序员没有专门编写防御代码，也能够避免大多数的溢出攻击。但是对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码，这必定是一种性能负担。

  无论如何，为了安全，数组边界检查肯定是要做的，但数组边界检查是不是必须在运行期间一次不漏地进行则是可以 “商量” 的事情。例如下面这个简单的情况: 数组下标是一个常量，如 foo[3]，只要在编译期根据数据流分析来确定 foo.length 的值，并判断下标 “3” 没有越界，执行的时候就无须判断了。更加常见的情况是，数组访问发生在循环之中，并且使用循环变量来进行数组的访问。如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间 [ 0，foo.length ) 之内，那么在循环中就可以把整个数组的上下界检查消除掉，这可以节省很多次的条件判断操作。

  把这个数组边界检查的例子放在更高的视角来看，大量的安全检查使编写 Java 程序比编写 C 和 C++ 程序容易了很多，比如: 数组越界会得到ArrayIndexOutfBoundsExcepion 异常；空指针访问会得到 NullPointExceptioen 异常；除数为零会得到 ArithmeticExceptinon 异常…在和C++程序中出现类似的问题，一个不小心就会出现 Segment Fault 信号或者 Windows 编程中常见的 “XXX内存不能为 Read/Write” 之类的提示，处理不好程序就直接崩溃退出了。但这些安全检查也导致出现相同的程序，从而使 Java 比 C 和 C++ 要做更多的事情(各种检查判断)，这些事情就会导致一些隐式开销， 如果不处理好它们，就很可能成为一项 “ Java语言天生就比较慢” 的原罪。为了消除这些隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提前到编译期完成的思路之外、还有一种避开的处理思路——隐式异常处理， Java中空指针检查和算术运算中除数为零的检查都采用了这种方案。举个例子，程序中访问一个对象(假设对象叫 foo )的某个属性(假设属性叫 value )，那以 Java 伪代码来表示虚拟机访问 foo.value 的过程为:

if (foo != null) {
	return foo.value;
}else{
	throw new NullPointException();
}

在使用隐式异常优化之后，虚拟机会把上面的伪代码所表示的访问过程变为如下伪代码:

try{
	return foo.value;
} catch (segment_fault) {
	uncommon_ trap();
}

  虚拟机会注册一个 Segment Fault 信号的异常处理器 ( 伪代码中的uncommon_trap()，务必注意这里是指进程层面的异常处理器，并非真的 Java 的 try-catch 语句的异常处理器)，这样当 foo 不为空的时候，对 value 的访问是不会有任何额外对 foo 判空的开销的，而代价就是当 foo 真的为空时，必须转到异常处理器中恢复中断并抛出 NullPointException 异常。进人异常处理器的过程涉及进程从用户态转到内核态中处理的过程，结束后会再回到用户态，速度远比一次判空检查要慢得多。当 foo 极少为空的时候，隐式异常优化是值得的，但假如 foo 经常为空，这样的优化反而会让程序更慢。幸好 HotSpot 虚拟机足够聪明，它会根据运行期收集到的性能监控信息自动选择最合适的方案。