05d6c27142
* Reduce number of thread locals in trap handling This commit refactors the trap handling portion of wasmtime with a few goals in mind. I've been reading around a bit lately and feel that we have a bit too few globals and thread locals floating around rather than handles attached to contexts. I'm hoping that we can reduce the number of thread locals and globals, and this commit is the start of reducing this number. The changes applied in this commit remove the set of thread locals in the `traphandlers` module in favor of one thread local that's managed in a sort of stack discipline. This way each call to `wasmtime_call*` sets up its own stack local state that can be managed and read on that stack frame. Additionally the C++ glue code around `setjmp` and `longjmp` has all been refactored to avoid going back and forth between Rust and C++. Now we'll simply enter C++, go straight into `setjmp`/the call, and then traps will enter Rust only once to both learn if the trap should be acted upon and record information about the trap. Overall the hope here is that context passing between `wasmtime_call*` and the trap handling function will be a bit easier. For example I hope to remove the global `get_trap_registry()` function next in favor of storing a handle to a registry inside each instance, and the `*mut VMContext` can be used to reach the `InstanceHandle` underneath, and this trap registry. * Update crates/runtime/src/traphandlers.rs Co-Authored-By: Sergei Pepyakin <s.pepyakin@gmail.com> Co-authored-by: Sergei Pepyakin <s.pepyakin@gmail.com>
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.