gh-115999: Stop the world when invalidating function versions#124997
gh-115999: Stop the world when invalidating function versions#124997colesbury merged 1 commit intopython:mainpython/cpython:mainfrom mpage:gh-115999-stop-the-world-func-versionmpage/cpython:gh-115999-stop-the-world-func-versionCopy head branch name to clipboard
Conversation
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.
ac558ce to
d18f161
Compare
colesbury
left a comment
There was a problem hiding this comment.
Overall, this looks good to me but I have a few questions:
- Why do we need to differentiate
FUNC_VERSION_UNSETvs.FUNC_VERSION_CLEARED? - If I understand correctly,
func_versiondoesn't need atomics because we only initialize it once when the function is created (inMAKE_FUNCTION) and it's only cleared during a stop-the-world event (or in thetp_clearhandler). 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 thePyFunctionObject(i.e., inPyFunction_NewWithQualName)?
This allows us to assert that a version is never assigned to a function once it has been cleared.
Yep, that's correct.
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 |
…ython#124997) Stop the world when invalidating function versions 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.
The tier1 interpreter specializes
CALLinstructions 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 inMAKE_FUNCTIONand 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:
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.
--disable-gilbuilds #115999