Complete JVM learning notes please click here

GC classification and performance index

  • Garbage collectors are not specified in the specification and can be implemented by different vendors and versions of JVMS.
  • Due to the rapid iteration of JDK versions, Java has spawned numerous GC versions to date.
  • By analyzing the garbage collector from different perspectives, GC can be categorized into different types.

According to the number of threads, it can be divided into serial garbage collectors and parallel garbage collectors

  • Serial collection means that only one CPU is allowed to perform garbage collection at a time, at which point the worker thread is suspended until the garbage collection is complete.
    • Performance of the serial collector may exceed that of parallel and concurrent collectors in fields where hardware platforms such as single-CPU processors or small application memory are not particularly superior. So serial reclamation is applied by default to the JVM in Client mode on the Client side
    • Such that, on a CPU with high concurrency capability, a parallel collector produces a shorter pause time than a serial collector.
  • In contrast to serial collection, parallel collection can use multiple cpus to perform garbage collection at the same time, thus improving the throughput of the application. However, parallel collection is still the same as serial collection, which is exclusive and uses a “Stop the world” mechanism.

According to the working mode, can be divided into parallel garbage collector and exclusive garbage collector

  • And the garbage collector works alternately with application threads to minimize application pause time.
  • Once run, the exclusive Stop the World garbage collector stops all user threads in the application until the garbage collection process is complete.

According to the way of debris treatment, it can be divided into compressed garbage collector and non-compressed garbage collector

  • The compressed garbage collector compresses the surviving objects after the collection is complete to eliminate the recovered fragments.
    • Redistribute object space using: pointer collisions
  • Non-compressed garbage collectors do not do this.
    • Reallocate object space usage: free list

According to the working memory interval, it can be divided into young generation garbage collector and old generation garbage collector

Evaluate the performance metrics for GC

  • == Throughput: The percentage of total elapsed time spent running user code ==

    • (Total running time: the running time of the program ten memory reclamation time)

  • Garbage collection overhead: the complement of throughput, the ratio of the garbage collection time to the total elapsed time.

  • == pause time: The amount of time a program’s worker thread is suspended while garbage collection is being performed ==

  • Collection frequency: How often collection operations occur relative to the execution of the application.

  • == Memory usage: The size of memory occupied by the Java heap ==

  • Fast: The time an object takes from birth to being recycled.

  • Together they form an impossible triangle. The overall performance of all three will get better and better as technology advances. A good collector usually does at most two of these.

  • Of these three, time out becomes increasingly important. Because more memory footprint becomes more tolerable as hardware evolves, hardware performance improvements also help reduce the impact of collector runtime on the application, which increases throughput. Memory expansion has a negative effect on latency.

  • In brief, two main points should be taken:

    • throughput
    • The pause time

throughput

  • Throughput is the ratio of CPU time spent running user code to total CPU consumption, i.e. Throughput = user code time run/(User code time run + garbage collection time)
    • Such as: if a virtual machine runs for 100 minutes and garbage collection takes 1 minute, then throughput is 99%
  • In this case, applications can tolerate high pause times, so high-throughput applications have a longer time baseline and fast response is not a concern.
  • Throughput first, which means that STW has the shortest time per unit time: 0.2 + 0.2 = 0.4

The pause time

  • “Pause time” refers to a period of time during which the application thread is paused to allow the GC thread to execute
    • For example, a 100-millisecond pause time during a GC means that no application thread is active during that 100-millisecond period. .
  • Pause time priority means keeping the time of a single STW as short as possible: 0.1+0.1 +0.1 +0.1=0.5

  • High throughput is good because it gives the end user of the application the impression that only application threads are doing “productive” work. Intuitively, the higher the throughput, the faster the application will run.
  • Low pause times (low latency) are better because it is always bad from the end user’s point of view whether an application is suspended for GC or any other reason. Depending on the type of application, sometimes even a brief 200-millisecond pause can interrupt the end-user experience. Therefore, it is very important to have low large pause times, especially for an interactive application.
  • Unfortunately, “high throughput” and “low pause times” are competing goals.
    • Trained, trained, trained, trained, trained, trained, trained.
    • Preparation, on the contrary, if low-latency priority is selected, then in order to reduce the pause time of each collection, it can only be performed frequently, which in turn causes memory shrinkage in the young generation and leads to a decrease in program throughput.
  • When designing (or using) a GC algorithm, we must determine our goals: a GC algorithm can only target one of two goals (i.e. focus only on large throughput or minimal pause times), or. Try to find a compromise.
  • Now standard: Reduce pause times when maximum throughput is first.

Overview of different garbage collectors

Garbage collection is Java’s signature capability and greatly improves development efficiency. This is of course a hot topic for interviews. So, what are the common Java garbage collectors?

History of garbage collector

With virtual machines, there is a need for Garbage Collection. This is Garbage Collection, and the corresponding product is called Garbage Collector.

  • With JDK1.3.1 in 1999 came the Serial GC, which was the first GC in Serial mode. The ParNew garbage collector is a multithreaded version of the Serial collector
  • Parallel GC and Concurrent Mark Sweep GC were released along with JDK1.4.2 on February 26, 2002
  • Parallel GC became the HotSpot default GC after JDK6.
  • In 2012, G1 was available in JDK 1.7U4.
  • In 2017, G1 became the default garbage collector in JDK9, replacing CMS.
  • Parallel full garbage collection for G1 garbage collector in JDK10 in March 2018, implementing parallelism to improve worst-case latency.
  • ==———— Watershed ————==
  • JDK11 was launched in September 2018. Introduced the Epsilon garbage collector, also known as the “No – 0P (No action) “collector. At the same time, the introduction of ZGC: scalable low delay garbage collector (Experimental).
  • In March 2019, JDK12 was released. Enhanced G1 to automatically return unused heap memory to the operating system. Meanwhile, Shenandoah GC: Experimental GC with low pause time is introduced.
  • JDK13 was released in September 2019. Enhanced ZGC to automatically return unused heap memory to the operating system.
  • In March 2020, JDK14 was released. Delete the CMS garbage collector. Extend ZGC on macOS and Windows

Seven classic garbage collectors

  • Serial collector: Serial. Serial Old
  • Parallel recycle: parnew.parallel Avenge. Parallel Old
  • Concurrent collector: cms.g1

The relationship between seven classic garbage collectors and garbage generation

  • Cenozoic collectors: Serial, ParNeW, Parallel Scavenge;
  • Serial 0LD, Parallel 0LD, CMS;
  • Whole heap collector: G1;

