fitzgen opened PR #8579 from fitzgen:missing-trampolines-and-subtyping
to bytecodealliance:main
:
Previously, we would look up a wasm-to-native trampoline in the Wasm module based on the host function's type. With Wasm GC and subtyping, this becomes problematic because a Wasm module can import a function of type
T
but the host can define a function of typeU
whereU <: T
. And if the Wasm has never defined typeU
then it wouldn't have a trampoline for it. But our trampolines don't actually care, they treat all reference values within the same type hierarchy identically. So the trampoline forT
would have worked in practice. But once we find a trampoline for a function, we cache it and reuse it every time that function is used in the same store again. Even if the function is imported with its precise type somewhere else. So then we would have a trampoline of the wrong type. But this happened to be okay in practice because the trampolines happen not to inspect their arguments or do anything with them other than forward them between calling convention locations. But relying on that accidental invariant seems fragile and like a gun aimed at the future's feet.This commit makes that invariant non-accidental, centering it and hopefully making it less fragile by doing so, by making every function type have an associated "trampoline type". A trampoline type is the original function type but where all the reference types in its params and results are replaced with the nullable top versions, e.g.
(ref $my_struct)
is replaced with(ref null any)
. Often a function type is its own associated trampoline type, as is the case for all functions that don't have take or return any references, for example. Then, all trampoline lookup begins by first getting the trampoline type of the actual function type, or actual import type, and then only afterwards finding for the pre-compiled trampoline in the Wasm module.Fixes https://github.com/bytecodealliance/wasmtime/issues/8432
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
fitzgen requested alexcrichton for a review on PR #8579.
fitzgen requested wasmtime-core-reviewers for a review on PR #8579.
fitzgen updated PR #8579.
alexcrichton submitted PR review:
Nice!
fitzgen updated PR #8579.
fitzgen has enabled auto merge for PR #8579.
fitzgen merged PR #8579.
Last updated: Nov 22 2024 at 16:03 UTC