GeezerVison is showing github.com — Make the specializing interpreter thread-safe in `--disable-gil` builds · Issue #115999 · python/cpython
Make the specializing interpreter thread-safe in --disable-gil builds #115999DescriptionFeature or enhancement
Proposal:
In free-threaded builds, the specializing adaptive interpreter needs to be made thread-safe. We should start with a small PR to simply disable it in free-threaded builds, which will be correct but will incur a performance penalty. Then we can work out how to properly support specialization in a free-threaded build.
These two commits from Sam's nogil-3.12 branch can serve as inspiration:
- specialize: make specialization thread-safe
- specialize: optimize for single-threaded programs
There are two primary concerns to balance while implementing this functionality on main:
- Runtime overhead: There should be no performance impact on normal builds, and minimal performance impact on single-threaded code running in free-threaded builds.
- Reducing code duplication/divergence: We should come up with a design that is minimally disruptive to ongoing work on the specializing interpreter. It should be easy for other devs to keep the free-threaded build working without having to know too much about it.
Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
Specialization Families
- [x] BINARY_OP
- [x] BINARY_SUBSCR - @corona10
- [x] CALL - @mpage
- [x] CALL_KW - @mpage
- [x] COMPARE_OP - @Yhg1s
- [x] CONTAINS_OP - @corona10
- [x] FOR_ITER - @Yhg1s
- [x] LOAD_ATTR - @mpage
- [x] LOAD_CONST
- [x] LOAD_GLOBAL - @mpage
- [x] LOAD_SUPER_ATTR - @nascheme
- [x] RESUME
- [x] SEND - @nascheme
- [x] STORE_ATTR - -@nascheme
- [x] STORE_SUBSCR - @colesbury
- [x] TO_BOOL - @corona10
- [x] UNPACK_SEQUENCE - @Eclips4
Linked PRs
Reacted by Donghee Na, Itamar Oren, Carl Meyer, Juhan Oskar Hennoste, Mikhail Efimov, Kirill Podoprigora and Vasily Ryabov Activitybrandtbucher commented on Feb 27, 2024 added a commit that references this issue on Mar 1, 2024gh-115999: Disable the specializing adaptive interpreter in free-thre… swtaarrs commented on Mar 1, 2024 This is now a performance (rather than correctness) issue for free-threaded builds, so I'm going to focus on more time-sensitive issues for a while. corona10 commented on Apr 20, 2024 @swtaarrs Out of curiosity, is there any progress or plan for this issue? Fidget-Spinner commented on Apr 24, 2024 @corona10 I'm planning to work on this after I get the deferred reference stack in. However, there are no concrete plans as of now. I'm really happy for you or anyone else to propose a design for the specializing interpreter with free-threaded safety! corona10 commented on Apr 25, 2024 @Fidget-Spinner cc @swtaarrs
Nice. I was also thinking about how to make it thread-safe in a seamless way since I agree with @swtaarrs.
But there is no good idea yet to solve the issue right now since I am not in a full-time position for this task :)
So it will be happy to see you have a good plan.
(I am curious that we can make them per-thread mechanism...)
By the way, in the short term, can we enable the specializer to be used only for the main thread if we can not solve the issue before 3.13 is released?
We can easily track the performance degradation between the default build because most of pyperformance benchmark are based on a single thread :) Fidget-Spinner commented on Apr 26, 2024 @corona10 for 3.13, I think generally we're focusing on scalability across multicore rather than single-threaded perf for 3.13. It's a bit too near to feature freeze for me to feel safe re-enabling specialization at this point. There are a lot of unsolved problems still even with specialization only on the main thread. Consider the following:
Two threads sharing the same code object, A and B. A is main thread.
Thread B is in LOAD_ATTR_METHOD_WITH_VALUES's action (after guards, it is in the middle of loading from a method)
Thread A is in LOAD_ATTR_METHOD_WITH_VALUES's guard, but then deopts, meaning the method reference is now most likely dead/invalid.
Thread B loads from LOAD_ATTR_METHOD_WITH_VALUE's method, it is now holding a dangling pointer.
Thread B pushes dangling pointer to the stack. Everything crashes.
I'm reading a few papers to get some inspiration and also looking at how CRuby and other runtimes deal with this. Will post back when I have an actual plan. Reacted by Donghee Na, Brett Simmers, Itamar Oren and Erlend E. Aasland added a commit that references this issue on Jul 4, 2025gh-115999: remove redundant check in free-threading from `_STORE_ATTR…
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|