Implement the Wasm GC instructions for converting between anyref and externref
#9435
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…d `externref` This commit implements two instructions: 1. `any.convert_extern` 2. `extern.convert_any` These instructions are used to convert between `anyref` and `externref` values. The `any.convert_extern` instruction takes an `anyref` value and converts it to an `externref` value. The `extern.convert_any` instruction takes an `externref` value and converts it to an `anyref` value. Rather than implementing wrapper objects -- for example an `struct AnyOfExtern(ExternRef)` type that is a subtype of `AnyRef` -- we instead reuse the same representation converted references as their unconverted reference. For example, `(any.convert_extern my_externref)` is identical to the original `my_externref` value. This means that we don't actually emit any clif instructions to implement these Wasm instructions; they are no-ops! Wasm code remains none-the-wiser because it cannot directly test for the difference between, for example, a `my_anyref` and the result of `(extern.convert_any my_anyref)` because they are in two different type hierarchies, so any direct `ref.test` would be invalid. The Wasm code would have to convert one into the other's type hierarchy, at which point it doesn't know whether wrapping/unwrapping took place. We did need some changes at the host API and host API implementation levels, however: * We needed to relax the requirement that a `wasmtime::AnyRef` only wraps a `VMGcRef` that points to an object that is a subtype of `anyref` and similar for `wasmtime::ExternRef`. * We needed to make the `wasmtime::ExternRef::data[_mut]` methods return an option of their associated host data, since any `externref` resulting from `(extern.convert_any ...)` does not have any associated host data. (This change would have been required either way, even if we used wrapper objects.)
github-actions
bot
added
fuzzing
Subscribe to Label Actioncc @fitzgen
This issue or pull request has been labeled: "fuzzing", "wasmtime:api", "wasmtime:c-api", "wasmtime:ref-types"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
alexcrichton
approved these changes
Oct 10, 2024
| @@ -363,8 +440,12 @@ impl ExternRef { | |||
| // so that we can get the store's GC store. But importantly we cannot | |||
| // trigger a GC while we are working with `gc_ref` here. | |||
| let gc_ref = self.inner.try_gc_ref(store)?.unchecked_copy(); | |||
| let externref = gc_ref.as_externref_unchecked(); | |||
There was a problem hiding this comment.
Given the footgun of using as_externref_unchecked would it make sense to remove that method entirely?
There was a problem hiding this comment.
Sure, I can make a follow up PR to do that, don't think it will be hard at this point.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit implements two instructions:
any.convert_externextern.convert_anyThese instructions are used to convert between
anyrefandexternrefvalues. Theany.convert_externinstruction takes anexternrefvalue and converts it to ananyrefvalue. Theextern.convert_anyinstruction takes ananyrefvalue and converts it to anexternrefvalue.Rather than implementing wrapper objects -- for example an
struct AnyOfExtern(ExternRef)type that is a subtype ofAnyRef-- we instead reuse the same representation converted references as their unconverted reference. For example,(any.convert_extern my_externref)is identical to the originalmy_externrefvalue. This means that we don't actually emit any clif instructions to implement these Wasm instructions; they are no-ops!Wasm code remains none-the-wiser because it cannot directly test for the difference between, for example, a
my_anyrefand the result of(extern.convert_any my_anyref)because they are in two different type hierarchies, so any directref.testwould be invalid. The Wasm code would have to convert one into the other's type hierarchy, at which point it doesn't know whether wrapping/unwrapping took place.We did need some changes at the host API and host API implementation levels, however:
We needed to relax the requirement that a
wasmtime::AnyRefonly wraps aVMGcRefthat points to an object that is a subtype ofanyrefand similar forwasmtime::ExternRef.We needed to make the
wasmtime::ExternRef::data[_mut]methods return an option of their associated host data, since anyexternrefresulting from(extern.convert_any ...)does not have any associated host data. (This change would have been required either way, even if we used wrapper objects.)