Skip to content

Commit cf7a309

Browse files
gh-119786: Remove mention of _PyThreadState_BumpFramePointer from InternalDocs/interpreter.md (#141816)
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
1 parent b372bd7 commit cf7a309

File tree

1 file changed

+5
-4
lines changed

1 file changed

+5
-4
lines changed

InternalDocs/interpreter.md

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -226,10 +226,11 @@ Up through 3.10, the call stack was implemented as a singly-linked list of
226226
heap allocation for the stack frame.
227227

228228
Since 3.11, frames are no longer fully-fledged objects. Instead, a leaner internal
229-
`_PyInterpreterFrame` structure is used, which is allocated using a custom allocator
230-
function (`_PyThreadState_BumpFramePointer()`), which allocates and initializes a
231-
frame structure. Usually a frame allocation is just a pointer bump, which improves
232-
memory locality.
229+
`_PyInterpreterFrame` structure is used. Most frames are allocated contiguously in a
230+
per-thread stack (see `_PyThreadState_PushFrame` in [Python/pystate.c](../Python/pystate.c)),
231+
which improves memory locality and reduces overhead.
232+
If the current `datastack_chunk` has enough space (`_PyThreadState_HasStackSpace`)
233+
then the lightweight `_PyFrame_PushUnchecked` can be used instead of `_PyThreadState_PushFrame`.
233234

234235
Sometimes an actual `PyFrameObject` is needed, such as when Python code calls
235236
`sys._getframe()` or an extension module calls

0 commit comments

Comments
 (0)