348c597a8e
* Remove global state for trap registration There's a number of changes brought about in this commit, motivated by a few things. One motivation was to remove an instance of using `lazy_static!` in an effort to remove global state and encapsulate it wherever possible. A second motivation came when investigating a slowly-compiling wasm module (a bit too slowly) where a good chunk of time was spent in managing trap registrations. The specific change made here is that `TrapRegistry` is now stored inside of a `Compiler` instead of inside a global. Additionally traps are "bulk registered" for a module rather than one-by-one. This form of bulk-registration allows optimizing the locks used here, where a lock is only held for a module at-a-time instead of once-per-function. With these changes the "unregister" logic has also been tweaked a bit here and there to continue to work. As a nice side effect the `Compiler` type now has one fewer field that requires actual mutability and has been updated for multi-threaded compilation, nudging us closer to a world where we can support multi-threaded compilation. Yay! In terms of performance improvements, a local wasm test file that previously took 3 seconds to compile is now 10% faster to compile, taking ~2.7 seconds now. * Perform trap resolution after unwinding This avoids taking locks in signal handlers which feels a bit iffy... * Remove `TrapRegistration::dummy()` Avoid an case where you're trying to lookup trap information from a dummy module for something that happened in a different module. * Tweak some comments
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.