Red Hat has introduced a new Java distribution, Mandrel, that compiles Java applications directly to native machine code for faster startup with lower memory.
Based on Oracle’s GraalVM, Mandrel offers an additional community-supported build with minor differences. Red Hat's senior director of engineering, Mark Little, explains, "Mandrel can best be described as a distribution of a regular OpenJDK with a specially packaged GraalVM native image." The primary driver behind Red Hat’s introduction of Mandrel is to drive speed and efficiency of the Quarkus framework, with its "supersonic subatomic Java." Quarkus is a framework offering both local development with rapid reload as well as containerized or serverless distribution to cloud providers. Since its first introduction in 2019, Quarkus has emphasized the ability to build native executables that start faster and decrease cloud operational cost & resources.
The head of GraalVM, Thomas Wuerthinger, responded to the release of Mandrel, stating, "Thank you @maxandersen and colleagues for active participation in the @graalvmcommunity!"
Andres Dinn explained the role of GraalVM and Mandrel in episode 7 of the Quarkus Insights video series. The video explains usage as well as various technical details with questions such as the difference between just-in-time compilation and ahead-of-time compilation. Dinn explains the benefits and drawbacks of each and where they are best suited.
Mandrel’s GitHub repository represents a fork of GraalVM but does not yet offer binary distribution. Instead, users compile the JDK themselves by following the provided instructions.
On performance benchmarks, GraalVM boasts a 50x faster startup time and 5x smaller memory usage. Tests were completed using a previous version of the Quarkus framework against Java’s HotSpot mode. While this improvement requires additional ahead-of-time compilation time, it slots for usage alongside Quarkus’ native Lambda and Azure Functions deployment.
Additional tips & tricks are available through James Ward, who has benchmarked several frameworks in native-compiled form. Ward covers the performance improvement benefits as well as some gotchas, such as applications that rely on reflection. "It creates a problem for GraalVM native images because reflection happens at runtime, making it hard for an AOT compiler to figure out the execution paths." For applications that do not need reflection, Quarkus’ home page aims directly at the benefit: 12MB of RAM compared to 73MB (an 83% decrease) and .016 seconds to first response compared to .943 (a 98% decrease).
Developers may use Mandrel now with their own build, or can leverage GraalVM Community or any JDK 11+ distribution. Interested developers can also use these to compete in the Quarkus hackathon.