5 ms·

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.

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.