6 ms·

I don't see too many immediate term improvements from what we have today, but I do see GraalVM to be just different enough from mainline OpenJDK releases to que

by adra 4y ago

I don't see too many immediate term improvements from what we have today, but I do see GraalVM to be just different enough from mainline OpenJDK releases to question exploring the features of that build (in JVM or native modes). I poked at the release from time to time between 19 and 22 but always ended up going back. If this can improve that story, I'd say it's a win for all. Of course I'm not sure what this changes in regards to Oracle's extended paid version of the GraalVM runtime.

Alupis 4y ago
GraalVM will mostly benefit those who are building and deploying Function/Serverless and Microservices most - the native compilation really shines in that space (for near-instant start times and footprint reduction). For anyone else, the normal JVM is likely a better choice for now - the tech built in there is very mature and battle tested. With that said - baking a bunch of GraalVM features into the normal JVM is nothing but good for everyone. Native AOT compilation does have it's uses outside microservices/serverless, and some cross-pollination of VM ideas is a great idea.
- cogman10 4y ago
  There are a lot of other neat parts for graal that will likely be beneficial. One of the big benefits of graal is that it makes implementing guest languages a snap (via the truffle framework). So you can get all the operational benefits of the JVM + a nice set of languages to play with along with interopt cross language (python calling java calling ruby calling perl, etc). Here's the languages they already have. https://github.com/oracle/graal/blob/master/truffle/docs/Languages.md https://github.com/oracle/graal/blob/master/truffle/docs/Lan...
  - kasperni 4y ago
    There are no plans to move Truffle to OpenJDK.
    - kaba0 4y ago
      On the other hand, Truffle is just a Java library (with some special handling when used by Graal JIT compiler), so one will be able to just simply place it on the classpath.
  - Alupis 4y ago
    That particular claim/goal used to get me excited (run any language on GraalVM), but the reality seems to have worked out to be a very large asterisk next to that claim. From what I can tell, the effort to get any particular language running on Graal is non-trivial, leading to that relatively small list of supported languages - most of which seem to be custom dialects in one fashion or another. Perhaps I'm wrong though...
    - mike_hearn 4y ago
      Is it a small list? Especially if you count ILs like LLVM bitcode or WASM, it probably includes most of them. Many of the languages people use in the real world are really large, really old, really hairy and rely heavily on native extensions that poke arbitrary interpreter internals. Truffle at least makes these implementable with higher performance, and the team size needed to get that done isn't infeasible. But implementing a Ruby or Python will never be a five minute job regardless of what tech you use.
      - Alupis 4y ago
        It's small in that nearly half of the published list is academic languages and dialects, and the other half seems to be custom dialects of languages. While LLVM or WASM support is nice, most modern languages are not compiling to either one by default, and likely means it's not "turn key" to get your system running on Graal anyway.
        samus 4y ago
        WASM support makes it possible to run code where there are native compilers for the language.
    - mukel 4y ago
      GraalVM team member here. Implementing any mainstream language is indeed a challenge, more so if you have to maintain bug-compatibility and cope with all the bits of bad design that went through the cracks in the de-facto implementation. Truffle is not for beginners, but knowing the basic set of features e.g. partial evaluation, deoptimization... can get you very far already e.g. you can easily speedup any interpreter by 10X or more with minimal changes. How long does take to implement a programming language? Well, from hours to years... depending on the language. To make my point; how long would it take to implement a JVM? A JVM is a complex beast, so I would myself guess from years to a decade probably, what if I told you, that Espresso was written in just 6 months by an intern and a seasoned engineer... in just 6 months it was able to Minecraft and even run itself. I assure you there's no magic here, and certainly no blinding talent either; the only reason for this unheard productivity was Graal/Truffle. So, whenever I talk about Espresso I always give all credit to Graal/Truffle, it is a sublime platform for implementing fast languages and runtimes, of which Espresso is just a byproduct.
