On top of the JVM you have the JRE (runtime you install to run apps) and the JDK (the JRE plus developer tools you use to build apps).
JVM (Java Virtual Machine) Internals
- Platform independence (write once, run anywhere).
- Memory management (automatic Garbage Collection).
- Runtime optimizations (JIT compiler).
- Security (verifies bytecode before running).
Main Components:
- Class Loader Subsystem – loads .class files.
- Runtime Data Areas – memory model (Heap, Stacks, etc.).
- Execution Engine – runs the code (Interpreter + JIT + GC).
- JNI (Java Native Interface) – connects Java with C/C++ native code.
- Native Libraries – platform-specific libraries.
Class Loader
- Purpose: Responsible for loading .class files into JVM memory so they can be executed.
Steps involved:
- Loading:
- Reads .class bytecode (from disk, JAR, or network).
- Creates a Class object in the heap.
- Linking:
- Verification: Checks bytecode is safe (no illegal memory access).
- Preparation: Allocates memory for static variables.
- Resolution: Replaces symbolic names in bytecode with actual memory references.
- Initialization:
- Executes static initializers (static variable assignments and static blocks) via the special method <clinit>.
Example:
public class MyClass {
static int x = 10; // static variable
static { System.out.println("Static block executed"); } // static block
}
- During initialization, JVM executes:
- x = 10
- The static block: System.out.println("Static block executed")
Class Loader Hierarchy:
- Bootstrap: Loads core Java classes (e.g., java.lang.String, java.util.ArrayList)
- Extension / Platform: Loads standard extension libraries (e.g., javax.crypto.Cipher)
- Application / System: Loads user-defined classes (e.g., com.myapp.Employee)
- Custom: User-created loaders for special needs (e.g., encrypted classes via MyClassLoader)
JVM memory is divided into two categories:
- Runtime Data Areas (used by your Java program).
- Native Memory (used internally by JVM).
- Stores:
- Class metadata – information about class structure (fields, methods, constructors, etc.)
- Runtime Constant Pool (RCP) – symbolic references and constants used by the class
- Static variables: Only the references are in Metaspace; their values live in the heap (in Java 7 and earlier, both references and values were in PermGen)
- Shared by all threads
- Java 7 and earlier → PermGen
- Java 8+ → Metaspace (native memory, grows dynamically)
Memory mapping:
Note: The String Pool is in the heap since Java 7, not in Metaspace.
- Largest memory area. Stores:
- Objects & arrays – all instances of classes
- Static variable values – actual data of static fields
- String Pool – interned strings (special area inside the heap)
- Object-related runtime data – e.g., object headers, GC info
- Shared by all threads.
- Garbage Collected.
Divisions:
- Young Generation (new objects)
- Eden: where new objects are created
- Survivor (S0, S1): objects that survive a GC cycle
- Old Generation (Tenured): long-lived objects
- Humongous Objects Space (G1 GC): very large objects (e.g.,
new int[10_000_000])
Errors:
- OutOfMemoryError: Java heap space → heap is full
- Each thread has its own stack, separate from other threads.
- Purpose: Keeps track of method calls.
Each method call creates a stack frame containing:
- Local variables – method parameters and local variables
- Operand stack – used for intermediate calculations during execution
- Return address – where to continue after the method finishes
- Stack frames are destroyed automatically when a method exits.
Errors:
- StackOverflowError → happens with deep recursion or very large stack usage
- OutOfMemoryError → occurs if JVM cannot create a new thread (because its stack cannot be allocated)
Example:
public class StackExample {
public static void main(String[] args) {
methodA();
}
public static void methodA() {
int x = 10; // stored in stack frame of methodA
int y = 20; // also in methodA's frame
methodB(); // new stack frame created for methodB
}
public static void methodB() {
int z = 30; // stored in stack frame of methodB
}
}
•When methodB finishes, its stack frame is removed, and execution returns to methodA’s frame.
(d) Program Counter (PC) Register
- Each thread has its own PC register.
- Stores: the address of the current bytecode instruction being executed.
Example:
public class PCExample {
public static void main(String[] args) {
int a = 10; // PC points here first
int b = 20; // then PC moves here
int sum = a + b; // then here
System.out.println(sum); // and finally here
}
}
- As the program executes, the PC register updates to point to the next bytecode instruction for the current thread.
- Important: Each thread has a separate PC, so threads execute independently.
(e) Native Method Stack
- Used by the JVM to execute native methods—methods written in languages like C or C++ (not Java).
- Works similarly to the Java stack, meaning it keeps track of method calls, local variables, and return addresses.
- Each thread has its own native method stack, just like the Java stack.
Example:
public class NativeExample {
static { System.loadLibrary("mylib"); } // load C/C++ library
public native void nativeMethod(); // declare a native method
public static void main(String[] args) {
new NativeExample().nativeMethod(); // JVM uses native stack to execute this
}
}
- When nativeMethod() runs, the JVM pushes a frame on the native method stack instead of the Java stack.
- Useful for calling system-level code or performance-critical operations written in C/C++.
- Memory used by the JVM outside of the heap, in the OS-managed native memory.
- Stores JVM internal structures and compiled code, not directly accessible by Java programs.
Main components:
- Code Cache:
- Stores JIT-compiled native code (machine code generated from Java bytecode).
- Helps the JVM execute code faster than interpreting bytecode.
- GC Structures:
- Data the garbage collector uses to track objects, regions, and references.
- Thread Control Structures:
- Information needed to manage threads, such as thread stacks, locks, and scheduling data.
Example:
- When JVM compiles a hot method (frequently used) using JIT, the native instructions are stored in the Code Cache, not the Java heap.
- Thread data like PC register or native stacks are managed here.
- Often called the “CPU of the JVM” because it actually runs your Java code.
Main components:
- Interpreter:
- Reads and executes bytecode line by line.
- Simple but slower for repeated code execution.
- JIT (Just-In-Time) Compiler:
- Converts frequently used (hot) bytecode into native machine code.
- Makes execution much faster than interpreting line by line.
- Garbage Collector (GC):
- Automatically frees memory occupied by objects that are no longer in use.
- Helps prevent memory leaks and manage heap efficiently.
- Purpose: Allows Java programs to call native code written in languages like C or C++.
- Use cases:
- Accessing operating system functions not available in Java
- Interacting with device drivers
- Using high-performance or system-level libraries
Example:
public class JNIExample {
static { System.loadLibrary("mylib"); } // load C/C++ library
public native void nativeMethod(); // declare a native method
public static void main(String[] args) {
new JNIExample().nativeMethod(); // JVM calls C/C++ code here
}
}
👉 In short: JNI is the bridge between Java and native code, letting Java interact with system-level resources or optimized libraries.
- Accessing operating system functions not available in Java
- Interacting with device drivers
- Using high-performance or system-level libraries
- Compilation:
- javac MyClass.java → produces MyClass.class (bytecode).
- Class Loading:
- Class Loader loads the .class file into JVM memory.
- Bytecode Verification:
- JVM checks bytecode for security and correctness before execution.
- Execution:
- Interpreter executes bytecode line by line.
- JIT Compiler optimizes frequently used code paths into native machine code for faster execution.
- Memory Management:
- Objects are created in the heap.
- Garbage Collector (GC) automatically clears objects that are no longer used.
class Employee {
String name; int age;}
public class Test { public static void main(String[] args) { Employee emp = new Employee(); emp.name = "Siraj"; emp.age = 30; System.out.println(emp.name); }}
class Employee {
👉 Let’s build this step by step for Java 8+ (where String Pool is in Heap).
When the program starts, classes are loaded into Metaspace, and string literals are created in the String Pool (Heap).
Employee emp = new Employee();
A new Employee object is created in the Heap. The stack now holds a reference.
emp.name = "Siraj"; emp.age = 30;
The name field now points to the "Siraj" object in the String Pool.
Example: Showing how different types of variables (Local, Instance, Static, String, Primitives) are stored in Java 8+ JVM Memory Model
We’ll use a simple Employee class:
And the main method:
name field now points to the "Siraj" object in the String Pool.We’ll use a simple Employee class:
And the main method:
- Employee and Test classes are loaded into Metaspace.
- Static variable company = "OpenAI" is created and stored in Heap (Class area inside heap, with static fields).
- "OpenAI" literal is placed in the String Pool (inside Heap).
int x = 10; → stored in the stack frame of main().
int x = 10; → stored in the stack frame of main().
Employee emp = new Employee();
- Reference emp stored in stack.
- New Employee object created in heap with default values (name = null, age = 0).
emp.name = "Alice"; emp.age = 30;
- "Alice" is stored in the String Pool (heap).
- name now points to "Alice".
- age is set to 30 directly in the heap object.
- Local variables (x, emp) → stored in stack frame.
- Instance variables (name, age) → stored inside the heap object.
- Static variables (company) → stored in Heap (class area, once per class).
- String literals ("OpenAI", "Alice") → stored in String Pool (inside Heap).
- Class metadata (Employee, Test) → stored in Metaspace.
Example: In Java (any version, including 8+), a static variable belongs to the class, not the object. So,
- If you create two (or more) objects of
Employee, you will still have only one memory location for static String company. - Both objects share the same static variable.
- If one object changes it, the change is visible to all other objects (and even without objects, since it’s tied to the class).
static variable belongs to the class, not the object. So,- If you create two (or more) objects of
Employee, you will still have only one memory location forstatic String company. - Both objects share the same static variable.
- If one object changes it, the change is visible to all other objects (and even without objects, since it’s tied to the class).
JVM Memory View (Java 8+)
Definition: Local variables are variables declared inside a method, constructor, or block.
Key Rules:
- Stored in the stack, inside the stack frame of the method.
- Lifetime = duration of method execution; removed when the method returns.
- Each method call gets a new copy of the variable.
- If the variable refers to an object, the reference is in the stack, but the object itself is in the heap.
Example 1: Simple Local Variable
public class Test {
public static void main(String[] args) {
int x = 10; // local primitive
System.out.println(x);
}
}
Memory Model:
Stack (main method frame)
x = 10
Heap:
(empty, no objects created)
Explanation:
- x is stored in the stack, inside the main method frame.
- Once main finishes execution, the stack frame is destroyed, and x disappears.
- No heap memory is used because x is a primitive.
Example 2: Two Calls to a Method
public class Test {
public static void printX() {
int x = 100; // local variable
System.out.println(x);
}
public static void main(String[] args) {
printX(); // first call
printX(); // second call
}
}
Memory Model:
Stack (Thread main)
───────────────────────────────
Frame: printX (first call)
x = 100
───────────────────────────────
Frame: printX (second call)
x = 100
───────────────────────────────
Heap:
(empty, no objects created)
Explanation:
- First call to printX()
- JVM creates a stack frame for printX.
- Local variable x = 100 is stored inside this frame.
- Second call to printX()
- JVM creates another stack frame for this call.
- This frame has its own copy of x = 100, independent of the first call.
- After each method returns
- The corresponding stack frame is removed.
- Local variables cease to exist.
- Heap:
- No objects are created, so the heap remains empty.
- Thread Safety:
- Each thread has its own stack.
- Local variables in different threads do not interfere.
Key Takeaways
- Local variables live in the stack.
- Primitives (int, double, boolean, etc.) are stored directly in the stack.
- Each method call gets a new stack frame, so local variables are independent for each call.
- Thread-safe: each thread has its own stack; local variables in one thread do not affect others.
Definition: Local variables are variables declared inside a method, constructor, or block.
Key Rules:
- Stored in the stack, inside the stack frame of the method.
- Lifetime = duration of method execution; removed when the method returns.
- Each method call gets a new copy of the variable.
- If the variable refers to an object, the reference is in the stack, but the object itself is in the heap.
public class Test {
public static void main(String[] args) {
int x = 10; // local primitive
System.out.println(x);
}
}
Memory Model:
Stack (main method frame)
x = 10
Heap:
(empty, no objects created)
Explanation:
- x is stored in the stack, inside the main method frame.
- Once main finishes execution, the stack frame is destroyed, and x disappears.
- No heap memory is used because x is a primitive.
Example 2: Two Calls to a Method
public class Test {
public static void printX() {
int x = 100; // local variable
System.out.println(x);
}
public static void main(String[] args) {
printX(); // first call
printX(); // second call
}
}
Memory Model:
Stack (Thread main)
───────────────────────────────
Frame: printX (first call)
x = 100
───────────────────────────────
Frame: printX (second call)
x = 100
───────────────────────────────
Heap:
(empty, no objects created)
Explanation:
- First call to printX()
- JVM creates a stack frame for printX.
- Local variable x = 100 is stored inside this frame.
- Second call to printX()
- JVM creates another stack frame for this call.
- This frame has its own copy of x = 100, independent of the first call.
- After each method returns
- The corresponding stack frame is removed.
- Local variables cease to exist.
- Heap:
- No objects are created, so the heap remains empty.
- Thread Safety:
- Each thread has its own stack.
- Local variables in different threads do not interfere.
Key Takeaways
- Local variables live in the stack.
- Primitives (int, double, boolean, etc.) are stored directly in the stack.
- Each method call gets a new stack frame, so local variables are independent for each call.
- Thread-safe: each thread has its own stack; local variables in one thread do not affect others.
JRE (Java Runtime Environment) Internals
The JRE provides everything needed to run Java apps (but not develop). It includes:
- JVM (execution engine).
- Core Libraries (java.lang, java.util, etc.).
- Security & Config (policies, certificates).
- Deployment (legacy) like Applets/Web Start.
- JVMTI (debugging interface).
👉 It lets you run Java programs.
JDK (Java Development Kit) Internals
- Compiler (javac) → .java → .class.
- Tools → jdb, jconsole, jvisualvm, etc.
- Packagers → jar, jlink, jmod.
- Docs → javadoc, javap.
Final Recap
- JVM = The engine (executes bytecode, manages memory, GC, JIT).
- JRE = JVM + Libraries + Config (runtime to run apps).
- JDK = JRE + Development tools (for developers).
In memory:
- Class info → Method Area (Metaspace).
- Objects → Heap.
- References → Stack.
- String literals → String Pool (inside Heap, not Metaspace).
👉 So,
- End-user who only runs apps → needs JRE.
- Developer who writes & runs apps → needs JDK.
- JVM itself is invisible, but it’s the actual engine inside both.
Feature / Component | JVM (Java Virtual Machine) | JRE (Java Runtime Environment) | JDK (Java Development Kit) |
Purpose | Executes Java bytecode | Provides environment to run Java programs | Provides environment + tools to develop Java programs |
Includes | Execution engine (Interpreter, JIT, GC) | JVM + Core Libraries + Config + Security | JRE + Compiler + Debuggers + Dev Tools |
Developer Tools? | No | No | Yes (javac, jdb, jconsole, etc.) |
Can run programs? | Yes | Yes | Yes |
Can compile programs? | No | No | Yes |
Memory Management | Handles Heap, Stack, PC Register, Metaspace, GC | Uses JVM for memory + provides libraries | Uses JRE + adds dev tools |
Installation (Java 9+) | Comes with JRE/JDK | Merged into JDK (not standalone) | Main distribution (contains everything) |
Typical Users | Internal runtime engine | End-users who just run Java apps | Developers writing and running Java apps |