Shulou(Shulou.com)06/02 Report--

This article will explain in detail how to achieve JVM garbage collection, the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Reference counting and reachability analysis of garbage collection algorithm

The first problem to be solved in garbage collection is how to judge whether an object should be reclaimed or not. There are usually two algorithms: reference counting algorithm and reachability analysis algorithm.

Reference counting algorithm (Reference Counting Algorithm)

Add a reference counter to the object, and every time you add a reference to it, the count increases by 1, and every time you cancel a reference to it, the count is reduced by 1. When the counter is 0, the object can be recycled. The reference counting algorithm is simple in principle and efficient in judgment, but it needs extra memory space, and can not solve the circular reference.

Reachability analysis algorithm (Reachability Analysis Algorithm)

Through a series of root objects called "GC Roots" as the starting node set, the search starts from these nodes, and the search path is called "reference chain" (Reference Chain). If the object is not connected to the GC Roots, it means that the object is inaccessible, that is, the object can no longer be used, it can be recycled. JVM uses this algorithm.

Fix the objects that can be used as GC Roots in Java:

Objects referenced in the local variable table in the virtual machine stack frame, such as parameters, variables, etc., used by each thread to be called.

Objects referenced by class static properties in the method area, such as Java class variables

Method to an object referenced by a constant, such as a reference to a constant pool of strings

Objects referenced by the local method stack JNI

References within JVM, such as Class objects corresponding to basic data types, resident exception objects, system loaders, etc.

All objects held by the synchronization lock (syschronized)

JMXBean that reflects the internal situation of JVM, callbacks registered in JVMTI, local code cache, etc.

After the finalize method object is marked as unreachable in the reachability analysis, it is not necessarily recycled, and you can save yourself in the finalize method. If the object overrides the finalize method and the finalize method has never been executed, the object is placed in the F-Queue queue, and a separate JVM thread executes the finalize method of the object in the queue later, but it is not guaranteed to wait for it to finish running. The collector will secondary mark the object in the F-Queue, and if it is re-associated with the object on the reference chain in the finalize method, the secondary tag will remove the recycled collection. In particular, the finalize method of any object will only be executed once and will not be executed the next time it is reclaimed. Since there is no guarantee that the finalize method will be fully executed, it is best not to use it.

Recovery of method area

Because the performance-to-price ratio of garbage collection in the method area is relatively low, the collection of the other method area is not necessary, and some collectors do not realize the collection of the method area. There are two main parts of recycling in the method area: obsolete constants and types that are no longer used (type unloading).

Obsolete constants, such as a string in the string constant pool, are no longer referenced by any string objects, and it will be recycled.

Type unloading, three conditions must be met:

Type unloading is not the same as object collection, which is not necessarily recycled if the condition is met. HotSopt can be controlled by the-Xnoclassgc parameter.

All instances of this class have been recycled

The class loader that loaded the class has been reclaimed

The corresponding Class object of this class is not referenced anywhere

Generational collection theory

Most current JVM garbage collectors follow the Generational Collection theory, which is based on the following three hypotheses:

Weak generational hypothesis: the vast majority of objects are permanent.

Strong generational hypothesis: the more objects that survive the GC process, the harder it is to be recycled.

Intergenerational citation hypothesis: intergenerational citations account for only a small number of references compared with those of the same generation.

Based on the first two hypotheses, the collector divides the Java heap into the new generation and the old age. In the new generation, the vast majority of objects are dying, each time GC can be recycled can clean up a lot of memory space, and can be reclaimed more frequently. The objects in the old era are difficult to be recycled, and the GC results are much lower than those in the new era, and the frequency of recovery is even lower.

The reason why there are fewer cross-generational references: objects with reference relationships should tend to exist or die at the same time. If there is an intergenerational reference in a Cenozoic object, because it is difficult for the old object to die out, with many times of GC, the Cenozoic object will be promoted to the old age, thus eliminating this intergenerational reference. Because there should be very few intergenerational references, in Minor GC, you can't add whole old objects to GC Roots in order to solve a small number of intergenerational references. That would affect efficiency too much.

The solution of cross-generational reference

Create a global dataset, the memory set, in the collection area, recording all references from the non-collection area to the collection area. There are many ways to implement memory sets, and most collectors use card tables. For example, create a card table in the new generation, then divide the old age into several blocks, and record in the card table that there are intergenerational references in that piece of memory. When Minor GC, you only need to add the memory object that has intergenerational references to the GC Roots.

