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()

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.

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.

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?

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?

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.

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 .

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.

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?

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.

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.

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?).

Ah, it was gh-102545 (668eb4c).

@kumaraditya303, FYI, I've updated gh-102543 to preserve the reftotal across multiple runtime init/fini cycles.

I'm still not sure what the value of that is, though. The only case I can imagine is where you have a leak during the first runtime instance but not in the second and somehow you only check for leaks after the second. In my mind you'd check for leaks after each finalization. In fact, that's exactly what happens if with ./python -X showrefcount.

(Regardless, I certainly concede that there are possible use cases of which I'm not aware! 😄)

@kumaraditya303, with the above in mind, do you have any objections to gh-102543 and to using _Py_GetGlobalRefTotal() (instead of using _Py_RefTotal directly)?

Note that if you're on board then move to per-interpreter (gh-102545) shouldn't be an issue.

with the above in mind, do you have any objections to #102543 and to using _Py_GetGlobalRefTotal() (instead of using _Py_RefTotal directly)?

No objections to this. You can proceed with this 👍

Thanks! Your feedback was super helpful.

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.