gh-115999: Stop the world when invalidating function versions

[mpage]

The tier1 interpreter specializes CALL instructions based on the values of certain function attributes (e.g. __code__, __defaults__). The tier1 interpreter uses function versions to verify that the attributes of a function during execution of a specialization match those seen during specialization. A function's version is initialized in MAKE_FUNCTION and is invalidated when any of the critical function attributes are changed. The tier1 interpreter stores the function version in the inline cache during specialization. A guard is used by the specialized instruction to verify that the version of the function on the operand stack matches the cached version (and therefore has all of the expected attributes). It is assumed that once the guard passes, all attributes will remain unchanged while executing the rest of the specialized instruction.

Stopping the world when invalidating function versions ensures that all critical function attributes will remain unchanged after the function version guard passes in free-threaded builds. It's important to note that this is only true if the remainder of the specialized instruction does not enter and exit a stop-the-world point.

We will stop the world the first time any of the following function attributes are mutated:

• defaults
• vectorcall
• kwdefaults
• closure
• code

This should happen rarely and only happens once per function, so the performance impact on majority of code should be minimal.

Additionally, refactor the API for manipulating function versions to more clearly match the stated semantics.

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

[colesbury]

Overall, this looks good to me but I have a few questions:

• Why do we need to differentiate FUNC_VERSION_UNSET vs. FUNC_VERSION_CLEARED?
• If I understand correctly, func_version doesn't need atomics because we only initialize it once when the function is created (in MAKE_FUNCTION) and it's only cleared during a stop-the-world event (or in the tp_clear handler). Is that correct?
• Why do we bother with _PyFunction_SetVersion() at all? Why not just set the version from the code object when we construct the PyFunctionObject (i.e., in PyFunction_NewWithQualName)?

[mpage]

Why do we need to differentiate FUNC_VERSION_UNSET vs. FUNC_VERSION_CLEARED?

This allows us to assert that a version is never assigned to a function once it has been cleared.

If I understand correctly, func_version doesn't need atomics because we only initialize it once when the function is created (in MAKE_FUNCTION) and it's only cleared during a stop-the-world event (or in the tp_clear handler). Is that correct?

Yep, that's correct.

Why do we bother with _PyFunction_SetVersion() at all? Why not just set the version from the code object when we construct the PyFunctionObject (i.e., in PyFunction_NewWithQualName)?

That's a good question :) It looks it at one point versions would be re-assigned after changes to any of the critical attributes. #117028 changed to the current behavior where versions are never reset once they are cleared. That still doesn't explain why they are initialized to a non-zero value in MAKE_FUNCTION but not in PyFunction_New... though. Maybe they didn't want to waste versions on functions that were created only through the C-API?