3 ms·

Doesn't the jvm weight dozens of megabytes, with tracing JIT, baked in OO semantics, GCs, etc.? That seems hardly comparable with wasm which currently works bes

by c-cube 5y ago

Doesn't the jvm weight dozens of megabytes, with tracing JIT, baked in OO semantics, GCs, etc.? That seems hardly comparable with wasm which currently works best for languages like C++ or rust with pretty small runtime. Just like people more commonly use lua as an extension language rather than Java.

still_grokking 5y ago
And where is the advantage to run C/C++/Rust as WASM? It's much slower than native (you will need a JIT to make it reasonable fast again!), needs a considerably huge runtime with a significant memory overhead compared to native, and a complicated build setup. Someone will say now: Sandbox. But sandboxing native code, in a native way (using directly the facilities that the WASM runtime would use) is much simpler, cheaper, and more performant. And for high-level languages you need anyway all the things that the JVM has build in. Also you get there instrumentation, monitoring, and debugging facilities for "free". The only valid point of criticism I see here is the complaint about the "build in" OO semantics of the JVM. But that's nothing that couldn't be augmented by some better fitting mechanics for cases where translation to OO is very problematic. (But actually I have a hard time to think of an example for this problem. OO and FP are actually duals¹ ² of each other, and there's not much that's neither OO nor FP). ¹ https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf ² https://www.researchgate.net/publication/332248372_Codata_in_Action https://www.researchgate.net/publication/332248372_Codata_in...
- c-cube 5y ago
  You do need a JIT, but a simpler one, like AOT-on-demand, since it's very static compared to other formats. It's not that far from shipping LLVM IR, except it's specified. As for the memory overhead, where have you seen that? To my knowledge the most problematic part there is that wasm currently doesn't offer any way to return memory to the OS. The point of sandboxing is that the space allocated to wasm is well delineated and there should be no way to access the rest of your memory from the inside. For stuff like plugins, that's very valuable compared to just providing a .so with absolutely 0 isolation, in addition to having to compile the .so/.dynlib for your specific OS and architecture beforehand.

by c-cube 5y ago

still_grokking 5y ago

And where is the advantage to run C/C++/Rust as WASM? It's much slower than native (you will need a JIT to make it reasonable fast again!), needs a considerably huge runtime with a significant memory overhead compared to native, and a complicated build setup. Someone will say now: Sandbox. But sandboxing native code, in a native way (using directly the facilities that the WASM runtime would use) is much simpler, cheaper, and more performant. And for high-level languages you need anyway all the things that the JVM has build in. Also you get there instrumentation, monitoring, and debugging facilities for "free". The only valid point of criticism I see here is the complaint about the "build in" OO semantics of the JVM. But that's nothing that couldn't be augmented by some better fitting mechanics for cases where translation to OO is very problematic. (But actually I have a hard time to think of an example for this problem. OO and FP are actually duals¹ ² of each other, and there's not much that's neither OO nor FP). ¹ https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf ² https://www.researchgate.net/publication/332248372_Codata_in_Action https://www.researchgate.net/publication/332248372_Codata_in...

c-cube 5y ago
You do need a JIT, but a simpler one, like AOT-on-demand, since it's very static compared to other formats. It's not that far from shipping LLVM IR, except it's specified. As for the memory overhead, where have you seen that? To my knowledge the most problematic part there is that wasm currently doesn't offer any way to return memory to the OS. The point of sandboxing is that the space allocated to wasm is well delineated and there should be no way to access the rest of your memory from the inside. For stuff like plugins, that's very valuable compared to just providing a .so with absolutely 0 isolation, in addition to having to compile the .so/.dynlib for your specific OS and architecture beforehand.