Chapter 73: Adaptive Interpreter, Specialization, and JIT Direction

Python 代码先被编译成 bytecode，再由 CPython 解释器执行。这个基本链路在 Python 3.11 之后多了一层运行时反馈：解释器会观察某些 opcode 在真实执行中的对象类型、命名空间形状和调用形状，然后把通用 opcode 替换成更窄、更快的 specialized opcode。读完本章后，读者应能追踪一个热点 Python 操作如何从普通 bytecode 进入 inline cache、specialization、deoptimization，再进入 Python 3.13 之后实验性 JIT 的 Tier 2 路径。

本章的贯穿材料是一段属性读取加整数累加代码。它表面上只是 item.value，runtime 中却涉及 code object、frame evaluation、LOAD_ATTR、BINARY_OP、对象类型、实例布局、缓存槽和失效回退。这个例子足够短，也能覆盖本章的主问题：CPython 如何在保持 Python 语义稳定的前提下，用运行时反馈降低动态分发成本。

本章默认讨论 CPython。Python 语言规范承诺的是代码语义，bytecode、inline cache、specialized opcode、Tier 2 IR 和 JIT 都属于 CPython 实现细节。Python 官方 dis 文档明确说明 bytecode 可在不同 Python 版本和不同 VM 之间变化，并提供 adaptive=True、show_caches=True、Python 3.14 的 --specialized 等观察入口；这些入口适合定位性能现象，不能当成跨版本 ABI 使用。

版本边界需要先固定。Specializing adaptive interpreter 来自 PEP 659，在 Python 3.11 成为 Faster CPython 的核心组成部分；Python 3.13 的实验性 JIT 构建选项记录在 Python 3.13 What's New 和 PEP 744 中。PEP 744 当前定位为讨论设计、状态和未来条件的 informational draft；工程判断应以目标 CPython 版本的文档和源码为准。

贯穿代码如下。后续每节都会回到这段代码，说明同一个 Python 现象在不同优化层的形态。

class Reading:
    def __init__(self, value: int) -> None:
        self.value = value


def total_value(items: list[Reading]) -> int:
    total = 0
    for item in items:
        total += item.value
    return total

total_value 的热点操作有两个：item.value 触发属性读取，total += ... 触发整数二元运算。初始 bytecode 要服务所有合法 Python 对象；运行多次后，CPython 可能发现 item 经常是同一个类的实例，value 经常在稳定实例布局中，total 和 item.value 经常是 int。specialization 的输入就是这些运行时事实，输出是更窄的 opcode、cache guard 和失败后的回退策略。

73.1 Adaptive Interpreter as Runtime Feedback Loop

Adaptive interpreter 可以理解为 CPython frame evaluation 内部的运行时反馈环。它读取 code object 的指令流，在 frame 中执行这些指令，同时把部分热点指令改写成 adaptive 或 specialized 形态。这里的 feedback 指真实执行中观察到的对象类型、字典 key 形状、函数调用形状和命中次数；这里的 loop 指同一段代码多次执行时，解释器持续把观察结果反馈到下一次调度路径。

这条路径可以按四个状态阅读。第一，code object 中存在普通逻辑指令，例如 LOAD_ATTR 和 BINARY_OP。第二，指令运行一段时间后进入 quickening，解释器给这类指令配上 adaptive 形态和缓存槽。第三，adaptive 指令根据计数器触发 specialize，检查当前对象类型、命名空间形状和操作类型。第四，specialized 指令在后续执行中先检查 guard，guard 命中时走 fast path，guard 失效时走 generic path 并更新计数器。

下面的图只描述 CPython 3.11 之后 adaptive interpreter 的概念路径。具体 opcode 名、cache 字段和生成文件会随版本变化。

在贯穿代码中，item.value 的普通语义是“在对象上执行属性查找”。这个语义覆盖实例字典、类属性、descriptor、__getattribute__、__getattr__、slots、模块属性等多种情况。通用 LOAD_ATTR 必须保留这些可能性，所以它需要进入属性查找协议。specialized LOAD_ATTR 会把范围缩小到当前观察到的一类情况，例如同一类型实例上的稳定属性位置。范围缩小之后，解释器可以减少字典查找、descriptor 分支和动态协议分发。

