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.
0 Comments
Leave a Reply. |