摘要

今年早些时候，一个实验性的“即时”编译器被合并到 CPython 的main开发分支中。虽然最近的 CPython 版本包含其他重大的内部更改，但此添加代表了 CPython 传统上执行 Python 代码方式的特别重大的偏离。因此，它值得更广泛的讨论。

本 PEP 的目标是总结此添加背后的设计决策、实现的当前状态以及未来将 JIT 作为 CPython 永久性非实验性部分的计划。它不试图提供关于 JIT如何工作的全面概述，而是专注于所选方法的特定优势和劣势，以及回答自引入 JIT 以来提出的许多问题。

有兴趣了解更多关于新的 JIT 的读者可以参考以下资源

• 在 2023 年 CPython 核心开发者冲刺中首次介绍 JIT 的演示文稿。它包括相关背景、对所使用的“复制和修补”技术的简要技术介绍，以及核心开发人员在场时对其设计进行的公开讨论。此演讲的幻灯片可以在GitHub上找到。
• 最初描述复制和修补的开放获取论文。
• 论文作者详细介绍了为 Lua 实现复制和修补 JIT 编译器的博客文章。虽然这是一个关于该方法的很好的底层解释，但请注意，它还包含其他技术并做出与 CPython 的 JIT 特别不相关的实现决策。
• 该实现本身。

动机

到目前为止，CPython 一直通过将其编译成字节码来执行 Python 代码，该字节码在运行时被解释。此字节码是对源代码或多或少直接的翻译：它是无类型的，并且基本上未经优化。

自 Python 3.11 版本以来，CPython 使用了“专门的自适应解释器”（PEP 659），它在运行时就地重写这些字节码指令，使用类型专门版本。这个新的解释器提供了显著的性能改进，尽管其优化潜力受到单个字节码指令边界的限制。它还收集了大量新的分析信息：通过程序流动的类型、特定对象的内存布局以及程序中哪些路径被执行得最多。换句话说，什么需要优化以及如何优化它。

自 Python 3.12 版本以来，CPython 已从类似 C 的领域特定语言（DSL）生成此解释器。除了控制新的自适应解释器的一些复杂性之外，DSL 还允许 CPython 的维护人员避免在解释器、编译器和标准库的许多部分手动编写乏味的样板代码，这些部分必须与指令定义保持同步。这种能够从单个真相来源生成大量运行时基础设施的能力不仅便于维护；它还为以新的方式扩展 CPython 的执行打开了多种可能性。例如，它使自动生成用于将指令序列转换为等效的较小“微操作”序列的表、生成这些微操作序列的优化器，甚至生成用于执行它们的完整第二个解释器成为可能。

事实上，自 Python 3.13 版本周期初期以来，所有 CPython 构建都包含了这种精确的微操作转换、优化和执行机制。但是，它默认情况下是禁用的；即使是优化后的微操作跟踪的解释开销对于大多数代码来说也过于庞大。更重的优化可能也不会改善这种情况，因为任何由新优化获得的效率提升都可能被即使是更小、更复杂的微操作的解释开销抵消。

克服这种新的瓶颈的最明显策略是静态编译这些优化的跟踪。这提供了避免解释引入的几个间接来源和开销的机会。特别是，它允许消除微操作之间的调度开销（通过用热代码的直线序列替换通用解释器）、单个微操作的指令解码开销（通过将参数、常量和缓存值的数值或地址“刻录”到机器指令中）以及内存流量（通过将数据从堆分配的 Python 帧移动到物理硬件寄存器中）。

由于这些数据中的大部分数据甚至在程序的相同运行之间也会发生变化，并且现有的优化管道大量使用运行时分析信息，因此提前编译这些跟踪没有多大意义，并且将是对现有规范和微操作跟踪基础设施的重大重新设计，而这些基础设施已经实现。正如许多其他动态语言（甚至 Python 本身）所证明的那样，最有希望的方法是“即时”编译优化的微操作以供执行。

基本原理

尽管 JIT 编译器名声在外，但它们并不是神奇的“加速”机器。即使对于单个平台，更不用说 CPython 所有最受欢迎的支持平台，开发和维护任何类型的优化编译器都是一项极其复杂、昂贵的任务。使用像 LLVM 这样的现有编译器框架可以简化此任务，但代价是引入了沉重的运行时依赖项和显着更高的 JIT 编译开销。

很明显，在运行时成功编译 Python 代码不仅需要针对正在运行的代码进行高质量的特定于 Python 的优化，还需要快速生成针对优化程序的有效机器代码。Python 核心开发团队拥有前者（与解释器紧密耦合的中端）所需的技能和经验，而复制和修补编译为后者提供了一种有吸引力的解决方案。

简而言之，复制和修补允许从用于生成其余解释器的相同 DSL 生成高质量的模板 JIT 编译器。对于像 CPython 这样广泛使用、由志愿者驱动的项目，这种好处怎么强调都不为过：CPython 的维护人员只需编辑字节码定义，即可同时“免费”获得更新的 JIT 后端，适用于所有支持 JIT 的平台。无论是在添加、修改还是删除指令时，情况都是如此。

与解释器的其余部分一样，JIT 编译器是在构建时生成的，并且没有运行时依赖项。它支持各种平台（请参阅下面的支持部分），并且维护负担相对较低。总而言之，当前的实现由大约 900 行构建时 Python 代码和 500 行运行时 C 代码组成。

规范

JIT 目前不是默认构建配置的一部分，并且在可预见的未来可能仍然如此（尽管官方二进制文件可能包含它）。也就是说，一旦满足以下所有条件，JIT 将变为非实验性的

