3 ms·

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

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.
- mike_hearn 4y ago
  I've used TeaVM in a past project, to compile some Java to JS. It's very cool tech. Unfortunately I heard that the team ripped out the TeaVM after I left. That's understandable - I had to fix some bugs and missing pieces in TeaVM as part of that project, and I think a lot of codebases would face the same issue, but compiler hacking isn't everyone's, um, cup of tea. It was a great way to get a lot done in the two weeks I had available though. I should have clarified. Yes, you can probably do a native-image style "compile an app+embedded JVM to wasm" by pretending V8 is a CPU. There are programs that do that sort of thing, I think Leaning Technologies makes one. That wouldn't be of use in any existing Java project though. The only reason you'd ever want to do that is because browsers offer nothing else, even though they could and at that point why not compile to JS, at least that way your GC isn't being interpreted too. If you're not constrained by the WHATWG's decisions though it doesn't offer anything.
  - thesuperbigfrog 4y ago
    >> There are programs that do that sort of thing, I think Leaning Technologies makes one. It looks like you mean CheerpJ: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ https://github.com/leaningtech/cheerpj-meta https://github.com/leaningtech/cheerpj-meta >> That wouldn't be of use in any existing Java project though. The only reason you'd ever want to do that is because browsers offer nothing else, even though they could and at that point why not compile to JS, at least that way your GC isn't being interpreted too. If you're not constrained by the WHATWG's decisions though it doesn't offer anything. It is very use case and "what is the future of your Java application" dependent. Some organizations are looking into migrating off of Java due to a variety of reasons. These kind of "Java conversion" tools help to keep legacy Java applications running until the legacy Java applications can be replaced.
chrisseaton 4y ago
Doesn't GraalVM have both a WASM frontend and backend?
- grashalm 4y ago
  No, there is only a frontend. There is a JavaScript backend though. I hope the GC proposal for WASM ultimately goes through to enable a backend in WASM too.
  - chrisseaton 4y ago
    Maybe I saw a demo round-tripping through LLVM then.
  - frant-hartm 4y ago
    What does frontend and backend mean in this context? With graal you can - run wasm interpreted on OpenJDK, similar to javascript running interpreted in nashorn, or now graalvm, you just need to add couple of graal sdk jars to your dependencies - run wasm compiled, you need to run on GraalVM for this. This is supposed to provide around 50x speedup compared to previous point
    - chrisseaton 4y ago
      Frontend means can you take WASM code and feed it into Graal as input. Backend means can you get Graal to produce WASM code as output.
patrickthebold 4y ago
python support seems fairly experimental right now: https://www.graalvm.org/22.3/reference-manual/python/ https://www.graalvm.org/22.3/reference-manual/python/ or is that something different?
- mike_hearn 4y ago
  It's "experimental" in the sense that it's incomplete, but the core tech is mature and works fine. Full support means supporting all the third party modules along with interpreter extensions, every part of the standard library etc.
bluejekyll 4y ago
> If Chrome and Safari shipped GraalVM accessible via <script> tags, how many people would care about WASM? That’s a good question, and partly why I was pointing out that it’s not just benevolence for Oracle to OSS this. I don’t know if the browsers vendors could embed Graal, maybe they can, (license restrictions being some of the issues I’m sure) and then that could supplant the individual JS and WASM runtimes they support. But this wasn’t even an option until today. > Remember that you can run WASM and LLVM bitcode on top of GraalVM too, it's not just about textual languages. Which is exactly why I mentioned that in my original comment. Yes, Graal could be that runtime, will it? Seems like a gamble for anyone who’s not already in the JVM ecosystem to some degree.
- mike_hearn 4y ago
  Despite the wording of the announcement, Graal and Truffle have been open source under permissive licenses for a long time now. The "donation" is from one open source project run by Oracle to another. Confusing, indeed, but Oracle is a big company. So it's been possible license-wise for a long time.
  - bluejekyll 4y ago
    In the announcement it sounds like they are planning to change the license in some manner, “Will the GraalVM license change? The plan is to align all the GraalVM technologies with Java both from a release perspective and from a licensing perspective. Additional details will follow in the coming months as we move forward through this process.”
    - origin_path 4y ago
      They're both open source licenses just slightly different ones (gpl2+CPE and upl I guess). Sun liked to use odd licenses.
0x457 4y ago
> WASM doesn't even support GCd languages at all Well, some GC'd languages support compilation to WASM, for example, you can compile go to WASM. The issue here is that for GC'd languages you have to bring your own runtime with GC in every module, so this doesn't really work.

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.