total += item.value 的普通语义是执行加法协议。对于 int 加 int，CPython 可以使用整数专用 fast path；对于自定义对象，加法可能触发 __add__、__radd__ 或异常路径。specialization 的判断点是“这条指令在当前热点路径中是否长期看到同一类输入”。稳定时，特殊化 opcode 把常见路径提前；输入形状变化时，回退路径仍按完整 Python 语义执行。

PEP 659 把这种设计称为 specializing adaptive interpreter：specialization 让指令利用当前类型和值的稳定性，adaptation 让指令在使用模式变化时快速调整。Python 3.11 文档也强调热点代码、type stability、inline caching、superinstruction 和 de-specialize 之间的关系。把这些信息合在一起，读 bytecode 优化时应先找“哪条指令重复执行”，再找“它观察到了什么稳定事实”，最后看“失效时如何回到通用语义”。

这个反馈环的工程意义在于成本位置发生改变。Python 动态性仍然存在，属性查找、全局变量查找、调用协议和二元运算协议仍然遵守语言规则。变化发生在常见稳定路径上：解释器把以前每次都要重新判断的条件，折叠成 cache guard 加 fast path。性能收益来自减少重复查找、减少分支、减少 dispatch 和减少临时对象路径；语义稳定来自 guard 失败后的通用路径。

73.2 Inline Cache and Deoptimization Boundary

Inline cache 是紧贴指令存放的缓存数据，用来记录 specialized opcode 需要的 guard 和 fast path 参数。Python 3.11 之后，dis 文档把 CACHE 指令作为可见观察入口：默认隐藏，传入 show_caches=True 可以显示；传入 adaptive=True 可以显示经过 specialization 后的指令形态。这个观察结果说明 cache 和 opcode 在解释器执行视角中紧密相邻，读性能问题时应把二者一起看。

对 item.value 来说，inline cache 通常要回答三个问题。第一，当前对象类型是否仍是 specialize 时看到的类型或兼容形状。第二，属性所在位置是否仍可用，例如实例值数组、slots 或模块字典中的索引。第三，命名空间结构是否改变，例如类字典 key、实例布局、descriptor 状态或模块 key 版本。cache 中保存的不是 Python 层对象语义的替代品，而是 fast path 的前置证据。

可以用下面的代码理解 cache guard 的必要性。两次调用使用相同源码和相同属性名，但第二组输入让 item.value 的对象来源出现变化。

from types import SimpleNamespace

stable_items = [Reading(index) for index in range(1000)]
mixed_items = stable_items + [SimpleNamespace(value=1000)]

print(total_value(stable_items))
print(total_value(mixed_items))

stable_items 让 LOAD_ATTR 长时间看到 Reading 实例，属性位置更容易稳定。mixed_items 添加了 SimpleNamespace，属性名仍然叫 value，对象类型和布局已经改变。正确结果仍要按 Python 属性语义计算；specialized opcode 在 guard 失败时需要回到 generic operation，随后根据失败频率降低特化信心，最终可能退回 adaptive opcode。

Deoptimization boundary 是回退发生的最小边界。PEP 659 的一个关键选择是按单条 bytecode 或 opcode family 做 specialization，因此回退边界很小。LOAD_ATTR 的 guard 失败只需要让这次属性读取走通用路径，并更新该指令自己的计数器；它无需撤销整个函数，也无需重建跨多条指令的大型优化区域。这个小边界让 CPython 可以更积极地尝试 specialization，因为错误猜测的修正成本受控。

属性读取、全局变量读取和调用特化的 guard 类型不同，但阅读顺序相同。LOAD_GLOBAL 关注 globals 和 builtins 的 key 结构，cache 可以保存命名空间索引和版本证据；LOAD_METHOD 或调用相关 opcode 关注 callable 的形状、vectorcall 路径和参数布局；BINARY_OP 关注操作数类型和具体运算族。每个 specialized opcode 都把“通用语义中的一大组分支”缩成“guard 命中后的一个 fast path”。

Deoptimization 还解释了性能波动的常见来源。代码语义相同，运行时形状不同，fast path 命中率就不同。稳定类实例列表、频繁改写类属性、在热循环中混入多种对象类型、动态替换 builtins、让同一个函数接收多种调用形状，都会改变 cache 命中率。排查时先不要急着改算法，先定位热点操作的对象形状是否稳定，再判断 specialized opcode 能否长期命中。