The composition of the garbage collector

  1. There is a line between the two collectors, indicating that they can be used together: Serial/Serial 01D, Serial/CMS, ParNew/Serial 01D, ParNew/CMS, Parallel Scavenge/Serial 01D, Parallel Scavenge/Parallel insane 0 ld, G1;
  2. Serial 0LD is a backup plan for Concurrent Mode Failure of CMS. 3. (red dotted line) Due to maintenance and compatibility testing costs, the combination Serial+CMS and ParNew+Serial 01D were declared obsolete in JDK 8 (JEP 173) and completely unsupported in JDK 9 (JEP214), i.e. : removed.
  3. Insane and Serial0ld GC JDK 14
  4. JDK 14: Delete CMS garbage collector (JEP 363)
  • Why have a lot of collectors not enough? Because Java is used in many scenarios, mobile, server and so on. Therefore, it is necessary to provide different garbage collectors for different scenarios to improve the performance of garbage collection.
  • Although we will compare each collector, we are not trying to pick the best one. There is no one-size-fits-all, one-size-fits-all collector, and there is no one-size-fits-all collector. So we chose only the collector that was most appropriate for our specific application.

View the default garbage collector

  • A xx: +PrintCommandLineFlags: View command line related parameters (including the garbage collector used)
  • Use the command line command: jinfo one flag Process ID for related garbage collector parameters
