某某茶叶有限公司欢迎您!
金沙棋牌在线 > 金沙棋牌在线 > AST解释器和字节码解释器

AST解释器和字节码解释器

时间:2019-12-29 06:39

1、背景

上文探讨了:【JVM】模板解释器–如何根据字节码生成汇编码?

本篇,我们来关注下字节码的resolve过程。

1、背景

仅针对JVM的模板解释器:

如何根据opcode和寻址模式,将bytecode生成汇编码。

本文的示例中所使用的字节码和汇编码,请参见上篇博文:按值传递还是按引用?

闲来无事,编译调试了下OpenJDK9,仔细研究了下HotSpot中的模板解释器。

自己原来做过一个编译相关的项目(全局优化问题变量相关性分组软件的实现),用的是字节码解释器,没有用AST解释器。当时基于的考虑是实现起来简单清晰,好调试,不像AST那么复杂,自己心中也是一直有个疑问,到底哪种方法更好?今天总结一下。
字节码结构更紧凑,内存局部性好,解释执行性能高。
从工程上说,字节码解释器也有利于把代码组织得更清晰,把关注点清晰的分离开来。
AST解释器有一些额外的开销,而字节码解释器可以节省这些开销。
AST解释器开销在于:

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
  // ...
}

2、寻址模式

本文不打算深入展开寻址模式的阐述,我们聚焦Intel的IA32-64架构的指令格式:

图片 1

简要说明下,更多的请参考intel的手册:

– Prefixes : 用于修饰操作码Opcode,赋予其lock、repeat等的语义.
– REX Prefix
—- Specify GPRs and SSE registers.
—- Specify 64-bit operand size.
—- Specify extended control registers.
Opcode:操作码,如mov、push.
Mod R/M:寻址相关,具体见手册。
SIB:和Mod R/M结合起来指定寻址。
Displacement:配合Mod R/M和SIB指定寻址。
Immediate:立即数。

对上面的Opcode、Mod R/W、SIB、disp、imm如果不明白,看句汇编有个概念:

%mov %eax , %rax,-0x18(%rcx,%rbx,4)

如果这句汇编也不太明白,那么配合下面的:

– Base + (Index ∗ Scale) + Displacement – Using all the addressing components together allows efficient
indexing of a two-dimensional array when the elements of the array are 2, 4, or 8 bytes in size.

C和C++之类的语言,会在编译期就直接编译成平台相关的机器指令,对于不同平台,可执行文件类型也不一样,如Linux为ELF,Windows为PE,而MacOS为Mach-O。而写Java的应该都清楚,java之所以跨平台性比较强,是因为Java在编译期没有被直接编译成机器指令,而是被编译成一种中间语言:字节码。

  1. AST上有些没有执行语义的节点,但解释器在执行时不得不访问它们,增加了解释开销。SquirrelFish文中用语句块(block)的举例,这个不错:一个block仅用于把一堆语句聚合在一起,自身并没有“有效的”执行语义,但解释器为了访问到这个block的子节点却不得不访问这个block。AST的节点种类相对于解析树(parse tree)通常要精简许多(括号、分号之类的token通常都扔掉了),但用于解释执行还是不够精简。
  2. AST通常使用链式结构实现(父节点用指针指向子节点),解释执行需要遍历AST,就得跟随这些指针不断做间接访问。外加AST常会携带一些跟解释执行没直接关系的额外信息,这使得AST节点比较“肥”,占用更多内存,而对解释执行有用的信息在内存里分隔得更开,不紧凑。
  3. AST中每种节点的结构未必相同,有多少个子节点、哪些子节点有用、要按什么顺序去访问那些子节点,都需要针对每种节点专门实现;换句话说,必须确定了节点种类才能确定遍历顺序,这也不利于解释器实现得紧凑。
  4. AST解释器的核心遍历逻辑最自然的实现方式是递归;当然,执行状态得顺着递归通过参数传递。(SquirrelFish文中还提到AST解释器要在节点间传递状态带来额外开销。这主要是以前的JavaScriptCore的实现太纱布了,不能怪AST解释器本身的概念不好⋯)

3、field、class的符号解析及链接

3、合法的值(64位)

关注下这4个参数的合法取值:

• Displacement — An 8-bit, 16-bit, or 32-bit value.
• Base — The value in a 64-bit general-purpose register.
• Index — The value in a 64-bit general-purpose register.
• Scale factor — A value of 2, 4, or 8 that is multiplied by the index value.

2016年我读完周志明的《深入理解Java虚拟机》后,不觉过瘾,便紧接着看完了张秀宏老师的《自己动手写Java虚拟机》,书中关于如何实现一个小型JVM做了详细讲解,其中一部分就是讲如何执行Class文件中方法体的字节码。

