GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — gh-115999: Stop the world when invalidating function versions by mpage · Pull Request #124997 · python/cpython

Conversation

@mpage

@mpage mpage commented Oct 5, 2024 •
edited by bedevere-app Bot
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@bedevere-app bedevere-app Bot mentioned this pull request Oct 5, 2024
Make the specializing interpreter thread-safe in --disable-gil builds #115999
Closed
@mpage mpage added the skip news label Oct 5, 2024
@mpage
Stop the world when invalidating function versions
d18f161
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.
@mpage
mpage force-pushed the gh-115999-stop-the-world-func-version branch from ac558ce to d18f161 Compare October 5, 2024 06:29
@mpage
mpage requested a review from colesbury October 5, 2024 06:58
@mpage
mpage marked this pull request as ready for review October 5, 2024 06:59
@mpage
mpage requested a review from ericsnowcurrently as a code owner October 5, 2024 06:59
@bedevere-app bedevere-app Bot added the awaiting review label Oct 5, 2024
colesbury
colesbury reviewed Oct 7, 2024
View reviewed changes

@colesbury colesbury left a comment

Copy link
Copy Markdown
Contributor

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.

All reactions
@mpage

mpage commented Oct 7, 2024

Copy link
Copy Markdown
Contributor Author

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?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@mpage
mpage requested a review from colesbury October 7, 2024 23:48
colesbury
colesbury approved these changes Oct 8, 2024
View reviewed changes
@bedevere-app bedevere-app Bot added awaiting merge and removed awaiting review labels Oct 8, 2024
@colesbury
colesbury merged commit e99f159 into python:main Oct 8, 2024
@bedevere-app bedevere-app Bot removed the awaiting merge label Oct 8, 2024
efimov-mikhail pushed a commit to efimov-mikhail/cpython that referenced this pull request Oct 9, 2024
@mpage @efimov-mikhail
pythongh-115999: Stop the world when invalidating function versions (p…
fc4dc44
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@colesbury colesbury colesbury approved these changes
@ericsnowcurrently 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

Labels

skip news

Projects

None yet

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.

2 participants

@mpage @colesbury
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.
You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.