JVM 系列之: 从汇编角度分析 NullCheck
简介
之前我们在讲 Virtual call 的时候有提到,virtual call 方法会根据传递的参数实例的不同而进行优化,从而优化成为 classic call,从而提升执行效率。
今天我们考虑一下,在 virtual call 中执行 nullcheck 的时候,如果已经知道传递的参数是非空的。JIT 会对代码进行优化吗?
一起来看看吧。
一个普通的 virtual call
我们来分析一下在方法中调用 list.add 方法的例子:
代码很简单,我们在循环中调用 testMethod 方法,而这个方法里面又调用了 list.get(0)方法,来获取 list 的第一个参数。
单纯的看 testMethod,这个方法是有可能抛出 NullPointerException 的,但是从整体运行的角度来看,因为我们的 list 是有值的, 所以不会抛出异常。
使用 JIT Watcher 看看运行结果:
先看第二个和第三个红框,我们可以看到代码先做了参数类型的比较,然后对 testMethod 进行了优化,这里还可以看到 get 方法是内联到 testMethod 中的。
代码优化的部分我们找到了,那么异常处理呢?如果 list 为空,应该怎么处理异常呢?
第一个红框,大家可以看到是一个隐式的异常处理,它重定向到 1152b4f01 这个地址。
第四个红框就是这地址,表示的是异常处理的代码。
普通方法中的 null check
我们在上面的普通方法里面加上一个 null check:
上面我们添加了一个 list !=null 的判断。
运行看下结果:
相比较而言,我们可以看到,代码其实没有太多的变化,说明 JIT 在代码优化的过程中,将 null check 优化掉了。
那么 null check 到底在什么地方呢? 看我标红的第二个框,这里是之前的异常处理区域,我们可以看到里面有一个 ifnull,表明这里做了 null check。
反优化的例子
上面的两个例子,我们可以看出在 virtual method 中,JIT 对 null check 进行了优化。接下来我们再看一个例子,在这个例子中,我们显示的传递一个 null 给 testMethod,然后再次循环 testMethod,如下所示。
我们看下 JIT 的结果:
看下结果有什么不同呢?
第一,ifnull 现在是显示调用的,并不包含在隐式异常中。
第二,隐式异常也不见了,因为使用显示的 ifnull。
总结
JIT 会根据不同的情况,对代码进行不同程度的优化,希望大家能够喜欢。
本文作者:flydean 程序那些事
本文链接:http://www.flydean.com/jvm-assembly-nullcheck/
本文来源:flydean 的博客
欢迎关注我的公众号:程序那些事,更多精彩等着您!
版权声明: 本文为 InfoQ 作者【程序那些事】的原创文章。
原文链接:【http://xie.infoq.cn/article/541fb0905b9863250e43bfa64】。文章转载请联系作者。
评论