Duke on #CRaC with #JakartaEE
summary
Demonstrates that CRaC (Coordinated Restore at Checkpoint) can cut Jakarta EE container startup from seconds to sub‑second by: building a small Jakarta app (random-strings), adding CDI lifecycle observers and a CRaC Resource with beforeCheckpoint/afterRestore, and creating Docker checkpoint images using Azul Zulu with the warp engine. Measured vanilla startup ~2.42s and CRaC restore ~0.8s (Helidon sees about a ~1s gain, Quarkus shows minimal benefit). Works end‑to‑end but requires handling open sockets/DB handles and currently depends on Zulu or privileged cryo.
AI-written summary · about
chapters (9)
- 0:00Introduction and JakartaEE overview
- 10:20What is CRaC and why it matters
- 28:58Demo setup and project overview
- 33:18Running the application without CRaC
- 36:26Building and testing CRaC container
- 44:47CRaC checkpoint and restore process
- 51:05Performance comparison and results
- 53:11JakartaEE and CRaC integration
- 1:02:47Q&A session
related talks
52mDuke on CRaC with Jakarta EE
53mJava on CRaC: Superfast JVM Application Startup
53mWhat the CRaC Superfast JVM startup
51mJava on CRaC Superfast JVM Application Startup
40mKotlin on CRaC – new JVM features to speed things up
45mOptimizing Java Startup and Warmup: Exploring the Power of CRaC on Embedded
46mCRAC vs GraalVM
48mDecoding Java snapshots with CRaC