JVM编译优化技术：数组边界检查消除。

客官°小女子只卖身不卖艺 2022-01-31 14:37 381阅读 0赞

***语言相关的经典优化技术之一：数组范围检查消除。***

数组边界检查消除（Array Bounds Checking Elimination）是即时编译器中的一项语言相关的经典优化技术。我们知道Java语言是一门动态安全的语言，对数组的读写访问也不像C、C++那样在本质上是裸指针操作。如果有一个数组foo\[\]，在Java语言中访问数组元素foo\[i\]的时候系统将会自动进行上下文的范围检查，即检查i必须满足>=0&&i<foo.length这个条件，否则将抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。这对软件开发者来说是一件很好的事情，即使程序员没有专门编写防御代码，也可以避免大部分的溢出攻击。但是对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码，这无疑也是一种性能负担。  
无论如何，为了安全，数组边界检查肯定是必须做的，但数组边界检查是不是必须在运行期间一次不漏的检查则是可以“商量”的事情。例如下面这个简单的情况：数组下标是一个常量，如foo\[3\]，只要在编译器根据数据流分析来确定foo.length的值，并判断下标“3”没有越界，执行的时候就无需判断了。更加常见的情况是数组访问发生在循环之中，并且使用循环变量来进行数组访问，如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间\[0, fo.length\]之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作。  
将这个数组边界检查的例子放在更高的角度来看，大量的安全检查令编写Java程序比编写C/C++程序容易的多，如数组越界会得到ArrayIndexOutOfBoundsException异常，空指针访问会得到NullPointException，除数为零会得到ArithmeticException等，在C/C++程序中出现类似的问题，一不小心就会出现Segment Fault信号或者Window编程中常见的“xxx内存不能为Read/Write”之类的提示，处理不好程序就直接崩溃退出了。但这些安全检查也导致了相同的程序，Java要比C/C++做更多的事情（各种检查判断），这些事情就成为一种隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提到编译器完成的思路之外，另外还有一种避免思路——隐式异常处理，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()），这样当foo不为空的时候，对value的访问是不会额外消耗一次对foo判空的开销的。代价就是当foo真的为空时，必须转入到异常处理器中恢复并抛出NullPointException异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢。当foo极少为空的时候，隐式异常优化是值得的，但假如foo经常为空的话，这样的优化反而会让程序更慢，还好HotSpot虚拟机足够“聪明”，它会根据运行期收集到的Profile信息自动选择最优方案。