Remove anyref

[RossTate]

The Overview describes the purpose of anyref to be to support the sort of uniform representation typically used by polymorphically or dynamically typed GC languages. However, we have seen that these languages are not using anyref for their uniform representation. In short, no one has first-class values corresponding to function references, and as such everyone is using eqref for its uniform representation at the least. So there appears to be no particularly good reason to have anyref.

On the other hand, there are good reasons to not have anyref:

1. The subtyping externref <: anyref forces JS values to be coerced to and from externref. For example, V8 uses SMIs, which conflict with i31ref, and so the coercion to externref requires boxing SMIs and requires unboxing i31ref-values-as-JS-values, and the reverse coercion has to do the opposite. Removing anyref would enable us to eliminate this coercion.
2. When we were discussing long-term JS API considerations, one thing that came up was being able to access fields of typed JS objects directly from within WebAssembly. One way we could do this would be to import externref field accessors/members. However, the coercions required by the externref <: anyref subtyping prevent this, since those fields would store JS values in their "native" JS representation rather than their wasm representation. Removing anyref would enable us to have direct field accessors/members into typed JS objects.
3. The instance-object model we're currently using means that many translations of GC languages into WebAssembly have to use closures where they would normally have just code pointers. Indeed, we're seeing substantial overheads in specifically the translations using function references, and my experiments (outside of wasm) suggest that using closures in place of code pointers indeed causes substantial overhead due to the extra chained load on a key language operation. One way we could reduce this overhead is to use a wide representation for function references, so that the code pointer sits alongside its environment (typically the instance-object) in memory, thereby reducing a chained load to a parallel load (and also likely improving locality). However, the funcref <: anyref subtyping forces function references to be represented the same as data references, preventing this optimization. Removing anyref could help us overcome the performance issues the current proposal is facing.

So, because anyref is not needed for its intended purpose, and because its presence obstructs various features and optimizations, I propose we remove it.

[tlively]

Overall I don't know of any good reasons not to do this. @rossberg, even Wob and WAML don't depend on func <: any, do they?

@jakobkummerow, would we be interested in experimenting with wide function pointers for function references?

The instance-object model we're currently using means that many translations of GC languages into WebAssembly have to use closures where they would normally have just code pointers.

Perhaps this would be better split off into a separate issue or discussion, but I would be interested in specific examples of this.

[RossTate]

The instance-object model we're currently using means that many translations of GC languages into WebAssembly have to use closures where they would normally have just code pointers.

Perhaps this would be better split off into a separate issue or discussion, but I would be interested in specific examples of this.

OO languages use a v-table for each class, with a field for every method of the given class. In a typical OO runtime, those fields are code pointers. In WebAssembly, those fields are typed function references. Because those typed function references can be implemented by functions from any module instance, and because different instances of the same module share code pointers in the instance-object model, they (with anyref) have to be represented at the least as a pointer to a closure containing the code pointer and the particular module instance the reference comes from.

The same issue arises with closures in functional languages. Even for the ones that use an instance-object model, normally the closure object contains the code pointer as a field. If the closure happens to depend on the module instance, then the pointer to the module-instance object is included directly in the closure object. But with anyref and WebAssembly's instance-object model, the (application-defined) closure must instead use a pointer to a (engine-defined) closure containing the code pointer and its module instance.

Thus anyref and the instance-object model add an extra (typically chained) load (with reduced locality) to the key operations of method dispatch and closure application. Furthermore, it's an extra load that's behind the scenes, so the generator cannot do anything to eliminate the extra operation.

[jakobkummerow]

I weakly support dropping anyref. "There's no use case" is all the reasoning I need. It's also consistent with our earlier decisions to drop things that don't have use cases (yet).

would we be interested in experimenting with wide function pointers for function references?

I doubt it. V8 heavily relies on a uniform representation internally. Exceptions are conceivable, e.g. we could special-case "array of funcref" or something. For playing such games, I don't think we care much whether funcref <: anyref or not.

[RossTate]

V8 heavily relies on a uniform representation internally.

Can you clarify this? Why is it problematic for a wasm field funcref to be internally represented as two fields? Presumably you already have support for wide fields like field f64.

[jakobkummerow]

Sure, struct fields could potentially also be special-cased.

[timjs]

We didn't discuss Waml yet during the meetings, but how is for example the identity function compiled to Wasm? For sure it needs to work on data as well as on functions, so I'd say you need anyref to support parametric polymorphism.

[RossTate]

