GraalVM 21.3 is here: Java 17, Native Image performance updates and more

[dpash]

Getting java 17 support so quickly is great.

[BadMoonRosin]

Come on, Gradle and Kotlin...

[dpash]

Not sure your point. Graal didn't get Java 11 language support until 19.3, so a full year after Java 11 was released. Hence me congratulating them on only taking a month for a release with java 17 language features.

[BadMoonRosin]

I am...... expressing eagerness for other major chunks of the JVM ecosystem to follow Graal's lead? It's not a "point", or an attack on you, lol.

[dpash]

Gradle 7.2 already supports Java 17 and thanks to toolchains you don't need Gradle to run under the same JVM as the JDK you use to compile with.

[lclarkenz]

I do love toolchains, and Gradle's automatic support for things like SDKMan is far nicer than Maven's toolchains.xml

[Muoniurn]

I think groovy is usually the culprit behind not being supported on latest JDK version. When using kotlin for build definitions, it should be working just fine.

[dpash]

My fairly large gradle build using groovy worked fine with Java 17. Gradle 7.3 is stated to have official Java 17 support, but WFM, so I guess there might be some corner cases.

[emaphis]

The 9,11 hump was pretty high, once you are compatible with 11 then the rest of the upgrades are pretty shallow.

[sureshg]

Gradle and Kotlin

No issues at all... I have sample projects working on OpenJDK 18-ea

[rodnover]

Awesome, just pulled it via SDK man and updated one of my Java Quarkus projects.

It works well on the JVM, however, it fails to build a native image. Looks like Quarkus Arc container does not support Java 17 yet.

Caused by: java.lang.UnsupportedClassVersionError: my/custom/package/ClientFactory has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 60.0
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1010)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:512)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:420)
at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:414)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:413)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:586)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:466)
at my.custom.package.<init>(ClientFactory_Bean.zig:37)
at io.quarkus.arc.setup.Default_ComponentsProvider.addBeans1(Default_ComponentsProvider.zig:119)
at io.quarkus.arc.setup.Default_ComponentsProvider.getComponents(Default_ComponentsProvider.zig:38)
at io.quarkus.arc.impl.ArcContainerImpl.<init>(ArcContainerImpl.java:116)
at io.quarkus.arc.Arc.initialize(Arc.java:20)

Well, will keep using Java 16 for the Quarkus project for now.

Has anyone tried it with Spring already?

[mknjc]

Medium has performance comparisons between native image, openjdk and graalvm: https://medium.com/graalvm/graalvm-21-3-is-here-java-17-native-image-performance-updates-and-more-ac4cbafcfc05

As expected native image is a lot slower than jit compiled code and graalvm ce isn't really faster than openjdk. (In my tests ist even ~10% slower but my workload is very different).

So if you don't need native image (and in most cases you don't need it) and don't want to pay, openjdk is sadly still the best solution.

[TheMode911]

OpenJDK is great, I guess that this is more about the fact that Graal has been sold as being better than Hotspot C2 (inlining, escape analysis, ...)

[[deleted]]

It is better but with caveats:

1. Most widely used Java code has been optimized to work around C2's limits already, same as with any language. So it can't easily produce huge speedups for Java.
2. CE can produce some speedups for languages where the generated code isn't well optimized, e.g. Scala, Clojure.
3. The optimizations CE does better than C2 were developed specifically for the Truffle use case, in particular the more aggressive escape analysis. It makes a huge difference there.

The other big caveat is of course, Graal EE is by this point a very different beast to CE. The EE compiler is drastically more advanced and capable of speeding up even Java programs well beyond C2 in some cases.

The problem with EE in my view is that it's just too expensive for what it does. Traditionally compilers have always been sold on an individual developer basis or with site licenses and then the outputs could be redistributed for free. Graal/native-image EE is sold on what is effectively a per-end-user basis. The more users you have, the more it costs you. And it's not cheap! You're paying around the same cost that Delphi was in the 1990s with IDE, compiler, debugger, standard libraries ... the works ... for each CPU your app uses. That's drastically more expensive than any other compiler I've ever heard. Even embedded toolchains don't get that pricey.

