What If... stacker didn't exist - #158759

ChrisDenton · 2026-07-04T02:53:14Z

The OS is great at growing the stack on demand. All we need do is reserve an upper limit of virtual memory. Modern host systems have terabytes of virtual memory available to the process (if not orders of magnitude more) so even a relatively large upper limit is a drop in the ocean.

So I want to see what happens if we just used a larger stack size instead of using stacker to manually grow the stack. I've set a stack size that's larger then we'd probably ever want for the purposes of this experiment.

Experiments run

512mb: c57b15c (perf)
16mb: e5e97e3 (perf, crater 1, crater 2)
8mb: 45a2f24 (fails tests)

ChrisDenton · 2026-07-04T02:53:47Z

@bors try @rust-timer queue

What If... stacker didn't exist

rust-bors · 2026-07-04T08:59:55Z

💥 Test timed out after 21600s

ChrisDenton · 2026-07-04T10:26:28Z

@bors try @rust-timer queue

What If... stacker didn't exist

ChrisDenton · 2026-07-04T10:28:54Z

For some reason this fixes #93237 and #108499. Maybe stacker segfaults eventually?

rust-bors · 2026-07-04T12:32:39Z

☀️ Try build successful (CI)
Build commit: c57b15c (c57b15ce8ca8db97d7aa3123252e5aa7f758b561)
Base parent: c397dae (c397dae808f70caebab1fc4e11b3edf7e59f58c7)

rust-timer · 2026-07-04T13:12:46Z

Finished benchmarking commit (c57b15c): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.8%	[0.7%, 0.8%]	6
Improvements ✅ (primary)	-0.5%	[-1.4%, -0.2%]	137
Improvements ✅ (secondary)	-0.8%	[-2.9%, -0.2%]	175
All ❌✅ (primary)	-0.5%	[-1.4%, -0.2%]	137

Max RSS (memory usage)

Results (primary 2.0%, secondary 3.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.0%	[2.0%, 2.0%]	1
Regressions ❌ (secondary)	3.4%	[2.8%, 4.0%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[2.0%, 2.0%]	1

Cycles

Results (secondary -0.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.0%	[2.4%, 11.3%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.9%	[-6.6%, -2.0%]	19
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 485.944s -> 484.59s (-0.28%)
Artifact size: 393.37 MiB -> 390.75 MiB (-0.67%)

ChrisDenton · 2026-07-04T13:29:10Z

For a 512mb stack limit, the only regression (+0.74% to +0.78%) is the secondary match-stress benchmark (in each profile/scenario), I've not looked into why yet but let's see if a more reasonable default stack limit affects this in any way.

I'm pretty happy with the results so far though.

ChrisDenton · 2026-07-04T13:30:11Z

@bors try

What If... stacker didn't exist

theemathas · 2026-07-23T23:59:45Z

@saethlin Why queue two crater runs t the same time?

saethlin · 2026-07-24T06:07:13Z

Because I didn't realize the rerun was started already

theemathas · 2026-07-24T06:18:08Z

@craterbot abort name=pr-158759-2

craterbot · 2026-07-24T06:18:12Z

🗑️ Experiment pr-158759-2 deleted!

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-07-25T12:04:50Z

🚧 Experiment pr-158759-3 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-07-25T21:24:58Z

🎉 Experiment pr-158759-3 is completed!
📊 0 regressed and 0 fixed (579 total)
📊 300 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-158759-3/retry-regressed-list.txt ↩

ChrisDenton · 2026-07-25T22:18:38Z

Ok that crater run removed another few hundred spurious results and didn't turn up any interesting regressions or fixes. While we could keep whittling it down to zero, at this point I don't think there's anything more to be learned here.

theemathas · 2026-07-25T23:31:28Z

I find it somewhat suspicious that the spurious regressions are build OOM, while the spurious fixes are prepare fail.

ChrisDenton · 2026-07-25T23:39:38Z

I'll queue another crater (they're quick at this point) but can you say why you find it suspicious? Less OOMs would be expected. I would not expect more OOMs from this change as it removes one source of them. At worst it should turn them into stack overflows, which I'm just not seeing.

@craterbot check start=master#c397dae808f70caebab1fc4e11b3edf7e59f58c7 end=try#e5e97e3ef0ee95d34bea49cdac051ed1bbac01df crates=https://crater-reports.s3.amazonaws.com/pr-158759-3/retry-regressed-list.txt p=1

craterbot · 2026-07-25T23:39:44Z

👌 Experiment pr-158759-2 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

theemathas · 2026-07-25T23:49:13Z

Can this change increase memory consumption of rustc processes, causing other rustc processes to fail?

ChrisDenton · 2026-07-25T23:57:22Z

It shouldn't increase the maximum memory usage. It can hold on to memory for longer (the duration of the threads) rather than releasing it more quickly. I guess if the machine is already near its limits this could make a difference. But that's always a risk, depending on how processes end up being scheduled.

saethlin · 2026-07-26T06:53:12Z

I find it somewhat suspicious that the spurious regressions are build OOM, while the spurious fixes are prepare fail.

Isn't this typical of crater runs? The crater system oversubscribes nodes, OOMs until you reduce the number of jobs sufficiently is designed into the system. It just sucks.

craterbot · 2026-07-28T02:01:52Z

🚧 Experiment pr-158759-2 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-07-28T10:11:17Z

🎉 Experiment pr-158759-2 is completed!
📊 0 regressed and 0 fixed (300 total)
📊 228 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-158759-2/retry-regressed-list.txt ↩

This does not impact memory usage since this is only reserved, not committed, memory; it could crash if we allocate more than the commit limit and overcommit is disabled but for such small numbers it practically can't happen. This is an alternative to using `stacker` to grow the stack on-demand; rustc is transitioning to the same model - rust-lang/compiler-team#1011. 16MiB was chosen because when that was chosen as the limit in rustc (rust-lang/rust#158759), crater succeeded for practically all crates, so it should be enough for us as well. It's also two times the current number (8MiB) which is a lot.

This does not impact memory usage since this is only reserved, not committed, memory; it could crash if we allocate more than the commit limit and overcommit is disabled but for such small numbers it practically can't happen. This is an alternative to using `stacker` to grow the stack on-demand; rustc is transitioning to the same model - rust-lang/compiler-team#1011. 16MiB was chosen because when that was chosen as the limit in rustc (rust-lang#158759), crater succeeded for practically all crates, so it should be enough for us as well. It's also two times the current number (8MiB) which is a lot.

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 4, 2026