1、背景
上文探討了：【JVM】模板直譯器–如何根據位元組碼生成彙編碼？
本篇，我們來關注下位元組碼的resolve過程。
2、問題及準備工作
上文雖然探討了位元組碼到彙編碼的過程，但是：
|
1 |
mov %rax,%(rcx,rbx,1) // 0x89 0x04 0x19 |
其中為什麼要指定0x04和0x19呢？
搬出我們的程式碼：
|
1 2 3 4 5 6 |
public int swap2(CallBy a,CallBy b) { int t = a.value; a.value = b.value; b.value = t; return t; } |
換句話講，我們的彙編程式碼是要將b.value賦給a.value：
|
1 2 |
//b.value怎麼來的呢？ a.value = b.value |
b.value是個整形的field，上述程式碼的關鍵位元組碼是putfield，而模板直譯器在初始化的時候（非執行時，這也是模板的意義所在）會呼叫下面的函式來生成對應的彙編碼：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 |
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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
// 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，來關注這個過程：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
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
看程式碼：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
// 對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：
|
1 2 3 4 5 |
// 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：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 |
// 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
// 關鍵點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：
關鍵程式碼如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
// 獲取當前正在執行的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 2 3 4 |
方法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在直譯器棧幀中意義：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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過程。
終。