浅谈JVM系列之JIT中的Virtual Call

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!");
            }
        }
    }
}

运行代码,结果如下:

总结

本文介绍了Virtual Call和它在java代码中的使用,并在汇编语言的角度对其进行了一定程度的分析。

以上就是浅谈JVM系列之JIT中的Virtual Call的详细内容,更多关于JVM系列之JIT中的Virtual Call的资料请关注我们其它相关文章!

(0)

相关推荐

  • jvm运行原理以及类加载器实例详解

    JVM运行原理 首先从".java"代码文件,编译成".class"字节码文件,然后类加载器将".class"字节码文件中的类给加载带JVM中,最后就是JVM执行写好的代码.执行过程如下图 类加载器 类加载过程 加载 -> 验证 -> 准备 -> 解析 -> 初始化 -> 使用 -> 卸载 加载 一旦JVM进程启动之后,一定会先把类加载到内存中,然后从main()方法的入口代码开始执行 public class

  • JVM中ClassLoader类加载器的深入理解

    JVM的体系结构图 先来看一下JVM的体系结构,如下图: JVM的位置 JVM的位置,如下图: JVM是运行在操作系统之上的,与硬件没有直接的交互,但是可以调用底层的硬件,用JIN(Java本地接口调用底层硬件) JVM结构图中的class files文件 class files文件,是保存在我们电脑本地的字节码文件,.java文件经过编译之后,就会生成一个.class文件,这个文件就是class files所对应的字节码文件,如下图: JVM结构图中的类加载器ClassLoader的解释 类加

  • JVM系列之:JIT中的Virtual Call接口操作

    简介 上一篇文章我们讲解了Virtual Call的定义并举例分析了Virtual Call在父类和子类中的优化. JIT对类可以进行优化,那么对于interface可不可以做同样的优化么? 一起来看看吧. 最常用的接口List List应该是大家最最常用的接口了,我想这个大家应该不会反驳. public interface List<E> extends Collection<E> { 今天我们就拿List来做例子,体验一下JIT优化接口的奥秘. 还是上代码,要分析的代码如下:

  • JVM上高性能数据格式库包Apache Arrow入门和架构详解(Gkatziouras)

    Apache Arrow是是各种大数据工具(包括BigQuery)使用的一种流行格式,它是平面和分层数据的存储格式.它是一种加快应用程序内存密集型. 数据处理和数据科学领域中的常用库: Apache Arrow.诸如Apache Parquet,Apache Spark,pandas之类的开放源代码项目以及许多商业或封闭源代码服务都使用Arrow.它提供以下功能: 内存计算 标准化的柱状存储格式 一个IPC和RPC框架,分别用于进程和节点之间的数据交换 让我们看一看在Arrow出现之前事物是如何

  • java虚拟机之JVM调优详解

    JVM常用命令行参数 1. 查看参数列表 虚拟机参数分为基本和扩展两类,在命令行中输入 JAVA_HOME\bin\java就可得到基本参数列表. 在命令行输入 JAVA_HOME\bin\java –X就可得到扩展参数列表. 2. 基本参数说明: -client,-server: 两种Java虚拟机启动方式,client模式启动比较快,但是性能和内存管理相对较差,server模式启动比较慢,但是运行性能比较高,windos上采用的是client模式,Linux采用server模式 -class

  • JVM常量池的深入讲解

    提示:这里咱们要说的常量池,常量池就是咱们面试中所说的常量池,谈谈你对常量池的认识?面试官一问咱们就懵逼了,你要记得你脑子中有一张图!!! 剩下的就好办了 提示:请各位大佬批评指正!! 前言 提示:学习的时候会有点头疼哦 一.Class常量池与运行时常量池 Class常量池可以理解为是Class文件中的资源仓库. Class文件中除了包含类的版本.字段.方法.接口等描述信息外,还有一项信息就是 常量池(constant pool table) ,用于存放编译期生成的各种 字面量(Literal)

  • Java 汇编JVM编写jasmin程序的操作方法

    Jasmin是Java汇编语言,以文本方式来描述JVM的指令集以及Java Class的结构,Jasmin编译器可以把汇编语言转换成二进制的字节码,使JVM可以调入执行. Jasmin最初是由Jon Meyer和Troy Downing编纂<Java Virtual Machine>时设计的范例,虽然该书不再出版,但是Jasmin成为了事实上的Java汇编语言标准,并作为开源项目得到发展:http://jasmin.sourceforge.net/. Jasmin在Java class方面的处

  • 华为技术专家讲解JVM内存模型(收藏)

    全是干货的技术号: 本文已收录在[github面试知识仓库],欢迎 star/fork: https://github.com/Wasabi1234/Java-Interview-Tutorial 内存是非常重要的系统资源,是硬盘和CPU的中间仓库及桥梁,承载着操作系统和应用程序的实时运行. JVM内存布局规定了Java在运行过程中内存申请.分配.管理的策略,保证了JVM的高效稳定运行.不同的JVM对于内存的划分方式和管理机制存在着部分差异.结合JVM虚拟机规范,来探讨经典的JVM内存布局. J

  • JVM双亲委派模型知识详细总结

    一.简介 除了顶层的启动类加载器(Bootstrap ClassLoader)外,其余的类加载器都应当有自己的上层加载器,如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给上层的加载器,如果上层类加载器还存在其上层类加载器,则进一步向上委托,依次递归,直到请求最终到达顶层的启动类加载器,从顶层类加载器开始,如果类加载器根据类的全限定名查询到已经加载过这个类,就成功返回加载过的此类信息,倘若加载器未加载过此类,则原路返回给下层加载器继续重复此过程,直到最先加载此类的加载器

  • 浅谈JVM系列之JIT中的Virtual Call

    Virtual Call和它的本质 有用过PrintAssembly的朋友,可能会在反编译的汇编代码中发现有些方法调用的说明是invokevirtual,实际上这个invokevirtual就是Virtual Call. Virtual Call是什么呢? 面向对象的编程语言基本上都支持方法的重写,我们考虑下面的情况: private static class CustObj { public void methodCall() { if(System.currentTimeMillis()==

  • 浅谈JVM系列之从汇编角度分析NullCheck

    一个普通的virtual call 我们来分析一下在方法中调用list.add方法的例子: public class TestNull { public static void main(String[] args) throws InterruptedException { List<String> list= new ArrayList(); list.add("www.flydean.com"); for (int i = 0; i < 10000; i++)

  • 浅谈jvm中的垃圾回收策略

    java和C#中的内存的分配和释放都是由虚拟机自动管理的,此前我已经介绍了CLR中GC的对象回收方式,是基于代的内存回收策略,其实在java中,JVM的对象回收策略也是基于分代的思想.这样做的目的就是为了提高垃圾 回收的性能,避免对堆中的所有对象进行检查时所带来的程序的响应的延迟,因为jvm执行GC时,会stop the word,即终止其它线程的运行,等回收完毕,才恢复其它线程的操作.基于分代的思想是:jvm在每一次执行垃圾收集器时,只是对一小部分内存 对象引用进行检查,这一小部分对象的生命周

  • 浅谈JVM中的JOL

    JOL简介 JOL的全称是Java Object Layout.是一个用来分析JVM中Object布局的小工具.包括Object在内存中的占用情况,实例对象的引用情况等等. JOL可以在代码中使用,也可以独立的以命令行中运行.命令行的我这里就不具体介绍了,今天主要讲解怎么在代码中使用JOL. 使用JOL需要添加maven依赖: <dependency> <groupId>org.openjdk.jol</groupId> <artifactId>jol-co

  • 浅谈JVM之使用JFR解决内存泄露

    简介 虽然java有自动化的GC,但是还会有内存泄露的情况.当然java中的内存泄露跟C++中的泄露不同. 在C++中所有被分配的内存对象都需要要程序员手动释放.但是在java中并不需要这个过程,一切都是由GC来自动完成的.那么是不是java中就没有内存泄露了呢? 要回答这个问题我们首先需要界定一下什么是内存泄露.如果说有时候我们不再使用的对象却不能被GC释放的话,那么就可以说发生了内存泄露. 一个内存泄露的例子 我们举一个内存泄露的例子,先定义一个大对象: public class KeyOb

  • 浅谈JVM之java class文件的密码本

    简介 机器可以读,人为什么不能读?只要我们掌握java class文件的密码表,我们可以把二进制转成十六进制,将十六进制和我们的密码表进行对比,就可以轻松的解密了. 下面,让我们开始这个激动人心的过程吧. 一个简单的class 为了深入理解java class的含义,我们首先需要定义一个class类: public class JavaClassUsage { private int age=18; public void inc(int number){ this.age=this.age+

  • 浅谈JVM之类的加载链接和初始化

    加载 JVM可以分为三大部分,五大空间和三大引擎,要讲起来也不是特别复杂,先看下面的总体的JVM架构图. 从上面的图中,我们可以看到JVM中有三大部分,分别是类加载系统,运行时数据区域和Execution Engine. 加载就是根据特定名称查找类或者接口的二进制表示,并根据此二进制表示来创建类和接口的过程. 运行时常量池 我们知道JVM中有一个方法区的区域,在JDK8中,方法区的实现叫做元空间.这个元空间是存放在本地内存中的. 方法区中存放着每个class对应的运行时常量池. 当类或者接口创建

  • 浅谈JVM垃圾回收有哪些常用算法

    一.前言: 垃圾回收: 在未来的JDK中可能G1会为ZGC所取代 先问自己几个问题: 什么是垃圾? 垃圾就是堆内存中(范指)没有任何指针指向的对象实体.不具有可达性. 为什么要回收垃圾? 因为我们的内存是有限的,内存长时间不清理就会导致内存溢出,OOM: 只要是程序正在跑,那么就不断生成新的对象,我们需要GC开辟新的空间分配给新的对象. 我们怎么回收垃圾? 依靠Java的自动内存回收机制,机制的优劣由算法决定: 或者说是机制的适配度由算法和应用场景共同决定. 什么时候回收垃圾? 当堆中的实体对象

  • 浅谈JVM 底层解析 i++和 ++i 区别

    目录 一.前言 二.代码实现 三.字节码指令 四.字节码解析 1. 第一类问题 2. 第二类问题 3. 第三类问题 4. 第四类问题 一.前言 如果只用普通的知识解释i++和++i的话 i++ 先将i赋值再++ ++i 先++再赋值 但是这简单的回答并不能入吸引面试官的眼球,如果用java字节码指令分析则效果完全不同 二.代码实现 public class OperandStackTest { /** 程序员面试过程中, 常见的i++和++i 的区别 */ public static void

随机推荐