JVM Architecture Explained

The Three Pillars of the JVM

At a high level, the JVM's architecture is composed of three main subsystems that work together to run your compiled Java code.

1. Class Loader Subsystem: Responsible for finding, loading, and preparing your class files.
2. Runtime Data Areas: The memory model of the JVM, where all data is stored during execution.
3. Execution Engine: Responsible for actually executing the bytecode.

This diagram provides a great mental map of how these components are organized. We will refer back to it as we explore each part in detail.

Let's dive into each of these subsystems.

1. Class Loader Subsystem

Before the JVM can run any code, it must first load the necessary classes. This is the job of the Class Loader Subsystem, which performs this task in three phases: Loading, Linking, and Initialization.

To get a comprehensive overview of this process, let's watch a segment from the "JVM architecture" tutorial.

Let's summarize the key points from the video:

• Loading: This phase finds the .class file on disk (or network) and brings its bytecode into the Method Area. The JVM uses a delegation hierarchy of class loaders:

  1. Bootstrap Class Loader: Loads core Java API classes (like String, Object) from rt.jar. It's the "parent" of all others and is implemented in native code.
  2. Extension Class Loader (renamed Platform Class Loader in Java 9+): Loads classes from the JRE's extension directory.
  3. Application (or System) Class Loader: Loads the classes from your application's classpath.

• Linking: This phase makes the class ready for execution.

  • Verification: A security step. The bytecode verifier checks that the .class file is valid and won't compromise the JVM. If it fails, you get a VerifyError.
  • Preparation: The JVM allocates memory for static variables and initializes them with their default values (e.g., 0 for int, false for boolean, null for objects).
  • Resolution: The JVM replaces symbolic references in the code (like class names) with actual direct memory references.

• Initialization: This is the final step. The initial values specified in your code are assigned to static variables, and any static blocks are executed. This phase is triggered only when the class is first actively used (e.g., by creating an instance or calling a static method).

2. Runtime Data Areas

Once classes are loaded, the JVM needs a place to store data and instructions. These are the Runtime Data Areas, essentially the memory of the JVM. Some areas are shared among all threads, while others are private to each thread.

The following segments of the video we started earlier explain these memory areas clearly.

Let's break down these areas, which are also shown in the architectural diagram at the start of the lesson.

Areas Shared by All Threads

1. Method Area:

   • Stores per-class information such as class metadata, the runtime constant pool, field and method data, and the code for methods.
   • Crucially, static variables are also stored here.
   • Before Java 8, this was a fixed-size part of the heap called PermGen (Permanent Generation). Running out of space here caused an OutOfMemoryError: PermGen space.
   • Since Java 8, PermGen has been replaced by Metaspace, which is allocated from native memory, not the Java heap. This makes it more flexible as it can grow automatically, reducing the frequency of that specific OutOfMemoryError.

2. Heap Area:

   • This is where all objects and arrays are allocated at runtime.
   • It is the largest memory area and is managed by the Garbage Collector.
   • When the heap runs out of space to allocate new objects, the JVM throws an OutOfMemoryError: Java heap space.

Areas Private to Each Thread

When a new thread is created, it gets its own set of these three data areas. This isolation is a key reason why local variables are inherently thread-safe.

3. Java Stack:

   • Stores stack frames. A new frame is created for each method invocation and destroyed when the method completes.
   • Each stack frame contains:
     • Local variables for that method.
     • An operand stack (a workspace for intermediate calculations).
     • A reference to the runtime constant pool.
   • If a thread's computation requires a deeper stack than allowed, a StackOverflowError is thrown. This is common with unterminated recursive calls.

4. PC (Program Counter) Register:

   • A very small memory area that holds the address of the JVM instruction currently being executed. Each thread has its own PC register to keep track of its own execution sequence.

5. Native Method Stack:

   • Similar to the Java Stack, but used for native (non-Java) method invocations, such as code written in C/C++ and called via the Java Native Interface (JNI).

public class MemoryExample {
    private static String staticField = "I'm static";
    private String instanceField = "I'm an instance";

    public void someMethod() {
        int localVariable = 100;
        MemoryExample anotherObject = new MemoryExample();
    }
}

3. Execution Engine

The Execution Engine is the component that reads the bytecode from the memory areas and executes it. It's the true "processor" of the JVM.

The core components of the Execution Engine are:

• Interpreter: Reads bytecode instruction by instruction, interprets it, and executes it. This is straightforward but relatively slow because the same method will be re-interpreted every time it's called.

• Just-In-Time (JIT) Compiler: To improve performance, the JVM uses a JIT compiler. The JVM profiles the code as it runs, identifying "hotspots"—methods that are executed frequently. The JIT compiler then compiles these hotspots into highly optimized native machine code that can be executed directly by the CPU, bypassing the interpreter. This is why Java applications often "warm up" over time, getting faster after an initial period of interpretation and profiling.

• Garbage Collector (GC): This component runs in the background to automatically find and reclaim memory from objects that are no longer referenced, freeing up space in the Heap. We will dedicate an entire future lesson to the GC, but for now, know that it's an essential part of the Execution Engine.

For a deeper perspective suited for senior-level interviews, it's useful to understand that the "Execution Engine" isn't just one thing, but a sophisticated system of interpretation and multiple levels of compilation.

Conclusion

You've now taken a detailed tour inside the JVM. This knowledge is not just academic; it's the foundation for understanding performance tuning, concurrency, and memory management in Java.

Let's summarize the key takeaways:

• JVM Architecture: Comprises the Class Loader Subsystem, Runtime Data Areas, and Execution Engine.
• Class Loading: A three-phase process (Load, Link, Initialize) that uses a delegation model to bring classes into the JVM.
• Runtime Data Areas: The JVM's memory is divided into the Heap (for objects), Method Area/Metaspace (for class data), and per-thread areas like the Java Stack (for local variables and method frames), PC Register, and Native Method Stack.
• Execution Engine: Uses a combination of a slow-but-simple Interpreter and a powerful JIT Compiler to execute bytecode efficiently, while the Garbage Collector manages memory automatically.

In our next lesson, we will focus on a very common interview topic: String, StringBuilder, and StringBuffer. We will explore string immutability and the String pool, a concept that directly relates to the Heap and Method Area we discussed today.