Evaluating the cost of a GC addition to wasm

[aardappel]

I generally feel the proposal is very elegant (in particular, being based on low level structs that are not assigned a particular semantics) and appears to be well positioned to be able to implement the semantics of quite a few languages.

I also feel there is potentially a large cost here that is not addressed clearly in the proposal, if it ends up not being adopted near-universally by languages.

The way I see it, it adds a 3rd option of what it means to be an object: An object can be represented as:

• A a linear memory object.
• A wasm-gc object.
• A JS object (when in the context of something like the current host-bindings proposal).

Now granted, the latter 2 of those 3 can be managed by the same GC implementation, but I still cannot write wasm code that is able to operate on more than one of those 3 representations (in a structurally equivalent way), so in that sense they are really separate kinds of objects. They may be able to refer to each other, but they largely live in their own worlds, operated upon by their own code. That to me is a significant cost.

A cost which is ok if we can get strong evidence that it will serve the needs of the majority of all managed languages out there. I think that is something that requires more evaluation. For example, if I am a language implementor, in a hypothetical future I may have these options to bring my language to the web:

1. Linear memory with no GC (C/C++/Rust/Swift/..)
2. Linear memory with my own GC, no help from wasm (stack in linear memory).
3. Linear memory with my own GC, using wasm stack root helper functions.
4. Wasm-GC (this proposal)
5. Wasm code with JS objects (using host-bindings as currently proposed).
6. JS code with JS objects.

Now it is important to note that not all of these are equally attractive to language implementors. Many languages have significant legacy runtime code built upon large amounts of complex C/C++ where (2) would actually be the route of least resistance, as it would require the least amount of changes to their runtime, followed by (3). (4) may require significant rewriting of their runtime.

Languages may also be very specific in what kind of GC or memory management / layout features they rely on for their typical workloads to be fast, which if not supported by (4) will push them in the direction of (2) or (3).

(2) is also the de-facto standard for most languages until this proposal turns into mature implementations in all browsers, so it has strong inertia to overcome.

Dynamic languages in particular do not appear to be well served by the current version of this proposal, as the diversity of ways they represent their values likely does not map well onto the strongly typed structs. The section on Variants may improve this, but even that can't cover all possible representations (tagged pointers vs nan-boxing vs external tags vs scalars as objects vs..).

(4) has huge advantages in terms of smaller binaries and more robust interop, but that doesn't mean much if it goes largely unused.

I guess something I'd like to ask language implementors, is given the current GC proposal, which of the above would you choose to use as your implementation path? If (4) doesn't garner a large majority, we'd either have to re-think the design of it, and/or instead poor more effort into alternatives like (3).

[lukewagner]

FWIW, the GC-related features of Host Bindings should be fully complementary to what's in the wasm-GC proposal so there shouldn't be an either/or situation between the two. In particular:

• anyref could point at either host or wasm-GC types and the dynamic casts could go to any ref type
• a wasm-GC object reference could flow in/out from JS and, from a JS pov, would look like a typed object (co-designing that proposal with wasm-GC)
• a wasm-GC object could have any of the Host Bindings types (anyref, type imports, etc) as field types of the managed struct/array types.

Your other points make sense and are why the group agreed we need significant validation of the GC feature via multiple source languages.

[aardappel]

Wasn't aware of the JS typed objects, that looks like a welcome addition :)

[tlively]

This proposal is now in phase 3 and there are multiple implementations showing significant benefits, so closing this.