Jvm-java8 's Metaspace

Java 8 completely removes the HotSpot JVM from the Permanent Generation (PermGen), migrating its original data to Java Heap or Metaspace

Why did you cancel the permanent generation and replace the permanent generation with metaspace?

In the HotSpot JVM, the metadata for classes and methods and constant pools, such as and, are used in the permanent generation Class Method . Whenever a class is loaded for the first time, its metadata is placed in the permanent generation.

The permanent generation is limited in size, so if there are too many classes loaded, it is likely to lead to a permanent memory overflow, the evil java.lang.OutOfMemoryError:PermGen , so we have to tune the virtual machine.

Why has PermGen been removed from the HotSpot JVM in Java 8? I've summed up two main reasons:

1, because PermGen memory often overflow, causing annoying java.lang.OutOfMemoryError:PermGen, so the JVM developers want this piece of memory can be more flexible to be managed, Do not often appear such OOM.

2. Removing PermGen can facilitate convergence between the HotSpot JVM and the JRockit VM, because JRockit does not have a permanent generation.

Depending on the various reasons above, the PermGen is eventually removed, the method area is moved to Metaspace, and the string constants are moved to the Java Heap.

What area is metaspace (meta space)?

JDK 8 begins to place the metadata of the class into the local heap memory (native heap), which is called Metaspace, and the Chinese name is the meta space.

Metaspace the size of the first knowledge?

What are the benefits of using local?

The most straightforward expression is that the oom problem will no longer exist because the default class's metadata allocation is limited only by the local memory size, that is, how much local memory is left　　 . theoretically metaspace can be how large (seemingly capacity also with the operating system of virtual memory has off? Not very clear here), which solves the problem of lack of space. However, it is obviously unrealistic to let Metaspace become infinitely large, so we also want to limit the size of Metaspace: Use the -xx:maxmetaspacesize parameter to specify the size of the Metaspace area. The JVM defaults to dynamically set the size of the maxmetaspacesize as needed at run time.

GC

　　If the Metaspace occupies a set maximum, then a GC is triggered to collect the dead objects and class loaders. Depending on the features of JDK 8, G1 and CMS will collect the Metaspace area (typically with full GC).

In order to reduce the frequency and time of garbage collection and control the throughput, it is necessary to monitor and tune the Metaspace properly. If there is a frequent full GC in the Metaspace area, it may indicate a memory leak or a metaspace area where the space is too small.

New JVM Parameters

-Xx:metaspacesize is the initial size allocated to the class metadata space (in bytes) (The initial high water level on the Oracle logical storage, theinitial High-water-mark ), which is an estimated value. Metaspacesize value set by the assembly

Extend garbage collection time. After garbage collection, the size of the class metadata space that caused the next garbage collection may become larger.

　　-xx:maxmetaspacesize is the maximum value assigned to the class metadata space, which triggers the full GC, which is not limited by default, but should depend on the size of the system memory. This value is dynamically changed by the JVM.

　　-XX:Minmetaspacefreeratio Once the GC is expressed, in order to avoid increasing the size of the metadata space, the minimal proportion of the free class metadata capacity will result in garbage collection.

　　-XX:Maxmetaspacefreeratio represents a GC, in order to avoid increasing the size of the metadata space, the largest proportion of the idle class metadata capacity is not enough to cause garbage collection.

Reference:

"1" personal blog, https://www.sczyh30.com/posts/Java/jvm-metaspace/

Jvm-java8 's Metaspace