-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Refactor stack overflow handling #123265
Refactor stack overflow handling #123265
Conversation
r? @ChrisDenton rustbot has assigned @ChrisDenton. Use |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very much in favour of containing platform specific stuff within platform specific directories. I'm less opinionated on where exactly to put the guard page handling but, sure, stack_overflow.rs makes sense to me.
Anyways this looks good to me, just a small nit
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c518e5a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeResultsThis 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.
Bootstrap: 667.497s -> 668.277s (0.12%) |
The binary size regressions are for actual binaries, not just metadata, which is a bit unfortunate. Was this expected? |
That is extremely weird, because this PR didn't really add any new code, it mainly just moved things around. |
|
Nearly all of that bloat is debug formatting. Filed #123356 to address what I believe to be the cause. |
Reduce code size of `thread::set_current` rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.
Reduce code size of `thread::set_current` rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.
…bilee Reduce code size of `thread::set_current` rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.
…nton Reduce code size of `thread::set_current` rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.
…nton Reduce code size of `thread::set_current` rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.
Rollup merge of rust-lang#123356 - joboet:set_current_size, r=ChrisDenton Reduce code size of `thread::set_current` rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.
Currently, every platform must implement a
Guard
that protects a thread from stack overflow. However, UNIX is the only platform that actually does so. Windows has a different mechanism for detecting stack overflow, while the other platforms don't detect it at all. Also, the UNIX stack overflow handling is split betweensys::pal::unix::stack_overflow
, which implements the signal handler, andsys::pal::unix::thread
, which detects/installs guard pages.This PR cleans this by getting rid of
Guard
and unifying UNIX stack overflow handling insidestack_overflow
(commit 1). Therefore we can get rid ofsys_common::thread_info
, which storesGuard
and the currentThread
handle and move thethread::current
TLS variable intothread
(commit 2).The second commit is not strictly speaking necessary. To keep the implementation clean, I've included it here, but if it causes too much noise, I can split it out without any trouble.