From cf7a309fbf2d405616f0c287c651b9b5a5156219 Mon Sep 17 00:00:00 2001 From: Mikhail Efimov Date: Tue, 16 Dec 2025 14:49:14 +0300 Subject: [PATCH] gh-119786: Remove mention of `_PyThreadState_BumpFramePointer` from `InternalDocs/interpreter.md` (#141816) Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com> --- InternalDocs/interpreter.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/InternalDocs/interpreter.md b/InternalDocs/interpreter.md index 38e9f6fced60..75acdf596a7f 100644 --- a/InternalDocs/interpreter.md +++ b/InternalDocs/interpreter.md @@ -226,10 +226,11 @@ Up through 3.10, the call stack was implemented as a singly-linked list of heap allocation for the stack frame. Since 3.11, frames are no longer fully-fledged objects. Instead, a leaner internal -`_PyInterpreterFrame` structure is used, which is allocated using a custom allocator -function (`_PyThreadState_BumpFramePointer()`), which allocates and initializes a -frame structure. Usually a frame allocation is just a pointer bump, which improves -memory locality. +`_PyInterpreterFrame` structure is used. Most frames are allocated contiguously in a +per-thread stack (see `_PyThreadState_PushFrame` in [Python/pystate.c](../Python/pystate.c)), +which improves memory locality and reduces overhead. +If the current `datastack_chunk` has enough space (`_PyThreadState_HasStackSpace`) +then the lightweight `_PyFrame_PushUnchecked` can be used instead of `_PyThreadState_PushFrame`. Sometimes an actual `PyFrameObject` is needed, such as when Python code calls `sys._getframe()` or an extension module calls -- 2.47.3