Comment by azakai
13 days ago
> [wasm] is executed in a stack-based virtual machine rather than as a native library code.
Wasm's binary format is indeed a stack-based virtual machine, but that is not how it is executed. Optimizing VMs convert it to SSA form, basic blocks, and finally machine code, much the same as clang or gcc compile native library code.
It is true that wasm has some overhead, but that is due to portability and sandboxing, not the stack-based binary format.
> On top of the above, memory available to WASM is limited by the browser (in case of Chrome, the limit is currently set at 4GB per tab).
wasm64 solves this, by allowing 64-bit pointers and a lot more than 4GB of memory.
The feature is already supported in Chrome and Firefox, but not everywhere else yet.
The more I read about WASM the more it sounds like the JVM
I'm still not clear what at its core it's done differently (in a way that couldn't be bolted on to a subset of the JVM)
The JVM is designed around Java. That's really the main difference, and it brings some downsides for the goals of wasm, which include running native code - think C++ or Rust. The JVM is great at Java, which relies on runtime inlining etc., but not at C++, which assumes ahead-of-time inlining and other optimizations.
I don't understand how the virtual machine would preclude you from in-lining ahead of time...? That's done when you're compiling.
What is WASM doing to facilitate recompiling native code that isn't practical to do on the JVM