Java Benchmarks: OpenJDK 8 Through OpenJDK 19 EA, OpenJ9, GraalVM CE

[archkde]

Why is OpenJDK 8 so fast, counter to the general trend "newer is faster"?

[marios]

Java is actually quite good with regard of energy consumption.

https://thenewstack.io/which-programming-languages-use-the-least-electricity/

it is only 2 times more power consuming than C.

The only better alternatives are C, Rust, C++ and Ada, but If you plan to develop mobile apps with those languages, good luck!

"only"

[Dovi]

"only"

Compare it to any other high level language that you could use to develop a mobile app with.

[NobodyXu]

Ignorance is bliss I guess. You use Java (and more recently Kotlin), but Android has never used any of the benchmarked runtimes. It used its own runtime (applying whatever optimizations it wanted), but it got rid of it long, long ago (Android 5, iirc). Everything that ran on Android since is pre-compiled code.
Not to mention there was always the Android NDK. But you go ahead and keep hating on Java.

Hmmm, after googling, I found an article on this topic https://proandroiddev.com/android-ru...k-6e57cf1c50e5

According to it, nowadays Android first runs the app on JIT, identify the hotspot, AOT compile it into native code on idle.
Google also collects profile data from phones and gather them on cloud and compile Apps according to the commonly used profiles.
They certainly have AOT, but it is not completely AOT and they still have JIT.

Also, the AOT compilation does not eliminate the GC, which is probably responsible for the ram usage and some power draw.

[NobodyXu]

It does, but native-image is still not production ready. Recently it has starting running out of memory when trying to compile simple programs. Not with an OOM, mind you, but with an arcane "Error: Image building with exit status 137" instead (Google it, it's "fun").

Looks like it still has way to go before it can be considered as production-ready.

[Degra]

It does, but native-image is still not production ready. Recently it has starting running out of memory when trying to compile simple programs. Not with an OOM, mind you, but with an arcane "Error: Image building with exit status 137" instead (Google it, it's "fun").

This is false, GraalVM's native images run ~20% slower on average than in JIT mode.
The reason is simply that code optimization with native images has to happen in compile time, rather than during runtime as with JIT, and GraalVM's compile time optimizations are worse than the runtime optimizations that had over 25 years of time to mature in Java.

Granted, if you're going for start-up time and memory consumption, both of these are massively reduced in native images.

[brucethemoose]

For anyone interested in Java ricing, the Minecraft community (of course) has come up with some flags for GraalVM EE: https://github.com/etil2jz/etil-minecraft-flags


Clear Linux's OpenJDK build also had some Minecraft performance benefits in the past, but I haven't tested it recently


...I wonder if I can add a Minecraft chunk generation test to openbenchmark, since it technically doesnt require any authentication.

[cb88]

Why is OpenJDK 8 so fast, counter to the general trend "newer is faster"?

Newer is faster? Is it?

The JDK 8 perhaps java peaked then... and much of the stuff after that is micro optimisations and bloat, Java 8 is the closes in this list to Sun Java only 4 years after the buyout. I wouldn't mind seeing Java 6 and 7 in this benchmark also.

Just for some context... performance wise Java hotspot has been out since Java 1.2... and had been in development for a around 15+ years by the time Java 8 was released so extremely mature.

[pmorph]

Why is OpenJDK 8 so fast, counter to the general trend "newer is faster"?

I suppose they had to add all kinds of little things to support the new language features.

[bug77]

Hmmm, after googling, I found an article on this topic https://proandroiddev.com/android-ru...k-6e57cf1c50e5

According to it, nowadays Android first runs the app on JIT, identify the hotspot, AOT compile it into native code on idle.
Google also collects profile data from phones and gather them on cloud and compile Apps according to the commonly used profiles.
They certainly have AOT, but it is not completely AOT and they still have JIT.

Also, the AOT compilation does not eliminate the GC, which is probably responsible for the ram usage and some power draw.

You didn't read that right. Code is compiled properly at install time. It's just that the runtime attempts to optimize it further based on your own usage.
But that's beside my original point: Java bytecode is just an IR. What actually runs is not a JVM, but something entirely of Google's making.