1、背景##
上文探討了：【JVM】模板解釋器--如何根據字節碼生成匯編碼？
本篇，我們來關注下字節碼的resolve過程。
2、問題及准備工作##
上文雖然探討了字節碼到匯編碼的過程，但是：
mov %rax,%(rcx,rbx,1) // 0x89 0x04 0x19
其中為什么要指定0x04和0x19呢？
搬出我們的代碼：
public int swap2(CallBy a,CallBy b) {
int t = a.value;
a.value = b.value;
b.value = t;
return t;
}
換句話講，我們的匯編代碼是要將b.value賦給a.value：
//b.value怎么來的呢？
a.value = b.value
b.value是個整形的field，上述代碼的關鍵字節碼是putfield，而模板解釋器在初始化的時候（非運行時，這也是模板的意義所在）會調用下面的函數來生成對應的匯編碼：
void TemplateTable::putfield_or_static(int byte_no, bool is_static) {
transition(vtos, vtos);
const Register cache = rcx;
const Register index = rdx;
const Register obj = rcx;
const Register off = rbx;
const Register flags = rax;
const Register bc = c_rarg3;
/********************************
* 關鍵：這個函數在做什么？
********************************/
resolve_cache_and_index(byte_no, cache, index, sizeof(u2));
jvmti_post_field_mod(cache, index, is_static);
// 上面resolve后，直接從cp cache中對應的entry中就可以獲取到field
load_field_cp_cache_entry(obj, cache, index, off, flags, is_static);
// [jk] not needed currently
// volatile_barrier(Assembler::Membar_mask_bits(Assembler::LoadStore |
// Assembler::StoreStore));
Label notVolatile, Done;
__ movl(rdx, flags);
__ shrl(rdx, ConstantPoolCacheEntry::is_volatile_shift);
__ andl(rdx, 0x1);
// field address
const Address field(obj, off, Address::times_1);
Label notByte, notInt, notShort, notChar,
notLong, notFloat, notObj, notDouble;
__ shrl(flags, ConstantPoolCacheEntry::tos_state_shift);
assert(btos == 0, "change code, btos != 0");
__ andl(flags, ConstantPoolCacheEntry::tos_state_mask);
__ jcc(Assembler::notZero, notByte);
// btos
// ...
// atos
// ...
// itos
{
/***************************************
* itos類型，我們的b.value是個整形，
* 所以對應的機器級別的類型是i，表示整形
****************************************/
__ pop(itos);
if (!is_static) pop_and_check_object(obj);
// 這里就是生成匯編碼，也就是上篇博文探討的主要內容了
__ movl(field, rax);
if (!is_static) {
patch_bytecode(Bytecodes::_fast_iputfield, bc, rbx, true, byte_no);
}
__ jmp(Done);
}
__ bind(notInt);
__ cmpl(flags, ctos);
__ jcc(Assembler::notEqual, notChar);
// ctos
// ...
// stos
// ...
// ltos
// ...
// ftos
// ...
// dtos
// ...
// Check for volatile store
// ...
}
3、field、class的符號解析及鏈接##
3.1、resolve_cache_and_index###
來看看上面代碼中的關鍵點：
// 1. 根據不同的字節碼，選擇對應的resolve函數.
// 2. 調用resolve函數.
// 3. 根據resolve后的結果，更新寄存器信息，做好銜接.
void TemplateTable::resolve_cache_and_index(int byte_no,
Register Rcache,
Register index,
size_t index_size) {
const Register temp = rbx;
assert_different_registers(Rcache, index, temp);
Label resolved;
assert(byte_no == f1_byte || byte_no == f2_byte, "byte_no out of range");
/****************
* 關鍵點1
*****************/
__ get_cache_and_index_and_bytecode_at_bcp(Rcache, index, temp, byte_no, 1, index_size);
__ cmpl(temp, (int) bytecode()); // have we resolved this bytecode?
__ jcc(Assembler::equal, resolved);
// resolve first time through
address entry;
switch (bytecode()) {
case Bytecodes::_getstatic:
case Bytecodes::_putstatic:
case Bytecodes::_getfield:
case Bytecodes::_putfield:
/****************
* 關鍵點2
*****************/
entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_get_put);
break;
// ...
default:
fatal(err_msg("unexpected bytecode: %s", Bytecodes::name(bytecode())));
break;
}
//
__ movl(temp, (int) bytecode());
__ call_VM(noreg, entry, temp);
//
// Update registers with resolved info
__ get_cache_and_index_at_bcp(Rcache, index, 1, index_size);
__ bind(resolved);
}
上面的代碼又有兩個關鍵點：
3.2、get_cache_and_index_and_bytecode_at_bcp###
--get_cache_and_index_and_bytecode_at_bcp函數，主要做的一些工作如下文所述。
cp cache指ConstantPoolCache，注意這不是一個一般意義上的緩存，其目的是用於解釋器執行時，對字節碼進行resolve的。
- 對給定的bytecode，在cp cache中查找是否已經存在，如果不存在要進行resolve.至於cp cache問題，最后再說。
- 進行resolve的主要內容：
-- InterpreterRuntime::resolve_get_put
-- InterpreterRuntime::resolve_invoke
-- InterpreterRuntime::resolve_invokehandle
-- InterpreterRuntime::resolve_invokedynamic
3.3、resolve_get_put###
因為我們的putfield字節碼會選擇函數resolve_get_put來進行resolve，來關注這個過程：
IRT_ENTRY(void, InterpreterRuntime::resolve_get_put(JavaThread* thread, Bytecodes::Code bytecode))
// resolve field
fieldDescriptor info;
constantPoolHandle pool(thread, method(thread)->constants());
bool is_put = (bytecode == Bytecodes::_putfield || bytecode == Bytecodes::_putstatic);
bool is_static = (bytecode == Bytecodes::_getstatic || bytecode == Bytecodes::_putstatic);
{
JvmtiHideSingleStepping jhss(thread);
/*******************
* 關鍵點
********************/
LinkResolver::resolve_field_access(info, pool, get_index_u2_cpcache(thread, bytecode),
bytecode, CHECK);
} // end JvmtiHideSingleStepping
// check if link resolution caused cpCache to be updated
if (already_resolved(thread)) return;
// compute auxiliary field attributes
TosState state = as_TosState(info.field_type());
Bytecodes::Code put_code = (Bytecodes::Code)0;
InstanceKlass* klass = InstanceKlass::cast(info.field_holder());
bool uninitialized_static = ((bytecode == Bytecodes::_getstatic || bytecode == Bytecodes::_putstatic) &&
!klass->is_initialized());
Bytecodes::Code get_code = (Bytecodes::Code)0;
if (!uninitialized_static) {
get_code = ((is_static) ? Bytecodes::_getstatic : Bytecodes::_getfield);
if (is_put || !info.access_flags().is_final()) {
put_code = ((is_static) ? Bytecodes::_putstatic : Bytecodes::_putfield);
}
}
// 設置cp cache entry
// 1. field的存/取字節碼.
// 2. field所屬的InstanceKlass(Java類在VM層面的抽象)指針.
// 3. index和offset
// 4. field在機器級別的類型狀態.因為機器級別只有i（整）、a（引用）、v(void)等類型，這一點也可以幫助理解為什么解釋器在生成匯編代碼時，需要判斷tos.
// 5. field是否final的.
// 6. field是否volatile的.
// 7. 常量池的holder（InstanceKlass*類型）.
cache_entry(thread)->set_field(
get_code,
put_code,
info.field_holder(),
info.index(),
info.offset(),
state,
info.access_flags().is_final(),
info.access_flags().is_volatile(),
pool->pool_holder()
);
IRT_END
注意tos這個點：
其中，tos是指 T op-- O f-- S tack，也就是操作數棧(vm實現中是expression stack)頂的東東的類型.
上面的代碼中又標出一個關鍵點：
3.4、resolve_field_access###
看代碼：
// 對field進行resolve，並檢查其可訪問性等信息
void LinkResolver::resolve_field_access(fieldDescriptor& result, constantPoolHandle pool, int index, Bytecodes::Code byte, TRAPS) {
// Load these early in case the resolve of the containing klass fails
// 從常量池中獲取field符號
Symbol* field = pool->name_ref_at(index);
// 從常量池中獲取field的簽名符號
Symbol* sig = pool->signature_ref_at(index);
// resolve specified klass
KlassHandle resolved_klass;
// 關鍵點1
resolve_klass(resolved_klass, pool, index, CHECK);
// 關鍵點2
KlassHandle current_klass(THREAD, pool->pool_holder());
resolve_field(result, resolved_klass, field, sig, current_klass, byte, true, true, CHECK);
}
注意到上面的代碼還調用了resolve_klass和resolve_field，我們一個一個看，
3.5、resolve_klass：###
// 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，並同當前線程一起，封裝為一個KlassHandle。
3.6、resolve_field：###
再接着看resolve_field：
// field的解析及鏈接
// 此過程將完成：
//
// 1. field的可訪問性驗證.
// 2. field所屬的類的可訪問性驗證.
// 3. field所屬的類的ClassLoaderData及當前執行的方法（Method）所屬的類的ClassLoaderData的驗證.
// 4. field所屬的類中，如果對其它的類有依賴，要進行裝載、解析和鏈接，如果沒有找到，比如classpath中不包含，那么就報類似ClassDefNotFoundError的異常.
// 如果Jar包沖突，也在這里檢測到，並報異常.
// 如果field所屬的類，及其依賴的類都找到了，那么將ClassLoaderData的約束constraint進行合並.
// 5. 當前正在調用的方法的簽名，從callee角度和caller角度來比較是否一致.
// 關於classLoader的問題，后續文章再展開吧，不是一句兩句能說的清。
void LinkResolver::resolve_field(fieldDescriptor& fd, KlassHandle resolved_klass, Symbol* field, Symbol* sig,
KlassHandle current_klass, Bytecodes::Code byte, bool check_access, bool initialize_class,
TRAPS) {
assert(byte == Bytecodes::_getstatic || byte == Bytecodes::_putstatic ||
byte == Bytecodes::_getfield || byte == Bytecodes::_putfield ||
(byte == Bytecodes::_nop && !check_access), "bad field access bytecode");
bool is_static = (byte == Bytecodes::_getstatic || byte == Bytecodes::_putstatic);
bool is_put = (byte == Bytecodes::_putfield || byte == Bytecodes::_putstatic);
// Check if there's a resolved klass containing the field
if (resolved_klass.is_null()) {
ResourceMark rm(THREAD);
THROW_MSG(vmSymbols::java_lang_NoSuchFieldError(), field->as_C_string());
}
/************************
* 關鍵點1
*************************/
// Resolve instance field
KlassHandle sel_klass(THREAD, resolved_klass->find_field(field, sig, &fd));
// check if field exists; i.e., if a klass containing the field def has been selected
if (sel_klass.is_null()) {
ResourceMark rm(THREAD);
THROW_MSG(vmSymbols::java_lang_NoSuchFieldError(), field->as_C_string());
}
if (!check_access)
// Access checking may be turned off when calling from within the VM.
return;
/************************
* 關鍵點2
*************************/
// check access
check_field_accessability(current_klass, resolved_klass, sel_klass, fd, CHECK);
// check for errors
if (is_static != fd.is_static()) {
// ...
THROW_MSG(vmSymbols::java_lang_IncompatibleClassChangeError(), msg);
}
// Final fields can only be accessed from its own class.
if (is_put && fd.access_flags().is_final() && sel_klass() != current_klass()) {
THROW(vmSymbols::java_lang_IllegalAccessError());
}
// initialize resolved_klass if necessary
// note 1: the klass which declared the field must be initialized (i.e, sel_klass)
// according to the newest JVM spec (5.5, p.170) - was bug (gri 7/28/99)
//
// note 2: we don't want to force initialization if we are just checking
// if the field access is legal; e.g., during compilation
if (is_static && initialize_class) {
sel_klass->initialize(CHECK);
}
if (sel_klass() != current_klass()) {
HandleMark hm(THREAD);
Handle ref_loader (THREAD, InstanceKlass::cast(current_klass())->class_loader());
Handle sel_loader (THREAD, InstanceKlass::cast(sel_klass())->class_loader());
{
ResourceMark rm(THREAD);
/************************
* 關鍵點3
*************************/
Symbol* failed_type_symbol =
SystemDictionary::check_signature_loaders(sig,
ref_loader, sel_loader,
false,
CHECK);
if (failed_type_symbol != NULL) {
// ...
THROW_MSG(vmSymbols::java_lang_LinkageError(), buf);
}
}
}
// return information. note that the klass is set to the actual klass containing the
// field, otherwise access of static fields in superclasses will not work.
}
上面的代碼，我們梳理出三個跟本主題相關的關鍵點，已在注釋中標出，我們來看：
// 關鍵點1 ：
// 獲取field所屬的類或接口對應的klass，或者NULL，如果是NULL就拋異常了
KlassHandle sel_klass(THREAD, resolved_klass->find_field(field, sig, &fd));
// 1. 如果是resolved_klass中的field，返回resolved_klass
// 2. 如果1不滿足，嘗試返回接口或接口的超類（super interface）對應的klass（遞歸）
// 3. 如果1、2點都不滿足，嘗試返回父類或超類對應的klass（遞歸）或者NULL.
Klass* InstanceKlass::find_field(Symbol* name, Symbol* sig, fieldDescriptor* fd) const {
// search order according to newest JVM spec (5.4.3.2, p.167).
// 1) search for field in current klass
if (find_local_field(name, sig, fd)) {
return const_cast<InstanceKlass*>(this);
}
// 2) search for field recursively in direct superinterfaces
{ Klass* intf = find_interface_field(name, sig, fd);
if (intf != NULL) return intf;
}
// 3) apply field lookup recursively if superclass exists
{ Klass* supr = super();
if (supr != NULL) return InstanceKlass::cast(supr)->find_field(name, sig, fd);
}
// 4) otherwise field lookup fails
return NULL;
}
// 關鍵點2：
// 1. resolved_klass來自當前線程所執行的當前方法的當前字節碼所屬的常量池.
// 2. sel_klass是field所屬的類或接口對應的klass
// 3. current_klass是常量池所屬的klass(pool_holder).
// 4. 3種klass可以相同，也可以不同.可以想象一個調用鏈，依賴的各個class.
check_field_accessability(current_klass, resolved_klass, sel_klass, fd, CHECK);
// 關鍵點3：
// ref_loader代表了current_klass的classLoader
Handle ref_loader (THREAD, InstanceKlass::cast(current_klass())->class_loader());
// sel_loader代表了sel_klass的classLoader
Handle sel_loader (THREAD, InstanceKlass::cast(sel_klass())->class_loader());
// 根據簽名符號sig、ref_loader、sel_loader來檢查classLoader的約束是否一致，如果不一致就會拋異常，所謂一致不是相同但包含相同的情況，如果一致，那么就合並約束，同時還要進行依賴（depedencies）鏈的維護.
// 由於內容比較多，本篇不展開.
Symbol* failed_type_symbol =
SystemDictionary::check_signature_loaders(sig,
ref_loader, sel_loader,
false,
CHECK);
上面的關鍵點解析都在注釋中了，其中有的地方內容太多，不宜在本篇展開。
那么，如何獲取當前執行的字節碼對應的cp cache entry呢？
3.7、如何獲取cp cache entry：###
關鍵代碼如下：
// 獲取當前正在執行的bytecode對應的cp cache entry
static ConstantPoolCacheEntry* cache_entry(JavaThread *thread) {
return cache_entry_at(thread, Bytes::get_native_u2(bcp(thread) + 1));
}
// ↓
// 獲取解釋器當前的(B)yte (C)ode (P)ointer，也就是當前指令地址，以指針表達
static address bcp(JavaThread *thread) {
return last_frame(thread).interpreter_frame_bcp();
}
// ↓
// 獲取cp cache entry
static ConstantPoolCacheEntry* cache_entry_at(JavaThread *thread, int i) {
return method(thread)->constants()->cache()->entry_at(i);
}
// ↓
// 獲取當前正在執行的方法
static Method* method(JavaThread *thread) {
return last_frame(thread).interpreter_frame_method();
}
// ↓
// 獲取interpreterState->_method，也就是當前正在執行的方法
Method* frame::interpreter_frame_method() const {
assert(is_interpreted_frame(), "interpreted frame expected");
Method* m = *interpreter_frame_method_addr();
assert(m->is_method(), "not a Method*");
return m;
}
// ↓
// 獲取interpreterState->_method的地址
inline Method** frame::interpreter_frame_method_addr() const {
assert(is_interpreted_frame(), "must be interpreted");
return &(get_interpreterState()->_method);
}
// ↓
// 獲取interpreterState
inline interpreterState frame::get_interpreterState() const {
return ((interpreterState)addr_at( -((int)sizeof(BytecodeInterpreter))/wordSize ));
}
// ↓
// interpreterState實際是個BytecodeInterpreter型指針
typedef class BytecodeInterpreter* interpreterState;
上述過程總結下：
1、獲取bcp，也就是解釋器當前正在執行的字節碼的地址，以指針形式返回.
2、bcp是通過當前線程的調用棧的最后一幀來獲取的，並且是個解釋器棧幀.為什么是最后一幀？
方法1 棧幀1
調用 -> 方法2 棧幀2
...
調用 -> 方法n 棧幀n // 最后一幀
每個方法在調用時都會用一個棧幀frame來描述調用的狀態信息，最后調用的方法就是當前方法，所以是取最后一幀.
3、當前方法的地址是通過棧幀中保存的interpreterState來獲取的，而這個interpreterState是個BytecodeInterpreter型的解釋器，不是模板解釋器。
4、獲取到方法的地址后，就可以獲取到方法所屬的常量池了，接着從常量池對應的cp cache中就可以獲取到對應的entry了。
5、第4點提到對應，怎么個對應法？想象數組的下標，這個下標是什么呢？就是對bcp的一個整形映射。
3.8、BytecodeInterpreter的一些關鍵字段###
注意BytecodeInterpreter和TemplateInterpreter不是一碼事.
BytecodeInterpreter的一些關鍵字段，幫助理解bcp、thread、cp、cp cache在解釋器棧幀中意義：
private:
JavaThread* _thread; // the vm's java thread pointer
address _bcp; // instruction pointer
intptr_t* _locals; // local variable pointer
ConstantPoolCache* _constants; // constant pool cache
Method* _method; // method being executed
DataLayout* _mdx; // compiler profiling data for current bytecode
intptr_t* _stack; // expression stack
messages _msg; // frame manager <-> interpreter message
frame_manager_message _result; // result to frame manager
interpreterState _prev_link; // previous interpreter state
oop _oop_temp; // mirror for interpreted native, null otherwise
intptr_t* _stack_base; // base of expression stack
intptr_t* _stack_limit; // limit of expression stack
BasicObjectLock* _monitor_base; // base of monitors on the native stack
在進行resolve后，字節碼就在ConstantPoolCache對應的Entry中了，下一次再執行就不需要resolve。
至於BytecodeInterpreter是個什么解釋器，和模板解釋器有啥關系，后面再說吧。
4、結語##
本文簡要探討了：
字節碼的resolve過程。
終。