6 ms·

It may not only be benevolence though. The JVM and Graal are not the only game in town anymore. Webassembly is growing in various areas, clienside, edge, backen

It may not only be benevolence though. The JVM and Graal are not the only game in town anymore. Webassembly is growing in various areas, clienside, edge, backend. WASM fills much of the same needs as Graal, and then some since it’s embedded in every major browser. This move is good for Graal, as it will help it compete, but there’s still a big question in my mind at least about if Graal is going to be able to compete long-term. Yes, I know Graal can also execute WASM generated binaries, so it may have a space in this environment, but will it outperform native WASM VMs? And will WASM become the de facto binary format for shipping things where JVM bytecode has been used in the past? What’s Graal’s place in the future?

dopidopHN 4y ago
Yeah. I see that as a way to position the JVM for cloud-function and other highly available and disposable compute.
lostmsu 4y ago
WASM is not really a replacement for Graal. Graal is more of a language implementation framework, while WASM is a compilation target.
- lostmsu 4y ago
  I think down in the comments people mentioned, that the language part of Graal is not actually included in the contribution.
vips7L 4y ago
Is there a current WASM implementation that can out perform HotSpot? Will WASM ever outperform it? I highly doubt it.
- frant-hartm 4y ago
  GraalVM? :-)
mike_hearn 4y ago
WASM isn't really a replacement for JVM bytecode. It's not like you can take a random JAR and convert it to WASM. Last I checked, WASM doesn't even support GCd languages at all, and at any rate the whole insight that makes GraalVM unique and a big deal is that universal bytecodes are a poor choice for making fast polyglot VMs. The JVM world was doing that long before WASM was even a twinkle in Google's eye, with invokedynamic and other initiatives, and it kinda works. JRuby+indy is a lot faster than MRI. But, there's a lot of compromises involved. Truffle is interesting because it says, no, we should not be trying to compile everything to a universal bytecode. Instead, we should JIT compile the source code directly, using the JVM as a runtime library but bypassing the bytecode layer. The language semantics can be expressed much more clearly, without needing to contort things to make them look like Java, whilst still benefiting from the JVM's core feature set. So really I'd ask it the other way around. If it weren't for the politics of the browser world and the monolithic "Chrome is the OS" approach, would WASM be competitive? Because the Graal team already proved you can run lots of different languages at relatively insane speeds using partial evaluation and bypassing bytecode. The WASM world has proven it can run C++ and Rust at slower speeds than normal, which isn't particularly unexpected. If Chrome and Safari shipped GraalVM accessible via <script> tags, how many people would care about WASM? Remember that you can run WASM and LLVM bitcode on top of GraalVM too, it's not just about textual languages. Arguably, if you wanted to give the web an instant free upgrade that'd make many developers rejoice, integrating Graal into Chrome would be an overnight way to do it. Python, Ruby, JVM bytecode and any other language you want at V8 like speeds, in a script tag? It's technically possible, it's just not politically possible.
- thesuperbigfrog 4y ago
  >> It's not like you can take a random JAR and convert it to WASM. Maybe you can: "TeaVM is an ahead-of-time compiler for Java bytecode that emits JavaScript and WebAssembly that runs in a browser. Its close relative is the well-known GWT. The main difference is that TeaVM does not require source code, only compiled class files. Moreover, the source code is not required to be Java, so TeaVM successfully compiles Kotlin and Scala." https://teavm.org/ https://teavm.org/ I have never had an opportunity to try out TeaVM, but it seems promising.
jjtheblunt 4y ago
What dependencies does WASM necessitate? A Javascript VM, for instance, or is that only for DOM connectivity reasons?

dopidopHN 4y ago

Yeah. I see that as a way to position the JVM for cloud-function and other highly available and disposable compute.

lostmsu 4y ago

WASM is not really a replacement for Graal. Graal is more of a language implementation framework, while WASM is a compilation target.

lostmsu 4y ago
I think down in the comments people mentioned, that the language part of Graal is not actually included in the contribution.

vips7L 4y ago

Is there a current WASM implementation that can out perform HotSpot? Will WASM ever outperform it? I highly doubt it.

frant-hartm 4y ago
GraalVM? :-)

mike_hearn 4y ago

WASM isn't really a replacement for JVM bytecode. It's not like you can take a random JAR and convert it to WASM. Last I checked, WASM doesn't even support GCd languages at all, and at any rate the whole insight that makes GraalVM unique and a big deal is that universal bytecodes are a poor choice for making fast polyglot VMs. The JVM world was doing that long before WASM was even a twinkle in Google's eye, with invokedynamic and other initiatives, and it kinda works. JRuby+indy is a lot faster than MRI. But, there's a lot of compromises involved. Truffle is interesting because it says, no, we should not be trying to compile everything to a universal bytecode. Instead, we should JIT compile the source code directly, using the JVM as a runtime library but bypassing the bytecode layer. The language semantics can be expressed much more clearly, without needing to contort things to make them look like Java, whilst still benefiting from the JVM's core feature set. So really I'd ask it the other way around. If it weren't for the politics of the browser world and the monolithic "Chrome is the OS" approach, would WASM be competitive? Because the Graal team already proved you can run lots of different languages at relatively insane speeds using partial evaluation and bypassing bytecode. The WASM world has proven it can run C++ and Rust at slower speeds than normal, which isn't particularly unexpected. If Chrome and Safari shipped GraalVM accessible via <script> tags, how many people would care about WASM? Remember that you can run WASM and LLVM bitcode on top of GraalVM too, it's not just about textual languages. Arguably, if you wanted to give the web an instant free upgrade that'd make many developers rejoice, integrating Graal into Chrome would be an overnight way to do it. Python, Ruby, JVM bytecode and any other language you want at V8 like speeds, in a script tag? It's technically possible, it's just not politically possible.

thesuperbigfrog 4y ago
>> It's not like you can take a random JAR and convert it to WASM. Maybe you can: "TeaVM is an ahead-of-time compiler for Java bytecode that emits JavaScript and WebAssembly that runs in a browser. Its close relative is the well-known GWT. The main difference is that TeaVM does not require source code, only compiled class files. Moreover, the source code is not required to be Java, so TeaVM successfully compiles Kotlin and Scala." https://teavm.org/ https://teavm.org/ I have never had an opportunity to try out TeaVM, but it seems promising.

jjtheblunt 4y ago

What dependencies does WASM necessitate? A Javascript VM, for instance, or is that only for DOM connectivity reasons?