std: Minimize size of panicking on wasm by alexcrichton · Pull Request #49488 · rust-lang/rust

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

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

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

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

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

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

I think a comment would be helpful...

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

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 8050f5aCompare March 30, 2018 06:57

sfackler reviewed Mar 30, 2018
View reviewed changes

Comment threadsrc/libstd/panicking.rs Outdated
sfacklerMar 30, 2018
Copy link
Copy Markdown
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
platfor

sfackler reviewed Mar 30, 2018
View reviewed changes

Comment threadsrc/libstd/sys/wasm/fast_thread_local.rs Outdated
sfacklerMar 30, 2018
Copy link
Copy Markdown
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wat

alexcrichton force-pushed the small-wasm-panic branch from 8050f5a to 03a18aaCompare 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 033b177Compare 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 e9d6cc2Compare 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 bb9c9b2Compare 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 46d16b6Compare 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:masterApr 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

Uh oh!

Uh oh!

Conversation

alexcrichton commented Mar 29, 2018

Uh oh!

alexcrichton commented Mar 29, 2018

Uh oh!

est31 commented Mar 29, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Mar 30, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sfackler commented Mar 30, 2018

Uh oh!

est31 commented Mar 30, 2018

Uh oh!

alexcrichton commented Mar 30, 2018

Uh oh!

bors commented Mar 30, 2018

Uh oh!

alexcrichton commented Mar 31, 2018

Uh oh!

fitzgen commented Mar 31, 2018

Uh oh!

alexcrichton commented Mar 31, 2018

Uh oh!

bors commented Mar 31, 2018

Uh oh!

bors commented Mar 31, 2018

Uh oh!

bors commented Mar 31, 2018

Uh oh!

TimNN commented Apr 7, 2018

Uh oh!

TimNN commented Apr 7, 2018

Uh oh!

kennytm commented Apr 7, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Apr 7, 2018

Uh oh!

alexcrichton commented Apr 9, 2018

Uh oh!

alexcrichton commented Apr 9, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Apr 10, 2018

Uh oh!

bors commented Apr 13, 2018

Uh oh!

alexcrichton commented Apr 13, 2018

Uh oh!

sfackler commented Apr 16, 2018

Uh oh!

bors commented Apr 16, 2018

Uh oh!

bors commented Apr 16, 2018

Uh oh!

bors commented Apr 17, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

kennytm commented Apr 7, 2018•
edited
Loading