Repository navigation
Make the specializing interpreter thread-safe in --disable-gil builds #115999
Description
Activity
(subscribing myself)
- added a commit that references this issue
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 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!
@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 :)@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. Aasland151 remaining items
- added a commit that references this issue
on Jul 4, 2025 - added 3 commits that reference this issue
on Jul 12, 2025 - added 4 commits that reference this issue
on May 22, 2026
Feature 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:
There are two primary concerns to balance while implementing this functionality on
main:Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
Specialization Families
Linked PRs
BINARY_OP#123926LOAD_GLOBALspecializations to avoid reloading {globals, builtins} keys #124953UNPACK_SEQUENCE#126600LOAD_GLOBALin free-threaded builds #126607TO_BOOL#126616CALLinstructions in free-threaded builds #127123LOAD_SUPER_ATTRin free-threaded builds #127128specialize#127167STORE_SUBSCR#127169SEND. #127426CALL_KWin free-threaded builds #127713STORE_ATTRin free-threaded builds. #127838LOAD_ATTRfor instance and class receivers in free-threaded builds #128164_STORE_ATTR_WITH_HINT#136249