第20篇-加载与存储指令之ldc与_fast_aldc指令（2）

阅读原文时间：2021年09月10日阅读：3

ldc指令将int、float、或者一个类、方法类型或方法句柄的符号引用、还可能是String型常量值从常量池中推送至栈顶。

这一篇介绍一个虚拟机规范中定义的一个字节码指令ldc，另外还有一个虚拟机内部使用的字节码指令_fast_aldc。ldc指令可以加载String、方法类型或方法句柄的符号引用，但是如果要加载String、方法类型或方法句柄的符号引用，则会在类连接过程中重写ldc字节码指令为虚拟机内部使用的字节码指令_fast_aldc。下面我们详细介绍ldc指令如何加载int、float类型和类类型的数据，以及_fast_aldc加载String、方法类型或方法句柄，还有为什么要进行字节码重写等问题。

1、ldc字节码指令

ldc指令将int、float或String型常量值从常量池中推送至栈顶。模板的定义如下：

def(Bytecodes::_ldc , ubcp|____|clvm|____, vtos, vtos, ldc , false );

ldc字节码指令的格式如下：

// index是一个无符号的byte类型数据，指明当前类的运行时常量池的索引
ldc index

调用生成函数TemplateTable::ldc(bool wide)。函数生成的汇编代码如下：　　

第1部分代码：

// movzbl指令负责拷贝一个字节，并用0填充其目
// 的操作数中的其余各位，这种扩展方式叫"零扩展"
// ldc指定的格式为ldc index，index为一个字节
0x00007fffe1028530: movzbl 0x1(%r13),%ebx // 加载index到%ebx

// %rcx指向缓存池首地址、%rax指向类型数组_tags首地址
0x00007fffe1028535: mov -0x18(%rbp),%rcx
0x00007fffe1028539: mov 0x10(%rcx),%rcx
0x00007fffe102853d: mov 0x8(%rcx),%rcx
0x00007fffe1028541: mov 0x10(%rcx),%rax

// 从_tags数组获取操作数类型并存储到%edx中
0x00007fffe1028545: movzbl 0x4(%rax,%rbx,1),%edx

// $0x64代表JVM_CONSTANT_UnresolvedClass，比较，如果类还没有链接，
// 则直接跳转到call_ldc
0x00007fffe102854a: cmp $0x64,%edx
0x00007fffe102854d: je 0x00007fffe102855d // call_ldc

// $0x67代表JVM_CONSTANT_UnresolvedClassInError，也就是如果类在
// 链接过程中出现错误，则跳转到call_ldc
0x00007fffe102854f: cmp $0x67,%edx
0x00007fffe1028552: je 0x00007fffe102855d // call_ldc

// $0x7代表JVM_CONSTANT_Class，表示如果类已经进行了连接，则
// 跳转到notClass
0x00007fffe1028554: cmp $0x7,%edx
0x00007fffe1028557: jne 0x00007fffe10287c0 // notClass

// 类在没有连接或连接过程中出错，则执行如下的汇编代码
// -- call_ldc --

下面看一下调用call_VM(rax, CAST_FROM_FN_PTR(address, InterpreterRuntime::ldc), c_rarg1)函数生成的汇编代码，CAST_FROM_FN_PTR是宏，宏扩展后为( (address)((address_word)(InterpreterRuntime::ldc)) )。

在调用call_VM()函数时，传递的参数如下：

%rax现在存储类型数组首地址，不过传入是为了接收调用函数的结果值
adr是InterpreterRuntime::ldc()函数首地址
c_rarg1用rdi寄存器存储wide值，这里为0，表示为没有加wide前缀的ldc指令生成汇编代码

生成的汇编代码如下：

第2部分：

// 将wide的值移到%esi寄存器，为后续
// 调用InterpreterRuntime::ldc()函数准备第2个参数
0x00007fffe102855d: mov $0x0,%esi
// 调用MacroAssembler::call_VM()函数，通过此函数来调用HotSpot VM中用
// C++编写的函数，通过这个C++编写的函数来调用InterpreterRuntime::ldc()函数