/** * -xx :+ printCommandFlags ** -xx :+UseSerialGC: indicates that the new generation uses the Serial Old GC ** -xx :+UseParNewGC: ParNew GC * * -xx :+UseParallelGC * -xx :+UseParallelOldGC: * * -xx :+UseConcMarkSweepGC: UseConcMarkSweepGC: UseConcMarkSweepGC At the same time, Public class GCUseTest {public static void main(String[] args) {ArrayList<byte[]> list = new ArrayList<>();while(true){ byte[] arr = new byte[100]; list.add(arr); try { Thread.sleep(10); } catch (InterruptedException e) { e.printStackTrace(); }}}}Copy the code

The output

-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC 
Copy the code

Or the command line

Parallel is used in JDK8



Jdk9 uses G1

Serial collector: Serial collector

  • The Serial collector is the most basic and oldest garbage collector. The only option to recycle the new generation before JDK1.3.
  • The Serial collector is the default new generation garbage collector in Client mode in HotSpot.
  • The Serial collector performs memory collection using a copy algorithm, Serial collection, and a “Stop the World” mechanism.
  • In addition to the young generation, the Serial collector also provides the Serial 0LD collector for performing the old generation garbage collection. The Serial 0LD collector also uses Serial collection and the “Stop the World” mechanism, but the memory collection algorithm uses the mark-one compression algorithm.
    • Designed to be an old age garbage collector running in Client mode by default
    • Preparation of the Serial 0LD for Server applications. ② As a backup garbage collection solution for the old CMS collector
  • The collector is a single-threaded collector, but its “single-threaded” meaning is not only that it uses only one CPU or one collection thread to complete garbage collection, but also that it must suspend all other worker threads while it collects garbage until it stops The World.

advantage

  • Simple and efficient (compared to the single-threaded collections of other collectors), the Seria1 collector naturally achieves the highest single-threaded collection efficiency in a single-CPU-constrained environment because it has no overhead of thread interaction.
    • Virtual machine running in Client mode is a good option.
  • In a user’s desktop application scenario, the available memory is generally small (tens of MB to one or two hundred MB), garbage collection can be completed in a relatively short time (tens of ms to more than one hundred ms), and serial collector is acceptable as long as it does not occur frequently.
  • In the HotSpot VIRTUAL machine, a XX: +UseSerialGC parameter can be used to specify that both young and old generations use serial collectors.
    • It is equivalent to replace Serial GC for freshmen and Serial 0LD GC for seniors
    • Console output-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseSerialGC

conclusion

  • This garbage collector, as you know, is no longer serial. And in the limited single-core CPU can only be used. It’s not even mono anymore.
  • For highly interactive applications, this garbage collector is unacceptable. T serial garbage collectors are generally not used in Javaweb applications.

ParNew collector: Parallel collection

  • If the Serial GC is a single-threaded garbage collector in the younger generation, the ParNew collector is a multithreaded version of the Serial collector.

    • Preparation of Paralle1, New: To deal only with the New generation

  • There is little difference between the two garbage collectors except that the ParNew collector performs memory collection in a parallel collection manner. The ParNew collector in the younger generation also uses the copy algorithm, the “stop-the-world” mechanism.

  • ParNew is the default garbage collector for the new generation of many JVMS running in Server mode.

  • For the new generation, the recycling times are frequent and the parallel method is efficient.

  • For the old age, the number of recycling is less, using the serial way to save resources. (CPU parallel need to switch threads, serial can save the resources of switching threads)

  • Since the ParNew collector is based on parallel collection, is it safe to assume that the ParNew collector will be more efficient at collecting than the Serial collector in any scenario? | I

    • Trained in multi-CPU environment, the ParNew collector can make full use of the advantages of physical hardware resources such as multi-CPU and multi-core, thus completing garbage collection more quickly and improving the throughput of the program.
    • Trained, however, on a single CPU, the ParNew collector is no more efficient than the Serial collector. Although the Serial collector is based on Serial collection, because the CPU does not need to switch tasks frequently, it can effectively avoid some of the extra overhead associated with multithreaded interactions.

  • Because in addition to Serial, only the ParNew GC currently works with the CMS collector

  • In the program, the developer can specify the use manually with the option “a XX: +UseParNewGC”. The ParNew collector performs a memory reclamation task. It means that the younger generation uses the parallel collector without affecting the older generation.

  • A XX: ParallelGCThreads limits the number of threads that are enabled by default. .

Parallel collector: Throughput first

  • The younger generation of HotSpot, in addition to having the ParNew collector based on Parallel recycling, also uses copying algorithms, Parallel recycling, and “Stop the World” mechanisms.
  • So is Parallel collector superfluous?
    • Unlike the ParNew collector, the Parallel Insane collector aims to achieve a controlled Throughput ==, which is also known as a Throughput first garbage collector.
    • Adaptive adjustment strategy is also a key difference between the Parallel Avenge and ParNew.
  • High throughput can efficiently use of CPU time, as soon as possible to complete the program | computing tasks, main should be suitable for operation in the background and don’t need too much interaction tasks. Therefore, it is commonly used in server environments. For example, applications that perform batch processing, order processing, payroll, and scientific calculations.
  • Parallel collector the Parallel 0ld collector for performing old-age garbage collection was provided in JDK1.6 in place of the old-age Serial 0ld collector.
  • The Parallel 0LD collector uses a mark-to-compression algorithm, but is also based on Parallel collection and a “stop-the-world” mechanism.

  • In application throughput first scenarios, the combination of the Parallel collector and the Parallel 0LD collector performs well in Server mode.
  • In Java8, the default is this garbage collector

Parameter configuration

  • A XX: +UseParallelGC manually specifies that young generations use the Parallel collector to perform memory reclamation tasks.
  • A XX: +UseParallel0ldGc manually specifies that older generations are using parallel collection collectors.
    • It applies to the new generation and the old age respectively. Jdk8 is enabled by default.
    • One of the above two parameters is enabled by default, and the other is enabled as well. (Mutual activation)
  • A XX: ParallelGCThreads sets the number of threads for the young generation of parallel collectors. In general, it is best to match the number of cpus to avoid too many threads affecting garbage collection performance.
    • By default, when the number of cpus is less than 8, the value Paralle lGCThreads equals the number of cpus.
    • ParallelGCThreads = 3+[5* cpu_count]/8 when the number of cpus is greater than 8
  • A XX: MaxGCPau3eMillis sets the maximum garbage collector pause time (that is, the STw time). The units are milliseconds.
    • Trained: In order to keep the pause time within MaxGCPauseMills as much as possible, Adjust the Java heap size or some other parameter at work.
    • : : For the user, the shorter the pause, the better the experience. But on the server side, we focus on high concurrency, overall throughput. So the server side is suitable for Parallel control. Such parameter should be used with caution.
  • XX: GCTimeRatio Ratio of garbage collection time to total time (= 1 / (N + 1)) Measures throughput.
    • Locality: Value range (0, 100). The default value is 99, which means that the garbage collection time does not exceed 1.
    • Prepared for preparation of one XX: MaxGCPauseMillis The longer the pause time, the Radio parameters tend to exceed the set ratio.
  • Apply the avenge avenge an adaptive adjustment policy
    • In this mode, parameters such as the size of the young generation, the ratio of Eden to Survivor, and the age of objects promoted to the old generation are automatically adjusted to reach a balance between heap size, throughput, and pause time.
    • In cases where manual tuning is difficult, you can use this adaptive approach to specify only the maximum heap of the virtual machine, the throughput of the target (GCTimeRatio), and the pause time (MaxGCPauseMills), and let the virtual machine do the tuning itself.

CMS collector: Low latency

  • In the JDK1.5 era, HotSpot introduced a garbage collector that could almost be considered revolutionary in strongly interactive applications: CMS (Concurrent one Mark one Sweep) collector, the first truly Concurrent collector in the HotSpot VIRTUAL machine, for the first time allowing garbage collection threads to work simultaneously with user threads.
  • The FOCUS of the CMS collector is to minimize the pause time of user threads during garbage collection. The shorter the pause interval (low latency), the better the application that interacts with the user, and the better the response speed improves the user experience.
    • Very large part of Java applications currently focus on the server side of Internet sites or B/ S systems. Such applications pay particular attention to the response speed of the service and hope to have the shortest system pause time so as to bring better user experience. The CMS collector is a good fit for such applications.
  • CMS’s garbage collection algorithm uses the tag-one cleanup algorithm and will also “stop a the world”
  • Unfortunately, CMS, as an older collector, does not work with the Parallel Insane, a new generation collector that already exists in JDK 1.4.0, so when CMS was used to collect older ages in JDK 1.5, The new generation can only choose one of the ParNew or Serial collectors.
  • Before G1, CMS was widely used. Today, there are still many systems using CMS GC.

The whole process of CMS is more complex than the previous collector. The whole process is divided into four main stages, namely the initial marking stage, concurrent marking stage, re-marking stage and concurrent clearing stage.

  • Initial Mark phase: In this phase, all the worker threads in the program will be affected. The main task of this phase is simply to mark the objects to which GCRoots can be directly associated. Once the tag is complete it will resume all applications that were previously suspended. Threads. Because the directly related object is small, the speed here is very fast.
  • Concurrent Mark phase: The process of traversing the entire object graph from the directly associated object of the GC Roots. This process is time-consuming but does not require the suspension of the user thread and can be run concurrently with the garbage collection thread.
  • Re-marking phase: Because in concurrent mark phase, the program will work thread and garbage collection threads run at the same time or cross operation, thus to correct during concurrent tags, tags that changes caused by the user program continue to operate the part of object mark record, this phase of the pause time usually slightly longer than the initial mark phase, but also far shorter than the concurrent mark phase.
  • Concurrent Sweep phase: This phase removes dead objects judged by the marking phase and frees memory space. Since there is no need to move live objects, this phase can also be concurrent with the user thread

Although the CMS collector uses concurrent collection (non-exclusive), it still performs a “Stop the World” mechanism to suspend the worker thread in the program during its initialization and re-marking phases, but not for very long. Thus, none of the current garbage collectors do not need to “Stop the World” at all, but simply keep the pause time as short as possible. Because the most time-consuming concurrent marking and concurrent cleanup phases do not require pauses, the overall collection is low-pause. In addition, since the user threads are not interrupted during the garbage collection phase, you should also ensure that the application user threads have enough memory available during the CMS collection process. Therefore, the CMS collector does not wait until the old age is almost completely filled, as other collectors do. Instead, the CMS collector starts collecting when the heap memory usage reaches a certain threshold to ensure that the application still has enough space to run while the CMS is working. If the CMS is running without enough memory to meet the program’s requirements, a “Concurrent Mode Failure” occurs, at which point the virtual machine starts a fallback: the Serial 0LD collector is temporarily enabled to restart the old garbage collection, resulting in long pauses. The GARBAGE collection algorithm of the CMS collector adopts the mark-clean algorithm, which means that after each collection, some memory fragments will inevitably be generated because the memory space occupied by the useless objects that perform the collection is most likely to be discrete chunks. The CMS will not be able to use the Bump the Pointer technique to allocate memory for new objects, and will only be able to select the Free List to allocate memory.

One might think that since Mark Sweep causes memory fragmentation, why not change the algorithm to Mark Compact? The answer is simple, because when concurrent cleanup is done, using Compact memory, how do you use the memory used by the user thread? To ensure that the user thread can continue to execute, the resource it is running on is not affected. The Mark Compact is better suited for “Stop the World” scenarios

· Advantages of CMS:

  • Concurrent collection
  • Low latency

Disadvantages of CMS:

  • 1) Memory fragmentation will be generated, resulting in insufficient space available for user threads after concurrent clearing. In the case that large objects cannot be allocated, the Full GC has to be triggered early.
  • 2) THE CMS collector is very CPU sensitive. In the concurrent phase, it does not cause user pauses, but it does slow down the application and reduce overall throughput by taking up a portion of the threads.
  • 3) THE CMS collector cannot handle floating garbage. A “Concurrent Mode Failure” may occur, resulting in another Full GC. In the concurrent marking stage, the worker thread and garbage collection thread of the program run at the same time or cross, so if new garbage objects are generated in the concurrent marking stage, CMS will not be able to mark these garbage objects, which will eventually lead to the timely collection of these newly generated garbage objects. These previously unreclaimed memory Spaces can only be freed on the next GC.

Parameter Settings

  • A XX: +UseConcMarkSweepGc manually specifies the use of the CMS collector to perform memory reclamation tasks.
    • Trained, trained, trained, trained, trained. ParNew (for Young area) +CMS (for 0LD area) +Serial 0LD combination.
  • A XX: CMS1ni tiatingOccupanyFraction Sets a threshold for heap memory usage. Once this threshold is reached, reclamation begins.
    • The default value for JDK5 and earlier versions is 68, that is, when the space usage of older generations reaches 68, one is executed. CMS collection. JDK6 5 or later the default value is 92
    • Preparation: If memory growth is slow, a slightly larger value can be set. A larger threshold can effectively reduce the triggering frequency of the CMS, and a reduction in the number of old age recollections can significantly improve application performance. Conversely, if your application’s memory usage is growing rapidly, you should lower this threshold to avoid triggering the old serial collector too often. Therefore, this option can effectively reduce the number of Full GC executions.
  • A XX: + UseCMSCompactAtFullCollection is used to specify the execution of the Full after GC to compress the memory space, so as to avoid the generation of memory fragments. The problem, however, is that the pause times become longer because the memory compacting process cannot be executed concurrently.
  • How many times a XX: CMSFullGCsBeforeCompaction Settings in the execution Full GC to compress the memory space after finishing.
  • A XX: ParallelCMSThreads sets the number of CMS threads.
    • The default number of threads started by CMS is (ParallelGCThreads+3) /4. ParallelGCThreads is the number of threads for the young generation of parallel collectors. When CPU resources are tight, application performance can be very poor during the garbage collection phase due to the impact of CMs collector threads.

Summary:

HotSpot has so many garbage collectors, so if someone asks, what is the difference between Serial GC, Parallel GC, and Concurrent Mark Sweep GC? Remember the following passwords: Serial GC if you want to minimize memory and parallel overhead; If you want to maximize the throughput of your application, Parallel GC; If you want to minimize GC interrupts or pauses, select CMS GC.

Changes to CMS in later JDK releases

  • New JDK9 feature: CMS marked as Deprecate (JEP291)
    • If you enable the CMS collector with XX: +UseConcMarkSweepGC on a HotSpot VIRTUAL machine with JDK 9 or later, you will receive a warning that the CMS will be deprecated in the future.
  • New features for JDK14: Remove CMS garbage collector (JEP363)
    • The CMS garbage collector has been removed. If you use a XX: +UseConcMarkSweepGC in JDK14, the JVM will not issue an error, just a warning message, but no exit. The JVM automatically falls back and starts the JVM in the default GC mode

G1 collector: Regionalization generation type

Why release Garbage First (G1) GCS when we already have the First few powerful GCS? The reason is that applications are dealing with more and more large and complex businesses, more and more users, without GC can not ensure the normal operation of the application, and often the STW GC can not keep up with the actual needs, so they constantly try to optimize GC. The G1 (Garbage First) Garbage collector is a new Garbage collector introduced after Java7 update4, and is one of the most advanced achievements in today’s collector technology development. At the same time, in order to accommodate today’s expanding memory and increasing number of processors, pause time is further reduced while maintaining good throughput. The official goal for G1 is to achieve the highest possible throughput with manageable latency, hence the heavy burden and expectation of a “fully functional collector” ==

Why is it called Garbage First (G1)?

  • Because G1 is a parallel collector, it divides heap memory into a number of unrelated regions (physically discontinuous). Use different regions to represent Eden, Survivor 0, Survivor 1, old age, and so on.
  • The G1 GC systematically avoids region-wide garbage collection across the entire Java heap. G1 tracks the value of garbage accumulation in each Region (the amount of garbage collection space obtained and the experience value of garbage collection time), maintains a priority list in the background, and collects garbage from the Region with the highest value according to the allowed collection time.
  • Since this approach focuses on regions where the most Garbage is collected, we gave G1 a name: Garbage First.
  • G1 (Garbage First) is a Garbage collector for server applications. It is mainly aimed at machines equipped with multi-core CPUS and large memory capacity. It meets the GC pause time with a high probability and has high throughput performance characteristics.
  • In JDK1.7 version officially enabled, removed the identity of Experimental, is the default garbage collector after JDK 9, replacing CMS collector and Parallel + Parallel 0LD combination. Oracle officially calls it a “full-featured garbage collector.”
  • CMS, meanwhile, has been marked deprecated in JDK 9. It is not the default garbage collector in JDK8 and needs to be enabled using a XX: +UseG1GC.

advantage

Compared to other GC collectors, G1 uses an entirely new partitioning algorithm, which features the following:

  • Parallelism and concurrency
    • Concurrency: G1 can have multiple Gc threads working at the same time during collection, effectively utilizing multi-core computing power. At this point the user thread is STW
    • Concurrency: G1 has the ability to alternate execution with the application, so that part of the work can be performed simultaneously with the application, so that, generally speaking, the application will not be completely blocked throughout the reclamation phase
  • Generational collection
    • G1 is still a generational garbage collector. It can distinguish the young generation from the old generation. The young generation still has Eden zone and Survivor zone. However, from the structure of the heap, it does not require the whole Eden area, the young generation or the old generation to be continuous, nor does it insist on fixed size and fixed quantity.
    • The division of heap space into regions containing logical young and old generations.
    • Very different from previous types of recyclers, it is designed for both young and old generations. Compare other recyclers, either working in the younger generation or working in the older generation;
  • Spatial integration
    • : : Token one clean algorithm, memory fragmentation, one defragmentation after several Gc’s
    • Preparation of Memory into regions in G1. Memory reclamation is based on region. Region to Region is a copy algorithm, but overall can actually be regarded as a Mark to Compact algorithm, both algorithms can avoid memory fragmentation. This feature helps programs run for a long time and allocate large objects without triggering the next GC prematurely because contiguity memory space cannot be found. This is especially true when the Java heap is very large.
  • Predictable pauses model (i.e., soft real-time soft real time) this is another big advantage of G1 relative to CMS, G1 in addition to the pursuit of low pause, also can establish predictable pauses model, can let the user specify in a length of M segment within milliseconds, time on garbage collection may not consume more than N milliseconds.
    • Prepared, therefore, that G1 can only select part of the region for memory reclamation due to partitioning, thus reducing the scope of reclamation and thus achieving good control over the occurrence of global pauses.
    • Trained, trained, trained, trained, trained, trained, trained, trained, trained, trained, trained, trained, trained, trained. The G1 collector is guaranteed to achieve the highest possible collection efficiency in a limited time.
    • : : Compared with CMSGC, G1 may not be able to achieve the delay of CMS in the best case, but in the worst case. Much better.

disadvantages

  • Compared to CMS, G1 does not have a comprehensive, overwhelming advantage. For example, G1 has a higher garbage collection Footprint and overload than CMS during user program execution.
  • Empirically, CMS is more likely to outperform G1 in small memory applications, while G1 is more likely to outperform G1 in large memory applications. The balance point is between 6 and 8GB.

Parameter Settings

  • A XX: +UseG1GC manually specifies the use of the G1 collector to perform memory reclamation tasks.
  • A XX: G1HeapRegionSize Sets the size of each Region. The value is a power of 2, ranging from 1MB to 32MB, and the goal is to partition about 2048 regions based on the minimum Java heap size. The default is 1/2000 of the heap.
  • A XX: MaxGCPauseMillis sets the maximum Gc pause time metric that the JVM will try to achieve, but is not guaranteed to achieve. The default value is 200ms
  • A xX: ParallelGCThread sets the value of sTw. The number of worker threads. The maximum value is 8
  • A XX: ConcGCThreads sets the number of concurrent threads to flag. Set n to about 1/4 of the number of parallel garbage collection threads (ParallelGCThreads).
  • A XX: Ini tiatingHeapOccupancyPercent set trigger a concurrent GC cycle Java heap usage rate threshold value. If this value is exceeded, GC is triggered. The default value is 45.

Common steps for G1 collector

G1 was designed to simplify JVM performance tuning by developers in three simple steps:

  • Step 1: Start the G1 garbage collector
  • Step 2: Set the maximum memory for the heap
  • Step 3: Set a maximum pause time

There are three garbage collection modes available in G1: YoungGC, Mixed GC, and Full GC, which are triggered under different conditions.

Applicable scenario

  • Server – oriented applications for machines with large memory and multiple processors. (Does not work in a normal-sized heap. Surprise)
  • The most important applications are applications that require low GC latency and have a large heap of solutions;
  • For example, when the heap size is about 6GB or larger, predictable pause times can be less than 0.5 seconds; G1 ensures that each GC pause is not too long by incrementally cleaning only some regions at a time, not all of them.
  • To replace the CMS collector in JDK1.5; Using G1 may be better than CMS when: ① More than 50% of the Java heap is occupied by active data; (2) The frequency of object assignment or chronological lifting varies greatly; ③ The GC pause time is too long (longer than 0.5 to 1 seconds).
  • In addition to G1, other garbage collectors use a built-in JVM thread to perform multi-threaded GC operations. G1 GC can use application threads to perform background GC operations. When the JVM’s GC thread is slow, the application thread is called to help speed up the garbage collection process.

Divide region into parts

Using the G1 collector, it divides the entire Java heap into about 2048 independent Region blocks of the same size. The size of each Region block depends on the actual size of the heap. The whole Region block is controlled between 1MB and 32MB, and it is controlled to the NTH power of 2, that is, 1MB, 2MB, 4MB, 8MB, 16MB. 32 MB. This can be set with a XX: G1HeapRegionSize. All regions are the same size and do not change during the lifetime of the JVM.

Although the concept of Cenozoic and oldyn is still retained, Cenozoic and oldyn are no longer physically separated; they are collections of parts of regions (which do not need to be continuous). Dynamic Region allocation enables logical continuity.

  • A region may belong to Eden, Survivor, or 0LD /Tenured memory regions. However, a region can belong to only one role. In the figure, E indicates that the region belongs to Eden memory region, S indicates that the region belongs to Survivor memory region, and 0 indicates that the region belongs to 0LD memory region. Blank Spaces in the figure represent unused memory space.
  • The G1 garbage collector also adds a new memory region called the Humongous memory region, shown in block H. It is used to store large objects. If the number of regions exceeds 1.5, the region is added to H.
  • The reason for setting H:
    • Large objects in the heap are directly assigned to the old age by default, but if it is a short-lived large object, this can have a negative impact on the garbage collector. To solve this problem, G1 has a Humongous section, which is dedicated to large objects. If an H block does not fit a large object, G1 looks for contiguous H blocks to store. Sometimes you have to start the Full GC in order to find consecutive H regions. Most of G1’s behavior treats the H region as part of the old age.

G1 collector garbage collection process

The garbage collection process of G1 GC mainly includes the following three steps:

  • Young GC
  • Concurrent Marking in the old days
  • Mixed GC
  • (Single-threaded, exclusive, high-intensity Full GC will still exist if needed. It provides a fail-safe mechanism against GC evaluation failures, i.e., strong collection.

    Clockwise, young GC – > Young GC + Concurrent mark – > Mixed GC
  • The application allocates memory and starts the young generation reclamation process when the young generation’s Eden area is exhausted. G1’s young-generation collection phase is a parallel, exclusive collector. During the young generation collection period, the G1 GC suspends all application threads and starts multithreading to perform the young generation collection. Then move the surviving object from the young generation to the Survivor or the old, or possibly both.
  • When heap memory usage reaches a certain value (45% by default), the old-age concurrent marking process begins.
  • Mark the finished horse. Start the mixed recycling process. For a mixed payback period, the G1 GC moves live objects from the old period to the free period, which becomes part of the old period. Unlike the young generation, the G1 collector of the old generation does not need to recycle the entire old generation, but only scan/reclaim a small number of old regions at a time. At the same time, the old Region is reclaimed along with the young generation.
  • For example, a Web server with a Java process with a maximum heap memory of 4 gigabytes responds to 1500 requests per minute and allocates about 2 gigabytes of new memory every 45 seconds. G1 does a young generation collection every 45 seconds, and every 31 hours the entire heap reaches a level of 45, starting the old generation concurrent marking process, and four or five mixed collections after the marking is complete.

Memory sets and write barriers

  • The problem of an object being referenced by different regions (generational referencing problem)
  • A Region cannot be isolated. Objects in a Region can be referenced by objects in any Region. Do YOU need to scan the entire Java heap to determine whether an object is alive?
  • This problem also exists in other generational collectors (more so in G1)
  • Will the new generation also have to scan the old?
  • This would reduce MinorGC’s efficiency;
  • · Solutions:
    • RememberedSet:
    • (3) Every Region has a corresponding Remeset;
    • Preparation: A Write Barrier temporary interruption operation will be generated every time a Reference class data Write operation is performed; .
    • Preparation of such an object, such as an object of the Reference type, to which the Reference is to be written is in a different Region from the Reference type.
    • Preparation: If not, the relevant reference information is recorded in the Remembered Set of the Region where the reference points to the object through CardTable.
    • Memory Set added to the enumeration of the root of the GC when garbage collection is performed; You can guarantee that no global scan will be done, and there will be no omissions.

Details of G1 recovery process

1. Young GENERATION GC

  • When JVM starts, G1 prepares Eden area first, and the program continuously creates objects to Eden area during the running process. When Eden space runs out, G1 will start a young generation garbage collection process.
  • Young generation garbage collection will only collect Eden and Survivor areas.
  • In YGC, G1 first stops The execution of The application (Stop The World) and creates a Collection Set, which refers to The Collection of memory segments that need to be reclaimed. The Collection in The young generation reclamation process contains all memory segments in The Eden area and Survivor area of The young generation.
  • Then start the following recycling process:
    • In the first stage, the roots are scanned. The root refers to the object to which the static variable points, the local variable in the chain of method calls being executed, and so on. The root reference, along with the external reference to the RSet record, serves as the entry point for scanning the living object.
    • Phase 2, update the RSet.

      Process cards in the Dirty Card queue (see remarks) and update the RSet. After this phase is complete, the RSet can accurately reflect the reference of the old age to the object in the memory segment.
      • Dirty Card Queue: For the application’s reference assignment statement Object. field=object, the JVM performs special operations before and after to enqueue a card that holds object references in the dirty Card queue. During the recycle of the young generation, G1 will process all cards in the Dirty Card Queue to update the RSet and ensure that the RSet accurately reflects the reference relationship in real time. Why not update the RSet directly at the reference assignment statement? This is for the sake of performance, RSet processing requires thread synchronization, which can be very expensive, using queue performance is much better.
    • In the third stage, the RSet is processed. Identify the objects in Eden that are pointed to by the old objects. The objects in Eden that are pointed to are considered alive.
    • In the fourth stage, objects are copied. At this stage, the object tree is traversed, and the surviving objects in the memory segment of Eden area will be copied to the hollow memory segment of Survivor area. If the age of surviving objects in the memory segment of Survivor area does not reach the threshold, the age will be increased by 1. When the age reaches the threshold, the surviving objects will be copied to the hollow memory segment of 01D area. If Survivor space is insufficient, some data in Eden space will be promoted directly to the old space.
    • The fifth stage deals with references. Handle Soft, Weak, Phantom, Final, JNI Weak etc references. Finally, the data in Eden space is empty, GC stops working, and the objects in the target memory are continuously stored without fragmentation. Therefore, the replication process can achieve the effect of memory consolidation and reduce fragmentation.

2. Concurrent marking process

  • Initial marking phase: marking objects directly reachable from the root node. This phase is STW and will trigger one. Subyoung generation GC.
  • Root Region Scanning: THE G1 GC scans the old Region objects that are directly reachable from the Survivor Region and marks the referenced objects. This process must be completed before the Young GC.
  • Concurrent Marking: Concurrent Marking (and application execution) throughout the heap, which can be interrupted by the Young GC. During the concurrent marking phase, if all objects in a region object are found to be garbage, the region is immediately reclaimed. At the same time, the object activity (the percentage of living objects in the region) of each region is calculated during concurrent tagging.
  • Remark: As the application continues, the result of the last mark needs to be corrected. Is the STW. G1 uses a faster initial snapshot algorithm than CMS: Snapshot one at one the Beginning (SATB).
  • Exclusive cleanup (STW) : Calculates the percentage of live objects and GC collections for each region and sorts them to identify areas that can be mixed for collection. Set the stage for the next phase. Is the STW.
    • This stage does not involve actual waste collection
  • Concurrent cleanup phase: Identify and clean up completely free areas.

3. Mixed recycling

As more and more objects are promoted to oldregion, in order to avoid running out of heap memory, the virtual machine triggers a Mixed garbage collector, namely Mixed GC, which is not an 0ldGC and will reclaim part of 0ldRegion in addition to the whole Young Region. Note here: part of the old era, not all of it. You can choose which 0ldRegion to collect, thereby controlling the time it takes to collect garbage. Also note that Mixed GC is not a Fu1l GC.

  • After the concurrent marking ends, the segments that are 100% garbage in the old age are reclaimed and the segments that are partially garbage are calculated. By default, these older memory segments are collected eight times (with a XX: G1MixedGCCountTarget setting).
  • The Collection Set of a mixed Collection consists of one-eighth of old age segments, Eden segment, and Survivor segment. The algorithm of hybrid collection is exactly the same as the algorithm of young generation collection, but it collects more memory segments of the old generation. Please refer to the young generation recycling process above for details.
  • Since memory segments are recycled eight times by default in older generations, G1 prioritises memory segments with more garbage. The higher the percentage of garbage in memory segments, the more garbage will be collected first. And has a threshold value will determine whether memory segments are recycled, a xX: G1MixedGCLiveThresholdPercent, the default is 65%, mean waste of memory block to achieve 65% can be recycled. If the garbage ratio is too low, it means that there is a high percentage of live objects, which will take more time to replicate.
  • Mixed recycling does not have to be done eight times. There is a threshold of Xx: G1HeapWastePercent, which defaults to 10%, meaning that 10% of the total heap memory is allowed to be wasted, meaning that if the percentage of garbage that can be recycled is less than 10% of the heap memory, no mixed recycling is done. Because GC takes a lot of time but recycles very little memory.

4. Full GC

The G1 was designed to avoid Full GC. But if that doesn’t work, G1 stops application execution (Stop The World) and uses a single-threaded memory reclamation algorithm for garbage collection, with poor performance and long application pauses. To avoid Full GC, you need to adjust once it happens. When will Full GC happen? For example, if the heap is too small, G1 will fall back to full GC when there is no empty segment available for copying live objects, a situation that can be resolved by increasing memory. There are two possible causes of G1Full GC:

  • (1) At the time of Evacuation, there is not enough to a space to hold the object of the promotion;
  • 2. The space is used up before the concurrent processing is complete.

supplement

According to official disclosures from Oracle, the Evacuation phase is. I also thought about designing it to run concurrently with user programs, but it was complicated. Considering that G1 only reclaims part of a Region and the pause times are controlled by the user, it was not urgent to implement this feature, and instead it was put into the low-latency garbage collector (ZGC) that emerged after G1. In addition, considering that G1 is not only geared toward low latency, pausing the user thread can maximize garbage collection efficiency, so the implementation of pausing the user thread completely was chosen to ensure throughput.

Optimization Suggestions

  • Young generation size
    • Preventing explicit setting of the size of the young generation using an Xmn or XX: NewRatio option
  • Don’t be too strict with your pause time goals
    • The throughput goal for the G1 GC is 90% application time and 10% garbage collection time
    • When evaluating G1 GC throughput, don’t be too harsh with pause time goals. Being too strict with your goals indicates that you are willing to incur more garbage collection overhead, which has a direct impact on throughput.

Garbage collector summary

As of JDK 1.8, there are seven different garbage collectors. Each different garbage collector has different characteristics, in the specific use of time, according to the specific situation of the selection of different garbage collector.



Virtual machine implementations vary greatly from vendor to vendor and version to version. HotSpot virtual machine after JDK7/8 all collectors and combinations (wired) as shown below:

  • 1. There is a line between the two collectors, indicating that they can be used together: Serial/Serial 0LD, Serial/ CMS, ParNew/Serial 0LD, ParNew/CMS, Parallel Scavenge/Serial 01D, Parallel Scavenge/Parallel 0 ld, G1;
  • 2. Serial 0LD is the backup plan for Concurrent Mode Failure of CMS.
  • 3. (red dashed line) Due to maintenance and compatibility testing costs, the combination Serial+CMS and ParNew+Serial 0LD were declared Deprecated in JDK 8 (JEP 173) and completely Deprecated in JDK 9 (JEP214), i.e. : Removed.
  • The ParallelScavenge avenge and Serial0ld GC JDK 14.
  • Serial => Parallel => CMS => G1 => ZGC

How do I choose a garbage collector

  • The configuration of the Java garbage collector is an important choice for JVM optimization, and choosing the right garbage collector can make a big difference in JVM performance.
  • How do I choose a garbage collector?
    • 1. Prioritize heap resizing to allow JVM adaptation.
    • 2. If the memory is less than 100M, use the serial collector
    • 3. If it is a single-core, single-machine program, and there is no pause time requirements, serial collector
    • 4. If it is multi-CPU, requires high throughput, and allows pause times of more than 1 second, choose parallelism or the JVM’s choice
    • 5. If you have multiple cpus and want low pause time, you need fast response (such as delay of no more than 1 second, such as Internet applications), use concurrent collector
    • The G1 is officially recommended for high performance. The current Internet projects are basically using G1.
  • Finally, we need to clarify one point:
    • 1. There is no best collector, and there is no universal collection;
    • 2. Tuning is always for specific scenarios, specific needs, and there is no one-size-fits-all collector

GC Log Analysis

By reading GC logs, we can understand the Java virtual machine memory allocation and reclamation policies. List of parameters for memory allocation and garbage collection

  • A XX: +PrintGC prints Gc logs. Verbose: a verbose: gc
  • A XX: +PrintGCDetails prints the GC details log
  • A XX: +PrintGCTimeStamps prints GC timestamps (in base time)
  • A XX: +PrintGCDateStamps prints the GC timestamp (in the form of a date, such as 2013/05-04T21:53:59.234 +0800)
  • A XX: +PrintHeapAtGC prints out the heap information before and after GC
  • Xloggc:.. /logs/ gc.log Output path

+PrintGC

  • Open GC log: one verbose: GC
  • This only shows the total GC heap change as follows:
[Allocation Failure (GC) 80832K >19298K (227840K), 0.0084018 secs] [Metadata GC Threshold) 109499K >21465K (228352K), 0.0184066 secs] [Full GC (Metadata GC Threshold) 21 465K一>16716K (201728K), 0.0619261 secs]Copy the code
  • Parameter analysis:
GC, Full GC: GC type, GC only on Cenozoic, Full GC includes immortal generation, Cenozoic, old generation. Allocation Failure: The reason why GC occurs. 80832K - > 19298K: heap size before and after GC. 228840K: Current heap size. 0.0084018 SECs: duration of GC.Copy the code

PrintGCDetails

– Open GC log: one verbose: GC one XX: +PrintGCDetaiis

  • Enter the following information:
[GC （Allocation Failure） [ PSYoungGen： 70640K一> 10116K（141312K） ] 80541K一>20017K （227328K），0.0172573 secs] [Times： user=0.03 sys=0.00， real=0.02 secs ]
[GC （Metadata GC Threshold） [PSYoungGen：98859K一>8154K（142336K） ] 108760K一>21261K （228352K），
0.0151573 secs] [Times： user=0.00 sys=0.01， real=0.02 secs]
[Full GC （Metadata GC Threshold） [PSYoungGen： 8154K一>0K（142336K） ] [ParOldGen： 13107K一>16809K（62464K） ] 21261K一>16809K （204800K），[Metaspace： 20599K一>20599K （1067008K） ]，0.0639732 secs]
[Times： user=0.14 sys=0.00， real=0.06 secs]
Copy the code
  • Parameter analysis:
The PSYoungGen insane insane insane insane insane insane insane insane insane insane insane Metaspace Metaspace is introduced in JDK1.8 to replace the permanent generation XXX secs: refers to the amount of time the Gc takes. Times: user: Refers to all CPU time spent by the garbage collector, sys: time spent waiting for system calls or system events, real: time spent by the GC from start to finish, including the actual time spent by other processes in the time slice.Copy the code

PrintGCTimeStamps

  • To open the GC log:Verbose: gc a XX: +PrintGCDetails a XX: +PrintGCTimeStamps a XX: +PrintGCDateStamps
  • Enter the following information:
2019-09-24T22:15:24.518 + 0800:3.287: [Allocation Failure (GC)] 13612k 一> 13613k (136192K)] 141425K一>17632K (222208K), 0.0248249secs] [Times: User =0.05sys=0.00, real= 0.03secs] 2019-09-24T22:15:25.559 + 0800:4.329: [GC (Metadata GC Threshold)] [PSYoungGen: [Times: Times: 3285k] [Times: 3285k] [Times: 3285k] [Times: 3285k] User = 0.00sys =0.00, real= 0.01 secs] 2019-09-24T22:15:25.569 + 0800:4.338: [Full GC (Metadata GC Threshold)] [PSYoungGen: 10068K一>0K (274944K)] [ParoldGen: 12590K一>13564K] 22658K一>13564K, [Metaspace: [Times: user=0.17 sys= 0.02, real= 0.05secs] [Times: user=0.17 sys= 0.02, real= 0.05secs]Copy the code

Explanation: Bring the date and time

added

  • “[GC” and “[Full GC” indicate the type of pause for this garbage collection, and “Full” indicates that the GC has “StopThe World”
  • Using Serial the collector in the New Generation is named De Fault New Generation, so it displays “[DefNew”
  • – The name of the collector using ParNew will be changed to “[ParNew”, meaning “Parallel New Generation”.
  • Use the Parallel Insane. The Cenozoic insane is called “PSYoungGen.”
  • The name of the old collection is determined by the collector, just like the new one
  • Using the G1 collector, it shows “garbage first heap”
  • Allocation Failure indicates that this time GC is caused because there is not enough space in the young generation to store new data.
  • [PSYoungGen: 5986K一>696K (8704K)] 5986K一> 704K (9216K) GC collects the size of the previous young generation and the old generation, and the size after the collection, (total size of the young generation and the old generation)
  • User indicates the reclaim time in user mode, sys kernel mode, and REA mode. Due to multicore, the sum of times may exceed real time

Minor GC

Full GC

case

/** * Run * -verbose: gC-xMS20m-XMx20m-xmn10m-xx :+PrintGCDetails -xx :SurvivorRatio= 8-xx :+UseSerialGC */ public class GCLogTest1 { private static final int _1MB = 1024 * 1024; public static voidtestAllocation() {
        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];
    }

    public static void main(String[] agrs) {
        testAllocation(); }}Copy the code