- threeseed 4y ago
  > building and deploying Function/Serverless and Microservices most For those you may be better with IBM OpenJ9: https://www.eclipse.org/openj9/ https://www.eclipse.org/openj9/ It also integrates with CRIU so you can almost instantly start/stop the JVM: https://blog.openj9.org/2022/09/26/getting-started-with-openj9-criu-support/ https://blog.openj9.org/2022/09/26/getting-started-with-open...
  - mdaniel 4y ago
    I keep forgetting about J9 but they're not doing themselves any branding favors since there actually is J17 on J9 :-/ https://github.com/eclipse-openj9/openj9/blob/openj9-0.35.0/doc/build-instructions/Build_Instructions_V17.md#building-openjdk-version-17-with-openj9 https://github.com/eclipse-openj9/openj9/blob/openj9-0.35.0/... (Also that 0.35 versioning ...) As best I can tell, these are the docker images: https://hub.docker.com/_/ibm-semeru-runtimes https://hub.docker.com/_/ibm-semeru-runtimes $ docker run --rm ibm-semeru-runtimes:open-11-jdk java -version openjdk version "11.0.17" 2022-10-18 IBM Semeru Runtime Open Edition 11.0.17.0 (build 11.0.17+8) Eclipse OpenJ9 VM 11.0.17.0 (build openj9-0.35.0, JRE 11 Linux amd64-64-Bit Compressed References 20221031_559 (JIT enabled, AOT enabled) OpenJ9 - e04a7f6c1 OMR - 85a21674f JCL - a94c231303 based on jdk-11.0.17+8)
  - vips7L 4y ago
    The phoronix benchmarks seem to imply that J9 performs worse overall. https://www.phoronix.com/review/java-openjdk-mid22 https://www.phoronix.com/review/java-openjdk-mid22
aseipp 4y ago
GraalVM is a bunch of components, but the most important one are 1) Graal, a library in Java that is a code generator and optimizer for compiler authors, 2) Native Image, a tool which turns Java programs into native executables via Graal, and 3) Truffle, a tool for implementing languages in Java that then get code generated, again by Graal "GraalVM" is the umbrella name of all these things packaged together, together with a couple languages implemented in Truffle. That's what you download when you go to the website. Galahad is a proposal to merge the Graal code generator library in Java, into OpenJDK's codebase, so that it is developed in tandem and comes with first-class support. And none of the other things, for now (Native Image will come later.) But you can also do this today: you can instead configure a stable LTS release of Java to use Graal as the code generator for the HotSpot VM, as an alternative to C2. It's a little bit of work to do so, but you can use any compliant OpenJDK build and test it out. Galahad will just make this an "out of the box" option rather than having to get Graal from Maven or whatever. So, you can just test things incrementally and see if Graal gives performance improvements over C2. You don't need to throw out your whole existing JVM, it's mostly just a new maven dependency. That's a much simpler and more targeted change, if you haven't given it a try (mostly by fiddling with some JVM -XX flags, as usual.)
hrpnk 4y ago
The challenge with GraalVM runtime is that there are differences in licensing. What was great about Java is that only for specialized use cases, one had to invest in a paid runtime. GraalVM moves essential features known from Java Runtime into an Enterprise Edition. From GraalVM docs [1] on memory management: "The G1 GC (only available with GraalVM Enterprise Edition) is a multi-threaded GC that is optimized to reduce stop-the-world pauses and therefore improve latency, while achieving high throughput. Currently, G1 can only be used in native images that are built on Linux for AMD64." [1] https://www.graalvm.org/22.2/reference-manual/native-image/optimizations-and-performance/MemoryManagement/ https://www.graalvm.org/22.2/reference-manual/native-image/o...
- kaba0 4y ago
  That particular one (and most differences) are only related to native image generation, not to Graal, as a JIT compiler.
- actuallyalys 4y ago
  I think tweaking the garbage collector when running on native is a specialized use case. Anecdotally, the projects using native image I'm aware of don't tweak the garbage collector settings that are available in the community version at all. If throughput is critical enough to warrant garbage collector fine tuning, there's a decent chance you'll run it on a VM anyway. Of course, there are exceptions, but I don't think this is a limitation for most projects. That being said, most of the JVM projects I'm very familiar are written in Clojure, so they may well be outliers compared to Java or other JVM languages.
thangalin 4y ago
It'll help build cross-platform desktop applications. In theory, it'll streamline using GitHub Actions to produce platform-specific binaries, such as my FOSS Markdown editor KeenWrite[0], without having to have a copy of every target operating system. To my knowledge, cross-compiling "native" Linux and Windows binaries using Java requires duct tape, chewing gum, and warp-packer.[1][2] If there's another way to cross-compile a Java application into a standalone binary for multiple target platforms, do tell! GraalVM isn't a panacea. For example, GraalVM cannot compile Renjin[3], a pure Java R interpreter, which means switching from Renjin to FastR. Not trivial. Other sinkholes likely lurk that'll only reveal themselves when walking through the weeds. [0]: https://github.com/DaveJarvis/keenwrite https://github.com/DaveJarvis/keenwrite [1]: https://dave.autonoma.ca/blog/2020/06/29/write-once-build-anywhere/ https://dave.autonoma.ca/blog/2020/06/29/write-once-build-an... [2]: https://github.com/dgiagio/warp https://github.com/dgiagio/warp [3]: https://github.com/bedatadriven/renjin/issues/564 https://github.com/bedatadriven/renjin/issues/564
- anentropic 4y ago
  I'm actually wanting to do this with Graal at the moment ("using GitHub Actions to produce platform-specific binaries") As far as I can tell Graal does not have cross-compilation ability currently (there is an open issue here: https://github.com/oracle/graal/issues/407 https://github.com/oracle/graal/issues/407)

