AVA 8 completely removed PermGen from the Hotspot JVM and moved its old data to Java Heap or Metaspace. In this article we will summarize the features of Metaspace. Please point out any mistakes, thank you

Introduction: What has permanently been removed from the HotSpot JVM? In the HotSpot JVM, metadata and pools of constants such as Class and Method are used to hold classes and methods in the permanent generation. Whenever a class is first loaded, its metadata is put into the permanent generation.

Permanent generation has a size limit, so if the loaded classes is too much, will likely result in the permanent generation of memory, namely the evil Java. Lang. OutOfMemoryError: PermGen, therefore we have to do to the virtual machine tuning.

So why was PermGen removed from the Hotspot JVM in Java 8? I have summarized two main reasons (see: JEP 122: Remove the Permanent Generation) :

Because the PermGen memory overflow, often causing annoying Java. Lang. OutOfMemoryError: The removal of PermGen will help the Hotspot JVM to integrate with the JRockit VM, since JRockit does not have permanent generation. For the various reasons above, PermGen was eventually removed, the method area moved to Metaspace, and the string constants moved to the Java Heap.

Due to the lack of data on Metaspace, this article is mainly based on the official Java Virtual Machine specification of Oracle and several articles on Oracle Blog.

First of all, what is the Metaspace region? The official explanation:

In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace.

In other words, JDK 8 began placing class metadata in native heap memory, an area called Metaspace (Metaspace).

What are the benefits of using local memory? The most immediate implication is that the OOM problem will no longer exist, because the default class metadata allocation is limited only by the size of local memory, meaning that Metaspace can theoretically have as much local memory as is left. It’s not clear here), which solves the space shortage problem. However, it is obviously impractical to make Metaspace infinitely large, so let’s also limit the size of Metaspace: use the -XX: maxMetaspacesize parameter to specify the size of the Metaspace region. By default, the JVM sets the size of MaxMetAspacesize dynamically as needed at run time.

Besides, it has the following advantages:

Take advantage of Java Language Specification property : Classes and associated metadata lifetimes match class loader’s Linear allocation only No individual potential applications except for RedefineClasses and class loading failure) No GC scan or compaction No relocation for metaspace objects GC If Metaspace’s space footprint reaches a set maximum, a GC is triggered to collect loaders for dead objects and classes. Depending on the nature of JDK 8, both G1 and CMS do a good job of collecting Metaspace sections (usually along with Full GC).

In order to reduce the frequency and time of garbage collection and control throughput, it is necessary to properly monitor and tune Metaspace. If frequent Full GC occurs in the Metaspace section, it may indicate a memory leak or that the Metaspace section is too small.

The new JVM parameter -XX: Metaspacesize is the initial size (in bytes) allocated to the class metadata space (the initial high-water-mark on Oracle logical storage), which is an estimate. Excessive MetaspaceSize values extend the garbage collection time. After the garbage collection, the size of the class metadata space that causes the next garbage collection may grow. -XX: MaxMetaspacesize is the maximum value allocated to the class metadata space, above which Full GC is triggered. This value is unlimited by default, but should depend on the size of system memory. The JVM changes this value dynamically. -XX: MinMetAspacefreeRatio represents the minimum percentage of free class metadata capacity that will result in garbage collection after a GC to avoid increasing the size of the metadata space. -XX: MaxMetaspacefreeRatio indicates the maximum percentage of free class metadata capacity after a GC, in order to avoid increasing the size of the metadata space, that will result in garbage collection if insufficient. Monitoring and tuning (to be added) VisualVM, jstat, jstack can monitor the dynamics of Metaspace, this will be updated in the future.