Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reimplement fast-path validation of MVP types #1930

Merged
merged 3 commits into from
Dec 2, 2024

Conversation

alexcrichton
Copy link
Member

This commit fixes an issue from #1906 which is preventing the upgrade of
wasm-tools in Wasmtime. That commit implemented a fast path by skipping
a function and reimplementing parts of it internally, but that then
caused Wasmtime to panic when other data structures weren't filled out.
The intention was that the user-facing interface doesn't change
depending on features, so this is an attempt at fixing the mistake in
that commit.

The fix here is to remove the fast path added and restructure it
differently. Instead now the fast and normal paths have much less
divergence which should prevent this issue from re-surfacing. This is
15% slower than main but it doesn't have the same bug as main so for
now that may be the best that can be done.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Benchmark the "fast path" in type interning.
This commit fixes an issue from bytecodealliance#1906 which is preventing the upgrade of
wasm-tools in Wasmtime. That commit implemented a fast path by skipping
a function and reimplementing parts of it internally, but that then
caused Wasmtime to panic when other data structures weren't filled out.
The intention was that the user-facing interface doesn't change
depending on features, so this is an attempt at fixing the mistake in
that commit.

The fix here is to remove the fast path added and restructure it
differently. Instead now the fast and normal paths have much less
divergence which should prevent this issue from re-surfacing. This is
15% slower than `main` but it doesn't have the same bug as `main` so for
now that may be the best that can be done.
@alexcrichton
Copy link
Member Author

cc @Robbepop

@Robbepop
Copy link
Collaborator

Robbepop commented Dec 2, 2024

@alexcrichton looks reasonable.

Can you provide me a link to the Wasmtime issue?

It is nicer that you managed to unify both implementations. The 15% slowdown is a bummer. Do you have an idea how to make it faster again? According to my benchmarks wasmparser v0.221 is still ~5-15% slower than wasmparser v0.100 for Wasmi but I deemed that an acceptable trade-off. However, I would rather want to make the newer wasmparser faster. :) I am hopeful we find more ways to do so.

Copy link
Collaborator

@Robbepop Robbepop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

The new needs_type_canonicalization needs a #[cfg(feature = "validate")] to fix CI issues.

@alexcrichton
Copy link
Member Author

No issue on the wasmtime side, just a failed build. The failure is in this loop which is iterating by rec groups and specifically this one was the failure where the fast path wasn't maintaining the rec group lists.

My guess is we could probably skip maintenance of the rec group lists entirely in the fast path, but only if the other paths that read these lists understand that they may be optional and/or not populated. That might require plumbing WasmFeatures more. I've long wanted to just store WasmFeatures on self in more places as it's currently plumbed in about a million places which is a bummer (and it's super small at 4-bytes so basically inconsequential to duplicate)

@alexcrichton alexcrichton added this pull request to the merge queue Dec 2, 2024
Merged via the queue into bytecodealliance:main with commit f51bdbb Dec 2, 2024
30 checks passed
@alexcrichton alexcrichton deleted the fix-fast-path branch December 2, 2024 22:41
@Robbepop
Copy link
Collaborator

Robbepop commented Dec 2, 2024

My guess is we could probably skip maintenance of the rec group lists entirely in the fast path, but only if the other paths that read these lists understand that they may be optional and/or not populated. That might require plumbing WasmFeatures more. I've long wanted to just store WasmFeatures on self in more places as it's currently plumbed in about a million places which is a bummer (and it's super small at 4-bytes so basically inconsequential to duplicate)

Sounds great and worthwhile!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants