Uh oh!
There was an error while loading. Please reload this page.
Move various thread-local objects that were used in self-contained places out of Thread - #99989
Conversation
…l of StackingAllocatorHolder instead of Thread
…tRandomInt's implementation (no reliance on the Thread object)
Tagging subscribers to this area: @mangod9 |
EgorBo
commented
Mar 20, 2024
Does it address #99661 too? |
jkoritzinsky
commented
Mar 20, 2024
It doesn't currently (as that's used a little more often than the metric I used), but I can try making it so. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
jkotas
commented
Mar 20, 2024
This should be done in a separate change. It will chance a lot of places like assembly helpers. |
…y one place that will use it in release builds, and it will only be used once in the process (all other uses are debug-only)
jkoritzinsky
commented
Mar 22, 2024
/ba-g The unrecognized failure is #99142, which was closed as a fix was made after this PR started running CI |
Move the following type's thread-specific trackers out of the
Threadobject and into self-contained fields/thread_local globals:Each of these were only used in one centralized location and the only usage of the
Threadobject was to fetch the object for the given thread. I've validated that for each of these cases, MSVC makes the same inlining decisions it made before this PR.Also, remove the thread-specific RCW active list as that code is never used.