5 ms·

GC and Exceptions in Wasmtime

155 points by phickey 2mo ago

faldor20 2mo ago
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/ https://wasmfx.dev/ I'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/proposals/stack-switching/Explainer.md https://github.com/WebAssembly/stack-switching/blob/main/pro...
- shevy-java 2mo ago
  > Seems like there is still progress Oh I already know that about WASM now. All is in progress ... perpetual progress. I'll look again in the next decade.
  - boomskats 2mo ago
    I would suggest you look at it a little more often than that - to improve the quality of discussion here, if for nothing else.
- boomskats 2mo ago
  Thanks for that link! There goes my Saturday morning. After a bunch of middle clicking I landed here [0]. So if I understand correctly, the current stack switching proposal depended on exception handling to be implemented first for resume.throw, so that bit was blocked until now. But it's also further along than you might assume [1], i.e. you can already invoke Wasmtime with `-W stack-switching` and hit the boundaries where the experimental implementation breaks. Sadly though, like many ambitious Wasm things that don't have revenue directly attached to them, it now seems partly a case of finding someone willing to sponsor or finish the remaining work [2]. I also found the list of open stack-switching issues[3] useful. (also, minor nit - Wasm != Wasmtime) [0]: https://github.com/bytecodealliance/wasmtime/issues/10248 https://github.com/bytecodealliance/wasmtime/issues/10248 [1]: https://github.com/bytecodealliance/wasmtime/issues/12941 https://github.com/bytecodealliance/wasmtime/issues/12941 [2]: https://github.com/bytecodealliance/wasmtime/issues/12941#issuecomment-4178105302 https://github.com/bytecodealliance/wasmtime/issues/12941#is... [3]: https://github.com/bytecodealliance/wasmtime/issues?q=state%3Aopen%20label%3A%22wasm-proposal%3Astack-switching%22 https://github.com/bytecodealliance/wasmtime/issues?q=state%...
- rdsubhas 2mo ago
  Looking at the link, it was quite an eye-opener moment (atleast for me) to see so many language-differentiating features - exceptions, async/await, continuations, generators - can all just be abstracted into one concept called "typed continuations". I'm still wrapping my head around this. On one hand, I'd assume a "focused" feature, like exceptions, would always be easier to fine-tune and optimize the language, runtime and workflow – rather than generalizing it. But at the same time, the prospect of saying all those are just special forms of a stacked "yield" (just for my mental model) is quite tantalizing.
  - noelwelsh 2mo ago
    You might enjoy digging into the world of effect handlers: it's a very neat model for expressing these features and boils down to continuations in the implementation.
  - duped 2mo ago
    PL theory seems to be in an infinite loop between arbitrary control flow like call/cc and then realizing it's hard to reason about and restricting it. I do wish we could land on a standard model for implementing non local control flow. Like growable stacks.
  - tankenmate 2mo ago
    I was never a huge fan of exceptions and their "come from" / "spooky behaviour at a distance" semantics, and now I see a group of other language features I never thought highly of all belong to a group of implementation / semantically similar behaviour. "He has all the virtues I dislike and none of the vices I admire." -- Churchill
ngrilly 2mo ago
Does it support interior pointers?
- ncruces 2mo ago
  No.
shevy-java 2mo ago
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.
- boomskats 2mo ago
  Ready for what? WASM is already running in production at a whole bunch of financial services orgs and government infra. The thing is, it's not running anywhere near HTML, CSS or JavaScript. It's running serverside, mostly on Wasmtime - which, as it happens, is what this post is all about.
  - troupo 2mo ago
    why.... why would financial services orgs and government infra run anything on wasm serverside?
    - boomskats 2mo ago
      It's lightweight, capability-secured, services start up way faster, smaller overhead than VMs, better isolation than containers, faster replication, etc. The original Wasmtime 1.0 blog post explains it all really well: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...
  - alex_suzuki 2mo ago
    > it's not running anywhere near HTML, CSS or JavaScript There’s plenty of usage in the browser environment as well, plenty of client-side SDKs for things like e.g. video editing, barcode scanning, etc. use it.
