gh-145685: Improve scaling of type attribute lookups

[colesbury]

Avoid locking in the PyType_Lookup cache-miss path if the type's tp_version_tag is already valid.

• Issue: Unexpected scaling bottleneck in _PyType_Lookup / _PyType_LookupStackRefAndVersion #145685

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @colesbury for commit 68c122c 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F145774%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again.

[mpage]

Would it be worth adding a test case to the scaling benchmark?

[mpage]

Do we need to hold the type lock around this?

[colesbury]

The operations in find_name_in_mro are individually thread-safe, although this allows for mutations to types to be interleaved with the MRO traversal. I think that's acceptable. There were already edge cases where that could happen due to ensure_shared_on_read() calls suspending the critical section during dictionary lookups in find_name_in_mro.

Importantly, if any type in the MRO chain is modified during lookup, the assigned version tag will be stale so any future cache lookups won't use it.

[colesbury]

Would it be worth adding a test case to the scaling benchmark?

This improves the scaling behavior, but it's not enough to scale linearly so I don't want to add a benchmark to ftscalingbench.py yet.

Here's the benchmark I've occasionally used locally: https://gist.github.com/colesbury/7d43e7dde89c1cb5574b5a2c73cc52b1

Some of the remaining issues:

1. The code keeps getting re-specialized and the specialization code itself causes reference count contention. This seems fixable in follow up PRs

2. Seq-lock contention in the MRO cache. This is trickier.