JVM 解释器优化(JAMVM)
简介
在前面的文章中有介绍过 miniJVM 的具体实现，但是 miniJVM 的解释器部分仍然是比较简单的 Switch 指令分发，从执行效率上来说是比较落后的。
同样是轻量级的 JVM，jamvm 在性能方面就要优秀很多，最新版本 2.0.0 支持了 openjdk8，并且支持 java 8 的所有特性，包括 miniJVM 不支持的 Reference。
jamvm 已经非常古老了，Android Framework 在研发阶段还是使用的 jamvm 作为临时的 java 虚拟机，直到 Android 正式发布时才替换成了 DVM
同时 jamvm 的最新版本是实现了一些现代 JVM 的一些关键优化技术的，例如栈顶缓存，direct-threaded，代码拷贝 jit 等。
下面就逐个介绍一下 jamvm 解释器的几种关键优化技术
带注释的 Repo: https://github.com/ganyao114/jamvm-2.0.0
栈顶缓存
我们知道 Java 原生的字节码是基于栈的，寄存器被转抽象成操作数栈，以此来提供更高的平台兼容性能。 但是这里就产生了性能问题。
还是以 1 + 2 为例
JVM 基于栈解释执行：
常量 1 入栈 ----- 1读1写
常量 2 入栈 ----- 1读1写
1 出栈给临时变量 a ----- 1读1写
2 出栈给临时变量 b ----- 1读1写
a + b -------- 2读
结果 3 入栈 ----- 1写
基于栈发生了 7 次内存读，5 次内存写
如果启用栈顶缓存，那么，栈操作将被替换成解释器方法内部的本地变量的付值操作。而这个本地变量在编译器的优化下在寄存器上分配，那么本来的内存操作就成了寄存器操作。因为寄存器的速度远远大于内存。
那么使用栈顶缓存：
常量 1 给寄存器 a ----- 1 读
常量 2 给寄存器 b ------ 1读
寄存器 a + 寄存器 b
结果 3 入栈 ------ 1 写
优化之后仅有 2 次内存读，1 次内存写，以及寄存器操作
JAMVM 栈顶缓存
下面就来看一下 JAMVM 栈顶缓存的实现
首先确定栈顶缓存的主题，用于模拟寄存器的本地变量的定义
#ifdef USE_CACHE
union {
struct {
uintptr_t v1;
uintptr_t v2;
} i;
int64_t l;
} cache;
#endif
可以看到在联合体内使用 v1，v2 来模拟寄存器，也就是说可以缓存栈顶两个 int 长度数据，以及一个 long 型数据
除此之外，为了保证编译器能将 v1 v2 分配到真机的寄存器上，解释器的方法没有任何参数，毕竟前4个参数是要占用寄存器的
实际所要执行的方法体等参数都被放在了每个线程独立的 Env 中的栈帧中
//解释执行 Java 方法
//这个方法不带参数想必是不想让参数占用宝贵的寄存器
uintptr_t *executeJava() {
//保存解释器状态的变量定义。这些对于所有解释器变体都是通用的
uintptr_t *arg1;
//PC 指针
register CodePntr pc;
//取出当前方法栈，和其中的操作数栈与本地变量栈
ExecEnv *ee = getExecEnv();
Frame *frame = ee->last_frame;
//本地变量栈指针存在寄存器中，因为这样每次查找本地变量时可以节省一次内存寻址
register uintptr_t *lvars = frame->lvars;
//操作数栈同理
register uintptr_t *ostack = frame->ostack;
//方法所在对象
Object *this = (Object*)lvars[0];
//方法结构体
MethodBlock *new_mb, *mb = frame->mb;
//常量池
ConstantPool *cp = &(CLASS_CB(mb->class)->constant_pool);
...........
}
在开启栈顶缓存之后，每当有入栈指令时，实际会将入栈操作改成给寄存器付值操作
#ifdef USE_CACHE
//本来 PUSH_0 是将常量推入操作数栈
//现在使用栈顶缓存的话，就直接将常量付值给 cache 中的 v1 模拟寄存器
#define PUSH_0(value, ins_len) \
cache.i.v1 = value; \
DISPATCH(1, ins_len);
#else
#define PUSH_0(value, ins_len) { \
uintptr_t tos = value; \
*ostack++ = tos; \
DISPATCH(0, ins_len); \
}
#endif
这里 PUSH_0 指令被替换成给 v1 寄存器付目标值
当遇到需要使用栈内数据的指令时
例如双目运算操作
并且由于只有 v1 v2 两个缓存寄存器，所以这里运算分为 3 个等级：
- 等级1: 不使用栈顶缓存，则栈中 1，2 操作数相加
- 等级2:使用1个栈顶缓存，则 v1 虚拟寄存器与栈中另一个操作数相加
- 等级3:两个操作数都使用栈顶缓存，则是 v1 和 v2 相加
#define BINARY_OP_0(OP) \
ostack -= 2; \
PUSH_0((int)ostack[0] OP (int)ostack[1], 1);
#define BINARY_OP_1(OP) \
PUSH_0((int)*--ostack OP (int)cache.i.v1, 1);
#define BINARY_OP_2(OP) \
PUSH_0((int)cache.i.v1 OP (int)cache.i.v2, 1);
#define INTDIV(OP, dividend, divisor) \
{ \
int v1 = dividend; int v2 = divisor; \
PUSH_0(v1 OP (INTDIV_OVERFLOW(v1, v2) ? 1 : v2), 1); \
}
Direct Threaded
JAMVM 执行字节码有 3 种方式
- 和 miniJVM 一样的 Switch 解释器
- 这次要讲的 Direct Threaded，也就是使用 goto 跳转到下一个指令
- 执行 Copy JIT 之后的代码
JAMVM 中使用了大量的宏来控制解释器运行模式，在解释器方法头部有个 INTERPRETER_PROLOGUE 的宏，它有三种实现：
- 仅仅使用 Switch 解释器时：
#define INTERPRETER_PROLOGUE \
DISPATCH_PROLOGUE \
jam_printf("Unrecognised opcode %d in: %s.%s\n", \
*pc, CLASS_CB(mb->class)->name, mb->name); \
exitVM(1);
//循环分发代码
#define DISPATCH_PROLOGUE \
while(TRUE) { \
switch(*pc) { \
default:
宏展开
while(true) {
switch(*pc) {
label_op_1:
label_op_2:
label_op_3:
label_op_n:
.......
}
}
- 使用 Direct Threaded 但不使用 JIT 时
#define INTERPRETER_PROLOGUE \
unused: \
rewrite_lock: \
DISPATCH_FIRST
#ifdef PREFETCH
#define DISPATCH_FIRST \
{ \
next_handler = pc[1].handler; \
REDISPATCH \
}
#define REDISPATCH \
goto *pc->handler;
#else
#define DISPATCH_FIRST \
REDISPATCH
宏展开
unused:
rewrite_lock:
{
next_handler = pc[1].handler;
goto *pc->handler;
}
- 当使用 Copy JIT 时
#define INTERPRETER_PROLOGUE \
GCC_HACK \
\
rewrite_lock: \
DISPATCH_FIRST \
\
unused: \
throwOOBLabel = NULL; \
throwNullLabel = NULL; \
throwArithmeticExcepLabel = NULL;
#define DISPATCH_FIRST \
goto *pc->handler;
和上面的差不多
所谓 Direct Threaded，就是在解释器方法体内部定义一堆 label，把原来的循环体 Switc Case 跳转换成 goto，这样可以节省 Case 比较的过程
Direct 执行的优化和准备工作
当启用 Direct Threaded 的时候，JAMVM 需要在第一次调用一个方法的时候去遍历这个方法内的每一行指令，这里有以下几个目的
- 为栈顶缓存收集每个指令需要匹配的优化等级，上文已经解释过了一共有 3 个等级
- 为后面的 JIT 收集必要数据
- 修改指令，将原始字节码中的一些指令替换为 JAMVM 中自定义的伪指令，用于适应 goto 跳转执行的环境，以及 JIT 后的跳转。
- 匹配一些可以优化的代码 Case，并且替换为优化后的指令
准备栈顶缓存等级
case OPC_LCONST_0: case OPC_DCONST_0: case OPC_DCONST_1:
case OPC_LCONST_1: case OPC_LLOAD_0: case OPC_DLOAD_0:
case OPC_LLOAD_1: case OPC_DLOAD_1: case OPC_LLOAD_2:
case OPC_DLOAD_2: case OPC_LLOAD_3: case OPC_DLOAD_3:
case OPC_LALOAD: case OPC_DALOAD: case OPC_DUP_X1:
case OPC_DUP_X2: case OPC_DUP2: case OPC_DUP2_X1:
case OPC_DUP2_X2: case OPC_SWAP: case OPC_LADD:
case OPC_LSUB: case OPC_LMUL: case OPC_LDIV:
case OPC_LREM: case OPC_LAND: case OPC_LOR:
case OPC_LXOR: case OPC_LSHL: case OPC_LSHR:
case OPC_LUSHR: case OPC_F2L: case OPC_D2L:
case OPC_LNEG: case OPC_I2L:
#ifdef USE_CACHE
//LONG 需要64位寄存器 Cache
cache = 2;
pc += 1;
break;
#endif
可以看到以上所有指令都是要将一个 long 型 或者 doubele 型数据入栈，那么这就需要使用到 2 个寄存器的缓存空间
指令修正
主要需要修正 opcode 中的操作数，因为一些优化指令的更改会造成指令地址的改变，那么原始操作数中大量存在的偏移就回出错
case OPC_SIPUSH:
operand.i = READ_S2_OP(code + pc);
#ifdef USE_CACHE
if(cache < 2)
cache++;
#endif
pc += 3;
break;
//此类分支跳转的处理是为了修正优化后的 Code 地址错误，因为优化后 Code 位置有所改变，那么原来分支跳转指令的地址将不准确
case OPC_IFEQ: case OPC_IFNULL: case OPC_IFNE:
case OPC_IFNONNULL: case OPC_IFLT: case OPC_IFGE:
case OPC_IFGT: case OPC_IFLE: case OPC_IF_ACMPEQ:
case OPC_IF_ICMPEQ: case OPC_IF_ACMPNE: case OPC_IF_ICMPNE:
case OPC_IF_ICMPLT: case OPC_IF_ICMPGE: case OPC_IF_ICMPGT:
case OPC_IF_ICMPLE:
{
//得到跳转的地址
int dest = pc + READ_S2_OP(code + pc);
#ifdef USE_CACHE
/* Conflict can only occur on first pass, and dest must be backwards */
if(cache_depth[dest] > 0) {
TRACE("CONFLICT in IF target addr: %d\n", dest);
/* Reset depthes calculated from the (backwards) destination and
here. By setting depth at dest to zero (see below) and starting
from dest again, we will immediately get a conflict which will be
resolved by adding a NOP. */
memset(&cache_depth[dest + 1], DEPTH_UNKNOWN, pc - dest);
cache = cache_depth[dest];
ins_count = map[dest] - 1;
pc = dest;
} else {
cache = 0;
#endif
pc += 3;
#ifdef USE_CACHE
}
#endif
if(pass == 1) {
TRACE("IF old dest %d new dest %d\n", dest, map[dest]);
operand.pntr = &new_code[map[dest]];
} else {
#ifdef USE_CACHE
/* Branches re-cache, so the cache depth at destination is zero */
cache_depth[dest] = 0;
#endif
#ifdef INLINING
info[pc] |= FALLTHROUGH;
info[dest] |= TARGET;
#endif
}
break;
}
指令精简与优化
指令中有一些比较常见的 Case 可以匹配到，并且可以做一些精简或者优化的，因为 java 在编译成字节码的时候并没进行太多的优化，因为 JVM 才是 Java 的核心，JVM 才懂得当前所在的平台环境需要进行何种优化。
那么 JAMVM 匹配到了下面一个可优化的场景，而且是非常非常常见的场景
当在当前类 load 一个本类 Field 的时候
例如：
public class A {
private String a = "ssss";
public void test() {
//这里相当于 b = this.a
String b = a;
}
}
这里相当于 this.a, 方法参数列表第一个一般保存的是 this 指针，那么引用本类变量的字节码应该为：
ALOAD_0 //this 指针入操作栈
GETFIELD //从操作栈顶的对象中 get 指定 Field 的值
那么当 JAMVM 匹配到 ALOAD_0 指令并且下一个指令是 GETFIELD 的时候，就匹配到了一个可优化的 Case
那么优化的逻辑就是直接将这个 Field 解析出来并且把 GETFIELD 指令替换成自己的 JVM 内部伪指令 GETFIELD_THIS，并将 Field 的偏移保存到操作数中
case OPC_ALOAD_0:
{
FieldBlock *fb;
#ifdef USE_CACHE
if(cache < 2)
cache++;
#endif
/* If the next instruction is GETFIELD, this is an instance method
and the field is not 2-slots rewrite it to GETFIELD_THIS. We
can safely resolve the field because as an instance method
the class must be initialised */
//当在当前类 load 一个本类 Field 的时候，那么它的 Code 形式一般是
/**
* ALOAD_0 this 指针入操作栈
* GETFIELD 从操作栈顶的对象中 get 指定 Field 的值
* */
//那么这个就是一个普遍可以优化的指令，这里直接将这个 Field 解析出来并且把 GETFIELD 指令替换成自己的 JVM 内部伪指令 GETFIELD_THIS，并将 Field 的偏移保存到操作数中
if((code[++pc] == OPC_GETFIELD) && !(mb->access_flags & ACC_STATIC)
&& (fb = resolveField(mb->class, READ_U2_OP(code + pc)))
&& !((*fb->type == 'J') || (*fb->type == 'D'))) {
if(*fb->type == 'L' || *fb->type == '[')
opcode = OPC_GETFIELD_THIS_REF;
else
opcode = OPC_GETFIELD_THIS;
operand.i = fb->u.offset;
pc += 3;
} else
opcode = OPC_ILOAD_0;
break;
}
JIT
JAMVM 中的 JIT 其实并不是真正的 JIT，这里的 JIT 其实是一种内联操作，确切的说是代码拷贝，将每行字节码指令所对应的处理 label，我们叫 handler 的代码段拷贝连接起来。这样在运行的时候就省去了分发代码的过程，这样的 JIT 其实和完整的 JIT 在效率上还是有些小的差距的。但是好在良好的可移植性，因为拷贝的是现成的代码。。。。
因为这部分代码较为复杂，后面会另起一文分析。