The javac compiler reads .java files and produces .class files containing bytecode instructions. This bytecode is platform-independent — the same file runs on any OS with a JVM. At runtime, the class loader loads these classes, the bytecode verifier validates instruction safety, and the JIT compiler (or interpreter) executes them. Hot methods are identified and compiled to native machine code for performance.

The interpreter executes bytecode instruction-by-instruction without generating machine code — it provides immediate portability but slower execution. The JIT compiler identifies frequently executed code ("hot spots") and compiles them to optimized native code on the fly, caching this compiled code for reuse. Modern JVMs use both: interpreter handles startup, JIT takes over for performance-critical paths once the application warms up.

The heap stores objects and arrays, subject to garbage collection. The stack holds method frames with local variables and return addresses — one per thread, not GC'd. Metaspace (Java 8+) stores class metadata, method signatures, and static fields. The program counter (PC) register tracks the current instruction per thread. The native method area holds stacks for JNI calls. The heap is the primary focus for memory tuning and GC optimization.

OutOfMemoryError occurs when the JVM cannot allocate objects because the heap is full and GC cannot reclaim sufficient memory. Common causes: object leaks (uncanceled event listeners, static collections), excessive object allocation, large memory-mapped files, or metaspace exhaustion from dynamic class loading. Diagnosis steps: enable GC logging (-Xlog:gc*=debug), capture heap dumps with jmap, analyze with Eclipse MAT or VisualVM. Set -Xmx appropriately and profile allocation patterns.

GC identifies and reclaims unreachable objects to free heap space. Serial GC uses a single thread — simple but pauses stop-the-world. Parallel GC (Throughput GC) uses multiple threads for major collections, optimized for batch throughput. G1 GC divides heap into regions, collects garbage incrementally with predictable pauses (default target: 200ms). ZGC and Shenandoah perform concurrent GC with sub-millisecond pauses regardless of heap size, trading some throughput for latency consistency.

Class loading has three phases. Loading uses the bootstrap classloader (for java.* classes), extension classloader (for javax.* and extension JARs), and application classloader (for user classes on classpath/module path). Each classloader has a parent delegation model — it asks its parent to load first. Linking involves bytecode verification (ensuring the instruction stream is type-safe anddoes not cause a stack overflow), and optional preparation (allocating static field space). Initialization executes static initializers and assigns static field default values. A class is not used until it is fully initialized — this prevents partial class states during startup.

The heap stores object instances and arrays — this is where new allocations live and where garbage collection occurs. Heap size is controlled by -Xms (initial) and -Xmx (maximum). Metaspace stores class metadata — the module-info.class, method signatures, field descriptors, and run-time constant pools. Metaspace is not part of the heap; in Java 8 it replaced PermGen, which had a fixed size. Metaspace can grow dynamically (subject to -XX:MaxMetaspaceSize), but exhaustion causes OutOfMemoryError: Metaspace. Primitive types, references, and local variables live on stacks or registers, not in metaspace.

At startup, the JVM interpreter executes bytecode immediately without compilation overhead. The JIT compiler profiles each method's execution frequency — "hot spots" are identified after thousands of invocations. Once hot, the method is compiled to native code with aggressive optimizations (inlining, escape analysis, dead code elimination). This warmup process takes seconds to minutes depending on application size. A short-lived process (under 30 seconds) that exits before warmup completes never benefits from compiled code — it pays the compilation cost but reaps none of the performance gain. This is why serverless Java functions (cold start + short duration) often underperform compared to pre-warmed long-running services.

Choose G1GC for general-purpose servers where throughput matters more than latency consistency — it is the default since Java 9 and handles heaps up to ~100GB well. Choose ZGC when you need consistent sub-millisecond pauses regardless of heap size (large heaps, low-latency trading systems, interactive APIs). ZGC performs most GC work concurrently, but trades some throughput. Choose Shenandoah when you want similar latency guarantees to ZGC but need the implementation to be open-source (Shenandoah is in OpenJDK, while ZGC had a proprietary version until JDK 17). For batch processing or throughput-focused workloads, Parallel GC is still the right choice.

The bytecode verifier validates every .class file before execution — it checks stack operand types, ensures no illegal type conversions, validates method call signatures, and enforces access modifier rules. This prevents a crafted .class file from crashing the JVM or breaching the security sandbox. -Xverify:none disables verification, but this is never safe in production — it was a performance hack for Java 1.0 that has been obsolete for decades. The verifier runs once per class at load time; the overhead is negligible compared to the safety guarantee it provides.

The JIT compiler uses profile feedback — it counts how many times each method and loop is executed. Methods exceeding the compilation threshold (e.g., 10,000 invocations for server mode) are flagged as hot and queued for JIT compilation. The JIT then applies a series of optimization tiers, escalating from simpler to more aggressive transformations. Key optimizations include: method inlining (replacing a method call with the method body to eliminate call overhead), escape analysis (determining if an object escapes a method to enable stack allocation), dead code elimination (removing code whose results are never used), and lock elision (removing synchronized blocks on objects proven to be thread-local).

