JVM 模板直譯器之位元組碼的resolve過程

foreach_break發表於2015-08-09
JVM

1、背景

上文探討了：【JVM】模板直譯器–如何根據位元組碼生成彙編碼？

本篇，我們來關注下位元組碼的resolve過程。

2、問題及準備工作

上文雖然探討了位元組碼到彙編碼的過程，但是：

mov %rax,%(rcx,rbx,1) // 0x89 0x04 0x19

其中為什麼要指定0×04和0×19呢？

搬出我們的程式碼：

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的。

  1. 對給定的bytecode，在cp cache中查詢是否已經存在，如果不存在要進行resolve.至於cp cache問題，最後再說。
  2. 進行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過程。

相關文章