6 ms·

You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.

by Rusky 7y ago

thesuperbigfrog 7y ago
Would you please share the "very specific technical differences"? As a long-time JVM user, I am curious about WASM and how it compares to the JVM and CLR.
- k__ 7y ago
  As far as I know, WASM was thought of as a compilation target for languages like C and Rust, which are quite different from Java and C#. That alone should make WASM quite different from the JVM, no?
  - pjmlp 7y ago
    https://github.com/oracle/graal https://github.com/oracle/graal The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis. As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System. Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,.... IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability. While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.
    - Rusky 7y ago
      Again, you keep bringing these up, by they are not the same thing as WASM. Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source. The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode- and the latter doesn't support newer language standards and is being phased out. WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.
      - chrisseaton 7y ago
        > Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs It does - LLVM bitcode.
        Rusky 7y ago
        LLVM bitcode is far worse than WASM bytecode as a standard binary interchange format. It is intentionally non-portable and unstable by its designers. Google tried using it for this purpose with PNaCl and it wasn't great. Apple makes it work by strictly controlling the target hardware they use it for, and with massive investment in the toolchain.
        chrisseaton 7y ago
        I didn't claim it was a good binary format - I just claimed GraalVM supports it, which it does.
        afiori 7y ago
        But it is not an application delivery format which is the whole point here.
        pjmlp 7y ago
        Sure it is, that is what watchOS uses.
        chrisseaton 7y ago
        I ship LLVM to deliver applications just fine.
        repolfx 7y ago
        That's more a criticism of C rather than LLVM. Bitcode isn't as portable or stable as JVM bytecode because real world C programs use processor specific intrinsics, make assumptions about endianness and word sizes, embed assembly etc etc. LLVM is designed to support all real C programs, which means it can't be entirely portable. Wasm today is a toy hardly anyone uses. It can't run many real world C programs which means they'll need to be "ported" to the subset of C wasm supports. Well, if you're willing to work with that constraint you can constrain bitcode in the same way. By the way Graals LLVM support can execute multiple bitcode versions, with seamless and fast language interop, and it virtualises execution so that e.g. a subset of x86 assembly can be cross compiled on the fly to other arch's. It's needed because so much real C doesn't target an abstract machine but real CPUs.
- flohofwoe 7y ago
  The simple C-style linear memory model is the most important one IMHO, since this preserves the explicit control over the entire memory layout of an application which languages like C, C++ or Rust allow. Optimizations for efficient use of CPU caches carry over into WASM. AFAIK both CLR and JVM use a much higher level model which is built around fine-grained allocations managed by a GC.
  - pjmlp 7y ago
    CLR supports C++ since version 1.0. In fact it had two versions of it, Managed C++ released in version 1.0, replaced by C++/CLI with version 2.0. JVM has support for C-style linear memory model on its unsafe interfaces (the non-public ones), and is being improved via Graal (which understands LLVM bitcode) and Projects Panama/Valhalla.
    - flohofwoe 7y ago
      Ah alright, thanks for the clarification. Pre-WASM emscripten actually shows that it's possible to compile C to any language or virtual machine that has simple linear arrays to use as C's heap, it's just not as efficient.
