5 ms·

> Graal was included in HotSpot-based Java VM releases like OpenJDK from Java 9 through 15, but was removed in Java 16 for lack of use. From wikipedia [0]. Wh

> Graal was included in HotSpot-based Java VM releases like OpenJDK from Java 9 through 15, but was removed in Java 16 for lack of use. From wikipedia [0]. What's the deal with GraalVM today? I guess Oracle is still keeping it alive since this is a post by an Oracle team. Does it have a future or is it going to be abandoned or what is the plan? [0] https://en.wikipedia.org/wiki/GraalVM#:~:text=The%20GraalVM%20compiler%20was%20started,16%20for%20lack%20of%20use https://en.wikipedia.org/wiki/GraalVM#:~:text=The%20GraalVM%....

papercrane 5y ago
GraalVM has always been built and maintained outside of the OpenJDK. Staring with Java 9 Oracle started including it with OpenJDK to provide AOT compilation, but as the article says, it wasn't widely adopted by OpenJDK users. Most people who wanted AOT would use GraalVM directly, so for most people nothings changed. Those that did use the OpenJDK AOT will have to migrate to using GraalVM's tooling post Java 15.
- kaba0 5y ago
  To my knowledge, another reason for the exclusion of Graal from OpenJDK was the different release cycle of development.
- The_rationalist 5y ago
chrisseaton 5y ago
I’m not sure including it in OpenJDK was ever a major goal, so removing it wasn’t the setback I think you’re mistaking it for.
- eatonphil 5y ago
  Yeah could be. I was just thinking that organizationally being part of OpenJDK sounds like a big thing and pulling back from that sounds like a reversal of a big thing. I'm sure the team wasn't extremely happy about it.
  - chrisseaton 5y ago
    I don’t recall anyone even having an opinion about it to be honest - we didn’t put it in in the first place.
    - eatonphil 5y ago
      Ok then! :)
  - mike_hearn 5y ago
    That move was much more reflective of the organizational politics inside Oracle as much as the tech itself. Graal turned into a separate (some might say competing) implementation of the Java platform, with its own unique vision and entirely separate teams, rather than simply feeding code into OpenJDK via its own processes. Swapping out a part of a JVM as critical as the JIT compiler with a from-scratch rewrite would be a tremendously difficult and risky project even if the rewrite was done by the exact same team. Doing it when the rewrite is in a different language, all the knowledge is in a different team, in a different part of the company organizationally, in different offices and parts of the world, and also their implementation strategy to eliminate performance drops involves a completely different JVM implementation (SVM-in-HotSpot) ... well, the maintenance, budgetary and training complexities of that alone make it a tough one to digest. I'm very hopeful they'll eventually figure out a path forward. It doesn't make much sense for Oracle to maintain three different JIT compilers (C1, C2, Graal). The biggest sticking point technically is probably the need to use native-image to produce libgraal. It'd be kinda weird for OpenJDK/HotSpot to ship two different JVMs, one that's used to implement the other. If they can find a way to AOT compile libgraal with acceptable performance, without a reliance on native-image, that'd probably be a good next step.
deleted 5y ago
[deleted]
kaba0 5y ago
As mentioned by sibling poster, it really is not a setback, they just have different release schedules. Graal is doing pretty well, it is heavily used by Twitter for example. And the polyglot part is simply completely novel and very exciting - it can basically optimize across language boundaries with it. A python call to a C function might get inlined and be much faster than native FFI. Enterprise edition also has managed mode for LLVM bitcode, making for example existing C code use managed heap for allocations. TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin and the JS runtime developed by comparatively few people (compared to V8 and the like) can achieve similar performance to it.
- rufugee 5y ago
  TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin This is interesting to me as someone working on a Rails app currently. I'm surprised it hasn't become the defacto ruby implementation given the benchmarks shown on the site. What are the drawbacks? Just Oracle ownership? Or does it require an enterprise subscription?
  - d3nj4l 5y ago
    This is partly covered in the GitHub Readme of TruffleRuby: TruffleRuby can run Rails and is compatible with many gems, including C extensions. However, TruffleRuby is not 100% compatible with MRI 3.0 yet. Please report any compatibility issues you might find. TruffleRuby passes around 97% of ruby/spec, more than any other alternative Ruby implementation. TruffleRuby might not be fast yet on Rails applications and large programs. Notably, large programs currently take a long time to warmup on TruffleRuby and this is something the TruffleRuby team is currently working on. Large programs often involve more performance-critical code so there is a higher chance of hitting an area of TruffleRuby which has not been optimized yet. However, I think this is slightly outdated, because I vaguely remember a talk from one of the rubycons about Rails being slightly faster with truffle. I can't say for sure why it's not been widely picked up yet; maybe other players are looking forward to JITs within Ruby itself, or don't like the two tier model of GraalVM (you can run it for free, but it also has an enterprise version with additional performance improvements.)
