|GraalVM Under The Covers|
|Written by Nikos Vaggalis|
|Monday, 10 January 2022|
Page 2 of 2
And now onto the Native images part. GraalVM allows Ahead-Of-Time (AOT) compilation of applications to native images:
Usage of native images can have significant performance
Such executables do not express with
We already seen this in practice in "Compile Spring Applications To Native Images With Spring Native". Spring Native lets you compile Spring applications to native images using the GraalVM native-image compiler:
What's the advantage in that? Instant startup, instant peak performance, and reduced memory consumption, since the native Spring applications are deployed as a standalone executable, well docker image, without including a JVM installation.
What's the disadvantage? It's that the GraalVM build process, which tries to make the most optimal image possible, throws a lot of stuff out. This could be dependencies, resources or parts of your code.
In particular, Ahead-Of-Time (AOT) compilation is highly beneficial when dealing with Microservices such as those examined in my recent report, Micronaut 3.2 Released for More Performant Microservices:
Spring of course is a monumental piece of technology;a versatile framework that does a lot under the covers to boost developer productivity. That magic comes with a drawback however. The magic Spring pulls is happening at runtime, analyzing your code and the annotations, injecting beans, etc thus using a lot of runtime loading as well as Reflection under the hood. And with bloated runtime comes an upshot on memory usage and of course startup time. The usual recipe of those stacks against performance hampering is caching but that comes with even more memory load.
Micronaut which gives you the same productivity boon as Spring, since the notion and code written against it are very similar, which of course make the transition a straightforward endeavor by providing the same dependency injection, inversion of control (IOC), and Aspect-Oriented Programming (AOP) but with massive memory and startup time savings at the same time.
The underlying technology was already there, on Android. The pointers of course is on the Ahead Of Time Compilation, a technique which determines what the application is going to need at compile time in order to avoid reflection completely thus keeping memory requirements down and performance up by doing more things at compile time than at runtime.
Embeddable Polyglot capabilities
Finally it's time to benchmark performance. The benchmarks have been done between GraalVM Enterprise, GraalVM Community, JDK 10 and JDK 11 on the following cases:
To cut a long story short, Graal EE performed the best in 4 out of 6 cases. For instance, Graal EE completes the h2 benchmark in 47. 06% faster than Graal CE. In comparison to standard JDK, both Graal CE and Graal EE versions proved to be better in most cases.
All that while GraalVM is still not a mature product 21. 3 is its latest version which foremostly comes with support for Java 17. A bright future is ahead.
Graal IR: An Extensible Declarative Intermediate Representation
or email your comment to: firstname.lastname@example.org
|Last Updated ( Monday, 10 January 2022 )|