Skip stack_start_aligned for immediate-abort

[danielzgtg]

This improves startup performance by 16%, shown by an optimized hello-world program. glibc's pthread_getattr_np performs expensive syscalls when reading /proc/self/maps. That is all wasted with panic = immediate-abort active because init() immediately discards the return value from install_main_guard(). A similar improvement can be seen in environments that don't have /proc. This change is safe because the immediately succeeding comment says that we rely on Linux's "own stack-guard mechanism".

Tracking issue: #147286

Benchmark

Set it up with cargo new hello-world2, and replace these files:

# Cargo.toml
cargo-features = ["panic-immediate-abort"]

[package]
name = "hello-world"
version = "0.1.0"
edition = "2024"

[profile.release]
lto = true
panic = "immediate-abort"
codegen-units = 1
opt-level = "z"
strip = true

# .cargo/config.toml
[unstable]
build-std = ["std"]

Before

home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
  Time (mean ± σ):     524.8 µs ±  65.1 µs    [User: 276.1 µs, System: 187.0 µs]
  Range (min … max):   446.4 µs … 975.5 µs    3996 runs
 
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
  Time (mean ± σ):     519.4 µs ±  65.8 µs    [User: 282.1 µs, System: 177.7 µs]
  Range (min … max):   443.2 µs … 830.5 µs    3612 runs
 
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
  Time (mean ± σ):     520.0 µs ±  64.3 µs    [User: 277.1 µs, System: 182.1 µs]
  Range (min … max):   447.1 µs … 1001.3 µs    3804 runs

For a visualization of the problem, run cargo +stage1 build --release && perf record --call-graph dwarf -F max ./target/release/hello-world2 && perf script | inferno-collapse-perf | inferno-flamegraph > flamegraph.svg:

After

home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2Benchmark 1: target/release/hello-world2
  Time (mean ± σ):     444.7 µs ±  57.3 µs    [User: 257.4 µs, System: 130.2 µs]
  Range (min … max):   379.4 µs … 1289.3 µs    3893 runs
 
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
 
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
  Time (mean ± σ):     452.3 µs ±  60.7 µs    [User: 261.5 µs, System: 133.5 µs]
  Range (min … max):   374.9 µs … 1512.4 µs    4177 runs
 
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
 
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
  Time (mean ± σ):     441.2 µs ±  56.1 µs    [User: 256.2 µs, System: 128.8 µs]
  Range (min … max):   375.0 µs … 760.4 µs    4032 runs

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, joboet

[bjorn3]

This should also be done for other targets where the OS already provides guard pages for the stack, right?

[danielzgtg]

Added to install_main_guard_bsds

[joboet]

The FreeBSD code can also be skipped.

[danielzgtg]

Added to install_main_guard_freebsd

[bjorn3]

It would have been nice if we could lazily get the stack bounds of the main thread inside the SIGSEGV handler, but it looks like pthread_getattr_np is not async-signal-safe. Perhaps on Linux we could do our own parsing of /proc/self/maps on SIGSEGV when the stack bounds for the current thread aren't set yet? That would also help for the non-immediate-abort case. No need to do that in this PR though.

[Mark-Simulacrum]

@bors r+ rollup

View changes since this review

[Mark-Simulacrum]

@asomers do you have context on what this "optionally" here is referring to? Not really related to this PR but since we intend to guarantee stack guards, I'm wondering if we should be branching on something and defining our own if FreeBSD didn't?

[rust-bors]

📌 Commit 577dba9 has been approved by Mark-Simulacrum

It is now in the queue for this repository.