The G1 Garbage collector is designed to “collect as much Garbage as possible First,” with the goal of minimizing the pauses associated with processing very large heaps (more than 4GB).

Therefore, G1 does not wait until memory runs out (such as the Serial Serial collector or Parallel collector) when the CMS is running out. Instead, G1 uses an internal heuristic algorithm to find regions with high collection benefits in the past to collect.

At The same time, G1 can automatically adjust The size of The young generation and The total heap according to The stop-the-world (STW) pause time goal set by The user (response time first). The shorter The pause time, The smaller The space of The young generation and The larger The total heap space.

An obvious advantage of G1 over CMS is that the generation rate of memory fragmentation is greatly reduced.

G1 is available in JDK7u4 and above, and in JDK9, G1 is the default garbage collector, replacing CMS.

G1 algorithm

Algorithm: three color mark + SATB

The characteristics of G1

  • Garbage collector for server-side applications
  • Parallelism and concurrency: The G1 takes full advantage of multiple cpus,multicoreThe environment uses multiple cpus or CPU cores to shortenSTW(stop-the-world) pause time.
  • Generational collection: G1 is physically non-generational, but logically still has the concept of generational.
  • Space consolidation: no memory space fragmentation will be generated. After collection, it can provide regular available memory and organize free space faster.
  • Predictable pauses (which can be planned to avoid district-wide garbage collection across the entire JAVA heap)
  • This is suitable for scenarios where high throughput is not required
  • The JAVA heap memory layout differs significantly from other collectors in that it divides the entire JAVA heap into multiple independent regions or partitions of equal size (Region).
  • G1 collector, used by virtual machinesRemembered SetTo avoid a full heap scan.

G1 memory model

Partitioning concepts

Traditional GC collectors divide contiguous memory space into new generation, old generation, and permanent generation (JDK 8 removes permanent generation and introduces Metaspace),

This division is characterized by sequential storage addresses (logical addresses, likewise below) for each generation. As shown below:

However, the storage addresses of G1 generations are discontinuous. Each generation uses n discontinuous regions of the same size, and each Region occupies a contiguous virtual memory address.

Region(Region, zone)

G1 uses the concept of regions to divide the entire heap space into several memory regions of equal size. Each allocation of object space uses memory segment by segment.

The concept of Cenozoic and olderage is retained, but Cenozoic and olderage are no longer physically isolated, they are collections of partial regions (which do not need to be continuous).

Therefore, G1 does not require the storage of objects to be physically contiguous, just logically contiguous, in the use of the heap.

Each partitionRegionIt does not definitely serve a generation and can switch between the younger and older generations as needed.

During startup, use -xx :G1HeapRegionSize=n to specify the partition size (1MB to 32MB, which must be a power of 2). The heap is divided into 2048 partitions by default.

Card(card)

Each partition Region is divided into several 512 Byte cards, which identify the minimum available granularity of the heap memory.

Cards of all regions are recorded in the Global Card Table.

The allocated object occupies several cards that are physically contiguous.

When looking for a reference to an object in a partitioned Region, the reference object can be found using a record card (see RSet).

Each memory reclamation is to process the cards in the specified partition.

Heap(heap)

G1 can also specify the heap size with -xms / -xmx.

When a young generation collection (YGC) or Mixed collection occurs, the heap size is automatically adjusted by calculating the elapsed time ratio of GC to application.

If the GC frequency is too high, the GC frequency is reduced by increasing the heap size, and the time consumed by GC is correspondingly reduced.

The target parameter -xx :GCTimeRatio is the ratio of GC time to application time. G1 defaults to 12 (JDK7,8 to 99, JDK11+ to start with 12), while CMS defaults to 99 because CMS is designed to spend as little time on GC as possible.

In addition, when there is insufficient space, such as object space allocation or transfer failure, G1 will first attempt to increase heap space, and if capacity expansion fails, it will initiate a guaranteed Full GC.

After Full GC, the heap size calculation results will also adjust the heap space.

Generational concept

Generation(points)

Generational garbage collection can focus on the most recently allocated objects without whole heap scanning, avoiding copies of long-lived objects, and independent collection helps reduce response times.

