Canonicalisation of host function types

[CharlieTap]

I'm working on implementing RTT's and I'm wondering how to approach creating an RTT for a host function, say through the embedding API func_alloc(store, functtype, hostfunction). Given that host functions are registered prior to importing and potentially prior to any decoding we would need to persist any RTT's created at host function allocation such that they can be used during the process of canonicalisation of module defined types.

Currently I'm aggregating all RTTs in the store as solution, which works but I'm unsure if this is the right approach. For context this is important for instructions like call indirect which retrieve the RTT from the function instance, and without this approach I'd have to fall back to structural defined type matching.

I appreciate this is somewhat of an engine question as opposed to the spec, but I've seen the custom descriptors proposal around making RTTS something more concrete and was wondering how people suggest approaching this?

[rossberg]

Yes, that is the typical implementation. Note that this is rather unrelated to GC types, since functions required a runtime representation of their type in Wasm 1.0 already, to support the runtime check necessary for call_indirect.

[jakobkummerow]

I just came upon this topic in the context of Custom Descriptors. The conclusion I've arrived at (which is perhaps obvious in retrospect) is:

• The "canonical" RTTs introduced (implicitly) by the GC proposal are convenient to share across the entire "store" (or process, or similar). That allows for easy and efficient type checks of values flowing around between different instances. For host functions and other builtin things, you can pre-create them whenever they're first needed.
• The RTTs implied by Custom Descriptors are not cached or automatically shared: they are entirely under the module's control, so they're allocated when userspace requests it, and passed around explicitly by userspace, and if a different instance wants to use one of them for a ref.cast_desc, it needs to be handed both the value and the descriptor from their originating instance.

Pleasingly, this separation between (1) cached canonical unconfigurable RTTs and (2) uncached configurable RTTs potentially with JavaScript prototypes also achieves compatibility with the requirement to prevent cross-context (aka cross-"world", cross-<iframe>) information leaks in web browsers.

[tlively]

FWIW, this difference is why we stopped calling custom descriptors "RTTs." They're fundamentally different from the RTTs used for existing casts (including in call_indirect).