10 ms·

GraalVM 22.1: Developer experience improvements, Apple Silicon builds, and more

190 points by fniephaus 4y ago

eatonphil 4y ago
> 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 4y 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 4y ago
    To my knowledge, another reason for the exclusion of Graal from OpenJDK was the different release cycle of development.
  - The_rationalist 4y ago
- chrisseaton 4y 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 4y 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 4y 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 4y ago
        Ok then! :)
    - mike_hearn 4y 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 4y ago
  [deleted]
- kaba0 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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?...
zorr 4y ago
GraalVM is interesting technology. I've been playing a little bit with native-image in a Kotlin project and it allows me to build native binaries from my Kotlin code. With support for a lot of the existing java/kotlin library ecosystem. The binaries are a bit large (10MB for a Kotlin hello world) but they are fast. I'll be using this for some personal cli tools since Kotlin+Maven is my personal 10x platform. Besides cli projects I've also done some experimentation with GUI and database stuff. Using the Gluon plugin GraalVM is able to compile a native binary for a JavaFX app that talks to a Sqlite database. When using a library that relies on reflection there might be some graalvm config to fiddle with but mostly it just works, and some of the libraries are already "native-image ready" with the necessary config inside the published package.
- 0x500x79 4y ago
  Have you tried taking a look at UPX for the binary size? I found that it significantly decreased the size of the binary to the point where the problem was more the size of my dependencies (large JARs that could not be optimized away) and could get the binary to a completely manageable place. They aren't C small, but they were definitely better than traditional Java apps by an order of magnitude.
  - eatonphil 4y ago
    UPX doesn't play nice with antivirus software if it's important for you to run on Windows (at least). https://github.com/upx/upx/issues/337 https://github.com/upx/upx/issues/337
  - zorr 4y ago
    I had not heard of UPX until just now and just did a quick test. With `-7` level it brings the 10MB binary down to 3.6MB but execution time was roughly x10.
    - 0x500x79 4y ago
      I haven't touched this in a long-while, but I believe startup will be impacted but post startup the impact should be smaller once the binary has been loaded. It depends on how your executable is used of course, but a hello world application will show the worst performance degredation since the code is loaded then executed once.
mark_l_watson 4y ago
My world revolves around Common Lisp (with Python for deep learning), but Clojure is also an important language to me because of both professional use and I wrote a Clojure AI book. What is the Graalvm + Clojure situation? A quick web search shows some use cases. I find the idea of using high programmer-efficient Lisp languages and then building small and fast native applications to be compelling. That said, LispWorks, SBCL, and Allegro CL are all good for building standalone apps.
- zorr 4y ago
  If you have a clojure project that builds to a single .jar file at hand, you can give it a quick shot using the native-image command from the GraalVM. If you're not using reflection-heavy libraries chances are it will just work and spit out a binary.
  - mark_l_watson 4y ago
    Wonderful, thanks.
- kaba0 4y ago
  It can compile Clojure to native executables but do note that Graal’s AOT part doesn’t promise better performance, just faster startup time and reduced memory usage. Using JIT compilers for long running processes (either the usual OpenJDK’s hotspot or Graal’s JIT compiler) will very likely beat the AOT compiled version for long running processes.
  - pjmlp 4y ago
    GraalVM AOT also accepts PGO.
    - eklavya 4y ago
      Can you please share your experience with PGO? I would be interested in some rough performance ballpark numbers for JVM languages.
tiffanyh 4y ago
I've always wondered if the perf silver bullet for Rails would be Graal/Tuffle.
- adamgordonbell 4y ago
  It doesn't seem like it. I think the newly added Ruby jit that you can optionally turn on is faster than Graal with a lot less startup time.
  - chrisseaton 4y ago
    > the newly added Ruby jit that you can optionally turn on is faster than Graal No TruffleRuby is still very much faster than any other Ruby JIT. YJIT does startup faster yes that's the goal. https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yjit-jruby-truffleruby.html https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...
    - tiffanyh 4y ago
      Hi Chris Do you see by the end of 2022, Rails being able to run on TruffleRuby?
      - chrisseaton 4y ago
        I think you can run Rails on TruffleRuby, but probably not your Rails application. We're working hard on it, both at Oracle and Shopify.
        tiffanyh 4y ago
        Just FYI - I don't know if your response was intended to deflect on an eta but some might perceive it as that since you didn't indicate if 2022 would be the year. Which might imply to some that it's not.
        chrisseaton 4y ago
