The Java Virtual Machine (JVM) start-up process is a carefully orchestrated sequence of steps that transforms a simple java command into a fully running Java application. Understanding this lifecycle is essential for diagnosing slow start-up times, optimizing cloud-native and microservice applications, and gaining deeper insight into how Java executes programs. Let us delve into understanding JVM start up and its internal execution flow.
1. JVM Startup: From the java Command to Runtime Initialization
When a developer executes a command such as java -Xms256m -Xmx512m com.example.Main, the process that follows is far more complex than simply starting a Java program. This command triggers a multi-stage bootstrap sequence involving the operating system, the Java launcher, and the JVM runtime itself. Understanding this sequence is critical when analyzing JVM startup latency or tuning performance-sensitive workloads.
The startup flow begins at the operating system level:
- Process Creation: The operating system creates a new process and locates the
javalauncher executable based on the systemPATHor the absolute path provided. Environment variables such asJAVA_HOMEandCLASSPATHare also resolved at this stage. - Java Launcher Initialization: The
javalauncher (written in native code) parses command-line arguments, separating JVM options (-Xms,-Xmx,-XX) from application arguments. Invalid or conflicting options are detected here, before the JVM itself is created. - JVM Selection and Loading: Based on the configuration and platform, the launcher selects the appropriate JVM implementation (for example, HotSpot Server or Client VM). The JVM’s native shared libraries are then dynamically loaded into memory using OS-specific mechanisms such as
dlopenon Linux orLoadLibraryon Windows. - Runtime Data Area Initialization: Once the JVM is loaded, it initializes core runtime structures, including the Java heap, metaspace, thread stacks, code cache, and internal synchronization primitives. Garbage collector selection and configuration are finalized at this point.
- Thread and Subsystem Startup: Essential JVM threads are created, including the main thread, garbage collection threads, JIT compiler threads, signal dispatcher threads, and reference handler threads. These threads form the backbone of JVM execution and memory management.
- Bootstrap Class Loader Activation: The bootstrap class loader loads fundamental Java platform classes such as
java.lang.Object,Class, andStringfrom the runtime image (rt.jarin older JDKs or thejimagein modern JDKs). Without these classes, no Java code can execute.
After the JVM runtime is fully initialized, the launcher hands control to the JVM. The JVM then locates the application’s main class, verifies and loads it, performs class initialization, and finally invokes the public static void main(String[] args) method. Only at this final step does user-defined Java code begin execution.
2. Class Lifecycle: Loading, Linking, and Initialization
After the JVM runtime has been created, it manages application execution through a well-defined class lifecycle governed by the Java Language Specification. Every Java class and interface goes through three major phases—loading, linking, and initialization—before it can be actively used. These phases are central to JVM correctness, security, and performance.
2.1 Class Loading
Class loading is the process of locating a class’s binary representation (bytecode) and creating an in-memory java.lang.Class object. The JVM uses a delegation-based class loader hierarchy to ensure platform stability and security:
- Bootstrap Class Loader: Loads core Java classes such as
java.langandjava.util. It is implemented in native code and has no Java-level representation. - Platform Class Loader: Loads platform-level modules introduced in Java 9, such as
java.sqlandjava.xml. - Application Class Loader: Loads classes from the application classpath or module path, including user-defined code.
The JVM follows the parent delegation model, meaning a class loader first delegates the loading request to its parent before attempting to load the class itself. This prevents core Java classes from being accidentally or maliciously overridden. Class loading is typically lazy, occurring only when a class is first referenced, which helps reduce startup time and memory usage.
2.2 Linking
Linking transforms a loaded class into a form suitable for execution. It consists of three distinct sub-phases:
- Verification: The bytecode verifier checks that the class file conforms to the JVM specification, ensuring type safety, stack correctness, and access control. This step prevents corrupted or malicious bytecode from compromising the JVM.
- Preparation: Memory is allocated for static fields and initialized to their default values (zero,
null, orfalse). At this stage, symbolic references are still unresolved, and explicit initializers are not yet run. - Resolution: Symbolic references in the constant pool (such as class, method, and field references) are replaced with direct references. Resolution may occur eagerly during linking or lazily at first use, depending on the JVM implementation.
2.3 Initialization
Initialization is the final phase of the class lifecycle and marks the point at which a class becomes fully operational. During this phase, the JVM executes the class initialization method (<clinit>), which is generated by the compiler to combine static variable initializers and static blocks. The JVM guarantees that class initialization is:
- Ordered: Superclasses are initialized before subclasses.
- Synchronized: Only one thread can initialize a class at a time.
- Lazy: Initialization occurs only when the class is actively used.
If an exception occurs during initialization, the class is marked as erroneous and cannot be used again during the lifetime of the JVM. Only after successful completion of this phase is a class considered fully usable by application code.
3. Code Example
package com.example;
public class JvmStartupDemo {
static {
System.out.println("Static block executed");
}
private static int value = initializeValue();
private static int initializeValue() {
System.out.println("Static field initialization");
return 42;
}
public static void main(String[] args) {
System.out.println("Main method started");
System.out.println("Value = " + value);
}
}
3.1 Code Explanation
This class demonstrates how the JVM executes class initialization during startup. When JvmStartupDemo is first referenced, the JVM loads and links the class, then begins initialization by executing the generated <clinit> method. During this phase, the static block runs first and prints “Static block executed”, followed by the initialization of the static field value, which invokes the initializeValue() method and prints “Static field initialization” before assigning the value 42. Only after all static initialization completes does the JVM invoke the main method, which prints “Main method started” and then accesses the already-initialized static field, outputting “Value = 42”. This execution order highlights the JVM’s guarantee that static initialization occurs exactly once and before any application logic runs.
3.2 Code Run
Compile and run the program using the Java compiler and runtime as shown below:
javac com/example/JvmStartupDemo.java java com.example.JvmStartupDemo
3.3 Code Output
Static block executed Static field initialization Main method started Value = 42
The output clearly reflects the JVM class initialization order: the static block executes first, followed by static field initialization, and finally the main method runs after the class has been fully initialized.
4. Improving JVM Startup Performance
JVM start-up performance plays a crucial role in modern application architectures, especially for command-line tools, serverless workloads, containerized applications, and microservices that are frequently started and stopped. Startup time is influenced by JVM initialization, class loading, bytecode verification, and just-in-time (JIT) compilation decisions. Optimizing this phase often requires balancing fast startup against long-term throughput and runtime performance.
Several proven techniques can significantly reduce JVM startup latency:
- Class Data Sharing (CDS): CDS allows the JVM to preload and memory-map a set of core Java classes into a shared archive. This reduces class loading and verification overhead while enabling multiple JVM instances to share the same read-only class metadata, improving both startup time and memory efficiency.
- Reducing Classpath Size: Large classpaths increase startup cost due to additional I/O, class discovery, and verification. Removing unused dependencies, shading libraries, or using the Java module system can significantly reduce the number of classes the JVM must scan and load during startup.
- Tiered Compilation Tuning: The JVM’s tiered compilation strategy trades faster startup for optimized runtime code. Adjusting options such as disabling tiered compilation or limiting compiler activity during startup can reduce warm-up time at the expense of peak performance, which is often acceptable for short-lived processes.
- Application Class-Data Sharing (AppCDS): AppCDS extends CDS to include application-specific classes. By creating a custom shared archive that includes frequently used application classes, the JVM can bypass repeated class loading and linking work, significantly improving startup times for large applications.
- Native Images with GraalVM: Ahead-of-time (AOT) compilation using GraalVM produces native executables that remove the need for a traditional JVM startup altogether. While this approach offers near-instant startup and low memory usage, it requires careful configuration and may limit certain dynamic Java features such as reflection and dynamic class loading.
In practice, the optimal startup strategy depends on the application’s execution model. Long-running services may tolerate slower startup in exchange for better throughput, while short-lived or elastic workloads benefit greatly from aggressive startup optimizations. Profiling, measurement, and incremental tuning are essential to finding the right balance.
5. Conclusion
JVM start-up is more than just launching a process—it is a multi-phase operation involving native initialization, class loading, linking, and execution. By understanding these internals, developers can make informed decisions about application design and performance tuning. Whether optimizing traditional server applications or modern cloud workloads, a solid grasp of JVM start-up behavior is a powerful tool in any Java engineer’s skill set.
