Re:Web Assembly now supported across all browsers
by m1el on Monday December 04, 2017 @06:20AM
(#15843100)
I'll take a stab at your question.
> Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it?
Lack of pointers. Lack of true structs. Different memory model. Enforced class/object model.
WebAssembly has a memory model which is very close to a generic CPU.
My understanding of what made WASM necessary -
You don't want a GC? You don't get a GC.
You want full control over your memory layout? You get a raw growable slab of memory with raw pointers.
Re:Web Assembly now supported across all browsers
by Game_Ender on Monday December 04, 2017 @06:09AM
(#15843059)
The first upside is WebAssembly is designed to run C++ at close to native <10% overhead. The WASM team is starting with that foundation then adding features needed for GC and cross language API access (DOM). This is as opposed the Java and C# byte codes which come with a lot of assumptions baked in.
But don't we already have a universal byte code with JVM bytecode?
Why did the wheel need to be reinvented here? Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it?
This isn't a troll question. I'm curious what are the fundamental underlying technical issues that made WebAssembly necessary
(please be nice... c++ developer here.. so I'm really clueless about web stuff. I don't even use the JVM)