JAVA8 Permanent Generation

In a Java Virtual machine (hereinafter referred to as the JVM), a class contains its corresponding metadata, such as class hierarchy information, method data and method information (such as bytecode, stack, and variable size), running a constant pool, determined symbolic references, and virtual method tables.

In the past (when the custom ClassLoader was used infrequently), classes were almost "static" and were rarely unloaded and recycled, so classes could also be considered "permanent". In addition, because classes are part of the JVM implementation, they are not created by programs because they are also considered "non-heap" memory.

In a hotspot virtual machine prior to JDK8, these "permanent" data for classes are stored in a zone called a permanent generation. For a permanent generation of contiguous memory space, we can control the size of the permanent generation by setting the value of the-xx:maxpermsize before the JVM starts, and the 32-bit machine defaults to a 64m,64-bit machine with a permanent size of 85M. A permanent garbage collection is bound to a garbage collection in the old age, and once one of the areas is full, the two zones are garbage collected. But there is an obvious problem as we can pass? Xx:maxpermsize sets the size of the permanent generation, once the metadata of the class exceeds the set size, the program runs out of memory and a memory overflow error (OOM) occurs.

Note : In a hotspot virtual machine prior to JDK7, strings that incorporate string constant pools are stored in a permanent generation, resulting in a series of performance problems and memory overflow errors.

With the advent of Java8, we will never see a permanent generation again. However, this does not mean that the metadata information for the class has disappeared. This data is moved to a local memory area that is not connected to the heap, which is the meta-space we are going to refer to. This change is necessary because it is difficult to tune the permanent generation. Metadata in a permanent generation may move as each full GC occurs. It is also difficult to set the space size for a permanent generation, because there are many factors, such as the total number of classes, the size of the constant pool, and the number of methods.

At the same time, each type of garbage collector for a hotspot virtual machine requires special processing of metadata in a permanent generation. The separation of metadata from the permanent generation not only realizes the seamless management of the meta-space, but also simplifies the full GC and optimizes the future of the concurrent isolation class meta-data.

Remove the effects of a permanent generation

Because the metadata of the class is allocated in local memory, the maximum allocated space of the meta-space is the available memory space of the system. Therefore, we will not encounter a memory overflow error when there is a permanent generation, nor will there be any such thing as leaking data to the swap area. The end user can set a maximum free space for the meta space, and if not set, the JVM automatically increases the capacity of the meta space dynamically based on the metadata size of the class.

Note : The removal of a permanent generation does not resolve the problem of a custom class loader leak. As a result, you must also monitor your memory consumption, because once a leak occurs, it can take up a lot of your local memory, and it can also cause the swap to get worse.

meta-space memory management

The memory management of the meta-space is done by the meta-space virtual machine. Previously, for the metadata of the class we needed a different garbage collector for processing, and now we just need to execute the C + + code of the meta-space virtual machine. In Meta space, the life cycle of a class and its metadata is the same as its corresponding class loader. In other words, as long as the ClassLoader survives, the metadata of the classes it loads is also alive and therefore not recycled.

The meta-space we've been talking about is a little bit less rigorous. To be exact, the storage area of each classloader is called a meta-space, and all of the meta-spaces together are the meta-space we have been talking about. When a classloader is marked by the garbage collector as no longer surviving, its corresponding meta-space is recycled. There are no relocation and compression operations during the meta-space recovery process. However, metadata in the meta-space is scanned to determine the Java reference.

The meta-space virtual machine is responsible for the allocation of the meta-space, which is used in the form of block allocation. The size of the block varies depending on the type of ClassLoader. There is a global list of free block blocks in the Meta space virtual machine. When a class loader requires a block, it obtains and maintains a list of its own blocks from this global list of block blocks. When a class loader no longer survives, the blocks it holds will be freed and returned to the global Block list. The block that the ClassLoader holds is then divided into chunks, each of which stores meta information for a single cell. The block in the block is a linear assignment (a pointer collision allocation form). The block is assigned from the memory-mapped area. These global virtual memory-mapped areas are connected as a linked list, which is returned to the operating system once a virtual memory-mapped area is emptied.

Refer to the following link: http://www.infoq.com/cn/articles/Java-PERMGEN-Removed?from=groupmessage&isappinstalled=0

JAVA8 Permanent Generation