需要保持两个边界。第一，inline cache 是 CPython 优化结构，PyPy、MicroPython 或其它实现可以采用完全不同的执行策略。第二，cache 内容和 opcode 名称是版本敏感信息。Python 3.11、3.12、3.13、3.14 的 dis 输出、jump offset 表达、显示参数和 specialized opcode 名称都可能调整。正式文档中 dis 对 bytecode 稳定性给出的限制，应作为阅读所有 cache 输出的前提。

73.3 Copy-and-Patch JIT Direction

Python 3.13 的实验性 JIT 方向建立在 adaptive interpreter 之上。它并没有把 Python 源码直接交给一个传统优化编译器；官方文档描述的路径是从 specialized Tier 1 bytecode 出发，热点代码被翻译成内部 Tier 2 IR，也叫 micro-ops，然后经过优化 pass，最后在 JIT 启用时翻译成机器码执行。这个顺序说明 JIT 的输入已经包含前一层 specialization 收集到的运行时信息。

Copy-and-patch 是一种模板式代码生成方法。构建 CPython 时，工具链可以从解释器指令定义生成机器码模板；运行时遇到优化后的 micro-op trace 时，JIT 复制对应模板片段，并把常量、地址、cache 值和跳转目标补进模板中的空位。这个策略追求低运行时编译成本和低维护成本：同一套指令定义同时服务解释器、Tier 2 翻译和 JIT 后端。

Python 3.13 文档给出的内部架构可以压缩成一条路径。

这条路径中的 Tier 2 interpreter 主要用于调试优化管线；真正的目标是把优化后的 micro-op trace 编译成直线机器码，减少 micro-op dispatch、指令解码、frame 数据搬运和间接访问。PEP 744 明确指出，静态编译优化后的 trace 可以移除 micro-op 之间的 dispatch 开销，把参数、常量和缓存值嵌入机器指令，并把部分数据放入硬件寄存器。

Copy-and-patch JIT 的边界也要清楚。PEP 744 写明当前 JIT 仍属于实验阶段，默认构建配置未启用，达到非实验状态需要满足性能、分发部署和 Steering Council 判断等条件；在非实验前，不建议用于生产。Python 3.13 文档列出了 --enable-experimental-jit、PYTHON_JIT 和 Windows 构建选项，这些属于构建与运行时开关，不能改变 Python 语言语义。

JIT 与 specialization 的关系可以用“前端反馈，后端成码”概括。adaptive interpreter 收集类型、布局和热路径信息，并把普通 opcode 改写为 specialized opcode；Tier 2 把这些热点路径拆成更适合机器码生成的 micro-ops；copy-and-patch 把 micro-op trace 映射为模板机器码。JIT 的收益空间来自更少的解释器 dispatch、更低的数据搬运成本和更直接的机器级控制流。

这也解释了 CPython JIT 与 Numba、PyPy、Cython 这类工具的差异。CPython 实验性 JIT面向通用 Python 执行路径，目标是在保持 CPython 语义和生态兼容的前提下改善热点代码成本。Numba 这类工具通常要求特定函数、类型约束或数组计算模型；PyPy 使用不同 VM 和 tracing JIT；Cython 通过静态编译扩展路径获得收益。比较这些工具时，应把输入约束、语义边界、生态兼容、热身成本和部署成本放在同一组维度上。

73.4 Performance Evidence and Semantic Stability

Specialization 和 JIT 优化改变的是可观察成本，保留的是 Python 语义。total_value(mixed_items) 仍要返回按对象属性协议计算出的结果；如果某个对象的属性读取触发 descriptor、自定义 __getattribute__ 或异常，fast path guard 必须识别出当前路径无法直接使用缓存证据，并转入通用语义。性能优化的正确性来自这个顺序：先检查 guard，再使用 fast path，失败后执行 generic operation。

性能证据需要把“代码现象”和“runtime 形状”同时写清。只说某段代码在 Python 3.11 之后更快，信息量不足；可复查的说法应说明目标版本、实现、热点操作、输入形状、热身方式和观测工具。例如 total_value(stable_items) 的分析可以写成：在 CPython 3.11 及之后，重复执行的属性读取和整数加法可能被特化；若输入长期保持同一实例布局和 int 操作数，LOAD_ATTR 与 BINARY_OP 的 fast path 命中率更高；若输入混合多种类型或频繁改变类字典，命中率下降。

dis 适合解释“解释器看到了什么”，基准测试适合解释“成本是否真的下降”。下面的代码用于观察，不属于语义正确性的前提。不同 Python 版本的输出会不同，读者应关注 cache、adaptive、specialized 这些层级关系。