0x00007fffe1017542: callq 0x00007fffe101754c
0x00007fffe1017547: jmpq 0x00007fffe10175df // 跳转到E1

// 调用MacroAssembler::call_VM_helper()函数
// 将栈顶存储的返回地址设置到%rax中，也就是将存储地址0x00007fffe1017547
// 的栈的slot地址设置到%rax中
0x00007fffe101754c: lea 0x8(%rsp),%rax

// 调用InterpreterMacroAssembler::call_VM_base()函数
// 存储bcp到栈中特定位置
0x00007fffe1017551: mov %r13,-0x38(%rbp)

// 调用MacroAssembler::call_VM_base()函数
// 将r15中的值移动到rdi寄存器中，也就是为函数调用准备第一个参数
0x00007fffe1017555: mov %r15,%rdi
// 只有解释器才必须要设置fp
// 将last_java_fp保存到JavaThread类的last_java_fp属性中
0x00007fffe1017558: mov %rbp,0x200(%r15)
// 将last_java_sp保存到JavaThread类的last_java_sp属性中
0x00007fffe101755f: mov %rax,0x1f0(%r15)

// … 省略调用MacroAssembler::call_VM_leaf_base()函数

// 重置JavaThread::last_java_sp与JavaThread::last_java_fp属性的值
0x00007fffe1017589: movabs $0x0,%r10
0x00007fffe1017593: mov %r10,0x1f0(%r15)
0x00007fffe101759a: movabs $0x0,%r10
0x00007fffe10175a4: mov %r10,0x200(%r15)

// check for pending exceptions (java_thread is set upon return)
0x00007fffe10175ab: cmpq $0x0,0x8(%r15)
// 如果没有异常则直接跳转到ok
0x00007fffe10175b3: je 0x00007fffe10175be
// 如果有异常则跳转到StubRoutines::forward_exception_entry()获取的例程入口
0x00007fffe10175b9: jmpq 0x00007fffe1000420

// -- ok --
// 将JavaThread::vm_result属性中的值存储到%rax寄存器中并清空vm_result属性的值
0x00007fffe10175be: mov 0x250(%r15),%rax
0x00007fffe10175c5: movabs $0x0,%r10
0x00007fffe10175cf: mov %r10,0x250(%r15)

// 结束调用MacroAssembler::call_VM_base()函数

// 恢复bcp与locals
0x00007fffe10175d6: mov -0x38(%rbp),%r13
0x00007fffe10175da: mov -0x30(%rbp),%r14

// 结束调用MacroAssembler::call_VM_helper()函数

0x00007fffe10175de: retq
// 结束调用MacroAssembler::call_VM()函数

下面详细解释如下汇编的意思。　　

call指令相当于如下两条指令：

push %eip
jmp addr

而ret指令相当于：

pop %eip

所以如上汇编代码：

0x00007fffe1017542: callq 0x00007fffe101754c
0x00007fffe1017547: jmpq 0x00007fffe10175df // 跳转
…
0x00007fffe10175de: retq

调用callq指令将jmpq的地址压入了表达式栈，也就是压入了返回地址x00007fffe1017547，这样当后续调用retq时，会跳转到jmpq指令执行，而jmpq又跳转到了0x00007fffe10175df地址处的指令执行。

通过调用MacroAssembler::call_VM()函数来调用HotSpot VM中用的C++编写的函数，call_VM()函数还会调用如下函数：

MacroAssembler::call_VM_helper
InterpreterMacroAssembler::call_VM_base()
MacroAssembler::call_VM_base()
MacroAssembler::call_VM_leaf_base()

在如上几个函数中，最重要的就是在MacroAssembler::call_VM_base()函数中保存rsp、rbp的值到JavaThread::last_java_sp与JavaThread::last_java_fp属性中，然后通过MacroAssembler::call_VM_leaf_base()函数生成的汇编代码来调用C++编写的InterpreterRuntime::ldc()函数，如果调用InterpreterRuntime::ldc()函数有可能破坏rsp和rbp的值（其它的%r13、%r14等的寄存器中的值也有可能破坏，所以在必要时保存到栈中，在调用完成后再恢复，这样这些寄存器其实就算的上是调用者保存的寄存器了），所以为了保证rsp、rbp，将这两个值存储到线程中，在线程中保存的这2个值对于栈展开非常非常重要，后面我们会详细介绍。