While partitioning eliminates the need for compact memory allocation, the G1 still uses the idea of generations.

Like other garbage collectors, G1 logically divides memory into young and old generations, with the young generation in turn divided into Eden space and Survivor space.

However, the young space is not fixed, and when the existing young partition is full, the JVM allocates a new free partition to the young space.

The entire young generation memory will dynamically change between the initial space -xx :NewSize and the maximum space -xx :MaxNewSize, and is calculated by the parameter target pause time -xx :MaxGCPauseMillis, the size to be expanded or reduced, and the memory set (RSet) of the partition.

Of course, G1 can still set a fixed young generation size (parameters -xx :NewRatio, -xmn), but pausing the target also makes no sense.

#####Local allocation Buffer (LAB) It is worth noting that due to the partitioning idea, each thread can “claim” a partitioned Region for thread-local allocation, regardless of whether the partition is contiguous or not.

Therefore, each application thread and GC thread will use partitions independently to reduce synchronization time and improve GC efficiency. This partition Region is called locally allocated Buffer (LAB).

  • Apply thread-local buffersTLABThe application thread can have a local buffer exclusively (TLAB), and most of the objects will fall into Eden area (except for giant objects or allocation failure), so TLAB partition belongs to Eden space;
  • GC thread local bufferGCLABEach GC thread can also monopolize a local buffer for each garbage collection (GCLAB) is used to transfer objects, each collection will copy the object to Suvivor space or old chrono space;
  • Promoting local buffersPLAB: For objects promoted from Eden/Survivor space to Survivor/ old space, there is also a gC-exclusive local buffer, which is called promoted local buffer (PLAB).

Partition model

Humongous Object(Giant object)

An Object that is 50% or more in size than a partitioned Region is called a Humongous Object. A large object can monopolize one or more contiguous partitions, where the first partition is marked as StartsHumongous and contiguous contiguous partitions as ContinuesHumongous. The Humongous Object has the following characteristics:

  • Humongous ObjectDirect allocation to the old era, to prevent repeated copy movement.

When a thread allocates space for a giant, it cannot simply allocate it in TLAB because of the high cost of moving a giant object and the possibility that a partition may not hold a giant object. Therefore, large objects are allocated directly in the old age, occupying contiguous space called Humongous regions.

  • Humongous Object 在 YGCStage,Global Concurrent MarkingPhase of theCleanup 和 FGCPhase recovery.

Since the optimization brought by LAB is not available and the entire Heap scan is required to determine a contiguic memory space, the cost of determining the starting location of a giant object is very high, and the application should avoid generating a giant object if possible.

  • In the distribution ofHumongous ObjectCheck if the constraint is longer than the one that is likely to be used-XX:InitiatingHeapOccupancyPercentControl) and the marking Threshold. If this is exceeded, the concurrent collection cycle is startedConcurrent Marking CycleIn order to recycle earlier and preventEvacuation Failure 和 Full GC.
RSet （Remember Set, memory set)

In serial and parallel collectors, GC scans the heap to determine whether an object is in a reachable path.

However, in order to avoid stW-type Heap scan, G1 records a memorized set (RSet) in each partition Region, which is similar to a reverse pointer inside and records the index of Card referencing objects in the partition Region.

To reclaim the Region of the Region, scan the RSet of the Region to determine whether the objects referenced in the Region are alive, and then determine whether the objects in the Region are alive.

In fact, not all references need to be recorded in the RSet. If a partition Region determines that it needs to be scanned, it can get references without missing any RSet.

Objects that refer to a Region from a local Region do not fall into an RSet.

Also, the G1 GC collects the whole of the young generation each time, so references to objects from the young generation do not need to be recorded in the RSet.

Finally, only older partition regions can have RSet records. These partitions are called an RSet’s owning Region.

Per Region Table (PRT)

