std: Minimize size of panicking on wasm #49488

alexcrichton · 2018-03-29T22:05:51Z

This commit applies a few code size optimizations for the wasm target to
the standard library, namely around panics. We notably know that in most
configurations it's impossible for us to print anything in
wasm32-unknown-unknown so we can skip larger portions of panicking that
are otherwise simply informative. This allows us to get quite a nice
size reduction.

Finally we can also tweak where the allocation happens for the
Box<Any> that we panic with. By only allocating once unwinding starts
we can reduce the size of a panicking wasm module from 44k to 350 bytes.

alexcrichton · 2018-03-29T22:05:57Z

r? @sfackler

est31 · 2018-03-29T22:50:08Z

So if I previously registered a custom panic handler to print the panic message via console.error (which gives you a nice stack trace btw), this panic handler will not print anything anymore?

In production you probably won't want such a handler so the default setting is probably most useful for production settings. Only asking in order to understand this PR.

scottmcm · 2018-03-30T05:26:17Z

src/libcore/panic.rs

+/// not use.
+#[unstable(feature = "std_internals", issue = "0")]
+#[doc(hidden)]
+pub trait BoxMeUp {


nit: shouldn't this be an unsafe trait since the box_me_up method must return a valid box pointer?

alexcrichton · 2018-03-30T06:58:20Z

@est31

this panic handler will not print anything anymore?

No, we will still invoke panic handlers

sfackler · 2018-03-30T07:05:06Z

src/libstd/panicking.rs

@@ -164,6 +166,12 @@ fn default_hook(info: &PanicInfo) {
    #[cfg(feature = "backtrace")]
    use sys_common::backtrace;

+    // Some platfors know that printing to stderr won't ever actually print


sfackler · 2018-03-30T07:09:09Z

src/libstd/sys/wasm/fast_thread_local.rs

+// option. This file may not be copied, modified, or distributed
+// except according to those terms.
+
+#![unstable(feature = "thread_local_internals", issue = "0")]


sfackler · 2018-03-30T07:11:59Z

LGTM other than the fast thread local stuff that sounds like it's not needed.

est31 · 2018-03-30T07:24:16Z

@alexcrichton yes but will it get a meaningful payload?

alexcrichton · 2018-03-30T07:27:45Z

@bors: r=sfackler

@est31 yes

bors · 2018-03-30T07:27:46Z

📌 Commit 03a18aa has been approved by sfackler

alexcrichton · 2018-03-31T05:26:09Z

@bors: r-

Ah talking with @fitzgen yesterday I'd like to add a test for this as well

fitzgen · 2018-03-31T06:32:58Z

cc @rust-lang/wg-wasm; just a heads up!

we can reduce the size of a panicking wasm module from 44k to 350 bytes.

alexcrichton · 2018-03-31T09:29:03Z

@bors: r=sfackler

bors · 2018-03-31T09:29:03Z

📌 Commit 033b177 has been approved by sfackler

bors · 2018-03-31T11:35:11Z

⌛ Testing commit 033b17760deef5251f9151f0347ad2e7d1192f1f with merge 31927a8e74b50918ba8a2d9f73c0072912245e10...

bors · 2018-03-31T12:50:10Z

💔 Test failed - status-travis

TimNN · 2018-04-07T09:30:08Z

Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[01:33:45] died due to signal 11
[01:33:45] error: test failed, to rerun pass '--test coretests'
[01:33:45]
[01:33:45]
[01:33:45] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "arm-linux-androideabi" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "core" "--"
---
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
ls: cannot access /home/travis/Library/Logs/DiagnosticReports/: No such file or directory
travis_time:end:018c9a0b:start=1523093342887998261,finish=1523093342904923268,duration=16925007
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:3045d9a8
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
find: `/home/travis/Library/Logs/DiagnosticReports': No such file or directory
travis_time:end:3045d9a8:start=1523093342910523349,finish=1523093342920816512,duration=10293163
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:035f6e3c
$ dmesg | grep -i kill
[   10.415132] init: failsafe main process (1094) killed by TERM signal

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN.

TimNN · 2018-04-07T09:30:37Z

Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[01:33:45] died due to signal 11
[01:33:45] error: test failed, to rerun pass '--test coretests'
[01:33:45]
[01:33:45]
[01:33:45] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "arm-linux-androideabi" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "core" "--"
---
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
ls: cannot access /home/travis/Library/Logs/DiagnosticReports/: No such file or directory
travis_time:end:018c9a0b:start=1523093342887998261,finish=1523093342904923268,duration=16925007
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:3045d9a8
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
find: `/home/travis/Library/Logs/DiagnosticReports': No such file or directory
travis_time:end:3045d9a8:start=1523093342910523349,finish=1523093342920816512,duration=10293163
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:035f6e3c
$ dmesg | grep -i kill
[   10.415132] init: failsafe main process (1094) killed by TERM signal

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN.

kennytm · 2018-04-07T09:53:46Z

~~The same error happened in the previous rollup, so pretty sure it is legit.~~ Or maybe it is #49775.

bors · 2018-04-07T14:40:11Z

☔ The latest upstream changes (presumably #49661) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · 2018-04-09T18:47:08Z

Ok I think I've debugged the issue of the failing test.

In the meantime I did a few more size optimizations here for libstd, @sfackler mind re-reviewing and re-r+'ing?

alexcrichton · 2018-04-09T20:00:49Z

@bors: p=0

Mark-Simulacrum · 2018-04-10T03:35:36Z

src/liballoc/raw_vec.rs

@@ -736,6 +736,10 @@ fn alloc_guard(alloc_size: usize) -> Result<(), CollectionAllocErr> {
    }
 }

+fn capacity_overflow() -> ! {


This feels non-obvious as to why it's extracted, maybe a comment would be good?

Mark-Simulacrum · 2018-04-10T03:36:41Z

src/libcore/fmt/mod.rs

@@ -1212,7 +1212,7 @@ impl<'a> Formatter<'a> {
            // truncation. However other flags like `fill`, `width` and `align`
            // must act as always.
            if let Some((i, _)) = s.char_indices().skip(max).next() {
-                &s[..i]
+                s.get(..i).unwrap_or(&s)


I think a comment would be helpful...

Mark-Simulacrum · 2018-04-10T03:38:40Z

src/libstd/panicking.rs

@@ -369,9 +424,7 @@ pub fn begin_panic<M: Any + Send>(msg: M, file_line_col: &(&'static str, u32, u3
 /// This is the entry point or panics from libcore, formatted panics, and
 /// `Box<Any>` panics. Here we'll verify that we're not panicking recursively,
 /// run panic hooks, and then delegate to the actual implementation of panics.
-#[inline(never)]
-#[cold]


Removing these seems fine, but it might be good to get some perf stats on some benchmark (though I don't have any particular ideas...).

FWIW the comment here is out of date and no longer correct, this function hasn't survived well through the various refactorings. I'll update it.

alexcrichton · 2018-04-10T14:23:54Z

Updated!

bors · 2018-04-13T13:19:06Z

☔ The latest upstream changes (presumably #49669) made this pull request unmergeable. Please resolve the merge conflicts.

This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.

Create one canonical location which panics with "capacity overflow" instead of having many. This reduces the size of a `panic!("{}", 1)` binary on wasm from 34k to 17k.

The expression `&s[..i]` in general can panic if `i` is out of bounds or not on a character boundary for a string, and this caused the codegen for `Formatter::pad` to be a bit larger than it otherwise needed to be. This commit replaces this with `s.get(..i).unwrap_or(&s)` which while having different behavior if `i` is out of bounds has a much smaller code footprint and otherwise avoids the need for `unsafe` code.

This commit removes allocation of the panic message in instances like `panic!("foo: {}", "bar")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now, and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed, but the panic=abort use case can be implemented at a later date if needed.

alexcrichton · 2018-04-13T14:04:49Z

ping r? @sfackler

sfackler · 2018-04-16T20:21:54Z

@bors r+

bors · 2018-04-16T20:21:55Z

📌 Commit 46d16b6 has been approved by sfackler

bors · 2018-04-16T23:19:47Z

⌛ Testing commit 46d16b6 with merge 3809bbf...

std: Minimize size of panicking on wasm This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.

bors · 2018-04-17T01:41:37Z

☀️ Test successful - status-appveyor, status-travis
Approved by: sfackler
Pushing 3809bbf to master...

rust-highfive assigned Mark-Simulacrum Mar 29, 2018

rust-highfive assigned sfackler and unassigned Mark-Simulacrum Mar 29, 2018

scottmcm reviewed Mar 30, 2018

View reviewed changes

alexcrichton force-pushed the small-wasm-panic branch from 582ebbd to 8050f5a Compare March 30, 2018 06:57

sfackler reviewed Mar 30, 2018

View reviewed changes

alexcrichton force-pushed the small-wasm-panic branch from 8050f5a to 03a18aa Compare March 30, 2018 07:27

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 30, 2018

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

alexcrichton force-pushed the small-wasm-panic branch from 03a18aa to 033b177 Compare March 31, 2018 09:28

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 Mar 31, 2018

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 31, 2018

kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 7, 2018

kennytm mentioned this pull request Apr 8, 2018

"died due to signal 11" in atomic::static_init libcore test on Android #49775

Closed

alexcrichton force-pushed the small-wasm-panic branch from f886518 to e9d6cc2 Compare April 9, 2018 18:46

Mark-Simulacrum reviewed Apr 10, 2018

View reviewed changes

alexcrichton force-pushed the small-wasm-panic branch from e9d6cc2 to bb9c9b2 Compare April 10, 2018 14:23

alexcrichton added 4 commits April 13, 2018 07:03

Reduce the size of panics in RawVec

66c5e3f

Create one canonical location which panics with "capacity overflow" instead of having many. This reduces the size of a `panic!("{}", 1)` binary on wasm from 34k to 17k.

alexcrichton force-pushed the small-wasm-panic branch from bb9c9b2 to 46d16b6 Compare April 13, 2018 14:04

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 Apr 16, 2018

bors merged commit 46d16b6 into rust-lang:master Apr 17, 2018

alexcrichton deleted the small-wasm-panic branch April 20, 2018 06:03

pnkfelix mentioned this pull request Dec 3, 2018

NLL error on closure, but not on equivalent function #55526

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

std: Minimize size of panicking on wasm #49488

std: Minimize size of panicking on wasm #49488

alexcrichton commented Mar 29, 2018

alexcrichton commented Mar 29, 2018

est31 commented Mar 29, 2018

scottmcm Mar 30, 2018

alexcrichton commented Mar 30, 2018

sfackler Mar 30, 2018

sfackler Mar 30, 2018

sfackler commented Mar 30, 2018

est31 commented Mar 30, 2018

alexcrichton commented Mar 30, 2018

bors commented Mar 30, 2018

alexcrichton commented Mar 31, 2018

fitzgen commented Mar 31, 2018

alexcrichton commented Mar 31, 2018

bors commented Mar 31, 2018

bors commented Mar 31, 2018

bors commented Mar 31, 2018

TimNN commented Apr 7, 2018

TimNN commented Apr 7, 2018

kennytm commented Apr 7, 2018 •

edited

Loading

bors commented Apr 7, 2018

alexcrichton commented Apr 9, 2018

alexcrichton commented Apr 9, 2018

Mark-Simulacrum Apr 10, 2018

sfackler Apr 10, 2018

Mark-Simulacrum Apr 10, 2018

Mark-Simulacrum Apr 10, 2018

alexcrichton Apr 10, 2018

alexcrichton commented Apr 10, 2018

bors commented Apr 13, 2018

alexcrichton commented Apr 13, 2018

sfackler commented Apr 16, 2018

bors commented Apr 16, 2018

bors commented Apr 16, 2018

bors commented Apr 17, 2018

std: Minimize size of panicking on wasm #49488

std: Minimize size of panicking on wasm #49488

Conversation

alexcrichton commented Mar 29, 2018

alexcrichton commented Mar 29, 2018

est31 commented Mar 29, 2018

Choose a reason for hiding this comment

alexcrichton commented Mar 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sfackler commented Mar 30, 2018

est31 commented Mar 30, 2018

alexcrichton commented Mar 30, 2018

bors commented Mar 30, 2018

alexcrichton commented Mar 31, 2018

fitzgen commented Mar 31, 2018

alexcrichton commented Mar 31, 2018

bors commented Mar 31, 2018

bors commented Mar 31, 2018

bors commented Mar 31, 2018

TimNN commented Apr 7, 2018

TimNN commented Apr 7, 2018

kennytm commented Apr 7, 2018 • edited Loading

bors commented Apr 7, 2018

alexcrichton commented Apr 9, 2018

alexcrichton commented Apr 9, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Apr 10, 2018

bors commented Apr 13, 2018

alexcrichton commented Apr 13, 2018

sfackler commented Apr 16, 2018

bors commented Apr 16, 2018

bors commented Apr 16, 2018

bors commented Apr 17, 2018

kennytm commented Apr 7, 2018 •

edited

Loading