Is the_PyBinopSpecializationDescr supposed to be extensible?

I assumed it's extensible and the extension manages it. The alternative is that it has avoid* field that the extension sets and manages. The advantage of letting extensions allocate is that if there is no dynamic information, you don't need to allocate a new one for each instruction that uses the specialisation.

Are there any microbenchmarks that show this improves performance?

Also, based on the benchmarking results that were posted, it looks like thecoverage,sqlalchemy_declarative, andsqlalchemy_imperative benchmarks crashed on this branch but succeeded on the base commit. Were these fixed before merging?

This seems to cause the refleaks unit test to fail for the test_datetime module. The leak seems to be related to theZoneInfoTest class, which uses thearray.array type.

The crash should have been fixed. I'll check the leak.

Re tier 2 - maybe there's a way but we can just deopt them when jitting if not.

This seems to cause the refleaks unit test to fail for the test_datetime module. The leak seems to be related to the ZoneInfoTest class, which uses the array.array type.

The follow code is enough to reprodue the issue:

importarrayimportgcdeffunc():a=array.array('B',b'hello world')# call array_binop_specialize() 3 times, once per loopprint("specialize")for_inrange(10):a[1]print("specialize")for_inrange(10):a[1]print("specialize")for_inrange(10):a[1]func()# array_subscr_free() is not calleddelfuncgc.collect()

The specialization calls PyMem_Malloc() in array_binop_specialize(), but nothing calls PyMem_Free(): array_subscr_free() is not called.

It seems thatarray_subscr_guard behaves incorrectly. It never returns0 (at least I can't make it return0), which is needed to triggerarray_subscr_free.

It seems thatarray_subscr_guard behaves incorrectly. It never returns0 (at least I can't make it return0), which is needed to triggerarray_subscr_free.

I don't think that's the issue. Free needs to happen when the code object is freed, and currently it's not.

I'm going to revert this so it doesn't delay the release today.
#133498

It's not terribly important for this to be in 3.14.

@iritkatriel I just ran JIT benchmarks on the head of this branch. Those three benchmarks are still broken, and it makes the JIT 1% slower (with individual benchmarks slowing down up to 25%, one benchmark using 8% more memory):

https://github.com/faster-cpython/benchmarking-public/blob/main/results/bm-20250505-3.14.0a7%2B-454bfc5-JIT/README.md#vs-base-1

So we should make sure to benchmark the JIT when this lands again, or find a new approach (I don'tlove having strong references in the inline caches, even just pointers to owned memory).