Shard AllocMap Lock

[Mark-Simulacrum]

This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in #136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too.

Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally.

r? @RalfJung

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @rust-lang/wg-const-eval

[Mark-Simulacrum]

@bors try @rust-timer queue

[bors]

⌛ Trying commit b2bff4f with merge e402369...

[bors]

☀️ Try build successful - checks-actions
Build commit: e402369 (e4023695dcabc9a5f89d120c866679e546717831)

[rust-timer]

Finished benchmarking commit (e402369): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.3%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -2.0%, secondary 2.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-2.0%	[-2.9%, -1.0%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.0%	[-2.9%, -1.0%]	2

Cycles

Results (primary 2.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.6%	[2.6%, 2.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.6%	[2.6%, 2.6%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 772.928s -> 772.728s (-0.03%)
Artifact size: 328.22 MiB -> 328.21 MiB (-0.00%)

[Mark-Simulacrum]

Perf results look neutral enough that I'm okay moving forward given the non-perf measured gains for parallel executions.

@rustbot label: perf-regression-triaged

[RalfJung]

Suggested change

	// Note that this map on rustc workloads seems to be rather dense. In #136105 we considered
	// Note that this map on rustc workloads seems to be rather dense, but
	// in Miri workloads it is expected to be quite sparse. In #136105 we considered

[RalfJung]

This locks to_alloc while dedup is locked. Seems worth documenting the lock order (in the AllocMap type, I guess) to avoid deadlocks.