didibus 4y ago
Anyone uses one of the Truffle languages in production? Like any Ruby or Python users are deploying on Graal's TrufflePython or TruffleRuby?
- The_rationalist 4y ago
  yes shopify runs on truffleruby. It is the fastest ruby VM by far and can seamlessly call state of the art Java libraries. GraalVM is the VM to rule them all and unify currently incompatible billions of dollars libraries ecosystems. Despite being the computer science breakthrough of the decade, people are not getting it yet.
  - byroot 4y ago
    > yes shopify runs on truffleruby That's incorrect.
    - The_rationalist 4y ago
  - ksec 4y ago
    Shopify does not run on TruffleRuby.
    - rufugee 4y ago
      If not...then why? If TruffleRuby is such a boost to performance...
      - ksec 4y ago
        >If TruffleRuby is such a boost to performance... TruffleRuby doesn't run complex Rails App yet. That is still a goal / target.
        The_rationalist 4y ago
rishav_sharan 4y ago
I tried Graal/Truffle last year, to make a toy language of my own. Unfortunately the state of documentation and tutorials was simply not good enough and I had to give up on it. I think for someone who is a Java/Graal enthusiast, Truffle documentation may be enough, but for someone like me who knows just the basics of Java and its ecosystem, the Truffle language implementation docs seemed woefully inadequate. Its a shame though, for what I did understand of Truffle seemed very interesting. I do plan on trying truffle yet again in a few years, when hopefully the community size and the state of the documentation have improved.
- fniephaus 4y ago
  Do you have any feedback on how we could improve the docs? If so, please let us know. I believe the easiest way to start a new Truffle language implementation is to fork SimpleLanguage [1] and turn it into your language. Did you try to do that? [1] https://github.com/graalvm/simplelanguage https://github.com/graalvm/simplelanguage
  - rishav_sharan 4y ago
    Yes please. My major blockers were - 1. Starting post ast generation was an abrupt start. An end to end tutorial - from parsing to working compiler for a tiny language like Lua, Lox, Wren etc would be very helpful. You need not deep dive into the parsing part - just give enough that we can follow along. Another option can be to continue an existing tutorial series like Lox from "crafting interpreters". That way you don't have to focus on parts which are not Truffle specific, yet users can follow along. 2. Just going through existing Java code of the Simple Language was extremely difficult for a newbie to Java, like me. I would much prefer a readable tutorial which explains all concepts in more details 3. More language examples please. As I said before, if possible do add a couple more languages like Lua. I believe Lua is already a Truffle language. Just an accompanying tutorial is missing. I remember when I tried to read through the codes of Ruby, Lua and simple language, they all started off very differently and I just got lost.
    - deleted 4y ago
      [deleted]
smasher164 4y ago
I think Project Loom support will open up green thread support for more Truffle-based languages. I could see Go, Haskell, Erlang, Scheme, and Concurrent ML -style languages taking advantage of that infrastructure. I'm also hoping for official support for static linking. Right now, it's an undocumented feature done through the Feature API.
exabrial 4y ago
If you love GraalVM, and very small app sizes, and get a nice dependency injection framework to break your code up into testable modules, be sure to check out https://quarkus.io https://quarkus.io . Be sure to scroll down to the memory and start time benchmarks :)
- flakiness 4y ago
  Cool! I vaguely remember about Microanus framework being in the similar area, there are also a couple more others (I don't remember the name.) How do these Graal native-ish frameworks compare? Or more broadly, what does the scene look like today?
  - lf-non 4y ago
    Micronaut (from Grails developers) was an early Graal adopter and is very actively developed and has a growing ecosystem around it. However, Quarkus has many distinguishing features beyond a nice dependency injection framework. First of all it is a Microprofile implementation - Microprofile is a collaborative effort among many large companies to adapt and evolve pieces of enterprise java stack to microservices. So large parts of your application would depend on Microprofile API rather than APIs specific to a particular framework like Quarkus and will be portable across Microprofile implementations (like Helidon or OpenLiberty) - for smaller individual services the benefits are minimal but it is a major advantage for larger corporations putting in decade long investments. Also, Quarkus is built atop vert.x which provides a non blocking event-loop and actor(-like) framework for JVM. Developers can choose to not bother with vert.x at all and use the MP apis exclusively but for people who like the actor-oriented programming model can choose to take advantage of it (perhaps for specific use cases). Lastly, as can be expected because it is by Redhat, there is out of the box integration with Hibernate. Regarding the scene, Spring is also pushing into the Graal ecosystem with native features - but they are still a bit late to party. They do have a huge ecosystem to support and can't afford breaking changes so it is understandable that good spring support for Graal is an evolving multi-year effort. But it does mean that early adopters like Micronaut and Quarkus have an edge. Also, irrespective of how well mainstream adoption for Graal pans out, I am quite happy about the growing initiative to move start-time work to build time which improves start times for non-graal deployments too.

190 points by fniephaus 4y ago

> 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 4y 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 4y ago
  To my knowledge, another reason for the exclusion of Graal from OpenJDK was the different release cycle of development.
- The_rationalist 4y ago
chrisseaton 4y 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 4y 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 4y 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 4y ago
      Ok then! :)
  - mike_hearn 4y 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 4y ago
