WebAssembly architecture for Go

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&#x27;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&#x27;t believe these are enough to implement proper cross-language GC, because you can&#x27;t query whether an potentially-dead object is actually dead.)<p>Web Assembly GC is not a performance optimization; it&#x27;s necessary for correctness.

What kind of WASM file sizes can we expect? I know some work has gone into shrinking Go executables, especially in 1.7, but will we be able to produce something like the 15KB Rust Hello World WASMs? Go has a fantastic stdlib but it hasn’t prioritized web optimized file sizes (yet).<p>I’m looking forward to the results of this work!

This is huge. Looking forward to see what sort of front-end toolkits will pop up for this new platform (Go for the client-side web).

I&#x27;m trying to learn more about this topic and I&#x27;m curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is because Go supports features, like garbage collection, that WebAssembly does not.<p>Is that right? Close? An oversimplification. Way off?

&gt; Go’s garbage collection is fully supported. WebAssembly is planning to add its own garbage collection, but it is hard to imagine that it would yield a better performance than Go’s own GC which is specifically tailored to Go’s needs<p>I don&#x27;t think it&#x27;s hard to imagine reading the GC proposal. The JS collector that might be reused could be off thread, something WASM can&#x27;t (yet) do.<p>&gt; Most file system operations are mapped to Node.js’ “fs” module. In the browser, file system operations are currently not available.<p>Please please abstract this. As a maintainer of a non-JS WASM backend, I&#x27;d love to use Go too.<p>&gt; Especially a “goto” operation in WebAssembly would be very helpful.<p>I didn&#x27;t look into the Go use case enough, but curious how much better this would be than the current labeled block and labeled break approach in WASM. WASM has fairly strict stack&#x2F;frame rules&#x2F;types, so arbitrary gotos wouldn&#x27;t work.

Strange that wasm doesn&#x27;t support go-to instructions. Didn&#x27;t they see the need for it coming? Most compiler backends need it, I suppose.

So when they say, it generates a big switch statement, do they generate this big switch statement for whole program or for individual functions which takes enough context to continue at at point where it yielded?

Afaik in theory stack machines are simpler to implement, but slower than register machines. In practise, the JVM is still pretty quick. Why was WASM designed as a stack machine?

Interestingly the issues sounds a lot like what a high performance Haskell implementation would run into. One additional note though on GC: highly tuned PL implementation requires completely control over object layout, pointer representation, and GC. (!)<p>No off-the-shelf GC will ever be perfect for all languages, thus I think WASM would be far better off doing whatever it could to facilitate runtimes implementing their <i>own</i>.<p>(!) Example from the lazy world: lazy closures when evaluated and updated often results in an indirection. We rely on GC to shortcut these. Sometimes we even have GC perform trivial constant-time evaluations when we know the result is smaller than the suspended evaluation.<p>Example from the Lisp world: cdr-coded cons cells can cut size in half, but no generic GC would be able to do this.

Why is WASM so weird? Why not just thinly model modern CPUs so it can be almost transliterated?

If you tried to look at the document and found that the entire internet has been screwing with the formatting, change &quot;Suggesting&quot; to &quot;Viewing&quot; in the top right. Seems like someone forgot to check permissions on the document.