GraalVM for JDK 21


215 points | by fniephaus 252 days ago


  • mgdev 252 days ago
    GraalVM is a hugely under-appreciated piece of technology. A lot of my initial interest came from being able to blend different languages into a single runtime via the polyglot APIs, but the combination of performance, strong sandboxing support, and multi-language support has helped it emerge as a key primitive for anyone wishing to build extensible platforms without sacrificing speed, security, or developer ergonomics.
    • weinzierl 252 days ago
      It's fascinating technology, but in my opinion too little, too late.

      Compiling with GraalVM is still a pain and will not work out-of-the-box without modifications for any non-trivial project. This is mostly, I believe, not GraalVM's fault, because it can only do so much within the confines of the existing ecosystem.

      If only AoT compilation to native code would have been taken seriously from the start, if only gcj would have gotten more attention, we could have ended up with an ecosystem that is somewhat amenable to what GraalVM tries to do.

      As much as I like GraalVM and wish it success, my prediction is that in a few years it will be in the same state gcj has been quite some years now.

      • mike_hearn 252 days ago
        gcj had a lot of problems beyond needing configuration of reflection metadata. It used a full reimplementation of the standard library, and it was never adopted by the wider Java community being largely just Red Hat's strategy for creating a fully open source Java implementation rather than something offering specific benefits to Java developers. In particular people thought it'd lead to faster code, but GCC was never designed for Java and the results were actually a fair bit slower iirc.

        Native image is quite different. With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly. At a stroke this is resolving one of the biggest complaints people have always had against JVM languages.

        And as a consequence you're seeing adoption by the wider community. All the modern Java web frameworks support it now, and there's a metadata repository where it's collected for projects that haven't accepted it upstream yet [1].


        • logicchains 252 days ago
          >With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly

          Does this mean that once Project Valhalla lands, Java via Graal will be a viable competitor to C++ for tasks requiring extremely high performance?

          • mike_hearn 251 days ago
            Valhalla and the vector API for SIMD, yes. In theory, at that point, the only major performance difference between them would be GC vs manual memory management. Also: code size.

            One interesting experiment that'd be worth trying is generating value types that wrap memory segments, as that's the new manual memory allocation API. You can do pretty sophisticated manual allocation with arenas and stuff, but you can't allocate Java objects into those segments. What you can do though, is create a "struct" using VarHandles that you can cast the segment to which then reads/writes through to the segment. This leads to the question of whether you can make a nice wrapper around such value types that yield C++ style manual memory allocation.

          • soulbadguy 252 days ago
            Possible, but i don't think it's very likely. Project Valhalla is a big umbrella term but couple of important points :

            - The new value type don't garanty flat memory representation, so might have some corner cases which are not properly optimized

            - The monomorphization or java vs C++ is still a big advantage for c++

            - The compiler optimization of LLVM/GCC are still quite a bit better (in term of generated code) vs jvm/graal

            • mike_hearn 251 days ago
              I'm not sure any of those are actually quite right.

              Valhalla supports flattening, that's the whole point of it. To get that you need to have a type declared as a value type, and then put it into a non-null variable, field or parameter. At least that's how the current prototype works. If you do that then the compiler will fully inline the allocation into arrays, containing objects/structs, or the stack.

              Valhalla started with monomorphization prototypes, although that went silent years ago. I don't know if it'll be delivered in the first version. But, it's an intended goal of the project to deliver.

              As for the final point, could you evidence that? It's very hard to do direct comparisons here because they're usually compiling very different languages and Graal hasn't been optimized for C++. For example, Graal can compile many languages LLVM just doesn't even try to. Also, you'd really need to compare against the Oracle GraalVM (née GraalVM Enterprise) to see the best of what it can do. I'm curious what comparison you're thinking of when you say that, as Graal is an extremely advanced compiler by any measure.

            • pjmlp 251 days ago
              There are JVM implementations, like Azul, that use LLVM for their AOT/JIT compilers, so the last point isn't really a plus for C++.

              Java like C and C++, enjoys multiple implementations.

              Regarding monomorphization, it is still open how much Valhala will go into that front.

              Even if Java will never be as good as C++ in generics, there are several other issues that usually tend to have Java chosen for instead of C++, even if C++ wins in the microbenchmark games.

              Likewise most options for running Java on the GPU aren't as feature rich as C++, and that is certainly an area where C++ will be dominating in decades to come.

        • soulbadguy 252 days ago
          > With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory

          Source ?

      • aseipp 252 days ago
        I think the reality is that faster startup, smaller deployments, and lower memory usage is considered much more valuable today than it was when GCJ was an actively maintained project. It simply did not offer things people needed at that time. But now, the tradeoffs are different, and so the effort of going back and modifying existing code to support AOT compilation has a greater overall payoff than it did in the past, which is why people are pursuing it. It's the same reason .NET is adding full AOT support - because people want it now, and they want it now more than they did before.
      • atgreen 252 days ago
        I worked on gcj (and GNU Classpath) for a number of years. gcj's origins are in the embedded systems space, where our customers valued the small memory footprint and portability across processor architectures that were unlikely to get performant JITs. As we eased out of the embedded space, it was clear that jumping on the OpenJDK train was the right choice for Free Software-minded gcj/Classpath devs, as Sun adopted the GPL and GNU Classpath exception license. gcj was unlikely to ever catch up, and many of us were motivated by the idea of a Free Software Java solution, which Sun just handed to us.
      • shellac 252 days ago
        > [...] my prediction is that in a few years it will be in the same state gcj has been quite some years now.

        You make it sound like GraalVM is just for ahead-of-time compiling like gcj, but there's more to it than native image. It's possible GraalVM will be openjdk's jit compiler, for example.

        • switchbak 252 days ago
          This is one of my challenges with the branding of the project - it's not super clear to me what folks are talking about when they mention Graal related tech.

          That alone I think can muddy the waters and can even hurt adoption. I wish they had clear and meaningful names for the specific distinct pieces of tech (even if there is some shared underpinnings).

        • weinzierl 252 days ago
          Good point. It is fascinating technology, but to get development resources in the long run it needs management/sponsor attention and for that it needs a practical use case today. That, I think is AoT compilation and I believe that, unfortunately, it doesn't cut it there.
      • paulddraper 252 days ago
        > my prediction is that in a few years it will be in the same state gcj has been quite some years now

        I'll take that bet.

        GraalVM has only gotten more and more popular.

        There are a lot of situations (large server applications) that don't benefit much from AOT.

        But others do. Android is (partially) AOT.

      • jabradoodle 252 days ago
        Were talking enterprise java, it's a behamouth and changing it takes forever.

        I think in today's ecosystem of microservices and serverless etc, AOT will be taken pretty seriously.

        • adra 252 days ago
          Everything has a cost though. The one thing we lose is the ability for hotspot to change its mind and recompile code based on usage patterns I've toyed with graalvm for some uses and ended up with lost performance. Also a key note is that it only supports a pretty naive serialgc right now which is a big limitation. Bellsoft has a parallelgc which probably plays a little better, but we're always going to need to play trade-offs until they can support the more robust GC impls
          • hueho 252 days ago
            The serial GC is a limitation of the community (OSS) edition. The enterprise proprietary version has G1 support.

            I hope Oracle will let it drip it down to the CE, but it's their project, their monetization strategy.

            • grashalm 251 days ago
              With the new GFTC license, we hope G1 is much more accessible now.
          • kaba0 252 days ago
            You can try to use Graal as a JIT compiler as well, in case of Scala for example that has a bit more indirection on average it can cause some speedups.

            Otherwise, it trades blows with hotspot.

      • pjmlp 252 days ago
        It was taken seriously, as commercial 3rd party offering, from which PTC and Aicas are the surviving vendors.

        Also Android uses a mix of AOT and JIT since version 5.

      • emptysongglass 252 days ago
        As someone on the outside looking at GraalVM with curiosity, is it even possible to use something like Poetry to manage the Python part? Would you do that? Would I even need a venv anymore? Where would its edges be? What are the limits?

        How are we people practically putting this polyglot stuff into action?

      • pdntspa 252 days ago
        It would be really nice if it didn't shit the bed over Swing apps.

        Distributing a nonmodularized Java Swing app in 2023 is far more difficult than it should be.

    • foobarbazetc 252 days ago
      We use Graal to sandbox a scripting language based on EcmaScript 6 for our app.

      It’s great.

      • neeleshs 252 days ago
        Can you say more on this? We're trying to do something similar and curious to know more
    • doctorpangloss 252 days ago
      The NodeJS performance is really bad for many use cases, such as anything you do to build a web app. It has a long way to go in terms of becoming practical.
    • mlinksva 252 days ago looks very interesting though enterprise (not open source I assume?) only and maybe only for executing javascript? Or do I misunderstand, or is there other sandboxing support?
      • grashalm 252 days ago
        The Polyglot sandbox is licensed under GFTC:

        ISOLATED and UNTRUSTED require GFTC

        CONSTRAINED is also available under open-source licenses.

        Only for JavaScript right now. We are working hard on supporting all the other languages!

        Developer here. So, if you have more questions, let me know!

        • mlinksva 252 days ago
          Thanks for explaining and for your work!

          Not sure I have questions, just generally interested in making it easier/lighter weight/built-in to constrain ambient authority (for example, to mitigate supply chain risks), thus have it be done more.

          The Polyglot sandfox feels very loosely analogous to Deno per process (and thus subprocess) permissions, though it looks like ISOLATED and UNTRUSTED can limit a bunch of things not possible with Deno.

          • grashalm 252 days ago
            We do not do process isolation yet, although we have plans to implement that as well as a fallback strategy.

            The advantage of the native-image-isolate-based isolation is that it is much more lightweight. For example, calls from and to the host application are much faster. There is no copying or expensive synchronization necessary. The disadvantage is that we need to do our own protections against attacks, as the OS protections between processes don't apply to such isolates. By default, we deploy software/compiler-based protections but are also very close to supporting hardware like Intel MPK.

            If you have more questions, you can also drop by on Slack; we are a friendly bunch:

      • gavinray 252 days ago
        Many of the configuration settings set by a sandboxing policy are available when creating Polyglot contexts with the Community Edition.
        • MrPowerGamerBR 250 days ago
          Are you sure? I created a JavaScript Polyglot context in Java with GraalJS CE 21 and...

          > Exception in thread "main" Polyglot sandbox limits can only be used with runtimes that support enterprise extensions. The runtime 'GraalVM CE' does not support sandbox extensions.

  • tombert 252 days ago
    I've only done one project with GraalVM and I've been pretty happy with it in regards to faster startup time.

    I was doing stuff in Clojure. Clojure is a great language but it tends to have very slow startup times, even by JVM standards (it's not weird for a large Clojure program to take 5-6 seconds to start. Even a "hello world" can take upwards of a second or two). Graal mostly Just Worked with the standalone uberjar produced by Leiningen and created an executable that started in about 3 milliseconds. It was amazing.

    While the lack of proper reflection support was a little annoying, it actually wasn't as horrible with Clojure as you might think; most problems were fixed with basic type hinting, and all but one Clojure library I used (http-kit) worked flawlessly.

    • dig1 252 days ago
      The recurring problem I've seen that would cause slow startup is cramming many (require) and (import) in the project core.clj file - for non-clojure devs here, this means including a lot of dependencies in the file called on the startup.

      By reordering things to be loaded smartly or lazily, startup speed can be improved a lot.

      Another reason for a slow startup is that Clojure must load its own runtime every time. The current compiler is not a tree shaker, nor can it rewrite complex expressions in compile-time, although many clojure.core functions were rewritten over time to accommodate JVM optimizers. However, Graal is here precisely to do at the bytecode level, as long as you take care of all type hint warnings and avoid things Graal can't see during compilation (e.g. deferring evaluation of some expressions for runtime).

    • lispisok 252 days ago
      What are the applications where slow startup time is such a big issue?
      • tombert 252 days ago
        Without getting too involved with details (I was working for a certain company that doesn't like people talking in detail about anything I did there), I had a program that routinely started other processes. I was required to use Java or Clojure, and we had a sort of quasi-RPC thing that would spawn process on the shell, get a result, and return that result as a string. This application wasn't super performance-oriented, but it was enough to where a 5 second start time was untenable.
      • amelius 252 days ago
        Commandline tools?
      • Nihilartikel 252 days ago
        Serverless apps possibly.
  • gzalo 252 days ago
    We tried to use it to improve AWS lambda startup times but desisted as it was a pain to use it with an existing app. It required too many tweaks as there are waay too many things that rely on reflection :(

    Things that broke include: JSON (de)serialization using Jackson, validations using hibernate, validator, AWS SDK, and even simpler libs like picocli...

    It could be quite useful for a set of simpler apps though

    • AndyPa32 252 days ago
      Yes, Jackson really was a bummer. To this day I can't understand how a project like Springboot advertises Graalvm readiness when Jackson is not supported without tweaks. What do the Springboot devs think we are using Springboot for, Hello World blog posts?
      • JacobiX 252 days ago
        From my understanding, Spring Boot takes care of providing the JSON metadata for many libraries, including Jackson. So in practice, it can be more straightforward to use it in a Spring Boot project.
      • CrimsonRain 252 days ago
        What's wrong with it? Genuinely curious. I've using Graal with spring/Jackson for a long time and haven't noticed any issue.
    • jiehong 252 days ago
      Picocli allows using a compiler annotation processor to generate classes at compile time instead [0].


    • eddythompson80 252 days ago
      this was our experience as well. Both with GraalVM/Quarkus and .NET CrossGen/Native/CoreRT. It's almost a different platform that's far less supported and less stable. Even if you put in the work to make things work, they'll eventually break. Quarkus tries to give a full experience like Kotlin Native, but both are also not really there.

      It's really unfortunate how Java and C# are perceived as slow because of their painful startup time.

    • invalidname 251 days ago
      GraalVM has an agent you can use to run your project. It then generates the dependency file for you and you can then use that file to compile the native code.

      If you use a framework like Spring Boot then you don't even need that. Just upgrade to 3+ and Jackson, Hibernate (and maybe these other APIs) should pretty much work out of the box.

    • pharaohgeek 251 days ago
      Look at the Quarkus framework. It's designed with Graalvm native in mind, so it knows how to handle Jackson, AWS, etc. and compile them to a native binary. I'm using it in production with a native-compiled Lambda that calls other AWS services. It works GREAT!
    • wizwit999 252 days ago
      ye even less relevant for that usecase with snapstart.
      • wink 252 days ago
        SnapStart for Java 17 was only released very recently, so if you are a bit early in the cycle it doesn't help. Don't even want to guess when it will be available for Java 21.
  • uticus 252 days ago
    From 5 years ago, but still fascinating: Ten Things You Can Do With GraalVM by Chris Seaton

  • jcadam 252 days ago
    Seems like every time I try to use Graal - there's some dependency in my project that doesn't like it.
  • refset 252 days ago
    The linked sibling post on "New Truffle and GraalVM Languages release" feels rather exciting too


    > GraalVM language runtimes (for JavaScript, Python, Ruby, Java on Truffle, WebAssembly, and LLVM) can now be [...] installed as Maven/Gradle dependencies [...] which will work for GraalVM JDK and any other compatible JDK

    Polyglot experimentation just got a whole lot easier! Kudos to everyone involved in pushing the JVM ecosystem forwards.

  • jsight 252 days ago
    I just wish the compile times weren't so painfully slow. It makes it really difficult to work with.
    • kaba0 252 days ago
      You can generally develop with the JDK, and only compile from time to time.
  • alberth 252 days ago
    What’s the latest on Truffle/Ruby supporting Rails?

    Wouldn’t this provide massive gains for the Rails ecosystem once delivered?

    (And with the GraalVM licenses changes to be more favorable/permission, I have to imagine there would be significant adoption)

  • monlockandkey 252 days ago
    I am more interested in this proposal

    It is "Ahead of Time Compilation for the Java Virtual Machine". The proposal details of using AOT code at startup and then JIT taking over. So you get best of both worlds with fast application launch and then throughput once things are warmed up.

    Graal is cool, but it will not be as throughput performant compared to JIT. Only for fast startup, serverless or low memory environments.

    • kaba0 252 days ago
      Not sure if you are aware of it, but Graal is also a JVMCI-comparible JIT compiler.

      Also, there was a proposal (not yet JEP though) on condensers and that model could also make great use of GraalVM.

    • ezst 252 days ago
      The linked post shows the AoT compiler ahead of the JIT one, it seems like PGO really closes the gap :)
  • sgammon 252 days ago
    Congrats to the GraalVM team on all their hard work
  • the-alchemist 251 days ago
    I think the biggest improvement in GraalVM 21 is profile-guided optimizations (PGO) in both aarch64 and amd64.

    This means you can take full advantage of ARM cloud services like AWS Graviton (sp?) services for lower cost.

    Also, looks like the Java Vector API (JEP338) has been optimized.

    So, same code on your Raspberry Pi and AWS Graviton, cool.

  • Jumziey 252 days ago
    Lots of comments about issues with dependencies and Graal. I suggest looking into Quarkus. Have had great success with and mandrel (a patched version of Graal for Quarkus). Quarkus focuses on creating Web APIs so wont cover it all but if thats what you want to do its great and builds native images quite easily.
  • Alifatisk 252 days ago
    I've slowly been keeping myself updated regarding GraalVM, I think Oracle is on to something here.
  • pregnenolone 252 days ago
    I use Graal Native to AOT compile my JavaFX applications. It works surprisingly well.
    • foooobaba 252 days ago
      I was considering this, working on a new javafx app for a side project. Using java 17, and generating binaries with fxlauncher/jpackage/wix is not working great imo. Any good recommendations on tooling for using the graal route? I develop on linux but most users will be on windows. It would be great to not have to use windows vm for building the binaries (but i can if needed ofcourse).
      • pregnenolone 252 days ago
        What trouble are you having with jpackage? It's easy. Anyway, in order to AOT compile your JavaFX compilation you will have to run(or test) your application with Graal's tracing agent to collect the metadata and then compile it. You can use Graal's native plugins for Gradle or Maven.
      • mike_hearn 251 days ago
        Take a look at, it supports JavaFX apps and can build Windows/Mac packages from Linux.

        It can't do native images from those though.

  • sgammon 252 days ago
    it’s time to do a barrel roll
    • sgammon 252 days ago
      why on earth was this downvoted. im excited for them
  • amelius 252 days ago
    Warning: Graal is owned by a law-firm called Oracle (that happens to employ some programmers too).
    • mwcampbell 252 days ago
      Who is actually at risk of falling victim to Oracle's infamous licensing shakedowns, though? And how bad are they actually?
    • sgammon 252 days ago
      they opened up the license...
      • cxr 251 days ago
        Sun themselves (not Oracle) also "opened up" their Java implementation as GPL 15 years ago. It didn't stop Oracle spending years sowing their own uncertainty and doubt and trying to claim billions of dollars in damages from Google in a lawsuit where McNealy sat on the stand and testified that the GPL licensing didn't allow commercial use.
  • Kingpin007 252 days ago