How do descriptors relate to rtt's and generics from post-MVP GC ideas

[eqrion]

The GC proposal had a section for post-MVP ideas. Two related ideas were explicit rtt's and generics (or parametric polymorphism).

How does this proposals relate to these ideas? Are descriptors just explicit rtts or are there differences?

[sjrd]

There's no parametric polymorphism in sight here. :)

Descriptors are however supercharged RTTs. They basically supersede that concept, with additional features:

• They carry user-space data
• They support mirroring subtyping, thanks to the introduction of exact heap types
• They can have meta descriptors (although I still don't know what toolchain would use that capacity)
• And of course the JS interop stuff

The only potential gap is that descriptors currently only apply to structs, whereas the RTT idea description mentioned also applying to array.

[tlively]

Just to consider what it would look like to add explicit RTTs on top of descriptors:

Descriptor structs can be viewed as either containing the RTT for their described type or wrapping that RTT. In either case, if RTTs were explicit, it would be redundant to pass an RTT to an allocation that already takes a descriptor. Furthermore, allocating a descriptor would require providing the RTT for the described type. So we would have four cases:

1. Non-described, non-descriptor type: Takes an explicit RTT at allocation time.
2. Non-described descriptor type: Takes explicit RTTs for itself and its describee at allocation time.
3. Described non-descriptor type: Takes a descriptor at allocation time.
4. Described descriptor type: Takes a descriptor and an explicit RTT for its describee at allocation time.

rtt.canon would only make sense for types that do not have descriptors.

If we do add parametric polymorphism, it might be worth it to just skip explicit RTTs and use descriptors to reify type parameters in user space instead. This might require allowing descriptors on arrays (or even functions? I hope not), but we've left the door open for that eventuality.

[rossberg]

As @sjrd says, descriptors supersede RTTs as a concept, with an RTT roughly being an empty descriptor. For generics, we'll likely still need an equivalent to rtt.canon, which returns an empty descriptor, plus some additional composition primitives. But I'd hope we won't need a notion of RTT separate from descriptors.

[eqrion]

I agree it'd be ideal to not have separate RTT and descriptor notions.

One difference between descriptors and RTTs (IIRC) was the RTTs didn't have reference equality but descriptors do. I think that's okay as long as we are careful about any descriptor.canon instruction not allowing you to observe (e.g. through mutable fields) how the engine is caching/collecting the canonical descriptor.

Another difference was that we were not going to allow RTTs to flow into JS, but it sounds like we will allow descriptors to flow into JS (unless #42 is resolved differently). So if we have a descriptor.canon we'll have a wasm struct object that is not associated with any particular JS Realm because the canonical descriptor for a type must be at least global to a given JS Agent (for unshared structs). This is a little odd to me, but I don't think it's a spec issue. As far as I can tell, only WebIDL platform objects are required to have a relevant agent and Wasm GC objects are not that, so we're maybe okay here too.

The bigger thing I'm confused about is how to understand casting with descriptors being the RTT. In the GC MVP there is only implicit canonical RTTs. If the descriptors in this proposal are RTTs, then it seems like two objects with different descriptors should have observably different types for casts. But my understanding of this proposal is that is not the case; two objects can have the same type with different runtime descriptors and still cast to the same type.

(struct $a (descriptor $aDesc))

struct.new $aDesc
struct.new $a
ref.cast $a
;; this succeeds in the current proposal, even though the struct doesn't actually have the canonical descriptor/rtt for $a

I think this is a rehash of the rtt.canon/sub/fresh stuff, which I didn't understand well back then. So I'm probably missing something.

[jakobkummerow]

Regarding casting: recall that (before this proposal) canonical RTTs formed a tree (or rather: forest), where for types $sub <: $super the RTT for $sub would have a "parent"/"supertype" pointer to the RTT for $super. (As an optional implementation detail, it might even store its entire list of super-RTTs, for O(1) casts.)
The RTTs associated with Custom Descriptors are added to this tree, and they are always leaves. When type $a has a (descriptor $aDesc), then every struct.new $aDesc allocates an RTT whose "parent"/"supertype" pointer points at the canonical RTT for $a. (We expect most modules to have only one of these, but nothing prevents them from having many if they find that useful.)
That way, ref.cast $a works for all structs having various instances of $aDesc descriptors, by finding the canonical RTT for $a on their chain (or list) of super-RTTs. In fact, it will always be the immediate/"one-step" supertype; in V8 we found that it's a significant performance win to cache this pointer such that it's as fast as possible to access; when generating code we can always tell statically that this is the RTT to compare with.
On the other hand, ref.cast_desc makes the different custom descriptors observable. After desc1 = (struct.new $aDesc); desc2 = (struct.new $aDesc); obj1 = (struct.new $a desc1); obj2 = (struct.new $a desc2);, (ref.cast_desc obj1 desc1) will work but (ref.cast_desc obj2 desc1) will not. In terms of executed machine instruction, these casts do what ref.cast for a final type did before, i.e. either the object's actual RTT equals the cast's expected RTT, or the cast fails; there's never a reason to search the super-RTT chain. So even if only one $aDesc struct is created by a module, using ref.cast_desc will provide a (minor) performance benefit.

(Regarding descriptor.canon: I don't see the utility of such an instruction, but that's a separate discussion to have.)

[rossberg]

What @jakobkummerow said. Conceptually, I believe it's adequate to think of descriptors as wrapping bare RTTs, who as such haven't changed. Casts (regular ones anyway) only look at that RTT component, as before. Descriptors themselves are only relevant for (a) the new cast_desc and friends, (b) and to access the additional fields they carry.

(Note of course that the conceptual RTT of a type with descriptor involves knowledge about the structure of the descriptor, so differs from the RTT of a type without descriptor.)

As a consequence, it makes no difference which descriptor you cast against if they wrap the same RTT. So far, even with the descriptor extension, the type system still always inserts the respective canonical RTT into each descriptor.

A canonical descriptor in this setting would then be a canonical (i.e., empty) wrapper around a canonical RTT. This is not useful at the moment, but will be needed if we add generics, as a way to allocate or cast against a type involving a generic type parameter. In such a setting, it might make sense to view a struct without a descriptor as a struct with canonical descriptor.

(Now that I'm saying this, this suggests that we should not overload the existing struct.new* to optionally take descriptors, but have separate opcodes for the instructions with descriptors. The reason being that in the generic context, descriptor operands will have to be given even for types that have no / a.k.a. canonical descriptors. @tlively)

[tlively]

(Now that I'm saying this, this suggests that we should not overload the existing struct.new* to optionally take descriptors, but have separate opcodes for the instructions with descriptors. The reason being that in the generic context, descriptor operands will have to be given even for types that have no / a.k.a. canonical descriptors. @tlively)

Can we not have the typing rule take into account whether the environment is generic when determining whether a canonical descriptor is required, just like we take into account whether the type has a defined descriptor now?

Similarly, if we do want a new opcode, can we not just as well give the future generic allocation instruction the new opcode?

[rossberg]

I'm not sure what you mean by the "environment being generic". Do you mean being inside a generic function?

Even inside such a function, you can have monomorphic instantiations (of generic types) that do not depend on the type parameters. On the other hand, you could have monomorphic instantiations in other contexts but want to factor out the descriptor construction. In the other direction, you may have monomorphic instantiations but want to keep them implicit. I really think all combinations make sense, so having the presence of a descriptor operand being inferred based on some ad-hoc rules could be both confusing and limiting. Better to have the instructions be explicit about it.

[tlively]

Sorry, I replaced "generic context" with "generic environment," but I think you got the gist.

I see what you're saying about there being more valid combinations in the future, but the combination of struct.new without descriptor and an allocated type with an explicit descriptor will never be allowed. The current struct.new opcode could forever mean "take a descriptor iff the allocated type has an explicit descriptor" and we could add a new struct.new_rtt in the future that takes a descriptor for types that do not have an explicit descriptor.

Or we could add a new opcode now, as you suggest. I mostly want to make sure I have the shape of the bike shed correct before committing to a color.

[rossberg]

Yes, I think that's the shape of it.

The current struct.new opcode could forever mean "take a descriptor iff the allocated type has an explicit descriptor"

Technically yes, I suppose so. But it would be quite weird if we later add struct.new_desc anyway, but sometimes you can use plain struct.new to do the same thing. That would introduce both overloading and overlap at the same time, which doesn't sound great to me. Given that it's just a handful of opcodes, I'd go for clean.

[eqrion]

@rossberg

What @jakobkummerow said. Conceptually, I believe it's adequate to think of descriptors as wrapping bare RTTs, who as such haven't changed. Casts (regular ones anyway) only look at that RTT component, as before. Descriptors themselves are only relevant for (a) the new cast_desc and friends, (b) and to access the additional fields they carry

As a consequence, it makes no difference which descriptor you cast against if they wrap the same RTT. So far, even with the descriptor extension, the type system still always inserts the respective canonical RTT into each descriptor.

A canonical descriptor in this setting would then be a canonical (i.e., empty) wrapper around a canonical RTT. This is not useful at the moment, but will be needed if we add generics, as a way to allocate or cast against a type involving a generic type parameter. In such a setting, it might make sense to view a struct without a descriptor as a struct with canonical descriptor.

Okay, so a descriptor value is not the same as a rtt value (I know Jakob has a different model, but I think it's equivalent). This is a different model than I understood in my previous comment, it assumed we were literally exposing rtt values and renaming them to descriptor, not wrapping rtts with descriptor structs.

To try and catch up with the discussion more, are there issues with a model where descriptor == rtt?

The descriptor wraps rtt model means that every struct has to either point at a descriptor which points at the rtt (adding an indirection to get to the rtt), or have two header words to point at the descriptor and the rtt (which adds size overhead).

If descriptor == rtt, I believe struct.new_desc would be equivalent to the previously discussed rtt.fresh and we could have a struct.canon_desc which would be equivalent to rtt.canon.

[jakobkummerow]

As far as specified behavior is concerned, I think it's totally fair to view this proposal as exposing RTT values and renaming them to descriptor.

The key point is that custom descriptors and custom RTTs are in a 1:1 relationship. Whether one wraps the other, or they point at each other, or they're actually the same object is an implementation detail; as a mental model for how things behave these are all equivalent. My previous post intentionally didn't make any assumptions about this choice.

[rossberg]

There are multiple equivalent ways of viewing this. What's important is the following:

• Descriptor types and RTTs are in a 1:1 relationship: every descriptor type is tied to a specific describee type.
• As a consequence, descriptor values and RTTs are in an N:1 relationship, i.e., you can allocate arbitrarily many descriptors that describe the same static type, and that hence are interchangeable wrt (regular) casts.

[jakobkummerow]

Arbitrarily many custom descriptors per static type and corresponding ref.cast $that_static_type yes, but to make ref.cast_desc work, each descriptor value is 1:1 with a custom RTT value.

(When I use the term "RTT", I mean the actual on-heap value representing the type of an object at runtime, not the static type it represents. As long as only canonical RTTs exist, it's effectively the same anyway, but the term "canonical RTT" already implies that there could be additional non-canonical RTTs for the same static type. Each of these non-canonical RTTs (or, if you prefer: RTT values) is in a 1:1 relationship with a descriptor value.)

[rossberg]

Yeah, I think this comes down to terminology. The reason why I wouldn't call descriptor values "custom RTTs" is because they do not participate in the subtype hierarchy — you cannot downcast to them like to actual types. You can use them as a type proxy in the special cast_desc instruction, but technically that is quite a different thing, because it checks for value identity, not for the runtime type, nor does it involve any hierarchical testing.