什么是语法制导翻译?

解释器边做语法分析边执行相应位置的语义动作(semantic action)而不构建AST(例如计算器,针对语义,直接执行相应的操作),于是在完成语法分析的时候也就完成了解释执行。假如不直接做解释执行,这些语义动作也可以用来生成代码(例如字节码),边做语法分析边完成了代码生成,中间也不需要AST。理解语法制导翻译的最重要的一点就是:那些嵌在语法里的语义动作,都可以看作epsilon匹配——匹配空字符串,也就是总是可以匹配——匹配到它们的时候就执行里面的代码。这样就很好理解这些代码是什么时候执行的,而它能访问到的上下文都是怎样的。

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);
}

上面的代码又有两个关键点:

4、Mod R/M(32位寻址)

我们在后文将会用到Mod R/M字节,所以将32位寻址的格式贴在这里:

图片 2

上表的备注,其中第1条将在我们的示例中用到,所以这里留意下:

  1. The [--][--] nomenclature means a SIB follows the ModR/M byte.
  2. The disp32 nomenclature denotes a 32-bit displacement that follows the ModR/M byte (or the SIB byte if one is present) and that is
    added to the index.
  3. The disp8 nomenclature denotes an 8-bit

《自己动手写Java虚拟机》中对于字节码的执行其实就是简单的翻译,比如要实现iload指令(将指定的 int 型局部变量推送至栈顶),其实就用GO(这本书用GO来实现JVM的)来实现其对应的功能:

参考资料:

  1. 为什么大多数解释器都将AST转化成字节码再用虚拟机执行,而不是直接解释AST?
  2. 符号表和抽象语法树是什么关系?两者在编译器设计中是否必需?
  3. 值得推荐的入门书(RednaxelaFX书评)
  4. 虚拟机随谈(一):解释器,树遍历解释器,基于栈与基于寄存器,大杂烩
  5. 《自制编程语言》集中讨论帖

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

5、SIB(32位寻址)

同样,因为用到了Mod R/M字节,那么SIB字节也可能要用到:

图片 3

func _iload(frame *rtda.Frame, index uint) { val := frame.LocalVars().GetInt frame.OperandStack().PushInt}

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)顶的东东的类型.

上面的代码中又标出一个关键点:

6、示例

当执行方法中的iload指令时,就直接调用该_iload()方法即可。

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_klassresolve_field,我们一个一个看,

6.1、准备工作

来看个实际的例子。

下面的代码是生成mov汇编码:

void Assembler::movl(Address dst, Register src) {
  InstructionMark im(this);
  prefix(dst, src);
  emit_int8((unsigned char)0x89);
  emit_operand(src, dst);
}

prefix(dst,src)就是处理prefix和REX prefix,这里我们不关注。

emit_int8((unsigned char) 0x89)顾名思义就是生成了一个字节,那字节的内容0×89代表什么呢?

先不急,还有一句emit_operand(src,dst),这是一段很长的代码,我们大概看下:

void Assembler::emit_operand(Register reg, Register base, Register index,
                 Address::ScaleFactor scale, int disp,
                 RelocationHolder const& rspec,
                 int rip_relative_correction) {
  relocInfo::relocType rtype = (relocInfo::relocType) rspec.type();

  // Encode the registers as needed in the fields they are used in

  int regenc = encode(reg) << 3;
  int indexenc = index->is_valid() ? encode(index) << 3 : 0;
  int baseenc = base->is_valid() ? encode(base) : 0;

  if (base->is_valid()) {
    if (index->is_valid()) {
      assert(scale != Address::no_scale, "inconsistent address");
      // [base + index*scale + disp]
      if (disp == 0 && rtype == relocInfo::none  &&
          base != rbp LP64_ONLY(&& base != r13)) {
        // [base + index*scale]
        // [00 reg 100][ss index base]

        /**************************
        * 关键点:关注这里
        **************************/

        assert(index != rsp, "illegal addressing mode");
        emit_int8(0x04 | regenc);
        emit_int8(scale << 6 | indexenc | baseenc);
      } else if (is8bit(disp) && rtype == relocInfo::none) {
        // ...
      } else {
        // [base + index*scale + disp32]
        // [10 reg 100][ss index base] disp32
        assert(index != rsp, "illegal addressing mode");
        emit_int8(0x84 | regenc);
        emit_int8(scale << 6 | indexenc | baseenc);
        emit_data(disp, rspec, disp32_operand);
      }
    } else if (base == rsp LP64_ONLY(|| base == r12)) {
      // ... 
    } else {

      // ... 
    }
  } else {
    // ... 
  }
}

