Metaspace vs PermGen — Why Java 8 Replaced PermGen

PermGen vs Metaspace — the change

PermGen (Java 7 and earlier)

• Heap-resident region
• Fixed size (-XX:MaxPermSize)
• Held class metadata + interned strings + static fields
• Default ~64–128MB — too small
• OutOfMemoryError: PermGen space was famous

Metaspace (Java 8+)

• Native memory (outside Java heap)
• Grows dynamically by default (no cap)
• Holds only class metadata
• New flag: -XX:MaxMetaspaceSize=512m

Migration timeline

Java 7

• Interned strings moved from PermGen to regular heap
• String pool now subject to normal GC

Java 8

• Static fields moved to regular heap (with Class objects)
• Class metadata moved to Metaspace
• PermGen removed entirely
• -XX:MaxPermSize silently ignored

What Metaspace stores

• Class metadata (method bytecode, constant pools, annotations)
• Just that
• Smaller scope than PermGen

What's NOT in Metaspace

• Interned strings (heap, since Java 7)
• Static fields (heap, since Java 8)
• JIT-compiled code (separate Code Cache)

Why PermGen was removed

1. 1
   Fixed size required tuning (every app needed a different -XX:MaxPermSize)
2. 2
   App server hot redeploy = OOM (Tomcat / JBoss / WebSphere reload webapps; classloader leaks accumulate)
3. 3
   Inflexibility (fixed region inside heap; conflicted with modern GC algorithms)
4. 4
   Default too small (64MB was fine in 2005; modern frameworks need more)

Why Metaspace can still OOM

Almost always classloader leak. Metaspace dynamic, but native memory is finite.

Common leaks

1. 1
   JDBC drivers register with DriverManager (parent classloader); webapp can't unload. Fix: deregister in ServletContextListener.
2. 2
   ThreadLocal not cleared on thread pool workers. Fix: tl.remove() in finally.
3. 3
   Logging framework references. Fix: parent-loaded or explicit unregister.
4. 4
   Dynamic proxies (Spring CGLIB, Hibernate, Mockito generate classes). Fix: mockito-inline.
5. 5
   JSP recompilation (each edit = new class).

Diagnosis

• jcmd VM.metaspace — total Metaspace usage
• jcmd VM.classloader_stats (Java 9+) — list classloaders; look for duplicates
• jstat -class 1000 — live class loading
• Heap dump + Eclipse MAT — 'Leak Suspects' / 'Duplicate Classes'

Production tuning

-XX:MaxMetaspaceSize=512m
-XX:MetaspaceSize=128m
-XX:+HeapDumpOnOutOfMemoryError
-Xlog:gc*,gc+metaspace=info

Container: heap + Metaspace + native overhead < container limit.

Common bugs / misconceptions

1. 1
   Saying Metaspace is on the heap (it's native memory)
2. 2
   Not knowing where interned strings moved (Java 7)
3. 3
   Thinking Metaspace can never OOM
4. 4
   Not setting MaxMetaspaceSize (default is unlimited → leak → native exhaustion → JVM dies)
5. 5
   Still using -XX:MaxPermSize (silently ignored in Java 8+)
6. 6
   Underestimating Mockito Metaspace usage in large test suites

For interviews

Lead with: PermGen was fixed-size, heap-resident, held class metadata + interned strings + static fields, caused frequent OOMs in app servers; Java 8 replaced it with Metaspace (native, dynamic, only class metadata).

Mention: migration timeline, always set MaxMetaspaceSize, classloader leaks still cause OOMs, common leak sources, diagnosis tools.

To stand out: app server hot redeploy was the killer use case for PermGen OOMs; mockito-inline tip for large test suites; container memory budgeting; jcmd VM.classloader_stats (Java 9+).

Recommendation: PermGen (Java 7 and earlier) was a fixed-size heap region holding class metadata, interned strings, and static fields. Its fixed cap (-XX:MaxPermSize, default ~64–128MB) caused the notorious `OutOfMemoryError: PermGen space` — especially in application servers (Tomcat, JBoss) doing hot redeploy, where classloader leaks (JDBC drivers registered with DriverManager, ThreadLocal not cleared, logging context references) prevented old webapp classloaders from being garbage collected, accumulating PermGen until OOM. Java 8 replaced PermGen with Metaspace, which lives in native memory (outside the Java heap), grows dynamically by default, and only stores class metadata (method bytecode, constant pools, annotations). The migration happened in two phases: Java 7 moved interned strings to the regular heap (subject to normal GC); Java 8 moved static fields to the regular heap (with their Class objects) and class metadata to Metaspace. Old -XX:PermSize / -XX:MaxPermSize flags are silently ignored in Java 8+. Metaspace can still OOM (OutOfMemoryError: Metaspace) — the cause is almost always a classloader leak, with common sources being JDBC drivers (deregister in ServletContextListener.contextDestroyed), ThreadLocal not cleared (always remove() in finally), dynamic class generation (Spring CGLIB, Hibernate, Mockito — use mockito-inline for large test suites), and JSP recompilation. Always set `-XX:MaxMetaspaceSize=512m` (or appropriate) in production to fail fast on leaks instead of consuming all native memory or being killed by the Linux OOM-killer. Diagnose with jcmd VM.metaspace and VM.classloader_stats (Java 9+), and analyze heap dumps in Eclipse MAT for duplicate classes (sign of classloader leaks). For containerized deployments, budget: heap (-Xmx) + Metaspace + native overhead must fit in the container memory limit. The mental model: PermGen was fixed-size and heap-resident and constantly OOM'd; Metaspace is dynamic and native-resident, but classloader leaks still strike — cap it explicitly and clean up references aggressively in long-running app servers.