Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GC and Exceptions in Wasmtime

bytecodealliance.org

Post reply on HN
Print view View original

21–30 of 44 posts

Re: GC and Exceptions in Wasmtime

#21

Post by pjmlp »

torginus wrote: post #13

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.

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.

Re: GC and Exceptions in Wasmtime

#22

Post by pjmlp »

ttd wrote: post #19
torginus wrote: post #12

Earlier quoted context omitted.

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 agno…

There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).

PNaCL was published with a standard and tooling, it was Mozzilla that refused to adopt it, and push asm.js instead.

Ironically, if it was today, Google could have pushed PNaCL without any problem.

Re: GC and Exceptions in Wasmtime

#23

Post by noelwelsh »

rdsubhas wrote: post #20
faldor20 wrote: post #2

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. Seems like there is still progress on that though which gives hope https://github.com/WebAssembly/stack-switching/blob/main/pro..…

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, runti…

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.

Re: GC and Exceptions in Wasmtime

#24

Post by ComputerGuru »

kittoes wrote: post #18
jaen wrote: post #14

Earlier quoted context omitted.

Links to discussions about why WASM GC in its current state is not suitable for .NET: https://github.com/WebAssembly/gc/issues/77 What should be improved: https://github.com/dotnet/runtime/issues/94420

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?

[dead]

Re: GC and Exceptions in Wasmtime

#25

Post by mckee_plus_plus »

hypendev wrote: post #15
torginus wrote: post #12

Earlier quoted context omitted.

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 agno…

> 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. Working on that! I'm building hypen.space which is platform agnostic language & SDK for building native crossplatform apps. It's a WASM engine at it's core, and while currently it doesn't have "package this app as wasm" capab…

Crediting LLMs with advancing wasm is a disservice to the best-in-industry bytecodealliance community & org.

Re: GC and Exceptions in Wasmtime

#26

Post by UncleEntity »

torginus wrote: post #13

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.

> 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.

Re: GC and Exceptions in Wasmtime

#27

Post by duped »

rdsubhas wrote: post #20
faldor20 wrote: post #2

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. Seems like there is still progress on that though which gives hope https://github.com/WebAssembly/stack-switching/blob/main/pro..…

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, runti…

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.

Re: GC and Exceptions in Wasmtime

#28

Post by torginus »

ttd wrote: post #19
torginus wrote: post #12

Earlier quoted context omitted.

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 agno…

There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).

NaCL was further along in every meaningful dimension (the ability to run native software at native speeds) after a year or two of development, than WASM is today after a decade (and I think this will be true a decade from now).

So the upside of WASM according to you, is that it got greenlit by the standards committee chaired by companies whose business model would've been hurt the most by a competent in-browser sandbox.

For example, the Epic-Apple Fortnite battle couldn't even have happened. Epic would've shipped it on NaCL and users would've been just as happy, and Apple (or Google) would've had no way of enforcing their sandox.

Whew, thankfully we've been saved from that terrible fate of getting to publish and enjoy software without gatekeepers and appstores.

At least I hope you have something to gain from your opinion, as the rest of us certainly lost out.

Re: GC and Exceptions in Wasmtime

#29

Post by inigyou »

torginus wrote: post #28
ttd wrote: post #19

Earlier quoted context omitted.

There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).

NaCL was further along in every meaningful dimension (the ability to run native software at native speeds) after a year or two of development, than WASM is today after a decade (and I think this will be true a decade from now). So the upside of WASM according to you, is that it got greenlit by the standards committee chaired by companies whose business model would've been hurt the most by a competent in-browser sandb…

Surely PNaCl is the one you need, because portability.
Post reply on HN