RSet internally uses Per Region Table(PRT) to record the references of partitioned regions. Since RSet records take up space for a partitioned Region, if a partition is very “popular”, the RSet footprint increases, reducing the available space for a partitioned Region. G1 addresses this problem by changing the density of the RSet, which will record references in three modes in the PRT:

  • Rare: Cards that directly record references to objectsCardThe index of the
  • Fine-grained: Records the partitions of reference objectsRegionThe index of the
  • Coarse-grained: Only references are recorded, one bit per partition

As can be seen from the above, coarse-grained PRT only records the number of references, and requires the whole Heap scan to find all references, so the scanning speed is also the slowest.

CSet(Collection Set, collection collection)

A collection collection (CSet) represents a series of target partition regions reclaimed each time a GC pauses.

During any collection pause, all partitions of the CSet are freed, and internal surviving objects are moved to the allocated free partition.

So whether young generation collection or mixed collection, the working mechanism is the same.

The CSet of YGC only contains the partitions of the young generation, while the Mixed GC will select the partitions with the highest recycling returns from the candidate recycling partitions of the old age through the heuristic algorithm and add them to the CSet.

  • Candidate old s partition CSet access conditions, can through the active threshold – XX: G1MixedGCLiveThresholdPercent 85% (default) Settings, to intercept the recycling expensive object;

  • At the same time, every time to collect old can contain the candidate s mixed partitions, according to the total size of CSet to heap of – XX: G1OldCSetRegionThresholdPercent cap on the number (10%) by default Settings.

It can be seen from the above that G1 collection is operated according to CSet, and there is no obvious difference between YGC and Mixed GC. The biggest difference lies in the triggering conditions of the two collections.

The younger generation collects collectionsCSet of Young Collection

As the application thread continues to be active, the young generation space gradually fills up. When the JVM fails to allocate an object to Eden’s region (Eden’s region is full), a STW-style collection of young generations is triggered. In the young collection set, the surviving objects in the Eden partition will be copied to the Survivor partition. The surviving objects of the existing Survivor partition will be promoted to PLAB, the new Survivor partition and the old decade partition respectively, according to the tenuring threshold. The original young generation partition will be recycled as a whole.

At the same time, the young generation collection is responsible for maintaining the age of the object (number of lives) and assisting in determining whether the aging object is promoted to the Survivor zone or to the old zone. Collection of young generation Firstly, the size sum and age information of promoted objects are maintained in the age table. Then calculate an appropriate tenure threshold based on the age table, Survivor size, Survivor fill capacity -xx :TargetSurvivorRatio(default 50%), maximum tenure threshold -xx :MaxTenuringThreshold(default 15). Any object that exceeds the tenure threshold is promoted to the old age.

Mixed collection collectionCSet of Mixed Collection

As the younger generation continues to collect, the space of the older generation will be gradually filled. When take up the space is more than a whole heap of old s IHOP threshold – XX: InitiatingHeapOccupancyPercent 45% (the default), the G1 will launch a hybrid garbage collection cycle.

In order to meet the pause goal, G1 may not be able to collect all candidate partitions at once, so G1 may produce multiple consecutive mixed collections that alternate with application threads, each STW mixing collection similar to the young-generation collection process.

  • To determine the old-age partition that contains the young-generation collection set CSet, the JVM passes the maximum total number of blending cycles through the parameters-XX:G1MixedGCCountTarget(Default 8), percentage of waste-XX:G1HeapWastePercent(Default 5%).

Through the total number of candidate old age partitions and the maximum total number of mixing cycles, the minimum number of partitions included in each CSet is determined.

When the collection parameters are reached, no new mixed collection will be started based on the percentage of heap waste. Each time a partition is added to the CSet, it is arranged by the calculated GC efficiency.

G1 activity cycle

G1 garbage collection includes the following:

  • Concurrent Marking Cycle Similar to the Concurrent collection process of CMS.

  • Young Collection (YGC, Young Generation Collection, STW)

  • Mixed Collection Cycle (STW)

  • Full GC (FGC, STW) JDK10

Concurrent marking cycleConcurrent Marking Cycle

The concurrent tagging cycle is a very important phase in G1, which identifies the old age partitions with the most garbage for the mixed collection cycle.

The cycle completes root marking, identifies all (possible) viable objects, and calculates the activity of each partition to determine the GC efficiency level.

