It seems like a bit of a shame that wasm got support for exceptions but doesn't support effects which are a generalisation of the same concept.
https://wasmfx.dev/
I'm guessing this may be because exceptions exclusively require stack unwinding where as effects require full stack switching.
WASM will be ready when GNU Hurd succeeds in running the desktop linux of the year. Already 10 years since WASM ... HTML, CSS and JavaScript all had a huge influence. WAS simply has not done so yet.
Just checked and out of the 3 major non-JS GC languages, Go and .NET aren't planning to support WASM GC due to non-matching semantics. There's an implementation for Java - TeaVM, which is an AOT Java compiler, that does have production grade support, but isn't aiming for full Java compatibility (not sure what this means in practical terms).
Native interop with JS objects on the JS GC heap isn't supported as well.
> We reuse WebAssembly linear memories under the covers to implement and sandbox the GC heap. A reference to a GC object is not a native pointer, it is a 32-bit index into the GC heap’s underlying linear memory [..] As far as being fast goes, it lets us use virtual-memory guard pages to elide explicit bounds checks, just like we do for linear memories
Array loads and stores still need an explicit bounds check, don't they? And struct loads and stores don't have one anyhow. Are there other bounds checks that Wasmtime is removing? I can't figure out what they mean here.
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).
7 comments
[ 0.27 ms ] story [ 17.1 ms ] threadI'm guessing this may be because exceptions exclusively require stack unwinding where as effects require full stack switching.
Seems like there is still progress on that though which gives hope https://github.com/WebAssembly/stack-switching/blob/main/pro...
Native interop with JS objects on the JS GC heap isn't supported as well.
> We reuse WebAssembly linear memories under the covers to implement and sandbox the GC heap. A reference to a GC object is not a native pointer, it is a 32-bit index into the GC heap’s underlying linear memory [..] As far as being fast goes, it lets us use virtual-memory guard pages to elide explicit bounds checks, just like we do for linear memories
Array loads and stores still need an explicit bounds check, don't they? And struct loads and stores don't have one anyhow. Are there other bounds checks that Wasmtime is removing? I can't figure out what they mean here.
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).