在 Python 解释器的实现版图中，PyPy 是一个独特的存在。它不仅是一个 Python 实现，更是一套动态语言实现框架。其核心思想是用 Python 本身来实现 Python 解释器，然后通过翻译工具链将解释器降至 C 代码运行。本文基于《The Architecture of Open Source Applications》中的 PyPy 章节，深入分析 bytecode 解释层与 JIT 编译层的技术路径，为编译器学习者提供可落地的工程参数。
一、RPython：可翻译的 Python 子集
PyPy 的解释器主体使用一种称为 RPython（Restricted Python）的语言子集编写。RPython 对标准 Python 施加了若干限制：禁止运行时创建函数、禁止同一变量持有不兼容类型等。这些限制并非为了降低开发体验，而是为后续的翻译过程铺路。当 RPython 程序被送入翻译工具链时，它首先运行在一个普通 Python 解释器上，此时程序仍拥有完整的动态特性。翻译器在开始真正的 lowering 阶段之前，程序必须已经是合法的 RPython。
这种设计的核心优势在于自举（self-hosting）：解释器可以用它自身的一种方言来编写，最终被翻译成底层语言。PyPy 的解释器因此可以在未翻译状态下直接运行在 CPython 上进行测试 —— 当然速度极慢，但这使得调试变得异常便捷。开发者可以使用标准的 Python 调试工具来追踪解释器行为，这在用 C 编写的 CPython 中是不可行的。
二、Bytecode 解释与 Objspace 抽象
PyPy 的 bytecode 解释器与 CPython 在很大程度上相似：使用几乎完全一致的字节码指令集和数据结构。两者的根本差异在于 PyPy 引入了一个关键抽象 —— 对象空间（object space，简称 objspace）。
在传统实现中，字节码解释器直接操作 Python 对象，知晓对象的具体表示形式。PyPy 则将所有对象操作委托给 objspace，解释器本身对这些对象一无所知。以二元加法操作 BINARY_ADD 为例，解释器只是从栈上弹出两个操作数，调用 space.add(object1, object2)，然后将结果压回栈顶。对象如何表示、加法如何实现，完全由 objspace 决定。
这种设计带来了极大的灵活性。同一套解释器可以搭配不同的 objspace 来改变 Python 语义。PyPy 团队曾实验过 thunking（惰性计算）和 tainting（敏感数据标记）—— 这些功能只需替换 objspace 而无需修改解释器本身。标准 objspace 还支持多方法派发（multimethod dispatch），允许同一数据类型拥有多种内部表示。例如，小型整数可以存储为机器字长度的值，只有超出范围时才使用任意精度整数实现。类似地，字典可以针对字符串键进行优化。这种优化对上层代码完全透明。
三、RPython 翻译工具链
解释器代码（RPython）需要经过一系列 lowering 阶段才能变成可执行的 C 代码。这个过程包括四个关键步骤。
首先是抽象解释（Abstract Interpretation）。翻译工具链使用一个特殊的 flow objspace 来解释 RPython 程序。Flow objspace 不包含真实的 Python 对象，只有两类基本元素：变量（代表编译时未知的值）和常量（代表编译时已知的不可变值）。当 Python 解释器执行 RPython 函数的字节码时，flow objspace 记录下所执行的每一步操作，将控制流的所有分支全部捕获。最终产物是函数的流图（flow graph），由若干基本块组成，每个块包含操作列表和一个出口 switch，用于决定下一步跳转到哪个块。流图采用静态单赋值形式（SSA），即每个变量仅被赋值一次，这大大简化了后续的编译转换。
其次是类型标注（Annotation）。标注器为流图中每个操作的输入输出分配类型信息。例如，对于一个阶乘函数，标注器会确定其参数和返回值都是整数类型。
第三步是 RTyping。RTyper 利用标注器提供的类型信息，将高层操作展开为低层操作。这是翻译过程中首个与目标后端相关的阶段。RTyper 维护两套类型系统：一套用于 C 等底层后端，另一套用于更高层次的后端。高层 Python 操作被转换为对应目标语言的底层操作。例如，整数加法在底层类型系统下变成 int_add 操作。
最后是优化与代码生成。在 RTyping 之后，工具链对流图执行传统编译器优化，包括常量折叠、存储下沉和死代码消除。malloc 消除是一种针对 Python 特性的优化：许多分配是局部且临时的，可以被 “展平” 为标量直接存储在寄存器或栈上，无需真正的堆分配。此外，函数内联可以减少调用开销并触发更多常量折叠，从而减小最终二进制体积。C 后端在生成代码前还需执行异常转换（将异常处理重写为手动栈展开）和栈深度检查插入。GC 转换器则负责在程序中嵌入垃圾回收支持，使不同的 GC 算法可以通过配置选项自由切换。
四、Tracing JIT 编译机制
原始 PyPy 解释器的执行速度比 CPython 慢约四倍，这主要来自 objspace 和多方法派发的抽象开销。为解决这一问题，PyPy 内置了一个追踪型 JIT 编译器。值得注意的是，PyPy 并没有一个 “特定于 Python” 的 JIT；它拥有一个 JIT 生成器，这个生成器在翻译过程中作为一个可选阶段被插入。任何使用 PyPy 框架编写的解释器只需添加两个 JIT 提示函数即可获得 JIT 能力。
PyPy 的 JIT 属于追踪型（tracing JIT），它检测频繁执行的 “热” 循环并将其编译为机器码。JIT 生成器在翻译阶段完成 RTyping 后被激活。它在解释器中找到两个关键提示位置：can_enter_jit（标识循环起点，对应 Python 字节码 JUMP_ABSOLUTE）和 merge_point（标识从 JIT 安全返回到解释器的位置，对应字节码分派循环的起点）。生成器将这些提示替换为运行时调用 JIT 的代码，并序列化所有待 JIT 函数的流图，这些序列化后的流图称为 jitcode，存储在最终二进制文件中。
运行时，JIT 维护一个计数器追踪每个循环的执行次数。当计数器超过阈值（默认通常在 1000 左右，可通过配置调整），JIT 开始追踪。此时，一个名为元解释器（meta-interpreter）的特殊组件开始执行 jitcode—— 它 “解释” 解释器本身，这正是 “元” 字的由来。元解释器在执行循环的过程中记录每一步操作，形成所谓的追踪（trace）。当追踪到达 can_enter_jit 起点时，追踪结束。
在追踪过程中，元解释器必须对循环的具体执行情况进行特化。当遇到条件分支时，它选择一个具体的执行路径并记录一个 guard 操作（如 guard_true 或 guard_false）。大多数算术操作也附带溢出 guard。这些 guard 实质上记录了元解释器在追踪时做出的假设。当最终生成机器码时，这些 guard 保护生成的代码只在假设成立的场景下运行。
五、JIT 优化与 Guard 失败处理
追踪得到的中间表示（IR）会经过两类优化。第一类是传统编译器优化，包括常量折叠和代数简化。第二类对动态语言尤为重要，包括 virtuals 和 virtualizables 优化。
Virtuals 指那些在追踪范围内不会 “逃逸” 的对象 —— 即它们不会被传递给非 JIT 编译的外部函数。这类对象无需真实分配，它们的数据可以直接存储在寄存器和栈上。这与翻译阶段的 malloc 消除非常相似。通过 virtuals 优化， boxed 的 Python 整数对象可以被解箱为纯机器字长整数，直接存入寄存器。
Virtualizables 类似于 virtuals，但可能会逃逸到追踪范围之外。在 Python 解释器中，帧对象（存储变量值和指令指针）被标记为 virtualizable。这允许栈操作和帧上的其他操作被优化掉。当 JIT 生成的代码需要访问 virtualizable 时，它会检查当前是否正在运行 JIT 代码；如果是，则从 JIT 数据中更新字段。当外部调用返回到 JIT 代码时，执行会回退到解释器。
优化完成后，追踪被汇编成机器码。由于 JIT IR 已经相当低层，大多数 IR 操作只需几条 x86 指令即可实现。寄存器分配采用简单的线性算法。生成代码中最复杂的部分是垃圾回收器集成和 guard 恢复。GC 需要知道 JIT 代码中的栈根位置，这通过 GC 中的动态根映射特殊支持来实现。
当 guard 失败时，生成的代码不再有效，控制流必须返回到字节码解释器。这个 “回退”（bail out）过程是 JIT 实现中最复杂的部分之一：必须根据 guard 失败时的寄存器和栈状态重建解释器状态。每个 guard 都带有一个紧凑的描述，说明恢复解释器状态所需的所有值在哪里。Guard 失败时，执行跳转到一个解码函数，该函数解读描述并将恢复值传递给解释器。由于失败的 guard 可能在某个复杂字节码执行的中间，解释器不能简单地执行下一条字节码。PyPy 使用一个 “黑洞解释器”（blackhole interpreter）来处理这种情况：它从 guard 失败点开始执行 jitcode，直到下一个 merge 点为止，然后真正的解释器可以在那里恢复执行。
对于频繁改变条件的循环，上述机制可能导致 guard 持续失败，使 JIT 生成的代码几乎没有机会运行。为此，每个 guard 拥有一个失败计数器。当失败次数超过阈值后，JIT 不再回退到解释器，而是从 guard 失败点开始新的追踪。这个新的子追踪称为 “桥”（bridge）。当桥追踪到循环末尾时，它被优化并编译，然后原始循环在 guard 处被修补为跳转到新桥而非失败处理代码。通过这种方式，带有动态条件的循环也能被有效 JIT 编译。
六、工程实践参数
基于 PyPy 的实现经验，以下参数对自行实现类似系统具有参考价值。JIT 触发阈值通常在 500 到 2000 次迭代之间可调，具体取决于目标工作负载的特征。Virtualization 优化对整型、浮点型和小型元组的效果最为显著，这些数据类型在科学计算和数值分析工作负载中占比最高。Guard 失败回退的开销大约是正常执行的 10 到 50 倍，因此桥接编译的阈值设置直接影响最终性能 —— 过低会导致频繁重编译，过高则会让解释器在长时间内承担热点代码的执行。
资料来源
本文核心内容译自《The Architecture of Open Source Applications (Volume 2)》第 19 章 "PyPy"，原文发表于 aosabook.org。