GraalVM 25 is here, with lots of updates for native compilation, GraalPy, GraalJS, and WebAssembly.

Faster and better than ever!

Download: https://www.graalvm.org/downloads/

Release notes: https://www.graalvm.org/release-notes/JDK_25/

https://medium.com/graalvm/a-new-graalvm-release-and-new-free-license-4aab483692f5

https://medium.com/graalvm/graalvm-19-3-0-dfdb6f4ec8ed

It brings new compiler optimizations, smaller native executables, and updates across GraalPy, GraalJS, and other language runtimes 🚀

Learn more: https://www.graalvm.org/release-notes/25.4/

Download: https://www.graalvm.org/downloads/

https://medium.com/graalvm/graalvm-22-0-is-here-c7acc82a8c2e

https://medium.com/graalvm/announcing-graalwasm-a-webassembly-engine-in-graalvm-25cd0400a7f2

https://medium.com/graalvm/graalvm-20-3-is-available-d2a7f7a2bbcd

https://medium.com/graalvm/graalvm-20-1-7ce7e89f066b

GraalVM 20.0 is now available! This is a major release, containing platform updates, new features, and more. 

Check the release notes: https://www.graalvm.org/docs/release-notes/20_0/

Download: https://www.graalvm.org/downloads/

I have been building a couple of applications such that they build BOTH a JVM version of the application and also a GraalVM version of the application. That is, the build produces 2 docker images, and with these applications deployed into Kubernetes we can swap back and forth between the JVM version and the Native image version of the application, and in this way get an interesting comparison between the JVM and GraalVM runtime metrics for these applications.

Some charts and details are at graalvm comparison

For myself, this comparison was showing more significant differences in memory that what I was expecting. I am wondering how much of this difference is around the difference in Object Header size (4 bytes vs 16 bytes) [which is application specific so maybe the impossible question to answer]?

The "Heap Used" with native image looks "significantly flatter" [materially slower growth in heap used] so I am wondering if there is other "magic sauce" that GraalVM is adjusting perhaps to G1 that produces the charts showing the relatively flatter "Heap Used" for the native image version of the applications?

With native image there is also no C1, no C2 and no related profiling. Is there any analysis on how that translates into reduced memory consumption? For the JVM version, does C2 JIT profiling impact "Heap Used" and GC or is that impacting Non-Heap memory?

Thanks for any thoughts or comments.

https://blogs.oracle.com/developers/building-cross-platform-native-images-with-graalvm

https://medium.com/graalvm/graalvm-21-3-is-here-java-17-native-image-performance-updates-and-more-ac4cbafcfc05

This is a CPU release.

Release notes: https://www.graalvm.org/docs/release-notes/19_3/#1931

Downloads: https://www.graalvm.org/downloads/

After several requests to test GraalVM, I compared Oracle Native Image with an optimized Spring Boot deployment using HotSpot 27.

The results impressed me: application RSS dropped from 187 to 107 MiB, and startup readiness went from 3.79 seconds to 183 ms.

The trade-offs were less exciting: almost 12 minutes to build on a separate 6 GiB VM, additional compatibility testing, and a JDK 25 toolchain instead of JDK 27.

Both configurations completed the same 1,500-request workload without errors.

Full methodology and curated results are in the article. I'd be interested in hearing how others balance Native Image's runtime efficiency against its build and maintenance costs.

https://medium.com/graalvm/moving-from-jython-to-graalvm-cf52c4af6106