KMag 5y ago
20 years ago, I was a lurker on the JikesRVM (IBM's research project building a JVM in Java) mailing list. JikesRVM is still around, but not terribly active last I checked. Oracle is quite late to the game, and I'm just generally sad that Oracle ended up owning Java instead of IBM (or perhaps Google, but my trust in Google seems to be monotonically decreasing). Last I checked, Oracle's AoT compiler threw away any metadata necessary for HotSpot to be able to trace its way trough the native code, so if your AoT-compiled code was part of a hot loop, HotSpot wouldn't be able to perform any inlining or other runtime optimizations of your code. It seems like fixing this would be a first step to having a high performance JVM written in Java with start-up/warm-up time comparable to a JVM written in C++. While we're at it, Erlang/Elixir/BEAM's NIFs seem the right way to implement native code extensions to your VM. You write implementations in your language that get replaced with native versions if the native library is successfully loaded. Maybe your non-native implementation is just a stub that throws if it's called. With a few lines at the top of your module, you can attempt to load one or more native libraries and handle/ignore any errors. This makes it much easier to gracefully degrade if a particular native library isn't available on the local machine (or even available for the platform). It's a real pain to fall back to a Java implementation if the JNI implementation isn't available for any reason.
- pjmlp 5y ago
  It was Oracle that turned the MaximeVM research project into GraalVM, bringing it outside of the research lab. IBM would have killed it instead, J9 already provides AOT and JIT caches, almost a decade older before such capabilities landed on OpenJDK.
  - lvh 5y ago
    Point of order since native-image is a party piece for Graal: AOT is more in the sense of JIT (but, well, ahead of time) than a self-standing binary a la native-image, right?
    - pjmlp 5y ago
      GraalVM uses its JIT infrastructure for AOT compilation, but it is still AOT, nee SubstrateVM. Or do you mean J9? It grew out of the Metromone project for embedded deployment. https://researcher.watson.ibm.com/researcher/view_group.php?id=174 https://researcher.watson.ibm.com/researcher/view_group.php?...

papercrane 5y ago

GraalVM has always been built and maintained outside of the OpenJDK. Staring with Java 9 Oracle started including it with OpenJDK to provide AOT compilation, but as the article says, it wasn't widely adopted by OpenJDK users. Most people who wanted AOT would use GraalVM directly, so for most people nothings changed. Those that did use the OpenJDK AOT will have to migrate to using GraalVM's tooling post Java 15.

kaba0 5y ago
To my knowledge, another reason for the exclusion of Graal from OpenJDK was the different release cycle of development.
The_rationalist 5y ago

chrisseaton 5y ago

I’m not sure including it in OpenJDK was ever a major goal, so removing it wasn’t the setback I think you’re mistaking it for.

eatonphil 5y ago
Yeah could be. I was just thinking that organizationally being part of OpenJDK sounds like a big thing and pulling back from that sounds like a reversal of a big thing. I'm sure the team wasn't extremely happy about it.
- chrisseaton 5y ago
  I don’t recall anyone even having an opinion about it to be honest - we didn’t put it in in the first place.
  - eatonphil 5y ago
    Ok then! :)
- mike_hearn 5y ago
  That move was much more reflective of the organizational politics inside Oracle as much as the tech itself. Graal turned into a separate (some might say competing) implementation of the Java platform, with its own unique vision and entirely separate teams, rather than simply feeding code into OpenJDK via its own processes. Swapping out a part of a JVM as critical as the JIT compiler with a from-scratch rewrite would be a tremendously difficult and risky project even if the rewrite was done by the exact same team. Doing it when the rewrite is in a different language, all the knowledge is in a different team, in a different part of the company organizationally, in different offices and parts of the world, and also their implementation strategy to eliminate performance drops involves a completely different JVM implementation (SVM-in-HotSpot) ... well, the maintenance, budgetary and training complexities of that alone make it a tough one to digest. I'm very hopeful they'll eventually figure out a path forward. It doesn't make much sense for Oracle to maintain three different JIT compilers (C1, C2, Graal). The biggest sticking point technically is probably the need to use native-image to produce libgraal. It'd be kinda weird for OpenJDK/HotSpot to ship two different JVMs, one that's used to implement the other. If they can find a way to AOT compile libgraal with acceptable performance, without a reliance on native-image, that'd probably be a good next step.

