Unclear meaning of unshared `externref` and `anyref` in combination with JS API

[Liedtke]

My initial understanding of externref was "any unshared host value", especially as any.convert_extern would propagate that information to unshared anyref and all other abstract types have this notion of "not marked as shared == only unshared objects legal".

However, after starting with the implementation and considering the implications for the usage, I assume externref and anyref continue meaning "any host value independently of whether it is shared or unshared" because everything else would just be painful.

Considerations:

1. A funcref can be stored in an externref and anyref via the JS API as well, even though it is not a subtype of anyref.
2. externref is used by toolchains for "any host value", if it disallowed shared objects, that would probably create a decent amount of pain.
3. For any engine having an externref in a signature and calling it from JS should be as cheap as possible. If we disallowed shared types there, the engine would need to check sharedness and then react accordingly. In a world where shared js structs exist, many JS values could be shared that are convertible to unshared variants (including Strings and Numbers) and therefore such a typecheck would need to consider these cases.

With externref containing shared struct and shared array, these propagate to unshared anyref then, however that only means that downcasts from anyref will need to check for non-sharedness then but these casts anyways aren't that cheap, so it probably is an acceptable cost.

WDYT? Does this make sense? Should we clarify this in the overview?
(It could very well be that some think that "obviously externref keeps the meaning of 'anything', that's how it is already spec'ed" but to me this wasn't very clear when starting with the implementation. 😄)

[tlively]

I think this sounds right. Any value should be able to flow from JS into an externref, even if that value is a shared JS struct or even a shared Wasm struct that happened to flow out to JS. Converting such an externref to anyref should succeed because that conversion is infallible, but trying to cast that anyref to anything more specific, even eqref, should fail because the anyref might in principle be implemented as a wrapper around the underlying data.

[rossberg]

I don't think this makes sense. AFAICS, it would allow to convert an unshared reference to shared and vice versa, by round-tripping them through JS. And that in turn would break at least two central invariants of the design, namely:

1. Shared objects cannot point to unshared objects.
2. Shared and unshared references can have different representations.

To preserve (1), we clearly need to provide a top type of all unshared references. That is what anyref is, and by extension, externref has the same property. If we wanted a common super type of both any and shared any, then we'd need to introduce it. But I don't see how that could be done without breaking (2).

What we could do is introduce additional implicit conversions at the Wasm/JS boundary, e.g., converting shared to unshared, provided we add some suitable wrapper type to box it. But even then we could not allow, say, converting an array(ref shared any) to an array(ref any) etc.

[tlively]

@rossberg, this only allows converting shared to unshared via JS, not the other way around. So this preserves invariant (1). It also preserves invariant (2) by allowing an implicit wrapper object to be introduced on the host/Wasm boundary, just like we allow for conversions between externref and anyref.

[rossberg]

I was (mis?)reading @Liedtke's proposal to include the idea that downcasts are allowed from anyref to shared types. But that would require anyref to be a supertype of both hierarchies inside Wasm, with all the bad consequences.

But I missed your previous response where you were already saying that such casts ought to not be allowed. That would result in the boundary-only conversion approach, so if we all agree on that, then it seems okay. Although I suspect it may be rather surprising for some devs?

But it still comes with a cost. Implementations that use wrapper objects now have to check for them and unwrap them every single time an anyref/externref is passed or extracted from Wasm to JS. That is, this makes JS interop globally more expensive for some engines, even if no such object is even used. (I recall previous discussions about keeping externref passing zero-cost, at least in the Wasm→JS direction, so this clearly works against that ideal.)

[Liedtke]

I was (mis?)reading @Liedtke's proposal to include the idea that downcasts are allowed from anyref to shared types. But that would require anyref to be a supertype of both hierarchies inside Wasm, with all the bad consequences.

Yes, I meant that downcasts from anyref need to read the sharedness-property verifying that it is a non-shared type. I updated the comment to make this clearer. This issue does not propose any changes inside core wasm.

But I missed your previous response where you were already saying that such casts ought to not be allowed. That would result in the boundary-only conversion approach, so if we all agree on that, then it seems okay. Although I suspect it may be rather surprising for some devs?

I'm not sure what a "boundary-only conversion" means here. At least for V8 there isn't really any conversion with this approach.
However, if we did say "non-shared externref must only contain non-shared objects", we'd need to check if the object is shared. If it is, we'd need to check if it is a wasm object and in that case throw an exception. If it is a shared JS-object, we'd need to allow it, because the sharedness property of e.g. a string in V8 is mostly an implementation detail.

Either way, the approach I'm describing should reduce the costs for passing an object into a wasm function expecting an externref (making it almost free for V8).

But it still comes with a cost. Implementations that use wrapper objects now have to check for them and unwrap them every single time an anyref/externref is passed or extracted from Wasm to JS. That is, this makes JS interop globally more expensive for some engines, even if no such object is even used. (I recall previous discussions about keeping externref passing zero-cost, at least in the Wasm→JS direction, so this clearly works against that ideal.)

V8 doesn't use wrapper objects and wouldn't have to pay any price for this and passing externref from Wasm to JS is zero-cost for us (not the other way around, however there we'd have an even higher cost without this "relaxation" that I'm proposing here.)
Are we aware of any such engines? It'd help to understand the performance-trade-offs as the "disallow shared objects in externref" sounds like it would always come with a cost when going from JS to Wasm.

A question that still might need to be clarified: In the stricter use case, would toolchains be able to always know if an externref has to be marked as shared or not in use cases where the externref really is just "something coming from the host that is passed through"? If that is a wasm object, they'd suddenly run into issues if it is shared, while it would be fine if it was e.g. a shared JS struct (as I assume we can't disallow shared JS objects there and wouldn't want to do so.)

[rossberg]

I'm not sure what a "boundary-only conversion" means here.

What I meant by that is that shared objects can only be injected into externref at the JS/Wasm boundary, which amounts to an implicit conversion to a different type inside ToJS/WasmValue, at least semantically. We seem to be on the same page regarding that.

Are we aware of any such engines?

Well, there is no engine implementing shared refs yet, so I guess the answer is trivially no. But the design decision to not allow subtyping between shared and unshared references was partially motivated by supporting the possibility of such implementations. A Wasm engine might e.g. want to instrument shared refs with additional metadata, perhaps as fat pointers. Though I suppose that choice isn't very attractive for a JS-embedded Wasm engine anyway.

Either way, the approach I'm describing should reduce the costs for passing an object into a wasm function expecting an externref (making it almost free for V8).

Like above, only for engines that use a homogeneous representation inside Wasm (which will probably be the vast majority).

[jakobkummerow]

I think it's a given that any combined JS/Wasm engine will use a uniform representation on the JS side, because JS's lack of static types makes anything else untractable. So, presumably, any engine that chooses to use different representations on the Wasm side must box (or otherwise wrap or convert) shared Wasm objects when they flow out to JS. @Liedtke 's proposal means that when such a value flows back into Wasm typed as externref, its box can simply be passed through and does not need to be inspected. So I think that's the lowest-possible-overhead design even for engines that want to use different representations for shared objects on the Wasm side.

And when such an engine is asked to do an any.convert_extern on such a box, it can do whatever it does for random JS objects or for funcrefs. More generally, the fact that Wasm funcrefs are specifically designed to possibly have a different representation, yet can show up in an anyref-typed value via the externref entry point, totally serves as precedent here. However an engine supports that, it can use the same technique to support arbitrary representations for shared Wasm objects.