by adra 4y ago

Alupis 4y ago

GraalVM will mostly benefit those who are building and deploying Function/Serverless and Microservices most - the native compilation really shines in that space (for near-instant start times and footprint reduction). For anyone else, the normal JVM is likely a better choice for now - the tech built in there is very mature and battle tested. With that said - baking a bunch of GraalVM features into the normal JVM is nothing but good for everyone. Native AOT compilation does have it's uses outside microservices/serverless, and some cross-pollination of VM ideas is a great idea.

cogman10 4y ago
There are a lot of other neat parts for graal that will likely be beneficial. One of the big benefits of graal is that it makes implementing guest languages a snap (via the truffle framework). So you can get all the operational benefits of the JVM + a nice set of languages to play with along with interopt cross language (python calling java calling ruby calling perl, etc). Here's the languages they already have. https://github.com/oracle/graal/blob/master/truffle/docs/Languages.md https://github.com/oracle/graal/blob/master/truffle/docs/Lan...
- kasperni 4y ago
  There are no plans to move Truffle to OpenJDK.
  - kaba0 4y ago
    On the other hand, Truffle is just a Java library (with some special handling when used by Graal JIT compiler), so one will be able to just simply place it on the classpath.
- Alupis 4y ago
  That particular claim/goal used to get me excited (run any language on GraalVM), but the reality seems to have worked out to be a very large asterisk next to that claim. From what I can tell, the effort to get any particular language running on Graal is non-trivial, leading to that relatively small list of supported languages - most of which seem to be custom dialects in one fashion or another. Perhaps I'm wrong though...
  - mike_hearn 4y ago
    Is it a small list? Especially if you count ILs like LLVM bitcode or WASM, it probably includes most of them. Many of the languages people use in the real world are really large, really old, really hairy and rely heavily on native extensions that poke arbitrary interpreter internals. Truffle at least makes these implementable with higher performance, and the team size needed to get that done isn't infeasible. But implementing a Ruby or Python will never be a five minute job regardless of what tech you use.
    - Alupis 4y ago
      It's small in that nearly half of the published list is academic languages and dialects, and the other half seems to be custom dialects of languages. While LLVM or WASM support is nice, most modern languages are not compiling to either one by default, and likely means it's not "turn key" to get your system running on Graal anyway.
      - samus 4y ago
        WASM support makes it possible to run code where there are native compilers for the language.
  - mukel 4y ago
    GraalVM team member here. Implementing any mainstream language is indeed a challenge, more so if you have to maintain bug-compatibility and cope with all the bits of bad design that went through the cracks in the de-facto implementation. Truffle is not for beginners, but knowing the basic set of features e.g. partial evaluation, deoptimization... can get you very far already e.g. you can easily speedup any interpreter by 10X or more with minimal changes. How long does take to implement a programming language? Well, from hours to years... depending on the language. To make my point; how long would it take to implement a JVM? A JVM is a complex beast, so I would myself guess from years to a decade probably, what if I told you, that Espresso was written in just 6 months by an intern and a seasoned engineer... in just 6 months it was able to Minecraft and even run itself. I assure you there's no magic here, and certainly no blinding talent either; the only reason for this unheard productivity was Graal/Truffle. So, whenever I talk about Espresso I always give all credit to Graal/Truffle, it is a sublime platform for implementing fast languages and runtimes, of which Espresso is just a byproduct.
threeseed 4y ago
> building and deploying Function/Serverless and Microservices most For those you may be better with IBM OpenJ9: https://www.eclipse.org/openj9/ https://www.eclipse.org/openj9/ It also integrates with CRIU so you can almost instantly start/stop the JVM: https://blog.openj9.org/2022/09/26/getting-started-with-openj9-criu-support/ https://blog.openj9.org/2022/09/26/getting-started-with-open...
- mdaniel 4y ago
  I keep forgetting about J9 but they're not doing themselves any branding favors since there actually is J17 on J9 :-/ https://github.com/eclipse-openj9/openj9/blob/openj9-0.35.0/doc/build-instructions/Build_Instructions_V17.md#building-openjdk-version-17-with-openj9 https://github.com/eclipse-openj9/openj9/blob/openj9-0.35.0/... (Also that 0.35 versioning ...) As best I can tell, these are the docker images: https://hub.docker.com/_/ibm-semeru-runtimes https://hub.docker.com/_/ibm-semeru-runtimes $ docker run --rm ibm-semeru-runtimes:open-11-jdk java -version openjdk version "11.0.17" 2022-10-18 IBM Semeru Runtime Open Edition 11.0.17.0 (build 11.0.17+8) Eclipse OpenJ9 VM 11.0.17.0 (build openj9-0.35.0, JRE 11 Linux amd64-64-Bit Compressed References 20221031_559 (JIT enabled, AOT enabled) OpenJ9 - e04a7f6c1 OMR - 85a21674f JCL - a94c231303 based on jdk-11.0.17+8)
