alexcrichton opened PR #3932 from no-backtraces
to main
:
This commit adds support to Wasmtime to disable, at compile time, the
gathering of backtraces on traps. Thewasmtime
crate now sports a
wasm-backtrace
feature which, when disabled, will mean that backtraces
are never collected at compile time nor are unwinding tables inserted
into compiled objects.The motivation for this commit stems from the fact that generating a
backtrace is quite a slow operation. Currently backtrace generation is
done with libunwind and_Unwind_Backtrace
typically found in glibc or
other system libraries. When thousands of modules are loaded into the
same process though this means that the initial backtrace can take
nearly half a second and all subsequent backtraces can take upwards of
hundreds of milliseconds. Relative to all other operations in Wasmtime
this is extremely expensive at this time. In the future we'd like to
implement a more performant backtrace scheme but such an implementation
would require coordination with Cranelift and is a big chunk of work
that may take some time, so in the meantime if embedders don't need a
backtrace they can still use this option to disable backtraces at
compile time and avoid the performance pitfalls of collecting
backtraces.In general I tried to originally make this a runtime configuration
option but ended up opting for a compile-time option becauseTrap::new
otherwise has no arguments and always captures a backtrace. By making
this a compile-time option it was possible to configure, statically, the
behavior ofTrap::new
. Additionally I also tried to minimize the
amount of#[cfg]
necessary by largely only having it at the producer
and consumer sites.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
alexcrichton updated PR #3932 from no-backtraces
to main
.
pchickey submitted PR review.
alexcrichton merged PR #3932.
Last updated: Dec 23 2024 at 12:05 UTC