Generational GC exploits an empirical observation: most objects die young. The heap is divided into generations — young gen (Eden + Survivor spaces) for new allocations, and old gen for objects that survive multiple GC cycles. New objects are allocated in Eden; when young GC runs, it reclaims most young objects cheaply (mark-sweep in Eden). Objects that survive enough young GCs are promoted to old gen. Major GC (which collects old gen) runs less frequently but is more expensive. This division delivers higher throughput than a flat heap because young GC is fast and operates on a small fraction of total memory.

Each thread in the JVM has its own Program Counter (PC) register that stores the address of the currently executing bytecode instruction. When a thread executes a native method (JNI), the PC register is undefined. When the thread is bytecode-executed, the PC holds the index of the current instruction within the current method's bytecode. The PC register enables accurate stack traces in exceptions and debugging — it is how the JVM knows which line number corresponds to the current execution point when a breakpoint is hit or an exception is thrown.

The JVM Specification is a document (JSR 924) that defines the abstract machine — bytecode instruction set, memory model, thread model, and class file format. It is platform-agnostic and deliberately abstract. HotSpot (originally from Sun, now maintained by Oracle and the OpenJDK community) is a concrete implementation of that specification. HotSpot implements the abstract execution engine using C++ code, adds a JIT compiler, multiple GC algorithms, and a performance team that optimizes for real-world workloads. Other implementations (OpenJ9, GraalVM Native, Azul Zing) also implement the same spec but differ in internal architecture.

The JVM's intrinsic locks are built on top of the operating system's synchronization primitives (mutexes and condition variables on Linux, critical sections on Windows). When a thread enters a synchronized block, the JVM attempts a fast-path lock using a biased locking scheme — if the lock is uncontended and the object is not already biased toward a thread, it is assigned to that thread without OS involvement. If contention occurs, the lock escalates to a thin lock (using atomic instructions like CAS), and eventually to a fat lock (full mutex). This escalation is invisible to the developer but affects performance — high contention on a shared lock is a common source of latency spikes.

Escape analysis is a JIT optimization that determines whether an object "escapes" the method that created it — i.e., whether it is visible beyond the creating thread or returned from the method. If an object is proven not to escape, the JIT compiler allocates it on the stack (where it is automatically deallocated when the method exits) instead of the heap (where GC is needed). Stack allocation eliminates allocation cost entirely and removes the need for subsequent GC of that object. This optimization is most impactful in tight loops creating short-lived temporary objects — a classic example is string concatenation in a loop, which JIT can stack-allocate if the StringBuilder never escapes.

Deoptimization is the JVM's ability to revert a previously compiled and optimized method back to interpreted mode — typically because runtime conditions changed and the compiled assumptions are no longer valid. Common triggers: (1) Guarded devirtualization — a method was inlined assuming a single implementation but a second class is loaded that overrides it. (2) Loop peeling — an optimization assumed a loop iterates a specific number of times, but an external value changes. (3) Stack allocation reversal — an object was stack-allocated but later escapes through an unexpected path. Deoptimization causes a brief performance dip (called a "deopt bump") but ensures correctness. It is a hallmark of the JVM's "optimistic" compilation strategy.

jstack prints thread dumps — all live threads, their stack traces, and the locks they are waiting on or holding. This is invaluable for diagnosing deadlocks (threads blocked in Object.wait cycles) and CPU hot spots (a thread in a specific method at high CPU). jmap inspects memory — it can print histogram summaries (jmap -histo ), dump heap to a binary file (jmap -dump:format=b,file=heap.hprof ), and show object retention paths. Heap dumps analyzed in Eclipse MAT or VisualVM reveal memory leaks (objects retaining other objects through static references). Together, jstack and jmap cover the two most common production issues: hangs and out-of-memory errors.

The interpreter executes bytecode instruction-by-instruction with no compilation overhead — startup is fast and memory usage is low. However, each instruction requires a dispatch overhead (reading the instruction, decoding, branching to implementation). For a loop executing 10 million iterations, the interpreter incurs 10 million dispatch overheads. The JIT compiler eliminates this by compiling the hot loop to native code — removing dispatch, using CPU registers directly, and applying vectorization optimizations where the loop body can be SIMD-optimized. In practice, JIT-compiled code runs 10–100x faster than interpreted code for compute-intensive workloads, which is why JIT warmup is critical for performance.

ZGC targets pauses of under 1 millisecond regardless of heap size (tested up to 16TB). It achieves this through concurrent compaction — unlike G1, which stops-the-world to relocate objects, ZGC moves objects while threads run. It uses load barriers (a small instruction inserted before heap accesses) and colored pointers (bits in object references encoding GC state) to track which heap regions are being relocated without stopping threads. When a thread accesses an object being moved, the load barrier catches it, performs the redirect, and continues. The pause only occurs during a brief "init-mark" and "init-remark" sync point — and these are bounded to under 1ms regardless of heap size.