- vips7L 4y ago
  The phoronix benchmarks seem to imply that J9 performs worse overall. https://www.phoronix.com/review/java-openjdk-mid22 https://www.phoronix.com/review/java-openjdk-mid22

aseipp 4y ago

GraalVM is a bunch of components, but the most important one are 1) Graal, a library in Java that is a code generator and optimizer for compiler authors, 2) Native Image, a tool which turns Java programs into native executables via Graal, and 3) Truffle, a tool for implementing languages in Java that then get code generated, again by Graal "GraalVM" is the umbrella name of all these things packaged together, together with a couple languages implemented in Truffle. That's what you download when you go to the website. Galahad is a proposal to merge the Graal code generator library in Java, into OpenJDK's codebase, so that it is developed in tandem and comes with first-class support. And none of the other things, for now (Native Image will come later.) But you can also do this today: you can instead configure a stable LTS release of Java to use Graal as the code generator for the HotSpot VM, as an alternative to C2. It's a little bit of work to do so, but you can use any compliant OpenJDK build and test it out. Galahad will just make this an "out of the box" option rather than having to get Graal from Maven or whatever. So, you can just test things incrementally and see if Graal gives performance improvements over C2. You don't need to throw out your whole existing JVM, it's mostly just a new maven dependency. That's a much simpler and more targeted change, if you haven't given it a try (mostly by fiddling with some JVM -XX flags, as usual.)

hrpnk 4y ago

The challenge with GraalVM runtime is that there are differences in licensing. What was great about Java is that only for specialized use cases, one had to invest in a paid runtime. GraalVM moves essential features known from Java Runtime into an Enterprise Edition. From GraalVM docs [1] on memory management: "The G1 GC (only available with GraalVM Enterprise Edition) is a multi-threaded GC that is optimized to reduce stop-the-world pauses and therefore improve latency, while achieving high throughput. Currently, G1 can only be used in native images that are built on Linux for AMD64." [1] https://www.graalvm.org/22.2/reference-manual/native-image/optimizations-and-performance/MemoryManagement/ https://www.graalvm.org/22.2/reference-manual/native-image/o...

kaba0 4y ago
That particular one (and most differences) are only related to native image generation, not to Graal, as a JIT compiler.
actuallyalys 4y ago
I think tweaking the garbage collector when running on native is a specialized use case. Anecdotally, the projects using native image I'm aware of don't tweak the garbage collector settings that are available in the community version at all. If throughput is critical enough to warrant garbage collector fine tuning, there's a decent chance you'll run it on a VM anyway. Of course, there are exceptions, but I don't think this is a limitation for most projects. That being said, most of the JVM projects I'm very familiar are written in Clojure, so they may well be outliers compared to Java or other JVM languages.

thangalin 4y ago

It'll help build cross-platform desktop applications. In theory, it'll streamline using GitHub Actions to produce platform-specific binaries, such as my FOSS Markdown editor KeenWrite[0], without having to have a copy of every target operating system. To my knowledge, cross-compiling "native" Linux and Windows binaries using Java requires duct tape, chewing gum, and warp-packer.[1][2] If there's another way to cross-compile a Java application into a standalone binary for multiple target platforms, do tell! GraalVM isn't a panacea. For example, GraalVM cannot compile Renjin[3], a pure Java R interpreter, which means switching from Renjin to FastR. Not trivial. Other sinkholes likely lurk that'll only reveal themselves when walking through the weeds. [0]: https://github.com/DaveJarvis/keenwrite https://github.com/DaveJarvis/keenwrite [1]: https://dave.autonoma.ca/blog/2020/06/29/write-once-build-anywhere/ https://dave.autonoma.ca/blog/2020/06/29/write-once-build-an... [2]: https://github.com/dgiagio/warp https://github.com/dgiagio/warp [3]: https://github.com/bedatadriven/renjin/issues/564 https://github.com/bedatadriven/renjin/issues/564

anentropic 4y ago
I'm actually wanting to do this with Graal at the moment ("using GitHub Actions to produce platform-specific binaries") As far as I can tell Graal does not have cross-compilation ability currently (there is an open issue here: https://github.com/oracle/graal/issues/407 https://github.com/oracle/graal/issues/407)