上面的代码的关注点已经标出,这里我们将其抽出,并将前文中的emit_int8((unsigned char) 0x89)结合起来:

emit_int8((unsigned char) 0x89)
emit_int8(0x04 | regenc);
emit_int8(scale << 6 | indexenc | baseenc);

最终其生成了如下的汇编代码(64位机器):

mov    %eax,(%rcx,%rbx,1)

好了,问题来了:

上面这句汇编怎么得出的?

这种解释器简单明了,而且容易理解,要是让我们来实现虚拟机,估计想到的也是这种方法(虽然我没有那个能力)。早期的HotSpot就是通过上面这种方法来解释执行字节码指令的,这种解释器有个通用的称呼:字节码解释器。目前HotSpot中还保留着字节码解释器,只不过没有使用了。

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。

6.2、计算过程

我们给个下面的值:

regenc = 0x0,scale << 6 | indexenc | baseenc = 25

进行简单的运算就可以得到:

emit_int8((unsigned char) 0x89) //得到0x89
emit_int8(0x04 | regenc); //得到0x04
emit_int8(scale << 6 | indexenc | baseenc); //得到0x19

合起来就是三个字节:

0x89 0x04 0x19

1、0×89对应什么?

图片 4

从上表可以看出因为JVM工作在64位下,所以需要配合REX.W来“起头”,不过在我们这个例子中,其恰好是0。

主要看那个89/r:

MOV r/m64,r64 //64位,将寄存器中的值给到寄存器或者内存地址中

2、0×04代表什么?

现在我们要用到上面的Mod R/M表和SIB表了。

用第二个字节0×04查Mod R/M表,可知源操作数是寄存器EAX,同时可知寻址类型是[--][--]类型,含义为:

The [--][--] nomenclature means a SIB follows the ModR/M byte.

3、0×19代表什么?

继续查SIB表,对应字节0×19的是:

base = ECX
scaled index = EBX

4、汇编代码:

//32位
mov %eax,%(ecx,ebx,1)

//64位
mov %rax,%(rcx,rbx,1)

字节码解释器的优点上面已经说过了,但是缺点也很明显:慢。每个字节码指令都要通过翻译执行,虽然在用C++写成的JVM中,类似上面_iload()这样的方法,最后也会被编译成机器指令,但是编译器生成的机器指令很冗余,而CPU本身就是不断取指执行,指令越多,耗时也就越长。对于JVM的解释器来说,其实也就是不断取指执行,如果每个字节码指令的执行时间都很慢,那么整体效率必然很差。

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呢?

7、结语

本文简要探讨了:

如何根据opcode和寻址模式,将bytecode生成汇编码。

早期的字节码解释器既然已经不能适应时代的发展,那么JVM的工程师想出了什么优化呢?上面提到字节码解释器慢是因为编译器生成的机器指令不够理想,那么我们直接跳过编译器,自己动手写汇编代码不就行了。没错,现在的HotSpot就是这样干的,这种解释器便称为模板解释器。

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的一个整形映射。

模板解释器相对于为每一个指令都写了一段实现对应功能的汇编代码,在JVM初始化时,汇编器会将汇编代码翻译成机器指令加载到内存中,比如执行iload指令时,直接执行对应的汇编代码即可。如何执行汇编代码?直接跳往汇编代码生成的机器指令在内存中的地址即可。HotSpot中很多地方都是利用手动汇编代码来优化效率的,在我的文章《JVM方法执行的来龙去脉》中也提到,方法的调用也是通过手动汇编代码来执行的。

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是个什么解释器,和模板解释器有啥关系,后面再说吧。

1:模板的初始化及机器指令的生成

4、结语

本文简要探讨了:

字节码的resolve过程。

我们平时说的iload指令等,其实都只是字节码指令的助记符,帮助我们理解,真正的自己码指令其实就是一个数字,比如iload是21,虚拟机执行21这个指令时,就是执行iload。字节码指令定义在bytecodes.hpp中:

class Bytecodes: AllStatic { public: enum Code { _illegal = -1, // Java bytecodes _nop = 0, // 0x00 _aconst_null = 1, // 0x01 _iconst_m1 = 2, // 0x02 _iconst_0 = 3, // 0x03 _iconst_1 = 4, // 0x04 _iconst_2 = 5, // 0x05 _iconst_3 = 6, // 0x06 _iconst_4 = 7, // 0x07 _iconst_5 = 8, // 0x08 _lconst_0 = 9, // 0x09 ...... }}