About This Route
Central question: What actually happens when Java code runs on the JVM?
This route maps Java source, class files, JVM runtime structures, and observable runtime behavior. It explains how Java source becomes class files, how a JVM process turns those artifacts into runtime structures, and how memory, method execution, threads, garbage collection, JIT compilation, pauses, and diagnostics fit together.
The practical reference point is HotSpot/OpenJDK, because that is the JVM implementation most Java developers encounter.
Contents
- What Does It Mean for Java Code to Run on the JVM?
- From Java Source Code to Class Files
- What a Class File Contains
- How the
javaCommand Starts a JVM Process - Class Loading, Linking, and Initialization
- Runtime Data Areas: Heap, Stacks, Metaspace, and Threads
- Stack Frames, Local Variables, and the Operand Stack
- Objects, References, and Heap Allocation
- Method Invocation, Dynamic Dispatch, and Exceptions
- Threads, Monitors, and Memory Visibility
- Garbage Collection as Reachability and Reclamation
- JIT Compilation, Warmup, and Runtime Optimization
- Safepoints, Pauses, and Runtime Coordination
- Diagnosing JVM Problems: OOM, GC Logs, Stack Traces, and Thread Dumps
- Final Mental Model: Java Concepts and Their JVM Runtime Counterparts
Reading Path
Read the notes in order. The path starts with what it means for Java code to run, then separates source code, class files, bytecode, the JVM process, runtime memory, method execution, objects, threads, garbage collection, JIT compilation, pauses, and diagnostic artifacts.
What You Will Understand
- Java source code is not what the JVM directly executes.
- Class files, bytecode, runtime memory areas, stack frames, objects, and threads are distinct parts of the runtime model.
- Garbage collection, JIT compilation, safepoints, and pauses are runtime mechanisms rather than vague JVM magic.
- Stack traces, GC logs, thread dumps, and memory errors are useful when connected back to the structures that produced them.