Describe the three top-level subsystems that make up a Java Virtual Machine implementation and what each one is responsible for.

## What "the JVM" actually is The Java Virtual Machine is a *specification* for an abstract computing machine — a stack-based machine that consumes a well-defined binary format (the class file) and executes its instruction set. HotSpot is the best-known implementation and is the reference point in most interviews, but the three-subsystem decomposition below is how essentially every implementation is organised, and it is language-agnostic: the machine never sees Java source. ## 1. The class loader subsystem This subsystem turns a stream of bytes into a usable runtime type, in three ordered stages. **Loading** — a class loader is asked for a type by name, finds its binary representation (a file on disk, a JAR entry, a module in the runtime image, bytes generated at runtime), and hands it to the VM, which creates the internal type structures and a corresponding `Class` object. Loaders are arranged hierarchically — a bootstrap loader for core platform classes, then platform and application loaders, then any user-defined ones — and a loaded type's *identity* is the pair (fully-qualified name, defining loader). Two loaders that each load `com.acme.Foo` produce two distinct, mutually incompatible runtime types. **Linking** — three sub-steps. *Verification* is a static analysis of the bytecode proving it is well-formed and type-safe: the operand stack never underflows or overflows, local variables are not read as the wrong type, branches land on real instruction boundaries. This is why the JVM can execute untrusted class files at speed — the checks are paid once, not per instruction. *Preparation* allocates storage for static fields and sets them to their default values (zero/null) — not to any initializer expression yet. *Resolution* replaces symbolic references in the constant pool ("the method `println` with this descriptor on this type") with direct references; the specification allows this to be lazy, and HotSpot resolves most references on first use. **Initialization** — runs the class initializer (`<clinit>`), which holds static-field initializers and `static {}` blocks. The JVM guarantees this runs exactly once and is safe under concurrent triggering. It is triggered lazily, by events such as the first instantiation, first access to a non-constant static field, or invocation of a static method. ## 2. The runtime data areas These are the memory regions the machine operates in. Some are shared by all threads, some are created per thread. - **Heap** — shared. Every object instance and every array lives here, and it is the region the garbage collector manages. - **Class-metadata area** — shared. Per-type structures: the runtime constant pool, field and method metadata, and the bytecode itself. In HotSpot since Java 8 this is Metaspace, allocated from native memory rather than the Java heap. - **Code cache** — shared. Native code produced by the JIT, plus the interpreter's own generated stubs. - **JVM stack** — one per thread, never shared. It is a stack of *frames*, one per in-flight method invocation, each holding a local-variable array, an operand stack and frame data. Frames are pushed on invocation and popped on return. - **Program-counter register** — one per thread, holding the address of the instruction currently executing (undefined while a native method runs). - **Native method stack** — per thread, for code entered through JNI. ## 3. The execution engine The engine consumes the bytecode of loaded types and makes it happen. - The **interpreter** decodes and executes instructions one at a time. It starts producing results immediately with no compilation latency, but its steady-state throughput is poor. - The **JIT compiler** watches execution. HotSpot counts method invocations and loop back-edges, and when a method crosses a threshold it is compiled to native code and installed in the code cache so later calls jump straight there. Because compilation happens with real profile data in hand, the compiler can inline aggressively and speculate on observed types and branches; when a speculation is later violated, the affected frame deoptimizes back to interpreted execution. - The **garbage collector** is the third leg: it identifies heap objects no longer reachable from the roots and reclaims their space. It is not a passive add-on — compiled code cooperates with it, emitting write barriers and reaching safepoints where the collector can act. - The **native interface** (JNI) lets bytecode call into and be called from native libraries. ## How the three fit together At startup the loader subsystem populates the metadata area with core types; the main class is loaded, linked and initialized; the engine begins interpreting `main` using frames on the launching thread's stack; objects it creates land on the heap; hot methods migrate to the code cache; the collector runs as the heap fills. Every JVM topic an interviewer follows up with — classloader leaks, warmup, GC pauses, Metaspace sizing — is a question about one of these three boxes or the seam between two of them.