In my previous blog post I evaluated the
feasibility of Java for lightweight system programming thanks to the
native image generation tool. Despite the initial results look promising,
I felt disappointed when they
pointed me out that GraalVM does not support reflection by default (which IMHO
is a wonderful and powerful tool to enhance the expressiveness of our software
and to reduce boilerplate). However, you can actually configure the
ahead-of-time compiler to incorporate a user-provided reflection metadata.
There is still a common belief about Java being slow (especially during startup)
and memory-consuming, making it not being the first option for ephemeral service
instances, like containers. This blog post pretends to put some light on
those assertions, quantifying the impact of a last-generation JVM in a simple,
single-threaded, application. We compare the impact of the JVM measuring the
execution time and memory spent of a Java QuickSort implementation,
comparing it with the execution of a native image generated with the modern
GraalVM Ahead-Of-Time (AOT) compiler and the same
QuickSort implementation in Go.
Despite copying a struct with several fields is slower than copying a pointer
to the same struct, returning a struct value may be faster than returning a
pointer if we consider escape analysis particularities.