-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-115999: Disable the specializing adaptive interpreter in free-threaded builds #116013
Conversation
!buildbot nogil |
🤖 New build scheduled with the buildbot fleet by @colesbury for commit db4f433 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
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.
This looks good to me, but I'd like someone working on the specializing interpreter to review it as well.
@brandtbucher, I saw your comment #115999. Would you be able to review this?
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.
I'll do the review. Looks good to me too. I was wondering if DECREMENT_ADAPTIVE_COUNTER() shouldn't just be an error. Otherwise only 1-2 nits.
Let me know if you need help figuring out the remaining test failures. |
The |
@swtaarrs - it looks like the free-threaded refleaks builds are broken on main: https://buildbot.python.org/all/#/builders/1226 |
Yeah, I've been trying (unsuccessfully) to bisect the failure for a bit. I'll update this PR with Guido's comment soon either way. |
This should be ready for review again. The test failures are from gh-116099. |
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.
Yeah! After the other PR lands you can merge the new main and then maybe @colesbury can merge this? (Or set up auto-merge.)
…e-threaded builds (python#116013) For now, disable all specialization when the GIL might be disabled.
…e-threaded builds (python#116013) For now, disable all specialization when the GIL might be disabled.
…e-threaded builds (python#116013) For now, disable all specialization when the GIL might be disabled.
For now, disable all specialization when the GIL might be disabled. We can reenable functionality as it is properly supported.
Disabling specialization was just a few lines in
pycore_code.h
, then there are two related changes:Define an alternate implementation of
DECREMENT_ADAPTIVE_COUNTER()
for free-threaded builds that aborts, as a sanity check.Add some code to the interpreter generator to avoid unused variable warnings for variables only used by code within
#ifdef ENABLE_SPECIALIZATION
blocks (likethis_instr
andcounter
here). There are a variety of ways to suppress these warnings. I went with(void)foo;
because it seemed like the most straightforward option, but I'm open to other suggestions. (Py_UNUSED(foo)
won't work since it's intended for variables that are completely unused, and it changes the variable's name to_unused_foo
.)Issue: Make the specializing interpreter thread-safe in
--disable-gil
builds #115999