[Golang实现JVM第三篇] 解释器雏形
在上一篇中我们已经完成了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 {
Execute(file *class.DefFile, methodName string) error
}
想想JVM在运行时都需要指定一个主类，所以第一个参数可以是主类的class定义，DefFile类型这个在上一篇解析class文件中就已经定义过了，里面包含一个类的全部信息。methodName指定要从哪个方法开始执行，为了简单起见，直接传入方法的简单名。
然后就可以定义一个执行引擎的具体实现了：
// 解释执行引擎
type InterpretedExecutionEngine struct {
miniJvm *MiniJvm
}
好了，现在就可以开始解释字节码了！
解释字节码
直接解释字节码，很多人可能会问，符号引用解析了吗？方法描述符解析了吗？访问权限验证(public, private)做了吗？方法栈哪去了？本地变量表还没有呢？这些一堆的问题。但是，这些边边角角的东西对我们的MiniJvm来说，现在都还不重要。还是那句话，如果过早的陷入到繁杂的细节中就会失去对问题核心的把控。所以，接下来要做的就是：
- 遍历
DefClass结构体的Methods字段 - 根据传入的方法名，找到目标方法
- 取出
code属性 - 遍历字节码，解释执行
搜索方法的简化代码如下(完整代码可参考https://github.com/wanghongfei/mini-jvm/blob/master/vm/interpreted_execution_engine.go)：
// 查找方法定义;
// def: 当前class定义
// methodName: 目标方法简单名
// methodDescriptor: 目标方法描述符
func (i *InterpretedExecutionEngine) findMethod(def *class.DefFile, methodName string, methodDescriptor string) (*class.MethodInfo, error) {
currentClassDef := def
for {
for _, method := range currentClassDef.Methods {
name := def.ConstPool[method.NameIndex].(*class.Utf8InfoConst).String()
descriptor := def.ConstPool[method.DescriptorIndex].(*class.Utf8InfoConst).String()
// 匹配简单名和描述符
if name == methodName && descriptor == methodDescriptor {
return method, nil
}
}
// 从父类中寻找
// ... 省略
// 取出父类全名
// .. 省略
// 加载父类
// .. 省略
currentClassDef = parentDef
}
return nil, fmt.Errorf("method '%s' not found", methodName)
}
忽略方法描述符参数，最最基本的逻辑其实就是遍历数组、从常量池中取出方法名、判断是否跟目标名称匹配、返回。
找到方法后就可以提取字节码了：
func (i *InterpretedExecutionEngine) findCodeAttr(method *class.MethodInfo) (*class.CodeAttr, error) {
for _, attrGeneric := range method.Attrs {
attr, ok := attrGeneric.(*class.CodeAttr)
if ok {
return attr, nil
}
}
// native方法没有code属性
return nil, nil
}
这个方法返回一个CodeAddr类型的指针，这个类型的定义在上一篇解析class文件中就定义好了，可能文章里没有，但是github项目里有，结构如下：
// code属性
type CodeAttr struct {
AttrLength uint32
MaxStack uint16
MaxLocals uint16
// 字节码长度
CodeLength uint32
Code []byte
// 异常表
ExceptionTableLength uint16
ExceptionTable []*ExceptionTable
AttrCount uint16
Attrs []interface{}
}
可以明显的看到，Code字段就是我们要找的字节码了！
接下的要做的就更简单了，遍历，执行：
for {
// 取出pc指向的字节码
byteCode := codeAttr.Code[frame.pc]
exitLoop := false
// 执行
switch byteCode {
case bcode.Iconst0:
// 将0压栈
frame.opStack.Push(0)
default:
return fmt.Errorf("unsupported byte code %s", hex.EncodeToString([]byte{byteCode}))
}
if exitLoop {
break
}
// 移动程序计数器
frame.pc++
}
return nil
由于从code中读取出来的是byte类型，所以我们需要定义一下每一个byte对应哪条指令，例如：
package bcode
const (
Nop byte = 0x00
Iconst0 = 0x03
// .. 省略 ..
)
这样就可以用switch case非常直观的处理字节码了。
对于icons_0这条指令，是要我们向操作数栈中压如一个整数0，所以，还需要一个栈：
// 操作数栈
type OpStack struct {
elems []interface{}
// 永远指向栈顶元素
topIndex int
}
func NewOpStack(maxDepth int) *OpStack {
return &OpStack{
elems: make([]interface{}, maxDepth),
topIndex: -1,
}
}
完整代码可以参考: https://github.com/wanghongfei/mini-jvm/blob/master/vm/op_stack.go
有了栈就可以解释这条指令了：
frame.opStack.Push(0)
注意frame是MethodStackFrame类型的指针，表示一个方法栈的栈帧(现阶段可以不实现，直接操作栈即可)，里面有程序计数器和本地变量表，完整定义可参考https://github.com/wanghongfei/mini-jvm/blob/master/vm/method_stack.go
至此，我们的Mini-JVM已经完成了第一条字节码指令的解释，算是迈出了万里长征第二步。完成第一条指令的解释后，我们就可以照葫芦画瓢，解释第二、第三条，当发现缺少执行这条指令的基础设施时再去实现这些设施，而不是一开始就想太多。
实际上当严格按照规范完成全部200多条字节码的解释后，JVM就基本完工了。虽然后面的指令会越来越复杂，解释所需要做的工作也越来越多，但是我们可以把支持的字节码数量当做衡量JVM进展的里程碑，相当于把一个天文工程划分成了200多个小步，这样写起来就能及时看到成果，也很有意思，不是吗？