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

31–40 of 44 posts

Re: GC and Exceptions in Wasmtime

#31

Post by torginus »

inigyou wrote: post #29
torginus wrote: post #28

Earlier quoted context omitted.

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.

Portability isn't worth as much as it was advertised. There are a grand total of 2 relevant CPU architectures for consumers, ARM64 and x86_64. Shipping 2 binaries is just running the compiler twice.

On the client side, there's just a verifier, and then the runtime basically consists of branching to the first instruction and having at it. Near-native performance and instant startup, you can't do better than that.

PNaCL was proto-WebAssembly and suffering from the same issues. They actually shipped LLVM bytecode, and you had to compile the executable locally with the whole toolchain, leading to quite bad startup performance and a lot of baggage.

Turns out there's no such thing as portable VM assembly. You still have to ship a full compiler (well, JIT) and compile the WASM IR.

Browser vendors have spent uncountable amount of engineering resources on making yet another compiler (actually multiple, since afaik Chrome uses a tiered JIT for WASM), that's neither as good as the big boys, and neither as fast as just running the dang binary.

Re: GC and Exceptions in Wasmtime

#32

Post by inigyou »

torginus wrote: post #31
inigyou wrote: post #29

Earlier quoted context omitted.

Surely PNaCl is the one you need, because portability.

Portability isn't worth as much as it was advertised. There are a grand total of 2 relevant CPU architectures for consumers, ARM64 and x86_64. Shipping 2 binaries is just running the compiler twice. On the client side, there's just a verifier, and then the runtime basically consists of branching to the first instruction and having at it. Near-native performance and instant startup, you can't do better than that. PNaC…

If you make the web dependent on a CPU architecture, you're giving up on a fundamental design principle and also letting one company control it.

Re: GC and Exceptions in Wasmtime

#33

Post by davexunit »

UncleEntity wrote: post #26
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.

I'm not sure what they mean by "native" here but (ref extern) is for host references, JS or otherwise. The i31 type is for "immediate" values, things that can fit in 31 bits and thus don't need to be allocated on the heap.

Re: GC and Exceptions in Wasmtime

#34

Post by torginus »

inigyou wrote: post #32
torginus wrote: post #31

Earlier quoted context omitted.

Portability isn't worth as much as it was advertised. There are a grand total of 2 relevant CPU architectures for consumers, ARM64 and x86_64. Shipping 2 binaries is just running the compiler twice. On the client side, there's just a verifier, and then the runtime basically consists of branching to the first instruction and having at it. Near-native performance and instant startup, you can't do better than that. PNaC…

If you make the web dependent on a CPU architecture, you're giving up on a fundamental design principle and also letting one company control it.

Linux distros are shipped as binaries yet you can still build them from source, and are certainly not controlled by one company, I don't see why that would be the case here.

Re: GC and Exceptions in Wasmtime

#35

Post by azakai »

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.

Re: GC and Exceptions in Wasmtime

#36

Post by inigyou »

torginus wrote: post #34
inigyou wrote: post #32

Earlier quoted context omitted.

If you make the web dependent on a CPU architecture, you're giving up on a fundamental design principle and also letting one company control it.

Linux distros are shipped as binaries yet you can still build them from source, and are certainly not controlled by one company, I don't see why that would be the case here.

Would you require every website to come with architecture-independent source code? What happens if it doesn't match the compiled binary? Or would the browser compile it every time?

Re: GC and Exceptions in Wasmtime

#37

Post by torginus »

inigyou wrote: post #36
torginus wrote: post #34

Earlier quoted context omitted.

Linux distros are shipped as binaries yet you can still build them from source, and are certainly not controlled by one company, I don't see why that would be the case here.

Would you require every website to come with architecture-independent source code? What happens if it doesn't match the compiled binary? Or would the browser compile it every time?

The original premise of the argument was about WASM bytecode vs native assembly - bytecode is no more open or closer to the source code than x86 asm. Your questions are completely orthogonal to the argument, so please bring up relevant points.

Re: GC and Exceptions in Wasmtime

#38

Post by ttd »

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…

It seems like you know quite a bit of the history here. Were you involved in some way? If so, I'm curious to know why you think NaCL did not achieve broad adoption? And what's stopping the world from catching up to your line of thinking and adopting a NaCL successor?

Re: GC and Exceptions in Wasmtime

#39

Post by tankenmate »

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…

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

Re: GC and Exceptions in Wasmtime

#40

Post by inigyou »

torginus wrote: post #37
inigyou wrote: post #36

Earlier quoted context omitted.

Would you require every website to come with architecture-independent source code? What happens if it doesn't match the compiled binary? Or would the browser compile it every time?

The original premise of the argument was about WASM bytecode vs native assembly - bytecode is no more open or closer to the source code than x86 asm. Your questions are completely orthogonal to the argument, so please bring up relevant points.

What's your design proposal?
Post reply on HN