Heap, stack, references and object headers

Every Java thread has a stack: one frame for each method call, holding that call’s local variables and its operand stack. A local variable of a primitive type, such as an int, holds its value right in the frame. A local variable of any other type holds a reference, the address of an object. The objects themselves, arrays included, always live on the heap, which all threads share and the garbage collector manages. Every object on the heap starts with an object header: a mark word, with the identity hash code, the age the collector tracks and the lock state, then a pointer to the object’s class. On 64-bit HotSpot that header takes 12 bytes, and every object is padded to a multiple of 8 bytes. Compact object headers shrink the header to 8 bytes: a product option in JDK 25 and the default in JDK 27. Besides ordinary references, java.lang.ref offers soft, weak and phantom references, which let the collector reclaim an object that you still point to.

Where the values of a program live

Points creates a million small records and measures them with the JVM’s class histogram, the report that jcmd <pid> GC.class_histogram prints, taken before and after. The histogram first runs a full collection, so it counts only objects that are still reachable:

import java.lang.ref.Reference;

/** A million small records on the heap, measured with the class histogram. */
public class Points {
    record Point(int x, int y) {}

    public static void main(String[] args) throws Exception {
        Heap.histogram();
        var before = Heap.histogram();
        Point[] points = new Point[1_000_000];
        for (int i = 0; i < points.length; i++) points[i] = new Point(i, -i);
        Heap.growth(before, Heap.histogram(), "Points$Point", "[LPoints$Point;");
        Reference.reachabilityFence(points);  // keeps the array reachable until the histogram has counted it
    }
}

import java.lang.management.ManagementFactory;
import java.util.HashMap;
import java.util.Map;
import javax.management.ObjectName;

/**
 * Measures reachable objects by class with the JVM's class histogram, the report that jcmd <pid> GC.class_histogram
 * prints, read here through the DiagnosticCommand MBean. A histogram runs a full garbage collection first, so it
 * counts only objects that are still reachable.
 */
final class Heap {
    private Heap() {}

    /**
     * Class name to {objects, bytes}, for every class in the heap. The first call loads the classes that a histogram
     * needs, so a program takes its "before" histogram twice and keeps the second.
     */
    static Map<String, long[]> histogram() throws Exception {
        String report = (String) ManagementFactory.getPlatformMBeanServer().invoke(
            new ObjectName("com.sun.management:type=DiagnosticCommand"), "gcClassHistogram",
            new Object[] { null }, new String[] { String[].class.getName() });
        Map<String, long[]> rows = new HashMap<>();
        for (String line : report.split("\n")) {
            String[] cols = line.trim().split("\\s+");
            if (cols.length >= 4 && cols[0].endsWith(":")) rows.put(cols[3], new long[] { Long.parseLong(cols[1]), Long.parseLong(cols[2]) });
        }
        return rows;
    }

    /** Prints what these classes gained between two histograms: objects, bytes, and bytes per object. */
    static void growth(Map<String, long[]> before, Map<String, long[]> after, String... classNames) {
        long total = 0;
        for (String name : classNames) {
            long[] b = before.getOrDefault(name, new long[2]);
            long[] a = after.getOrDefault(name, new long[2]);
            long objects = a[0] - b[0];
            long bytes = a[1] - b[1];
            total += bytes;
            String each = objects > 1 ? String.format("  %,.1f bytes each", bytes / (double) objects) : "";
            System.out.printf("  %-24s %,10d object%s %,12d bytes%s%n", name, objects, objects == 1 ? " " : "s", bytes, each);
        }
        System.out.printf("  %-24s %10s %,20d bytes%n", "in all", "", total);
    }
}

The program ran three times, on JDK 25 with its default headers, on JDK 25 with -XX:+UseCompactObjectHeaders, and on JDK 27, where compact headers are the default:

from session import run

# The same program three times: JDK 25 with its default object headers, JDK 25 with compact object headers, and JDK 27,
# where compact object headers are the default.
run("""
javac -d out Heap.java Points.java
java -cp out Points
java -XX:+UseCompactObjectHeaders -cp out Points
""")
run("""
java -cp out Points
""", jdk="27")

# JDK in use: openjdk version "25.0.4.1" LTS
$ javac -d out Heap.java Points.java
$ java -cp out Points
  Points$Point              1,000,000 objects   24,000,000 bytes  24.0 bytes each
  [LPoints$Point;                   1 object     4,000,016 bytes
  in all                                        28,000,016 bytes
$ java -XX:+UseCompactObjectHeaders -cp out Points
  Points$Point              1,000,000 objects   16,000,000 bytes  16.0 bytes each
  [LPoints$Point;                   1 object     4,000,016 bytes
  in all                                        20,000,016 bytes
# JDK in use: openjdk version "27"
$ java -cp out Points
  Points$Point              1,000,000 objects   16,000,000 bytes  16.0 bytes each
  [LPoints$Point;                   1 object     4,000,016 bytes
  in all                                        20,000,016 bytes

The frame of main holds the loop counter i as an int, and three references: args, before and points. Every object they lead to is on the heap, and the sizes follow from the headers:

The million records shrank from 24 MB to 16 MB, a third less, while the array stayed the same size. JEP 450, which introduced compact headers, explains why small objects gain most: many workloads have objects of only 32 to 64 bytes on average, so the header is a large share of them.

What the header holds

The mark word comes first and takes 64 bits: it holds the identity hash code once one is computed, the age of the object for the collector, and the bits that say whether the object is locked. The class word follows, a compressed class pointer of 32 bits. Compact object headers fold a 22-bit class pointer into the mark word itself, which is how a header fits in 64 bits. The java documentation says the option saves 4 bytes per object on average, and the garbage collection tuning guide adds its one limit: with compact headers, at most about 4 million classes can be loaded. The saving can vanish in padding. An Integer is 12 + 4 = 16 bytes with the default header and 8 + 4 = 12, padded back to 16, with the compact one, which is why the lesson on choosing collections measured a list of a million Integers at the same size both ways.

Two more mechanisms decide what an object costs. Compressed references store each reference in 4 bytes while the heap is smaller than 32 GB. Escape analysis lets the JIT avoid allocating an object that never leaves its method.

Four strengths of reference

The garbage collector frees an object once nothing can reach it. The package java.lang.ref defines how strongly a reference holds its object, and each kind has one job:

• A strong reference, the ordinary kind, keeps its object alive for as long as the reference itself is reachable.
• A soft reference lets the collector clear its object when memory runs short, and always before an OutOfMemoryError.
• A weak reference is cleared at the first collection that finds its object reachable only through weak references.
• A phantom reference never returns its object; it tells you, through a queue, that the object is gone.

On top of phantom references, Cleaner runs a cleanup action after an object becomes unreachable. Finalization, the old way of doing the same with an overridden finalize(), is deprecated for removal by JEP 421.

Three layouts of a million points, estimated and then measured Pro: opens with a Pro, Premium or Ultimate pass

Soft, weak and phantom references and Cleaner, reproduced Pro: opens with a Pro, Premium or Ultimate pass

Key takeaways

• Each thread’s stack holds one frame per call, with primitives and references; objects and arrays live on the heap.
• An object costs a 12-byte header by default, its fields, and padding to a multiple of 8; a million two-int records took 24 MB.
• Compact object headers cut the header to 8 bytes: the same records took 16 MB with -XX:+UseCompactObjectHeaders on JDK 25, and by default on JDK 27.
• Soft references are cleared when memory runs short, weak ones at the next collection, and phantom ones only report that an object is gone; Cleaner builds on them, and finalize() is on its way out.