wasmtime / PR #8629 Remove the native ABI calling convent... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #8629 Remove the native ABI calling convent...

Wasmtime GitHub notifications bot (May 15 2024 at 21:15):

alexcrichton opened PR #8629 from alexcrichton:remove-native-abi to bytecodealliance:main:

This commit proposes removing the "native abi" calling convention used in Wasmtime. For background this ABI dates back to the origins of Wasmtime. Originally Wasmtime only had Func::call and eventually I added TypedFunc with TypedFunc::call and Func::wrap for a faster path. At the time given the state of trampolines it was easiest to call WebAssembly code directly without any trampolines using the native ABI that wasm used at the time. This is the original source of the native ABI and it's persisted over time under the assumption that it's faster than the array ABI due to keeping arguments in registers rather than spilling them to the stack.

Over time, however, this design decision of using the native ABI has not aged well. Trampolines have changed quite a lot in the meantime and it's no longer possible for the host to call wasm without a trampoline, for example. Compilations nowadays maintain both native and array trampolines for wasm functions in addition to host functions. There's a large split between Func::new and Func::wrap. Overall, there's quite a lot of weight that we're pulling for the design decision of using the native ABI.

Functionally this hasn't ever really been the end of the world. Trampolines aren't a known issue in terms of performance or code size. There's no known faster way to invoke WebAssembly from the host (or vice-versa). One major downside of this design, however, is that Func::new requires Cranelift as a backend to exist. This is due to the fact that it needs to synthesize various entries in the matrix of ABIs we have that aren't available at any other time. While this is itself not the worst of issues it means that the C API cannot be built without a compiler because the C API does not have access to Func::wrap.

Overall I'd like to reevaluate given where Wasmtime is today whether it makes sense to keep the native ABI trampolines. Sure they're supposed to be fast, but are they really that much faster than the array-call ABI as an alternative? This commit is intended to measure this.

This commit removes the native ABI calling convention entirely. For example VMFuncRef is now one pointer smaller. All of TypedFunc now uses *mut ValRaw for loads/stores rather than dealing with ABI business. The benchmarks with this PR are:

sync/no-hook/core - host-to-wasm - typed - nop - 5% faster

sync/no-hook/core - host-to-wasm - typed - nop-params-and-results - 10% slower

sync/no-hook/core - wasm-to-host - typed - nop - no change

sync/no-hook/core - wasm-to-host - typed - nop-params-and-results - 7% faster

These numbers are a bit surprising as I would have suspected no change in both "nop" benchmarks as well as both being slower in the params-and-results benchmarks. Regardless it is apparent that this is not a major change in terms of performance given Wasmtime's current state. In general my hunch is that there are more expensive sources of overhead than reads/writes from the stack when dealing with wasm values (e.g. trap handling, store management, etc).

Overall this commit feels like a large simplification of what we currently do in TypedFunc:

The number of ABIs that Wasmtime deals with is reduced by one. ABIs are pretty much always tricky and having fewer moving parts should help improve the understandability of the system.

All of the WasmTy trait methods and TypedFunc infrastructure is simplified. Traits now work with simple load/store methods rather than various other flavors of conversion.

The multi-return-value handling of the native ABI is all gone now which gave rise to significant complexity within Wasmtime's Cranelift translation layer in addition to the TypedFunc backing traits.

This aligns components and core wasm where components always use the array ABI and now core wasm additionally will always use the array ABI when communicating with the host.

I'll note that this still leaves a major ABI "complexity" with respect to native functions do not have a wasm ABI function pointer until they're "attached" to a Store with a Module. That's required to avoid needing Cranelift for creating host functions and that property is still true today. This is a bit simpler to understand though now that Func::new and Func::wrap are treated uniformly rather than one being special-cased.

Wasmtime GitHub notifications bot (May 15 2024 at 21:15):

alexcrichton requested wasmtime-core-reviewers for a review on PR #8629.

Wasmtime GitHub notifications bot (May 15 2024 at 21:15):

alexcrichton requested elliottt for a review on PR #8629.

Wasmtime GitHub notifications bot (May 15 2024 at 21:16):

alexcrichton requested fitzgen for a review on PR #8629.

Wasmtime GitHub notifications bot (May 15 2024 at 22:44):

github-actions[bot] commented on PR #8629:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"

Thus the following users have been cc'd because of the following labels:

fitzgen: wasmtime:ref-types

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (May 17 2024 at 00:49):

fitzgen submitted PR review:

Ship it!

Wasmtime GitHub notifications bot (May 17 2024 at 03:40):

alexcrichton updated PR #8629.

Wasmtime GitHub notifications bot (May 17 2024 at 03:41):

alexcrichton has enabled auto merge for PR #8629.

Wasmtime GitHub notifications bot (May 17 2024 at 04:15):

alexcrichton updated PR #8629.

Wasmtime GitHub notifications bot (May 17 2024 at 04:15):

alexcrichton has enabled auto merge for PR #8629.

Wasmtime GitHub notifications bot (May 17 2024 at 04:42):

alexcrichton merged PR #8629.

Last updated: Nov 22 2024 at 16:03 UTC