The implementation of the card table in HotSopt is an byte array, and the values of the array elements are 0 and 1. The reason for not using the bit array is that modern computer hardware is addressed by the smallest byte, but using bit requires multiple instructions. Each element in the byte array corresponds to a memory block with a size of 512 byte. The memory address of each object divided by 512 is its position in the array. This memory block is called a card page. A card page usually contains more than one object. When there is an intergenerational reference in the field of an object in the card page, then the value of the corresponding element in the card table is 1. When GC, you only need to add the objects in the card page corresponding to the element with a value of 1 in the card table to GC Roots.

As for the reason for using such a coarse granularity of the card table, it is because it can save storage space and maintenance costs.

When do I change the value in the card table? When objects in other generational regions refer to objects in this area, you need to change the values in the card table.

How to change the value in the card table-write barrier. The write barrier is very similar to the idea of AOP. Using the write barrier, JVM generates instructions for all assignment operations to maintain the values in the card table.

Mark-clear algorithm

The collector first marks the objects that need to be recycled, and then uniformly reclaims all the marked objects after the marking is completed, of course, it can also mark the objects that do not need to be recycled, and then clean up the untagged objects. It has two obvious flaws:

Execution efficiency is unstable, and if there are a large number of objects in the heap and most of them need to be recycled, a large number of marking and cleaning actions must be carried out, and the execution efficiency decreases as the number of objects increases.

Produces a large number of discontiguous memory fragments.

Tag-copy algorithm

Divide the memory into two equal-sized areas, and use only one of them at a time. When this area is used up, copy the surviving objects to the other, and then clean up the full memory space at once. If most objects are recyclable, the overhead of copying a small number of objects is small, and since only one cleanup is required, the execution efficiency is high and stable compared to tag cleanup, and there is no memory fragmentation. The cost is that only half of the memory space is available at a time.

In practice, most collectors use this algorithm to recover the new generation. The new generation is divided into one Eden zone and two Survivor zones. The default ratio is 8:1:1. Only Eden zone and one Survivor zone are used at a time, that is, only 90% of the actual area in the new generation is available. The minor GC copies the surviving objects to another Survivor zone, and then cleans up the Eden and the used Survivor zone. If the object that survives at GC requires more space than the size of the Survivor, it will be put directly into the old age, which is guaranteed by the allocation of old memory.

Marking-finishing algorithm

It is obvious that the tag replication algorithm is not very suitable for the old era, where GC usually uses tags to clean up, that is, first marking the objects that can be recycled, then moving the surviving objects to one side of the memory space, and then directly cleaning up the memory beyond the boundary.

The biggest difference from mark-removal is that you need to move living objects, moving objects can avoid memory fragments, and you need to update all places that reference these objects, but it is easier to allocate memory; it is easy to reclaim memory without moving objects, while allocating memory becomes complicated because of memory fragments. So different collectors will choose their own algorithms according to their own characteristics, such as Parallel Old focus on throughput using tag replication, CMS focus on latency using flag cleanup.

Root node enumeration

So far, all collectors need to freeze all user threads when enumerating GC Roots, that is, STW (Stop The World), so how to find all root node objects efficiently must be solved. HotSpot uses exact GC to speed up the enumeration of GC roots. The so-called accurate GC is to let JVM know the type of data in a certain location in memory. For example, whether the data in the current memory location is an integer variable or a reference type. In this way, JVM can quickly determine the location of all reference types for more targeted GC roots enumeration.

