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

阅读原文时间：2021年10月28日阅读：1

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操作&&编译时的静态绑定与动态绑定