In the HotSpot JVM, what data is stored in the metaspace region, and why does the JVM keep that data in native memory rather than inside the Java heap?

## What class metadata is Loading a class does far more than remember the bytes of a classfile. The JVM builds native structures that the interpreter and the JIT compiler read on every operation: - a **type structure per class** (HotSpot calls it `InstanceKlass`): superclass link, implemented interfaces, instance-field layout, access flags, initialization state; - **method metadata**: signature, exception table, line-number and local-variable tables, and the **bytecode array itself**; - the **runtime constant pool**: the resolved form of the classfile constant pool, holding symbolic references to other classes, methods and fields plus their resolution state; - **dispatch tables**: the vtable and itable that make a virtual or interface call an indexed jump rather than a search; - profiling counters the JIT uses to decide what to compile. Collectively this is *class metadata*, and the native region holding it is **metaspace**. ## What is deliberately not in metaspace This distinction is the usual follow-up. On the heap you find: the `java.lang.Class` mirror object for each type (it is a normal Java object with a normal object header); the **values of static fields**, which are stored in that mirror; interned `String` instances; and every array or instance your code allocates. Metaspace holds the machine's private description of a type; the heap holds objects that Java code can reference. ## Why native memory Before JDK 8 this metadata lived in the permanent generation, a region *inside* the Java heap with its own fixed maximum. That design had three practical problems. 1. **Two budgets, one knob set.** A container might need a large object heap and few classes, or a modest heap and thousands of classes from many deployed applications. With metadata inside the heap, every deployment had to guess a split in advance. 2. **A fixed ceiling that was reached in normal operation.** The permanent generation was sized once at startup. Applications that generated proxies or redeployed modules would exhaust it even though the machine had free memory. 3. **Awkward collection.** Metadata is not shaped like Java objects: it is not moved, and it becomes garbage only in whole class-loader-sized units. Making a tracing, compacting collector responsible for it added complexity for little benefit. Moving the data into native memory addresses all three. Metaspace is **committed from the OS as classes are loaded** and, in HotSpot, is limited only by available native memory unless you set `-XX:MaxMetaspaceSize`. Growth is elastic: a typical service loads its classes during warm-up, metaspace stabilises, and the knob is never touched. ## How it is reclaimed Metaspace is allocated per class loader: each loader gets its own arena of chunks. Because every piece of metadata belongs to exactly one loader, the JVM can free an entire arena at once when that loader becomes unreachable and its classes are unloaded during a collection cycle. There is no compaction of individual metadata blocks and no per-class free. This is why a class loader that stays reachable keeps *all* of its classes' metadata alive. ## Consequences worth stating in an interview - Metaspace usage is **not visible in a heap dump's object graph as class metadata**; it is native memory, reported separately by the runtime's memory-pool beans and by `jcmd <pid> VM.metaspace`. - Because the default is unbounded, a runaway class generator degrades into native-memory exhaustion of the whole process rather than a bounded, clearly attributed failure. In containers it is common practice to set an explicit `-XX:MaxMetaspaceSize` so the JVM stops itself before the OS kills the container. - `-Xmx` does **not** cover metaspace. A JVM's resident memory is always larger than the maximum heap, and metadata is one of the reasons. ## The short version Metaspace = native storage for the runtime description of loaded classes. Native because its size is driven by class count rather than allocation rate, because it must be able to grow on demand instead of hitting a preconfigured wall, and because its natural reclamation unit is the class loader rather than the individual object.