mike_hearn 4y ago
I've used TeaVM in a past project, to compile some Java to JS. It's very cool tech. Unfortunately I heard that the team ripped out the TeaVM after I left. That's understandable - I had to fix some bugs and missing pieces in TeaVM as part of that project, and I think a lot of codebases would face the same issue, but compiler hacking isn't everyone's, um, cup of tea. It was a great way to get a lot done in the two weeks I had available though. I should have clarified. Yes, you can probably do a native-image style "compile an app+embedded JVM to wasm" by pretending V8 is a CPU. There are programs that do that sort of thing, I think Leaning Technologies makes one. That wouldn't be of use in any existing Java project though. The only reason you'd ever want to do that is because browsers offer nothing else, even though they could and at that point why not compile to JS, at least that way your GC isn't being interpreted too. If you're not constrained by the WHATWG's decisions though it doesn't offer anything.
- thesuperbigfrog 4y ago
  >> There are programs that do that sort of thing, I think Leaning Technologies makes one. It looks like you mean CheerpJ: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ https://github.com/leaningtech/cheerpj-meta https://github.com/leaningtech/cheerpj-meta >> That wouldn't be of use in any existing Java project though. The only reason you'd ever want to do that is because browsers offer nothing else, even though they could and at that point why not compile to JS, at least that way your GC isn't being interpreted too. If you're not constrained by the WHATWG's decisions though it doesn't offer anything. It is very use case and "what is the future of your Java application" dependent. Some organizations are looking into migrating off of Java due to a variety of reasons. These kind of "Java conversion" tools help to keep legacy Java applications running until the legacy Java applications can be replaced.

chrisseaton 4y ago

Doesn't GraalVM have both a WASM frontend and backend?

grashalm 4y ago
No, there is only a frontend. There is a JavaScript backend though. I hope the GC proposal for WASM ultimately goes through to enable a backend in WASM too.
- chrisseaton 4y ago
  Maybe I saw a demo round-tripping through LLVM then.
- frant-hartm 4y ago
  What does frontend and backend mean in this context? With graal you can - run wasm interpreted on OpenJDK, similar to javascript running interpreted in nashorn, or now graalvm, you just need to add couple of graal sdk jars to your dependencies - run wasm compiled, you need to run on GraalVM for this. This is supposed to provide around 50x speedup compared to previous point
  - chrisseaton 4y ago
    Frontend means can you take WASM code and feed it into Graal as input. Backend means can you get Graal to produce WASM code as output.

patrickthebold 4y ago

python support seems fairly experimental right now: https://www.graalvm.org/22.3/reference-manual/python/ https://www.graalvm.org/22.3/reference-manual/python/ or is that something different?

mike_hearn 4y ago
It's "experimental" in the sense that it's incomplete, but the core tech is mature and works fine. Full support means supporting all the third party modules along with interpreter extensions, every part of the standard library etc.

bluejekyll 4y ago

> If Chrome and Safari shipped GraalVM accessible via <script> tags, how many people would care about WASM? That’s a good question, and partly why I was pointing out that it’s not just benevolence for Oracle to OSS this. I don’t know if the browsers vendors could embed Graal, maybe they can, (license restrictions being some of the issues I’m sure) and then that could supplant the individual JS and WASM runtimes they support. But this wasn’t even an option until today. > Remember that you can run WASM and LLVM bitcode on top of GraalVM too, it's not just about textual languages. Which is exactly why I mentioned that in my original comment. Yes, Graal could be that runtime, will it? Seems like a gamble for anyone who’s not already in the JVM ecosystem to some degree.

mike_hearn 4y ago
Despite the wording of the announcement, Graal and Truffle have been open source under permissive licenses for a long time now. The "donation" is from one open source project run by Oracle to another. Confusing, indeed, but Oracle is a big company. So it's been possible license-wise for a long time.
- bluejekyll 4y ago
  In the announcement it sounds like they are planning to change the license in some manner, “Will the GraalVM license change? The plan is to align all the GraalVM technologies with Java both from a release perspective and from a licensing perspective. Additional details will follow in the coming months as we move forward through this process.”
  - origin_path 4y ago
    They're both open source licenses just slightly different ones (gpl2+CPE and upl I guess). Sun liked to use odd licenses.

0x457 4y ago

> WASM doesn't even support GCd languages at all Well, some GC'd languages support compilation to WASM, for example, you can compile go to WASM. The issue here is that for GC'd languages you have to bring your own runtime with GC in every module, so this doesn't really work.