When reach IHOP threshold – XX: InitiatingHeapOccupancyPercent (45% accounted for a whole heap of old s ratio, the default), will trigger a concurrent marking cycles.

The entire Concurrent Marking cycle consists of Initial Marking, Root Region Scanning, Concurrent Marking, re-marking, and Cleanup.

The initial mark (active with the young collection), relabelling, and clearing are STW’s, while concurrent marks that are too late to mark viable objects may trigger several more young collection (YGC) during concurrent marking.

Initial Marking(Initial flag, STW)

It marks objects directly reachable from GC Root.

In fact, when the IHOP threshold is reached, G1 does not immediately initiate a concurrent marking cycle. Instead, G1 waits for the next young generation to collect and completes the initial marking using the STW period collected by the young generation, a process known as Piggybacking.

Root region scanning(Root partition scan)

After the initial tag pause ends, the young generation collects the work of copying the completed objects to Survivor, and the application thread becomes active. At this time, to ensure the correctness of the marking algorithm, all newly copied objects to Survivor partition need to be scanned and marked as roots, a process known as Root Region Scanning, and Suvivor partition scanned is also known as Root Region.

Concurrent Marking(Concurrent token)

This phase starts with GC Root to mark objects in the heap, the tag thread executes in parallel with the application thread, and collects information on live objects for each Region. -xx :ConcGCThreads(1/4 of the default number of GC threads, i.e. -xx :ParallelGCThreads/4) controls the number of threads to be started. Each thread scans only one partition Region at a time. Thus marking the graph of living objects.

All tagging tasks must be scanned before they fill up, and if concurrent tagging takes a long time, it is possible that several collections of young generations will occur during the concurrent tagging process. If the marking task is not completed before it fills up, the guarantee mechanism is triggered and a long serial Full GC goes through.

Remark(Relabel, STW)

Mark objects that change during the concurrent mark phase and are reclaimed. This phase is also executed in parallel, with the parameter -xx :ParallelGCThread setting the number of GC threads available for GC pauses.

Cleanup(Cleanup, STW)

Perform the following operations during the clearing phase:

  • RSetCarding, heuristic algorithm will be based on activity andRSetDimensions define different grades of partitions, whileRSetMath and mathematics can also help spot useless quotes. parameter-XX:+PrintAdaptiveSizePolicyCan turn on printing heuristic algorithm decision details;
  • Collating heap partitions to identify old age partition sets with high recovery returns (based on free space and pause goals) for mixed collection cycles;
  • Identify all free partitions, that is, partitions that find no living objects. This partition can be reclaimed during the cleanup phase without waiting for the next collection cycle.

Young Collection/Mixed Collection Cycle Mixed Collection Cycle

When the application starts running, the heap memory available space is still relatively large, and only when the young generation is full, the young generation collection is triggered.

Memory as the old s growth, when arrived at IHOP threshold – XX: InitiatingHeapOccupancyPercent (accounted for a whole heap of old s ratio, 45%) by default, the G1 began preparing to collect old s space.

The Concurrent Marking Cycle is first experienced to identify high-yield old age partitions, as described above.

But instead of immediately starting a mixed collection, G1 lets the app run for a while, waiting for a young collection to trigger.

In this STW, G1 will keep the collation mixed collection cycle on track. Then let the application thread run again, and when the next few collections of young generations are made, older partitions will be added to the CSet,

Mixed collections are triggered, and these Mixed collections are called Mixed Collection cycles.

The Young generation collects Young collections,YGC

During each collection, there are both parallel and serial activities, but both can be multithreaded.

In parallel tasks, if a task is too heavy, other threads will wait for the processing of a task, which needs to be optimized.