- torginus 2mo ago
  Yeah, WASM has been a disappointment, and I guess there's a good reason for that. If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead. Native Client, which ran native x86 (but statically verified) code in the browser, basically fit all the criteria, except it wasn't platform agnostic. I'm not married to their approach, but I refuse to believe that this can't be done in a safe and peformant manner. I guess WASM turned out to be a sandbagging rather than sandboxing technology. But I eagearly await the arrival of concern trolls who can explain why WASM is slower than JS, and why native threading support is impossible to do securely without imposing limitations, that made sites like itch turn it off, so it might as well not exist.
torginus 2mo ago
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.
- jaen 2mo ago
  Links to discussions about why WASM GC in its current state is not suitable for .NET: https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77 What should be improved: https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420
  - kittoes 2mo ago
    I'm not familiar with the current spec and those posts are from 6/3 years ago, respectively. Do you happen to know if anything has changed since?
    - ComputerGuru 2mo ago
      [dead]
- pjmlp 2mo ago
  This is another good example that not all GCs are born alike, even though its is common to place them on the same basket. WASM GC is a MVP, only usable by languages whose GC requirements overlap with JavaScript's GC. Java has it easier than either Go or C#, because the Java and JVM specification is actually silent on how GC should be implemented, hence why there are so many implementations to chose from across JVMs. Outside the browser there is hardly any value, just use JVM or CLR directly.
- UncleEntity 2mo ago
  > Native interop with JS objects on the JS GC heap isn't supported as well. Isn't that what the i31 type is for, that extra bit is a tag for...something, native GC'd object perhaps? Not so clear on that myself as Java's object model (minus synchronized) slots in perfectly so my Java 1.0 -> wasm compiler doesn't need it but that's my limited understanding of what it's for.
rbbydotdev 2mo ago
I'm personally excited for a better thread story (not web-workers) and JIT
azakai 2mo ago
Wait, what does this mean? > 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.
- yencabulator 2mo ago
  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).

155 points by phickey 2mo ago

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/ https://wasmfx.dev/ I'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/proposals/stack-switching/Explainer.md https://github.com/WebAssembly/stack-switching/blob/main/pro...

shevy-java 2mo ago
> Seems like there is still progress Oh I already know that about WASM now. All is in progress ... perpetual progress. I'll look again in the next decade.
- boomskats 2mo ago
  I would suggest you look at it a little more often than that - to improve the quality of discussion here, if for nothing else.
boomskats 2mo ago
Thanks for that link! There goes my Saturday morning. After a bunch of middle clicking I landed here [0]. So if I understand correctly, the current stack switching proposal depended on exception handling to be implemented first for resume.throw, so that bit was blocked until now. But it's also further along than you might assume [1], i.e. you can already invoke Wasmtime with `-W stack-switching` and hit the boundaries where the experimental implementation breaks. Sadly though, like many ambitious Wasm things that don't have revenue directly attached to them, it now seems partly a case of finding someone willing to sponsor or finish the remaining work [2]. I also found the list of open stack-switching issues[3] useful. (also, minor nit - Wasm != Wasmtime) [0]: https://github.com/bytecodealliance/wasmtime/issues/10248 https://github.com/bytecodealliance/wasmtime/issues/10248 [1]: https://github.com/bytecodealliance/wasmtime/issues/12941 https://github.com/bytecodealliance/wasmtime/issues/12941 [2]: https://github.com/bytecodealliance/wasmtime/issues/12941#issuecomment-4178105302 https://github.com/bytecodealliance/wasmtime/issues/12941#is... [3]: https://github.com/bytecodealliance/wasmtime/issues?q=state%3Aopen%20label%3A%22wasm-proposal%3Astack-switching%22 https://github.com/bytecodealliance/wasmtime/issues?q=state%...
rdsubhas 2mo ago
Looking at the link, it was quite an eye-opener moment (atleast for me) to see so many language-differentiating features - exceptions, async/await, continuations, generators - can all just be abstracted into one concept called "typed continuations". I'm still wrapping my head around this. On one hand, I'd assume a "focused" feature, like exceptions, would always be easier to fine-tune and optimize the language, runtime and workflow – rather than generalizing it. But at the same time, the prospect of saying all those are just special forms of a stacked "yield" (just for my mental model) is quite tantalizing.
- noelwelsh 2mo ago
  You might enjoy digging into the world of effect handlers: it's a very neat model for expressing these features and boils down to continuations in the implementation.
