JVM architecture

the picture

you know how everyone says "the JVM" like it's one thing that runs your code? it's more like a tiny operating system that happens to speak bytecode. it has a loader, a memory manager, a scheduler of sorts, two compilers and a cleaner, all inside one process.

think of a restaurant kitchen. deliveries arrive at the back door and get checked before anything goes on a shelf (the class loader). the recipe binder holds every dish the kitchen knows (metaspace). there's one shared pantry where all the ingredients live (the heap). every cook has their own notepad and a finger on the line of the recipe they're on (a stack and a pc register per thread). a new cook reads each recipe line by line (the interpreter). a cook who has made the same dish ten thousand times does it from muscle memory (JIT-compiled machine code). and someone keeps clearing plates nobody is eating from (the GC).

the boxes the spec actually requires are the class loading pipeline, the heap, a method area, per-thread stacks and pc registers, and something that executes bytecode. everything about how (which GC, whether there's a JIT at all, how an object is laid out in memory) is left to the implementation. on this site that implementation is HotSpot, the JVM inside every OpenJDK build (Temurin, Oracle, Corretto, Zulu, all of them).

follow java Hello through it

here's the smallest program that touches most of the map:

public class Hello {
    public static void main(String[] args) {
        System.out.println("hello");
    }
}

and here's all of main after javac, as javap -c prints it. four instructions:

public static void main(java.lang.String[]);
  Code:
     0: getstatic     #7    // Field java/lang/System.out:Ljava/io/PrintStream;
     3: ldc           #13   // String hello
     5: invokevirtual #15   // Method java/io/PrintStream.println:(Ljava/lang/String;)V
     8: return

press step and watch which parts of the JVM each moment touches.

the numbers are real: -Xlog:class+load printed 415 lines for that run, and Hello was line 402. everything before it was the JDK booting itself, almost all of it mapped straight out of the CDS archive (a pre-parsed snapshot of JDK classes that ships with the JDK, more in AOT and Leyden).

[0.008s][info][class,load] java.lang.Object source: shared objects file
[0.008s][info][class,load] java.io.Serializable source: shared objects file
[0.008s][info][class,load] java.lang.Comparable source: shared objects file
...
[0.021s][info][class,load] Hello source: file:/.../jvm-lab/arch/
...
[0.022s][info][class,load] java.lang.Shutdown$Lock source: shared objects file

what's actually inside the process

your program is one thread. the JVM brings its own crew. this is jcmd <pid> Thread.print against a program whose main just sleeps:

java can only see a handful of those. the compiler threads are real java threads, but HotSpot hides them from your code:

void main() {
    Thread.getAllStackTraces().keySet().stream()
        .map(t -> t.getName() + (t.isDaemon() ? " (daemon)" : ""))
        .sorted()
        .forEach(IO::println);
}

Common-Cleaner (daemon)
Finalizer (daemon)
Notification Thread (daemon)
Reference Handler (daemon)
Signal Dispatcher (daemon)
main

and here's where that idle process's memory went, from -XX:NativeMemoryTracking=summary and jcmd <pid> VM.native_memory summary. this is committed memory (actually backed by RAM), not the much bigger reserved address space:

the spec vs HotSpot

the JVM is two things: a specification (the JVMS, a long PDF) and implementations of it. the spec is deliberately vague about anything that would tie an implementation's hands.

other JVMs exist and make different choices: Eclipse OpenJ9 (its own GC and JIT, a smaller footprint), and GraalVM (HotSpot with the Graal compiler, plus native image, see AOT and Leyden). your bytecode runs on all of them, which is the whole point of the spec.