由于如上汇编代码会解释执行，在解释执行过程中会调用C++函数，所以C/C++栈和Java栈都混在一起，这为我们查找带来了一定的复杂度。

调用的MacroAssembler::call_VM_leaf_base()函数生成的汇编代码如下：

第3部分汇编代码：

// 调用MacroAssembler::call_VM_leaf_base()函数
0x00007fffe1017566: test $0xf,%esp // 检查对齐
// %esp对齐的操作，跳转到 L
0x00007fffe101756c: je 0x00007fffe1017584
// %esp没有对齐时的操作
0x00007fffe1017572: sub $0x8,%rsp
0x00007fffe1017576: callq 0x00007ffff66a22a2 // 调用函数，也就是调用InterpreterRuntime::ldc()函数
0x00007fffe101757b: add $0x8,%rsp
0x00007fffe101757f: jmpq 0x00007fffe1017589 // 跳转到E2
// -- L --
// %esp对齐的操作
0x00007fffe1017584: callq 0x00007ffff66a22a2 // 调用函数，也就是调用InterpreterRuntime::ldc()函数

// -- E2 --

// 结束调用
MacroAssembler::call_VM_leaf_base()函数

在如上这段汇编中会真正调用C++函数InterpreterRuntime::ldc()，由于这是一个C++函数，所以在调用时，如果要传递参数，则要遵守C++调用约定，也就是前6个参数都放到固定的寄存器中。这个函数需要2个参数，分别为thread和wide，已经分别放到了%rdi和%rax寄存器中了。InterpreterRuntime::ldc()函数的实现如下：

// ldc负责将数值常量或String常量值从常量池中推送到栈顶
IRT_ENTRY(void, InterpreterRuntime::ldc(JavaThread* thread, bool wide))
ConstantPool* pool = method(thread)->constants();
int index = wide ? get_index_u2(thread, Bytecodes::_ldc_w) : get_index_u1(thread, Bytecodes::_ldc);
constantTag tag = pool->tag_at(index);

Klass* klass = pool->klass_at(index, CHECK);
oop java_class = klass->java_mirror(); // java.lang.Class通过oop来表示
thread->set_vm_result(java_class);
IRT_END

函数将查找到的、当前正在解释执行的方法所属的类存储到JavaThread类的vm_result属性中。我们可以回看第2部分汇编代码，会将vm_result属性的值设置到%rax中。

接下来继续看TemplateTable::ldc(bool wide)函数生成的汇编代码，此时已经通过调用call_VM()函数生成了调用InterpreterRuntime::ldc()这个C++的汇编，调用完成后值已经放到了%rax中。

// -- E1 --
0x00007fffe10287ba: push %rax // 将调用的结果存储到表达式中
0x00007fffe10287bb: jmpq 0x00007fffe102885e // 跳转到Done

// -- notClass --
// $0x4表示JVM_CONSTANT_Float
0x00007fffe10287c0: cmp $0x4,%edx
0x00007fffe10287c3: jne 0x00007fffe10287d9 // 跳到notFloat
// 当ldc字节码指令加载的数为float时执行如下汇编代码
0x00007fffe10287c5: vmovss 0x58(%rcx,%rbx,8),%xmm0
0x00007fffe10287cb: sub $0x8,%rsp
0x00007fffe10287cf: vmovss %xmm0,(%rsp)
0x00007fffe10287d4: jmpq 0x00007fffe102885e // 跳转到Done

// -- notFloat --
// 当ldc字节码指令加载的为非float，也就是int类型数据时通过push加入表达式栈
0x00007fffe1028859: mov 0x58(%rcx,%rbx,8),%eax
0x00007fffe102885d: push %rax

// -- Done --

由于ldc指令除了加载String外，还可能加载int和float，如果是int，直接调用push压入表达式栈中，如果是float，则在表达式栈上开辟空间，然后移到到这个开辟的slot中存储。注意，float会使用%xmm0寄存器。

