Problem

Two costs the new GC + free-threaded object model imposes on every thread, even single-threaded code:

1. Allocation-time GC tracking serializes on a global lock. GcState::track_object (crates/vm/src/gc_state.rs ~285) does generation_lists[0].write() (a global PyRwLock) + two SeqCst fetch_adds + a maybe_collect check for every tracked allocation, and untrack_object repeats it on death. Everything with HAS_TRAVERSE, an instance dict, or a heap type is tracked (crates/vm/src/object/core.rs ~2279) — that includes every Frame (i.e. every Python call) and every user-class instance. Under threads this is a contention point; single-threaded it's still a lock + SeqCst RMWs in the hottest allocation paths.

2. Every refcount operation is an atomic RMW. RefCount::inc = fetch_add(Relaxed), dec = fetch_sub(Release) + acquire fence (crates/common/src/refcount.rs ~105/153). The interpreter is refcount-saturated (stack pushes/pops, argument passing, code/globals clones per call), so this is a diffuse tax over everything — one big reason the loop baseline (acc += 1 per iteration) is 4.6x CPython even before any "interesting" work happens. LOAD_FAST_BORROW-style elision already helps but only covers local loads.

Suggested direction (keeping free threading — that's the point of this design)

For (1):

• Per-thread gen-0 nursery lists that are only merged (or stolen) at collection time — allocation becomes a lock-free thread-local list push; this mirrors what the per-thread datastack already does for frames.
• Relax the counters from SeqCst to Relaxed (they only feed the collection heuristic).
• Defer tracking for objects that usually die immediately: e.g. track a Frame only when it escapes (generator/traceback/sys._getframe) — a frame that never escapes can live and die untracked. (Or remove the per-call Frame allocation entirely, per the call-overhead issue, which makes this moot for calls.)

For (2), the proven free-threading-compatible option is biased refcounting (Choi et al., what CPython 3.13t ships): each object stores an owner thread id + a non-atomic local refcount for the owner, plus an atomic shared count for other threads. The owner thread — the overwhelmingly common case — does plain increments. This slots into the existing bit-packed RefCount design, and could be combined with deferred refcounting for objects referenced from the datastack (also a 3.13t technique; the borrow-bit PyStackRef machinery already present is halfway there).

Also worth auditing while in here: the object header is ~48 bytes before payload (refcount + vtable + gc bits/generation + two intrusive GC list pointers + type pointer) for every object including untracked ints/strs. Moving the GC link pointers out of untracked objects (side allocation or only for tracked types) would cut memory traffic across the board.

None of this changes user-visible semantics; it's all about making the no-GIL design pay less rent on the fast path.

Researched and written by Claude on behalf of @youknowone. Part of the performance tracking series.

Part of #38.