3 ms·

Latest Javas can run hello world in about 50msec or less. If you AOT compile the app it can do so a bit faster than an app written in C, believe it or not. This

Latest Javas can run hello world in about 50msec or less. If you AOT compile the app it can do so a bit faster than an app written in C, believe it or not. This is not really a competitive advantage for wasmtime. Actually, wasm is less flexible than the JVM because with GraalVM/Truffle you can run: 1. WASM 2. LLVM bitcode both on the JVM, alongside all the other languages it can do like Python, Ruby, Clojure, JavaScript, Kotlin, Smalltalk, R etc. Therefore you can run Rust, C and C++ on the JVM. Don't think you can run Go, but this is still way more languages on the JVM than WASM. https://www.graalvm.org/22.2/reference-manual/llvm/ https://www.graalvm.org/22.2/reference-manual/llvm/ https://www.graalvm.org/22.2/reference-manual/wasm/ https://www.graalvm.org/22.2/reference-manual/wasm/ When running these bytecodes on GraalVM, you also get full interop between languages: https://www.graalvm.org/22.2/reference-manual/polyglot-programming/ https://www.graalvm.org/22.2/reference-manual/polyglot-progr... You ask why there's no popular C frontend for the JVM. It's because nobody really cares about running C on a VM except for people targeting Chrome/Safari. You can do it with GraalVM and it has some uses for running C language extensions to scripting languages, but otherwise is a bit of a curiousity. Usually if you want to call a C library it's because it's an operating system API or because you want to do things that a VM wouldn't do well anyway e.g. stuff with inline native assembly.

bfung 4y ago
To get back at a higher level - I’m not attacking the JVM - a lot of my career had been using it to much success. And the large benefits of wasm are still in the making/a bit unclear. In my original post, I question why this runtime is useful at all, as the jvm already does a lot of the same things. However, GC by default is not in wasm right now, and that enables non-GC languages to be ported over, while it makes no sense to port those languages to the jvm. And a lot of the important stuff is written in those non-GC languages; game engines, gpu compute usage for AI, and others I probably don’t know. The JVM is old ~ still good/great for backend server side things, but not great for fast startup (50ms is still 10,000’slower than wasmtime’s 5 micro second startup), non-gc stuff, and non-technical, impatient, end user browser stuff. Hence worth the exploration - and if it means jvm being replaced 10 years later, so be it (maybe there’ll be a Java to wasm port + gc for wasm by then).
- origin_path 4y ago
  You can actually run non-GC languages on the JVM because it does expose a manual memory allocator. That's how the WASM and LLVM support work. In that case the GC gets out of the way (or is used only for Java objects). Of course in that case a lot of the benefits of the JVM aren't there, but if you need to do JIT compilation+manual memory management then it can make sense. The real question I think is, if it weren't for particular technical choices by the browser people, would anyone care about JIT compiling C? Probably not. We know how to sandbox C/C++/Rust without a JITC, nacl and other initiatives have proved that. Portability, so what - there's really two CPU archs that matter and new ones don't come along very often. Cross compilers work. The GraalVM guys have found a good reason to JITC of C for language interop and interpreter extensions but that's pretty special case.

bfung 4y ago

To get back at a higher level - I’m not attacking the JVM - a lot of my career had been using it to much success. And the large benefits of wasm are still in the making/a bit unclear. In my original post, I question why this runtime is useful at all, as the jvm already does a lot of the same things. However, GC by default is not in wasm right now, and that enables non-GC languages to be ported over, while it makes no sense to port those languages to the jvm. And a lot of the important stuff is written in those non-GC languages; game engines, gpu compute usage for AI, and others I probably don’t know. The JVM is old ~ still good/great for backend server side things, but not great for fast startup (50ms is still 10,000’slower than wasmtime’s 5 micro second startup), non-gc stuff, and non-technical, impatient, end user browser stuff. Hence worth the exploration - and if it means jvm being replaced 10 years later, so be it (maybe there’ll be a Java to wasm port + gc for wasm by then).

origin_path 4y ago
You can actually run non-GC languages on the JVM because it does expose a manual memory allocator. That's how the WASM and LLVM support work. In that case the GC gets out of the way (or is used only for Java objects). Of course in that case a lot of the benefits of the JVM aren't there, but if you need to do JIT compilation+manual memory management then it can make sense. The real question I think is, if it weren't for particular technical choices by the browser people, would anyone care about JIT compiling C? Probably not. We know how to sandbox C/C++/Rust without a JITC, nacl and other initiatives have proved that. Portability, so what - there's really two CPU archs that matter and new ones don't come along very often. Cross compilers work. The GraalVM guys have found a good reason to JITC of C for language interop and interpreter extensions but that's pretty special case.