在上一篇中我们已经完成了class文件的解析工作,虽然没有解析所有的属性,但是已经足够支持一些基本的算法题Java代码编译生成的class文件了。有了这一步,日后如果遇到新的特性需要支持,只需缺哪补哪,补上对应属性的解析逻辑就可以了。下一步就是实现一个基本的执行引擎,即解释器,并且支持基本的栈操作相关的指令,比如iconst_x
, istore_x
, bipush
等。
基于栈的指令集和基于寄存器的指令集
JVM字节码是一套基于栈的指令集,也就是说操作数栈是一切计算的基本容器,大部分指令都是围绕着操作数栈展开的。相对应的还有一种基于寄存器的指令集,这种指令集的特点是指令中就携带寄存器地址,对寄存器进行操作,优点指令短小精悍,执行效率高,缺点是会依赖于特定的硬件,可移植性差。栈指令集的优缺点则刚好相反,因为栈是一种抽象数据结构而不是具体的硬件设施,因此可移植性强,但是指令的数量往往比较臃肿,执行效率相对较低。
举个例子,计算1+1,用Javac编译后的对应字节码是这样的:
iconst_1
iconst_1
iadd
istore_0
其中前两条iconst_1
表示将整数1压入操作数栈,这时候操作数栈就有两个1了。iadd
指令则表示从操作数栈中连续出栈两次,将值相加,最后再把结果压入栈中。istore_0
则表示将栈顶元素(计算结果2)出栈,存入本地变量表索引为0的槽位中。可以看到,明明是很简单的计算,却多出了很多压栈出栈操作。
如果是基于寄存器的指令集,那一般会长这样:
mov exa,1
add exa,1
即先将1存入exa寄存器,然后直接把寄存器中的值+1完成计算,指令数量少了很多。
不过并不是说JVM的字节码一定就会比寄存器指令慢,毕竟JVM 中有大量的优化,字节码可能会被省略、被乱序执行,或者直接被JIT编译成本地语言,也就是基于寄存器的指令了。当然,优化并不在我们实现JVM的目标范围内。
解释器实现思路
想实现JVM的朋友应该都对JVM的基本构成有了解了,什么方法区、堆区、方法栈等等。还是那句话,千万不要一上来就考虑这么复杂的因素,这样只会掉坑里爬不出来,正确的方法是先实现一个最简单的能跑的例子,然后再根据真实的JVM结构慢慢扩充。比如,对于字节码iconst_1
来说,他的含义就是将整数1压如操作数栈,那么实现一个栈,遇到这条指令就压栈不就完事了吗?什么方法栈、堆区、类加载器、垃圾回收、线程调度,现阶段通通都不要考虑,随着字节码越来越复杂,这些总会有的。
一个解释器应该具备的最基本的要素,就两条,一是死循环,二是指向下一条指令的程序计数器(Program Counter, 简称PC),golang伪代码如下:
pc := 0
for {
byteCode := code[pc] // 取出pc指向的指令
execute(byteCode, &pc) // 执行指令,同时传入PC的指针,因为执行的过程可能需要修改pc的值
if 结束? {
break
}
}
我们可以先定义一个结构体MiniJvm
来表示一个JVM:
// VM定义
type MiniJvm struct {
// 方法区
MethodArea *MethodArea
// MainClass全限定性名
MainClass string
// 执行引擎
ExecutionEngine ExecutionEngine
// 本地方法表
NativeMethodTable *NativeMethodTable
// 保存调用print的历史记录, 单元测试用
DebugPrintHistory []interface{
}
}
这里有很多现阶段用不到的字段,忽略即可,等解释到对应的字节码以后再回头加上;
然后我们定义出执行引擎接口,为啥用接口呢,因为现在是解释的,万一以后牛逼了想搞个编译的呢?
type ExecutionEngine interface {