The following parts can be viewed in combination with logs

  • Parallel activities

    • External Root partition Scanning Ext Root Scanning: This activity scans the off-heap roots (JVM system directories, VM data structures, JNI thread handles, hardware registers, global variables, thread-to-stack roots) to find objects that have not been added to the paused collection CSet. If the system directory (single root) has a large number of loaded classes, it may end up waiting time for that activity to continue after other parallel activities have finished.

    • Update RS: The concurrent optimization thread scans the partition of dirty cards to Update the log buffer to Update the RSet, but only the global buffer list is processed. As a supplement, any remaining Buffers that have been logged but have not yet been Processed by the optimized thread are Processed at this stage and become Processed Buffers. In order to limit time spent on the update of RSet, can set the suspend occupancy percentage – XX: G1RSetUpdatingPauseTimePercent (default 10%, namely – XX: MaxGCPauseMills / 10). It is important to note that if the task of updating the log buffer update is not reduced, simply reducing the RSet update time will result in fewer buffers being processed during pauses, pushing the log buffer update work onto the concurrent optimization thread, thereby increasing contention for Java application thread resources.

    • RSet Scan Scan RS: Before collecting the current CSet, the RSet of the CSet partition must be scanned in consideration of out-of-partition references. If the RSet is coarsened, the scanning time of the RSet is increased. After open diagnostic mode – XX: UnlockDiagnosticVMOptions, through parameter – XX: + G1SummarizeRSetStats concurrent optimization of thread can be determined whether can handle in time to update the log buffer, and provide more information, to help provide the total number of RSet coarsening window. Parameters – XX: G1SummarizeRSetStatsPeriod = n can be set up RSet statistical period, that is, how much experience after the GC to make a statistics

    • Code Root Scanning: The Code Root set is scanned, and reference information (Nmethod Scanning) of the Code Native Method after JVM compilation is scanned for RSet Scanning. In fact, an NMethod scan is only done for references to csets if the RSet in the CSet partition has a strong code root.

    • Object Copy: With the selected CSet and the complete reference set of the CSet partition, the main parts of the pause time are performed: the transfer of CSet partition surviving objects and the reclamation of CSet partition space. The thread of the copy object is load balanced through the work stealing mechanism, and the live object of the copy and scan object being moved is copied to each GC thread allocation buffer GCLAB. G1 adjusts the size of the young generation by calculating how long partition replication will take.

    • Termination: If the task queue is empty after completing the Termination task, the worker thread will issue a Termination request. If another thread continues to work, the idle thread tries to help the other thread through the work theft mechanism. A thread that performs a root partition scan alone will eventually terminate later if the task is too heavy.

    • GC Worker Other: This part is not the GC activity, but the JVM activity that is taking up GC pause time (for example, JNI compilation).

  • Serial activities

    • Root Fixup: Updates the Code Root based on the transfer object.

    • Purge Code Root Purge: Purge the Root collection table.

    • Clear CT: PRTS that are scanned in CSet and RSet records in any collection cycle will be marked in the global card table to prevent repeated scanning. The scanned flags in the global card table are cleared at the end of the collection cycle.

    • Choose CSet for next collection: This part is mainly used for young generation collection and mixed collection after concurrent marking cycle. In these collection processes, due to the addition of candidate partitions of the old age, it is often necessary to define the scope of the next collection. But in a pure young collection, all collected partitions will be collected and there is no choice.

    • Ref Proc: Soft, weak, virtual, final, and JNI references. When the Ref Proc takes up too much time, can choose to use parameters – XX: ParallelRefProcEnabled activation multithreaded processing. G1 wants applications to be careful with soft references because they occupy memory until Full GC collects them when they run out of space. Even if Full GC does not occur, the memory footprint of soft references can lead to an increase in GC counts.

    • Reference queued Ref Enq: This activity may result in an update to the RSet, in which the associated cards are marked as dirty by logging.

    • Redirty Cards: Redirty Cards.

    • Reclaim idle giant partition Humongous Reclaim: G1 made an optimization: by checking the RSet of all root objects and young generation partitions, if it is confirmed that there is no reference to the giant object in the RSet, it means that G1 found an unreachable giant object and the object partition will be reclaimed.

    • Free CSet: Reclaims all space in the CSet partition and adds it to the Free partition.

    • Other: Other activities, such as fixing JNI handles, may also be experienced in the GC.

Young Collection Following Concurrent Marking Cycle

