HotSpot replaced the permanent generation with metaspace in Java 8. What concretely changed, and which data moved out of the permanent generation before that, in Java 7?

## What the permanent generation was Until JDK 7 inclusive, HotSpot kept the runtime description of loaded classes in a heap region called the **permanent generation**. "Permanent" reflected the original assumption that classes load once and stay forever. It was sized at startup with `-XX:PermSize` and `-XX:MaxPermSize`, collected only during full collections, and it held three quite different kinds of data: 1. class metadata (type structures, method bytecode, runtime constant pools, dispatch tables); 2. the **interned-string pool** contents; 3. **static field storage** for each class. ## Step one: Java 7 moves strings and statics to the heap JDK 7 relocated the interned-string pool and static fields onto the ordinary Java heap. Two mechanics matter. - The **string table** is a native hash table, but from JDK 7 on it stores *references* to `String` objects that live on the heap. `String.intern()` therefore produces a normal heap object. Since JDK 11 that table is a resizable concurrent hash table, so `-XX:StringTableSize` sets only the initial bucket count and rarely needs tuning. - **Static field values** moved into the `java.lang.Class` mirror object, itself a heap object. Why it mattered: in the PermGen era, heavy interning (parsers, XML tooling, code that interned user input) could exhaust `MaxPermSize` while the object heap was nearly empty, and those strings were only collectable during a full collection of a region tuned for permanence. Once they were plain heap objects, an unreferenced interned string became garbage like anything else, collected by the ordinary young/old machinery. ## Step two: Java 8 removes the permanent generation JDK 8 deleted PermGen and moved the remaining class metadata into **metaspace**, native memory outside the Java heap. The changes a candidate should be able to list: - `-XX:PermSize` and `-XX:MaxPermSize` no longer exist. Passing them produces a warning and they are ignored; `java.lang.OutOfMemoryError: PermGen space` cannot occur. - Metadata is now **committed from the OS on demand** and is unbounded by default. You opt into a cap with `-XX:MaxMetaspaceSize`; exceeding it raises `OutOfMemoryError: Metaspace` instead of the old PermGen error. - `-XX:MetaspaceSize` is *not* a minimum allocation. It is the **initial high-water mark**: the first time committed metaspace crosses it, the JVM runs a collection to attempt class unloading, then adjusts the mark up or down according to how much was reclaimed. - Metadata is allocated from per-class-loader arenas and freed wholesale when a loader is unloaded, so metaspace reclamation is tied to class-loader lifecycles rather than to a compacting heap collector. - The memory-pool beans exposed by the runtime changed names accordingly: monitoring dashboards that watched "PS Perm Gen" had to be repointed at "Metaspace" and "Compressed Class Space". ## Why native memory was the right target Three independent pressures pushed the same way. Metadata volume scales with **class count**, not with allocation rate, so pinning it inside the object heap forced an artificial split of one budget. Application servers and frameworks that redeploy modules or generate proxies routinely blew a fixed ceiling that the machine had ample memory to satisfy. And metadata is unlike Java objects: it is never relocated, and it becomes garbage only in loader-sized units, which is a poor fit for a moving collector. ## What did *not* change The removal was a relocation, not a relaxation of class-unloading rules. Metadata still becomes reclaimable only when its class loader becomes unreachable, so a loader kept alive by a stray reference retains all of its metadata exactly as it did in the PermGen era. The failure mode moved from a bounded region with an obvious error to a native region that, by default, grows until something worse happens. That is precisely why setting an explicit maximum is standard practice in memory-limited containers. ## Answering it crisply Say: PermGen was a fixed heap region holding metadata, interned strings and statics. Java 7 moved strings and statics to the heap. Java 8 deleted the region and moved metadata to native metaspace, which grows on demand, is capped only via `-XX:MaxMetaspaceSize`, and is reclaimed per class loader. Then name one operational consequence: process memory now exceeds `-Xmx` by the metadata footprint.