1. 它至少为一个流行的平台提供了有意义的性能改进（实际上，大约 5%）。
2. 它可以构建、分发和部署，而不会造成最小的干扰。
3. 指导委员会在收到请求后，已确定如果启用它比禁用它对社区更有价值（考虑到维护负担、内存使用或替代设计的可行性等权衡）。

这些标准应被视为起点，并且可能会随着时间的推移而扩展。例如，对本 PEP 的讨论可能会表明，应将其他要求（例如多名已承诺的维护人员、安全审计、开发指南中的文档、对进程外调试的支持或禁用 JIT 的运行时选项）添加到此列表中。

在 JIT 成为非实验性之前，不应在生产环境中使用它，并且可能会随时中断或删除，恕不另行通知。

一旦 JIT 不再是实验性的，它应该与其他构建选项（如--enable-optimizations或--with-lto）以相同的方式对待。它可能是某些平台的推荐（甚至默认）选项，并且发布经理可能会选择在官方版本中启用它。

向后兼容性

由于当前解释器和 JIT 后端都是从相同的规范生成的，因此 Python 代码的行为应该完全不变。在实践中，在测试期间发现并修复的可观察差异往往是现有微操作翻译和优化阶段的错误，而不是复制和修补步骤中的错误。

安全影响

这个 JIT，像任何 JIT 一样，在运行时会生成大量可执行数据。这为 CPython 引入了潜在的新攻击面，因为能够影响此数据内容的恶意行为者因此能够执行任意代码。这是 JIT 编译器的众所周知的漏洞。

为了降低这种风险，JIT 的编写考虑了最佳实践。特别是，问题数据在 JIT 编译器中保持可写状态时不会暴露给程序的其他部分，并且在任何时候数据都不会同时可写且可执行。

基于模板的 JIT 的性质也严重限制了可以生成的代码类型，从而进一步降低了成功利用的可能性。作为额外的预防措施，模板本身存储在静态的只读内存中。

但是，假设 JIT 中不存在任何可能的漏洞是幼稚的，尤其是在这个早期阶段。作者不是安全专家，但愿意加入或与 Python 安全响应团队紧密合作，对出现的安全问题进行分类和修复。

如何教授

选择最能描述您的部分

• 如果您是 Python 程序员或最终用户…
  • …对您来说没有任何变化。在它仍然是实验性功能时，没有人应该向您分发启用 JIT 的 CPython 解释器。一旦它不再是实验性的，您可能会注意到性能略有提高，内存使用量略有增加。您不应该观察到任何其他变化。
• 如果您维护第三方包…
  • …对您来说没有任何变化。没有 API 或 ABI 更改，并且 JIT 不会暴露给第三方代码。您无需更改 CI 矩阵，并且在启用 JIT 时，您不应该能够观察到软件包工作方式的差异。
• 如果您分析或调试 Python 代码…
  • …对您来说没有任何变化。所有 Python 分析和跟踪功能都保持不变。
• 如果您分析或调试 C 代码…
  • …目前，跟踪通过JIT 帧的能力是有限的。如果您需要观察整个 C 调用堆栈，而不仅仅是“叶”帧，这可能会导致问题。有关更多信息，请参阅上面的调试部分。
• 如果您编译自己的 Python 解释器…。
  • …如果您不希望构建 JIT，您可以简单地忽略它。否则，您需要安装兼容版本的 LLVM，并将适当的标志传递给构建脚本。您的构建可能需要多花一分钟。请注意，在 JIT 仍然处于实验阶段时，不应将其分发给最终用户或用于生产环境。
• 如果您是 CPython（或 CPython 的分支）的维护者…
  • …并且您更改了字节码定义或主解释器循环…
    • …通常，JIT 不应该给您带来太多不便（取决于您尝试执行的操作）。微操作解释器不会消失，并且仍然提供与当今主字节码解释器提供的类似的调试体验。解释器的大规模更改（例如添加新的局部变量、更改错误处理和反优化逻辑或更改微操作格式）很可能会需要更改用于生成 JIT 的 C 模板，该模板旨在模仿主解释器循环。您也可能偶尔只是运气不好，并破坏 JIT 代码生成，这将需要您自己修改 Python 构建脚本，或寻求更熟悉它们的人的帮助（见下文）。
  • …并且您在 JIT 本身上工作…
    • …您希望已经对您将要处理的事情有一个不错的了解。您将定期修改 Python 构建脚本、用于生成 JIT 的 C 模板以及构成 JIT 运行时部分的 C 代码。您还将处理各种崩溃、在调试器中逐步执行机器代码、查看 COFF/ELF/Mach-O 转储、在各种平台上进行开发，并且通常是更改字节码时 CI 在其 PR 上开始失败的人员的联络点（见上文）。理想情况下，您至少熟悉汇编语言，修过几门名称中包含“编译器”的课程，并且阅读过一两篇关于链接器的博文。
  • …并且您维护 CPython 的其他部分…
    • …对您来说没有任何变化。您无需使用 JIT 构建在本地进行开发。如果您选择这样做（例如，帮助重现和分类 JIT 问题），则每次修改相关文件时，构建可能需要多花一分钟。

参考实现

实现的关键部分包括

• Tools/jit/README.md：有关如何构建 JIT 的说明。
• Python/jit.c：JIT 编译器的整个运行时部分。
• jit_stencils.h：JIT 生成的模板示例。
• Tools/jit/template.c：编译以生成 JIT 模板的代码。
• Tools/jit/_targets.py：在构建时编译和解析模板的代码。

被拒绝的方案

未解决的问题

脚注

版权

本文档置于公共领域或根据 CC0-1.0-通用许可证，以更宽松者为准。