Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize away poison guards when std is built with panic=abort #100603

Merged
merged 1 commit into from
Feb 14, 2024

Conversation

tmandry
Copy link
Member

@tmandry tmandry commented Aug 15, 2022

Note: To take advantage of this PR, you will have to use -Zbuild-std or build your own toolchain. rustup toolchains always link to a libstd that was compiled with panic=unwind, since it's compatible with panic=abort code.

When std is compiled with panic=abort we can remove a lot of the poison machinery from the locks. This changes the Flag and Guard types to be ZSTs. It also adds an uninhabited member to PoisonError so the compiler knows it can optimize away the Result::Err paths, and make LockResult<T> layout-equivalent to T.

Is this a breaking change?

PoisonError::new now panics if invoked from a libstd built with panic="abort" (or any non-unwind strategy). It is unclear to me whether to consider this a breaking change.

In order to encounter this behavior, both of the following must be true:

Using a libstd with panic="abort"

This is pretty uncommon. We don't build libstd with that in rustup, except in (Tier 2-3) platforms that do not support unwinding, most notably wasm.

Most people who do this are using cargo's -Z build-std feature, which is unstable.

panic="abort" is not a supported option in Rust's build system. It is possible to configure it using CARGO_TARGET_xxx_RUSTFLAGS, but I believe this only works on non-host platforms.

Creating PoisonError manually

This is also unlikely. The only common use case I can think of is in tests, and you can't run tests with panic="abort" without the unstable -Z panic_abort_tests flag.

It's possible that someone is implementing their own locks using std's PoisonError and defining "thread failure" to mean something other than "panic". If this is the case then we would break their code if it was used with a panic="abort" libstd. The locking crates I know of don't replicate std's poison API, but I haven't done much research into this yet.

I've touched on a fair number of considerations here. Which ones do people consider relevant?

@rustbot
Copy link
Collaborator

rustbot commented Aug 15, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Aug 15, 2022
@rust-highfive
Copy link
Collaborator

r? @thomcc

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 15, 2022
@tmandry
Copy link
Member Author

tmandry commented Aug 15, 2022

@rustbot label +T-libs-api -T-libs
r? rust-lang/t-libs-api

@rustbot rustbot added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 15, 2022
@thomcc
Copy link
Member

thomcc commented Aug 15, 2022

I'm in favor of this, but am unsure if it constitutes a breaking change. Either way, I think this probably needs an FCP. I'm going to reassign to someone on t-libs-api for that.

r? @m-ou-se

@rust-highfive rust-highfive assigned m-ou-se and unassigned thomcc Aug 15, 2022
@tmandry
Copy link
Member Author

tmandry commented Aug 31, 2022

@rustbot label +I-libs-api-nominated

@rustbot rustbot added the I-libs-api-nominated The issue / PR has been nominated for discussion during a libs-api team meeting. label Aug 31, 2022
@m-ou-se
Copy link
Member

m-ou-se commented Sep 6, 2022

Why not leave PoisonError the way it was, with an always working new function? It seems the performance benefits come from the changes to Flag and Guard, even if PoisonError remains unchanged.

@m-ou-se m-ou-se added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed I-libs-api-nominated The issue / PR has been nominated for discussion during a libs-api team meeting. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 6, 2022
@tmandry
Copy link
Member Author

tmandry commented Sep 6, 2022

The reason for the change to PoisonError is to make code paths that check the result of locking a Mutex trivially optimize away. I'd like the lock code we generate to be the same as if you hand-rolled an implementation without poisoning.

In theory this can be done with enough inlining and optimizations turned on, without a change to PoisonError. I can investigate that. It probably requires playing with #[inline] attributes a bit, which can impact performance in other ways, but hopefully the inliner behaves reasonably predictably.