2、fast_aldc虚拟机内部字节码指令

下面介绍_fast_aldc指令，这个指令是虚拟机内部使用的指令而非虚拟机规范定义的指令。_fast_aldc指令的模板定义如下：

def(Bytecodes::_fast_aldc , ubcp|____|clvm|____, vtos, atos, fast_aldc , false );

生成函数为TemplateTable::fast_aldc(bool wide)，这个函数生成的汇编代码如下：

// 调用InterpreterMacroAssembler::get_cache_index_at_bcp()函数生成
// 获取字节码指令的操作数，这个操作数已经指向了常量池缓存项的索引，在字节码重写
// 阶段已经进行了字节码重写
0x00007fffe10243d0: movzbl 0x1(%r13),%edx

// 调用InterpreterMacroAssembler::load_resolved_reference_at_index()函数生成

// shl表示逻辑左移，相当于乘4,因为ConstantPoolCacheEntry的大小为4个字
0x00007fffe10243d5: shl $0x2,%edx

// 获取Method*
0x00007fffe10243d8: mov -0x18(%rbp),%rax
// 获取ConstMethod*
0x00007fffe10243dc: mov 0x10(%rax),%rax
// 获取ConstantPool*
0x00007fffe10243e0: mov 0x8(%rax),%rax
// 获取ConstantPool::_resolved_references属性的值，这个值
// 是一个指向对象数组的指针
0x00007fffe10243e4: mov 0x30(%rax),%rax

// JNIHandles::resolve(obj)
0x00007fffe10243e8: mov (%rax),%rax

// 从_resolved_references数组指定的下标索引处获取oop，先进行索引偏移
0x00007fffe10243eb: add %rdx,%rax

// 要在%rax上加0x10，是因为数组对象的头大小为2个字，加上后
// %rax就指向了oop
0x00007fffe10243ee: mov 0x10(%rax),%eax

获取_resolved_references属性的值，涉及到的2个属性在ConstantPool类中的定义如下：

// Array of resolved objects from the constant pool and map from resolved
// object index to original constant pool index
jobject _resolved_references; // jobject是指针类型
Array* _reference_map;

关于_resolved_references指向的其实是Object数组。在ConstantPool::initialize_resolved_references()函数中初始化这个属性。调用链如下：

ConstantPool::initialize_resolved_references() constantPool.cpp 　　
Rewriter::make_constant_pool_cache() rewriter.cpp
Rewriter::Rewriter() rewriter.cpp
Rewriter::rewrite() rewriter.cpp
InstanceKlass::rewrite_class() instanceKlass.cpp
InstanceKlass::link_class_impl() instanceKlass.cpp

后续如果需要连接ldc等指令时，可能会调用如下函数：（我们只讨论ldc加载String类型数据的问题，所以我们只看往_resolved_references属性中放入表示String的oop的逻辑，MethodType与MethodHandle将不再介绍，有兴趣的可自行研究）

oop ConstantPool::string_at_impl(
constantPoolHandle this_oop,
int which,
int obj_index,
TRAPS
) {
oop str = this_oop->resolved_references()->obj_at(obj_index);
if (str != NULL)
return str;

Symbol* sym = this_oop->unresolved_string_at(which);
str = StringTable::intern(sym, CHECK_(NULL));

this_oop->string_at_put(which, obj_index, str);

return str;
}

void string_at_put(int which, int obj_index, oop str) {
// 获取类型为jobject的_resolved_references属性的值
objArrayOop tmp = resolved_references();
tmp->obj_at_put(obj_index, str);
}

在如上函数中向_resolved_references数组中设置缓存的值。

大概的思路就是：如果ldc加载的是字符串，那么尽量通过_resolved_references数组中一次性找到表示字符串的oop，否则要通过原常量池下标索引找到Symbol实例（Symbol实例是HotSpot VM内部使用的、用来表示字符串），根据Symbol实例生成对应的oop，然后通过常量池缓存下标索引设置到_resolved_references中。当下次查找时，通过这个常量池缓存下标缓存找到表示字符串的oop。

