GC logical model
1. Generation model
Serial and Parallel, Parnew, and CMS are all GC components implemented based on generational models. The generation model divides memory into several parts roughly: young generation, surviving region, and old age. The young generation and the surviving section are recycled by a collector component. The old area is recycled by another component.
The two components of serial are: SerialGC and SerialOldGC parallel ParallelGC and ParallelOldGC CMS is based on a generational model, but because of its young generation has no corresponding recovery components, in most cases using parNew undertakes collocation, There is no essential difference between ParNew and ParallelGC, but it is optimized for CMS.
Diagram of generation model:
Objects that are not cleaned up successfully after GC in the young generation will enter the survivor zone.
The Eden and Survivor zones default to 8:1:1
The ratio of Eden to Survivor and old age is usually 1:2
(These ratios can be adjusted.)
If the new object cannot be placed in the new generation, a Minor collection will be launched. If the new object cannot be placed in the new generation, a Minor collection will be launched. If the new object cannot be placed in the new generation, a Minor collection will be placed in the old age.
Serial, parallel,
Serial and Parallel have a similar execution flow. The largest one is that Serial is single-threaded and each stage is STW, while Parallel is multi-threaded. The execution flow is shown in the figure below
CMS (Concurrent Mark Sweep) :
CMS is an old GC component, and the execution flow is shown in the figure below
Initial markup: Mark the roots, which is the root node.
Concurrent marking: runs concurrently with the program, addressing from the roots node, marking valid objects.
Relagging: Since concurrent marking occurs at the same time as the program, there may be some false marking, such as when the object is no longer referenced, but when it saves itself in the finally method of the object, the object should not be garbage, so the false marking is corrected during the relagging phase.
Concurrent cleaning: To clean up garbage objects. The concurrent cleaning process of CMS is mark-clean, and all objects other than valid objects are deleted
Concurrent reset: Resets the state of all objects in preparation for the next GC flow
2. Generation-free model
G1 and ZGC the implementations has greatly weaken the traditional concept of generational model, ZGC has no concept of generational garbage collection mechanism consists of a set of a complete set of complex algorithm to realize the G1 is evolved from the CMS, slightly similar processes Garbage judgment standard is done with addressing method, which is to determine whether some root node roots, By reference addressing from roots, those found are not garbage, and those not found are treated as garbage. The general process is shown in the following figure
G1:
G1 divides the Java heap into independent regions of equal size, and the JVM can have up to 2048 regions. General Region size is equal to the heap size divided by 2048, such as the heap size of 4096M, Region size is 2M, of course, you can also use the parameter “-xx :G1HeapRegionSize” manually specified Region size
Region is no longer a physical barrier. A Region that was previously a young generation may become an old generation after GC. Similarly, an old generation may be reallocated to a young generation after GC, and the corresponding memory model is similar to the following figure
The change mechanism of Eden, survivor and old region in G1 is the same as the generation mechanism of CMSCopy Copy (mark collation)Algorithm, a valid object in a block copy to another block, copy the end of the copy directly clear the region.
The difference is that G1 adds a humongous region, which is specially used to store large objects, and optimizes the Full GC problem that may be caused by large objects entering into the old age directly. The judgment of large objects is marked as more than 50% of the size of a single region. If a single region cannot fit large objects, Is stored across several regions
The execution process of G1 is as follows:
Initial labeling: Label the ROOTS
Concurrent tagging: Similar to CMS, concurrent tagging with the program starts at the Roots node
Final markup: Same as above, similar to CMS, fixes some object state markup errors due to concurrent markup
Screening and recycling: The filtering and recycling logic of G1 is more complex, because G1 can specify the pause time of each stage, and the pause time of each stage is currently up to 200 milliseconds. However, since 200 milliseconds may not be able to clear all the garbage, G1 will conduct a potency ratio analysis first. Determine the objects that can be cleaned in a short period of time and get the maximum benefit from memory release to give priority to cleaning. G1 recycling way to arrange, can be as simple as copy and paste, and valid for a block object is copied to another block, copy after clearing the region directly, because the algorithm is too complex, there is no concurrency, but limits the time of each process execution, so on the feeling is not too obvious.
Concurrent reset: Resets the state of each Region block in preparation for the next GC flow
PS:
Young GC: YoungGCYoungGC does not mean that it will trigger as soon as the existing Eden area is full. G1 will calculate how long it will take for the current Eden area to be collected. If the collection time is much less than the value set by -XX: maxGCPAUSEMILLS, Then increase the region of the young generation (adjust the total space allocated to the young generation in memory, so as to achieve the effect of young generation expansion), continue to store the new object, do not immediately do YoungGC, until the next Eden area is full, G1 calculate the collection time is close to the value set by the parameter -XX: maxGCPAusemills. This will trigger the Young GC
MixedGC: Not FullGC, the heap of Old s share reach parameters (- XX: InitiatingHeapOccupancyPercent) set the value of the trigger, recycle all part of Young and Old, A Full GC is triggered when a copy is executed if it is found that there are not enough empty Regions to host the copy object
Full GC: Stopping a system program and then using a single thread to tag, clean, and compact so that a batch of Regions is free for the next mixedGC can be time-consuming. Shenandoah optimized for multi-threaded collection.
ZGC:
ZGC is an experimental, low-latency garbage collector added to JDK 11
ZGC inTemporarily noGeneration concept, but the memory is divided into small region, medium region and large region three parts for data storage, useRead barrier, color pointerAnd other technologies to achieve concurrentmark-collatealgorithm
Small Region (Small Region): Capacity fixed at 2MB for small objects smaller than 256KB.
Medium Region: Size fixed at 32MB, used for objects greater than or equal to 256KB but less than 4MB.
Large Region (Large Region): Capacity is not fixed and can change dynamically, but must be an integer multiple of 2MB for large objects of 4MB or more. Only one large object is held in each large Region, indicating that despite the name “large Region,” it is entirely possible that the actual capacity of a “large Region” is smaller than that of a medium-sized Region, with a minimum capacity as low as 4MB.
The execution flow and memory model are shown below.
Initial tag: Again, get the Roots node list
Concurrent tags: As in G1, objects are marked using the method of accessibility analysis, but unlike G1, ZGC does not mark objects in the header, but in the pointer layer
In the end tag: There will be a short pause during the final marking phase, also to correct the marking
Concurrent provisioning redistributionThis phase determines which regions need to be cleaned up by the GC and then organizes these regions into a Relocation Set.
Concurrent redistribution: This stage is the core stage of ZGC. In this stage, the Relocation Set generated by concurrent prepared Relocation will be used to move several valid objects into a new region, and then a remap table will be maintained, which stores the old memory address and new memory address of the valid objects. It is easy for the read barrier to modify the memory pointer to an object reference in real time while an object is read
Concurrent remapping: Batch update the corresponding memory address changes in the remap table, and correct all the moved object reference addresses
Colour Pointers Colored Pointers
One of the core designs of ZGC. The GC information of the previous garbage collector was stored in the object header, while the GC information of the ZGC was stored in Pointers. Each object has a 64-bit pointer. These 64-bits are divided into 18 bits: reserved for later use; Bit 1: The Finalizable identifier, which relates to concurrent reference handling and indicates that the object can only be accessed through finalizer (an empty method of the Object base class that, if overwritten, will be called before GC, and will only be called once); 1 bit: Remapped flag, and the object does not point to a relocation set (relocation set represents a Region set that needs GC). 1 bit: Marked1 identifier; 1 bit: Marked0 identifier, and Marked1 above are both tag objects used to assist GC; 42-bit: The address of the object (so it can support 2^42=4T of memory) :
The problem with two marked bits is that at the beginning of each GC cycle, the mark bits used are swapped, invalidating the corrected marked state from the last GC cycle, and all references become unmarked. GC cycle 1: With mark0, all references to mark tags will become 01 at the end of the cycle. GC cycle 2: With mark1, as with cycle 1, all mark tags will become 10.
Read barrier
ZGC adopt the way of read barrier to fix a pointer reference, due to copy the ZGC USES is finishing the GC, probably after the position of the object pointer position has not been updated program calls the object, so at this time in applications requiring concurrent access to the object references, ZGC would be to read the object pointer, If the object is located in the region that needs to clean up, the object will have memory address change. The new reference address will replace the original reference address of the object in the pointer, and then return. Thus, the use of read barriers solves the problem of reading objects in concurrent GC
The root node type
- The associated object in the virtual stack (the local variable area of the stack frame, also known as the local variable scale).
- Object associated with a class static property in the method area.
- Constantly-related objects in the method area.
- JNI (Native Method) – related objects in the local method stack.
Three color tag
At present, the mainstream GC accessibility analysis algorithms are basically based on the idea of tricolor marker, but the implementation methods are different. Trichromatic marking can be simply understood as dividing all objects into three colors, black, gray and white, which represent different states of objects. Black: Represents that the object and all of its children have been reachable analyzed. Grey: Indicates that the object has been analyzed for accessibility, but the child nodes of the object have not completed all the accessibility analysis. White: Indicates that the object has not been analyzed for accessibility.
If all the accessibility analysis is done, the white object is garbage to be collected, because no references can reach it to change the color label of the object.
Card table
The simple understanding of the card table is to solve the problem of cross-reference, which exists for GC components that do GC with partitioned blocks. For example, when G1 cleans objects stored in a region, objects in that region are referenced by objects in other regions or objects in that region refer to objects in other regions, the effect of cross-collection accessibility analysis is poor.
In a garbage collection scenario, the collector simply needs to determine from the memory set whether a non-collection area has a pointer to a collection area
Thus came the concept of memory sets. The card table is the implementation of the memory set, and the JVM uses a write barrier to maintain the card table.
The card table is implemented using a byte array: CARD_TABLE[], with each element corresponding to the memory region it identifies as a memory block of a specific size, called a “card page”.
A card page can contain multiple objects, as long as the fields of an object exists across generations a pointer, the elements of the corresponding card table becomes 1, said the elements become dirty, otherwise as 0. GC, convenient card table array, find the value of 1 element identification, screening the logo corresponding collection area of card tables in the dirty elements join GCRoots.
At the level of card table, the whole memory is divided into many small pieces stored in card table (CARD_TABLE[]), and all the dirty elements will be added to GCROOTS. GCROOTS is non-partitioned/generation, and all extents/generations have to start from GCROOT for accessibility analysis, so the problem of cross-region/cross-generation reference is solved