Understanding the Java Virtual Machine (JVM): Architecture, Memory Areas, Execution Engine, and Garbage Collection

JVM (Java Virtual Machine)

The JVM enables Java programs to run on any device that provides a Java runtime by interpreting compiled .class bytecode into native machine instructions; the java.exe launcher loads the platform‑specific jvm.dll (or libjvm.so on Unix) where the actual virtual machine operates.

JVM Memory Area Division

The internal structure of the JVM consists of three major components: the Class Loader subsystem, the Runtime Data Area, and the Execution Engine.

Class Loader

Each JVM contains a class‑loader subsystem responsible for loading classes and interfaces and assigning them unique names. Two main loaders exist: the bootstrap (or startup) class loader, which is part of the JVM implementation, and user‑defined class loaders that extend java.lang.ClassLoader.

Execution Engine

The execution engine runs the bytecode loaded by the class loader. It can operate in three modes: interpretation (first‑generation JVM), Just‑In‑Time compilation (JIT, second‑generation), and adaptive optimization (used by modern HotSpot JVMs), which dynamically switches between interpretation and compiled code based on runtime profiling.

Runtime Data Area

The runtime data area includes the Method Area, Heap, Java Stack, Program Counter (PC) register, and Native Method Stack.

Method Area and Heap (shared by all threads)

The Heap stores all objects created at runtime, while the Method Area holds class metadata such as names, modifiers, static variables, and constant pool information. Both are shared across threads.

Java Stack and PC Register (thread‑local)

Each thread has its own Java Stack, which contains frames for method invocations. A frame includes a local variable array (including method parameters and the implicit "this" reference), an operand stack, and a reference to the constant pool. The PC register points to the next bytecode instruction to execute for the current thread.

Native Method Stack

The Native Method Stack stores state for native (non‑Java) method calls, typically mapping to the underlying C stack when the JVM invokes native code.

JVM Garbage Collection

Modern JVMs use generational garbage collection, dividing the heap into Young, Tenured (Old), and Permanent (Perm) generations. Collection types include:

Minor GC – collects the Young generation.

Full GC – collects the Old generation and optionally the Permanent generation.

Explicit GC – triggered by System.gc(), which performs a Full GC.

Object references are classified into four types, influencing collection behavior:

Strong references – default; objects are reclaimed only when no strong references remain.

Soft references – cleared only when memory is low, useful for caches.

Weak references – cleared on any GC cycle.

Phantom references – used to detect when an object has been reclaimed.

Young Generation

The Young generation consists of an Eden space and two Survivor spaces. New objects are allocated in Eden; when Eden fills, surviving objects are copied to a Survivor space, and eventually promoted to the Tenured generation.

Tenured (Old) Generation

Stores long‑lived objects that have survived multiple Young‑generation collections.

Permanent Generation (Perm)

Holds class metadata, static fields, and interned strings. Although not directly reclaimed by the typical heap GC, it can be resized via the -XX:MaxPermSize option for applications that dynamically generate many classes.

Source: blog.csdn.net/stanlee_0/article/details/51171382