Deep understanding of Java Virtual Machine-----> Garbage collector and Memory allocation policy (bottom)

1. Preface

• memory allocation and recovery policy
  • Structure analysis of JVM heap (new generation, old age, permanent generation)
  • Object Precedence in Eden Assignment
  • Large objects go straight into the old age
  • Long-lived objects will enter the old age.
  • Dynamic Object Age Determination
  • Space Allocation guarantee

2. Garbage collector and memory allocation policy

The automated memory management advocated in the Java technology system can ultimately be attributed to automating the solution of two problems:

• allocating memory to objects;
• Reclaims the memory allocated to an object.

The object's memory allocation, in the general direction is the allocation on the heap, the object is mainly distributed in the new generation of Eden area. A few may also be assigned in the old age, depending on which garbage collector combination, and also the parameter settings of the associated memory in the virtual machine. Let's start with the chronology in the JVM: The new generation, the old age, and the permanent generation (JDK1.8 called the meta-space).

Structural analysis of 2.1 JVM heap (new generation, old age, permanent generation)

The HotSpot JVM divides the young generation into three parts: 1 Eden area and 2 survivor area (called from (S1) and to (S2)), which can be used to refer to the following JVM memory system diagram. The default allocation scale for Eden and survival is 8:1. In general, newly created objects are assigned to the Eden area (some large object special handling, which is said later), and if they survive the first minor GC, they will be moved to the survivor area. Object in the Survivor area each time minor GC, age will increase by 1 years, when its age to a certain extent, it will be moved to the old generation.

Because the young generation of the object is basically to die (more than 80%), so in the young Generation garbage collection algorithm uses the replication algorithm , the basic idea of the copy algorithm is to divide the memory into two pieces, each time only with one piece, when this piece of memory run out, Copy the object that is still alive on top of the other piece. The replication algorithm does not produce memory fragmentation.

At the beginning of the GC, the object will only exist in the Eden area and the survivor area named "from", and the Survivor area "to" is empty. All surviving objects in the Gc,eden area are then copied to the "to", and in the "from" area, the surviving objects are determined according to their age values. Objects that reach a certain age (age threshold, which can be set by-xx:maxtenuringthreshold) are moved to older generations, and objects that do not reach the threshold are copied to the "to" area. After this GC, the Eden Zone and the from zone have been emptied. At this time, "from" and "to" will exchange their role, that is, the new "to" is the previous GC "from", The new "from" is the previous GC "to". In any case, the survivor area named to is guaranteed to be empty . The Minor GC repeats this process until the "to" area is filled and the "to" area is filled, and all objects are moved into the old generation.

Objects that survived after n garbage collection in the younger generation will be placed in the old age. Therefore, it can be considered that older generations are storing objects with longer life cycles.
Permanent generations are mainly used to store static files, Java classes, methods, and so on. The permanent generation has no significant impact on garbage collection, but some applications may dynamically generate or invoke some classes, such as Hibernate, at which time it is necessary to set a larger holding space to hold the new class in the running process. The permanent generation size is set by-xx:maxpermsize = <N>.

2.2 Objects are allocated on Eden

Most of the Cenozoic objects are allocated in the Eden area. When the Eden area does not have enough space to allocate, the virtual machine will initiate a minor GC.

