Explain the lifecycle of application startup in native mode vs JVM mode?

Both modes run an application that was already fully augmented at build time, but what actually happens between "process launched" and "ready to serve requests" differs meaningfully between the two.

In JVM mode, the JVM still has to load classes and begin JIT compilation of hot code paths as execution proceeds, even though Quarkus has minimized the DI/config wiring work needed at that point; some of that JIT warm-up continues even after the app starts accepting traffic, with peak throughput improving gradually over the first several seconds or minutes.

In native mode, GraalVM can pre-initialize significant portions of application and framework state at build time and embed that initialized heap directly into the binary, so the process effectively resumes from a mostly-ready state rather than building it up from scratch — skipping class loading and JIT warm-up entirely, which is why native startup times are consistently an order of magnitude faster than even Quarkus's already-fast JVM mode.