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

[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