Is the _PyBinopSpecializationDescr supposed to be extensible?

I assumed it's extensible and the extension manages it. The alternative is that it has a void* 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 the coverage, sqlalchemy_declarative, and sqlalchemy_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 the ZoneInfoTest class, which uses the array.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:

import array
import gc

def func():
    a=array.array('B', b'hello world')
    # call array_binop_specialize() 3 times, once per loop
    print("specialize")
    for _ in range(10): a[1]
    print("specialize")
    for _ in range(10): a[1]
    print("specialize")
    for _ in range(10): a[1]

func()

# array_subscr_free() is not called
del func
gc.collect()

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

It seems that array_subscr_guard behaves incorrectly. It never returns 0 (at least I can't make it return 0), which is needed to trigger array_subscr_free.

It seems that array_subscr_guard behaves incorrectly. It never returns 0 (at least I can't make it return 0), which is needed to trigger array_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't love having strong references in the inline caches, even just pointers to owned memory).