获取到_resolved_references属性的值后接着看生成的汇编代码，如下：

// …
// %eax中存储着表示字符串的oop
0x00007fffe1024479: test %eax,%eax
// 如果已经获取到了oop，则跳转到resolved
0x00007fffe102447b: jne 0x00007fffe1024481

// 没有获取到oop，需要进行连接操作，0xe5是_fast_aldc的Opcode
0x00007fffe1024481: mov $0xe5,%edx　　

调用call_VM()函数生成的汇编代码如下：

// 调用InterpreterRuntime::resolve_ldc()函数
0x00007fffe1024486: callq 0x00007fffe1024490
0x00007fffe102448b: jmpq 0x00007fffe1024526

// 将%rdx中的ConstantPoolCacheEntry项存储到第1个参数中

// 调用MacroAssembler::call_VM_helper()函数生成
0x00007fffe1024490: mov %rdx,%rsi
// 将返回地址加载到%rax中
0x00007fffe1024493: lea 0x8(%rsp),%rax

// 调用call_VM_base()函数生成
// 保存bcp
0x00007fffe1024498: mov %r13,-0x38(%rbp)

// 调用MacroAssembler::call_VM_base()函数生成

// 将r15中的值移动到c_rarg0(rdi)寄存器中，也就是为函数调用准备第一个参数
0x00007fffe102449c: mov %r15,%rdi
// Only interpreter should have to set fp 只有解释器才必须要设置fp
0x00007fffe102449f: mov %rbp,0x200(%r15)
0x00007fffe10244a6: mov %rax,0x1f0(%r15)

// 调用MacroAssembler::call_VM_leaf_base()生成
0x00007fffe10244ad: test $0xf,%esp
0x00007fffe10244b3: je 0x00007fffe10244cb
0x00007fffe10244b9: sub $0x8,%rsp
0x00007fffe10244bd: callq 0x00007ffff66b27ac
0x00007fffe10244c2: add $0x8,%rsp
0x00007fffe10244c6: jmpq 0x00007fffe10244d0
0x00007fffe10244cb: callq 0x00007ffff66b27ac
0x00007fffe10244d0: movabs $0x0,%r10
// 结束调用MacroAssembler::call_VM_leaf_base()

0x00007fffe10244da: mov %r10,0x1f0(%r15)
0x00007fffe10244e1: movabs $0x0,%r10

// 检查是否有异常发生
0x00007fffe10244eb: mov %r10,0x200(%r15)
0x00007fffe10244f2: cmpq $0x0,0x8(%r15)
// 如果没有异常发生，则跳转到ok
0x00007fffe10244fa: je 0x00007fffe1024505
// 有异常发生，则跳转到StubRoutines::forward_exception_entry()
0x00007fffe1024500: jmpq 0x00007fffe1000420

// ---- ok ----

// 将JavaThread::vm_result属性中的值存储到oop_result寄存器中并清空vm_result属性的值
0x00007fffe1024505: mov 0x250(%r15),%rax
0x00007fffe102450c: movabs $0x0,%r10
0x00007fffe1024516: mov %r10,0x250(%r15)

// 结果调用MacroAssembler::call_VM_base()函数

// 恢复bcp和locals
0x00007fffe102451d: mov -0x38(%rbp),%r13
0x00007fffe1024521: mov -0x30(%rbp),%r14

// 结束调用InterpreterMacroAssembler::call_VM_base()函数
// 结束调用MacroAssembler::call_VM_helper()函数

0x00007fffe1024525: retq

// 结束调用MacroAssembler::call_VM()函数，回到
// TemplateTable::fast_aldc()函数继续看生成的代码，只
// 定义了resolved点

// ---- resolved ----　　

调用的InterpreterRuntime::resolve_ldc()函数的实现如下：

IRT_ENTRY(void, InterpreterRuntime::resolve_ldc(
JavaThread* thread,
Bytecodes::Code bytecode)
) {
ResourceMark rm(thread);
methodHandle m (thread, method(thread));
Bytecode_loadconstant ldc(m, bci(thread));
oop result = ldc.resolve_constant(CHECK);

thread->set_vm_result(result);
}
IRT_END

