本文由HeapDump性能社区首席讲师鸠摩（马智）受权整顿公布

第29篇-调用Java主类的main()办法

后面曾经写了许多篇介绍字节码指令对应的汇编代码执行逻辑，还有一些字节码指令对应的汇编代码逻辑没有介绍，这些指令包含办法调用指令、同步指令、异样抛出指令，这些指令的汇编代码实现逻辑比较复杂，所以前面在介绍到办法调用、同步和异样解决的知识点时，会通过大篇幅的文章进行具体介绍！

在第1篇中大略介绍过Java中主类办法main()的调用过程，这一篇介绍的具体一点，大略的调用过程如下图所示。

其中浅红色的函数由主线程执行，而另外的浅绿色局部由另外一个线程执行，浅绿色的线程最终也会负责执行Java主类中的main()办法。在JavaMain()函数中调用LoadMainClass()函数加载Java主类。接着在JavaMain()函数中有如下调用：

源代码地位：openjdk/jdk/src/share/bin/java.c mainID = (*env)->GetStaticMethodID(  env,   mainClass,   "main",   "([Ljava/lang/String;)V");

env为JNIEnv*类型。调用JNIEnv类型中定义的GetStaticMethodID()函数获取Java主类中main()办法的办法惟一ID，调用GetStaticMethodID()函数就是调用jni_GetStaticMethodID()函数，此函数的实现如下：

