Wasm Proposals - Wasmtime

# Wasm Proposals

This document is intended to describe the current status of WebAssembly proposals in Wasmtime. For information about implementing a proposal in Wasmtime see the associated documentation.

WebAssembly proposals that want to be tier 2 or above are required to check all boxes in this matrix. An explanation of each matrix column is below.

## On-by-default proposals

Proposal | Phase 4 | Tests | Finished | Fuzzed | API | C API
--- | --- | --- | --- | --- | --- | ---
`mutable-globals` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`sign-extension-ops` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`nontrapping-fptoint` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`multi-value` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`bulk-memory` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`reference-types` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`simd` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`component-model` | ❌1 | ✅ | ✅ | ⚠️2 | ✅ | ❌3
`relaxed-simd` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`multi-memory` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`threads` | ✅ | ✅ | ✅4 | ❌5 | ✅ | ✅
`tail-call` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`extended-const` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅
`memory64` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅

1

The `component-model` proposal is not at phase 4 in the standardization process but it is still enabled-by-default in Wasmtime.

2

Various shapes of components are fuzzed but full-on fuzzing along the lines of `wasm-smith` are not implemented for components.

5

Fuzzing with threads is an open implementation question that is expected to get fleshed out as the `shared-everything-threads` proposal advances.

3

Support for the C API for components is desired by many embedders but does not currently have anyone lined up to implement it.

4

There are known issues with shared memories and the implementation/API in Wasmtime, for example they aren't well integrated with resource-limiting features in `Store`. Additionally `shared` memories aren't supported in the pooling allocator.

## Off-by-default proposals

Proposal | Phase 4 | Tests | Finished | Fuzzed | API | C API
--- | --- | --- | --- | --- | --- | ---
`function-references` | ✅ | ✅ | ❌ | ❌ | ✅ | ❌
`gc` 6 | ✅ | ✅ | ❌7 | ❌ | ✅ | ❌
`wide-arithmetic` | ❌ | ✅ | ✅ | ✅ | ✅ | ✅
`custom-page-sizes` | ❌ | ✅ | ✅ | ✅ | ✅ | ❌

6

There is also a tracking issue for the GC proposal.

7

The implementation of GC has known performance issues which can affect non-GC code when the GC proposal is enabled.

## Unimplemented proposals

Proposal | Tracking Issue
--- | ---
`branch-hinting` | #9463
`exception-handling` | #3427
`flexible-vectors` | #9464
`memory-control` | #9467
`stack-switching` | #9465
`shared-everything-threads` | #9466

## Feature requirements

For each column in the above tables, this is a further explanation of its meaning:

- Phase 4 - The proposal must be in phase 4, or greater, of the WebAssembly standardization process.

- Tests - All spec tests must be passing in Wasmtime and where appropriate Wasmtime-specific tests, for example for the API, should be passing. Tests must pass at least for Cranelift on all tier 1 platforms, but missing other platforms is otherwise acceptable.

- Finished - No open questions, design concerns, or serious known bugs. The implementation should be complete to the extent that is possible. Support must be implemented for all tier 1 targets and compiler backends.

- Fuzzed - Has been fuzzed for at least a week minimum. We are also confident that the fuzzers are fully exercising the proposal's functionality. The `module_generation_uses_expected_proposals` test in the `wasmtime-fuzzing` crate must be updated to include this proposal.

  > For example, it would not have been enough to simply enable reference types in the `compile` fuzz target to enable that proposal by default. Compiling a module that uses reference types but not instantiating it nor running any of its functions doesn't exercise any of the GC implementation and does not run the inline fast paths for `table` operations emitted by the JIT. Exercising these things was the motivation for writing the custom fuzz target for `table.{get,set}` instructions.

  One indication of the status of fuzzing is this file which controls module configuration during fuzzing.

- API - The proposal's functionality is exposed in the `wasmtime` crate's API. At minimum this is `Config::wasm_the_proposal` but proposals such as `gc` also add new types to the API.

- C API - The proposal's functionality is exposed in the C API.