Although we have not yet discussed Waml, @rossberg did confirm in the last meeting that Waml does not use anyref for its uniform representation. In answer to your question, parametric polymorphism only needs uniform representation for all values of the language at hand. All Waml's values are either datarefs or i31refs, and so eqref is sufficient for its uniform representation. (Furthermore, OCaml would likely want at least eqref for its uniform representation in order to provide a simple and efficient implementation of its polymorphic physical equality operator ==.)

[rossberg]

Anyref is the common supertype of externref and Wasm-internal reference types(*). As such, it is the only type that can abstract from whether some abstract reference (or type) external to a module is implemented in Wasm or by the host. Since making such abstraction possible is a stated goal of Wasm, anyref is needed.

As I already said in reply to this question during my talk, anyref would hence likely show up in something like Waml if you tried to support some form of FFI, which it currently doesn't have.

(*) Requiring that every Wasm reference can be externalised in every possible host environment would be quite a significant requirement, so assuming anyref = externref as opposed to just anyref >= externref is probably not a good idea in general, even if it could work in JS engines specifically.

[RossTate]

Polymorphic typed functional languages compiling to wasm need a way to downcast from their uniform representation to the lowerings of their concrete types. But there is no way to downcast from anyref to externref, so Waml's FFI wouldn't be able to use externref for its representation of values corresponding to foreign references.

But what Waml's FFI could do is use ref (struct externref). Yeah, this requires boxing foreign references, but Waml also needs to box float64; that's just an inherent cost of its implementation strategy. In fact, OCaml would likely want to do this anyways, as it keeps the implementation of both physical and structural equality simpler and more efficient.

Object-oriented languages would also do the same. They want to be able to assume all (object) values have methods like toString and equals, and so their uniform representation usually ensures even a v-table. Using externref in the uniform representation would mean having to branch on calls to these common methods. Instead, they'll box the externref in some class for foreign values, whose v-table will be filled with implementations essentially calling the appropriate imported function on the wrapped externref.

[rossberg]

You are missing the point of what I just said, namely achieving independence from how an outside reference is actually implemented (host vs Wasm). Whether that is then boxed up or not inside the language runtime is a different question. (FWIW, no downcast is needed for polymorphic functions if the lowered instantiation type is anyref.)

[RossTate]

Then please clarify your point, as what you're saying seems contradictory to me.

You are missing the point of what I just said, namely achieving independence from how an outside reference is actually implemented (host vs Wasm).

One of the problems with the externref <: anyref subtyping is that it does not allow for such independence. It forces external references to be coerced from their native form to one that is compatible with WebAssembly references.

FWIW, no downcast is needed for polymorphic functions if the lowered instantiation type is anyref.

This would require the FFI to use anyref, which seems problematic (especially if you don't want the foreign system to have to represent arbitrary wasm references, which I thought you were suggesting above).

This also forces anyref to be the uniform representation. That makes downcasts from the uniform representation to (other) types more costly, both in terms of instruction size and in terms of run time performance. This does not seem to be a worthwhile tradeoff compared to the boxing approach.

Could you articulate why the boxing approach is unsatisfactory to you?

[rossberg]

I thought we had long settled this. Yes, you need a uniform representation for anyref and externref. And no, there is no way around it given the goal of implementation independence for imported modules. Not unless you completely change the Wasm compilation model. Even without anyref you'd have the exact same problem with abstract type imports.

Again, boxing is a separate question and does neither help nor hinder in that regard.

[RossTate]

I thought we had long settled this.

I do not know how you came under this impression. #143 is precisely on this topic, over a year old, and unresolved.

Even without anyref you'd have the exact same problem with abstract type imports.

There are also unresolved issues regarding the type imports proposal related to the expectation that all imports should be subtypes of anyref: WebAssembly/proposal-type-imports#6 (comment) and WebAssembly/proposal-type-imports#10.

Even if we want to stick with the model that imported types should not need to be known before compilation, you can achieve this by allowing unbound imported types to be instantiated with any reference type or with externref—so long as the engine has the same size for the two, this is still compatible with that compilation model.

[rossberg]

Even if we want to stick with the model that imported types should not need to be known before compilation, you can achieve this by allowing unbound imported types to be instantiated with any reference type or with externref—so long as the engine has the same size for the two, this is still compatible with that compilation model.

I don't see how that can work efficiently. One might be garbage-collected, the other might not? Both might use different tagging schemes? In general, the compiler already needs to know which is which. The GC will need to know it. Size is not enough. If they don't statically know how to interpret the representation they'd have to compile in multiple alternative paths everywhere, and dynamically select based on some per-type mode flag, which is no better than a uniform representation.

Can you provide any concrete example of a real life runtime that would not simply implement a uniform representation in such a scenario?