What Are Young, Old, and Metaspace Generations?

The young generation holds newly allocated objects. It is split into two spaces: the Eden, where almost every object is born, and two survivor spaces, which hold objects that have survived at least one collection. The old generation holds objects that have survived many collections and are assumed to be long-lived — the classic examples are caches, connection pools and anything held in a static field.

Metaspace is not part of the Java heap. It holds the class metadata: the loaded class objects, their constant pools, their method and field definitions and their bytecode. It replaced the permanent generation, which used to live inside the heap but was never collected. The practical consequence is that Metaspace is native memory, sized by the operating system rather than by your heap setting, and it is bounded by the machine rather than by a flag you set for the heap. So a class-loading leak shows up as native memory growth rather than as a Java heap problem.

How objects move between the areas is the part worth understanding. When the young generation fills up, a minor collection runs. Objects that are still alive are copied from Eden into a survivor space, and the survivor spaces swap roles. Objects that survive enough minor collections get promoted to the old generation. A major collection then collects the old generation, and it is far more expensive because it has to trace a much larger object graph, often with the young generation collected at the same time.

Here is the same thing as runnable code:

public class Main {
    public static void main(String[] args) {
        Runtime runtime = Runtime.getRuntime();

        System.out.println("max heap MB   : " + runtime.maxMemory() / (1024 * 1024));
        System.out.println("total heap MB : " + runtime.totalMemory() / (1024 * 1024));
        System.out.println("free heap MB  : " + runtime.freeMemory() / (1024 * 1024));
        System.out.println("used heap MB  : " + usedMb(runtime));

        // Allocate a little and watch the numbers move.
        java.util.List<byte[]> ballast = new java.util.ArrayList<>();
        for (int i = 0; i < 30; i++) {
            ballast.add(new byte[1024 * 1024]);
        }
        System.out.println("after 30MB    : used " + usedMb(runtime) + " MB");
        System.out.println("ballast size  : " + ballast.size());
    }

    static long usedMb(Runtime runtime) {
        return (runtime.totalMemory() - runtime.freeMemory()) / (1024 * 1024);
    }
}

Most collectors use a write barrier and a remembered set to keep the old generation from being traced during a young collection. The remembered set then tells the collector which old objects might point back into the young space, so it only has to examine those rather than the whole old generation. That is what makes a minor collection cheap even when the old generation is huge.

The algorithm in the young generation is copying. Objects are copied from Eden into the survivor space, and the survivors are compacted in the process, so the collection both frees memory and removes fragmentation. An object that has survived a minor collection is tenured — it is promoted to the old generation, or kept in the survivor space and copied again next time.

Two things decide when promotion happens, and they differ between collectors. The tenuring threshold is an age counter: an object that has survived a certain number of collections is promoted regardless of anything else. The dynamic age rule is a refinement: the threshold is adjusted dynamically so that the survivor space stays at a roughly constant occupancy, which stops the survivor space overflowing when allocation rates are very high.

The cost of a copy is proportional to the number of live objects, not to the number of dead ones. That is the whole design insight: the young generation is cheap to collect precisely because almost nothing in it is still alive. It also means that a young collection that happens while a large live data set is in Eden can be surprisingly expensive — which is one reason large long-lived arrays are allocated carefully rather than in a loop.

Here is the same thing as runnable code:

public class Main {
    public static void main(String[] args) {
        // Long-lived objects get promoted out of the young generation.
        java.util.List<byte[]> survivors = new java.util.ArrayList<>();
        for (int round = 0; round < 3; round++) {
            survivors.add(new byte[512 * 1024]);
            System.gc();   // a hint, not a command
            System.out.println("round " + round
                    + " - live objects: " + survivors.size()
                    + ", used heap: " + usedMb() + " MB");
        }

        // Short-lived garbage is collected cheaply in the young generation.
        for (int i = 0; i < 2000; i++) {
            byte[] rubbish = new byte[16 * 1024];
            rubbish[0] = (byte) i;
        }
        System.out.println("after garbage  : used heap: " + usedMb() + " MB");
    }

    static long usedMb() {
        Runtime runtime = Runtime.getRuntime();
        return (runtime.totalMemory() - runtime.freeMemory()) / (1024 * 1024);
    }
}

Metaspace is the native-memory area that holds class metadata — the runtime representation of every loaded class, its constant pool, its methods, its fields and its bytecode. It sits outside the Java heap, in the memory the JVM requests from the operating system.

It replaced the permanent generation, which was a special area inside the heap holding the same information. The old design had two problems. The permanent generation was never collected, so a class-loading leak — loading a new class for every request, say — could never be reclaimed and the process would eventually die. And its size had to be tuned with a separate flag, which meant that sizing the heap and sizing the class metadata were two independent decisions that were easy to get wrong.

Metaspace fixes both. Because it is native memory, it grows automatically as classes are loaded and it is reclaimed when the class loader that loaded them becomes unreachable. And because the operating system bounds it rather than the JVM, you generally do not set a size for it at all — although you can, and you should set a maximum if you want the process to fail rather than to consume the whole machine.

For an interview the short version is this: the permanent generation was removed because class metadata was moved out of the heap into native memory, which made it automatically reclaimable and removed the need for a separate sizing flag. The heap is now purely for objects, and the two kinds of memory problem — too many objects and too many classes — are diagnosed in completely different places.