GeezerVison is showing github.com — gh-115999: Stop the world when invalidating function versions by mpage · Pull Request #124997 · python/cpython
Conversation
mpage
commented
Oct 5, 2024
•
edited by bedevere-app
Bot
Loading
Uh oh!
There was an error while loading. Please reload this page.
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.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)?
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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?
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
efimov-mikhail
pushed a commit
to efimov-mikhail/cpython
that referenced
this pull request
Oct 9, 2024
…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.
Reviewers
ericsnowcurrently
Awaiting requested review from ericsnowcurrently
ericsnowcurrently is a code owner
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
|