SOM（Simple Object Machine）是一个专为教学和研究设计的最小化 Smalltalk 实现，其设计初衷是让研究者和学生能够在一个干净、可理解的框架中探索对象系统的核心机制。与功能完备的 Squeak 或 Pharo 相比，SOM 的核心实现通常仅需数千行代码，却涵盖了动态类型面向对象语言的完整运行时要素。本文将从字节码解释器、对象模型和即时编译三个维度，系统解析 SOM 的架构设计，为希望从零实现虚拟机的开发者提供可落地的参考参数与实现要点。
字节码解释器架构
SOM 的字节码设计遵循「正交紧凑」原则，其指令集通常控制在 20 至 30 条之间，涵盖了栈操作、方法调用、控制流和基本算术运算等核心功能。典型的字节码分类包括以下几类：第一类是栈操作指令，如 push、pop、dup 用于栈帧管理；第二类是局部变量访问指令，如 load、store 用于方法局部变量和临时变量的读写；第三类是实例变量访问指令，如 pushField、storeField 用于对象字段的操作；第四类是消息发送指令，如 send、superSend 用于触发动态分派；最后一类是控制流指令，包括条件跳转 jumpIfTrue/jumpIfFalse 和无条件跳转 jump。
在解释器实现层面，SOM 通常采用基于栈的帧布局（Stack-Based Frame），每个方法调用创建一个新的栈帧，其中包含局部变量区、操作数栈和返回地址。字节码解释器的核心是一个无限循环的 dispatch 过程，其伪代码结构可概括为：循环读取当前程序计数器指向的字节码，根据字节码值分发到对应的处理函数，执行完毕后更新程序计数器和操作数栈状态。对于现代实现，建议将字节码 dispatch 优化为基于跳转表（Jump Table）或标签分发（Threaded Code）的方式，可将每条指令的解释开销降低至 2 至 3 个 CPU 周期。具体的实现参数可参考：栈帧默认深度设为 256 至 512 元素、操作数栈初始容量设为 64 元素、局部变量槽位上限设为 32 个。
消息发送是字节码解释器中最复杂的操作，其完整流程包括：解析消息选择子（Selector）在接收者类的方法字典中进行查找，若未命中则沿继承链向上搜索，找到方法后将接收者和参数压栈并跳转到目标字节码序列的起始位置。这一过程在纯解释执行下的开销通常占整体执行时间的 40% 至 60%，因此许多 SOM 实现会在此处引入内联缓存（Inline Cache）机制来加速方法查找。
对象模型设计
SOM 的对象模型遵循经典的 Smalltalk-80 三层结构：对象（Object）作为实例的运行时表示，类（Class）作为对象的元描述，而元类（Metaclass）则描述类本身的行为。这种模型的优势在于其一致性 —— 一切皆为对象，类本身也是对象，每个类都是其元类的实例。在 SOM 的具体实现中，每个对象由两个核心部分构成：一个是指向类对象的引用（Class Pointer），用于在运行时确定对象的类型和可执行方法；另一个是字段区域（Fields Area），用于存储对象的实例变量值。
类的数据结构通常包含方法字典（Method Dictionary）、超类引用（Superclass）、实例变量布局信息以及可选的继承层级缓存。方法字典以键值对形式存储选择子到方法对象的映射，其中选择子（Selector）是一个表示消息名称的字符串或符号，方法对象（Method）则包含字节码数组和字面量池（Literal Pool）的引用。当执行消息发送时，虚拟机首先从接收者的类开始遍历方法字典，若找到匹配的选择子则执行对应方法，否则沿超类链继续搜索，直至遇到 nil（根类 Object 的超类）时触发「消息未理解」（DoesNotUnderstand）异常。
对于对象布局的优化，生产级实现通常采用指针混合（Pointer Swizzling）或对象表（Object Table）技术来减少对象创建和垃圾回收的开销。在教学级 SOM 实现中，建议保持最简设计：每个对象使用一个固定大小的数组存储实例变量，通过类指针间接获取变量名映射，这种设计虽非最优但足以演示对象模型的核心概念。实践中可设定的参数包括：实例变量默认槽位数 16 个、对象头大小 2 个机器字（分别存储类指针和对象标识）、最小对象分配粒度 16 字节。
即时编译机制
尽管 SOM 以解释器为核心实现，但为了达到可接受的执行性能，现代 SOM 变体通常集成了即时编译器（JIT Compiler）。SOM 的 JIT 设计通常采用两层架构：解释器层负责初始执行和 profiling，即时编译器层在识别到热点代码后将其编译为本地机器码。两层之间的切换通过计数反馈机制控制 —— 当某个方法的执行计数超过阈值（典型值为 1000 至 10000 次）时，触发该方法的即时编译。
SOM 的即时编译策略可分为两大类：基于 tracing 的编译（Tracing JIT）和基于方法的编译（Method-Based JIT）。Tracing JIT 通过在解释执行期间记录热点执行路径（Trace），将线性执行序列聚合并编译为优化后的机器码，这种方式适合存在大量循环的场景。Method-Based JIT 则以完整方法为编译单元，在方法首次被调用时即触发编译，适用于方法体较小但调用频繁的场景。在实现层面，SOM 的 JIT 编译器需要处理几个关键挑战：栈帧布局的转换（从解释器的虚拟栈帧到本地调用约定）、字节码到中间表示（IR）的映射、以及运行时类型信息的收集与利用。
对于希望实现 SOM JIT 的开发者，建议采用渐进式策略：第一阶段实现解释器的 baseline 编译，将字节码直接转译为等价的目标代码，保持栈帧布局不变；第二阶段引入简单的寄存器分配和基本块优化；第三阶段加入基于 profiling 的类型推断和内联缓存固化。这种分阶段实现路径既能快速看到成果，又能在每个阶段验证核心功能的正确性。具体的工程参数可参考：JIT 编译触发阈值设为 5000 次调用热点、方法内联候选阈值设为 32 字节以内、生成的机器码缓存上限设为 8MB。
SOM 作为教学用最小化 Smalltalk 实现，其价值在于提供了一个「可呼吸」的 VM 骨架 —— 既不过于复杂导致难以理解，又足够完整以展示动态面向对象语言运行时的所有关键要素。从字节码解释器的 dispatch 循环到对象模型的方法查找，再到即时编译的热点优化，这条技术路径为编译器研究者提供了一个从理论到实践的完整闭环。无论是用于课程教学还是作为 VM 研究的原型平台，SOM 都展示了一种简洁而强大的实现哲学。
资料来源：SOM 项目官方页面（https://som-st.github.io/）以及相关学术论文阐述了 SOM 作为教学 VM 的设计理念与实现细节。