3 ms·

I think this too, when I read about WASM. It seems to be tackling the same problem that java was created to solve. Namely, a platform independent VM for runni

I think this too, when I read about WASM. It seems to be tackling the same problem that java was created to solve. Namely, a platform independent VM for running applications (applets) in the browser. I, for one, would appreciate an explanation of how WASM differs from the original JVM, if someone has a moment.

FullyFunctional 7y ago
Controversial opinion alert! Java Bytecode is an awful design. It's obvious if you study it that it was never designed as a compiler intermediate. Instead it was a fairly trivial byte code machine for which JITting was an afterthought. The bytecode "verification" is such a difficult problem that it lead to multiple articles and originally had a sequence of security holes. The JVM is also very far from language independent. Good luck making an efficient mapping for any language that doesn't look like Java. WASM in contrast is designed explicitly for JITting, in fact, one-pass JITting is possible. The data structures maps well to the compiler backend. The representation is restricted in ways to avoid requiring expensive analysis, most notoriously, no arbitrary branching.
zamadatix 7y ago
If you're looking for technical details about the virtual machines themselves it's easier to just read their documentation. If you're looking for what WASM does differently resulting in the JVM not being a good fit it's mostly around browser integration. WASM runs as part of the browser, designed so that the same VM running the JavaScript portions of a page can run the WASM portions without enormous modification. It's also more tightly coupled with the data model of the browser but it doesn't have full direct access to everything, still better than ferrying everything to a second VM. As for why people are so excited to use it outside of the browser it probably has to do with the level of support and investment around engines like V8 and that it's not designed for a particular language.
AndrewDucker 7y ago
JVM bytecode is significantly higher level, and comes with support for type reflection, garbage collection, etc. Whereas WASM doesn't include any of that. Which makes it simpler and more lightweight, but means that anything which needs that functionality has to do it itself.

FullyFunctional 7y ago

Controversial opinion alert! Java Bytecode is an awful design. It's obvious if you study it that it was never designed as a compiler intermediate. Instead it was a fairly trivial byte code machine for which JITting was an afterthought. The bytecode "verification" is such a difficult problem that it lead to multiple articles and originally had a sequence of security holes. The JVM is also very far from language independent. Good luck making an efficient mapping for any language that doesn't look like Java. WASM in contrast is designed explicitly for JITting, in fact, one-pass JITting is possible. The data structures maps well to the compiler backend. The representation is restricted in ways to avoid requiring expensive analysis, most notoriously, no arbitrary branching.

zamadatix 7y ago

If you're looking for technical details about the virtual machines themselves it's easier to just read their documentation. If you're looking for what WASM does differently resulting in the JVM not being a good fit it's mostly around browser integration. WASM runs as part of the browser, designed so that the same VM running the JavaScript portions of a page can run the WASM portions without enormous modification. It's also more tightly coupled with the data model of the browser but it doesn't have full direct access to everything, still better than ferrying everything to a second VM. As for why people are so excited to use it outside of the browser it probably has to do with the level of support and investment around engines like V8 and that it's not designed for a particular language.

AndrewDucker 7y ago

JVM bytecode is significantly higher level, and comes with support for type reflection, garbage collection, etc. Whereas WASM doesn't include any of that. Which makes it simpler and more lightweight, but means that anything which needs that functionality has to do it itself.