pjmlp 7y ago
Please, what wonderful feature does WASM have that neither JVM nor CLR are capable of? Or for that matter, the myriad of bytecode formats devised since UNCOL, like the IBM and UNISYS's language environments on their mainframes.
- yellowapple 7y ago
  WASM is much smaller and simpler than either. This makes it easier to implement, both within browsers (as evidenced by most mainstream browsers already supporting it natively, and the rest via a polyfill) and beyond (e.g. the myriad of WASM runtimes out there - both interpreted and JIT/AOT compiled - written in all sorts of languages and usable outside a web browser). Same goes for most other bytecode VMs of a similar style/vintage (Dis, Parrot, BEAM, Dalvik, etc.). Can't speak to mainframe VMs, since I ain't familiar with them. It's reasonable to assume they were proprietary, though (that's how things typically were back in those days), so WASM has a leg up there.
  - pjmlp 7y ago
    WASM MVP is smaller and simpler. The WASM that everyone dreams about will be the same size, if it is supposed to match in features. Plenty of bytecode formats since have been AOT/JIT since the early 70's. We wouldn't even be discussing WASM if Mozilla wasn't unwilling to implement PNaCL. Apparently being open source, with initial support for C, C++ and OCaml support wasn't enough.
    - yellowapple 7y ago
      > The WASM that everyone dreams about will be the same size, if it is supposed to match in features. The WASM I dream about (can't speak for anyone else) won't be a whole lot bigger than it is now [0], and I don't think anyone expects it to match the bigger VMs in features (the sheer number of features in the bigger VMs is part of the problem!). ---- [0]: It's already pretty great, IMO, and the additions I'd like to see - namely, support for multiple memories, and the handful of extra instructions necessary to support tail call optimization [0.1] and garbage collection [0.2] - ain't expected to be that huge of an addition in terms of instruction set bloat. I'm hopeful that they won't be especially complex to implement, either. [0.1]: https://github.com/WebAssembly/tail-call/blob/master/proposals/tail-call/Overview.md https://github.com/WebAssembly/tail-call/blob/master/proposa... [0.2]: https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.

by Rusky 7y ago

You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.

thesuperbigfrog 7y ago

Would you please share the "very specific technical differences"? As a long-time JVM user, I am curious about WASM and how it compares to the JVM and CLR.

k__ 7y ago
As far as I know, WASM was thought of as a compilation target for languages like C and Rust, which are quite different from Java and C#. That alone should make WASM quite different from the JVM, no?
- pjmlp 7y ago
  https://github.com/oracle/graal https://github.com/oracle/graal The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis. As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System. Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,.... IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability. While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.
  - Rusky 7y ago
    Again, you keep bringing these up, by they are not the same thing as WASM. Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source. The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode- and the latter doesn't support newer language standards and is being phased out. WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.
    - chrisseaton 7y ago
      > Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs It does - LLVM bitcode.
      - Rusky 7y ago
        LLVM bitcode is far worse than WASM bytecode as a standard binary interchange format. It is intentionally non-portable and unstable by its designers. Google tried using it for this purpose with PNaCl and it wasn't great. Apple makes it work by strictly controlling the target hardware they use it for, and with massive investment in the toolchain.
        chrisseaton 7y ago
        I didn't claim it was a good binary format - I just claimed GraalVM supports it, which it does.
        afiori 7y ago
        But it is not an application delivery format which is the whole point here.
        pjmlp 7y ago
        Sure it is, that is what watchOS uses.
        chrisseaton 7y ago
        I ship LLVM to deliver applications just fine.
        repolfx 7y ago
        That's more a criticism of C rather than LLVM. Bitcode isn't as portable or stable as JVM bytecode because real world C programs use processor specific intrinsics, make assumptions about endianness and word sizes, embed assembly etc etc. LLVM is designed to support all real C programs, which means it can't be entirely portable. Wasm today is a toy hardly anyone uses. It can't run many real world C programs which means they'll need to be "ported" to the subset of C wasm supports. Well, if you're willing to work with that constraint you can constrain bitcode in the same way. By the way Graals LLVM support can execute multiple bitcode versions, with seamless and fast language interop, and it virtualises execution so that e.g. a subset of x86 assembly can be cross compiled on the fly to other arch's. It's needed because so much real C doesn't target an abstract machine but real CPUs.
flohofwoe 7y ago
The simple C-style linear memory model is the most important one IMHO, since this preserves the explicit control over the entire memory layout of an application which languages like C, C++ or Rust allow. Optimizations for efficient use of CPU caches carry over into WASM. AFAIK both CLR and JVM use a much higher level model which is built around fine-grained allocations managed by a GC.
- pjmlp 7y ago
  CLR supports C++ since version 1.0. In fact it had two versions of it, Managed C++ released in version 1.0, replaced by C++/CLI with version 2.0. JVM has support for C-style linear memory model on its unsafe interfaces (the non-public ones), and is being improved via Graal (which understands LLVM bitcode) and Projects Panama/Valhalla.
  - flohofwoe 7y ago
    Ah alright, thanks for the clarification. Pre-WASM emscripten actually shows that it's possible to compile C to any language or virtual machine that has simple linear arrays to use as C's heap, it's just not as efficient.

pjmlp 7y ago

Please, what wonderful feature does WASM have that neither JVM nor CLR are capable of? Or for that matter, the myriad of bytecode formats devised since UNCOL, like the IBM and UNISYS's language environments on their mainframes.

yellowapple 7y ago
WASM is much smaller and simpler than either. This makes it easier to implement, both within browsers (as evidenced by most mainstream browsers already supporting it natively, and the rest via a polyfill) and beyond (e.g. the myriad of WASM runtimes out there - both interpreted and JIT/AOT compiled - written in all sorts of languages and usable outside a web browser). Same goes for most other bytecode VMs of a similar style/vintage (Dis, Parrot, BEAM, Dalvik, etc.). Can't speak to mainframe VMs, since I ain't familiar with them. It's reasonable to assume they were proprietary, though (that's how things typically were back in those days), so WASM has a leg up there.
- pjmlp 7y ago
  WASM MVP is smaller and simpler. The WASM that everyone dreams about will be the same size, if it is supposed to match in features. Plenty of bytecode formats since have been AOT/JIT since the early 70's. We wouldn't even be discussing WASM if Mozilla wasn't unwilling to implement PNaCL. Apparently being open source, with initial support for C, C++ and OCaml support wasn't enough.
  - yellowapple 7y ago
    > The WASM that everyone dreams about will be the same size, if it is supposed to match in features. The WASM I dream about (can't speak for anyone else) won't be a whole lot bigger than it is now [0], and I don't think anyone expects it to match the bigger VMs in features (the sheer number of features in the bigger VMs is part of the problem!). ---- [0]: It's already pretty great, IMO, and the additions I'd like to see - namely, support for multiple memories, and the handful of extra instructions necessary to support tail call optimization [0.1] and garbage collection [0.2] - ain't expected to be that huge of an addition in terms of instruction set bloat. I'm hopeful that they won't be especially complex to implement, either. [0.1]: https://github.com/WebAssembly/tail-call/blob/master/proposals/tail-call/Overview.md https://github.com/WebAssembly/tail-call/blob/master/proposa... [0.2]: https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...