GraalVM 20.1, OpenJ9 0.20, OpenJDK Java Benchmarks

[phoronix]

Phoronix: GraalVM 20.1, OpenJ9 0.20, OpenJDK Java Benchmarks

Given the release last week of GraalVM 20.1 as well as last month's release of Eclipse OpenJ9 0.20, here are some fresh JVM benchmarks up against multiple OpenJDK releases.

http://www.phoronix.com/vr.php?view=29211

[LightBit]

I like OpenJ9, because it is not greedy on memory.
But it looks like performance is not the best.

[bug77]

I'm not sure why the difference between OpenJDK 11 and 14. The language barely changed between them. Different default GC maybe?

[Michael_S]

I wonder how the OpenJDK benchmark numbers would change based on different garbage collector settings? OpenJDK now has at least 6 garbage collectors:

CMS (old garbage collector, lower performance in most scenarios than the next two)
Parallel GC (default in OpenJDK 8)
G1GC (default in OpenJDK 9)
ZGC (sacrifices throughput for latency)
Shenandoah (sacrifices throughput for latency, alternate algorithm vs. ZGC)
Epsilon (noop garbage collector, it just lets you keep allocating new objects until your program finishes or until you run out of memory and then it crashes, used to measure GC overhead).

[bug77]

I wonder how the OpenJDK benchmark numbers would change based on different garbage collector settings? OpenJDK now has at least 6 garbage collectors:

CMS (old garbage collector, lower performance in most scenarios than the next two)
Parallel GC (default in OpenJDK 8)
G1GC (default in OpenJDK 9)
ZGC (sacrifices throughput for latency)
Shenandoah (sacrifices throughput for latency, alternate algorithm vs. ZGC)
Epsilon (noop garbage collector, it just lets you keep allocating new objects until your program finishes or until you run out of memory and then it crashes, used to measure GC overhead).

You must be new to Java. Once you come at odds with the garbage collector, you're going to go through pages of explanations for GC engines and their options. This is nothing a generic benchmark will ever help you with, it's all very workload specific.

Also, G1GC is the only one you should care about. The rest are removed (CMS), obsoleted (Parallel GC, CMS) or still experimental (the other 3). Epsilon can be useful for unix-style tools that run on demand and then exit; it can potentially slim down your executable considerably when used together with the native tool. The other experimental ones are worth keeping tabs on, there's potential there.

[pierce]

I would love to see how dotnet core stacks up against the latest Java has to offer.

[Michael_S]

You must be new to Java. Once you come at odds with the garbage collector, you're going to go through pages of explanations for GC engines and their options. This is nothing a generic benchmark will ever help you with, it's all very workload specific.

Also, G1GC is the only one you should care about. The rest are removed (CMS), obsoleted (Parallel GC, CMS) or still experimental (the other 3). Epsilon can be useful for unix-style tools that run on demand and then exit; it can potentially slim down your executable considerably when used together with the native tool. The other experimental ones are worth keeping tabs on, there's potential there.

I've worked with Java for a while, but I haven't done much GC tuning.

My guess is that for some of those benchmarks, switching GCs to one of the experimental ones might improve performance.

[cynical]

JVM performance is very impressive. I’m looking forward to seeing the value types from Project Valhalla and the virtual threads from Project Loom. I don’t mind writing async code, but being able to write regular blocking code and have it perform just as well would be amazing. We’ve had to look at threads as a scarce resource for so long that it will feel weird having millions of them.

[Zlatan Kadragic]

Also, G1GC is the only one you should care about.

But there is one surprise. In all documentation it is stated that from JDK9 G1 is default, sometimes they even say it is default on server machines. Sounds OK, but! Running apps islolated in cloud environment in containers it can happened, even with latest JDK that is suppose to have support for containers, that JVM detects only one CPU (core) and than conclude that it is running on prehistoric desktop machine and starts with serial gc. Even if you supply correct switches trough docker so JVM sees more then one CPU it will again decide not to use G1 if you didn't attached 2 and more GB to the container which in too much memory for some simple applications but if you do not use G1 then when app has high load it may not do GC on time, non-heap added to that uncleaned heap may hit container limit giving OOM kill. Then you have 2 options: to increase memory to 2 GB or to force use of G1 with flags...

[elatllat]

No graalvm native-image testing yet on phoronix right?

https://www.reddit.com/r/java/comments/j0ir4q/java_graalvm_native_image_vs_rust/