[deleted]
kaba0 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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?...

zorr 4y ago

GraalVM is interesting technology. I've been playing a little bit with native-image in a Kotlin project and it allows me to build native binaries from my Kotlin code. With support for a lot of the existing java/kotlin library ecosystem. The binaries are a bit large (10MB for a Kotlin hello world) but they are fast. I'll be using this for some personal cli tools since Kotlin+Maven is my personal 10x platform. Besides cli projects I've also done some experimentation with GUI and database stuff. Using the Gluon plugin GraalVM is able to compile a native binary for a JavaFX app that talks to a Sqlite database. When using a library that relies on reflection there might be some graalvm config to fiddle with but mostly it just works, and some of the libraries are already "native-image ready" with the necessary config inside the published package.

0x500x79 4y ago
Have you tried taking a look at UPX for the binary size? I found that it significantly decreased the size of the binary to the point where the problem was more the size of my dependencies (large JARs that could not be optimized away) and could get the binary to a completely manageable place. They aren't C small, but they were definitely better than traditional Java apps by an order of magnitude.
- eatonphil 4y ago
  UPX doesn't play nice with antivirus software if it's important for you to run on Windows (at least). https://github.com/upx/upx/issues/337 https://github.com/upx/upx/issues/337
- zorr 4y ago
  I had not heard of UPX until just now and just did a quick test. With `-7` level it brings the 10MB binary down to 3.6MB but execution time was roughly x10.
  - 0x500x79 4y ago
    I haven't touched this in a long-while, but I believe startup will be impacted but post startup the impact should be smaller once the binary has been loaded. It depends on how your executable is used of course, but a hello world application will show the worst performance degredation since the code is loaded then executed once.

mark_l_watson 4y ago

My world revolves around Common Lisp (with Python for deep learning), but Clojure is also an important language to me because of both professional use and I wrote a Clojure AI book. What is the Graalvm + Clojure situation? A quick web search shows some use cases. I find the idea of using high programmer-efficient Lisp languages and then building small and fast native applications to be compelling. That said, LispWorks, SBCL, and Allegro CL are all good for building standalone apps.

zorr 4y ago
If you have a clojure project that builds to a single .jar file at hand, you can give it a quick shot using the native-image command from the GraalVM. If you're not using reflection-heavy libraries chances are it will just work and spit out a binary.
- mark_l_watson 4y ago
  Wonderful, thanks.
kaba0 4y ago
It can compile Clojure to native executables but do note that Graal’s AOT part doesn’t promise better performance, just faster startup time and reduced memory usage. Using JIT compilers for long running processes (either the usual OpenJDK’s hotspot or Graal’s JIT compiler) will very likely beat the AOT compiled version for long running processes.
- pjmlp 4y ago
  GraalVM AOT also accepts PGO.
  - eklavya 4y ago
    Can you please share your experience with PGO? I would be interested in some rough performance ballpark numbers for JVM languages.

tiffanyh 4y ago

I've always wondered if the perf silver bullet for Rails would be Graal/Tuffle.

adamgordonbell 4y ago
It doesn't seem like it. I think the newly added Ruby jit that you can optionally turn on is faster than Graal with a lot less startup time.
- chrisseaton 4y ago
  > the newly added Ruby jit that you can optionally turn on is faster than Graal No TruffleRuby is still very much faster than any other Ruby JIT. YJIT does startup faster yes that's the goal. https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yjit-jruby-truffleruby.html https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...
  - tiffanyh 4y ago
    Hi Chris Do you see by the end of 2022, Rails being able to run on TruffleRuby?
    - chrisseaton 4y ago
      I think you can run Rails on TruffleRuby, but probably not your Rails application. We're working hard on it, both at Oracle and Shopify.
      - tiffanyh 4y ago
        Just FYI - I don't know if your response was intended to deflect on an eta but some might perceive it as that since you didn't indicate if 2022 would be the year. Which might imply to some that it's not.
        chrisseaton 4y ago

didibus 4y ago

Anyone uses one of the Truffle languages in production? Like any Ruby or Python users are deploying on Graal's TrufflePython or TruffleRuby?

