Python 3.15 release candidate upgrades CPython's experimental JIT with tracing and register allocation

Release candidate lands with a more capable JIT

Python 3.15.0rc1, published on August 4, 2026, is the first release candidate for a version of CPython whose experimental just-in-time compiler has taken a visible step forward. According to dev.to, the JIT has been part of CPython in experimental form since Python 3.13, but the significance of 3.15 is not simply that a JIT exists — it is that the machinery for observing and optimizing running code has improved considerably. The final release is expected in October.

A new tracing frontend

The headline internal change is a rewritten tracing frontend. As dev.to explains, the new frontend records the execution paths a program actually takes, giving the compiler concrete evidence about which operations and branches matter. Earlier versions operated with much less information about the code being run. The tracing work is not itself the main performance win; it is groundwork that makes the optimizations built on top of it more effective.

Tighter generated code

Three optimizations sit on that foundation:

• Register allocation. JIT-generated code previously moved many intermediate values through memory between operations. Python 3.15 can now keep selected values in CPU registers across several operations, reducing memory traffic — a change that helps most in code with repeated arithmetic and other tight loops.
• Leaner reference counting. Reference counting is central to CPython's memory management, but it imposes real CPU work. The new JIT can eliminate reference-count operations when it can prove they are unnecessary, so compiled code spends less time maintaining object lifetime bookkeeping and more time on actual work.
• In-place numeric operations. For some int and float operations, when the compiler can determine that an object is not referenced anywhere else, it can reuse that object instead of allocating a new one for every result. This is aimed squarely at numeric loops that repeatedly update the same values.

What the benchmarks show

According to the dev.to write-up, current pyperformance results indicate a geometric-mean improvement of roughly 8-9% on x86-64 Linux and around 12-13% on AArch64 macOS, in each case compared with the corresponding non-JIT interpreter configuration. The author is careful to frame these as indicators of progress rather than a promise that every Python program becomes about a tenth faster — the real effect depends heavily on the workload.

Experimental status and the PEP 836 question

The JIT remains disabled by default in 3.15. It is positioned for experimentation and benchmarking rather than as something production systems should switch on without testing, and some of its interfaces are explicitly marked unstable, reflecting an implementation that is still evolving.

The governance side is equally unsettled. On June 8, 2026, the Python Steering Council paused new JIT development on CPython's main branch and asked the developers for a formal plan for the project's future. That plan became PEP 836, "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython," which lays out a multi-release roadmap with measurable performance targets — including a proposed 20% geometric-mean improvement on the pyperformance suite for JIT combined with free-threading by Python 3.17. As of August 2026, PEP 836 was still under discussion rather than settled policy, which leaves CPython in an unusual position: the implementation is far more capable than in its early releases, while its long-term place in the interpreter is still being decided.

Why it matters

CPython's performance trajectory over the next several years may hinge on how this experiment resolves. The 3.15 release candidate demonstrates that the JIT can deliver measurable, benchmarkable gains through conventional compiler techniques — tracing, register allocation, dead-reference-count elimination and object reuse — but those gains remain opt-in and modest on average. PEP 836 forces the community to define what success looks like, with concrete targets tied to specific releases, rather than continuing open-ended development on the main branch. For library authors and performance-sensitive users, Python 3.15 is worth watching less as the moment Python gets a JIT and more as a live test of whether a JIT can become a reliable, supported part of CPython's execution model.