Mixed collection does not begin immediately after G1 initiates the concurrent marking cycle. G1 will wait for the next young generation collection, and then determine the CSet(Choose CSet) for the next mixed collection during this collection phase.

Mixed Collection Cycle,Mixed GC

A single mixed collection is no different from a young collection.

Depending on the pause goal, older partitions may not be processed in a single pause Collection, and G1 initiates multiple consecutive Mixed collections, known as Mixed Collection cycles.

G1 calculates the number of partitions added to the CSet each time and the number of mixed collections. In the last young generation collection and the next mixed collection, G1 determines which partition set to add to the CSet next time and whether to end the mixed collection cycle.

Transfer failed guarantee mechanismFull GC

Evacuation Failure is when G1 is unable to apply for a new partition in the heap space, triggering a guarantee mechanism to perform a STW-style, single-threaded (MULTIthreaded) Full GC.

The Full GC will mark the heap clean and compress it, and will end up containing only pure live objects. The parameter -xx :G1ReservePercent(default 10%) can reserve space for exceptions in promotion mode, occupying up to 50% of the heap, or more.

G1 fires Full GC and logs to-space Exhausted and Evacuation Failure in the following scenarios:

  • A free partition could not be found while copying a live object from a young partition
  • A free partition could not be found while moving a live object from an older partition
  • Allocating giant ObjectsHumongous ObjectCould not find enough contiguous partitions in the old days

Because G1 applications tend to have large heap memory, Full GC is expensive to collect and should be avoided.

The problem

  • When is concurrent marking triggered?
#The percentage of heap memory occupied when the Concurrent Marking Cycle (and the subsequent MixedGC Cycle) is started. G1 uses it to trigger concurrent GC cycles based on the utilization of the entire heap, not just the percentage of memory used in a particular generation. The default 45%
#When the heap alive occupies 45% of the heap, the Concurrent Marking Cycle in G1 starts
-XX:InitiatingHeapOccupancyPercent
Copy the code

  • When does Mixed GC occur? Concurrent marking is primarily intended to provide marking services for Mixed GC and is not a required part of a GC process.

    Controlled by a number of parameters, it also controls which older regions are selected into the CSet.

#Maximum number of Mixed GC executions after a concurrent marking (default: 8)
-XX:G1MixedGCCountTarget
#Garbage percentage (default 5%). After each YGC and before the Mixed GC occurs again, it will check whether the garbage percentage reaches this parameter. Only when the Mixed GC reaches this parameter, will the Mixed GC occur next time.
-XX:G1HeapWastePercent
#The proportion of live objects in the old Generation region is selected into the CSet only after this parameter is specified.
-XX:G1MixedGCLiveThresholdPercent
#The maximum number of Old Generation regions that can be selected into a CSet in a Mixed GC.
-XX:G1OldCSetRegionThresholdPercent
Copy the code

GC log details

