Once the class loading process—comprising loading, verification, preparation, resolution, and initialization—concludes, the execution engine utilizes the runtime data area to process classes. This memory region acts as a critical bridge between storage and the CPU, managing real-time operations for both the operating system and applications. The Java Virtual Machine specifies distinct memory regions that persist for the lifetime of the VM or are tied to specific thread lifecycles.

Runtime Data Area Architecture

The JVM memory layout dictates strategies for allocation and management, ensuring stability. While implementations vary, the standard specification divides memory into thread-private and thread-shared regions.

• Thread-Private: Program Counter, Java Virtual Machine Stack, Native Method Stack.
• Thread-Shared: Heap, Metaspace (or Permanent Generation in older versions), Code Cache.

A single Runtime instance exists per JVM, serving as the central environment for these memory structures.

Thread Execution Model

A thread represents a single unit of execution within a process. The JVM supports concurrent execution through multiple threads. In the HotSpot implementation, Java threads map directly to native operating system threads. When a Java thread starts, a corresponding native thread is spawned; upon termination, the native thread is reclaimed. The OS scheduler assigns these native threads to available CPU cores, invoking the run() method once initialization is complete.

Internal System Threads

Beyond the user-defined main thread and its children, the JVM operates several background threads visible via debuggging tools:

• VM Thread: Operations requiring a safepoint, such as stop-the-world garbage collection, stack dumping, or thread suspension.
• Periodic Task Thread: Handles time-based events and periodic scheduling.
• GC Thread: Supports various garbage collection algorithms.
• Compiler Thread: Performs Just-In-Time (JIT) compilation of bytecode to native code.
• Signal Dispatcher Thread: Receives external signals and dispatches them internally for handling.

The Program Counter Register

The Program Counter (PC) Register mimics the physical registers found in CPU architecture. It holds the address of the next instruction to be executed. This small, high-speed memory space is crucial for control flow.

Functionality and Lifecycle

According to the JVM specification, every thread possesses its own PC register. It is thread-private and exists only while the thread is active. At any given moment, a thread executes a single method. The PC register stores the address of the current JVM instruction being executed. If the thread is executing a native method, the register value remains undefined.

This register acts as the control flow indicator, enabling branching, loops, jumps, exception handling, and thread recovery. The bytecode interpreter modifies the PC value to select the subsequent instruction. Notably, this is the only memory area in the JVM specification that does not throw an OutOfMemoryError.

Code Execution Example

Consider a method that calculates the sum of two integers:

public int computeSum() {
    int valueA = 5;
    int valueB = 6;
    return valueA + valueB;
}

The corresponding bytecode instructions would appear as follows:

0: iconst_5
1: istore_1
2: iconst_6
3: istore_2
4: iload_1
5: iload_2
6: iadd
7: ireturn

Context Switching and Privacy

The PC register stores the bytecode instruction adress to facilitate thread switching. Since CPUs switch between threads rapidly, the system must know where to resume execution when a thread is scheduled again. The bytecode interpreter relies on the PC register to identify the next instruction.

Privacy is essential because multiple threads compete for CPU time slices. In a concurrent environment, a single CPU core executes only one thread's instruction at any specific nanosecond. Frequent interruptions and resumptions ocurr due to time slicing. To ensure accuracy during these switches, each thread maintains its own PC register and stack frame. This isolation prevents interference, allowing independent calculation and precise tracking of execution progress across concurrent threads.