Here is a test program demo, detailing the memory allocations for the new generation of objects in the Eden area. Try to allocate 3 2MB size and a 4MB size object, at run time through the VM parameter settings (see code comment), limit Java heap size is 20MB, not extensible, where 10M assigned to the new generation, 10M to the old age, It is important to note that the space ratio of the Eden area to a survivor area is 8:1, and from the output you can see the "Eden Space 8192k,from space 1024k,to space 1024K" information, The total space of the Cenozoic is 9216KB (total capacity of the ENDN Zone + 1 survivor zones). The test code is as follows:

 Public classMINOR_GC {Private Static Final int_1MB = 1024 * 1024; /** VM parameter configuration:-xms20m *-xmx20m *-xmn10m *-xx:+printgcdetails */     Public Static voidMain (String args[]) {byte[] allocation1,allocation2,allocation3,allocation4; Allocation1=New byte[2 *_1MB]; Allocation2=New byte[2 *_1MB]; Allocation3=New byte[2 *_1MB]; Allocation4=New byte[4 * _1MB];//One GC recycle occurs    }}

The output GC logs are as follows:

The above parameters can be seen: the execution of the main function, assigned to the Allocation4 object when a minor GC (Cenozoic recovery), the result of this GC is the new generation of memory 7684k---->365k, but the heap of total memory occupies little change, Because Allocation1, Allocation2, Allocation3 are all alive, this recovery basically did not find recyclable objects. The analysis is as follows:

1. The Cenozoic was assigned a total of 10M, of which enden:8m,survivor:2m (from:1m,to:1m);
2. When allocating memory to Allocation4, Eden has been occupied with 6M (Allocation1, 2, 3 total of 6 m, so the 2M is left), so the memory is not enough to use the----> occur GC;
3. However, 6M does not fit into the survivor from (only 1M), so it can only be transferred to the old age by the distribution guarantee mechanism.

After this GC is over, Eden has 4 m of Allocation4 objects (total 8 m, occupied 50% or so), survivor is idle, old age on behalf of 6M (by Allocation1, 2, 3 occupancy), the log is displayed as 6146k, The old age adopted the method of Mark-sweep (sign clear) recycling.

[note]: differentiate between Cenozoic (Minor GC) and older generation (full GC):

1. New Generation GC (Minor GC): Refers to the garbage collection action occurring in the Cenozoic, because most of the Java objects have the characteristics of the Minor, so the GC is very frequent, the general recovery speed is relatively fast;
2. Old age GC (Major gc/full GC): Refers to garbage collection actions that occur in the old age, Major GC, often with at least one MINORGC (because most of the objects are allocated in Eden First, but not absolute). Major GC Recovery is more than 10 times times slower than the minor GC (since minor GC recovery is generally a large-area reclamation with a replication algorithm, and the Major GC has no extra space for him to vouch for, only the mark-and-clean method), which is the reverse of the idea of recycling, is a space-time and time-space-changing relationship.

2.2 Large objects go straight into the old age

Large objects are Java objects that require a lot of memory space, the most typical of which is the very long string and Array (byte[] is a typical large object). The presence of objects can easily cause memory to have a lot of space to trigger garbage collection ahead of time to get enough contiguous space to "place" them.

The virtual machine provides a-xx:pretenuresize Threshold () parameter, which makes the objects larger than this set straight directly in the old age allocation. This is done to avoid a large amount of memory duplication between the Eden and Survivor Zones (the new belt uses a replication method to complete the GC). Here's a test demo explaining the problem:

 Public classMAJOR_GC {Private Static Final int_1MB = 1024 * 1024; /** VM parameter configuration:-xms20m *-xmx20m *-xmn10m *-xx:+printgcdetails *-xx:pretenuresizethreshold=3145728 (equals 3M)*/         Public Static voidMain (String args[]) {byte[] allocation; Allocation=New byte[4 * _1MB];//will be allocated directly to the old age .        }}

After running it can be seen that the memory will be allocated directly in the old age. [Note]: This does not give a running result, so as not to be misleading, because in the Parallel scavenge collector is not supported pretenuresizethreshold This parameter, can not get such a conclusion.

2.3 Long-term survival targets will enter the old age

　　Java Virtual machines use the idea of generational collection to manage virtual machine memory . The virtual machine defines an object age counter for each object. If an object is born in Eden and survives after the first minor GC, and can be survivor, it will be moved to survivor space, and the object age is increased to a certain level (by default, 15 years old), it will be promoted to the old age. Thresholds for objects that are promoted to the old age can be set by-xx:maxtenuringthreshold.

The test demo is given below:

 Public classLongtimeexistobj {Private Static Final int_1MB = 1024 * 1024; /** VM parameter configuration:-xms20m *-xmx20m *-xmn10m *-xx:+printgcdetails *-xx:maxtenuringthreshold=1 *-xx:+printtenuringdistribution*/         Public Static voidMain (String args[]) {byte[] allocation1,allocation2,allocation3; Allocation1=New byte[_1MB/4]; //when to enter the old age depends on the setting of-xx:maxtenuringthresholdAllocation2 =New byte[4 *_1MB]; Allocation3=New byte[4 *_1MB]; Allocation3=NULL; Allocation3=New byte[4 *_1MB]; }}

　　

　　The test results are as follows:

2.4 Dynamic Object Age determination

　　virtual does not always require that the object age must reach Maxtenuringthreshold can be promoted to the old age, if the sum of all objects of the same age in Survivor space is greater than half of the survivor space, the object of age greater than or equal to that age is directly as old , there is no need to wait until the age required in Maxtenuringthreshold.

Here is a dynamic Age test demo:

 Public classLongtimeexistobj {Private Static Final int_1MB = 1024 * 1024; /** VM parameter configuration:-xms20m *-xmx20m *-xmn10m *-xx:+printgcdetails *-xx:maxtenuringthreshold=15 *-xx:+printtenuringdistribution*/@SuppressWarnings ("Unused")         Public Static voidMain (String args[]) {byte[] allocation1,allocation2,allocation3,allocation4; Allocation1=New byte[_1MB/4]; //makes Allocation1 + allocation2 > Survivor half of Space (0.5M)Allocation2 =New byte[_1MB/4]; Allocation3=New byte[4 *_1MB]; Allocation4=New byte[4 *_1MB]; Allocation4=NULL; Allocation4=New byte[4 *_1MB]; }}

The test results are as follows:

In the execution code results, it can be seen that the survivor area occupies 0 (from = 0,to = 0), while the memory usage of the old age is 5 m, and the other objects are 4M, you can know, Both Alloccation1 and Allocation2 entered the old age before they reached the age of 15. Verified our conclusion----> the sum of all objects of the same age in Survivor space is greater than half of the survivor space, the objects of age greater than or equal to that age are directly as old as the ages.

2.5 Space Allocation Guarantee

　　Before the minor GC, the virtual opportunity to check whether the continuous space available in the old age is greater than the total space of all cenozoic, if greater than that, then this GC can be guaranteed security, if not established, it may cause the promotion of the old age when the memory is insufficient. In such a case, the virtual machine first checks whether the Handlepromotionfailure setting value allows the guarantee to fail, and if so, then the virtual machines allow such risks to exist and persist. Then check whether the largest contiguous free space in the old age is greater than the average size of the previous promotion age object, if it is greater than that, execute minor GC, if less than, or handlepromotionfailure setting does not allow adventure, then the first full The GC cleans up the memory of the old age and then judges it.

The risk mentioned above is due to the new generation because the surviving object uses the replication algorithm, but in order to memory utilization, only one of the survivor space is used, the surviving objects are backed up to the survivor space, once a large number of objects occur at once minor The GC will still survive (the worst plan is not to find that there is a need to clean up), then the old age to share a portion of memory, the survivor on the allocation of objects directly into the old age, because we do not know exactly how much memory needed, we can only estimate a reasonable value, The value of this method is to calculate the average memory size for each promotion of the old Age as a reference, if necessary, then a full GC in advance.

Averaging is feasible in most cases, but because of too much uncertainty in memory allocation, it is still possible to guarantee failure in the event of a sudden occurrence of certain large objects or minor GC after the majority of objects survive, causing memory to be much higher than the average. Failure). If a handlepromotionfailure fails, then you have to re-launch the full GC after the failure. In this case, the guarantee failure is to pay the price, most of the cases will still open the handlepromotionfailure switch, after all, the probability of failure is relatively small, such a guarantee can avoid the full GC too often, the garbage collector frequent startup is certainly not good.

the above is very cumbersome (detailed), really can not see the picture bar:

In this paper, the concept of the new generation and the old age is partly referenced in the blog: https://www.cnblogs.com/E-star/p/5556188.html

This article refers to a book: "In-depth understanding of Java virtual machines"

Deep understanding of Java Virtual Machine-----> Garbage collector and Memory allocation policy (bottom)