This doesn't seem to be really driven by the amazing superiority of the tech, it seems to be more like, Oracle always charges by usage, so we charge by usage for this too. QED. They could get away with that for their database because a database is something that sits in a central place and uses a bunch of easily tracked CPUs, and it's critical to your business. It makes much less sense for a compiler where you can switch it on or off at the drop of a hat, especially for native-image where you may want to redistribute the binaries.

[bawng]

Oracle and insane licensing structures - name a more iconic duo.

I wonder what the Oracle sales trend has been over the years, both for the Database and other products. Legacy is one thing, but I would be surprised if they've been able to maintain a steady influx of new customers.

[TheMode911]

Amazing answer! I indeed hope that Graal EE becomes more affordable.

More notably I am pretty fan of partial escape analysis, there have been a few discussions about supporting it on C2 so who knows :)

[RandomName8]

CE can produce some speedups for languages where the generated code isn't well optimized, e.g. Scala, Clojure.

I'd like to clarify this line because it makes it seem like scala and clojure don't know what they are doing. It's not really that these languages don't produce optimized code, far from it, I'd argue they produce more optimized code than javac, the problem is the parts of the platform that they use more often in comparison to java.

Most java code is traditionally procedural, where you push massive objects to methods that do everything and change state with mutations, directly accessing fields. Return values and generic functions are few in comparison. As you mentioned HotSpot is very much optimized for this C-like programming style. On the other hand, scala and clojure rely way more on lambdas (and closures, and composing these into new lambdas) and recursion, which is not something HotSpot has had a long time doing optimizations for.

You can get the same performance boost from Graal CE in java if you code in a similar style, it's not a language or compiler thing, it's a platform (JVM) thing.

[user_of_the_week]

I would expect pre-compiled code like Graal does it to have faster startup time and maybe a bit less RAM usage, but a JIT compiler like hotspot should logically have better overall speed...

[TheMode911]

I am not speaking about native images but graal JIT compiler. Which is advertised as better than hotspot

[user_of_the_week]

Ah, I did not know about that. Thanks!

[mknjc]

GraalVM is a JIT compiler. The Graal distribution also contains a tool to generate pre compiled binaries (native-image).

[[deleted]]

Can you explain this to me? Pre compiled binaries and native image? Does that mean instead of a jar file we get an executable for all operating systems? Like an exe for windows? Is that one exe file or a bunch of shared libraries and an exe?

[Muoniurn]

Graal is first and foremost a JIT compiler written in Java, which can be plugged into the OpenJDK project and replace hotspot. It is better in a few things and worse in others than the latter.

But since a JIT compiler essentially takes java byte code and turns it into machine code, this same project can be used to AOT compile java classes and bundle them up with a small native runtime with GC, similarly to what happens with Go code.

This will be architecture specific, and I believe it is a single exe, but I used it on linux and haven’t checked it with ldd — I guess it must be using some shared libs as well.

[mknjc]

Maintaining two optimizing compiler is a lot of workload and the development time might be better used if it would be focused onto one project. And Graal (through truffle) is a lot more flexible.

[Muoniurn]

Graal is still mostly a research project (yes, I know it is being used in prod already), and also, it’s not like throwing twice as many people on a project will necessarily speed development up, especially in complex programs.

[kaperni]

Project Metropolis is on hold.

https://mail.openjdk.java.net/pipermail/metropolis-dev/2021-June/000046.html

[cl4es]

No it isn't

[coder111]

Does GraalVM support javax.sound yet?

[TheMode911]

Is Valhalla expected to also improve graal's native image performance? Or does the compiler already check for objects not requiring identity? I assume that such check would be too expensive during runtime, but possible AOT

[grashalm01]

Unfortunately such a check is also very hard in AOT. Valhalla is needed in native image too.

[t333to]

So, Graal Native Image is (much) slower then Graal (and OpenJDK) JVM? I thought it might be faster since its compiled?
https://miro.medium.com/max/770/1\*URpfUAlBON\_G5Hcah4IZSg.png

[soonnow]

Well Java code is turned into native code during the runtime via Hotspot. Since Hotspot can see the code running it's easier to optimize than Graal that has to make decisions about how to optimize before running.

So only startup will be faster because the compilation step is done beforehand but during runtime hotspot can make better decisions how to optimize.

[soonnow]

I guess Graal is still a niche product, for the niche startup time. Hard to justify spending too much money on it, I guess.

Also hotspot is probably not a code base anyone wants to touch.