The_rationalist 4y ago
yes shopify runs on truffleruby. It is the fastest ruby VM by far and can seamlessly call state of the art Java libraries. GraalVM is the VM to rule them all and unify currently incompatible billions of dollars libraries ecosystems. Despite being the computer science breakthrough of the decade, people are not getting it yet.
- byroot 4y ago
  > yes shopify runs on truffleruby That's incorrect.
  - The_rationalist 4y ago
- ksec 4y ago
  Shopify does not run on TruffleRuby.
  - rufugee 4y ago
    If not...then why? If TruffleRuby is such a boost to performance...
    - ksec 4y ago
      >If TruffleRuby is such a boost to performance... TruffleRuby doesn't run complex Rails App yet. That is still a goal / target.
      - The_rationalist 4y ago

rishav_sharan 4y ago

I tried Graal/Truffle last year, to make a toy language of my own. Unfortunately the state of documentation and tutorials was simply not good enough and I had to give up on it. I think for someone who is a Java/Graal enthusiast, Truffle documentation may be enough, but for someone like me who knows just the basics of Java and its ecosystem, the Truffle language implementation docs seemed woefully inadequate. Its a shame though, for what I did understand of Truffle seemed very interesting. I do plan on trying truffle yet again in a few years, when hopefully the community size and the state of the documentation have improved.

fniephaus 4y ago
Do you have any feedback on how we could improve the docs? If so, please let us know. I believe the easiest way to start a new Truffle language implementation is to fork SimpleLanguage [1] and turn it into your language. Did you try to do that? [1] https://github.com/graalvm/simplelanguage https://github.com/graalvm/simplelanguage
- rishav_sharan 4y ago
  Yes please. My major blockers were - 1. Starting post ast generation was an abrupt start. An end to end tutorial - from parsing to working compiler for a tiny language like Lua, Lox, Wren etc would be very helpful. You need not deep dive into the parsing part - just give enough that we can follow along. Another option can be to continue an existing tutorial series like Lox from "crafting interpreters". That way you don't have to focus on parts which are not Truffle specific, yet users can follow along. 2. Just going through existing Java code of the Simple Language was extremely difficult for a newbie to Java, like me. I would much prefer a readable tutorial which explains all concepts in more details 3. More language examples please. As I said before, if possible do add a couple more languages like Lua. I believe Lua is already a Truffle language. Just an accompanying tutorial is missing. I remember when I tried to read through the codes of Ruby, Lua and simple language, they all started off very differently and I just got lost.
  - deleted 4y ago
    [deleted]

smasher164 4y ago

I think Project Loom support will open up green thread support for more Truffle-based languages. I could see Go, Haskell, Erlang, Scheme, and Concurrent ML -style languages taking advantage of that infrastructure. I'm also hoping for official support for static linking. Right now, it's an undocumented feature done through the Feature API.

exabrial 4y ago

If you love GraalVM, and very small app sizes, and get a nice dependency injection framework to break your code up into testable modules, be sure to check out https://quarkus.io https://quarkus.io . Be sure to scroll down to the memory and start time benchmarks :)

flakiness 4y ago
Cool! I vaguely remember about Microanus framework being in the similar area, there are also a couple more others (I don't remember the name.) How do these Graal native-ish frameworks compare? Or more broadly, what does the scene look like today?
- lf-non 4y ago
  Micronaut (from Grails developers) was an early Graal adopter and is very actively developed and has a growing ecosystem around it. However, Quarkus has many distinguishing features beyond a nice dependency injection framework. First of all it is a Microprofile implementation - Microprofile is a collaborative effort among many large companies to adapt and evolve pieces of enterprise java stack to microservices. So large parts of your application would depend on Microprofile API rather than APIs specific to a particular framework like Quarkus and will be portable across Microprofile implementations (like Helidon or OpenLiberty) - for smaller individual services the benefits are minimal but it is a major advantage for larger corporations putting in decade long investments. Also, Quarkus is built atop vert.x which provides a non blocking event-loop and actor(-like) framework for JVM. Developers can choose to not bother with vert.x at all and use the MP apis exclusively but for people who like the actor-oriented programming model can choose to take advantage of it (perhaps for specific use cases). Lastly, as can be expected because it is by Redhat, there is out of the box integration with Hibernate. Regarding the scene, Spring is also pushing into the Graal ecosystem with native features - but they are still a bit late to party. They do have a huge ecosystem to support and can't afford breaking changes so it is understandable that good spring support for Graal is an evolving multi-year effort. But it does mean that early adopters like Micronaut and Quarkus have an edge. Also, irrespective of how well mainstream adoption for Graal pans out, I am quite happy about the growing initiative to move start-time work to build time which improves start times for non-graal deployments too.