GeezerVison

I don't think you need the live flag in the stack ref. The presence of the bits in the mapping implies liveness.
That way the _PyStackRef struct can remain unchanged.

Something like this:

THE_MAP: dict[uintptr_t, object] = {}
THE_COUNTER = 0

class StackRef:
    bits: uintptr_t

    def __init__(self, obj):
        THE_COUNTER += 1
        self.bits = THE_COUNTER
        THE_MAP[self.bits] = obj
       
    def close(self):
        del THE_MAP[self.bits]

    def dup(ref: StackRef) -> StackRef:
        obj = THE_MAP[ref.bits]
        return StackRef(obj)

    def steal_obj(ref: StackRef) -> object:
        return THE_MAP.pop(ref.bits)
      
    def steal_ref(ref: StackRef) -> StackRef:
        return StackRef.from_obj_steal(self.steal_obj())
  
    @classmethod
    def from_obj_steal(obj: object) -> StackRef:
        res = StackRef(obj)
        Py_DECREF(object)
        return res

    @classmethod
    def from_obj_new(obj: object) -> StackRef:
        return StackRef(obj)

The hashtable in hashtable.c should provide the basics of the mapping.

Can you try this on the full set of tests, just to see if it would be acceptable on CI?

I did. It fails

    test.test_gdb.test_pretty_print test_capi test_exceptions
    test_regrtest test_repl test_sys test_tracemalloc

mainly because they count allocations/test out of memory situations, and the hashtable adds random allocations which breaks their careful calculations.

On my computer on free threaded builds with the stackref debugging mode, it takes 5 minutes to run the whole test suite. macOS is the fastest/"cheapest" runner we have right now because Cirrus Labs is sponsoring bare-metal runners IIRC. Without stackref debug mode, it takes 2 min 7 s. So roughly a 2.5x slowdown. Factoring that in, the fastest Cirruslabs runners takes 6 min to complete on this PR. So it should take 15 minutes to run the whole test suite. We would need to skip those tests above too, as those are known failures.

mainly because they count allocations/test out of memory situations

That's too bad. I wonder what it would take to fix those tests to be less fragile (tightly coupled to fine details)? I've opened gh-121978 so we can consider that separately.

This is already implemented on main by Mark.