gh-116868: Avoid locking in PyType_IsSubtype

[DinoV]

This showed up as a heavy point of contention while testing PR #116775. Currently we just simply lock for PyType_IsSubType, when profiling is enabled on all threads PyCFunction_Check hits this pretty heavily and leads to a nearly 50% slow down vs. a lock free version.

This uses _Py_TryIncref to try and get a reference to the MRO and falls back to the lock only if that cannot succeed.

• Issue: Free-threaded builds can experience heavy contention on PyType_IsSubtype #116868

[colesbury]

Is there still reference count contention? In other words, will we want to start using some sort of deferred reference count here in the future?

[colesbury]

I'm probably using "deferred reference count" too broadly here. I'm thinking of something like:

1. PyType_IsSubtype uses a borrowed reference to self->tp_mro
2. Modifications to the mro use QSBR to delay decref'ing the old MRO

[DinoV]

Well we're no longer ending up in the parking lot which was the large source of the slowdown, I imagine there is still some amount of contention but it's not enough to obviously show up in gdb.

[DinoV]

Looking at it under perf it does look like ~8% is spent in _Py_DecRefShared so this probably is still significant and using QSBR probably makes a lot of sense here especially given how little this will ever change.

[colesbury]

LGTM.

I suspect we'll want to avoid reference counting the mro in PyType_IsSubtype in the future, but we can address that later.

[itamaro]

I suspect we'll want to avoid reference counting the mro in PyType_IsSubtype in the future, but we can address that later.

Is there an open issue to track the "addressing it later" bit?

[colesbury]

Is there an open issue to track the "addressing it later" bit?

It's in "Deferred tasks " in #108219