Feature or enhancement

The_PyInterpreterFrame struct contains a strong reference to:

• f_executable - the currently executing code object
• f_funcobj - the function object
• f_locals - the locals object (often NULL)
• frame_obj - the frame object (often NULL)

We should use deferred references (in the free-threaded build) forf_executable andf_funcobj because they are a common source of reference count contention. The pointed to objects (code and function) already support deferred reference counting, but the references in the frame are not deferred.

I think we don't need to bother with changingf_locals for now. I don't think it's used frequently enough to be a bottleneck, but we can revisit it later if necessary.

Theframe_obj are typically unique -- not shared across threads -- so we don't need to bother with deferred reference counting forframe_obj.

Complications and hazards

_PyInterpreterFrame are also embedded in generators/coroutines andPyFrameObject, which are heap objects. We need to be careful that_PyStackRef fields are visible to the GC in order to be kept alive. Once an object is untracked, the_PyStackRef fields may no longer be valid: it's safe to callPyStackRef_CLOSE/CLEAR but not otherwise access or dereference those fields because the GC may have already collected them.

Linked PRs

• gh-123923: Defer refcounting forf_executable in_PyInterpreterFrame #123924
• gh-123923: Defer refcounting forf_funcobj in_PyInterpreterFrame #124026