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

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

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

生成函数为invokevirtual，传递的参数为f2_byte，也就是2，如果为2时，ConstantPoolCacheEntry::indices中取[b2,b1,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、TemplateTable::prepare_invoke()函数

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

第1部分：

0x00007fffe1021f90: mov    %r13,-0x38(%rbp)    // 将bcp保存到栈中

// invokevirtual x中取出x，也就是常量池索引存储到%edx，

// 其实这里已经是ConstantPoolCacheEntry的index，因为在类的连接

// 阶段会对方法中特定的一些字节码指令进行重写

0x00007fffe1021f94: movzwl 0x1(%r13),%edx

// 将ConstantPoolCache的首地址存储到%rcx

0x00007fffe1021f99: 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]中的b2

0x00007fffe1021fa4: 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个参数，也就是bytecode

0x00007fffe1021fc8: mov    %rbx,%rsi

0x00007fffe1021fcb: lea    0x8(%rsp),%rax

0x00007fffe1021fd0: mov    %r13,-0x38(%rbp)

0x00007fffe1021fd4: mov    %r15,%rdi

0x00007fffe1021fd7: mov    %rbp,0x200(%r15)

0x00007fffe1021fde: mov    %rax,0x1f0(%r15)

0x00007fffe1021fe5: test   $0xf,%esp

0x00007fffe1021feb: je     0x00007fffe1022003

0x00007fffe1021ff1: sub    $0x8,%rsp

0x00007fffe1021ff5: callq  0x00007ffff66ac528

0x00007fffe1021ffa: add    $0x8,%rsp

0x00007fffe1021ffe: jmpq   0x00007fffe1022008

0x00007fffe1022003: callq  0x00007ffff66ac528

0x00007fffe1022008: movabs $0x0,%r10

0x00007fffe1022012: mov    %r10,0x1f0(%r15)

0x00007fffe1022019: movabs $0x0,%r10

0x00007fffe1022023: mov    %r10,0x200(%r15)

0x00007fffe102202a: cmpq   $0x0,0x8(%r15)

0x00007fffe1022032: je     0x00007fffe102203d

0x00007fffe1022038: jmpq   0x00007fffe1000420

0x00007fffe102203d: mov    -0x38(%rbp),%r13

0x00007fffe1022041: mov    -0x30(%rbp),%r14

0x00007fffe1022045: 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存储到%rbx

0x00007fffe1022052: mov    0x20(%rcx,%rdx,8),%rbx

 // ConstantPoolCacheEntry::_flags存储到%edx

0x00007fffe1022057: 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位保存的TosState

0x00007fffe102206b: shr    $0x1c,%edx 

// 将TemplateInterpreter::invoke_return_entry地址存储到%r10

0x00007fffe102206e: 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

// 还原bcp

0x00007fffe1022080: mov    -0x38(%rbp),%r13

TemplateInterpreter::invoke_return_entry保存了一段例程的入口，这段例程在后面会详细介绍。

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

rbx: 存储的是ConstantPoolCacheEntry::_f2属性的值

rcx: 就是调用实例方法时的第一个参数this

rdx: 存储的是ConstantPoolCacheEntry::_flags属性的值

栈的状态如下图所示。

栈中压入了TemplateInterpreter::invoke_return_entry的返回地址。

2、TemplateTable::invokevirtual_helper()函数

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

// flags存储到%eax

0x00007fffe1022084: 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),%r13

0x00007fffe10220b9: mov    %r13,-0x10(%rbp)

// 跳转到Method::_from_interpretered_entry入口去执行

0x00007fffe10220bd: jmpq   *0x58(%rbx)

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

如下代码是通过vtable查找动态分派需要调用的方法入口。

// **** notFinal ****

// invokevirtual指令调用的如果是非final方法，直接跳转到这里

// %rcx中存储的是receiver，用oop来表示。通过oop获取Klass

0x00007fffe10220c0: 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),%r13

0x00007fffe1022176: 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属性的值。

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

参考文章：Java字节码里的invoke操作&&编译时的静态绑定与动态绑定