gh-112529: Remove PyGC_Head from object pre-header in free-threaded build

[colesbury]

This avoids allocating space for PyGC_Head in the free-threaded build. The GC implementation for free-threaded CPython does not use the PyGC_Head structure.

• The trashcan mechanism uses the ob_tid field instead of _gc_prev in the free-threaded build.
• The GDB libpython.py file now determines the offset of the managed dict field based on whether the running process is a free-threaded build. Those are identified by the ob_ref_local field in PyObject.
• Fixes _PySys_GetSizeOf(), which incorrectly incorrectly included the size of PyGC_Head in the size of static PyTypeObject.

• Issue: Make the garbage collector thread-safe in --disable-gil builds #112529

[colesbury]

This now more closely matches the behavior of the Python check_sizeof function, although that function does not account for space for managed dict/weakref.

[nascheme]

This looks good to me.

I think the comment beside ob_tid should also note that it's used for the trashcan list.

It would be nice to have a bit more explanation of how ob_tid is being re-used by the GC. It wasn't totally clear to me when I was reviewing the previous PR. Maybe a comment somewhere inside gc_free_threading.c? My current understanding: when it is being used for the "gc refs" count, it cannot be used by the biased refcnt logic. So the GC code needs to be careful not to call any API that will fiddle refcnts. When it is being used as a list pointer (i.e. object stack), it does work as a valid thread-id and calling those APIs is safe (e.g. running finalizers).

Minor nit not really worth fixing: in libpython.py, I think the test could be if "ob_ref_local" in pyobj.fields()

[nascheme]

Another change that is now possible but maybe should be separate from this PR: _PyObject_IS_GC() could be optimized in the nogil build. That function is a bit expensive since it has to check for tp_is_gc() and possibly call it. Now that all objects have ob_gc_bits, we could store the "IS GC" status as another bit there, when the object is allocated.

In gc_free_threading.c, I think you mostly don't care about the "IS GC" check. You care if the tracked or finalized bits are set. You can just check those bits directly.

There are a couple potentially hot paths outside of gc_free_threading that call _PyObject_IS_GC() and they could just check a ob_gc_bits bit. It might be worth it. In my gh-44897 PR, having that bit would make it a bit faster. I still think enabling the "trashcan" for all GC objects is the right thing to do, rather than requiring the type of use the trashcan macros.

[colesbury]

I think the comment beside ob_tid should also note that it's used for the trashcan list.

Added

My current understanding: when it is being used for the "gc refs" count, it cannot be used by the biased refcnt logic. So the GC code needs to be careful not to call any API that will fiddle refcnts. When it is being used as a list pointer (i.e. object stack), it does work as a valid thread-id and calling those APIs is safe (e.g. running finalizers).

Yeah, that's correct. I've added a comment in update_refs.

Minor nit not really worth fixing: in libpython.py, I think the test could be if "ob_ref_local" in pyobj.fields()

That doesn't work because pyobj.fields() returns a list of gdb.Field instances.

Another change that is now possible but maybe should be separate from this PR: _PyObject_IS_GC() could be optimized in the nogil build...

Good point. I'll do that in a follow up PR.