HotSpot uses OopMap to implement accurate GC. When the class is loaded, HotSpot stores the data of what type of offset value in the object memory layout into OopMap; in the JIT compilation process of HotSpot, relevant instructions are also inserted to indicate where the object reference is stored, so that when GC occurs, HotSpot can directly scan the OopMap to get the storage location of object reference, thus carrying out GC Roots enumeration. (? Still don't understand why you need OopMap)

Safe points and safe areas

Because there are so many instructions that cause the reference relationship to change, that is, to change the content of the OopMap, if each instruction generates a corresponding OopMap, it will consume a lot of extra space, so the HotSpot only records this information in a specific location, which is the safe point. The existence of the safe point requires that when GC, the user thread must execute to the safe point before it can be paused, instead of pausing anywhere in the instruction flow. When the collector needs to pause the user thread, it does not operate directly on the thread, but sets a flag, which will be actively polled by each thread during execution, and if the flag is true, it will be actively interrupted and suspended at the nearest safe point.

A problem with the safe point can not be solved, that is, if the user thread is in the state of sleep or blocked, it must not be able to respond to the interrupt to get to the safe point, so it needs a safe zone to solve. A security zone is a guarantee that the reference relationship will not change in a code snippet, so it is safe to start a GC anywhere in that area. When the user thread executes the code in the safe zone, it will identify itself as entering the safe zone, so during this time JVM does not have to worry about the threads that are already in the safe zone to initiate GC. When the thread leaves the safe zone, it must check that JVM has finished enumerating the root node, and if not, it must wait all the time.

Concurrency reachability analysis

After the root node enumeration is completed, you need to traverse the entire object graph from GC Roots, which is a very time-consuming process. Therefore, in order to reduce the STW time of GC, some collectors let the process of traversing the object graph and the user thread execute concurrently, which greatly reduces the STW time. However, if the user thread modifies the reference relationship during this period, it will cause marking errors, such as the following figure:

Object D in the image above is mistakenly recycled. Causing a white object to be incorrectly recycled requires two conditions to be met at the same time:

The assignor inserts one or more new references from black objects to white objects.

The assignor removes all direct or indirect references from the gray object to the white object

There are two ways to solve it:

Incremental update: breaking condition 1, when the black object inserts a new reference to the white object, the newly inserted reference is recorded, and after the concurrent scan is over, the black object in these records is re-scanned as Roots.

Original snapshot: broken condition 2, when the gray object deletes the reference to the white object, the reference to be deleted is recorded, and when the concurrent scan is over, scan again with the gray object as Roots. Note that the second scan is the original data scanned (so it is called the original snapshot), and the second scan finds a reference from C to D, so D is judged to be alive. There is a problem with this, that is, if there is no new reference from A to D, D will be mistakenly judged to be alive, but this does not matter, because the object that should be recycled is judged to be alive far less than the object that should survive as a recycling problem, just waiting for the next recycling.

In HotSpot, CMS uses incremental updates to mark concurrency, while G1 and Shenandoah use the original snapshot.

Garbage collector Serial/Serial old

Serial collector is a very early and simple new generation collector, it is a "single thread" (described as serial may be more appropriate) collector, the extra consumption of resources is very small, under the condition of limited hardware resources, it is still the preferred collector, so the default collector in HotSpot VM client mode is Serial. The disadvantage of Serial is also very obvious, that is, it will be STW throughout the GC period.

The Serial old collector is an old version of Serial. The difference is that Serial uses the tag-copy algorithm and Serial old uses the tag-collation algorithm.

Related parameter:-XX:+UseSerialGC

PerNew

The PerNew collector is essentially a multithreaded parallel version of the Serial collector and a new generation of collectors that are usually used with CMS or Serial old (no longer supported after JDK9). In the single-core or even dual-core processor environment, the effect of PerNew is not as good as Serial because of the overhead of thread interaction, but the efficiency improvement is still very obvious with the increase of cores. By default, PerNew uses the same number of threads as the number of processor logical cores.

Enable parameter: this parameter is canceled after-XX:+UseParNewGC,JDK 9

Specify the number of garbage collection threads:-XX:ParallelGCThreads

Parallel Scavenge

Parallel Scavenge is also a collector for the new generation, using tag-copy, parallel collection. Scaveng is very similar to PerNew, and so is the GC process, but its main concern is system throughput.

Can control the throughput of the system

# the maximum pause time of each GC. The parameter value is the number of milliseconds greater than 0-XX:MaxGCPauseMillis# throughput. The parameter value is an integer greater than 0 and less than 100. The default value is 99, that is, the maximum time of GC is 1 / (1-99) = 1%-XX:GCTimeRatio of the total time allowed by the system.

According to the operation of the system, Scavenge can dynamically adjust the ratio of Eden area to Survivor area, object promotion age and other parameters to provide appropriate pause time or maximum throughput. The parameter to enable this function is-XX:+UseAdaptiveSizePolicy

Parallel Scavenge is the default young generation garbage collector for JDK 8, with a startup parameter of-XX:+UseParallelGC.

Parallel Old

Parallel old is a multithreaded concurrent collector based on the tag-collation algorithm, which is designed to work with Scavenge, which is also the default collector combination for JDK 8. Startup parameter:-XX:+UseParallelOldGC

CMS

CMS (Concurrent Mark Sweep) is an old-fashioned collector based on the mark-and-clear algorithm, which is designed to reduce GC pause time. The previous collectors all have an Achilles' heel: the whole process of GC requires STW,CMS. Although it doesn't solve this problem completely, it greatly shortens the time of STW. It divides the GC process into the following steps:

Initial tag (initial mark)

STW is required, and only objects with which GC Roots can be directly associated are marked. This process is very fast.

Concurrent tagging (concurrent mark)

Without STW, start traversing the object graph from the object you got in the previous step, a process that takes a long time but runs concurrently with the user thread.

Relabel (remark)

STW is required, and it takes less time to correct the tag record of the part of the object whose tag changes due to the running of the user thread during the concurrent marking.

Concurrent cleanup (concurrent sweep)

Do not need STW, concurrent clean up marked dead objects, because it is a direct clean up does not need to clean up, so it is also running concurrently with the user thread.

Enable parameter:-XX:+UseConcMarkSweepGC

Disadvantages of CMS:

Because of the mark-clear algorithm, memory fragmentation is inevitable, and Full GC is triggered when there are too many fragments to allocate space for large objects.

Unable to handle floating garbage. The newly generated garbage during concurrent marking and concurrent collation cannot be cleaned up in this GC and can only be saved until the next GC. Similarly, because the user thread is still running during GC, we can't start GC until all the old space is occupied, and we need to leave some space for the user thread during GC, so start GC (- XX:CMSInitialingOccupancyFracion) when there is much space left. This is very critical. If the memory reserved during GC can not meet the allocation of objects, concurrency fails. At this point, JVM will enable Serial old to restart the old garbage collection.

Although the user thread will not be frozen during parallel processing, the collector itself will occupy part of the system resources, resulting in a decline in the throughput of the user thread. The default number of threads used by CMS is $(number of processor cores + 3) / 4 $.

G1

Before the G1 (Garbage First), the target scope of the garbage collector was clear: Minor GC, Major GC, and whole heap (Full GC). G1 is no longer like this, it can be collected from any part of heap memory to form a collection, the measure is no longer which generation it belongs to, but which piece of memory has the largest amount of garbage and the highest recycling revenue, which is the G1 Mixed GC mode. Starting from G1, most new collectors no longer pursue to clean up the garbage at once, but to pursue the memory allocation rate that can cope with the application, as long as the collection speed can keep up with the memory allocation speed of new objects, that is perfect.

Instead of insisting on a fixed size or number of generational regions, G1 divides a continuous heap into multiple independent regions of equal size (Region), and each Region can act as Eden, Survivor, or Old space as needed (G1 is still collected by generation). The size of each Region can be set by the parameter-XX:G1HeapRegionSize, the value range is 1MB-32MB, and should be 2 to the N power. There is a special area in Region for storing large objects-Humongous Region,G1 believes that objects that exceed half of the capacity of Region are large objects, while those that exceed the capacity of Region will be stored in N consecutive Humongous Region.

G1 takes Region as the smallest unit of a single collection, tracks the amount of space and time required for each Region recovery, and then maintains a priority list in the background, giving priority to the most valuable Region each time according to the allowed pause time set by the user (- XX:MaxGCPauseMillis, default 200ms), thus ensuring a limited time and possibly high recycling efficiency. This memory layout makes G1 mark-clean as a whole and mark-copy from two Region, avoiding the problem of memory fragmentation caused by mark-removal of CMS.

To solve the problem of "intergenerational" referencing, G1 lets each Region have its own memory set, which records which Region references the objects of this Region. The implementation of a memory set is a hash table, key is the starting address of another Region, and value is a collection in which the elements stored are the index numbers of the card table. As a result, the G1 memory set is more complex to maintain and takes up more space than the CMS card table, and the memory set consumes roughly 10 to 20 percent of the stack space.

G1 uses the original snapshot algorithm in the concurrency marking phase, and adds two TAMS (Top at Mark Start) pointers to each Region to allocate a part of the space in the Region for the allocation of new objects in the concurrency process. The objects in this part of the space are alive by default and will not be included in the recycling scope of the current GC.

The operation of the G1 collector is roughly divided into four steps:

Initial mark

Need STW, mark objects that GC Roots can be directly associated with, and modify the value of the TAMS pointer.

Concurrent tagging

Without STW, start traversing the object graph from the object you got in the previous step.

Final mark

STW is required to handle objects with reference changes during concurrent markup

Screening and recovery

Need STW, update the statistics of Region, sort the recovery value and cost of each Region, make a recovery plan according to the pause time expected by the user, freely select multiple Region to constitute the collection, copy the surviving objects in the recycled Region to the empty Region, and then clean up the entire Region space.

G1 is the default collector for JDK11. Enable parameter:-XX:+UseG1GC

Disadvantages of G1:

Because each Region has a memory set and its structure is more complex, the memory footprint is higher than that of CMS.

In addition to using post-write barriers to maintain more replicated memory sets, it is also necessary to use pre-write barriers to track changes in concurrent marking phase references, which puts an additional burden on user programs.

Shenandoah

Shenandoah uses the same Region memory layout as G1. By default, it also gives priority to Region with high recycling value. The biggest difference between G1and G1 is:

Generational collection is not used by default

The recovery phase can be in parallel with the user thread

Use the global data structure of the join matrix (Connection Matrix) to record reference relationships across Region.

As shown in the figure above, the object of Region5 refers to the object of Region3 and marks it in 3 rows and 5 columns; Region3 refers to the object of Region1 and marks it on 1 row and 3 columns (the position on the figure is wrong).

The working process of the Shenandoah collector is roughly divided into nine processes:

Initial mark

STW is required to mark objects with which GC Roots can be directly associated.

Concurrent tagging

Without STW, start traversing the object graph from the object you got in the previous step.

Final mark

STW is needed to deal with objects with changes in references during concurrent markup, and statistics show that the Region with the highest recovery value constitutes a recycling set.

Concurrent cleanup

Without the need for STW, clean up the Region that does not have a living object.

Concurrent recovery

Without the need for STW, copy the surviving objects to the unused Region.

How Shenandoah solves the problem of user thread accessing the copied object when copying the object, because the references held by other objects are not updated at this time, and if the object is read and written at this time, the data will be inconsistent. The way is to add a new reference field in front of the original object layout structure, that is, the forwarding pointer, and when it is not normally in concurrent movement, the forwarding pointer points to the object itself, and when it moves, modify the value of the forwarding pointer to a new address, so that all references to the object can be forwarded to the new copy. For concurrency security, CAS is used to modify the forwarding pointer.

Initial reference update

STW is required to establish a thread assembly point to ensure that all concurrent recycling threads have finished moving objects.

Concurrent reference update

Without the need for STW, fix the reference to the old object in the heap to the copied new address.

Final reference update

If STW is required, fix the reference to GC Roots.

Concurrent cleanup

There is no need for STW, and the memory space of Region is cleaned concurrently.

As can be seen from the above nine steps, the pause time of Shenandoah is very short, and all time-consuming steps can be parallel to the user thread, so Shenandoah is a low-latency collector, and the average pause time of GC in actual operation does not exceed 50ms.

Enable parameter:-XX:UseShenandoahGC,openjdk12 join, currently in the experimental stage, it is expected that JDK15 can be used in production.

ZGC

ZGC collector is a garbage collector based on Region memory layout, without generation, using read barrier, color pointer and memory multi-mapping technology to achieve concurrent mark-finishing algorithm, with low latency as the primary goal. Referenc

Region memory layout

ZGC also uses a Region-based memory layout. Unlike G1, ZGC's Region is dynamic-- dynamic creation and destruction, and dynamic area capacity size, which can be roughly divided into three categories:

Mini Regoin (Small Region): fixed capacity 2MB, used to place objects smaller than 256KB.

Neutral Region (Medium Region): the capacity is fixed to 32MB, and objects greater than or equal to 256KB and less than 4MB are placed.

Large Region (Large Region): the capacity is not fixed and can be changed dynamically, but it must be an integral multiple of 2MB, which is used to place objects of 4MB and above. There is only one large object in each Large Region, so the minimum capacity of Large Region is 4MB.

Dyeing pointer

Only its reference relationship can determine whether an object survives or not, and all the attributes of the object can not affect the result of its survival, so it is most direct to record the tag information directly on the object pointer, the Serial collector records in the object header, and G1 uses a separate bitmap to store. Colored Pointer is a technique that stores a small amount of extra information directly on the pointer. In 64-bit system, the memory that can be accessed in theory is as high as 16EB (64-bit address), but in practice, only 52-bit (4PB) address bus and 48-bit (256TB) virtual address space are supported in AMD64 architecture. At the operating system level, 64-bit Linux only supports 47-bit (128TB) process virtual address space and 46-bit (64TB) physical address space, while Windows system is even less. Therefore, ZGC extracts the high 4 bits of the 46-bit pointer in the Liunx to store four flag information. Through these flag bits, the JVM can see directly from the pointer the tricolor flag state of its referenced object (Marked1, Marked0), whether it has entered the allocation set (that is, moved, Remapped), and whether it can only be accessed through the finalize method (Finalizable). This also results in that ZGC cannot manage more memory than 4TB (42-bit, JDK13 increases to 16TB), cannot support 32-bit platforms, and cannot use compression pointers.

The advantages of dyeing pointers are also very obvious, as follows:

After the dye pointer causes the surviving objects in the Region to be removed, the Region can be released or reused immediately, rather than having to wait for references to the Region in the heap to be corrected before cleaning up, as Shenandoah does. So in theory, as long as there is a free Region,ZGC, the collection can be completed.

Coloring pointers can significantly reduce the number of memory barriers used during garbage collection because reference change information has been maintained in pointers, eliminating previous operations that were recorded through the write barrier.

The dye pointer can be used as an extensible storage structure to record more data related to object marking and relocation process, so as to further improve performance in the future. For example, find a way to do something with the unused high 18 bits.

Multiple mapping

To understand how multiple mapping works, we need to briefly explain the difference between virtual memory and physical memory. Physical memory is the actual memory available to the system, usually the capacity of the installed DRAM chip. Virtual memory is abstract, which means that the application has its own view of (usually isolated) physical memory. The operating system is responsible for maintaining the mapping between virtual memory and physical memory ranges by using the memory management unit (MMU) of the page table and processor and the translation lookup buffer (TLB), which translates the address requested by the application.

ZGC on the Linux/X84-64 platform uses memory multiple mapping (Multi-Mapping) to map different virtual machine memory addresses to the same physical address, which is a many-to-one mapping, which means that ZGC sees more address space in virtual memory than the actual heap memory space. If the flag bits in the coloring pointer are regarded as segment splitters of the address, as long as these different address segments are mapped to the same physical memory space, after multiple mapping conversion, you can use the coloring pointer to address normally, as shown below:

Working process

The operation process of ZGC can be roughly divided into the following stages:

Initial mark

STW is required to mark objects with which GC Roots can be directly associated. ZGC scans all Region each time it is reclaimed, saving the maintenance cost of the memory set in G1 with a wider range of scanning costs.

Concurrent tagging

Without STW, start traversing the object graph from the object you got in the previous step, and update the Marked0 and Marked1 flag bits of the dye pointer.

Final mark

STW is required to deal with objects with reference changes during concurrent markup.

Concurrent Reserve reassignment (Concurrent Prepare for Relocate)

There is no need for STW. Figure out which Region will be cleaned up during this collection according to the specific query conditions, and then compose these Region into redistribution sets. Since the redistribution set that scans all Region,ZGC only determines that the surviving objects in it will be copied to other Region, the Region in the allocation set is released, so the tag is for the whole heap, but the collection is not.

Initial redistribution (Relocate Start)

STW is required to copy the objects directly associated with the GC Roots in the redistribution set to the new Region.

Concurrent redistribution (Concurrent Relocate)

Without the need for STW, copy the living objects in the redistribution set to the new Region, and maintain a forwarding table for each Region in the allocation set (not in the Region, in a separate area), recording the forwarding relationship from the old object to the new object. During this period, the user thread accesses the object in the redistribution set, which is intercepted by a preset memory barrier, then forwards the access to the new object according to the Region forwarding table, and modifies and updates the value of the reference to point to the new object-- ZGC calls this behavior the self-healing ability of the pointer. The advantage of this is that only the first access to the old object will get caught in forwarding, unlike the forwarding pointer of Shenandoah, which has forwarding overhead every time.

Concurrent remapping (Concurrent Remap)

Do not need STW, correct the references to the objects in the redistribution set throughout the heap, and release the forwarding table when finished. Because of the self-healing ability, this step does not need to be completed immediately, so ZGC merges this step into the concurrency phase of the next collection, saving the overhead of traversing the object graph.

Enable method:-XX:+UnlockExperimentalVMOptions-XX:+UseZGC,ZGC is officially added as an experiment in the Linux version of JDK11, while mac and windows require JDK14, which is expected to be officially Release in JDK15 for production.

On how to achieve JVM garbage collection is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.