Move _Py_RefTotal to PyInterpreterState

[ericsnowcurrently]

(See gh-100227.)

_Py_RefTotal holds the current global total number of refcounts. It only exists if Py_REF_DEBUG is defined (implied by Py_DEBUG). It is exposed by sys.gettotalrefcount() and set by Py_INCREF(), Py_DECREF(), etc. and _Py_NewReference().

Modications to _Py_RefTotal are currently protected by the GIL so it should be moved to PyInterpreterState. For various aspects of compatibility, it makes sense to keep the _Py_RefTotal symbol around (and correct) and keep returning the global total from sys.gettotalrefcount().

Also, _Py_RefTotal is used by stable ABI extensions only where Py_REF_DEBUG is defined (unlikely) and only where built against 3.9 or earlier. Just in case, though, we must still keep the global variable around, so any solution here must respect that.

Linked PRs

• gh-102304: Consolidate Direct Usage of _Py_RefTotal #102514
• gh-102304: Move _Py_RefTotal to _PyRuntimeState #102543
• gh-102304: Move the Total Refcount to PyInterpreterState #102545
• gh-102304: Add a What's New Entry About _Py_RefTotal #102845
• gh-102304: Fix Non-Debug Builds #102846
• gh-102304: Fix 2 New Stable ABI Functions #104762
• gh-102304: Fix Py_INCREF() stable ABI in debug mode #104763
• gh-102304: Temporarily Bump Py_LIMITED_API for 2 New Functions #104766
• [3.12] gh-102304: Fix 2 New Stable ABI Functions (gh-104762) #105123
• gh-102304: doc: Add links to Stable ABI and Limited C API #105345
• [3.12] gh-102304: doc: Add links to Stable ABI and Limited C API (GH-105345) #105347
• gh-102304: Enhance Simple ABI doc #105351
• [3.12] gh-102304: Fix Py_INCREF() stable ABI in debug mode (#104763) #105352
• [3.12] gh-102304: doc: Add links to Stable ABI and Limited C API (#105345) #105371
• gh-102304: Document Py_INCREF() change in What's New in Python 3.12 #105389
• gh-102304: Debug mode no longer supports Limited API 3.9 #105391
• gh-102304: Fix Py_INCREF() for limited C API 3.9 #105550
• [3.12] gh-102304: Fix Py_INCREF() for limited C API 3.9 (GH-105550) #105551
• gh-102304: Remove Py_INCREF() doc change #105552
• [3.12] gh-102304: Fix Py_INCREF() for limited C API 3.9 #105553
• gh-102304: Rename _Py_IncRefTotal_DO_NOT_USE_THIS() #107193
• [3.12] gh-102304: Rename _Py_IncRefTotal_DO_NOT_USE_THIS() (GH-107193) #107199
• [3.11] gh-102304: doc: Add links to Stable ABI and Limited C API (#105345) (#105371) #109901

[ericsnowcurrently]

From #100227 (comment):

FYI, I have a plan for _Py_RefTotal that should preserve stable ABI compatibility without breaking interpreter isolation (and without relying on granular locks). Basically:

• deprecate _Py_Reftotal but keep exporting the symbol (for stable ABI compatibility)
• add _PyRuntimeState.object_state.last_legacy_reftotal
• add _PyRuntimeState.object_state.reftotal
• update everywhere to use the reftotal field (for simplicity, add #define _Py_RefTotal _PyRuntime.object_state.reftotal)

We would update _Py_GetRefTotal() to something like this:

Py_ssize_t
_Py_GetRefTotal(void)
{
    // _Py_GetLegacyRefTotal() returns the value of the actual `_Py_RefTotal` global.
    Py_ssize_t legacy = _Py_GetLegacyRefTotal();
    _PyRuntimeState.object_state.reftotal += legacy - _PyRuntimeState.object_state.last_legacy_reftotal;
    _PyRuntimeState.object_state.last_legacy_reftotal = legacy;
    return _PyRuntimeState.object_state.reftotal;
}

All this assumes that folks are not using _Py_RefTotal directly.

---

For a per-interpreter GIL, I see two options:

1. add a granular lock around modifying _PyRuntimeState.object_state.reftotal, which would hurt the performance of incref/decref, but only on debug builds
2. switch to PyInterpreterState.object_state.reftotal and aggregate the values from all interpreters in _Py_GetRefTotal()

[ericsnowcurrently]

Alternately, from #100227 (comment):

_Py_RefTotal is only defined if Py_REF_DEBUG is defined.
All updates to _Py_RefTotal can be made atomic (which will have terrible performance with multiple parallel interpreters) to preserve the API.

[kumaraditya303]

I vote to make it atomic instead of per interpreter. I use this while debugging refleaks and making it per interp will effectively make it impossible to use. This is only used in debug builds so I am not too much concerned about performance.

[ericsnowcurrently]

I use this while debugging refleaks and making it per interp will effectively make it impossible to use.

Do you modify _Py_RefTotal? Otherwise, would using _Py_GetRefTotal() be good enough?

[kumaraditya303]

Do you modify _Py_RefTotal? Otherwise, would using _Py_GetRefTotal() be good enough?

I do that sometimes though that's not important. With this change is _Py_GetRefTotal functional even after runtime is finalized?

[ericsnowcurrently]

With this change is _Py_GetRefTotal functional even after runtime is finalized?

We would definitely make sure that happens, since that's basically how it works now, but I don't think I did that in my branch. Doing so means that we'd have to track leaks during each subinterpreter finalization, which I don't think I've been doing. That's manageable though.

[kumaraditya303]

We would definitely make sure that happens, since that's basically how it works now, but I don't think I did that in my branch. Doing so means that we'd have to track leaks during each subinterpreter finalization, which I don't think I've been doing. That's manageable though.

Have you tried making it atomic? It will preserve all existing behavior like working after runtime is finalized and would work for per interpreter GIL. This is important as otherwise we'll lose the ability to monitor refleaks across multiple runtime initializations .

[kumaraditya303]

We would definitely make sure that happens, since that's basically how it works now, but I don't think I did that in my branch. Doing so means that we'd have to track leaks during each subinterpreter finalization, which I don't think I've been doing. That's manageable though.

I haven't looked at the implementation but I think there might be complications in this because some of the things at startup happens when GIL is not created so might need some special casing to get right.

[ericsnowcurrently]

Have you tried making it atomic?

I started but haven't gotten back to it.

Regardless, I think it is worth having a per-interpreter reftotal for the following reasons:

• it identifies which interpreter is leaking
• it can help identify when an object is breaking isolation between interpreters
• objects are interpreter-specific so it makes sense that the ref total be too
• the obmalloc state is going to be per-interpreter, with the opportunity to report/investigate allocated blocks for each interpreter; it would be helpful for the reftotal to parallel that

otherwise we'll lose the ability to monitor refleaks across multiple runtime initializations .

What do you mean by this? Are you talking about objects that don't get freed during interpreter finalization? If so, how is multiple runtime initializations an exceptional case?

I think there might be complications in this because some of the things at startup happens when GIL is not created so might need some special casing to get right.

I'm not sure I follow. Please elaborate on how the GIL relates to tracking refleaks for each interpreter? Or are you talking about something else?

[kumaraditya303]

What do you mean by this? Are you talking about objects that don't get freed during interpreter finalization? If so, how is multiple runtime initializations an exceptional case?

We need to make sure that the counter remains valid even after the runtime is finalized. If there are multiple runtime finalizations we need to continue using the old counter value and not initialize it to zero as we'll lose the old value. This is what I meant.

[kumaraditya303]

I'm not sure I follow. Please elaborate on how the GIL relates to tracking refleaks for each interpreter? Or are you talking about something else?

While working on #101696 I noticed that the type cache is initialized before the gil is created which increfs None without GIL being held, I found this surprising hence I wanted to let you that you are aware of it, it is hidden in pycore_create_interpreter. This might not be relevant here but wanted to let you know just in case, from here ref total starts getting mutated.

[ericsnowcurrently]

the type cache is initialized before the gil is created which increfs None without GIL being held

Yeah, I ran into this too, while working on something in the last week (gh-101660? gh-102343?).

[vstinner]

With PR #104763 (backported to Python 3.12), I excluded _Py_IncRefTotal_DO_NOT_USE_THIS() and _Py_DecRefTotal_DO_NOT_USE_THIS() from the stable ABI. They were used in a debug build of Python, it's no longer the case. The stable ABI now uses opaque function calls.