Oracle's GraalVM 22.2 Brings More Performance Optimizations

[phoronix]

Phoronix: Oracle's GraalVM 22.2 Brings More Performance Optimizations

Oracle has issued its newest quarterly release of GraalVM as its high performance Java JVM/JDK that also supports additional execution models and programming languages. GraalVM 22.2 is this newest version and contains a number of different optimizations for its growing number of components...

https://www.phoronix.com/news/Oracle-GraalVM-22.2

[bug77]

"lowered the memory footprint for the native-image generator" - this I will have to test.
I'm not sure if it was bugged before, but it managed to OOM when trying to compile a rather simple client utility.

[timofonic]

Who uses this?

[Gappa]

Who uses this?

This is really cool for desktop Java gui applications. Slow startup time due to the Java JIT and other VM related issues was adding a few second to startup time, with a native compiled app with GraalVM you get instant native performing gui apps and start up time.

[Delgarde]

Who uses this?

It's fast growing in popularity in the Java community, because it provides most of the benefits of working in Java (i.e. one of the most widely used enterprise languages on the planet) but provides the ability to run Java programs in a much lighter manner (e.g. about half the memory use for a typical microservice web server, and a much faster startup time). And that's an obvious benefit for containerised apps running in cloud... they use fewer resources (i.e. cheaper) and can be spun up much more rapidly to respond to load.

[bug77]

Who uses this?

Hobbyists, mostly, since it's "not production ready" for years.

It reduces memory usage and startup times by A LOT, making Java applications much more palatable for, say, cloud environments or CLI utilities. Its goal, however, seems to be perpetually a bridge too far.

[Delgarde]

Its goal, however, seems to be perpetually a bridge too far.

For any arbitrary Java, I'd agree. But it's quite acceptable for a reasonable subset of Java, so if you're building new stuff - particularly in an ecosystem like Spring which has embraced it, it's a good target to work against.

[Michael_S]

I think short term the native image feature is attractive for companies already using Java in a lot of web services. If you're using a lot of containers the smaller container size, faster startup, and lower memory overhead is good.

Longer term, Oracle hopes that the Graal language polyglot features make it One Runtime to Rule Them All. But I am hopeful WebAssembly wins that war because it's an open standard.

[mdedetrich]

Who uses this?

Its somewhat popular in Scala mainly because there some optimizations that have been added to GraalVM which don't exist in OpenJDK which heavily benefit Scala applications (i.e. its typical in purely functional Scala apps to represent your entire program as lazy values that are run in an interpreter and the JVM doesn't optimize this code very well).

GraalVM also tends better to Scala applications because unlike typical Java apps, Scala code very rarely uses features like reflection or bytecode manipulation which in Java land is a PITA to setup with GraalVM (since GraalVM is AOT compiled it needs to know all of these cases upfront when you pass it as cli args into the compiler).

On the other side of things there is stuff like scalafmt-native, scalafmt is a code formatter and the native part is built with GraalVM so it has almost instant startup (handy for cli).

It reduces memory usage and startup times by A LOT, making Java applications much more palatable for, say, cloud environments or CLI utilities. Its goal, however, seems to be perpetually a bridge too far.

Honestly biggest problem with GraalVM is this split between the enterprise and community edition

[bug77]

For any arbitrary Java, I'd agree. But it's quite acceptable for a reasonable subset of Java, so if you're building new stuff - particularly in an ecosystem like Spring which has embraced it, it's a good target to work against.

Nah, not Spring. Quarkus or Micronaut.
And even that doesn't work very well, because you never know whether the shiny new dependency you just added uses some funky reflection.

Project Leyden is supposed to be an approach that would be able to tackle what GraalVM couldn't, but even that seems to be going off-track: https://www.infoq.com/news/2022/06/p...en-delays-aot/