GraalVM Updated For Java/JDK 21, Great Performance Results

[phoronix]

Phoronix: GraalVM Updated For Java/JDK 21, Great Performance Results

In addition to Oracle releasing OpenJDK 21 / Java 21 on Tuesday, their GraalVM team also carried out a same-day release of GraalVM with the new Java 21 features and more...

https://www.phoronix.com/news/GraalVM-JDK-Java-21

[bug77]

And once again they pride themselves about AoT compile, despite:

The Native Image technology is distributed as a separate installable to GraalVM

Native Image for GraalVM Enterprise Edition is available as an Early Adopter feature

https://www.graalvm.org/22.0/reference-manual/native-image/

[Linuxhippy]

I guess this AOT support as well as a better looking swing default theme (does anyone still remember pre java-1.5 metal) would have saved java on the desktop back then.
Imagine you would have to wait 30s for an application to start, and when it finally pops up it looks like this:
grafik.png

The sad thing is technically everything was always there (Excelsior JET for AOT, pluggable swing themes that looked really cool), but without the push from Sun those things didn't gain tracktion.

[caligula]

I guess this AOT support as well as a better looking swing default theme (does anyone still remember pre java-1.5 metal) would have saved java on the desktop back then.
Imagine you would have to wait 30s for an application to start

It's just bad application design. On a modern system the Java runtime (JIT, not AOT) takes around 200-500 ms to launch. It can be faster if you use jlink. Often Java applications have really complex startup and initialization sequences. They could also lazily load more stuff. A GUI app doesn't need to initialize all the windows before showing them.

[bug77]

It's just bad application design. On a modern system the Java runtime (JIT, not AOT) takes around 200-500 ms to launch. It can be faster if you use jlink. Often Java applications have really complex startup and initialization sequences. They could also lazily load more stuff. A GUI app doesn't need to initialize all the windows before showing them.

It's called business logic. You know, the whole reason applications exist in the first place. The thing is JIT is the complete antithesis of quick startup. To the point Java even came up with CDS, to lower some of the burden placed on JIT. But nobody uses CDS, so it doesn't really matter. What makes a tangible difference for performance in Java is something introduced in Java 6 (!): annotation processors. Think Quarkus or Micronaut and how they move a ton of things to the compile phase, so startup and even memory usage are vastly improved. AoT compile would be golden for Java at this points, but it needs to work reliably and be dead-simple to use. AoT compile adds its own issues, though.

[Linuxhippy]

It's just bad application design. On a modern system the Java runtime (JIT, not AOT) takes around 200-500 ms to launch. It can be faster if you use jlink. Often Java applications have really complex startup and initialization sequences. They could also lazily load more stuff. A GUI app doesn't need to initialize all the windows before showing them.

I was talking about the days when desktop applications were still relevant (e.g. 1998/99) and more than a niche.
Believe me, with Java-1.4 on a P2-350 with 64MB Ram and a spinning disk, you had to wait MANY seconds before a window would appear, even for the most basic application.
Startup was slow because the JVM had to parse and verify protable bytecode at each application start (pre-verification and class-data-sharing weren't available back then), and when the class was finally loaded the JIT hadn't even kicked in yet. Swing was be slow simply because it had a large code-base which was mostly lukewarm code (a case where JITs do not excel), despite hardware accelerated rendering added with Java 1.4. I still remember running JBuilder back then

I guess back then not a lot was missing to make Java a viable development plattform for client applications. However those things were not done or avoided (e.g. AOT was probably avoided to make users install the JRE), and desktop java basically died: The only popular swing based app I know still of relevance today is IntelliJ.

[bug77]

I was talking about the days when desktop applications were still relevant (e.g. 1998/99) and more than a niche.
Believe me, with Java-1.4 on a P2-350 with 64MB Ram and a spinning disk, you had to wait MANY seconds before a window would appear, even for the most basic application.
Startup was slow because the JVM had to parse and verify protable bytecode at each application start (pre-verification and class-data-sharing weren't available back then), and when the class was finally loaded the JIT hadn't even kicked in yet. Swing was be slow simply because it had a large code-base which was mostly lukewarm code (a case where JITs do not excel), despite hardware accelerated rendering added with Java 1.4. I still remember running JBuilder back then

I guess back then not a lot was missing to make Java a viable development plattform for client applications. However those things were not done or avoided (e.g. AOT was probably avoided to make users install the JRE), and desktop java basically died: The only popular swing based app I know still of relevance today is IntelliJ.

Yeah, somehow desktop was never a priority for Java. After applets and Swing killed it on the desktop, we got JavaFX which was actually nice and introduced the separation between presentation and business logic which Swing didn't enforce. But of course, by then it was already too late.
Azureus was popular too, but it also died a few years back.

[caligula]

I was talking about the days when desktop applications were still relevant (e.g. 1998/99) and more than a niche.
Believe me, with Java-1.4 on a P2-350 with 64MB Ram and a spinning disk, you had to wait MANY seconds before a window would appear, even for the most basic application.

Well yea. OTOH I think you could have run interpreter instead. It was a lot slower, but anyway. The Sun implementation of Java wasn't really suitable for those kind of low-end systems. I think they had some kind of internal development project for speeding up the startup (I don't mean the ones they later published), but that project was never released. GCJ was a bit faster to launch. Then again, even native applications like those made with Delphi were a lot slower than slimmer apps written in Visual C++.

Swing was be slow simply because it had a large code-base which was mostly lukewarm code (a case where JITs do not excel), despite hardware accelerated rendering added with Java 1.4. I still remember running JBuilder back then

Swing also relies on an extra verbose style of OOP where e.g. layout manager objects are different from the containers and many functionalities require adapters and all sorts of wrappers. This puts a lot of burden on the GC and other parts of the runtime. If Java didn't allow dynamic loading of new classes, it would have been possible to optimize things a lot more, especially those intermediate objects that don't need an explicit class name.

[cynic]

I still remember running JBuilder back then

oh, I still have the CD, the manual and the original box somewhere!

[cynic]

I guess this AOT support as well as a better looking swing default theme (does anyone still remember pre java-1.5 metal) would have saved java on the desktop back then.
Imagine you would have to wait 30s for an application to start, and when it finally pops up it looks like this:
grafik.png

The sad thing is technically everything was always there (Excelsior JET for AOT, pluggable swing themes that looked really cool), but without the push from Sun those things didn't gain tracktion.

for the time Metal L&F was not bad at all.

TBH I still like it today, but I realize that I have a bit of outdated tastes regarding GUI.