Stream: git-wasmtime

Topic: wasmtime / PR #4325 Use a `StoreOpaque` during backtraces...

Wasmtime GitHub notifications bot (Jun 27 2022 at 15:10):

alexcrichton opened PR #4325 from trap-backtrace-with-store to main:

Previous to this commit Wasmtime would use the GlobalModuleRegistry
when learning information about a trap such as its trap code, the
symbols for each frame, etc. This has a downside though of holding a
global read-write lock for the duration of this operation which hinders
registration of new modules in parallel. In addition there was a fair
amount of internal duplication between this "global module registry" and
the store-local module registry. Finally relying on global state for
information like this gets a bit more brittle over time as it seems best
to scope global queries to precisely what's necessary rather than
holding extra information.

With the refactoring in wasm backtraces done in #4183 it's now possible
to always have a StoreOpaque reference when a backtrace is collected
for symbolication and otherwise Trap-identification purposes. This
commit adds a StoreOpaque parameter to the Trap::from_runtime
constructor and then plumbs that everywhere. Note that while doing this
I changed the internal traphandlers::lazy_per_thread_init function to
no longer return a Result and instead just panic! on Unix if memory
couldn't be allocated for a stack. This removed quite a lot of
error-handling code for a case that's expected to quite rarely happen.
If necessary in the future we can add a fallible initialization point
but this feels like a better default balance for the code here.

With a StoreOpaque in use when a trap is being symbolicated that means
we have a ModuleRegistry which can be used for queries and such. This
meant that the GlobalModuleRegistry state could largely be dismantled
and moved to per-Store state (within the ModuleRegistry, mostly just
moving methods around).

The final state is that the global rwlock is not exclusively scoped
around insertions/deletions/is_wasm_trap_pc which is just a lookup and
atomic add. Otherwise symbolication for a backtrace exclusively uses
store-local state now (as intended).

The original motivation for this commit was that frame information
lookup and pieces were looking to get somewhat complicated with the
addition of components which are a new vector of traps coming out of
Cranelift-generated code. My hope is that by having a Store around for
more operations it's easier to plumb all this through.

<!--

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.
-->

Wasmtime GitHub notifications bot (Jun 27 2022 at 15:10):

alexcrichton requested fitzgen for a review on PR #4325.

Wasmtime GitHub notifications bot (Jun 27 2022 at 15:33):

alexcrichton updated PR #4325 from trap-backtrace-with-store to main.

Wasmtime GitHub notifications bot (Jun 27 2022 at 17:40):

pchickey submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2022 at 17:40):

pchickey submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2022 at 17:40):

pchickey created PR review comment:

        .expect("allocating memory map for altstack");

Wasmtime GitHub notifications bot (Jun 27 2022 at 17:58):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2022 at 19:19):

alexcrichton updated PR #4325 from trap-backtrace-with-store to main.

Wasmtime GitHub notifications bot (Jun 27 2022 at 20:25):

alexcrichton merged PR #4325.

Last updated: Nov 22 2024 at 17:03 UTC