Repository navigation
JIT optimizer cleanups #143421
Description
Activity
I agree, but let's refactor the JIT structs to be heap allocated first.
Reacted by Ken JinI agree, but let's refactor the JIT structs to be heap allocated first.
Assigning this to @cocolato
- changed the title
[-]Make the JIT optimizer buffer add to a new buffer, not in-place[/-][+] JIT optimizer cleanups[/+]on Jan 6, 2026 - added 4 commits that reference this issue
on Jan 8, 2026 How should we handle the following case? It appears that we cannot simply use
ADD_OPas a substitute. Perhaps we still need aREPLACE_OPto handle the new buffer.andcpython/Python/optimizer_bytecodes.c
Line 1512 in e7f5ffa
cpython/Python/optimizer_bytecodes.c
Line 1024 in e7f5ffa
@cocolato make REPLACE_OP operate on the new buffer instead of the old one. Ideally you should have two buffers. An old buffer containing the current uops, and a new buffer, containing the uops being written.
If the optimizer stops early, you can just insert an _EXIT_TRACE at that location in the new buffer.
Reacted by Hai Zhu- added 4 commits that reference this issue
on Feb 15, 2026
Feature or enhancement
Proposal:
Currently the JIT uop buffer modifies uops traces in place.
I think we should make it add to a new buffer. Having modifications be in-place is making our code messy and full of special cases.
So
should become
in
optimizer_bytecodes.c,Also, the default generated case of optimizer_bytecodes.c should be to
ADD_OP(pc, ...)This is also blocking optimization in #143414, as ocassionally we need to insert extra guards to check the uniqueness of an object for example.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
JitOptContextfrom stack allocation to per-thread heap allocation to avoid stack overflow. #143536