Guide
What are the parts of the JVM?
The main parts of the Java Virtual Machine: class loading, the runtime data areas, the execution engine, garbage collection, the native interface and the platform beneath, and how they connect.
The main parts
Class loading
The class loader finds class files and turns them into classes the JVM can use.
On the map: Class loader subsystem. Finds class bytes, turns them into run-time classes, links them and runs their static initialization, on demand.
Open class loadingMemory
Runtime memory holds what a running program needs: objects, method calls in progress and class information.
On the map: Runtime data areas. The memory areas the JVM uses while running a program: some shared by all threads, some private to each thread.
Open memoryExecution engine
The execution engine runs bytecode instructions, and compiles busy code into machine code.
On the map: Execution engine. Turns bytecode into work on the CPU: an interpreter first, then JIT-compiled machine code for hot code.
Open execution engineGarbage collection
The garbage collector finds objects the program can no longer reach and reclaims their memory.
On the map: Garbage collector. Automatic storage management: finds objects the program can no longer reach and reclaims their memory.
Open garbage collectionNative interface
The native interface lets Java call code written for the operating system, such as C libraries, and lets that code call back.
On the map: Native interface. The boundary between Java and native code: JNI, and since JDK 22 the Foreign Function & Memory API.
Open native interfacePlatform
The operating system and processor that the JVM itself runs on.
On the map: Operating system and hardware. What the JVM runs on: an OS providing processes, threads, virtual memory and I/O, and a CPU executing machine code.
Open platform
Runtime data areas
JVM specificationThe memory areas the JVM uses while running a program: some shared by all threads, some private to each thread.
Simply put
While your program runs, the JVM keeps data in several places. Objects live in the shared heap. Information about classes lives in the shared method area. Each thread gets its own stack for method calls and its own PC register that remembers which instruction it is on.
What a developer sees
In a running program, objects and arrays created with new live in the heap. Each method call gets a frame on the calling thread’s stack, holding its parameters and local variables. A class’s code and constants belong to the method area (HotSpot: Metaspace); HotSpot keeps static field values in the class’s java.lang.Class object, in the heap.
Threads share the heap and the method area but never each other’s stacks: a local variable is never seen by another thread, though the object it refers to might be. Errors point to the area: StackOverflowError (a stack), OutOfMemoryError: Java heap space (the heap), OutOfMemoryError: Metaspace (HotSpot’s method area).
Picture it
A workshop: a shared storeroom for finished items, a binder of instructions everyone reads from, and for each worker a pile of trays, one tray per job in progress.
- The shared storeroom
The heap, where objects live
- The instruction binder
The method area: each class’s code and constants
- A worker
A thread
- The worker’s pile of trays
The thread’s JVM stack, one frame per method call
Where the picture stops working
These are logical areas, not rooms side by side: HotSpot lays them out in one process’s memory as it sees fit. And a tray never holds an item from the storeroom, only a note saying where it is (a reference).
Deep dive: the specification and HotSpot in detail
JVMS §2.5 defines six logical areas. Created at JVM start-up and shared by all threads: the and the (with one per class). Created with each thread and private to it: the , the and the .
These are logical areas. HotSpot maps them onto its own structures: the Java heap managed by the selected GC; Metaspace (native memory) for class metadata; java.lang.Class mirrors and interned strings in the Java heap; one native thread stack holding both Java and native frames; and the interpreter's bytecode pointer as the pc.
The specification requires
Six areas with defined lifetimes and error conditions (StackOverflowError, OutOfMemoryError). No addresses, sizes or layouts.
HotSpot (JDK 25) does
HotSpot JDK 25: Java heap (G1 by default), Metaspace, code cache, one native stack per thread with guard zones, and a bytecode pointer register in the interpreter.
Common misconceptions
Objects live on the stack and primitives live on the heap (or the reverse).
Local variables, primitive or reference, live in the frame on the thread's stack; objects and arrays live in the heap. A reference variable on the stack *refers to* an object in the heap.
Sources
- SpecJVMS §2.5 Run-Time Data Areas(opens in a new tab)
Defines the data areas used during program execution and which are per thread. · Java SE 25
- SpecJVMS §2.13 Public Design, Private Implementation(opens in a new tab)
Implementations may translate bytecode to native code and choose their own internals. · Java SE 25