gh-115999: Specialize LOAD_ATTR for instance and class receivers in free-threaded builds

[mpage]

This PR finishes specialization forLOAD_ATTR in the free-threaded build by adding support for class and instance receivers.

The bulk of it is dedicated to making the specialized instructions and the specialization logic thread-safe. This consists of using atomics / locks in the appropriate places, avoiding races in specialization related to reloading versions, and ensuring that the objects stored in inline caches remain valid when accessed (by only storing deferred objects). See the section on "Thread Safety" below for more details.

Additionally, making this work required a few unrelated changes to fix existing bugs or work around differences between the two builds that results from only storing deferred values (which causes in specialization failures in the free-threaded build when a value that would be stored in the cache is not deferred):

• Fixed a bug in the cases generator where it wasn't treating macro tokens as terminators when searching for the assignment target of an expression involving PyStackRef_FromPyObjectNew.
• Refactored test_descr.MiscTests.test_type_lookup_mro_reference to work when specialization fails (and also be a behavorial test).
• Temporarily skip test_capi.test_type.TypeTests.test_freeze_meta when running refleaks tests on free-threaded builds. Specialization failure triggers an existing bug.

Single-threaded Performance

• Performance is improved by ~12% on free-threaded builds.
• Performance is ~neutral on default builds. (Technically the benchmark runner reports a 0.2% improvement, but that looks like noise to me.)

We're leaving a bit of perf on the table by only storing deferred objects: we can't specialize attribute lookups that resolve to class attributes (e.g. counters, settings). I haven't measured how much perf we're giving up, but I'd like to address that in a separate PR.

Scalability

The object_cfunction and pymethod benchmarks are improved (1.4x slower -> 14.3x faster, 1.8x slower -> 13.0x faster, respectively). Other benchmarks appear unchanged.

I would expect that cmodule_function would also improve, but it looks like the benchmark is bottlenecked on increfing the int.__floor__ method that is returned from the call to _PyObject_LookupSpecial in math_floor (the incref happens in _PyType_LookupRef, which is called by PyObject_LookupSpecial):

cpython/Modules/mathmodule.c

Line 1178 in 3879ca0

PyObject *method = _PyObject_LookupSpecial(number, state->str___floor__);

Raw numbers:

Running benchmarks with 28 threads
                   Merge-base    This PR
object_cfunction    1.4x slower  14.3x faster
cmodule_function    1.7x slower   1.7x slower
mult_constant      12.8x faster  13.6x faster
generator          11.5x faster  12.2x faster
pymethod            1.8x slower  13.4x faster
pyfunction         12.2x faster  13.0x faster
module_function    14.5x faster  14.8x faster
load_string_const  13.0x faster  13.2x faster
load_tuple_const   12.7x faster  14.1x faster
create_pyobject    12.8x faster  13.5x faster
create_closure     13.9x faster  14.8x faster
create_dict        10.5x faster  13.3x faster
thread_local_read   3.9x slower   4.0x slower

Thread Safety

Thread safety of specialized instructions is addressed in a few different ways:

• Use atomics where needed.
• Lock the instance dictionary in _LOAD_ATTR_WITH_HINT.
• Only store deferred objects in the inline cache. All uops that retrieve objects from the cache are preceded by type version guards, which ensure that the (deferred) value retrieved from the cache is valid. The type version will be mutated before destroying the reference in the type. If the type held the last reference, then GC will need to run in order to reclaim the object. GC requires stopping the world, so if GC reclaims the object then we will see the new type version and the guard will fail.

Thread safety of specialization is addressed using similar techniques:

• Atomics / locking is used to access shared state.
• Specialization code is refactored to read versions at the start of specialization and store the same version in caches (as opposed to rereading the version). This ensures that the specialization is consistent with the version by avoiding races where the type or shared keys dictionary changes after we've queried it.

Stats

Following the instructions in the comment preceding specialize_attr_loadclassattr, I collected stats for the default build for both this PR and its merge base using ./python -m test_typing test_re test_dis test_zlib and compared them using Tools/scripts/summarize_stats.py. The results for LOAD_ATTR are nearly identical and are consistent with results from comparing the merge base against itself:

• Comparison
• Raw stats for merge base
• Raw stats for PR

• Issue: Make the specializing interpreter thread-safe in --disable-gil builds #115999

[colesbury]

Overall looks great!

I think I unintentionally changed the object_cfunction when cleaning it up for inclusion in CPython. It previously had a * 1.0 to coerce the value to a float and avoid the _PyObject_LookupSpecial.

(We should deal with the _PyObject_LookupSpecial bottlenecks, but it's a lower priority)

[colesbury]

I'm not thrilled with the lock here -- we've tried to avoid locking in the fast path dictionary accesses -- but given the overall perf gains, we can come back to this later.

[mpage]

The JIT test failure is unrelated to this PR: here is an example of it failing in the same way on a different PR.

The failing test, test_multiprocessing_spawn.test_processes.WithProcessesTestLock.test_repr_rlock, looks racy.

The test:

cpython/Lib/test/_test_multiprocessing.py

Lines 1525 to 1530 in 30efede

	t = threading.Thread(target=self._acquire_release,
	args=(lock, 0.2),
	name=f'T1')
	t.start()
	time.sleep(0.1)
	self.assertEqual('<RLock(SomeOtherThread, nonzero)>', repr(lock))

The function, _acquire_release, which runs in the thread:

cpython/Lib/test/_test_multiprocessing.py

Lines 1489 to 1497 in 30efede

	@staticmethod
	def _acquire_release(lock, timeout, l=None, n=1):
	for _ in range(n):
	lock.acquire()
	if l is not None:
	l.append(repr(lock))
	time.sleep(timeout)
	for _ in range(n):
	lock.release()

This will fail if _acquire_release runs to completion or doesn't acquire the lock before the test checks the repr.

[nascheme]

This looks a bit mysterious to me. Does this do something different than what class a: [...] does? Calling it an instance (which techically true) is a bit confusing too. I would just say a "set to an object that uses ...". It's a class object. If you need it written like this, I think a little helper function with a docstring explaining why it must be done that way would help:

def make_deferred_ref_count_obj():
    return type("Foo", (object,), {})

[nascheme]

Ah, I see later there is item.a = type("Foo", (object,), {}) so you want an expression not a statement.

[nascheme]

Regarding summarize_stats.py, I was expecting to see SPEC_FAIL_ATTR_DESCR_NOT_DEFERRED under the failure kind table for LOAD_ATTR. Do we know why it isn't included? It would give a clue to the amount of performance being missed due to only handling deferred refcount objects.

[mpage]

Regarding summarize_stats.py, I was expecting to see SPEC_FAIL_ATTR_DESCR_NOT_DEFERRED under the failure kind table for LOAD_ATTR. Do we know why it isn't included?

Yep: the stats were collected on the default build. I've updated the PR description to make that clear.

It would give a clue to the amount of performance being missed due to only handling deferred refcount objects.

That's a good point. Let me collect stats for the free-threaded build and see what things look like.

[mpage]

• Hypothesis failure is test_glob: test_selflink() failed on AMD64 RHEL8 Refleaks 3.x #109959
• TSAN failure looks new, but unrelated to this PR. I filed Race between PyUnicode_SET_UTF8 and _PyUnicode_CheckConsistency #128212 and will add a suppression.