这个函数会调用一系列的函数，相关调用链如下：

ConstantPool::string_at_put() constantPool.hpp
ConstantPool::string_at_impl() constantPool.cpp
ConstantPool::resolve_constant_at_impl() constantPool.cpp
ConstantPool::resolve_cached_constant_at() constantPool.hpp
Bytecode_loadconstant::resolve_constant() bytecode.cpp
InterpreterRuntime::resolve_ldc() interpreterRuntime.cpp 　　

其中ConstantPool::string_at_impl()函数在前面已经详细介绍过。

调用的resolve_constant()函数的实现如下：

oop Bytecode_loadconstant::resolve_constant(TRAPS) const {
int index = raw_index();
ConstantPool* constants = _method->constants();
if (has_cache_index()) {
return constants->resolve_cached_constant_at(index, THREAD);
} else {
return constants->resolve_constant_at(index, THREAD);
}
}

调用的resolve_cached_constant_at()或resolve_constant_at()函数的实现如下：

oop resolve_cached_constant_at(int cache_index, TRAPS) {
constantPoolHandle h_this(THREAD, this);
return resolve_constant_at_impl(h_this, _no_index_sentinel, cache_index, THREAD);
}

oop resolve_possibly_cached_constant_at(int pool_index, TRAPS) {
constantPoolHandle h_this(THREAD, this);
return resolve_constant_at_impl(h_this, pool_index, _possible_index_sentinel, THREAD);
}

调用的resolve_constant_at_impl()函数的实现如下：

oop ConstantPool::resolve_constant_at_impl(
constantPoolHandle this_oop,
int index,
int cache_index,
TRAPS
) {
oop result_oop = NULL;
Handle throw_exception;

if (cache_index == _possible_index_sentinel) {
cache_index = this_oop->cp_to_object_index(index);
}

if (cache_index >= 0) {
result_oop = this_oop->resolved_references()->obj_at(cache_index);
if (result_oop != NULL) {
return result_oop;
}
index = this_oop->object_to_cp_index(cache_index);
}

jvalue prim_value; // temp used only in a few cases below

int tag_value = this_oop->tag_at(index).value();

switch (tag_value) {
// …
case JVM_CONSTANT_String:
assert(cache_index != _no_index_sentinel, "should have been set");
if (this_oop->is_pseudo_string_at(index)) {
result_oop = this_oop->pseudo_string_at(index, cache_index);
break;
}
result_oop = string_at_impl(this_oop, index, cache_index, CHECK_NULL);
break;
// …
}

if (cache_index >= 0) {
Handle result_handle(THREAD, result_oop);
MonitorLockerEx ml(this_oop->lock());
oop result = this_oop->resolved_references()->obj_at(cache_index);
if (result == NULL) {
this_oop->resolved_references()->obj_at_put(cache_index, result_handle());
return result_handle();
} else {
return result;
}
} else {
return result_oop;
}
}

通过常量池的tags数组判断，如果常量池下标index处存储的是JVM_CONSTANT_String常量池项，则调用string_at_impl()函数，这个函数在之前已经介绍过，会根据表示字符串的Symbol实例创建出表示字符串的oop。在ConstantPool::resolve_constant_at_impl()函数中得到oop后就存储到ConstantPool::_resolved_references属性中，最后返回这个oop，这正是ldc需要的oop。　

通过重写fast_aldc字节码指令，达到了通过少量指令就直接获取到oop的目的，而且oop是缓存的，所以字符串常量在HotSpot VM中的表示唯一，也就是只有一个oop表示。　

C++函数约定返回的值会存储到%rax中，根据_fast_aldc字节码指令的模板定义可知，tos_out为atos，所以后续并不需要进一步操作。

HotSpot VM会在类的连接过程中重写某些字节码，如ldc字节码重写为fast_aldc，还有常量池的tags类型数组、常量池缓存等内容在《深入剖析Java虚拟机：源码剖析与实例详解》中详细介绍过，这里不再介绍。