Repository navigation
Tier 2 optimizer may use canonical builtins for functions with a copied __builtins__ dictionary #157468
Description
Bug report
Bug description:
A function can use a builtins dictionary other than the interpreter’s canonical builtins dictionary. With the JIT enabled, _LOAD_GLOBAL_BUILTINS may nevertheless be constant-folded using interp->builtins.
A dictionary created by vars(builtins).copy() can share its keys table and keys version with the canonical dictionary while storing independent values. Replacing an existing value such as len does not necessarily change that keys version.
The optimizer validates and watches interp->builtins, then obtains the constant from that dictionary. It does not first verify that the optimized function’s func_builtins is the same dictionary. Consequently, an optimized executor can continue using the
canonical len after the function’s own builtins dictionary has been changed.
I reproduced this on main at commit a60343e. The non-JIT interpreter produces the expected result.
The direct reproducer is a regression introduced by GH-138379 and first appears in Python 3.15.0a1.
A related case involving distinct functions with the same function/code version but different builtins dictionaries dates back to GH-116460 and Python 3.13.0a5.
Minimal reproducer
import builtins
from _testinternalcapi import TIER2_THRESHOLD
namespace = {"__builtins__": vars(builtins).copy()}
exec(
"""
def size(value):
return len(value)
def run(value, n):
for _ in range(n):
result = size(value)
return result
""",
namespace,
)
print(namespace["run"]([0], TIER2_THRESHOLD))
namespace["__builtins__"]["len"] = lambda value: 42
print(namespace["run"]([0], 8))Run it with a JIT-enabled build:
$ PYTHON_JIT=1 ./python repro.py
1
1
Expected output:
1
42
With the JIT disabled, the expected result is produced:
$ PYTHON_JIT=0 ./python repro.py
1
42
Proposed fix
Only constant-fold _LOAD_GLOBAL_BUILTINS when the current function uses the interpreter’s canonical builtins dictionary:
ctx->frame->func != NULL &&
ctx->frame->func->func_builtins == interp->builtins
For a custom builtins dictionary, retain the ordinary _LOAD_GLOBAL_BUILTINS operation so that it reads and guards the
function’s actual mapping.
A runtime identity guard should also accompany constants folded from the canonical builtins dictionary:
DEOPT_IF(BUILTINS() != tstate->interp->builtins);
The runtime guard is needed because function or code version checks alone do not identify the function’s builtins mapping.
A distinct function created from the same code object can use a different __builtins__ dictionary while satisfying the existing version guard.
Regression tests should cover:
- Mutating an existing value in a copied builtins dictionary after an executor has been created.
- Calling a different function with the same code/version but a different builtins dictionary through an existing optimized
executor.
CPython versions tested on:
3.15, CPython main branch
Operating systems tested on:
Linux
Activity
markshannon commentedon Sep 21, 2026
The diagnosis and proposed fix don't seem to quite match up with the error.
It seems to me that there are two underlying problems, and the proposed fix handles only one of them.
The problems are:
dict.copy()allows keys of different non-split dictionaries to have the same keys version number. We rely on the uniqueness of version numbers for the correctness of optimizing not only of_LOAD_GLOBAL_BUILTINS, but_LOAD_GLOBAL_MODULEas well._LOAD_GLOBAL_BUILTINSonly guards against the keys version for the module dict, not the builtin dict.I think it should be possible to break our optimization of
_LOAD_GLOBAL_MODULEusing a similar reproducer.I think the correct fix is to:
Also, we should be able to optimize out repeated checks in the same way as we remove repeated module dict keys version checks.
gh-157468: Validate correct builtins used under JIT (GH-157766)
[3.15] gh-157468: Validate correct builtins used under JIT (GH-157766) (