@@ -267,6 +313,7 @@ where
{
match result {
Ok(t) => Ok(f(t)),
#[cfg(panic = "unwind")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

map_result isn't public API so instead of removing the variant you could add an unreachable_unchecked in this

@Dylan-DPC
Copy link
Member

@tmandry any updates on this? thanks

@dtolnay dtolnay assigned dtolnay and unassigned m-ou-se Jan 26, 2024
@dtolnay
Copy link
Member

dtolnay commented Jan 26, 2024

@rust-lang/libs-api:
@rfcbot fcp merge

I am in favor of this, including the change to make PoisonError::new abort in the narrow circumstances described above.

@rfcbot
Copy link

rfcbot commented Jan 26, 2024

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jan 26, 2024
@Amanieu
Copy link
Member

Amanieu commented Feb 3, 2024

I was actually looking into something similar, but where std::thread::panicking was changed to always return false when built with panic=abort. This would allow crates like scopeguard to optimize away scope guards that only trigger when unwinding (defer_on_unwind).

However it would be a (slight) breaking change since panicking could be called from the panic hook and would incorrectly return false there.

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Feb 3, 2024
@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Feb 3, 2024
@rfcbot
Copy link

rfcbot commented Feb 3, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Feb 13, 2024
@rfcbot
Copy link

rfcbot commented Feb 13, 2024

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@dtolnay
Copy link
Member

dtolnay commented Feb 13, 2024

@bors r+

@dtolnay
Copy link
Member

dtolnay commented Feb 13, 2024

@bors ping

@dtolnay dtolnay closed this Feb 13, 2024
@dtolnay dtolnay reopened this Feb 13, 2024
@dtolnay
Copy link
Member

dtolnay commented Feb 13, 2024

@bors ping

@bors
Copy link
Contributor

bors commented Feb 13, 2024

😪 I'm awake I'm awake

@dtolnay
Copy link
Member

dtolnay commented Feb 13, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Feb 13, 2024

📌 Commit 6b9289c has been approved by dtolnay

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 13, 2024
@bors
Copy link
Contributor

bors commented Feb 14, 2024

⌛ Testing commit 6b9289c with merge 81b757c...

@bors
Copy link
Contributor

bors commented Feb 14, 2024

☀️ Test successful - checks-actions
Approved by: dtolnay
Pushing 81b757c to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 14, 2024
@bors bors merged commit 81b757c into rust-lang:master Feb 14, 2024
12 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Feb 14, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (81b757c): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

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

Binary size

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

Bootstrap: 632.818s -> 633.405s (0.09%)
Artifact size: 306.16 MiB -> 306.10 MiB (-0.02%)

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Feb 15, 2024
celinval added a commit to model-checking/kani that referenced this pull request Feb 26, 2024
Upgrade toolchain to 2024-02-17. Relevant PR:

- rust-lang/rust#120500
- rust-lang/rust#100603

Fixes #87
Fixes #3034
Fixes #3037
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request May 4, 2024
Pkgsrc changes:
 * Adapt checksums and patches, some have beene intregrated upstream.

Upstream chnages:

Version 1.78.0 (2024-05-02)
===========================

Language
--------
- [Stabilize `#[cfg(target_abi = ...)]`]
  (rust-lang/rust#119590)
- [Stabilize the `#[diagnostic]` namespace and
  `#[diagnostic::on_unimplemented]` attribute]
  (rust-lang/rust#119888)
- [Make async-fn-in-trait implementable with concrete signatures]
  (rust-lang/rust#120103)
- [Make matching on NaN a hard error, and remove the rest of
  `illegal_floating_point_literal_pattern`]
  (rust-lang/rust#116284)
- [static mut: allow mutable reference to arbitrary types, not just
  slices and arrays]
  (rust-lang/rust#117614)
- [Extend `invalid_reference_casting` to include references casting
  to bigger memory layout]
  (rust-lang/rust#118983)
- [Add `non_contiguous_range_endpoints` lint for singleton gaps
  after exclusive ranges]
  (rust-lang/rust#118879)
- [Add `wasm_c_abi` lint for use of older wasm-bindgen versions]
  (rust-lang/rust#117918)
  This lint currently only works when using Cargo.
- [Update `indirect_structural_match` and `pointer_structural_match`
  lints to match RFC]
  (rust-lang/rust#120423)
- [Make non-`PartialEq`-typed consts as patterns a hard error]
  (rust-lang/rust#120805)
- [Split `refining_impl_trait` lint into `_reachable`, `_internal` variants]
  (rust-lang/rust#121720)
- [Remove unnecessary type inference when using associated types
  inside of higher ranked `where`-bounds]
  (rust-lang/rust#119849)
- [Weaken eager detection of cyclic types during type inference]
  (rust-lang/rust#119989)
- [`trait Trait: Auto {}`: allow upcasting from `dyn Trait` to `dyn Auto`]
  (rust-lang/rust#119338)

Compiler
--------

- [Made `INVALID_DOC_ATTRIBUTES` lint deny by default]
  (rust-lang/rust#111505)
- [Increase accuracy of redundant `use` checking]
  (rust-lang/rust#117772)
- [Suggest moving definition if non-found macro_rules! is defined later]
  (rust-lang/rust#121130)
- [Lower transmutes from int to pointer type as gep on null]
  (rust-lang/rust#121282)

Target changes:

- [Windows tier 1 targets now require at least Windows 10]
  (rust-lang/rust#115141)
 - [Enable CMPXCHG16B, SSE3, SAHF/LAHF and 128-bit Atomics in tier 1 Windows]
  (rust-lang/rust#120820)
- [Add `wasm32-wasip1` tier 2 (without host tools) target]
  (rust-lang/rust#120468)
- [Add `wasm32-wasip2` tier 3 target]
  (rust-lang/rust#119616)
- [Rename `wasm32-wasi-preview1-threads` to `wasm32-wasip1-threads`]
  (rust-lang/rust#122170)
- [Add `arm64ec-pc-windows-msvc` tier 3 target]
  (rust-lang/rust#119199)
- [Add `armv8r-none-eabihf` tier 3 target for the Cortex-R52]
  (rust-lang/rust#110482)
- [Add `loongarch64-unknown-linux-musl` tier 3 target]
  (rust-lang/rust#121832)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------

- [Bump Unicode to version 15.1.0, regenerate tables]
  (rust-lang/rust#120777)
- [Make align_offset, align_to well-behaved in all cases]
  (rust-lang/rust#121201)
- [PartialEq, PartialOrd: document expectations for transitive chains]
  (rust-lang/rust#115386)
- [Optimize away poison guards when std is built with panic=abort]
  (rust-lang/rust#100603)
- [Replace pthread `RwLock` with custom implementation]
  (rust-lang/rust#110211)
- [Implement unwind safety for Condvar on all platforms]
  (rust-lang/rust#121768)
- [Add ASCII fast-path for `char::is_grapheme_extended`]
  (rust-lang/rust#121138)

Stabilized APIs
---------------

- [`impl Read for &Stdin`]
  (https://doc.rust-lang.org/stable/std/io/struct.Stdin.html#impl-Read-for-%26Stdin)
- [Accept non `'static` lifetimes for several `std::error::Error`
  related implementations] (rust-lang/rust#113833)
- [Make `impl<Fd: AsFd>` impl take `?Sized`]
  (rust-lang/rust#114655)
- [`impl From<TryReserveError> for io::Error`]
  (https://doc.rust-lang.org/stable/std/io/struct.Error.html#impl-From%3CTryReserveError%3E-for-Error)

These APIs are now stable in const contexts:

- [`Barrier::new()`]
  (https://doc.rust-lang.org/stable/std/sync/struct.Barrier.html#method.new)

Cargo
-----

- [Stabilize lockfile v4](rust-lang/cargo#12852)
- [Respect `rust-version` when generating lockfile]
  (rust-lang/cargo#12861)
- [Control `--charset` via auto-detecting config value]
  (rust-lang/cargo#13337)
- [Support `target.<triple>.rustdocflags` officially]
  (rust-lang/cargo#13197)
- [Stabilize global cache data tracking]
  (rust-lang/cargo#13492)

Misc
----

- [rustdoc: add `--test-builder-wrapper` arg to support wrappers
  such as RUSTC_WRAPPER when building doctests]
  (rust-lang/rust#114651)

Compatibility Notes
-------------------

- [Many unsafe precondition checks now run for user code with debug
  assertions enabled] (rust-lang/rust#120594)
  This change helps users catch undefined behavior in their code,
  though the details of how much is checked are generally not
  stable.
- [riscv only supports split_debuginfo=off for now]
  (rust-lang/rust#120518)
- [Consistently check bounds on hidden types of `impl Trait`]
  (rust-lang/rust#121679)
- [Change equality of higher ranked types to not rely on subtyping]
  (rust-lang/rust#118247)
- [When called, additionally check bounds on normalized function return type]
  (rust-lang/rust#118882)
- [Expand coverage for `arithmetic_overflow` lint]
  (rust-lang/rust#119432)

Internal Changes
----------------

These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.

- [Update to LLVM 18](rust-lang/rust#120055)
- [Build `rustc` with 1CGU on `x86_64-pc-windows-msvc`]
  (rust-lang/rust#112267)
- [Build `rustc` with 1CGU on `x86_64-apple-darwin`]
  (rust-lang/rust#112268)
- [Introduce `run-make` V2 infrastructure, a `run_make_support`
  library and port over 2 tests as example]
  (rust-lang/rust#113026)
- [Windows: Implement condvar, mutex and rwlock using futex]
  (rust-lang/rust#121956)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet