WebAssembly Troubles Part 4: Microwasm

troubles.md

134 points·justinclift··8 comments

I really like how it has only CFG control flows which would have made life much easier for people generating WASM and for people writing AOT compilers. Too bad WASM had to cater for the requirements of V8.

Perfect example of why the Chrome/V8 monoculture is a bad idea.

Indeed, if V8 has a deficient design, well, it's no reason to stop the world. Adults can't be cry-babies.

V8 was a major influence on the limits of wasm control flow from the beginning, it's a real bummer. But you have to make the most of what you have, I guess. I can't imagine a way for us to have gotten those V8 limitations fixed

I guess, but what about PNaCl? Was V8 blocking that too?

No, PNaCl didn't use V8. It used an elaborate set of llvm changes that had problems and couldn't be upstreamed.

A big part of wasm's pitch is that it reuses JS engine infrastructure (less new engineering, less attack surface), but that means it's intrinsically more limited. No mmap, etc.

The V8 people didn't want to support heap growth at all (it made some part of the JIT harder) but eventually were convinced. Imagine having to pre-allocate 512mb or more of heap for every little app you deploy. (asm.js already had this limitation for the same reason)

Note the previous 3 parts are also make very interesting points.

Haven't all of these problems already been solved if you use GO as your compiler?

Reply on news.ycombinator.com