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
benefits in certain situations, when JVM is not required to
run, load, and initialize classes, resulting in a fast startup
and low footprint.

Such executables do not express with
peak performance, but a fast startup and low runtime
overhead could make a significant difference in a
contemporary cloud or serverless production environment.

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
Native image capabilities aside, GraalVM can also be embedded into different runtime platforms, for example, relational databases. Possible implementations include MySQL and Oracle databases, Apache Spark,NGINX, and others.

The benchmarks

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: 

• h2 – execution of JDBC like in-memory benchmark, by running a large number of transactions on a banking application model
• lusearch-fix – an application that indexes works of Shakespeare and the King James Bible by using lucene
• xalan – an application that transforms XML documents into HTML documents
• pmd – an application that analyzes a number of Java classes for a range of source code problems
• sunflow – an application that renders a set of images using ray tracing
• jython – an application that interprets the pybench 

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.

To sum it up, GraalVM paves the way for the future of the VMs. Writing code in many languages and executing it in any platform. Cross-language interoperability, sharing code and libraries without any performance overhead allowing computing problems to be solved in the best-specialized language. The possibility of creating native images has been proved beneficial especially in the cloud and microservices industry while the embeddability options can extend products like databases;for instance by enabling users to call a JavaScript function directly from SQL.

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. 

More Information

Exploring Aspects of Polyglot High-Performance Virtual Machine GraalVM

Graal IR: An Extensible Declarative Intermediate Representation
An Oz implementation using Truffle and Graal
One VM to Rule Them All
Automatic generation of Truffle-based interpreters for
Domain-Specific Languages
Sulong: An experience report of using the "other end" of LLVM in GraalVM
Graal: where it’s come from and where it’s going
Fast, Flexible, Polyglot Instrumentation Support for Debuggers and other Tools
Truffle/Graal:From Interpreters to Optimizing Compilers via Partial Evaluation

Related Articles

GraalVM 21.3 Released

Micronaut 3.2 Released for More Performant Microservices

Compile Spring Applications To Native Images With Spring Native

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info