15.2 字节码解释器
解释器会反复取出操作码（opcode）、解码操作数（operands）、执行对应的操作，然后再选择下一条指令。这个循环看似很小，却位于每条已执行字节码（bytecode）的必经路径上，并协调着虚拟机的数值表示法（value representation）、调用栈帧（call frames）、异常处理（exceptions）、垃圾回收器（garbage collector）、调试器（debugger）与原生接口（native interface）。因此，解释器工程的核心是清晰的不变量与经过仔细测量的热点路径（hot paths）。
简单的栈式解释器（stack interpreter）会维护指令指针 ip（instruction pointer）、操作数栈指针 sp（operand-stack pointer）、当前栈帧（frame）与字节码数组：
while true:
opcode = code[ip++]
switch opcode:
CONST: stack[sp++] = constants[read_u16()]
ADD: stack[sp-2] = add(stack[sp-2], stack[sp-1]); sp--
JUMP: ip += read_i16()
CALL: push_frame(...)
RET: restore_caller(...)生产级实现还要验证内存边界、保留源码位置（source position）、轮询中断与垃圾回收安全点（interrupt/GC safepoint），并在遇到异常结果时保持虚拟机状态（VM state）不被破坏。
分发（Dispatch）策略塑造最热循环
可移植的 C/C++ 解释器通常使用 switch 语句。编译器可能会将其优化为跳转表（jump table），但在每一次分发时，所有的操作码最终都会回到中央分发点（dispatch site）。某些平台可以借助编译器扩展实现直接线索分发（direct-threaded dispatch）：在跳转表中直接存入处理程序（handler）的地址，使每个 handler 执行完毕后直接跳向下一项。这使不同的操作码状态转移（opcode transition）拥有各自独立的间接分支跳转点（indirect-branch site），能显著改善分支预测（branch prediction），代价是可移植性有所下降且处理程序代码体积（handler code）有所增大。
超级指令（Superinstruction）会把 load_local; load_const; add 等高频执行指令序列融合为一个单一的内部操作码（opcode），从而减少分发次数并暴露局部优化机会，不过这也扩大了操作码集合（opcode set）和指令缓存占用（instruction-cache footprint）。虚拟机可以预先生成超级指令，依据运行时的性能分析（profiling）重写已解码的字节码（bytecode），或者使用快化（quickening）技术：一旦在运行中观察到具体的值类型，就把通用的通用操作（generic operation）替换为更高效的特化操作（specialized operation）。
Frame 让调用、异常与 GC 变得具体
每次函数激活（activation）都需要栈帧（frame），用以保存返回指令指针（return instruction pointer）、调用者指针（caller link）、参数、局部变量/虚拟寄存器、操作数栈基址（operand-stack base）、闭包环境（closure environment）以及可能的异常处理游标（exception-handler cursor）。表示方式可以是缓存局部性（cache locality）较好的连续虚拟机栈（VM stack）、支持延续性（continuation）的堆分配栈帧（heap-allocated frames），或者二者混合的形式。对于递归与庞大的栈帧，必须做显式溢出检查（overflow check），绝不能将原生进程崩溃当作语言级的栈溢出诊断。
函数调用会检查参数个数（arity），创建或复用栈帧，安装参数，再把指令指针 ip 转向被调用者（callee）。函数返回时则把结果放到调用者（caller）期望的位置，并恢复调用者的执行状态。当语言的调试与栈检查语义（stack-inspection semantics）允许时，尾调用（tail call）可以直接复用当前的栈帧。闭包（Closure）则让捕获的环境（captured environment）拥有独立于创建它的激活记录的生命周期。
抛出异常时，运行时（runtime）会在异常处理器表（handler table）中搜索覆盖当前字节码区间且类型与之匹配的项。若没有找到处理器，对应的栈帧将被展开（unwind）；在展开途中，可能会先执行一些清理或 finally 逻辑。每次异常转移都必须让操作数栈符合异常处理器所声明的状态。这些栈帧同时也是垃圾回收的根节点（roots）：在安全点（safepoint），垃圾回收器（collector）必须依靠类型标签或栈映射（stack maps），把对象引用（reference）与普通整数、浮点数以及未初始化的插槽区分开来。
属性值表示、特化与正确性边界
动态类型的虚拟机需要紧凑的值表示法（value representation）。标记联合体（Tagged union）显式地保存类型标签与数据负载（payload）；指针标记（pointer tagging）利用对齐指针空出的低位；NaN 装箱（NaN-boxing）则巧妙利用 IEEE-754 NaN 规范中未被使用的位负载，在 double 浮点数之外编码指针、整数、布尔值与空值（null）。每种方案对硬件架构、垃圾回收、调试以及外部函数接口（FFI）都有深远影响；运行时绝不能把任意的二进制位错误识别成活跃的对象引用（live reference）。
通用的 ADD 指令可能要实现整数加法、浮点运算、字符串拼接或用户自定义的分发。特化的 ADD_INT 指令则可直接检查类型标签并快速执行常见路径，在发生溢出（overflow）或遇到意外类型时回退（fallback）到通用路径。快化（Quickening）技术必须保证语义等价，并且在假设不成立时必须是可以安全逆转的。
解释器测试绝不能仅局限于操作码单元测试。应进行全方位验证，包括：畸形字节码拒绝（malformed-bytecode rejection）、控制流汇合处的栈高度校验（stack-height join）、算术边界、分支偏移量、递归导致的栈溢出、嵌套异常、finally 块、每个安全点处的垃圾回收、原生调用重入、调试器单步调试（stepping）以及异步中断等。差分测试（Differential testing）可让同一个生成程序分别在参考解释器（reference interpreter）与优化虚拟机（optimized VM）中执行以对比结果。模糊测试器（Fuzzer）应当在校验器边界完全明确后，才去随机突变字节流：不可信的畸形输入必须得到受控的安全拒绝，绝不能造成底层的内存破坏。