v0.32.0 - 2024-05-28

Note:

• This release is the culmination of months of research, development and QA
  with a new execution engine utilizing register-based IR at its core boosting
  both startup and execution performance to new levels for the Wasmi interpreter.
• This release is accompanied with an article that presents some of the highlights.

Added

• Added a new execution engine based on register-machine bytecode. (#729)
  • The register-machine Wasmi Engine executes roughly 80-100% faster and
    compiles roughly 30% slower according to benchmarks conducted so far.
• Added Module::new_unchecked API. (#829)
  • This allows to compile a Wasm module without Wasm validation which can be useful
    when users know that their inputs are valid Wasm binaries.
  • This improves Wasm compilation performance for faster startup times by roughly 10-20%.
• Added Wasm compilation modes. (#844)
  • When using Module::new Wasmi eagerly compiles Wasm bytecode into Wasmi bytecode
    which is optimized for efficient execution. However, this compilation can become very
    costly especially for large Wasm binaries.
  • The solution to this problem is to introduce new compilation modes, namely:
    • CompilationMode::Eager: Eager compilation, what Wasmi did so far. (default)
    • CompilationMode::LazyTranslation: Eager Wasm validation and lazy Wasm translation.
    • CompilationMode::Lazy: Lazy Wasm validation and translation.
  • Benchmarks concluded that
    • CompilationMode::LazyTanslation: Usually improves startup performance by a factor of 2 to 3.
    • CompilationMode::Lazy: Usually improves startup performance by a factor of up to 27.
  • Note that CompilationMode::Lazy can lead to partially validated Wasm modules
    which can introduce non-determinism when using different Wasm implementations.
    Therefore users should know what they are doing when using CompilationMode::Lazy if this is a concern.
  • Enable lazy Wasm compilation with:

    let mut config = wasmi::Config::default();
    config.compilation_mode(wasmi::CompilationMode::Lazy);

  • When CompilationMode::Lazy or CompilationMode::LazyTranslation and fuel metering is enabled
    the first function access that triggers compilation (and validation) will charge fuel respective
    to the number of bytes of the Wasm function body. (#876)
• Added non-streaming Wasm module compilation. (#1035)
  • So far Wasmi only offered a streaming Wasm module compilation API, however most users
    probably never really needed that. So starting from this version both Module::new and
    Module::new_unchecked are now non-streaming with insane performance improvements of up
    to 80% in certain configurations.
  • For streaming Wasm module users we added Module::new_streaming and Module::new_streaming_unchecked APIs.
• Added Module::validate API. (#840)
  • This allows to quickly check if a Wasm binary is valid according to a Wasmi Engine config.
  • Note that this does not translate the Wasm and thus Module::new or Module::new_unchecked
    might still fail due to translation errors.
• CLI: Added --compilation-mode argument to enable lazy Wasm compilation. (#849)
• Added --verbose mode to Wasmi CLI by @tjpalmer. (#957)
  • By default Wasmi CLI no longer prints messages during execution.
• Added Memory::new_static constructor by @Ddystopia. (#939)
  • This allows to construct a Wasm Memory from a static byte array
    which is especially handy for certain embedded use cases.
• Added LinkerBuilder type. (#989)
  • Using LinkerBuilder to create new Linkers with the same set of host functions is a lot more
    efficient than creating those Linkers the original way. However, the initial LinkerBuilder
    construction will be as inefficient as building up a Linker previously.
• Added EnforcedLimits configuration option to Config. (#985)
  • Some users want to run Wasm binaries in a specially restricted or limited mode.
    For example this mode limits the amount of functions, globals, tables etc. can be defined
    in a single Wasm module.
    With this change they can enable this new strict mode using

    let mut config = wasmi::Config::default();
    config.engine_limits(wasmi::EnforcedLimits::strict());

    In future updates we might relax this to make EnforcedLimits fully customizable.
• Added EngineWeak constructed via Engine::weak. (#1003)
  • This properly mirrors the Wasmtime API and allows users to store weak references to the Engine.
• Added no-hash-maps crate feature to the wasmi crate. (#1007)
  • This tells the wasmi crate to avoid using hash based data structures which can be beneficial for
    running Wasmi in some embedded environments such as wasm32-unknown-unknown that do not support
    random sources and thus are incapable to spawn hash maps that are resilient to malicious actors.
  • Note that Wasmi has always avoided using hash map based data structures prior to this change so
    not enabling this new crate feature kind of acts as an optimization.
• Added Default implementation for Store<T> where T: Default. (#1031)
  • This mostly serves as a convenient way to create a minimal Wasmi setup.
• Added WasmTy implementations for f32 and f64 Rust primitives. (#1031)
  • This is convenience for Linker::func_wrap calls that take those primitives as arguments.
    Before this change users had to use F32 and F64 instead which is a bit cumbersome.

Changed

• Minimum Rust version set to 1.77. (#961)
• CLI: Enabled Wasm tail-calls and extend-const proposals by default. (#849)
  • We expect those Wasm proposals to be stabilized very soon so we feel safe to enable them by default already.
• Improved Debug and Display impls for NaNs of Wasm f32 and f64 values.
  • They now show nan:0x{bytes} where {bytes} is their respective raw bytes.
• Implement Sync for ResumableInvocation and TypedResumableInvocation. (#870)
• Properly mirror Wasmtime's fuel API. (#1002)
• Renamed some Wasmi items to improve its Wasmtime mirroring. (#1011)
• Improved Wasmtime API mirror for Store fuel. (#1002)
• Enabled Config::tail_call and Config::extended_const by default. (#1031)
  • Those Wasm proposals have been moved to phase 4 for many months now.

Removed

• Removed the stack-machine bytecode based Wasmi Engine backend. (#818)
  • The new register-machine bytecode based Wasmi Engine is more promising
    and the Wasmi team does not want to maintain two different engine backends.
• Removed FuelConsumptionMode from Config. (#877)
  • FuelConsumptionMode was required to differentiate between lazy and eager fuel consumption.
    This was necessary due to how lazy fuel consumption was implemented in that it would pre-charge
    for instruction execution were the exact amount of required fuel was not possible to determine
    at compilation time. Examples are memory.grow and table.copy instructions. The linked PR
    improved lazy fuel consumption to no longer pre-charge and instead pre-check if the operation
    is going to succeed and only charge fuel in that case.

Dev. Note

• Added execution fuzzing and differential fuzzing.
  • PRs: #832, #833
  • Both fuzzing strategies are applied on each commit in our CI pipeline.
• Updated CI jobs to use dtolnay/rust-toolchain instead of actions-rs because the latter was deprecated. (#842)