Use log analysis tools

There are tools available to analyze these GC logs. Common log analysis. Tools: GCViewer, GCEasy, GCHisto, GCLogViewer, Hpjmeter, Garbagecat, etc.

New developments in garbage collectors

GC is still in rapid development, the current default option G1 GC is constantly improving, many of the shortcomings we previously thought of, such as serial Full GC, Card Table scanning inefficiency, have been greatly improved, for example, after JDK 10, Fu1l GC has been running in parallel. In many scenarios, it also performs slightly better than Parallel GC’s Parallel Full GC implementation. Even Serial GC, although relatively old, is not necessarily obsolete in its simple design and implementation. Its overhead, whether GC related data structure overhead, or thread overhead, is very small. Therefore, with the rise of cloud computing, in new application scenarios such as Serverless, Serial GC has found a new arena. Unfortunately, CMS GC has been deprecated in JDK9 and removed in JDK14, although it still has a very large user base due to theoretical flaws in its algorithm.

JDK11 new features

  • JEP318: Epsilon: No one Op A Garbage Collector (Epsilon Garbage Collector, “No one Op (No operation)” Collector) HTTP: / / openidk.java.net/ieps/318
  • JEP333: A Scalable Low Latency; Garbage Collector (Experimental) (ZGC: Scalable low delay retreat 竝 Sakan Collector, Experimental)