源代码地位：openjdk/hotspot/src/share/vm/prims/jni.cpp JNI_ENTRY(jmethodID, jni_GetStaticMethodID(JNIEnv *env, jclass clazz,const char *name, const char *sig))  jmethodID ret = get_method_id(env, clazz, name, sig, true, thread);  return ret;JNI_END  static jmethodID get_method_id(   JNIEnv *env,   jclass clazz,   const char *name_str,   const char *sig,   bool is_static,   TRAPS){  const char *name_to_probe = (name_str == NULL)                        ? vmSymbols::object_initializer_name()->as_C_string()                        : name_str;  TempNewSymbol name = SymbolTable::probe(name_to_probe, (int)strlen(name_to_probe));  TempNewSymbol signature = SymbolTable::probe(sig, (int)strlen(sig));   KlassHandle klass(THREAD,java_lang_Class::as_Klass(JNIHandles::resolve_non_null(clazz)));   // 保障java.lang.Class类曾经初始化实现  klass()->initialize(CHECK_NULL);   Method* m;  if ( name == vmSymbols::object_initializer_name() || 查找的是<init>办法       name == vmSymbols::class_initializer_name() ) { 查找的是<clinit>办法    // 因为要查找的是构造函数，构造函数没有继承个性，所以以后类找不到时不向父类中持续查找    if (klass->oop_is_instance()) {       // find_method()函数不会向上查找       m = InstanceKlass::cast(klass())->find_method(name, signature);     } else {       m = NULL;    }  } else {    // lookup_method()函数会向上查找    m = klass->lookup_method(name, signature);     if (m == NULL && klass->oop_is_instance()) {       m = InstanceKlass::cast(klass())->lookup_method_in_ordered_interfaces(name, signature);    }  }  return m->jmethod_id();}

获取Java类中main()办法的jmethod_id。

源代码地位：method.hpp// Get this method's jmethodID -- allocate if it doesn't existjmethodID jmethod_id()  {      methodHandle this_h(this);      return InstanceKlass::get_jmethod_id(method_holder(), this_h);}

调用的InstanceKlass::get\_jmethod\_id()函数获取惟一ID，对于如何获取或生成ID的过程这里不再具体介绍，有趣味的自行钻研。

在JavaMain()函数中有如下调用：

mainArgs = CreateApplicationArgs(env, argv, argc); (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);

通过调用CallStaticVoidMethod()函数来调用Java主类中的main()办法。控制权转移到Java主类中的main()办法之中。调用CallStaticVoidMethod()函数就是调用jni_CallStaticVoidMethod()函数，此函数的实现如下：

源代码地位：openjdk/hotspot/src/share/vm/prims/jni.cpp  JNI_ENTRY(void, jni_CallStaticVoidMethod(JNIEnv *env, jclass cls, jmethodID methodID, ...))  va_list args;  va_start(args, methodID);  JavaValue jvalue(T_VOID);   JNI_ArgumentPusherVaArg  ap(methodID, args);  jni_invoke_static(env, &jvalue, NULL, JNI_STATIC, methodID, &ap, CHECK);  va_end(args);JNI_END

将传给Java办法的参数以C的可变长度参数传入后，应用JNI_ArgumentPusherVaArg实例ap是将其封装起来。JNI_ArgumentPusherVaArg类的继承体系如下：

JNI_ArgumentPusherVaArg->JNI_ArgumentPusher->SignatureIterator

调用的jni\_invoke\_static()函数的实现如下：

// 通过jni的形式调用Java静态方法static void jni_invoke_static( JNIEnv *env, JavaValue* result, jobject receiver, JNICallType call_type, jmethodID method_id, JNI_ArgumentPusher *args, TRAPS){  Method* m = Method::resolve_jmethod_id(method_id);  methodHandle method(THREAD, m);   ResourceMark rm(THREAD);  int number_of_parameters = method->size_of_parameters();  // 这里进一步将要传给Java的参数转换为JavaCallArguments对象传下去  JavaCallArguments java_args(number_of_parameters);  args->set_java_argument_object(&java_args);   // Fill out(填，填写) JavaCallArguments object  Fingerprinter fp = Fingerprinter(method);  uint64_t x = fp.fingerprint();  args->iterate(x);  // Initialize result type  BasicType bt = args->get_ret_type();  result->set_type(bt);   // Invoke the method. Result is returned as oop.  JavaCalls::call(result, method, &java_args, CHECK);   // Convert result  if (    result->get_type() == T_OBJECT ||     result->get_type() == T_ARRAY  ) {     oop tmp = (oop) result->get_jobject();     jobject jobj = JNIHandles::make_local(env,tmp);     result->set_jobject(jobj);  }}

通过JavaCalls::call()函数来调用Java主类的main()办法。对于JavaCalls::call()函数大家应该不会生疏，这个函数是怎么建设Java栈帧以及找到Java办法入口在之前曾经具体介绍过，这里不再介绍。

第30篇-解释执行main()办法小实例

咱们在介绍完一些罕用字节码指令的汇编代码执行逻辑后，根本看到一个main()办法从开始调用、栈帧建设、字节码执行的整个逻辑了，然而办法退栈、同步办法以及异样抛出等知识点还没有介绍，咱们这里只举个最简略的例子，能够帮忙大家回顾一下之前那么多篇文章所学到的内容。

在第7篇具体介绍过为Java办法创立的栈帧，如下图所示。

调用完generate\_fixed\_frame()函数后一些寄存器中保留的值如下：

rbx：Method*ecx：invocation counterr13：bcp(byte code pointer)rdx：ConstantPool* 常量池的地址r14：本地变量表第1个参数的地址

当初咱们举一个例子，来残缺的走一下解释执行的过程。这个例子如下：

package com.classloading; public class Test {    public static void main(String[] args) {        int i = 0;        i = i++;    }}

通过javap -verbose Test.class命令反编译后的字节码文件内容如下：　

Constant pool:   #1 = Methodref #3.#12 // java/lang/Object."<init>":()V   #2 = Class #13 // com/classloading/Test   #3 = Class #14 // java/lang/Object   #4 = Utf8 <init>   #5 = Utf8 ()V   #6 = Utf8 Code   #7 = Utf8 LineNumberTable   #8 = Utf8 main   #9 = Utf8 ([Ljava/lang/String;)V  #10 = Utf8 SourceFile  #11 = Utf8 Test.java  #12 = NameAndType #4:#5 // "<init>":()V  #13 = Utf8 com/classloading/Test  #14 = Utf8 java/lang/Object{  ...   public static void main(java.lang.String[]);    descriptor: ([Ljava/lang/String;)V    flags: ACC_PUBLIC, ACC_STATIC    Code:      stack=1, locals=2, args_size=1         0: iconst_0         1: istore_1         2: return}

如上实例对应的栈帧状态如下图所示。

当初咱们就以解释执行的形式执行main()办法中的字节码。因为是从虚拟机调用过去的，而调用完generate\_fixed\_frame()函数后一些寄存器中保留的值并没有波及到栈顶缓存，所以须要从iconst\_0这个字节码指令的vtos入口进入，而后找到iconst\_0这个字节码指令对应的机器指令片段。

当初回顾一下字节码分派的逻辑，在generate\_normal\_entry()函数中会调用generate\_fixed\_frame()函数为Java办法的执行生成对应的栈帧，接下来还会调用dispatch_next()函数执行Java办法的字节码，首次获取字节码时的汇编如下：

// 在generate_fixed_frame()办法中曾经让%r13存储了bcpmovzbl 0x0(%r13),%ebx // %ebx中存储的是字节码的操作码  // $0x7ffff73ba4a0这个地址指向的是对应state状态下的一维数组，长度为256movabs $0x7ffff73ba4a0,%r10  // 留神%r10中存储的是常量，依据计算公式%r10+%rbx*8来获取指向存储入口地址的地址，// 通过*(%r10+%rbx*8)获取到入口地址，而后跳转到入口地址执行jmpq *(%r10,%rbx,8)

留神如上的$0x7ffff73ba4a0这个常量值曾经示意了栈顶缓存状态为vtos下的一维数组首地址。而在首次进行办法的字节码分派时，通过0x0(%r13)即可取出字节码对应的Opcode，应用这个Opcode可定位到iconst_0的入口地址。

%r10指向的是对应栈顶缓存状态state下的一维数组，长度为256，其中存储的值为Opcode，这在第8篇具体介绍过，示意图如下图所示。

当初就是看入口为vtos，进口为itos的iconst_0所要执行的汇编代码了，如下：

... // vtos入口mov $0x1,%eax ...// iconst_0对应的汇编代码xor    %eax,%eax

汇编指令足够简略，最初将值存储到了%eax中，所以也就是栈顶缓存的进口状态为itos。

上图紫色的局部是本地变量表，因为本地变量表的大小为2，所以我画了2个方格示意slot。

执行下一个字节码指令istore_1，也会执行字节码分派相干的逻辑。这里须要揭示下，其实之前在介绍字节码指令对应的汇编时，只关注了字节码指令自身的执行逻辑，其实在为每个字节码指令生成机器指令时，个别都会为这些字节码指令生成3局部机器指令片段：

（1）不同栈顶状态对应的入口执行逻辑；

（2）字节码指令自身须要执行的逻辑；

（3）分派到下一个字节码指令的逻辑。

对于字节码指令模板定义中，如果flags中指令有disp，那么这些指令本人会含有分派的逻辑，如goto、ireturn、tableswitch、lookupswitch、jsr等。因为咱们的指令是iconst_0，所以会为这个字节码指令生成分派逻辑，生成的逻辑如下：

movzbl 0x1(%r13),%ebx    // %ebx中存储的是字节码的操作码  movabs itos对应的一维数组的首地址,%r10 jmpq *(%r10,%rbx,8)

须要留神的是，如果要让%ebx中存储istore\_1的Opcode，则%r13须要加上iconst\_0指令的长度，即1。因为iconst\_0执行后的进口栈顶缓存为itos，所以要找到入口状态为itos，而Opcode为istore\_1的机器指令片段执行。指令片段如下：

mov    %eax,-0x8(%r14)

代码将栈顶的值%eax存储到本地变量表下标索引为1的地位处。通过%r14很容易定位到本地变量表的地位，执行实现后的栈状态如下图所示。

执行iconst\_0和istore\_1时，整个过程没有向表达式栈（上图中sp/rsp开始以下的局部就是表达式栈）中压入0，实际上如果没有栈顶缓存的优化，应该将0压入栈顶，而后弹出栈顶存储到局部变量表，然而有了栈顶缓存后，没有压栈操作，也就有弹栈操作，所以能极大的进步程序的执行效率。

return指令判断的逻辑比拟多，次要是因为有些办法可能有synchronized关键字，所以会在办法栈中保留锁相干的信息，而在return返回时，退栈要开释锁。不过咱们当初只看针对本实例要运行的局部代码，如下：

// 将JavaThread::do_not_unlock_if_synchronized属性存储到%dl中0x00007fffe101b770: mov 0x2ad(%r15),%dl// 重置JavaThread::do_not_unlock_if_synchronized属性值为false0x00007fffe101b777: movb $0x0,0x2ad(%r15) // 将Method*加载到%rbx中0x00007fffe101b77f: mov -0x18(%rbp),%rbx// 将Method::_access_flags加载到%ecx中0x00007fffe101b783: mov 0x28(%rbx),%ecx// 查看Method::flags是否蕴含JVM_ACC_SYNCHRONIZED0x00007fffe101b786: test $0x20,%ecx// 如果办法不是同步办法，跳转到----unlocked----0x00007fffe101b78c: je 0x00007fffe101b970

main()办法为非同步办法，所以跳转到unlocked处执行，在unlocked处执行的逻辑中会执行一些开释锁的逻辑，对于咱们本实例来说这不重要，咱们间接看退栈的操作，如下：

// 将-0x8(%rbp)处保留的old stack pointer(saved rsp)取出来放到%rbx中0x00007fffe101bac7: mov -0x8(%rbp),%rbx // 移除栈帧// leave指令相当于：// mov %rbp, %rsp// pop %rbp0x00007fffe101bacb: leaveq // 将返回地址弹出到%r13中0x00007fffe101bacc: pop %r13// 设置%rsp为调用者的栈顶值0x00007fffe101bace: mov %rbx,%rsp0x00007fffe101bad1: jmpq *%r13

这个汇编不难，这里不再持续介绍。退栈后的栈状态如下图所示。

这就齐全回到了调用Java办法之前的栈状态，接下来如何退出如上栈帧并完结办法调用就是C++语言的事儿了。

第31篇-办法调用指令之invokevirtual

invokevirtual字节码指令的模板定义如下：

def(Bytecodes::_invokevirtual , ubcp|disp|clvm|____, vtos, vtos, invokevirtual , f2_byte );

生成函数为invokevirtual，传递的参数为f2_byte，也就是2，如果为2时，ConstantPoolCacheEntry::indices中取[b2,b1,original constant pool index]中的b2局部。调用的TemplateTable::invokevirtual()函数的实现如下：

void TemplateTable::invokevirtual(int byte_no) {  prepare_invoke(byte_no,                 rbx, // method or vtable index                 noreg, // unused itable index                 rcx, // recv                 rdx); // flags  // rbx: index  // rcx: receiver  // rdx: flags  invokevirtual_helper(rbx, rcx, rdx);}

先调用prepare\_invoke()函数，后调用invokevirtual\_helper()函数来生成invokevirtual字节码指令对应的汇编代码（其实是生成机器指令，而后反编译对应的汇编代码，在前面咱们就间接表述为汇编代码，读者要晓得）。

1、prepare_invoke()函数

调用TemplateTable::prepare_invoke()函数生成的汇编代码比拟多，所以咱们分三局部进行查看。

第1局部：

0x00007fffe1021f90: mov %r13,-0x38(%rbp) // 将bcp保留到栈中// invokevirtual x中取出x，也就是常量池索引存储到%edx，// 其实这里曾经是ConstantPoolCacheEntry的index，因为在类的连贯// 阶段会对办法中特定的一些字节码指令进行重写0x00007fffe1021f94: movzwl 0x1(%r13),%edx // 将ConstantPoolCache的首地址存储到%rcx0x00007fffe1021f99: mov -0x28(%rbp),%rcx // 左移2位，因为%edx中存储的是ConstantPoolCacheEntry索引，左移2位是因为// ConstantPoolCacheEntry占用4个字0x00007fffe1021f9d: shl $0x2,%edx        // 计算%rcx+%rdx*8+0x10，获取ConstantPoolCacheEntry[_indices,_f1,_f2,_flags]中的_indices// 因为ConstantPoolCache的大小为0x16字节，%rcx+0x10定位// 到第一个ConstantPoolCacheEntry的地位// %rdx*8算进去的是绝对于第一个ConstantPoolCacheEntry的字节偏移0x00007fffe1021fa0: mov 0x10(%rcx,%rdx,8),%ebx // 获取ConstantPoolCacheEntry中indices[b2,b1,constant pool index]中的b20x00007fffe1021fa4: shr $0x18,%ebx // 取出indices中含有的b2，即bytecode存储到%ebx中0x00007fffe1021fa7: and $0xff,%ebx // 查看182的bytecode是否曾经连贯 0x00007fffe1021fad: cmp $0xb6,%ebx  // 如果连贯就进行跳转，跳转到resolved 0x00007fffe1021fb3: je 0x00007fffe1022052

次要查看字节码是否曾经连贯，如果没有连贯则须要连贯，如果曾经进行了连贯，则跳转到resolved间接执行办法调用操作。

第2局部：

// 调用InterpreterRuntime::resolve_invoke()函数，因为指令还没有连贯// 将bytecode为182的指令挪动到%ebx中0x00007fffe1021fb9: mov $0xb6,%ebx // 通过调用MacroAssembler::call_VM()函数来调用// InterpreterRuntime::resolve_invoke(JavaThread* thread, Bytecodes::Code bytecode)函数// 进行办法连贯0x00007fffe1021fbe: callq 0x00007fffe1021fc8 0x00007fffe1021fc3: jmpq 0x00007fffe1022046 // 跳转到----E----// 筹备第2个参数，也就是bytecode0x00007fffe1021fc8: mov %rbx,%rsi 0x00007fffe1021fcb: lea 0x8(%rsp),%rax0x00007fffe1021fd0: mov %r13,-0x38(%rbp)0x00007fffe1021fd4: mov %r15,%rdi0x00007fffe1021fd7: mov %rbp,0x200(%r15)0x00007fffe1021fde: mov %rax,0x1f0(%r15)0x00007fffe1021fe5: test $0xf,%esp0x00007fffe1021feb: je 0x00007fffe10220030x00007fffe1021ff1: sub $0x8,%rsp0x00007fffe1021ff5: callq 0x00007ffff66ac5280x00007fffe1021ffa: add $0x8,%rsp0x00007fffe1021ffe: jmpq 0x00007fffe10220080x00007fffe1022003: callq 0x00007ffff66ac5280x00007fffe1022008: movabs $0x0,%r100x00007fffe1022012: mov %r10,0x1f0(%r15)0x00007fffe1022019: movabs $0x0,%r100x00007fffe1022023: mov %r10,0x200(%r15)0x00007fffe102202a: cmpq $0x0,0x8(%r15)0x00007fffe1022032: je 0x00007fffe102203d0x00007fffe1022038: jmpq 0x00007fffe10004200x00007fffe102203d: mov -0x38(%rbp),%r130x00007fffe1022041: mov -0x30(%rbp),%r140x00007fffe1022045: retq // 完结MacroAssembler::call_VM()函数的调用// **** E ****// 将invokevirtual x中的x加载到%edx中,也就是ConstantPoolCacheEntry的索引0x00007fffe1022046: movzwl 0x1(%r13),%edx // 将ConstantPoolCache的首地址存储到%rcx中 0x00007fffe102204b: mov -0x28(%rbp),%rcx  // %edx中存储的是ConstantPoolCacheEntry index，转换为字偏移0x00007fffe102204f: shl $0x2,%edx

办法连贯的逻辑和之前介绍的字段的连贯逻辑相似，都是欠缺ConstantPoolCache中对应的ConstantPoolCacheEntry增加相干信息。

调用InterpreterRuntime::resolve_invoke()函数进行办法连贯，这个函数的实现比拟多，咱们在下一篇中具体介绍。连贯实现后ConstantPoolCacheEntry中的各个项如下图所示。

所以对于invokevirtual来说，通过vtable进行办法的散发，在ConstantPoolCacheEntry中，\_f1字段没有应用，而对\_f2字段来说，如果调用的是非final的virtual办法，则保留的是指标办法在vtable中的索引编号，如果是virtual final办法，则_f2字段间接指向指标办法的Method实例。

第3局部：

// **** resolved ****// resolved的定义点，到这里阐明invokevirtual字节码曾经连贯// 获取ConstantPoolCacheEntry::_f2,这个字段只对virtual有意义// 在计算时，因为ConstantPoolCacheEntry在ConstantPoolCache之后保留，// 所以ConstantPoolCache为0x10，而// _f2还要偏移0x10，这样总偏移就是0x20// ConstantPoolCacheEntry::_f2存储到%rbx0x00007fffe1022052: mov 0x20(%rcx,%rdx,8),%rbx  // ConstantPoolCacheEntry::_flags存储到%edx0x00007fffe1022057: mov 0x28(%rcx,%rdx,8),%edx  // 将flags挪动到ecx中0x00007fffe102205b: mov %edx,%ecx // 从flags中取出参数大小 0x00007fffe102205d: and $0xff,%ecx          // 获取到recv,%rcx中保留的是参数大小，最终计算参数所须要的大小为%rsp+%rcx*8-0x8，// flags中的参数大小对实例办法来说，曾经包含了recv的大小// 如调用实例办法的第一个参数是this(recv)0x00007fffe1022063: mov -0x8(%rsp,%rcx,8),%rcx // recv保留到%rcx // 将flags存储到r13中0x00007fffe1022068: mov %edx,%r13d // 从flags中获取return type，也就是从_flags的高4位保留的TosState0x00007fffe102206b: shr $0x1c,%edx // 将TemplateInterpreter::invoke_return_entry地址存储到%r100x00007fffe102206e: movabs $0x7ffff73b6380,%r10 // %rdx保留的是return type，计算返回地址// 因为TemplateInterpreter::invoke_return_entry是数组，// 所以要找到对应return type的入口地址0x00007fffe1022078: mov (%r10,%rdx,8),%rdx // 向栈中压入返回地址0x00007fffe102207c: push %rdx // 还原ConstantPoolCacheEntry::_flags 0x00007fffe102207d: mov %r13d,%edx // 还原bcp0x00007fffe1022080: mov -0x38(%rbp),%r13

TemplateInterpreter::invoke\_return\_entry保留了一段例程的入口，这段例程在前面会具体介绍。

执行完如上的代码后，曾经向相干的寄存器中存储了相干的值。相干的寄存器状态如下：

rbx: 存储的是ConstantPoolCacheEntry::_f2属性的值rcx: 就是调用实例办法时的第一个参数thisrdx: 存储的是ConstantPoolCacheEntry::_flags属性的值

栈的状态如下图所示。

栈中压入了TemplateInterpreter::invoke\_return\_entry的返回地址。

2、invokevirtual_helper()函数

调用TemplateTable::invokevirtual_helper()函数生成的代码如下：

// flags存储到%eax0x00007fffe1022084: mov %edx,%eax // 测试调用的办法是否为final 0x00007fffe1022086: and $0x100000,%eax // 如果不为final就间接跳转到----notFinal---- 0x00007fffe102208c: je 0x00007fffe10220c0 // 通过(%rcx)来获取receiver的值，如果%rcx为空，则会引起OS异样0x00007fffe1022092: cmp (%rcx),%rax // 省略统计相干代码局部// 设置调用者栈顶并保留0x00007fffe10220b4: lea 0x8(%rsp),%r130x00007fffe10220b9: mov %r13,-0x10(%rbp)// 跳转到Method::_from_interpretered_entry入口去执行0x00007fffe10220bd: jmpq *0x58(%rbx)

对于final办法来说，其实没有动静分派，所以也不须要通过vtable进行指标查找。调用时的栈如下图所示。

如下代码是通过vtable查找动静分派须要调用的办法入口。

// **** notFinal ****// invokevirtual指令调用的如果是非final办法，间接跳转到这里// %rcx中存储的是receiver，用oop来示意。通过oop获取Klass0x00007fffe10220c0: mov 0x8(%rcx),%eax // 调用MacroAssembler::decode_klass__not_null()函数生成上面的一个汇编代码0x00007fffe10220c3: shl $0x3,%rax // LogKlassAlignmentInBytes=0x03// 省略统计相干代码局部// %rax中存储的是recv_klass// %rbx中存储的是vtable_index，// 而0x1b8为InstanceKlass::vtable_start_offset()*wordSize+vtableEntry::method_offset_in_bytes()，// 其实就是通过动静分派找到须要调用的Method*并存储到%rbx中0x00007fffe1022169: mov 0x1b8(%rax,%rbx,8),%rbx// 设置调用者的栈顶地址并保留0x00007fffe1022171: lea 0x8(%rsp),%r130x00007fffe1022176: mov %r13,-0x10(%rbp)// 跳转到Method::_from_interpreted_entry处执行0x00007fffe102217a: jmpq *0x58(%rbx)

了解如上代码时须要晓得vtable办法分派以及vtable在InstanceKlass中的布局，这在《深刻分析Java虚拟机：源码分析与实例详解》一书中具体介绍过，这里不再介绍。　　

跳转到Method::\_from\_interpretered\_entry保留的例程处执行，也就是以解释执行运行invokevirtual字节码指令调用的指标办法，对于Method::\_from\_interpretered\_entry保留的例程的逻辑在第6篇、第7篇、第8篇中具体介绍过，这里不再介绍。

如上的汇编语句 mov 0x1b8(%rax,%rbx,8),%rbx 是通过调用调用lookup\_virtual\_method()函数生成的，此函数将vtable\_entry\_addr加载到%rbx中，实现如下：

void MacroAssembler::lookup_virtual_method(Register recv_klass,                                           RegisterOrConstant vtable_index,                                           Register method_result) {  const int base = InstanceKlass::vtable_start_offset() * wordSize;  Address vtable_entry_addr(    recv_klass,    vtable_index,    Address::times_ptr,    base + vtableEntry::method_offset_in_bytes());    movptr(method_result, vtable_entry_addr);}

其中的vtable\_index取的就是ConstantPoolCacheEntry::\_f2属性的值。

最初还要说一下，如上生成的一些汇编代码中省略了统计相干的执行逻辑，这里统计相干的代码也是十分重要的，它会辅助进行编译，所以前面咱们还会介绍这些统计相干的逻辑。

第32篇-解析interfacevirtual字节码指令

在后面介绍invokevirtual指令时，如果判断出ConstantPoolCacheEntry中的\_indices字段的\_f2属性的值为空，则认为调用的指标办法没有连贯，也就是没有向ConstantPoolCacheEntry中保留调用办法的相干信息，须要调用InterpreterRuntime::resolve_invoke()函数进行办法连贯，这个函数的实现比拟多，咱们分几局部查看：

InterpreterRuntime::resolve_invoke()函数第1局部：

Handle receiver(thread, NULL);if (bytecode == Bytecodes::_invokevirtual || bytecode == Bytecodes::_invokeinterface) {    ResourceMark rm(thread);    // 调用method()函数从以后的栈帧中获取到须要执行的办法    Method* m1 = method(thread);    methodHandle m (thread, m1);     // 调用bci()函数从以后的栈帧中获取须要执行的办法的字节码索引    int i1 = bci(thread);    Bytecode_invoke call(m, i1);     // 以后须要执行的办法的签名    Symbol* signature = call.signature();     frame fm = thread->last_frame();    oop x = fm.interpreter_callee_receiver(signature);    receiver = Handle(thread,x);}

当字节码为invokevirtual或invokeinterface这样的动静分派字节码时，执行如上的逻辑。获取到了receiver变量的值。接着看实现，如下：

InterpreterRuntime::resolve_invoke()函数第2局部：

CallInfo info;constantPoolHandle pool(thread, method(thread)->constants()); {    JvmtiHideSingleStepping jhss(thread);    int cpcacheindex = get_index_u2_cpcache(thread, bytecode);    LinkResolver::resolve_invoke(info, receiver, pool,cpcacheindex, bytecode, CHECK);    ...}  // 如果曾经向ConstantPoolCacheEntry中更新了调用的相干信息则间接返回if (already_resolved(thread))  return;

依据存储在以后栈中的bcp来获取字节码指令的操作数，这个操作数通常就是常量池缓存项索引。而后调用LinkResolver::resolve\_invoke()函数进行办法连贯。这个函数会间接调用LinkResolver::resolve\_invokevirtual()函数，实现如下：

void LinkResolver::resolve_invokevirtual( CallInfo& result, Handle recv, constantPoolHandle pool, int index, TRAPS){   KlassHandle resolved_klass;  Symbol* method_name = NULL;  Symbol* method_signature = NULL;  KlassHandle current_klass;   resolve_pool(resolved_klass, method_name, method_signature, current_klass, pool, index, CHECK);   KlassHandle recvrKlass(THREAD, recv.is_null() ? (Klass*)NULL : recv->klass());   resolve_virtual_call(result, recv, recvrKlass, resolved_klass, method_name, method_signature, current_klass, true, true, CHECK);}

其中会调用resolve\_pool()和resolve\_vritual_call()函数别离连贯常量池和办法调用指令。调用会波及到的相干函数大略如下图所示。

上面介绍resolve\_pool()和resolve\_virtual_call()函数及其调用的相干函数的实现。

01 resolve_pool()函数

调用的resolve_pool()函数会调用一些函数，如下图所示。

每次调用LinkResolver::resolve\_pool()函数时不肯定会按如上的函数调用链执行，然而当类还没有解析时，通常会调用SystemDictionary::resolve\_or_fail()函数进行解析，最终会获取到指向Klass实例的指针，最终将这个类更新到常量池中。

resolve_pool()函数的实现如下：

void LinkResolver::resolve_pool( KlassHandle& resolved_klass, Symbol*& method_name, Symbol*& method_signature, KlassHandle& current_klass, constantPoolHandle pool, int index, TRAPS) {  resolve_klass(resolved_klass, pool, index, CHECK);   method_name = pool->name_ref_at(index);  method_signature = pool->signature_ref_at(index);  current_klass = KlassHandle(THREAD, pool->pool_holder());}

其中的index为常量池缓存项的索引。resolved\_klass参数示意须要进行解析的类（解析是在类生成周期中连贯相干的局部，所以咱们之前有时候会称为连贯，其实具体来说是解析的意思），而current\_klass为以后领有常量池的类，因为传递参数时是C++的援用传递，所以同值会间接扭转变量的值，调用者中的值也会随着扭转。

调用resolve_klass()函数进行类解析，一般来说，类解析会在解释常量池项时就会进行，这在《深刻分析Java虚拟机：源码分析与实例详解（根底卷）》一书中介绍过，这里须要再说一下。

调用的resolve_klass()函数及相干函数的实现如下：

void LinkResolver::resolve_klass( KlassHandle& result, constantPoolHandle pool, int                  index, TRAPS) {  Klass* result_oop = pool->klass_ref_at(index, CHECK);  // 通过援用进行传递  result = KlassHandle(THREAD, result_oop);} Klass* ConstantPool::klass_ref_at(int which, TRAPS) {  int x = klass_ref_index_at(which);  return klass_at(x, CHECK_NULL);} int klass_ref_index_at(int which) {  return impl_klass_ref_index_at(which, false);}

调用的impl\_klass\_ref\_index\_at()函数的实现如下：　　

int ConstantPool::impl_klass_ref_index_at(int which, bool uncached) {  int i = which;  if (!uncached && cache() != NULL) {    // 从which对应的ConstantPoolCacheEntry项中获取ConstantPoolIndex    i = remap_instruction_operand_from_cache(which);  }   assert(tag_at(i).is_field_or_method(), "Corrupted constant pool");  // 获取  jint ref_index = *int_at_addr(i);  // 获取低16位，那就是class_index  return extract_low_short_from_int(ref_index);}

依据断言可知，在原常量池索引的i处的项必定为JVM\_CONSTANT\_Fieldref、JVM\_CONSTANT\_Methodref或JVM\_CONSTANT\_InterfaceMethodref，这几项的格局如下：

CONSTANT_Fieldref_info{  u1 tag;  u2 class_index;   u2 name_and_type_index; // 必须是字段描述符} CONSTANT_InterfaceMethodref_info{  u1 tag;  u2 class_index; // 必须是接口  u2 name_and_type_index; // 必须是办法描述符} CONSTANT_Methodref_info{  u1 tag;  u2 class_index; // 必须是类  u2 name_and_type_index; // 必须是办法描述符}

3项的格局都一样，其中的class\_index索引处的项必须为CONSTANT\_Class\_info构造，示意一个类或接口，以后类字段或办法是这个类或接口的成员。name\_and\_type\_index索引处必须为CONSTANT\_NameAndType\_info项。　　

通过调用int\_at\_addr()函数和extract\_low\_short\_from\_int()函数获取class_index的索引值，如果理解了常量池内存布局，这里函数的实现了解起来会很简略，这里不再介绍。

在klass\_ref\_at()函数中调用klass_at()函数，此函数的实现如下：

Klass* klass_at(int which, TRAPS) {    constantPoolHandle h_this(THREAD, this);    return klass_at_impl(h_this, which, CHECK_NULL);}

调用的klass\_at\_impl()函数的实现如下：

Klass* ConstantPool::klass_at_impl( constantPoolHandle this_oop, int which, TRAPS) {     CPSlot entry = this_oop->slot_at(which);  if (entry.is_resolved()) { // 曾经进行了连贯    return entry.get_klass();  }   bool do_resolve = false;  bool in_error = false;   Handle mirror_handle;  Symbol* name = NULL;  Handle loader;  {     MonitorLockerEx ml(this_oop->lock());     if (this_oop->tag_at(which).is_unresolved_klass()) {      if (this_oop->tag_at(which).is_unresolved_klass_in_error()) {        in_error = true;      } else {        do_resolve = true;        name = this_oop->unresolved_klass_at(which);        loader = Handle(THREAD, this_oop->pool_holder()->class_loader());      }    }  } // unlocking constantPool   // 省略当in_error变量的值为true时的解决逻辑    if (do_resolve) {    oop protection_domain = this_oop->pool_holder()->protection_domain();    Handle h_prot (THREAD, protection_domain);    Klass* k_oop = SystemDictionary::resolve_or_fail(name, loader, h_prot, true, THREAD);    KlassHandle k;    if (!HAS_PENDING_EXCEPTION) {      k = KlassHandle(THREAD, k_oop);      mirror_handle = Handle(THREAD, k_oop->java_mirror());    }     if (HAS_PENDING_EXCEPTION) {      ...      return 0;    }     if (TraceClassResolution && !k()->oop_is_array()) {      ...     } else {      MonitorLockerEx ml(this_oop->lock());      do_resolve = this_oop->tag_at(which).is_unresolved_klass();      if (do_resolve) {        ClassLoaderData* this_key = this_oop->pool_holder()->class_loader_data();        this_key->record_dependency(k(), CHECK_NULL); // Can throw OOM        this_oop->klass_at_put(which, k()); // 留神这里会更新常量池中存储的内容，这样就示意类曾经解析实现，下次就不须要反复解析了      }    }  }   entry = this_oop->resolved_klass_at(which);  assert(entry.is_resolved() && entry.get_klass()->is_klass(), "must be resolved at this point");  return entry.get_klass();}

函数首先调用slot\_at()函数获取常量池中一个slot中存储的值，而后通过CPSlot来示意这个slot，这个slot中可能存储的值有2个，别离为指向Symbol实例（因为类名用CONSTANT\_Utf8_info项示意，在虚拟机外部对立应用Symbol对象示意字符串）的指针和指向Klass实例的指针，如果类曾经解释，那么指针示意的地址的最初一位为0，如果还没有被解析，那么地址的最初一位为1。

当没有解析时，须要调用SystemDictionary::resolve\_or\_fail()函数获取类Klass的实例，而后更新常量池中的信息，这样下次就不必反复解析类了。最初返回指向Klass实例的指针即可。

持续回到LinkResolver::resolve\_pool()函数看接下来的执行逻辑，也就是会获取JVM\_CONSTANT\_Fieldref、JVM\_CONSTANT\_Methodref或JVM\_CONSTANT\_InterfaceMethodref项中的name\_and\_type\_index，其指向的是CONSTANT\_NameAndType\_info项，格局如下：

CONSTANT_NameAndType_info{   u1 tag;  u2 name_index;  u2 descriptor index;}

获取逻辑就是先依据常量池缓存项的索引找到原常量池项的索引，而后查找到CONSTANT\_NameAndType\_info后，获取到办法名称和签名的索引，进而获取到被调用的指标办法的名称和签名。这些信息将在接下来调用的resolve\_virtual\_call()函数中应用。

02 resolve\_virtual\_call()函数

resolve\_virtual\_call()函数会调用的相干函数如下图所示。

LinkResolver::resolve\_virtual\_call()的实现如下：

void LinkResolver::resolve_virtual_call( CallInfo& result, Handle recv, KlassHandle receiver_klass, KlassHandle resolved_klass, Symbol* method_name, Symbol* method_signature, KlassHandle current_klass, bool         check_access, bool         check_null_and_abstract, TRAPS) {  methodHandle resolved_method;   linktime_resolve_virtual_method(resolved_method, resolved_klass, method_name, method_signature, current_klass, check_access, CHECK);   runtime_resolve_virtual_method(result, resolved_method, resolved_klass, recv, receiver_klass, check_null_and_abstract, CHECK);}

首先调用LinkResolver::linktime\_resolve\_virtual_method()函数，这个函数会调用如下函数：

void LinkResolver::resolve_method( methodHandle& resolved_method, KlassHandle resolved_klass, Symbol* method_name, Symbol* method_signature, KlassHandle current_klass, bool          check_access, bool          require_methodref, TRAPS) {   // 从解析的类和其父类中查找办法  lookup_method_in_klasses(resolved_method, resolved_klass, method_name, method_signature, true, false, CHECK);   // 没有在解析类的继承体系中查找到办法  if (resolved_method.is_null()) {     // 从解析类实现的所有接口（包含间接实现的接口）中查找办法    lookup_method_in_interfaces(resolved_method, resolved_klass, method_name, method_signature, CHECK);    // ...     if (resolved_method.is_null()) {      // 没有找到对应的办法      ...    }  }   // ...}

如上函数中最次要的就是依据method\_name和method\_signature从resolved\_klass类中找到适合的办法，如果找到就赋值给resolved\_method变量。

调用lookup\_method\_in\_klasses()、lookup\_method\_in\_interfaces()等函数进行办法的查找，这里临时不介绍。

上面接着看runtime\_resolve\_virtual_method()函数，这个函数的实现如下：

void LinkResolver::runtime_resolve_virtual_method( CallInfo& result, methodHandle resolved_method, KlassHandle resolved_klass, Handle recv, KlassHandle recv_klass, bool check_null_and_abstract, TRAPS) {   int vtable_index = Method::invalid_vtable_index;  methodHandle selected_method;   // 当办法定义在接口中时，示意是miranda办法  if (resolved_method->method_holder()->is_interface()) {     vtable_index = vtable_index_of_interface_method(resolved_klass,resolved_method);     InstanceKlass* inst = InstanceKlass::cast(recv_klass());    selected_method = methodHandle(THREAD, inst->method_at_vtable(vtable_index));  } else {    // 如果走如下的代码逻辑，则示意resolved_method不是miranda办法，须要动静分派且必定有正确的vtable索引    vtable_index = resolved_method->vtable_index();     // 有些办法尽管看起来须要动静分派，然而如果这个办法有final关键字时，可进行动态绑定，所以间接调用即可    // final办法其实不会放到vtable中，除非final办法覆写了父类中的办法    if (vtable_index == Method::nonvirtual_vtable_index) {      selected_method = resolved_method;    } else {      // 依据vtable和vtable_index以及inst进行办法的动静分派      InstanceKlass* inst = (InstanceKlass*)recv_klass();      selected_method = methodHandle(THREAD, inst->method_at_vtable(vtable_index));    }  }     // setup result resolve的类型为CallInfo，为CallInfo设置了连贯后的相干信息  result.set_virtual(resolved_klass, recv_klass, resolved_method, selected_method, vtable_index, CHECK);}

当为miranda办法时，调用 LinkResolver::vtable\_index\_of\_interface\_method()函数查找；当为final办法时，因为final办法不可能被子类覆写，所以resolved\_method就是指标调用办法；除去后面的2种状况后，剩下的办法就须要联合vtable和vtable\_index进行动静分派了。

如上函数将查找到调用时须要的所有信息并存储到CallInfo类型的result变量中。　

在获取到调用时的所有信息并存储到CallInfo中后，就能够依据info中相干信息填充ConstantPoolCacheEntry。咱们回看InterpreterRuntime::resolve_invoke()函数的执行逻辑。

InterpreterRuntime::resolve_invoke()函数第2局部：

switch (info.call_kind()) {  case CallInfo::direct_call: // 间接调用    cache_entry(thread)->set_direct_call(          bytecode,          info.resolved_method());    break;  case CallInfo::vtable_call: // vtable分派    cache_entry(thread)->set_vtable_call(          bytecode,          info.resolved_method(),          info.vtable_index());    break;  case CallInfo::itable_call: // itable分派    cache_entry(thread)->set_itable_call(          bytecode,          info.resolved_method(),          info.itable_index());    break;  default: ShouldNotReachHere();}

无论间接调用，还是vtable和itable动静分派，都会在办法解析实现后将相干的信息存储到常量池缓存项中。调用cache\_entry()函数获取对应的ConstantPoolCacheEntry项，而后调用set\_vtable_call()函数，此函数会调用如下函数更新ConstantPoolCacheEntry项中的信息，如下：

void ConstantPoolCacheEntry::set_direct_or_vtable_call( Bytecodes::Code invoke_code, methodHandle method, int vtable_index) {  bool is_vtable_call = (vtable_index >= 0); // FIXME: split this method on this boolean    int byte_no = -1;  bool change_to_virtual = false;   switch (invoke_code) {    case Bytecodes::_invokeinterface:       change_to_virtual = true;     // ...    // 能够看到，通过_invokevirtual指令时，并不一定都是动静散发，也有可能是动态绑定    case Bytecodes::_invokevirtual: // 以后曾经在ConstantPoolCacheEntry类中了      {        if (!is_vtable_call) {          assert(method->can_be_statically_bound(), "");          // set_f2_as_vfinal_method checks if is_vfinal flag is true.          set_method_flags(as_TosState(method->result_type()),                           ( 1      << is_vfinal_shift) |                           ((method->is_final_method() ? 1 : 0) << is_final_shift) |                           ((change_to_virtual ? 1 : 0) << is_forced_virtual_shift), // 在接口中调用Object中定义的办法                           method()->size_of_parameters());          set_f2_as_vfinal_method(method());        } else {          // 执行这里的逻辑时，示意办法是非动态绑定的非final办法，须要动静分派，则vtable_index的值必定大于等于0          set_method_flags(as_TosState(method->result_type()),                           ((change_to_virtual ? 1 : 0) << is_forced_virtual_shift),                           method()->size_of_parameters());          // 对于动静散发来说，ConstantPoolCacheEntry::_f2中保留的是vtable_index          set_f2(vtable_index);        }        byte_no = 2;        break;      }      // ...  }   if (byte_no == 1) {    // invoke_code为非invokevirtual和非invokeinterface字节码指令    set_bytecode_1(invoke_code);  } else if (byte_no == 2) {    if (change_to_virtual) {      if (method->is_public())          set_bytecode_1(invoke_code);    } else {      assert(invoke_code == Bytecodes::_invokevirtual, "");    }    // set up for invokevirtual, even if linking for invokeinterface also:    set_bytecode_2(Bytecodes::_invokevirtual);  } }

连贯实现后ConstantPoolCacheEntry中的各个项如下图所示。

第33篇-办法调用指令之invokeinterface

invokevirtual字节码指令的模板定义如下：

def(Bytecodes::_invokeinterface , ubcp|disp|clvm|____, vtos, vtos, invokeinterface , f1_byte );

能够看到指令的生成函数为TemplateTable::invokeinterface()，在这个函数中首先会调用TemplateTable::prepare\_invoke()函数，TemplateTable::prepare\_invoke()函数生成的汇编代码如下：

第1局部

0x00007fffe1022610: mov %r13,-0x38(%rbp)0x00007fffe1022614: movzwl 0x1(%r13),%edx0x00007fffe1022619: mov -0x28(%rbp),%rcx0x00007fffe102261d: shl $0x2,%edx// 获取ConstantPoolCacheEntry[_indices,_f1,_f2,_flags]中的_indices0x00007fffe1022620: mov 0x10(%rcx,%rdx,8),%ebx  // 获取ConstantPoolCacheEntry中indices[b2,b1,constant pool index]中的b1// 如果曾经连贯，那这个b1应该等于185,也就是invokeinterface指令的操作码0x00007fffe1022624: shr $0x10,%ebx0x00007fffe1022627: and $0xff,%ebx0x00007fffe102262d: cmp $0xb9,%ebx// 如果invokeinterface曾经连贯就跳转到----resolved----0x00007fffe1022633: je 0x00007fffe10226d2

汇编代码的判断逻辑与invokevirutal统一，这里不在过多解释。

第2局部

因为办法还没有解析，所以须要设置ConstantPoolCacheEntry中的信息，这样再一次调用时就不须要从新找调用相干的信息了。生成的汇编如下：

// 执行如下汇编代码时，示意invokeinterface指令还没有连贯，也就是ConstantPoolCacheEntry中// 还没有保留调用相干的信息   // 通过调用call_VM()函数生成如下汇编，通过这些汇编// 调用InterpreterRuntime::resolve_invoke()函数// 将bytecode存储到%ebx中0x00007fffe1022639: mov $0xb9,%ebx // 通过MacroAssembler::call_VM()来调用InterpreterRuntime::resolve_invoke()0x00007fffe102263e: callq 0x00007fffe1022648 0x00007fffe1022643: jmpq 0x00007fffe10226c60x00007fffe1022648: mov %rbx,%rsi0x00007fffe102264b: lea 0x8(%rsp),%rax0x00007fffe1022650: mov %r13,-0x38(%rbp)0x00007fffe1022654: mov %r15,%rdi0x00007fffe1022657: mov %rbp,0x200(%r15)0x00007fffe102265e: mov %rax,0x1f0(%r15)0x00007fffe1022665: test $0xf,%esp0x00007fffe102266b: je 0x00007fffe10226830x00007fffe1022671: sub $0x8,%rsp0x00007fffe1022675: callq 0x00007ffff66ae13a0x00007fffe102267a: add $0x8,%rsp0x00007fffe102267e: jmpq 0x00007fffe10226880x00007fffe1022683: callq 0x00007ffff66ae13a0x00007fffe1022688: movabs $0x0,%r100x00007fffe1022692: mov %r10,0x1f0(%r15)0x00007fffe1022699: movabs $0x0,%r100x00007fffe10226a3: mov %r10,0x200(%r15)0x00007fffe10226aa: cmpq $0x0,0x8(%r15)0x00007fffe10226b2: je 0x00007fffe10226bd0x00007fffe10226b8: jmpq 0x00007fffe10004200x00007fffe10226bd: mov -0x38(%rbp),%r130x00007fffe10226c1: mov -0x30(%rbp),%r140x00007fffe10226c5: retq  // 完结MacroAssembler::call_VM()函数// 将invokeinterface x中的x加载到%edx中0x00007fffe10226c6: movzwl 0x1(%r13),%edx// 将ConstantPoolCache的首地址存储到%rcx中0x00007fffe10226cb: mov -0x28(%rbp),%rcx// %edx中存储的是ConstantPoolCacheEntry项的索引，转换为字节// 偏移，因为一个ConstantPoolCacheEntry项占用4个字0x00007fffe10226cf: shl $0x2,%edx

与invokevirtual的实现相似，这里依然在办法没有解释时调用InterpreterRuntime::resolve\_invoke()函数进行办法解析，前面咱们也具体介绍一下InterpreterRuntime::resolve\_invoke()函数的实现。

在调用完resolve\_invoke()函数后，会将调用置信的信息存储到CallInfo实例info中。所以在调用的InterpreterRuntime::resolve\_invoke()函数的最初会有如下的实现：

switch (info.call_kind()) {  case CallInfo::direct_call: // 间接调用    cache_entry(thread)->set_direct_call(          bytecode,          info.resolved_method());    break;  case CallInfo::vtable_call: // vtable分派    cache_entry(thread)->set_vtable_call(          bytecode,          info.resolved_method(),          info.vtable_index());    break;  case CallInfo::itable_call: // itable分派    cache_entry(thread)->set_itable_call(          bytecode,          info.resolved_method(),          info.itable_index());    break;  default: ShouldNotReachHere();}

之前曾经介绍过vtable分派，当初看一下itable分派。

当为itable分派时，会调用set\_itable\_call()函数设置ConstantPoolCacheEntry中的相干信息，这个函数的实现如下：

void ConstantPoolCacheEntry::set_itable_call( Bytecodes::Code invoke_code, methodHandle method, int index) {   InstanceKlass* interf = method->method_holder();  // interf肯定是接口，method肯定是非final办法  set_f1(interf); // 对于itable，则_f1为InstanceKlass  set_f2(index);  set_method_flags(as_TosState(method->result_type()),                   0, // no option bits                   method()->size_of_parameters());  set_bytecode_1(Bytecodes::_invokeinterface);}

ConstantPoolCacheEntry中存储的信息为：

bytecode存储到了_f2字段上，这样当这个字段有值时示意曾经对此办法实现了解析；
\_f1字段存储申明办法的接口类，也就是\_f1是指向示意接口的Klass实例的指针；
\_f2示意\_f1接口类对应的办法表中的索引，如果是final办法，则存储指向Method实例的指针。

解析实现后ConstantPoolCacheEntry中的各个项如下图所示。

第3局部

如果invokeinterface字节码指令曾经解析，则间接跳转到resolved执行，否则调用resolve_invoke进行解析，解析实现后也会接着执行resolved处的逻辑，如下：

// **** resolved ****// resolved的定义点，到这里阐明invokeinterface字节码曾经连贯  // 执行完如上汇编后寄存器的值如下：// %edx：ConstantPoolCacheEntry index// %rcx：ConstantPoolCache // 获取到ConstantPoolCacheEntry::_f1// 在计算时，因为ConstantPoolCacheEntry在ConstantPoolCache// 之后保留，所以ConstantPoolCache为0x10，而// _f1还要偏移0x8，这样总偏移就是0x180x00007fffe10226d2: mov 0x18(%rcx,%rdx,8),%rax // 获取ConstantPoolCacheEntry::_f2属性0x00007fffe10226d7: mov 0x20(%rcx,%rdx,8),%rbx// 获取ConstantPoolCacheEntry::_flags属性0x00007fffe10226dc: mov 0x28(%rcx,%rdx,8),%edx  // 执行如上汇编后寄存器的值如下：// %rax：ConstantPoolCacheEntry::_f1// %rbx：ConstantPoolCacheEntry::_f2// %edx：ConstantPoolCacheEntry::_flags // 将flags挪动到ecx中0x00007fffe10226e0: mov %edx,%ecx// 从ConstantPoolCacheEntry::_flags中获取参数大小0x00007fffe10226e2: and $0xff,%ecx // 让%rcx指向recv 0x00007fffe10226e8: mov -0x8(%rsp,%rcx,8),%rcx // 临时用%r13d保留ConstantPoolCacheEntry::_flags属性0x00007fffe10226ed: mov %edx,%r13d // 从_flags的高4位保留的TosState中获取办法返回类型 0x00007fffe10226f0: shr $0x1c,%edx// 将TemplateInterpreter::invoke_return_entry地址存储到%r100x00007fffe10226f3: movabs $0x7ffff73b63e0,%r10// %rdx保留的是办法返回类型，计算返回地址// 因为TemplateInterpreter::invoke_return_entry是数组，// 所以要找到对应return type的入口地址0x00007fffe10226fd: mov (%r10,%rdx,8),%rdx// 获取后果处理函数TemplateInterpreter::invoke_return_entry的地址并压入栈中0x00007fffe1022701: push %rdx  // 复原ConstantPoolCacheEntry::_flags中%edx0x00007fffe1022702: mov %r13d,%edx // 还原bcp 0x00007fffe1022705: mov -0x38(%rbp),%r13

在TemplateTable::invokeinterface()函数中首先会调用prepare_invoke()函数，下面的汇编就是由这个函数生成的。调用完后各个寄存器的值如下：

rax: interface klass (from f1)rbx: itable index (from f2)rcx: receiverrdx: flags

而后接着执行TemplateTable::invokeinterface()函数生成的汇编片段，如下：

第4局部

// 将ConstantPoolCacheEntry::_flags的值存储到%r14d中0x00007fffe1022709: mov %edx,%r14d// 检测一下_flags中是否含有is_forced_virtual_shift标识，如果有，// 示意调用的是Object类中的办法，须要通过vtable进行动静分派0x00007fffe102270c: and $0x800000,%r14d0x00007fffe1022713: je 0x00007fffe1022812 // 跳转到----notMethod---- // ConstantPoolCacheEntry::_flags存储到%eax0x00007fffe1022719: mov %edx,%eax// 测试调用的办法是否为final0x00007fffe102271b: and $0x100000,%eax0x00007fffe1022721: je 0x00007fffe1022755 // 如果为非final办法，则跳转到----notFinal----  // 上面汇编代码是对final办法的解决 // 对于final办法来说，rbx中存储的是Method*，也就是ConstantPoolCacheEntry::_f2指向Method*// 跳转到Method::from_interpreted处执行即可0x00007fffe1022727: cmp (%rcx),%rax// ... 省略统计相干的代码// 设置调用者栈顶并存储0x00007fffe102274e: mov %r13,-0x10(%rbp)// 跳转到Method::_from_interpreted_entry0x00007fffe1022752: jmpq *0x58(%rbx) // 调用final办法  // **** notFinal **** // 调用load_klass()函数生成如下2句汇编// 查看recv这个oop对应的Klass，存储到%eax中0x00007fffe1022755: mov 0x8(%rcx),%eax // 调用decode_klass_not_null()函数生成的汇编 0x00007fffe1022758: shl $0x3,%rax         // 省略统计相干的代码 // 调用lookup_virtual_method()函数生成如下这一句汇编0x00007fffe10227fe: mov 0x1b8(%rax,%rbx,8),%rbx // 设置调用者栈顶并存储0x00007fffe1022806: lea 0x8(%rsp),%r130x00007fffe102280b: mov %r13,-0x10(%rbp) // 跳转到Method::_from_interpreted_entry0x00007fffe102280f: jmpq *0x58(%rbx)

如上汇编蕴含了对final和非final办法的分派逻辑。对于final办法来说，因为ConstantPoolCacheEntry::_f2中存储的就是指向被调用的Method实例，所以非常简单；对于非final办法来说，须要通过vtable实现动静分派。分派的要害一个汇编语句如下：

mov    0x1b8(%rax,%rbx,8),%rbx

须要提醒的是，只有大量的办法可能才会走这个逻辑进行vtable的动静分派，如调用Object类中的办法。

如果跳转到notMethod后，那就须要通过itable进行办法的动静分派了，咱们看一下这部分的实现逻辑：

第5局部

// **** notMethod **** // 让%r14指向本地变量表0x00007fffe1022812: mov -0x30(%rbp),%r14 // %rcx中存储的是receiver，%edx中保留的是Klass0x00007fffe1022816: mov 0x8(%rcx),%edx // LogKlassAlignmentInBytes=0x03，进行对齐解决0x00007fffe1022819: shl $0x3,%rdx // 如下代码是调用如下函数生成的：__ lookup_interface_method(rdx, // inputs: rec. classrax, // inputs: interfacerbx, // inputs: itable indexrbx, // outputs: methodr13, // outputs: scan temp. regno_such_interface);   // 获取vtable的起始地址 // %rdx中存储的是recv.Klass，获取Klass中// vtable_length属性的值0x00007fffe10228c1: mov 0x118(%rdx),%r13d  // %rdx：recv.Klass，%r13为vtable_length，// 最初r13指向第一个itableOffsetEntry// 加一个常量0x1b8是因为vtable之前是InstanceKlass0x00007fffe10228c8: lea 0x1b8(%rdx,%r13,8),%r13 0x00007fffe10228d0: lea (%rdx,%rbx,8),%rdx  // 获取itableOffsetEntry::_interface并与%rax比拟，%rax中存储的是要查找的接口0x00007fffe10228d4: mov 0x0(%r13),%rbx0x00007fffe10228d8: cmp %rbx,%rax// 如果相等，则间接跳转到---- found_method ----0x00007fffe10228db: je 0x00007fffe10228f3 // **** search ****// 检测%rbx中的值是否为NULL，如果为NULL，// 那就阐明receiver没有实现要查问的接口0x00007fffe10228dd: test %rbx,%rbx// 跳转到---- L_no_such_interface ----0x00007fffe10228e0: je 0x00007fffe1022a8c0x00007fffe10228e6: add $0x10,%r13 0x00007fffe10228ea: mov 0x0(%r13),%rbx0x00007fffe10228ee: cmp %rbx,%rax// 如果还是没有在itableOffsetEntry中找到接口类，// 则跳转到search持续进行查找0x00007fffe10228f1: jne 0x00007fffe10228dd // 跳转到---- search ---- // **** found_method **** // 曾经找到匹配接口的itableOffsetEntry，获取// itableOffsetEntry的offset属性并存储到%r13d中0x00007fffe10228f3: mov 0x8(%r13),%r13d// 通过recv_klass进行偏移后找到此接口下申明// 的一系列办法的开始地位0x00007fffe10228f7: mov (%rdx,%r13,1),%rbx

咱们须要重点关注itable的分派逻辑，首先生成了如下汇编：

mov    0x118(%rdx),%r13d

%rdx中存储的是recv.Klass，获取Klass中vtable_length属性的值，有了这个值，咱们就能够计算出vtable的大小，从而计算出itable的开始地址。

接着执行了如下汇编：

lea    0x1b8(%rdx,%r13,8),%r13

其中的0x1b8示意的是recv.Klass首地址到vtable的间隔，这样最终的%r13指向的是itable的首地址。如下图所示。

前面咱们就能够开始循环从itableOffsetEntry中查找匹配的接口了，如果找到则跳转到found\_method，在found\_method中，要找到对应的itableOffsetEntry的offset，这个offset指明了接口中定义的办法的存储地位绝对于Klass的偏移量，也就是找到接口对应的第一个itableMethodEntry，因为%rbx中曾经存储了itable的索引，所以依据这个索引间接定位对应的itableMethodEntry即可，咱们当初合起来看如下的2个汇编：

lea    (%rdx,%rbx,8),%rdx ...mov    (%rdx,%r13,1),%rbx

当执行到如上的第2个汇编时，%r13存储的是绝对于Klass实例的偏移，而%rdx在执行第1个汇编时存储的是Klass首地址，而后依据itable索引加上了绝对于第1个itableMethodEntry的偏移，这样就找到了对应的itableMethodEntry。　　

第6局部

在执行如下汇编时，各个寄存器的值如下：

rbx: Method* to call
rcx: receiver

生成的汇编代码如下：

0x00007fffe10228fb: test %rbx,%rbx// 如果原本应该存储Method*的%rbx是空，则示意没有找到// 这个办法，跳转到---- no_such_method ----0x00007fffe10228fe: je 0x00007fffe1022987  // 保留调用者的栈顶指针0x00007fffe1022904: lea 0x8(%rsp),%r13 0x00007fffe1022909: mov %r13,-0x10(%rbp)// 跳转到Method::from_interpreted指向的例程并执行0x00007fffe102290d: jmpq *0x58(%rbx)   // 省略should_not_reach_here()函数生成的汇编  // **** no_such_method ****// 当没有找到办法时，会跳转到这里执行 // 弹出调用prepare_invoke()函数压入的返回地址0x00007fffe1022987: pop %rbx// 复原让%r13指向bcp0x00007fffe1022988: mov -0x38(%rbp),%r13// 复原让%r14指向本地变量表0x00007fffe102298c: mov -0x30(%rbp),%r14  // ... 省略通过call_VM()函数生成的汇编来调用InterpreterRuntime::throw_abstractMethodError()函数// ... 省略调用should_not_reach_here()函数生成的汇编代码 // **** no_such_interface **** // 当没有找到匹配的接口时执行的汇编代码0x00007fffe1022a8c: pop %rbx0x00007fffe1022a8d: mov -0x38(%rbp),%r130x00007fffe1022a91: mov -0x30(%rbp),%r14 // ... 省略通过call_VM()函数生成的汇编代码来调用InterpreterRuntime::throw_IncompatibleClassChangeError()函数// ... 省略调用should_not_reach_here()函数生成的汇编代码

对于一些异样的解决这里就不过多介绍了，有趣味的能够看一下相干汇编代码的实现。　

因为字数限度，《虚拟机解释执行Java办法（下）》将在下篇中释出

有性能问题，找HeapDump性能社区