deleted 5y ago

[deleted]

kaba0 5y ago

As mentioned by sibling poster, it really is not a setback, they just have different release schedules. Graal is doing pretty well, it is heavily used by Twitter for example. And the polyglot part is simply completely novel and very exciting - it can basically optimize across language boundaries with it. A python call to a C function might get inlined and be much faster than native FFI. Enterprise edition also has managed mode for LLVM bitcode, making for example existing C code use managed heap for allocations. TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin and the JS runtime developed by comparatively few people (compared to V8 and the like) can achieve similar performance to it.

rufugee 5y ago
TruffleRuby, Graal’s ruby implementation is the fastest ruby runtime by a huge margin This is interesting to me as someone working on a Rails app currently. I'm surprised it hasn't become the defacto ruby implementation given the benchmarks shown on the site. What are the drawbacks? Just Oracle ownership? Or does it require an enterprise subscription?
- d3nj4l 5y ago
  This is partly covered in the GitHub Readme of TruffleRuby: TruffleRuby can run Rails and is compatible with many gems, including C extensions. However, TruffleRuby is not 100% compatible with MRI 3.0 yet. Please report any compatibility issues you might find. TruffleRuby passes around 97% of ruby/spec, more than any other alternative Ruby implementation. TruffleRuby might not be fast yet on Rails applications and large programs. Notably, large programs currently take a long time to warmup on TruffleRuby and this is something the TruffleRuby team is currently working on. Large programs often involve more performance-critical code so there is a higher chance of hitting an area of TruffleRuby which has not been optimized yet. However, I think this is slightly outdated, because I vaguely remember a talk from one of the rubycons about Rails being slightly faster with truffle. I can't say for sure why it's not been widely picked up yet; maybe other players are looking forward to JITs within Ruby itself, or don't like the two tier model of GraalVM (you can run it for free, but it also has an enterprise version with additional performance improvements.)

KMag 5y ago

20 years ago, I was a lurker on the JikesRVM (IBM's research project building a JVM in Java) mailing list. JikesRVM is still around, but not terribly active last I checked. Oracle is quite late to the game, and I'm just generally sad that Oracle ended up owning Java instead of IBM (or perhaps Google, but my trust in Google seems to be monotonically decreasing). Last I checked, Oracle's AoT compiler threw away any metadata necessary for HotSpot to be able to trace its way trough the native code, so if your AoT-compiled code was part of a hot loop, HotSpot wouldn't be able to perform any inlining or other runtime optimizations of your code. It seems like fixing this would be a first step to having a high performance JVM written in Java with start-up/warm-up time comparable to a JVM written in C++. While we're at it, Erlang/Elixir/BEAM's NIFs seem the right way to implement native code extensions to your VM. You write implementations in your language that get replaced with native versions if the native library is successfully loaded. Maybe your non-native implementation is just a stub that throws if it's called. With a few lines at the top of your module, you can attempt to load one or more native libraries and handle/ignore any errors. This makes it much easier to gracefully degrade if a particular native library isn't available on the local machine (or even available for the platform). It's a real pain to fall back to a Java implementation if the JNI implementation isn't available for any reason.

pjmlp 5y ago
It was Oracle that turned the MaximeVM research project into GraalVM, bringing it outside of the research lab. IBM would have killed it instead, J9 already provides AOT and JIT caches, almost a decade older before such capabilities landed on OpenJDK.
- lvh 5y ago
  Point of order since native-image is a party piece for Graal: AOT is more in the sense of JIT (but, well, ahead of time) than a self-standing binary a la native-image, right?
  - pjmlp 5y ago
    GraalVM uses its JIT infrastructure for AOT compilation, but it is still AOT, nee SubstrateVM. Or do you mean J9? It grew out of the Metromone project for embedded deployment. https://researcher.watson.ibm.com/researcher/view_group.php?id=174 https://researcher.watson.ibm.com/researcher/view_group.php?...