import dis

for _ in range(20_000):
    total_value([Reading(index) for index in range(10)])

dis.dis(total_value, adaptive=True, show_caches=True)

这段观察代码能回答的问题是：当前 CPython 是否把某些指令显示为 specialized 形态，是否显示 inline cache entry。它回答不了的问题是：所有机器、所有版本、所有输入是否都有同样收益。性能判断仍要用稳定基准来验证，并把热身、输入规模、对象形状和 Python 构建选项写进实验条件。

语义稳定也有可观察边界。Python 层调试、profile、trace、异常、descriptor 和对象模型仍要成立；JIT 路径也要保持 Python profiling 和 tracing 功能的可用性。PEP 744 指出当前解释器和 JIT 后端来自同一 specification，Python 代码行为应保持不变；同时它也说明 C 层 profiler 或 debugger 穿透 JIT frame 的能力仍有限。这意味着“Python 语义稳定”和“底层调试可见性完全相同”属于两个层级的判断。

内存和构建成本也属于性能证据的一部分。PEP 659 讨论过 inline cache 的额外内存占用，并将其和 Python 3.10 的 opcache 做过比较；PEP 744 则指出实验性 JIT 牵涉构建时 LLVM 依赖、模板、可执行内存和平台支持。一个工程项目评估 runtime optimization 时，应同时记录运行时间、内存、启动和热身、构建复杂度、调试可见性和发布平台。

最终判断可以落到贯穿代码上。total_value 的优化机会来自两个稳定事实：item 的属性布局稳定，total 的加法类型稳定。解释器用 inline cache 把这两个事实变成 guard；guard 命中时降低属性查找和二元运算成本；guard 失效时回到通用 Python 语义。JIT 方向继续使用这些运行时事实，把热路径转成更低 dispatch 成本的 micro-op trace 和机器码。语义没有放宽，成本模型变细了。

73.5 Runtime Optimization Reading Checklist

阅读 CPython runtime optimization 时，先固定实现和版本。检查对象是 CPython 3.11、3.12、3.13、3.14，还是其它 Python VM；检查解释器是否带实验性 JIT 构建；检查 dis 参数在当前版本中的含义。官方 dis 文档已经把 bytecode 标记为 CPython 实现细节，所以跨版本对比时应把 opcode 名称、cache 数量和输出格式视为版本事实。

第二步定位热点操作。不要从“这段函数慢”直接跳到 JIT；先把成本落到具体 opcode family：属性读取看 LOAD_ATTR，全局和内建查找看 LOAD_GLOBAL，调用看 CALL 和相关调用路径，二元运算看 BINARY_OP，迭代和下标访问看对应指令族。热点操作定位后，再问它依赖哪些 runtime 对象：type、dict keys、descriptor、callable、code object、frame 或 protocol method。

第三步检查输入形状是否稳定。属性访问要看对象类型和实例布局，全局变量要看 globals 与 builtins 的 key 结构，方法调用要看 receiver 类型和 callable 形状，二元运算要看左右操作数类型。稳定形状能支撑 fast path；形状频繁变化会提高 miss path 比例。这个判断顺序比直接背 specialized opcode 名称更可迁移，因为 opcode 名会变，guard 依赖的 runtime 关系更稳定。

第四步解释 cache 和 deoptimization。cache 命中时说明 guard 证据、fast path 使用的索引或直接地址、减少了哪类重复成本；cache 失效时说明回退到哪个通用语义、计数器如何降低特化信心、该失败是否只影响当前指令族。deoptimization 边界越小，错误猜测修正成本越低，解释器越能积极尝试 specialization。

第五步再阅读 JIT。JIT 不是所有性能问题的第一入口。先确认 Tier 1 specialization 能否解释现象，再看热点路径是否进入 Tier 2 IR、优化 pass 和 copy-and-patch machine code。Python 3.13 的实验性 JIT需要构建选项和运行时开关；它适合研究通用 CPython 执行路径的未来方向，生产采用要等待对应版本文档、发布策略和项目风险评估。

第六步整理证据。语义证据来自 Python 代码结果、异常路径和对象模型；runtime 证据来自 dis、版本文档和必要时的 CPython 源码；性能证据来自带热身和输入说明的基准测试；工程证据来自构建选项、内存占用、部署平台和调试工具能力。把这四类证据分开写，结论才不会被单次 benchmark 或单个 dis 输出牵引。