Concurrent Marking Cycle Concurrent Marking Cycle
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0094252 secs]
#Root partition scan, which may be interrupted by YGC, is terminated as follows: [GC Pause (G1 Evacuation pause) (young)[GC concurrent-root-region-scan-end, 0.00157 secs]
[GC concurrent-mark-start]
[GC concurrent-mark-end, 0.0203881 secs]
#Concurrent marking phase2. [GC remark [Finalize Marking, 0.0007822 secs] [GC ref-proc, 0.0002279secs]#Relabel, STW[Times: user=0.01 sys=0.00, real=0.00 secs] [GC cleanup 13985K->13985K, 0.0034675 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] User sys = = 0.00 0.00, real = 0.00 secs]#remove
Copy the code
The younger generation collects YGC
[GC pause (G1 Evacuation Pause) (young), 0.0022483 secs]
#Young -> Young generation Evacuation-> Replicate living objects[Parallel Time: 1.0ms, GC Workers: 10] [GC Worker Start (ms): Min: 109.0, Avg: 109.1, Max: 109.1, Diff: 0.2] [Ext Root Scanning (MS): Min: 0.1, Avg: 0.2, Max: 0.3, Diff: 0.2, Sum: Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: [Processed Buffers: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0] [Scan RS (ms): Min: 0.0, Avg: 0.0, Diff: 0.0, Sum: 0.0]# Root Scanning (ms): Min: 0.0, Avg: 0.0, Sum: 0.0]# Root Scanning (MS): Min: 0.0, Avg: 0.0, Sum: 0.0]# Root Scanning (MS): Min: 0.0, Avg: 0.0, Sum: 0.0]# Root Scanning (MS): Min: 0.0, Avg: 0.0, Sum: 0.0 0.0, Diff: 0.0, Sum: 0.1] # Object Copy (ms): Min: 0.3, Avg: 0.3, Max: 0.4, Diff: 0.1, Sum: 0.1 [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: Termination (ms): Min: 0.0, Avg: 0.0, Diff: 0.0, Sum: If the task queue is empty, the worker thread will issue a termination request. [Termination Attempts: Min: 1, Avg: 5.8, Max: 9, Diff: 8, Sum: 58] [GC Worker Other (MS): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1] # Parallel activity outside the GC, which is not GC activity, but JVM activity that causes the GC pause time to be occupied (for example, JNI compilation). [GC Worker Total (ms): Min: 0.5, Avg: 0.6, Max: 0.7, Diff: 0.2, Sum: 5.9] [GC Worker End (ms): Min: 109.7, Avg: 109.7, Max: 109.7, Diff: 0.0] [Root Fixup: 0.0 ms] [Clear CT: 0.5ms] # Select CSet, select CSet, select CSet, select CSet, select CSet CSet [Ref Proc: 0.4ms] [Ref Proc: 0.4ms] Ref Enq [Redirty Cards: 0.3ms] [Humongous Register] [Humongous Register] 0.0ms] [Humongous Reclaim: 0.0ms] # Reclaim the idle giant partition. After checking the RSet of all the root objects and the young partition, if it is confirmed that there is no reference to the giant object in the RSet, the object partition will be reclaimed. [Free CSet: 0.08K] # Free CSet [Eden: 12288.0K(12288.0K)-> 0.0b (11264.0K) Survivors: 0.0b ->1024.0K Heap: [Times: user= 0.03sys =0.00, real=0.00 secs] [Times: user= 0.03sys =0.00, real=0.00 secs]Copy the code
#A free partition could not be found while copying a live object from a young partition
#YGC is caused by one of two situations in which no free partition can be found when a live object is transferred from an older partition
[GC pause (G1 Evacuation Pause) (young) (to-space exhausted), 0.0916534 secs]
Copy the code
#Concurrent Marking Cycle The root partition scanning phase in the Concurrent Marking Cycle is interrupted by YGC[GC Pause (G1 Evacuation Pause) (young)[GC Concurrent-root-region-scan-end, 0.00157 SECS]Copy the code
Mixed Collection Cycle, Mixed GC
#Start of Concurrent Marking Cycle Concurrent Marking Cycle[GC Pause (G1 Evacuation Pause) (Young) (Initial-Mark), 0.0443460 secS]Copy the code
Full GC
[Full GC (Allocation Failure) 20480K->9656K(20480K), 0.0189481 secs]
   [Eden: 0.0B(1024.0K)->0.0B(5120.0K) Survivors: 0.0B->0.0B Heap: 20480.0K(20480.0K)->9656.8K(20480.0K)], [Metaspace: 4960K->4954K(1056768K)]
 [Times: user=0.03 sys=0.00, real=0.02 secs] 
Copy the code

The resources

  • www.oracle.com/technical-r…
  • JDK8 G1: docs.oracle.com/javase/8/do…
  • Other Blog:
    • www.infoq.com/articles/G1…
    • Tech.meituan.com/2016/09/23/…
    • www.infoq.com/articles/tu…
    • Blog.csdn.net/coderlius/a…
    • www.cnblogs.com/webor2006/p…
    • www.cnblogs.com/webor2006/p…
    • [1] Charlie H, Monica B, Poonam P, Bengt R. Java Performance Companion
    • [2] Zhou Zhiming. In-depth understanding of the JVM virtual machine

by Sven Augustus my.oschina.net/langxSpirit

This article is published by OpenWrite, a blogging tool platform