GC and Exceptions in Wasmtime

> Were you involved in some way?

Only as a developer using the technology, as part of a failed commercial venture.

> If so, I'm curious to know why you think NaCL did not achieve broad adoption?

NaCl had 2 limitations compared to WASM, the first one was a design philosophy difference:

Unlike WASM, it was designed to maximize compatibility with native code, so it had no ability to coexist in the same process with JS/DOM like WASM does. You had to put the code in an iframe, and talk to it via postMessage. WASM promised to be a better design, but a decade on, we can see it's missing most of those promised features, or said features are half-baked, and it has turned into one of the biggest NIH quests in modern computer science.

The second issue was that it worked through Chrome's plugin API, which has since been deprecated. You could sit down and standardize an API that's not chrome specific. The biggest piece of API surface the browser has is WebGL, and they essentially exposed OpenGL ES to the browser, which is identical to what PPAPI did.

Some APIs were much better, like audio just gave you a buffer to write into, compared to WebAudio, which aims to implement the whole processing pipeline via stringing together JS objects, and everybody seems to hate it.

> And what's stopping the world from catching up to your line of thinking and adopting a NaCL successor?

Theoretically nothing, but you'd have to fork Chrome, do the changes yourself, develop a spec and tooling and THEN ask browser vendors to standardize on your changes. If there was some soul who would undertake this task (maybe feasible with AI for a non-huge team?), combined with a strong awareness campaign to get committees to consider adoption. So it's a tall order in reality.

When WASM people say "linear memory", they mean the whole address space that the guest program uses resides contiguously in a relatively small chunk of the 64-bit address space. In typical native programs, each heap allocation gets an essentially-random 64-bit address, and the can spread over a much larger chunk of the address space, with no guarantees on where a pointer can point.

With the 4 GiB linear memory trick, WASM's 32-bit pointers can't point outside of the range of virtual memory they allocate for the guest, so from the point of view of host, the guest is unable to have an out-of-bounds reference.

The program running inside the WASM virtual machine can still corrupt its internal state, but that doesn't matter for the WASM engine's security model: the program can be assumed to be directly hostile.

They're saying they used a similar design for WasmGC -- concretely, they're 32-bit indexes to a second span of virtual memory, but opaque and with more rules about how they can be used. They're unforgeable by design, but even if you find a bug in the WASM engine, it's still only a 32-bit index.

The quote extends that 4 GiB thinking to the GC design: Even with a bug in the WASM engine, every index is "safe" to access at any time, eliding bounds checks (the explosion is instant, predictable, and contained).