CI/CD, Github Actions, and GraalVM Native Image
GraalVM Native Image Benefits
A native image has a number of benefits over an JVM based application, mainly owed to the extensive analysis done at build time.
Some of advantages mentioned:
- Runtime speed ~ 25% above the same code running on an JVM
- Ahead of Time compilation can lead to up to 9 times less memory consumption than running on an JVM
- Code executes faster with a smaller memory footprint than comparable Go applications ( but still is bigger/slower than C by a whisk)
- Warmup time got moved to build time, improving startup time
Building the image
Build has been greatly improved with tooling available:
- a Maven plugin (also available for Gradle), eliminating the need of extensive commandline foo.
- a GitHub action to install the GraalVM tooing in a pipeline
- reduced memory consumption, so most apps will fit into the GitHub build container limit of 7GB memory
- option for a non-optimized fast build, useful for testing correctness
Thoughts and conclusions
A big step in the right direction making native images more accessible. There's still room for improvements, like caching the build images and more samples. What Oracle solved nicely: If you are a GraalVM Enterprise customer, accessing GraalVM Enterprise edition is done using an access token, fully compatible to any build system. No messing around with downloads and manual installations required.