PEP 836 – JIT Go Brrr: The Path to a Supported JIT Compiler for CPython | peps.python.org

Following system colour scheme

Selected dark colour scheme

Selected light colour scheme

PEP 836 – JIT Go Brrr: The Path to a Supported JIT Compiler for CPython

PEP 836 – JIT Go Brrr: The Path to a Supported JIT Compiler for CPython

Author:<br>Savannah Ostrowski ,<br>Ken Jin ,<br>Brandt Bucher<br>Discussions-To:<br>Pending<br>Status:<br>Draft<br>Type:<br>Standards Track<br>Created:<br>02-Jul-2026<br>Python-Version:<br>3.16<br>Post-History:<br>Pending

Table of Contents<br>Abstract

Proposal

Motivation

Current State

Learnings

Rationale

Specification<br>Key JIT Infrastructure

Optimizations

First-Class Support for Free-Threading

A Better JIT Distribution Story

Compatibility Review

Tooling Support

Relationship to Other JITs and Compiler Tools

Platform Support

Maintenance Model

Backwards Compatibility

Security Implications

How to Teach This

Reference Implementation

Rejected Ideas<br>Maintain the JIT Outside of CPython main

Pluggable JIT Infrastructure

Dropping the Build-Time LLVM Requirement

A Higher-Tier JIT

Enable/Support the Current JIT As-Is

Open Issues

Appendix<br>Average JIT Speedup by Machine (calculated from 2026-06-16 to 2026-06-27)

Footnotes

Change History

Copyright

Abstract

The experimental Just-in-Time (JIT) compiler has been part of CPython’s main<br>branch since Python 3.13. PEP 744 described part of its initial design and<br>explicitly deferred a number of questions about the JIT’s long-term status.<br>Since then, the JIT has been re-architected and matured considerably. In Python<br>3.15, it delivers a measurable, reproducible speedup over the interpreter<br>(about 4-12% geometric mean performance improvement across measured Tier 1<br>platforms (see Appendix),<br>emits frames that native debuggers can unwind through, and reduces the memory<br>footprint of generated code relative to 3.14. Along the way, we have learned a<br>good deal about what works for a JIT in CPython.

This PEP proposes a path for the JIT to become a supported, non-experimental<br>part of CPython if it meets measurable performance, compatibility, tooling,<br>platform, distribution, security, and maintenance goals. The initial<br>performance target is at least 20% geometric mean improvement on pyperformance<br>for the JIT + free-threaded build compared to the non-JIT free-threaded build’s<br>interpreter, measured as the mean across the supported Tier 1 platforms, by the<br>first beta release of Python 3.17. The target is set as a minimum bar for<br>continued in-tree development of the JIT.

Proposal

This PEP does not propose declaring the JIT as supported immediately. Instead,<br>it proposes a time-bounded path for keeping JIT development in CPython main<br>while the project meets explicit performance, compatibility, tooling,<br>distribution, security, and maintenance goals.

If these goals are met, the JIT can be promoted to a non-experimental feature<br>of CPython. If they are not met, the Steering Council and core team should<br>re-evaluate whether the JIT should remain in CPython main. After promotion,<br>enabling the JIT by default on supported platforms would require a separate<br>final approval from the Release Manager.

At a high level, these are our milestones and goals for the JIT over the next<br>2.5 years:

Year 1 (ending with Python 3.16’s first beta) - Developer experience<br>improvements<br>Evolve the frontend from trace recording to method-based. We believe that a method frontend will put us on a<br>path that allows for easier maintenance, teachability, debugging, etc. The<br>first implementation should be minimal, may initially use more memory or<br>perform slightly worse, and may be rolled back to the current tracing<br>frontend if the approach does not meet the project’s goals in the first<br>year.

Make the JIT compatible with free-threading. We<br>believe that this is important to prioritize early on in the next phase of<br>the JIT as free-threading adoption is expanding rapidly.

Add further testing (and address any discovered remaining gaps in<br>coverage) for native and Python profilers and debuggers.<br>At a minimum, this will include anything that uses frame pointers to<br>unwind, but should also be expanded to support tools that symbolize Python<br>frames. Third-party tooling must have documented remediation paths when<br>existing behavior cannot be preserved exactly.

A better JIT distribution story. Provide<br>redistributors with a documented and reproducible way to build or verify<br>JIT stencils, without requiring long-term dependence on one exact LLVM<br>version [10].

No lower than 5% uplift for JIT + GIL versus the GIL<br>interpreter alone. In other words, we will not significantly regress<br>existing performance improvements while in pursuit of longer-term goals. We<br>will also not discourage other contributors from contributing performance<br>improvements during this stage. However, our main focus will be the<br>developer experience improvements.

Year 2 (ending with Python 3.17’s first beta) - Improved performance<br>Achieve at least 20% performance geometric...