Java garbage Collection Pristine-part3

The Java garbage collection essence is divided into 4 parts, this is the 3rd part of this article. In part 3rd, the serial collector, the parallel collector, and the concurrency Token cleanup collector (CMS) are described.

Serial collector (Serial Collector)

The serial collector is the simplest collector and is a great choice for single-processor systems. Of course, it is also the least common in all collectors. The serial collector uses a separate thread for collection, whether it is a secondary collection or a primary collection. Objects allocated in the old quarter use a simple bump pointer algorithm (Bump-the-pointer algorithm). When tenured space fills up, it triggers a major recycle.

In this technique, the JVM maintains a allocatedtail pointer inside, always pointing to the tail of the previously allocated object. When a new object assignment request arrives, it is only necessary to check the remaining space in the generation, that is, from Allocatedtail to Genetail to accommodate the object, and to update the Allocatedtail pointer and initialize the object in the case of "satisfied".

Parallel collector (Parallel Collector)

There are two forms of a parallel collector: a parallel collector (-xx:+ USEPARALLELGC) that uses multithreading in secondary recycling, single-threaded execution in primary recycling, and a parallel legacy collector (Parallel old) that is used by default from Java 7u4 Collector) (XX:+USEPARALLELOLDGC), using multithreading in both secondary and primary recycling. Objects allocated in tenured space use a simple bump pointer (bump-the-pointer) algorithm. When the old quarter fills up, it triggers a major recovery.

On multiprocessor systems, the parallel old generation collector is the most throughput collector, and only the collection begins to affect the running program. It is then collected using the most efficient algorithm, multiple parallel threads. This makes parallel legacy generation collectors ideal for batch applications.

The cost of recovering older generations is affected by the number of objects being retained, which is less affected by the heap size. To improve the efficiency of the parallel legacy collector collection and provide greater throughput, more memory, longer payback times, and fewer pauses at collection time are required.

This is expected to be the fastest secondary recovery. Because in this collector, the promotion to the old Quarter is a simple bump pointer (bump-the-pointer) and a copy operation.

For server applications, the parallel old generation collector must be the first stop for garbage collection. If the suspension of the primary recycle exceeds the application's tolerance limit, you need to consider using a collector that executes concurrently with the application to collect older objects.

Note: Under current hardware conditions, it is expected that a 1-5-second pause is required for the old generation of compression per GB of live objects.

Note: setting "-xx:+ Usenuma" in a multi-socket CPU server application can achieve better performance through a parallel collector. This is because the CPU slots on the thread local are allocated to Eden memory. Unfortunately, this feature is not supported by other collectors.

CMS (concurrency tag cleanup collector, Concurrent Mark Sweep)

The CMS (-xx:+ useconcmarksweepgc) collector is used in older generations to specifically collect older objects that cannot be reached in the primary collection. It runs concurrently with the application and maintains ample space in older generations to ensure that the young generation fails to promote.

A promotion failure will be triggered once fullgc,cms will be processed in the following steps:

1. Initialize tag: Look for the GC root.
2. Concurrency token: Marks all objects reachable from the GC root.
3. Concurrent pre-cleanup: Checks for updated object references and promoted objects in the concurrency tagging phase.
4. Re-tagging: Captures object references for the pre-clean phase to begin updating.
5. Concurrent cleanup: Updates the list of available spaces by reclaiming the memory occupied by the dead object.
6. Concurrent Reset: Resets the data structure to prepare for the next run.

When an old object becomes inaccessible, the occupied space is reclaimed by the CMS and placed in the free space list. When a promotion occurs, a list of free spaces is queried to find the right size for the promotion object. This increases the cost of the promotion, thus increasing the cost of secondary collection compared to the parallel collector.

Note: Unlike a compression collector, a CMS can produce fragments over time in older generations. Object promotion may fail because a large object may not be able to find a sufficient space available in the old generation. If this happens, the log logs a "promotion failed" message, and then triggers a FULLGC to compress the surviving old object. For this compression-driven FULLGC, because the CMS uses single-threaded compression, it can be expected to use a longer pause time than the primary collection using the parallel legacy generation collector.

The CMS runs as much as possible with the application, which has several layers of meaning. First, the CPU time is consumed by the collector, so the CPU can be used to reduce the time slice of the application. The amount of time consumed by CMS is linearly correlated with the number of promotions to tenured space (old age area). Second, for some phases of the concurrent GC cycle, all application threads must reach a security point, such as tagging the GC root and performing parallel re-tagging to check for updates.

Note: the re-tagging phase can be time-consuming if the object of an application's old age is significantly changed, and in extreme cases it may be longer than the compression time of a complete parallel legacy collector.

To reduce the frequency of FULLGC, CMS can be achieved by reducing throughput, using more time-consuming secondary recoveries, and taking up more space. Depending on the promotion rate, throughput will be 10%-40% less than parallel collection. The CMS also requires more than 20% of the space to hold additional data structures and "floating garbage" (floating garbage), which is discarded during the concurrent tagging phase and thrown to the next collection cycle processing object.

High promotion rates, and the resulting fragments, can sometimes be reduced by increasing the size of the new generation and the old generation of space.

Note: when the CMS reclaim space does not meet the promotion requirements, it may experience "concurrency mode failure (concurrent mode failures)", where records can be found in the log. This may be due to the fact that the collection is too late, which can be resolved by adjusting the policy. It could also be a collection of space-free rates that are not up to the high promotion rate or some applications that have super-elevated object update rates. If your program's promotion rate and update rate is too high, you may need to change your app to reduce the pressure on your promotion. Increasing memory to the CMS can sometimes make the situation worse because it requires more memory to be scanned.

Java garbage Collection Pristine-part3