Backport WorkerLocal

[zetanumbers]

#107782 added a WorkerLocal into rustc_data_structures. Due to it being ported from the old rustc rayon fork it required also porting Registry and sort of hack it in there. This PR replaces new version with the old one while trying to backport whatever microoptimizations were added. But I doubt #107782's manual benchmarks as those aren't significantly big to differentiate from the noise, although that's from my experience.

One difference I haven't yet addressed is an indirection through thread-local WORKER_THREAD_STATE pointer. I've found that changing its type to ManuallyDrop<OnceCell<WorkerThread>> itself is essentially a clean up/refactor which I've stashed for now.

cc @Zoxc

[rustbot]

r? @nikomatsakis

rustbot has assigned @nikomatsakis.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 72 candidates
• Random selection from 17 candidates

[Zoxc]

I'd just copy over the whole new file to keep the updated safety comments and microoptimizations, then just change it to share just the Registry type, so it doesn't make use of WorkerThread at all. The use of WorkerThread adds a null check and the indirection, so that would be slightly slower. That overhead can be avoided with #155688, but I'm a bit unsure about that change.

[zetanumbers]

If I did that I would copy old code back due to this registry struct. I've copied all of the safety comments and microoptimizations. The aforementioned null check is unavoidable as it is done for REGISTRY thread-local too due to OnceCell::get returning an Option.

[nikomatsakis]

@Zoxc (do you want to take this review, or should I?)

[Zoxc]

The aforementioned null check is unavoidable

Not on deref which is the hot function (used for arena allocators).

[nikomatsakis]

r? @Zoxc

Feel free to assign back to me, Zoxc, or re-roll.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[zetanumbers]

I'd just copy over the whole new file to keep the updated safety comments and microoptimizations, then just change it to share just the Registry type, so it doesn't make use of WorkerThread at all. The use of WorkerThread adds a null check and the indirection, so that would be slightly slower. That overhead can be avoided with #155688, but I'm a bit unsure about that change.

I've rewritten this PR more conservatively. I've just replaced the old version with the new one. However I had to rename Registry into ComplementaryRegistry to avoid confusion between these two. That is because I didn't find a good way to use rustc_thread_pool::Registry directly as I would need to create it before creating a thread pool, which would require more intrusive changes.

I think this PR is done but CI for some reason is broken.

@rustbot ready

[Zoxc]

That is because I didn't find a good way to use rustc_thread_pool::Registry directly as I would need to create it before creating a thread pool, which would require more intrusive changes.

I'm a bit confused to why this is a problem?

[rust-bors]

☔ The latest upstream changes (presumably #160284) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.