Open JDK12的Shenandoah GC

  • The G1 collector has been the default collector for several years now.
  • We also saw the introduction of two new collectors: ZGC (JDK11 appears) and Shenandoah (Open JDK12).
    • Primary feature: low pause time

Shenandoah GC for Open JDK12: Low-pause GC (Experimental)

  • Shenandoah is undoubtedly the loneliest of the many GC’s. The first HotSpot garbage collector not developed by the Oracle team. Inevitably ostracized by the authorities. For example, Oracle, which claims no difference between OpenJDK and OracleJDK, still refuses to support Shenandoah in OracleJDK12.
  • Shenandoah Garbage Collector An implementation of the PauselessGC, a garbage collector research project originally undertaken by RedHat, was designed to address the need for low pauses for memory collection on the JVM. Contributed to OpenJDK in 2014.
  • Red Hat’s Shenandoah team claims that the Shenandoah garbage collector pauses regardless of the size of the heap, meaning 99.9% of the time, whether the heap is set to 200MB or 200GB, can limit garbage collection pauses to less than 10 milliseconds. However, actual usage performance will depend on the actual working heap size and workload.
  • RedHat published a paper in 2016 that tested using Es to index 200GB of wikipedia data. From the results:
    • The pause time is a qualitative leap compared to other collectors, but it does not achieve the maximum pause time under ten milliseconds.
    • There was a significant drop in throughput, with the longest total running time of any test collector.
  • Weakness of the Shenandoah GC: Throughput degradation under high operating load.
  • Shenandoah GC’s strength: low latency.

