Understanding Java Class Loading Mechanism and Runtime Data Areas

Class Loading Mechanism (Official Introduction)

https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-5.html Chapter 5. Loading, Linking, and Initializing The Java Virtual Machine dynamically loads, links and initializes classes and interfaces. Loading finds the binary representation of a class or interface and creates it; linking combines it into the runtime state; initialization executes the class or interface initialization method (§2.9.2).

According to the specification, Java class loading consists of three steps: Loading, Linking, and Initializing.

Preliminary Understanding of Runtime Data Areas

https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-2.html#jvms-2.5 2.5. Run‑Time Data Areas The JVM defines various run‑time data areas used during program execution. Some are created at JVM start‑up and exist until the JVM exits, while others are per‑thread and are created when a thread starts and destroyed when it ends.

The JVM runtime data areas can be divided into five main regions:

Method Area – stores loaded class metadata, constants, and static variables (Metaspace in JDK 1.8+, Permanent Generation in JDK 1.7).

Heap – shared memory that holds object instances.

Java Virtual Machine Stacks – thread‑private stacks that store local variable tables.

Program Counter (PC) Registers – per‑thread pointer to the current bytecode instruction.

Native Method Stacks – used for executing native (non‑Java) methods.

Method Area (Thread‑Shared Memory)

Metaspace >= JDK 1.8 Permanent Generation >= JDK 1.7

The Method Area stores class metadata, constant pool, static variables, and compiled code. It is shared by all threads, thus not thread‑safe, and an OutOfMemoryError is thrown when it runs out of space.

Run‑Time Constant Pool (a small digression)

2.5.5. Run‑Time Constant Pool A run‑time constant pool is a per‑class or per‑interface representation of the constant_pool table in a class file.

The constant pool contains literals and symbolic references generated at compile time; after class loading, it resides in the Method Area.

Heap (Thread‑Shared Memory)

The Heap stores instances of classes. Example code that creates objects:

new User();
Class clazz = Class.forName("");

If the Heap cannot allocate memory and cannot expand, an OutOfMemoryError is thrown.

Java Virtual Machine Stacks (Thread‑Private)

Each method invocation creates a stack frame that contains a local variable table, operand stack, dynamic linking information, and a return address.

Example pseudo‑code:

public static void main(String args[]) {
  a();
}
static void a() {
  b();
}
static void b() {
  c();
}
static void c() {
  System.out.println("hello");
}

The diagram below (omitted) illustrates the push‑pop process of stack frames as the methods are called and return.

Stack Frame

Each stack frame corresponds to a called method and includes:

Local Variable Table – stores method parameters and local variables.

Operand Stack – stores intermediate computation results.

Reference to the Run‑Time Constant Pool.

Return Address – where execution resumes after the method returns.

Additional information.

Program Counter Registers

The PC register records the address of the next bytecode instruction for Java methods; it is empty for native methods.

Native Method Stacks

Native methods are executed on the native method stack. Example native method declaration:

public native int hashCode();

Class Loading Process Revisited

Class loading involves loading the class file into memory, verifying, preparing, and initializing it, ultimately producing a java.lang.Class object.

Loading (Load)

Obtain the binary byte stream of the class via its fully qualified name.

Convert the byte stream into the runtime data structures in the Method Area.

Create a java.lang.Class object in the Heap to serve as an access point.

Linking (Link)

Linking consists of three sub‑steps: Verification, Preparation, and Resolution.

Verification

File format verification

Metadata verification

Bytecode verification

Symbolic reference verification

Preparation

Allocate memory for static variables and assign default values.

Resolution

Transform symbolic references in the constant pool into direct references.

Initialization (Initialize)

Execute static variable initializations and static blocks.

ClassLoaders

The JVM provides several built‑in class loaders:

Bootstrap ClassLoader – loads core library classes from $JAVA_HOME/jre/lib/rt.jar (implemented in native code).

Extension ClassLoader – loads extension libraries from $JAVA_HOME/jre/lib/*.jar or directories specified by -Djava.ext.dirs .

App ClassLoader – loads classes from the application classpath.

Custom ClassLoader – user‑defined loaders extending java.lang.ClassLoader (e.g., Tomcat, JBoss).

Parent‑Delegation Model

The loading process follows a parent‑delegation hierarchy. When a class is requested, the current loader first checks if it has already loaded the class; if not, it delegates the request to its parent. This continues up to the Bootstrap ClassLoader. Only when the parent cannot find the class does the child attempt to load it. This design prevents multiple loaders from loading the same system class (e.g., java.lang.String ), ensuring a single definition.

Some containers, such as Tomcat, break the strict parent‑delegation rule for web applications, allowing their own class loader to load non‑core classes before delegating to the parent.

Conclusion

We have seen how a Java source file is compiled into a .class file, how the JVM loads that file into memory, and the structure of the runtime data areas. The next article will dive deeper into the JVM memory model and garbage‑collection mechanisms.