Where Does Java Keep Its Constants? A Deep Dive into JDK Runtime, String, and Static Constant Pools

JVM Runtime Memory Layout

The JVM divides the process memory into five logical regions:

Program Counter (PC) register – a per‑thread pointer to the next bytecode instruction.

Java stack (VM stack) – stores frames for method invocation, local variables and operand stacks.

Native method stack – used by native (JNI) code.

Method area – holds class metadata, static fields, and the runtime constant pool.

Heap – the runtime data area for objects and arrays.

Static Constant Pool

Each compiled .class file contains a constant pool that stores literals (numeric, string, class references, etc.) and symbolic references used by the bytecode. The pool entries have a uniform binary format:

cp_info {
    u1 tag;        // identifies the entry type
    u1 info[];     // type‑specific data
}

Common entry types include CONSTANT_Class, CONSTANT_Utf8, CONSTANT_Fieldref, CONSTANT_Methodref, …

Example structures:

CONSTANT_Class_info {
    u1 tag;          // 7
    u2 name_index;   // index to a CONSTANT_Utf8 entry
}

CONSTANT_Utf8_info {
    u1 tag;          // 1
    u2 length;       // number of bytes
    u1 bytes[length]; // UTF‑8 encoded characters
}

The static constant pool resides in the .class file and can be inspected with javap -verbose <ClassName>.

Runtime Constant Pool

When a class is loaded, the JVM copies the class‑file constant pool into the method area, creating a runtime constant pool . This pool is mutable: during class resolution symbolic references are replaced by direct references, and new constants (e.g., String literals created by String.intern()) may be added.

String Constant Pool

String literals are stored in a dedicated string constant pool . After the verification and preparation phases of class loading, each distinct literal is entered once; subsequent String creations first check this pool and reuse the existing instance if present.

Evolution of Constant‑Pool Placement Across JDK Versions

JDK 1.6 and earlier – Both the runtime constant pool and the string constant pool are located in the method area, which is implemented as the Permanent Generation (PermGen).

JDK 1.7 – The string constant pool is moved from PermGen to the heap, while the static constant pool (class‑file constant pool) remains in the method area (still PermGen).

JDK 8 and later – PermGen is removed and replaced by Metaspace (a native‑memory area). The string constant pool stays on the heap, and the runtime constant pool is now allocated in Metaspace.

Key Takeaways

The static constant pool is a compile‑time artifact stored in each .class file.

During class loading the static pool is copied into the method area, forming the mutable runtime constant pool.

String literals are deduplicated in a separate string constant pool; since JDK 7 the pool resides on the heap.

JDK 8 introduced Metaspace, moving the runtime constant pool out of PermGen into native memory.

Understanding these placements helps diagnose class‑loading behavior, memory‑usage patterns, and performance implications of constant‑pool operations.