The revolutionary ZGC

ZGC is highly similar to Shenandoah’s goal of achieving low latency that can limit garbage collection pauses to less than 10 milliseconds at any heap size with as little impact on throughput as possible. The ZGC collector is a garbage collector based on Region memory layout, with (for now) no generation, using techniques such as read barriers, dye Pointers, and memory multiple mapping to implement concurrent marker-compression algorithms, with low latency as the primary goal. The working process of ZGC can be divided into four stages: concurrent marking, concurrent preparatory reallocation, concurrent reallocation, concurrent remapping, etc. ZGC is executed almost everywhere concurrently, except for the sTW that is initially marked. So the pause time is almost spent on the initial tag, the actual time for this part is very small.

Test data is shown in figure:

Disadvantages compared

Advantage to compare

In the pause time test, which the ZGC is strong at, it pulls away two orders of magnitude from the Parallel and G1 without mercy. The ZGC has no trouble keeping average pauses, 958 pauses, 998 pauses, 99.98 pauses, and maximum pause times under 10 milliseconds.

JDK14 new features

JEP 364: ZGC on macOS JEP 365: ZGC on Windows Before JDK14, ZGC was supported only on Linux

  • Although many users of ZGC use Linux-like environments, they also need ZGC for development deployment and testing on Windows and macOS. Many desktop applications can also benefit from ZGC. As a result, the ZGC feature was ported to Windows and macOs.
  • ZGC is now available on MAC or Windows as an example: a XX: +Unloc kExperimentalVMOptions a XX: +UseZGC.

Other garbage collectors :AliGC

AliGC is alibaba JVM team based on G1 algorithm, for LargeHeap application scenarios. Comparison in the specified scenario:Of course, other vendors offer a variety of unique GC implementations, such as the well-known low-latency GC, Zing (www.infoq.com/articles/az…)


JVM learning code and notes

【 code 】 github.com/willShuhuan… JVM_02 Class loading subsystem JVM_03 Run time data area 1- [program counter + vm stack + local method stack] JVM_04 Local method interface JVM_05 Run time data area 2- heap JVM_06 run time data area 3- Method area JVM_07 JVM_08 Execution Engine JVM_09 String constant pool StringTable JVM_10 Garbage Collection 1- Overview + Related algorithm JVM_11 Garbage Collection 2- Concepts related to garbage collection JVM_12 Garbage collection 3- Garbage collector