JVM Architecture Components
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
The main JVM parts can be grouped into class loading, runtime memory, and execution. Class loaders find class definitions. The JVM then verifies and links each class, and runs its static initialization when the class is first actively used.
Runtime memory includes the shared heap for objects and arrays and the shared method area for class information. Each thread also has its own program counter and JVM stack. Every method call creates a frame with local values and an operand stack.
The execution engine runs bytecode and provides services such as exception handling, synchronization, and automatic memory management. HotSpot uses an interpreter, JIT compilers, a code cache, garbage collectors, and JNI support, although another JVM can implement these services differently.
For example, calling order.total() creates a frame on the current thread's stack. The Order object stays in the shared heap, its class information belongs to shared class data, and a hot version of the method may run as compiled native code. This separates portable JVM concepts from HotSpot implementation details.
JVM Architecture Components
Direct Answer
A useful JVM architecture model has three layers: class loading/linking/initialization, runtime data areas, and execution/runtime services. The specification defines class-file and runtime-area behavior, while components such as HotSpot's interpreter, JIT compilers, garbage collectors, code cache, and JNI are implementation facilities.
Deep Dive & Architecture
Group the areas by ownership
Per-thread areas are created with a thread and cannot be directly used as another thread's JVM stack. The program-counter register identifies the current JVM instruction, and the stack holds that thread's active frames. The heap and method area begin with the VM and are logically shared across threads.
A method call through the JVM
For order.total(), the current thread creates a frame. A local slot contains the order reference, but the Order object remains in shared heap storage. Bytecode moves operands through the frame's operand stack and returns the result to the caller. The frame disappears whether the call returns normally or exits through an uncaught exception; the Order can remain reachable through other references.
Logical JVM areas and physical memory
The JVM specification defines behaviour and lifetime, not a mandatory map of operating-system memory. An implementation may represent frames, object references, metadata, and compiled code in ways that an application cannot observe. Metaspace and code cache are useful HotSpot terms, while method area and JVM stacks are specification terms.
Runtime failures as memory-area evidence
Deep invocation can produce StackOverflowError; inability to provide heap, method-area, or stack expansion can produce an OutOfMemoryError under the specified conditions. The error detail, GC logs, thread dump, class-loading data, and native-memory evidence identify the actual area. One architecture diagram should therefore show ownership and flow without pretending every box is the same kind of component.
Code Example
class JvmComponents {
private final int base;
JvmComponents(int base) {
this.base = base;
}
int add(int value) {
int result = base + value; // value and result belong to this invocation's frame
return result;
}
public static void main(String[] args) {
JvmComponents object = new JvmComponents(40);
System.out.println(object.add(2));
}
}
Check your understanding
Answer these without looking back at the article.
- Which JVM runtime areas are per thread?
- What is stored in a JVM frame?
- Why is a HotSpot JIT compiler not a runtime data area?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.