gh-115999: Add partial free-thread specialization for BINARY_SUBSCR

[corona10]

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

• BINARY_SUBSCR_LIST_INT -> Should wait gh-115999: Add free-threaded specialization for STORE_SUBSCR #127169 would be merged.
• BINARY_SUBSCR_STR_INT / BINARY_SUBSCR_TUPLE_INT -> Immutable collections
• BINARY_SUBSCR_DICT -> AFAIK, PyDict_GetItemRef is thread-safe internally.
• BINARY_SUBSCR_GETITEM -> Should be disabled from now on until gh-115999: Enable specialization of CALL instructions in free-threaded builds #127123 is merged, I should follow several strategies from here.

[corona10]

I am going to write test codes at this week.

[corona10]

It should make to be thread-safe by using LOCK_TYPE(), but it will be handled with separated PRs.

[corona10]

@mpage Would you like to take a look?

[mpage]

Thanks for doing this! I left one comment inline, but otherwise looks good to me. I kicked off benchmark runs for default/free-threaded builds and will post the results once they're finished.

[corona10]

@mpage Done thanks!

[corona10]

FYI, aarch64 linux CI failure is not related to this PR, #127332 will fix the issue.

[mpage]

I should have caught this last time, but I think we want to use the fast-path for list accesses in BINARY_SUBSCR_LIST_INT.

[corona10]

I should have caught this last time, but I think we want to use the fast-path for list accesses in BINARY_SUBSCR_LIST_INT.

You mean that the fast-path that can avoid locking object?

[mpage]

You mean that the fast-path that can avoid locking object?

Yep

[corona10]

What about checking _Py_IsOwnedByCurrentThread and _PyObject_GC_IS_SHARED?

[mpage]

What about checking _Py_IsOwnedByCurrentThread and _PyObject_GC_IS_SHARED?

Yes, those are needed for correctness. I think for now we probably want to have two slightly different code paths for the free-threaded and default builds. The default build should continue to use the existing logic to fetch the item from the list. The free-threaded builds should use PyList_GetItemRef to take advantage of the fast-path.

[corona10]

Matt, I define a new _PyList_GetItemRef to avoid unnecessary type checking, which is guaranteed when the function is called by a specializer.

[corona10]

The default build of list_get_item_ref is almost same as current implementation,
we might able to this implementation to the default build also.

cpython/Objects/listobject.c

Lines 352 to 361 in 328187c

	#else
	staticinlinePyObject*
	list_get_item_ref(PyListObject*op, Py_ssize_ti)
	{
	if (!valid_index(i, Py_SIZE(op))){
	returnNULL;
	}
	returnPy_NewRef(PyList_GET_ITEM(op, i));
	}
	#endif

[mpage]

It would certainly be cleaner, but it might come with some performance cost in the default build.

[mpage]

Looking good! I kicked off new benchmark runs and will post the results here once they're finished. They take a few hours to run and there are other runs queued ahead of them, so that will probably be sometime tomorrow.

There are a couple tests that should be enabled using requires_specialization_ft now that we're specializing BINARY_SUBSCR in free-threaded builds:

• test_opcache.TestRacesDoNotCrash.test_binary_subscr_list_int
• test_dis.DisTests.test_binary_subscr_specialize - This should probably be deleted. It's covered by the tests that you've added and we want to move the specialization tests out of test_dis.

[mpage]

Nice! Most recent performance results look good:

• Neutral on the default build.
• ~1% improvement on free-threaded builds.

[mpage]

I think it would also be worth mentioning that this does not raise errors whereas PyList_GetItemRef does.

[vstinner]

It seems like the change introduced a regression: #127521.