Spill the stack pointer across calls in the interpreter. #119866
Labels
interpreter-core
(Objects, Python, Grammar, and Parser dirs)
Comments
|
Benchmarking shows negligible slowdown even when spilling the stack pointer on all escaping calls. |
|
@markshannon, are you still planning to work on this? If not, I can take a look at it. |
markshannon
added a commit
that referenced
this issue
Oct 7, 2024
* Spill the evaluation around escaping calls in the generated interpreter and JIT. * The code generator tracks live, cached values so they can be saved to memory when needed. * Spills the stack pointer around escaping calls, so that the exact stack is visible to the cycle GC.
brandtbucher
added a commit
that referenced
this issue
Mar 26, 2025
diegorusso
pushed a commit
to diegorusso/cpython
that referenced
this issue
Apr 1, 2025
seehwan
pushed a commit
to seehwan/cpython
that referenced
this issue
Apr 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For performance we keep the stack pointer in a register, however this means that the stack pointer is invisible to debuggers and other tools. If we spill the stack pointer across "escaping" calls, then most of the time we want to inspect the evaluation the stack pointer should be in memory.
Spilling the stack pointer is also a necessary precursor to deferred reference counting: faster-cpython/ideas#677, #117139, as it means there is no need to redundantly set the unused part of the stack to
NULL.Since the C compiler needs to spill values around calls, manually spilling the stack pointer has quite a low cost. It limits the freedom of the C compiler to allocate registers, but not that much.
Linked PRs
frame->stackpointeron release builds #131750The text was updated successfully, but these errors were encountered: