![]() ![]() ![]() This spectrum is anchored at its extremes by the full Java experience at one end, and the closed world native compiled image at the other. The results are impressive but there are trade-offs required of the developer, the framework, and the platform to get there - see SubstrateVM’s limitations for a description of some of these tradeoffs.įrom the investigations we’ve done into OpenJ9 startup improvements, CRIU, and SubstrateVM, a spectrum of options emerges, each targeted towards different use cases. Quarkus shows off the startup benefits of SubstrateVM on its main page, demonstrating that incredibly fast startup time (aka time to first request) when the application is compiled to native. SubstrateVM starts applications fast through native image creation. While our investigation started with CRIU and focused on how to make OpenJ9 start even faster than it already does ( check out SharedClasses and dynamic AOT if you haven’t already!), it would be foolish to ignore Graal’s SubstrateVM technology when looking at this space. Otherwise, follow along through the spectrum of options that helped guide our choice to focus on snapshot+restore at the JVM level. For the impatient, jump ahead to the “Snapshot+Restore” section. Only available on Linux while the JVM runs on a plethora of operating systems and architectures.Īfter our CRIU investigation, we took a step back and surveyed the landscape before landing on “Snapshot+Restore” at the JVM level.All memory in the process needs to be saved, including the unused space in the Java heap, which can result in larger than necessary images (and restore times). ![]() The large footprint overhead of a full process image.Similar to the ASLR issue, this makes operations more predicable and easier to attack as well as exposing them to anyone with a copy of the checkpointed process. Secrets, encryption keys, random number generators and more are all reused from the checkpoint.Work is being done in this space so this may be less of an issue in the future. The capabilities needed to restore give the application more privileges than it would otherwise need resulting in a larger attack surface. Restoring a CRIU process requires running as root.Restarting a checkpoint results in exactly the same address space layout as previous runs making it easier for attackers to “learn” addresses for later attacks. It defeats address space layout randomization (ASLR).That’s the basic premise of CRIU: live migrating systems is more performant than stopping and restarting.ĬRIU, while being an amazing piece of technology, has some drawbacks: Past experiments with CRIU have demonstrated that JVM startup time can be greatly improved by checkpointing the process and then subsequently creating new processes from that checkpointed state. The snapshot work is originally inspired by Linux’s CRIU (checkpoint restore in user-space) which does the same thing as snapshot+restore but for a full Linux process. To understand how we arrived at snapshot+restore of the JVM as the best approach for the widest set of workloads, I’d like to share the journey we went on as we investigated this space. In the next major evolution of our work in this space, the project recently created a new snapshot branch containing an early prototype of snapshot+restore functionality at the JVM level which allows snapshotting (saving) a running JVM process and restoring it later from the saved point. And we’ve done a pretty good job of it - see any of our claims about fast startup with comparable performance in roughly half the memory. The Eclipse OpenJ9 project has a strong focus on finding the right balance between startup performance, peak throughput and memory usage. ![]()
0 Comments
Leave a Reply. |