background

It has been nearly 3 months since I joined the new company. Recently, I saw a strange word on Intranet technology wiki: A “persistent generation” is what programmers who are used to developing and deploying on HotSpot JVMS are used to calling the contents of the method area persistent generation (which is an implementation of the method area), whereas in JDK8 the method area is gone and Metaspace is created. This article briefly summarizes JDK8’s changes to the JVM memory distribution and the JVM memory model.

JDK version

Java version "1.8.0_251" Java(TM) SE Runtime Environment (build 1.8.0_251-B08) Java HotSpot(TM) 64-bit Server VM (build 25.251 - b08, mixed mode)Copy the code

What is a method area

Before we get to the method area, let’s take a quick look at what data was stored in the method area before JDK8:

1) Class information: class name/inheritance/attributes of the class itself

2) Method information, such as method name/method attribute/related exception information, will be loaded as the class is loaded

3) Constant pool

4) Class variables are non-final class variables

Each loaded Class creates an instance of java.lang.Class, and references to this instance are stored in the method area

6) Method table is convenient for quick activation method

7) References to ClassLoader

It can be seen that most of the data in the method area is loaded with the class load, basically the metadata of the class, often no change after loading.

Is there GC in the method area? The answer is yes, but you can see that in addition to class variables that may change and require GC, other class data will also be gc if there is no instance of the class

Is the size of the method area fixed? The default method area size is 20.75 MB. You can manually change the method area size:

-xx :MaxPermSize # Set the maximum space that can be allocated for the permanent generationCopy the code

Why does metacreage replace permanent generation

In Java8, method areas exist in Metaspace. The meta-space is no longer contiguous to the heap and exists in local memory.

By default, the use of local memory is unlimited, but the JVM also provides some parameters to limit the use of the meta space:

-xx :MetaspaceSize # MetaspaceSize # MetaspaceSize # MetaspaceSize # MetaspaceSize # MetaspaceSize -xx :MinMetaspaceFreeRatio #GC Minimum remaining percentage of the post-meta space. -xx :MaxMetaspaceFreeRatio #GC Maximum remaining percentage of the post-meta spaceCopy the code

Think about it, why do you use a meta-space instead of a permanent generation?

Reason 1: When a Java project is built, we often do not know how many classes there will be, so the size of the class meta data is unknown, and the initial space and maximum space are not appropriate regardless of the default/design size. The best solution is to free the permanent generation from the heap.

Reason 2: The recovery efficiency of permanent generation is low, which will bring unnecessary complexity to GC. The scanning frequency of permanent generation can be much lower than that of old generation. If placed in heap memory, the old GC will also scan the permanent generation, resulting in a waste of resources.

The above is my personal understanding of the reason for metaspace to replace the permanent generation, welcome to discuss ~

The heap

The Heap is the high incidence of OOM failure. It stores almost all instance objects. The Heap is automatically reclaimed by the garbage collector, and the Heap area is shared by each sub-thread. It usually takes up the most space of any memory region, but can easily run out of space if you create a large number of objects inordinately. The memory space of the heap can be fixed size or dynamically adjusted at runtime.

-xms # Initial heap memory -xmx # Maximum heap memoryCopy the code

The new generation

In the JVM, the heap is divided into two distinct regions: Young Gen and Old Gen. The Cenozoic era is divided into three regions: Eden region, From Survivor region and To Survivor region. In general, newly created objects will be allocated to Eden area, and some special large objects will be directly allocated to the old age. When the space occupied by the new generation reaches the critical value, THE Eden area will be GC, and such GC is called Minor GC. During the Minor GC, most of the objects will be cleaned up, some of them may still be alive (for a while), and the surviving objects will need to be copied to the From Survivor zone, and then the Eden zone will be emptied.

The next time a Minor GC occurs, the age of the objects in the From Survivor zone is +1, the surviving objects in the Eden zone are copied To the To Survivor zone, and the surviving objects in the From Survivor zone have two places:

1. When the age reaches the age threshold, the object is moved to the old generation

2. If the age does not reach the age threshold, the object is moved To the To Survivor zone

That is, in this Minor GC, the From Survivor zone is cleared, the To Survivor zone holds objects that did not reach the age threshold, the objects that reached the age threshold enter the old age, and so on, the From/To Survivor zone is like two sieves, Constantly move objects that meet the requirements to the old age, it is impossible to have objects From Survivor zone at the same time.

The space size ratio of the two Survivor zones is 1:1 (related to the replication algorithm)

The Eden:To:From space ratio is 8:1:1 (this is a very subtle default ratio, IBM said in the paper that according To their statistics, 95% of objects have a very short survival time, you can calculate by yourself), parameter setting:

-xx :SurvivorRatio # Default value 8Copy the code

Age threshold setting parameters:

‐XX:+MaxTenuringThreshold # Default value 15Copy the code

The old s

From the above analysis, it can be seen that the Old areas are generally older objects, and there will also be GC in the Old age. GC in the Old age is called Major GC/Full GC.

The old generation has much more memory than the new generation, and a Full GC takes much longer than a Minor GC (STW).

Frequent Full GC takes a long time and can affect program execution and response speed.

The stack

JVM virtual machine stack

Stack is a thread’s private memory area, where there is no data security problem. It describes the memory model of each function execution. A Stack Frame stores information such as local variable table, operand Stack, dynamic link, method exit and so on. The JVM specifies two exceptions for stack areas: if the thread requests a stack depth greater than the virtual machine allows, a StackOverflowError is thrown; If the virtual stack can scale dynamically, an OutOfMemoryError will be thrown if sufficient memory cannot be allocated during the scale.

Local method stack

The difference between the Native method stack and the JVM virtual machine stack is that the virtual machine stack performs Java method (bytecode) services for the virtual machine, while the Native method stack serves the Native methods used by the virtual machine. StackOverflowError and OutOfMemoryError exceptions are also thrown by the local method stack.

Program counter

A program counter is a small memory area that stores the address of the current instruction during execution for Java methods (i.e., methods without native keywords). Program counters are thread private and record the execution of each thread. The program counter is also the only area of the JVM that does not report an OutOfMemoryError.

I will not draw a schematic of the JVM memory model