f5b505de04
* Remove the `jit_function_registry` global state This commit removes on the final pieces of global state in wasmtime today, the `jit_function_registry` module. The purpose of this module is to help translate a native backtrace with native program counters into a wasm backtrace with module names, function names, and wasm module indices. To that end this module retained a global map of function ranges to this metadata information for each compiled function. It turns out that we already had a `NAMES` global in the `wasmtime` crate for symbolicating backtrace addresses, so this commit moves that global into its own file and restructures the internals to account for program counter ranges as well. The general set of changes here are: * Remove `jit_function_registry` * Remove `NAMES` * Create a new `frame_info` module which has a singleton global registering compiled module's frame information. * Update traps to use the `frame_info` module to symbolicate pcs, directly extracting a `FrameInfo` from the module. * Register and unregister information on a module level instead of on a per-function level (at least in terms of locking granluarity). This commit leaves the new `FRAME_INFO` global variable as the only remaining "critical" global variable in `wasmtime`, which only exists due to the API of `Trap` where it doesn't take in any extra context when capturing a stack trace through which we could hang off frame information. I'm thinking though that this is ok, and we can always tweak the API of `Trap` in the future if necessary if we truly need to accomodate this. * Remove a lazy_static dep * Add some comments and restructure
Wasmtime: a WebAssembly Runtime
A Bytecode Alliance project
Wasmtime is a standalone wasm-only optimizing runtime for WebAssembly and WASI. It runs WebAssembly code outside of the Web, and can be used both as a command-line utility or as a library embedded in a larger application.
To get started, visit wasmtime.dev.
There are Rust, C, and C++ toolchains that can compile programs with WASI. See the WASI intro for more information, and the WASI tutorial for a tutorial on compiling and running programs using WASI and wasmtime, as well as an overview of the filesystem sandboxing system.
Wasmtime passes the WebAssembly spec testsuite. To run it, update the
tests/spec_testsuite submodule with git submodule update --remote, and it
will be run as part of cargo test.
Wasmtime does not yet implement Spectre mitigations, however this is a subject of ongoing research.
Additional goals for Wasmtime include:
- Support a variety of host APIs (not just WASI), with fast calling sequences, and develop proposals for additional API modules to be part of WASI.
- Facilitate development and testing around the Cranelift and Lightbeam JITs, and other WebAssembly execution strategies.
- Develop a native ABI used for compiling WebAssembly suitable for use in both JIT and AOT to native object files.
Including Wasmtime in your project
Wasmtime exposes an API for embedding as a library through the wasmtime subcrate,
which contains both a high-level and safe Rust API, as well as a C-compatible API
compatible with the proposed WebAssembly C API.
For more information, see the Rust API embedding chapter of the Wasmtime documentation.
It's Wasmtime.