JVM系列之:JIT中的Virtual Call
简介
什么是Virtual Call?Virtual Call在java中的实现是怎么样的?Virtual Call在JIT中有没有优化?
所有的答案看完这篇文章就明白了。
Virtual Call和它的本质
有用过PrintAssembly的朋友,可能会在反编译的汇编代码中发现有些方法调用的说明是invokevirtual,实际上这个invokevirtual就是Virtual Call。
Virtual Call是什么呢?
面向对象的编程语言基本上都支持方法的重写,我们考虑下面的情况:
private static class CustObj { public void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj is very good!"); } } } private static class CustObj2 extends CustObj { public final void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj2 is very good!"); } } }
我们定义了两个类,CustObj是父类CustObj2是子类。然后我们通一个方法来调用他们:
public static void doWithVMethod(CustObj obj) { obj.methodCall(); }
因为doWithVMethod的参数类型是CustObj,但是我们同样也可以传一个CustObj2对象给doWithVMethod。
怎么传递这个参数是在运行时决定的,我们很难在编译的时候判断到底该如何执行。
那么JVM会怎么处理这个问题呢?
答案就是引入VMT(Virtual Method Table),这个VMT存储的是该class对象中所有的Virtual Method。
然后class的实例对象保存着一个VMT的指针,执行VMT。
程序运行的时候首先加载实例对象,然后通过实例对象找到VMT,通过VMT再找到对应的方法地址。
Virtual Call和classic call
Virtual Call意思是调用方法的时候需要依赖不同的实例对象。而classic call就是直接指向方法的地址,而不需要通过VMT表的转换。
所以classic call通常会比Virtual Call要快。
那么在java中是什么情况呢?
在java中除了static, private和构造函数之外,其他的默认都是Virtual Call。
Virtual Call优化单实现方法的例子
有些朋友可能会有疑问了,java中其他方法默认都是Virtual Call,那么如果只有一个方法的实现,性能不会受影响吗?
不用怕,JIT足够智能,可以检测到这种情况,在这种情况下JIT会对Virtual Call进行优化。
接下来,我们使用JIT Watcher来进行Assembly代码的分析。
要运行的代码如下:
public class TestVirtualCall { public static void main(String[] args) throws InterruptedException { CustObj obj = new CustObj(); for (int i = 0; i < 10000; i++) { doWithVMethod(obj); } Thread.sleep(1000); } public static void doWithVMethod(CustObj obj) { obj.methodCall(); } private static class CustObj { public void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj is very good!"); } } } }
上面的例子中我们只定义了一个类的方法实现。
在JIT Watcher的配置中,我们禁用inline,以免inline的结果对我们的分析进行干扰。
如果你不想使用JIT Watcher,那么可以在运行是添加参数-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:-Inline, 这里使用JIT Watcher是为了方便分析。
好了运行代码:
运行完毕,界面直接定位到我们的JIT编译代码的部分,如下图所示:
obj.methodCall相对应的byteCode中,大家可以看到第二行就是invokevirtual,和它对应的汇编代码我也在最右边标明了。
大家可以看到在invokevirtual methodCall的最下面,已经写明了optimized virtual_call,表示这个方法已经被JIT优化过了。
接下来,我们开启inline选项,再运行一次:
大家可以看到methodCall中的System.currentTimeMillis已经被内联到methodCall中了。
因为内联只会发生在classic calls中,所以也侧面说明了methodCall方法已经被优化了。
Virtual Call优化多实现方法的例子
上面我们讲了一个方法的实现,现在我们测试一下两个方法的实现:
public class TestVirtualCall2 { public static void main(String[] args) throws InterruptedException { CustObj obj = new CustObj(); CustObj2 obj2 = new CustObj2(); for (int i = 0; i < 10000; i++) { doWithVMethod(obj); doWithVMethod(obj2); } Thread.sleep(1000); } public static void doWithVMethod(CustObj obj) { obj.methodCall(); } private static class CustObj { public void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj is very good!"); } } } private static class CustObj2 extends CustObj { public final void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj2 is very good!"); } } } }
上面的例子中我们定义了两个类CustObj和CustObj2。
再次运行看下结果,同样的,我们还是禁用inline。
大家可以看到结果中,首先对两个对象做了cmp,然后出现了两个优化过的virtual call。
这里比较的作用就是找到两个实例对象中的方法地址,从而进行优化。
那么问题来了,两个对象可以优化,三个对象,四个对象呢?
我们选择三个对象来进行分析:
public class TestVirtualCall4 { public static void main(String[] args) throws InterruptedException { CustObj obj = new CustObj(); CustObj2 obj2 = new CustObj2(); CustObj3 obj3 = new CustObj3(); for (int i = 0; i < 10000; i++) { doWithVMethod(obj); doWithVMethod(obj2); doWithVMethod(obj3); } Thread.sleep(1000); } public static void doWithVMethod(CustObj obj) { obj.methodCall(); } private static class CustObj { public void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj is very good!"); } } } private static class CustObj2 extends CustObj { public final void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj2 is very good!"); } } } private static class CustObj3 extends CustObj { public final void methodCall() { if(System.currentTimeMillis()== 0){ System.out.println("CustObj3 is very good!"); } } } }
运行代码,结果如下:
很遗憾,代码并没有进行优化。
具体未进行优化的原因我也不清楚,猜想可能跟code cache的大小有关? 有知道的朋友可以告诉我。
总结
本文介绍了Virtual Call和它在java代码中的使用,并在汇编语言的角度对其进行了一定程度的分析,有不对的地方还请大家不吝指教!
本文作者:flydean程序那些事
本文链接:http://www.flydean.com/jvm-virtual-call/
本文来源:flydean的博客
欢迎关注我的公众号:程序那些事,更多精彩等着您!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
五大代码异味:你需要提高警惕了!
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 作为广泛应用的警告标志,与字面意思不同,代码异味并不是指代码中需要立即注意的漏洞。相反,它反映出代码中更深层次的问题,更确切地说是代码中的裂缝,如果不加以纠正,这些问题可能会在未来导致更严重的后果。 代码异味是弱点或设计缺陷的标志,可能会在可读性、可维护性和可拓展性上导致问题,通常是由不当做法和未使用正确的工具导致的。 Python是最流行的语言之一,这在很大程度上与其相当容易的学习曲线和高度伪英语句法有关,而这却容易令人陷入单一的做事方法。本文中,我们将了解一些典型的Python代码异味案例以及如何避免它们。 可变默认参数 在Python中,使用默认参数是一个很常见的操作,你可以设置一个预定值,并在调用时选择更改。这在设置文字、数字或布尔值时很有用,因为有助于避免出现较长的有冗余值的参数列表。 但是将可变的值设置为默认参数可能是危险的,并且会导致bug。来看以下示例: def addElements(a=[]): a.append(5) return aaddElements() # ...
- 下一篇
Executors功能如此强大,ThreadPoolExecutor功不可没(一)
作为 Java 程序员,无论是技术面试、项目研发或者是学习框架源码,不彻底掌握 Java 多线程的知识,做不到心中有数,干啥都没底气,尤其是技术深究时往往略显发憷。 在 JDK1.5 以前,研发人员在面对线程频繁调度的场景,必须手动打造线程池,来节约系统开销(画外音:真是吃了不少苦头)。 从 JDK1.5 开始,Java 提供了一个 Excutors 工厂类来生产线程池,可以帮助研发人员有效的进行线程控制(画外音:不用造轮子啦,爽歪歪)。 (配图释义:JDK 1.8 能用 Excutors 创建的线程池) 如上图示意,Excutors 提供了满足各种场景的线程池创建方式,Java研发人员就不用苦逼哈哈的去造轮子啦,谁用谁爽。 但是,阿里开发规约明确强制研发人员:线程池不允许使用Executors去创建,而是通过ThreadPoolExecutor的方式。 (配图释义:阿里巴巴Java开发手册,线程池创建规约) 不过,若经常关注源码的同学会发现,无论是 newFixedThreadPool() 方法、newSingleThreadExecutor() 方法,还是 newCachedThr...
相关文章
文章评论
共有0条评论来说两句吧...