GraalVM native image comparison vs JVM

[rbygrave]

For a couple of applications that use Ebean (and Helidon 4) on Java 25 deloying to Kubernetes, these applications are building 2 docker images, with one being a usual JVM based version and another being a GraalVM native image version. In this way, for these applications we can swap deployment between these 2 images to compare the same application as JVM vs GraalVM native image.

Some charts and notes are at: https://avaje.io/graalvm/comparison

Note that these are admittedly fairly small applications, that also use use the avaje libraries so using code generation (via annotation processing) for dependency injection, json serialization, http routing etc. Perhaps this makes it easier for GraalVM compiler to optimise this code.

• GraalVM AOT compile produced very impressive results
• GraalVM AOT compile used static analysis (which now includes Machine Learning). So no PGO and no "Training run" required. I think this is significant in that if we had to use PGO with an additional training run and additional compile step, that could add complexity to CICD build pipelines and make adoption harder for those cases.
• Good news for Ebean in that GraalVM AOT compile optimised a bunch of non-trivial ebean orm queries [with ebean-datasource and Postgres JDBC driver].

To me this looks very significant in terms of potential savings available via reduced cpu and memory resource consumption.