Luna Phipps-Costin (Oct 20 2022 at 17:19): Luna Phipps-Costin (Oct 20 2022 at 17:19):If I have only a reference to a store, and a type index (not an internal index, a wasm type index), can I retrieve the actual type instance? How?
Context:
@Daniel Hillerström and I are implementing the typed continuations proposal in wasmtime. In the proposal, the distinction between a continuation ref type and a function ref type is not explicit in ValType, which rather includes an index to the store which should hold the variant (function or continuation) and the type (function type / another type index). Stores do hold this information in the current spec. This comes up in Val::from_raw when we have a raw RawVal value and a ValType (and a store) and need to turn it into a tagged Val value.
Alex Crichton (Oct 20 2022 at 17:29):The answer probably depends on how y'all are writing this proposal, currently the embedding API of wasmtime gives out type information as object moreso than indices so it sounds like you're adding a new notion of a type index?
Alex Crichton (Oct 20 2022 at 17:30):The only type-level information currently neeeded is function types which all live at the Engine level with a VMSharedSignatureIndex to index, currently there are no store-level internal type index
Daniel Hillerström (Oct 20 2022 at 20:16):Yes, the proposal adds a new continuation type, which is parameterised by a function type, i.e. a type index.
Alex Crichton (Oct 20 2022 at 20:19):in that case if you have a VMSharedSignatureIndex you'll look that up in Engine
Alex Crichton (Oct 20 2022 at 20:19):although dealing with types is done quite carefully to avoid the locks on Engine or clones as much as possible, so things aren't always straightforward
Luna Phipps-Costin (Oct 20 2022 at 21:03):Thanks Alex! You've pointed out some important things I missed. Types weren't in the store prior to function references, despite what I said. And they in fact are not referenced by indices in the spec. They are translated to addresses, which I believe corresponds to the internal wasmtime indices in Store. So we need to implement the static vs dynamic types addition to function references. We need to allocate all static types into dynamic types with an internal wasmtime store index (Stored<T>, right?) during module allocation. I can keep looking around for this, but if you happen to have this on hand, do you know where we would do that allocation? I believe it would occur right before we populate store.store_data.funcs, which I can't find (it's not in allocate where I would expect it).
Alex Crichton (Oct 20 2022 at 21:04):hm I'm not sure I quite follow, but for any Store-related stuff you can shove it directly in StoreData<T> .. . actually lemme get a link
Alex Crichton (Oct 20 2022 at 21:05):anything internal to Wasmtime itself can get stored here since most internal operations work with &StoreOpaque
Alex Crichton (Oct 20 2022 at 21:06):you won't want to use Stored<T> since that's mostly just for public-facing API details like struct Instance(Stored<InstanceData>) (unless this is public-facing in which case it may be useful)
Alex Crichton (Oct 20 2022 at 21:07):So we need to implement the static vs dynamic types addition to function references
I think this is the bit I don't quite follow, by static types I think you mean more-or-less the type section of the wasm module (right?) but for dynamic types I'm not sure what you mean here. The answer may be as simple as "alex please go read the spec" too
Luna Phipps-Costin (Oct 21 2022 at 21:48):Thanks for all the help. After messing around for a while longer, I've decided that I can't do what I need from the Store. I believe I must attain a reference to the Module in wasmtime::Val::from_raw (or its caller, wasmtime::Func::call_impl, etc) in order to access types indexable by a wasm (static) type index (It looks like a Module does have this information). I believe this because as I understand, the wasmtime Store is shared across modules and therefore cannot store or access data particular to a single module. Sound about right? Is there any way to access the Module from either of those functions?
Feel free to ignore my ramblings about the spec, I think what I was saying was totally wrong, sorry :)
Alex Crichton (Oct 22 2022 at 17:30):You're right in that a Store can have many modules instantiated within it, and while it currently has handles to modules for other reasons I don't think there's an identifier per-se to go from a local module's type index to some identifier which can be used to acquire the Module and then map the local type index. Instead though for these sorts of use cases of type information you'll want to probably use VMSharedSignatureIndex and Engine-level type information. Basically once you get past the compilation phase you typically don't want to deal with module-local indices any more if possible.
That all being said I'm not quite sure what the end goal of this is or what embedder API you're envisioning for the use case here, so I could also be totally off in how this would need to work.
Last updated: Dec 23 2024 at 13:07 UTC