- duped 2mo ago
  PL theory seems to be in an infinite loop between arbitrary control flow like call/cc and then realizing it's hard to reason about and restricting it. I do wish we could land on a standard model for implementing non local control flow. Like growable stacks.
- tankenmate 2mo ago
  I was never a huge fan of exceptions and their "come from" / "spooky behaviour at a distance" semantics, and now I see a group of other language features I never thought highly of all belong to a group of implementation / semantically similar behaviour. "He has all the virtues I dislike and none of the vices I admire." -- Churchill

ngrilly 2mo ago

Does it support interior pointers?

ncruces 2mo ago
No.

shevy-java 2mo ago

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.

boomskats 2mo ago
Ready for what? WASM is already running in production at a whole bunch of financial services orgs and government infra. The thing is, it's not running anywhere near HTML, CSS or JavaScript. It's running serverside, mostly on Wasmtime - which, as it happens, is what this post is all about.
- troupo 2mo ago
  why.... why would financial services orgs and government infra run anything on wasm serverside?
  - boomskats 2mo ago
    It's lightweight, capability-secured, services start up way faster, smaller overhead than VMs, better isolation than containers, faster replication, etc. The original Wasmtime 1.0 blog post explains it all really well: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...
- alex_suzuki 2mo ago
  > it's not running anywhere near HTML, CSS or JavaScript There’s plenty of usage in the browser environment as well, plenty of client-side SDKs for things like e.g. video editing, barcode scanning, etc. use it.
torginus 2mo ago
Yeah, WASM has been a disappointment, and I guess there's a good reason for that. If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead. Native Client, which ran native x86 (but statically verified) code in the browser, basically fit all the criteria, except it wasn't platform agnostic. I'm not married to their approach, but I refuse to believe that this can't be done in a safe and peformant manner. I guess WASM turned out to be a sandbagging rather than sandboxing technology. But I eagearly await the arrival of concern trolls who can explain why WASM is slower than JS, and why native threading support is impossible to do securely without imposing limitations, that made sites like itch turn it off, so it might as well not exist.

torginus 2mo ago

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.

jaen 2mo ago
Links to discussions about why WASM GC in its current state is not suitable for .NET: https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77 What should be improved: https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420
- kittoes 2mo ago
  I'm not familiar with the current spec and those posts are from 6/3 years ago, respectively. Do you happen to know if anything has changed since?
  - ComputerGuru 2mo ago
    [dead]
pjmlp 2mo ago
This is another good example that not all GCs are born alike, even though its is common to place them on the same basket. WASM GC is a MVP, only usable by languages whose GC requirements overlap with JavaScript's GC. Java has it easier than either Go or C#, because the Java and JVM specification is actually silent on how GC should be implemented, hence why there are so many implementations to chose from across JVMs. Outside the browser there is hardly any value, just use JVM or CLR directly.
UncleEntity 2mo ago
> Native interop with JS objects on the JS GC heap isn't supported as well. Isn't that what the i31 type is for, that extra bit is a tag for...something, native GC'd object perhaps? Not so clear on that myself as Java's object model (minus synchronized) slots in perfectly so my Java 1.0 -> wasm compiler doesn't need it but that's my limited understanding of what it's for.

rbbydotdev 2mo ago

I'm personally excited for a better thread story (not web-workers) and JIT

azakai 2mo ago

Wait, what does this mean? > 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.

yencabulator 2mo ago
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).