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

[marios]

Most of the energy my phone uses isn't on 'running code', it's on 'sending radio signals' and 'making screen bright'.

Even if it spends 30% (random number that looks realistic) of the energy running code and java drains twice the energy of native compiled code, it wastes 15% of your phone battery...

[marios]

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

All languages that are used for mobile suck. The reason is not because bad languages are fit for mobile apps. It is because google and apple (if I am not mistaken) provide an API for slow languages but not for any language that does not suck. Forcing java down your throat is one of the main reasons android sucks.

[zamroni111]

Java and derivatives, I hate you for your poor performance and huge memory consumption.
You are the reason why Android phones performing lower than iOS and requiring more RAM.

Java coder can always nullify unused objects and call garbage collector to reduce memory usage.

[mangeek]

"only"

Most of the energy my phone uses isn't on 'running code', it's on 'sending radio signals' and 'making screen bright'.

[sinepgib]

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

Considering nowadays you just stick to ARM for phones, it wouldn't be crazy for a phone provider to actually allow Rust. It'll never happen, but a man can only dream.

[bug77]

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

It does fewer things. No modules support, no records, no enhanced switch statements...

[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.

[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.

[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.

[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.