This is the third day of my participation in the August More text Challenge. For details, see: August More Text Challenge
CMS
- Initial tag: STW finds the root object, takes a short time
- Concurrency flag: The application thread and GC thread execute concurrently, and it takes a long time to find other objects referenced by the root object. During this process, a previously unavailable object becomes available again.
- Re-marking: STW finds the object whose state changes during the concurrent marking process and re-marks it, which takes a short time
- Concurrent cleanup: The application thread and GC thread execute concurrently to clean up garbage objects. In the process, new garbage (floating garbage) will be generated for the next GC cleanup.
G1
Reference article: G1GC
- Garbage First
- G1 is a garbage collector for server-side applications aimed at multi-core, large-memory machines that can achieve the specified GC pause times in most cases while still maintaining high throughput.
G1: Divide and conquer (logical generation, physical generation)
The characteristics of
- Concurrent collection
- Compressing idle time does not extend GC pause times
- More predictable GC pause times
- Suitable for scenarios where high throughput is not required
The memory area of G1 is not fixed with E or O
Basic concepts of GC algorithm
- Card Table
During YGC, the entire old area needs to be scanned to determine whether an object is referenced, which is very inefficient. If there is an object in the Card Table of the old area that points to the Y area, set it to dirty. In the next scan, only dirty cards need to be scanned. Structurally, Card Table is implemented using BitMap.
-
CSet = Collection Set
- A collection of partitions that can be reclaimed
- Data that lives in a CSet is moved to another availability zone during GC. Partitions in a CSet can be Eden, Survivor, or old. Csets take up less than 1% of the total heap space.
-
RSet = Remembered Set
- It records the references from objects in other regions to the Region
- The value of rsets is that the garbage collector doesn’t have to scan the entire heap to find out who referenced the object in the current partition. Instead, the garbage collector scans the RSet.
- Efficiency of RSet and assignment
- Because of rsets, every time you assign a reference to an object, you have to do something extra
- This refers to making some extra recording in the RSet (called a write barrier in GC)
- This write barrier is not equal to the memory barrier
-
Ali’s multi-tenant JVM
- Each tenant has a single space
- session based GC
-
The size of each Region
-
5 percent to 60 percent
- It is not required to specify manually
- Because this is the benchmark G1 uses to predict the STW pause time
-
Humongous Object
The number of objects exceeds 50% of a single region or spans multiple regions
In the G1 MixedGC
– XX: InitiatingHeapOccupancyPercent old s footprint to achieve the whole heap memory threshold
- The default value of 45%
- When the old object exceeds this value, MixedGC is started
MixedGC process
- The initial tag is STW
- Concurrent tags
- Finally mark STW (re-mark)
- Filter reclaim STW (parallel)
Three-color labeling
Concurrent marking algorithm, used in G1 and CMS
- White: Unmarked objects
- Gray: self is marked, member variables are not marked
- Black: both self and member variables have been marked
Missing label: B->D disconnect, A->D
To produce a leaky mark, two conditions should be met:
- A black – to – white reference is added as the markup progresses, and if the black is not reprocessed, the markup will be missed
- If the gray object’s reference to the white object is deleted, the white object may be missed
There are two ways to solve the missing mark:
Incremental update [CMS]
Incremental Update — Focus on the addition of references
Re-mark black to gray and rescan the properties next time
SATB “G1”
SATB 【 Snapshot at the Beginning 】 — Focus on deletion of references
When B->D disappears, the reference is pushed onto the GC stack to ensure that D is still scanned by GC
Why does G1 use SATB?
When the grey -> white reference disappears, if there is no black pointing to white, the reference will be pushed to the stack, and the next scan will get the reference. Due to the presence of RSet, there is no need to scan the whole heap to find the reference pointing to white, which is more efficient.
SATB with RSet
CMS Log Analysis
Run the following command: Java -xms20m -xmx20m -xx :+PrintGCDetails -xx :+UseConcMarkSweepGC com.mashibing.jvm.gc.t15_fullgc_problem01
[GC (Allocation Failure) [ParNew: 6144K->640K(6144K), 0.0265885 secs] 6585K->2770K(19840K), 0.0268035 secs] [Times: User sys = = 0.02 0.00, real = 0.02 secs]
ParNew: young generation collector
6144->640: comparison before and after collection
(6144) : the entire young generation capacity
6585 -> 2770: the condition of the entire heap
(19840) : total heap size
[GC (CMS Initial Mark) [1 CMS-initial-mark: 8511K(13696K)] 9866K(19840K), 0.0040321 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
//8511 (13696) : Old age use (maximum)
//9866 (19840) : entire heap usage (Max)
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.018/0.018 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
// The time is not significant here, because the execution is concurrent
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
// Marking Card as Dirty. Also called Card Marking
[GC (CMS Final Remark) [YG occupancy: 1597 K (6144 K)][Rescan (parallel) , 0.0008396 secs][weak refs processing, 0.0000138 secs][class unloading, 0.0005404 secs] [scrub symbol table, 0.0006169 secs] [scrub string table, 0.0004903 secs[1]CMS-remark: 8511K(13696K10108)]K(19840K), 0.0039567 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
//STW phase, YG Occupancy: Young occupancy and capacity
//[Rescan (PARALLEL) : live object tag under STW
// Weak refs processing
Class semantics: class that is not required for unloading
//scrub symbol(string) table:
//cleaning up symbol and string tables which hold class-level metadata and
//internalized string respectively
// cms-remark: 8511K(13696K)
//10108K(19840K): heap occupancy and capacity after phase
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.005/0.005 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
// The tag has been completed, and concurrent cleanup is underway
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
// Reset the internal structure for the next GC
Copy the code
Description of G1 logs
[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0015790 secs]
// Young -> Young generation Evacuation-> Replicate surviving objects
//initial-mark indicates the phase of the mixed collection. This is the YGC mixed old age collection[Parallel Time: 1.5ms, GC Workers: 1]// A GC thread
[GC Worker Start (ms): 92635.7]
[Ext Root Scanning (ms): 1.1]
[Update RS (ms): 0.0]
[Processed Buffers: 1]
[Scan RS (ms): 0.0]
[Code Root Scanning (ms): 0.0]
[Object Copy (ms): 0.1]
[Termination (ms): 0.0]
[Termination Attempts: 1]
[GC Worker Other (ms): 0.0]
[GC Worker Total (ms): 1.2]
[GC Worker End (ms): 92636.9] [Code Root Fixup: 0.0ms] [Code Root Purge: 0.0ms] [Clear CT: 0.0ms] [Other: 0.1ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.0 ms] [Ref Enq: 0.0 ms] [Redirty Cards: 0.0 ms] [Humongous Register: 0.0 ms] [Humongous Reclaim: 0.0 ms] [Free CSet: 0.0 ms] [Eden: 0.0B(1024.0K)- > 0.0B(1024.0K)Survivors: 0.0 - > 0.0 B B Heap: 18.8M(20.0M)- > 18.8M(20.0M)]
[Times: user=0.00 sys=0.00, real=0.00 secs]
// The following are the other stages of mixed recycling
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0000078 secs]
[GC concurrent-mark-start]
// Unable to perform FGC for evacuation
[Full GC (Allocation Failure) 18M->18M(20M), 0.0719656 secs]
[Eden: 0.0B(1024.0K)- > 0.0B(1024.0K)Survivors: 0.0 - > 0.0 B B Heap: 18.8M(20.0M)- > 18.8M(20.0M)], [Metaspace: 38
76K->3876K(1056768K)] [Times: user=0.07 sys=0.00, real=0.07 secs]
Copy the code