How is class-metadata memory allocated and released inside the JVM, and why can metaspace usage stay high even after an application stops using the classes involved?

## Allocation: arenas, chunks, and no compaction Metaspace is not a general-purpose native allocator with per-object `free`. It is organised in three layers. 1. The JVM **reserves** virtual address space and **commits** it in granules as demand grows. 2. Committed space is divided into **chunks** of varying sizes. 3. Each **class loader** owns an **arena**: a list of chunks from which its metadata is bump-allocated. When a loader defines a class, the type structure, method metadata, bytecode and constant pool are all appended into that loader's current chunk; when it fills, another chunk is attached. Nothing is ever relocated, so pointers into metadata stay valid for the life of the arena and no read barrier or compaction phase is needed. A small arena for a loader that defines one class would waste space, so HotSpot hands out small chunks first and larger ones as a loader proves it keeps loading. The boot loader and other long-lived loaders get large chunks immediately. ## Release: only at loader granularity The design consequence is the whole point of the question. Metadata is freed **only when the owning class loader is unloaded**, and a loader can be unloaded only when it and all of its classes are unreachable. Two references make that stricter than people expect: - every `java.lang.Class` object strongly references its defining loader, so holding one class alive holds the loader alive; - every instance references its class, so a single live instance of one class pins the entire loader arena. So there is no such thing as "this class hasn't been used in an hour, free it". Either the whole loader goes or none of it does. During a collection cycle the JVM computes loader reachability, unloads the classes of dead loaders, and returns their chunks. Modern collectors do this concurrently, so class unloading no longer requires a stop-the-world full collection. ## Why usage stays high Given that granularity, high metaspace with an idle application means one of three things: - **Loaders are still reachable.** Dynamic proxies, scripting engines, bytecode-generating frameworks and repeated deployment create a loader per unit; anything retaining one of their classes or instances retains the arena. - **No collection has run recently.** Metadata is only reclaimed as part of a collection cycle, and a JVM with a quiet heap may not run one. Committed metaspace crossing the high-water mark set by `-XX:MetaspaceSize` is itself a trigger, which is why an idle process can suddenly reclaim a large block. - **The classes really are all live.** Large frameworks legitimately load tens of thousands of classes; the plateau is the steady state, not a defect. A useful discriminator is the trend rather than the level: a footprint that rises to a plateau and stays there is normal; a footprint that steps up with each cycle of work and never falls after collections points at retained loaders. ## What changed with the reworked allocator The original JDK 8 implementation suffered two structural weaknesses: chunks freed by unloading were kept for reuse rather than returned to the OS, so the process footprint ratcheted upward, and mismatched chunk sizes fragmented the space so that committed memory exceeded what was actually in use, sometimes substantially. JDK 16 replaced it with an elastic scheme: chunks are managed by a **buddy allocator** that splits and merges neighbouring blocks, allocation commits memory lazily in small granules, and memory freed by class unloading is **uncommitted back to the operating system**. Practically, on JDK 16 and later, unloading a batch of loaders visibly reduces the process's resident memory instead of merely making room for future classes. On JDK 8 through 15, expect the footprint to stay at its peak. ## How to inspect it `jcmd <pid> VM.metaspace` reports used, committed and reserved for the class and non-class parts, and its detailed form lists **arenas per class loader** with each loader's name and class count. That per-loader view is the direct read on the mechanism: many arenas with identical loader names is the signature of loaders accumulating rather than legitimate class-count growth. Enabling class-unloading logging shows which loaders each cycle actually released. ## Answer shape Say: chunk-based per-loader arenas, no compaction, no per-class free, release only on loader unload during a collection; therefore any reference into a loader's classes pins all of its metadata; and since JDK 16 freed metadata is uncommitted to the OS so the footprint can actually shrink.