对于本章贯穿代码，可复用检查顺序如下：先确认 CPython 版本；再定位 LOAD_ATTR 和 BINARY_OP；接着检查 items 内对象类型、属性布局和加法操作数类型；然后观察 inline cache 与 specialized bytecode；最后把性能结果解释成 guard 命中率、dispatch 成本和回退频率。这个顺序也适用于全局变量、方法调用、下标访问和循环热点路径。

最小自检任务

阅读下面代码，判断它在 CPython 3.11 及之后的 adaptive interpreter 中，哪一部分更容易形成稳定 specialization，哪一部分更容易触发 cache miss 或 deoptimization。要求说明对象关系、状态变化、边界条件和最终结论。

class Counter:
    def __init__(self, value: int) -> None:
        self.value = value


def sum_values(items):
    result = 0
    for item in items:
        result += item.value
    return result

same_shape = [Counter(index) for index in range(1000)]
changed_shape = same_shape + [type("Other", (), {"value": 1})()]

答案要点

same_shape 中每个元素通常是同一个 Counter 类型的实例，item.value 的属性读取更容易让 LOAD_ATTR 观察到稳定类型和稳定实例布局。result += item.value 如果长期看到 int 加 int，BINARY_OP 也更容易进入整数 fast path。这里的核心对象关系是 code object 中的属性读取指令、frame 中的局部变量 item 和 result、Counter 实例的属性布局、以及 inline cache 保存的 guard 证据。

changed_shape 末尾混入动态创建的 Other 实例，属性名仍然是 value，对象类型和布局已经变化。LOAD_ATTR 的 guard 可能在这个元素上失效，解释器需要执行通用属性查找语义，并更新当前指令的计数器。若这种变化频繁出现，specialized opcode 的信心下降，可能回到 adaptive 形态。这个回退影响的是当前属性读取指令族，函数整体语义仍按 Python 对象模型计算。

最终结论是：稳定输入形状支持 specialization，混合类型和变化布局提高 miss path 比例。性能现象应从 opcode family、cache guard、对象形状和回退边界解释，源码中属性名相同只是局部证据。若要复查，可在目标 CPython 版本上用 dis.dis(sum_values, adaptive=True, show_caches=True) 观察；观察结果只说明当前版本的实现形态，语义判断仍来自 Python 属性查找和二元运算规则。

本章知识点总结

• 反馈环：Adaptive interpreter 在 frame 执行过程中收集运行时事实，并把部分热点 opcode 改写成 adaptive 或 specialized 形态。
• 运行事实：Specialization 依赖对象类型、命名空间 key 形状、属性布局、调用形状和操作数类型等可检查证据。
• Quickening：Quickening 把普通指令推进到可被运行时改写和缓存的内部形态，为后续 specialized opcode 提供入口。
• Inline cache：Inline cache 紧贴指令保存 guard 和 fast path 参数，用来减少重复查找、动态分支和协议分发成本。
• Guard 命中：Guard 命中表示缓存证据仍然匹配当前对象形状，解释器可以走更窄的 fast path。
• Guard 失效：Guard 失效会转入通用 Python 语义，并更新计数器以降低当前特化路径的信心。
• 回退边界：PEP 659 的 specialization 以单条指令或 opcode family 为主要边界，错误猜测的修正成本较小。
• 语义稳定：优化改变执行成本和可观察 bytecode 形态，Python 属性查找、调用、异常和对象模型语义仍要成立。
• 版本边界：Bytecode、specialized opcode、cache entry 和 dis 输出属于 CPython 实现细节，跨版本阅读必须先固定版本。
• Tier 2 路径：Python 3.13 实验性 JIT 从 specialized Tier 1 bytecode 进入 Tier 2 IR，再经过优化 pass 和机器码生成。
• Copy-and-patch：Copy-and-patch 通过复制构建期生成的机器码模板并补入运行时参数，降低 JIT 运行时编译成本。
• JIT 边界：当前 CPython JIT 方向面向通用 Python 热路径，实验阶段的构建、部署、调试和安全成本都要纳入评估。
• 性能证据：可信性能结论需要同时说明版本、实现、热点操作、输入形状、热身方式、观测工具和基准方法。
• 阅读顺序：分析 runtime optimization 时先看 CPython 版本，再看 opcode family，再看 guard 依赖，最后解释 cache 命中、回退和 JIT 入口。