[pcwalton]

The main benefit of using the Web Assembly GC is not improved performance within the language, but rather having a single GC that handles both native DOM objects and language objects. Having two GCs interoperate is a big pain, and it's very difficult to pull off without leaks or performance problems. This is especially true for DOM objects, which have no user-visible finalizers. (The closest thing is WeakMaps, but I don't believe these are enough to implement proper cross-language GC, because you can't query whether an potentially-dead object is actually dead.)

Web Assembly GC is not a performance optimization; it's necessary for correctness.

[sseth]

In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.

[pcwalton]

I mean, as of Oilpan the V8 garbage collector marks C++ objects by calling trace hooks, as I understand things. That isn't an option for Web Assembly, which doesn't have access to the V8 garbage collector in that way (except via the wasm GC proposal; in fact, that's fundamentally what the wasm GC proposal is).

[slimsag]

It's also worth mentioning WASM has no GC today.

[pjmlp]

My amd64 and ARM CPUs also don't have it.

On languages where the algorithm is an implementation detail, one can make use of reference counting with a cycle collector, which are just a few hundred lines.

Implementing one is pretty simple, making it perform well is another matter.

[hajile]

Unlike your real processor though, you can't directly access memory or ensure its absolute location. You can make an advanced GC that is slow or a basic one that is not.

[Sawamara]

Which is good. You can always implement GC inside it, but personally, for performance-intensive computing, I do not want GC inside WASM unless eplicitly enabled.