gh-117139: Convert the evaluation stack to stack refs

[Fidget-Spinner]

Only tags all pointers 0b11 and NULL and immortal stuff as deferred for now.

• Issue: Set up tagged pointers in the evaluation stack #117139

[gvanrossum]

Could we hold off on this until 3.14? It's only a week until feature freeze for 3.13 (at which point main becomes 3.14), and this looks like a lot of churn in a time where we all would like stability to merge things that are actually needed in 3.13.

[Fidget-Spinner]

Could we hold off on this until 3.14? It's only a week until feature freeze for 3.13 (at which point main becomes 3.14), and this looks like a lot of churn in a time where we all would like stability to merge things that are actually needed in 3.13.

Alright. I always forget that ten other people are rushing in things at the same time as me. I don't think this will add any value for CPython 3.13 anyways at the moment.

[colesbury]

Could we hold off on this until 3.14?

That makes sense. I'll start providing feedback and reviewing this now, but it won't be merged in 3.13.

[colesbury]

I left some comments below, mostly minor. I'll take a closer look at bytecodes.c and the generated cases next.

[Fidget-Spinner]

I have made the requested changes; please review again

Namely:

1. Manually convert most of the bytecodes.c to stackref, instead of making it magically done by the cases generator.
2. Fix ownership problems when using steal or borrow.
3. Tag all pointers 0b11.

To be conservative, this PR only defers immortal objects at the moment and NULL.

[bedevere-app]

Thanks for making the requested changes!

@markshannon: please review the changes made to this pull request.

[colesbury]

These names do not look like other CPython function naming conventions to me. Can we do something like:

• PyStackRef_AsPyObjectBorrow(_PyStackRef) -- instead of this funcion

And, for example:

• PyStackRef_AsPyObjectSteal
• PyStackRef_FromPyObjectBorrow
• PyStackRef_FromPyObjectSteal

[Fidget-Spinner]

Note: I'm aware that certain decref options don't follow the semantics laid out in the issue. For now they're still safe because they will never operate on deferred objects. In PEP 703's plan, (non-immortal) floats and ints will not be deferred. So we're safe for now. However, in the future if we want to defer everything, then those need to be removed #118930.

[Fidget-Spinner]

5% performance hit on single-threaded default build: https://github.com/faster-cpython/benchmarking-public/tree/main/results/bm-20240511-3.14.0a0-144a6fa

[markshannon]

I really think we need a design document (in an issue) that we can discuss before doing more work on this.
I will attempt to summarize what I believe to be the design at the moment:

• Values on "localsplus", that is the fast locals and evaluation stack, of frames may be deferred. This includes suspended generators, so that deferred references may occur in the heap without being present in the frame stack
• A reference can only be deferred if it references an object whose class is in a fixed set of "deferrable" classes.
• Because deferred references can exist in the heap alone, objects that can have deferred references to them can only collected by scanning the heap.
• Calls to Py_Dealloc can cause a garbage collection and updating stacktop across all calls to Py_Dealloc and any other call that would escape the interpreter is deemed too expensive.
• This has the following consequences:
  • Since the stack pointer may not visible to the GC it must scan the whole stack including the dead part.
  • Unused stack items must be initialized to NULL, so that they don't point to invalid memory.
  • It is OK to scan dead pointers to deferred objects, as only the GC can free those objects.
  • I don't understand how non-deferred objects are freed, as we cannot safely look at non-deferred pointers.

[colesbury]

I really think we need a design document (in an issue)...

I'll add a more detailed summary of the GC changes to:

• Implement deferred reference counting in free-threaded builds #117376

I don't understand how non-deferred objects are freed, as we cannot safely look at non-deferred pointers

We don't look at non-deferred pointers above stacktop (beyond checking the tag).

To be clear, what we are describing here is an extra step in the GC that scans each thread's stack and ensures that deferred referenced objects from thread's stacks are kept alive. These frames are mostly not tracked and would not otherwise be considered by the GC.

We don't need to do anything special in this step for non-deferred references because those objects are kept alive by their reference count (i.e., computed gc_refs > 0), just like they are today.

[colesbury]

I've updated #117376.