What Are the Parts of the JVM?

The JVM has four large pieces. The class loader subsystem loads, links and initialises classes. The runtime data areas are the memory the JVM manages while the program runs. The execution engine interprets and compiles the bytecode. And the runtime library provides the class library the program actually calls into.

For an interview the runtime data areas are the part worth being precise about, because they are what people actually get asked about. The heap holds every object and is shared between all threads; this is where the garbage collector works. The method area holds the metadata for each class — its field and method definitions, the constant pool, and the bytecode — and is part of the heap in modern implementations. The JVM stack is created per thread and holds a frame for each active method, with the frames holding the local variables and the operands of the expression being evaluated. The program counter is a per-thread register pointing at the instruction currently being executed. And the native method stack holds frames for the native code the JVM calls into.

Two details that separate the knowledgeable from the rote-learners. Each thread has its own stack and its own program counter, which is why one thread blocking does not affect another. And the stack is not heap memory — stack frames are allocated and reclaimed in a strictly last-in-first-out fashion, which is why a deep recursion overflows it quickly while allocating a large array does not.

Here is the same thing as runnable code:

public class Main {
    public static void main(String[] args) {
        // Ask the JVM about itself.
        System.out.println("java.vm.name    : " + System.getProperty("java.vm.name"));
        System.out.println("java.vm.version : " + System.getProperty("java.vm.version"));
        System.out.println("java.vm.vendor  : " + System.getProperty("java.vm.vendor"));
        System.out.println("java.home       : " + System.getProperty("java.home"));
        System.out.println("spec version    : " + System.getProperty("java.specification.version"));
        System.out.println("runtime version : " + Runtime.version());
        System.out.println("available CPUs  : " + Runtime.getRuntime().availableProcessors());
        System.out.println("max memory      : " + Runtime.getRuntime().maxMemory() / (1024 * 1024) + " MB");
    }
}

The class loader turns a class name into the class object the runtime uses. It has three phases. Loading finds the bytes for the class and defines a Class object for it. Linking then prepares it: verification checks that the bytecode is safe and obeys the type rules, preparation allocates memory for the static fields and sets their defaults, and resolution replaces the symbolic references in the constant pool with direct references. Initialisation runs the static initialisers and the static field initialisers.

The class loader hierarchy is what makes the runtime safe to extend. The bootstrap loader loads the core classes from the runtime itself. The platform loader loads the platform classes. The application loader loads everything on the classpath. And each loader asks its parent first — that is the parent delegation model — so a class named java.lang.String always comes from the bootstrap loader and never from your classpath, no matter what you put there.

The runtime data areas are where the program actually runs: the heap for objects, shared between threads; the method area for class metadata; the per-thread JVM stack for method frames; and the per-thread program counter. The division matters because it explains the practical behaviour. Objects are garbage collected because they live on the heap, whereas local variables disappear when their method returns because their frames live on the stack. And unsynchronised access to a field is unsafe because the field lives in the shared heap, where different threads may see different values.

The JVM starts in interpreted mode. The interpreter reads each bytecode instruction and performs the corresponding action directly. That gets the program running quickly, but an interpreter is roughly an order of magnitude slower than compiled code, so a hot method would never be fast enough.

That is where the JIT compiler comes in. The JVM keeps counters on each method, and once a method crosses a threshold the JIT compiler compiles it to native machine code. From then on the compiled version runs instead of the interpreter. The compiler does more than translate: it profiles the method as it runs and then specialises the code accordingly, inlining calls that always receive the same type and pruning branches that are never taken.

Because the compiler specialises based on observed behaviour, the compiled code can become invalid if reality changes. If a call site that was always receiving a String starts receiving a different type, the compiler has to throw away the specialised version and recompile from the interpreter. That is called a deoptimisation, and it is why the JVM keeps both paths around.

public class Main {
    public static void main(String[] args) {
        // Interpreted first, then JIT compiled once the method is hot.
        long start = System.nanoTime();
        long total = 0;
        for (int i = 0; i < 20_000_000; i++) {
            total += i;
        }
        long firstMs = (System.nanoTime() - start) / 1_000_000;

        start = System.nanoTime();
        for (int i = 0; i < 20_000_000; i++) {
            total += i;
        }
        long secondMs = (System.nanoTime() - start) / 1_000_000;

        System.out.println("total        : " + total);
        System.out.println("first run ms : " + firstMs);
        System.out.println("second run ms: " + secondMs);
        System.out.println("the exact numbers vary by machine and JIT state");
    }
}

The output shows two passes over the same loop. The numbers vary from machine to machine and depend on how the JIT happened to behave, so do not quote them — what you are looking at is the shape, where the second pass is usually faster because the loop body has been compiled by then.

The other half of the story is tiered compilation. Rather than compiling a method the first time it gets hot, the JVM compiles it in a simple, quick form first, and only promotes it to the expensive optimising compiler if it stays hot. That keeps start-up fast, which matters a great deal for short-lived processes and serverless workloads where the JIT barely gets a chance to warm up.