[In-depth understanding of JVM] 10, CMS+G1+MixedGC+card table+ missing labels and avoiding missing labels [draft]

 

G1

1. ▪https://www.oracle.com/technical-resources/articles/java/g1gc.html

G1 log details

[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0015790 secs]
//young -> 年轻代 Evacuation-> 复制存活对象 
//initial-mark 混合回收的阶段，这里是YGC混合老年代回收
   [Parallel Time: 1.5 ms, GC Workers: 1] //一个GC线程
      [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.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.0 ms]
   [Other: 0.1 ms]
      [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.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)]
 [Times: user=0.00 sys=0.00, real=0.00 secs] 
//以下是混合回收其他阶段
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0000078 secs]
[GC concurrent-mark-start]
//无法evacuation，进行FGC
[Full GC (Allocation Failure)  18M->18M(20M), 0.0719656 secs]
   [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B 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]

 Throughput is reduced by 10%-15%, but its response time can reach 200ms or less.

 

 Stratification and divide and conquer.

Humongous: Enlarge the object area.

old：

Survivor：

Eden：

 

G1 features:

• Concurrent collection
• Compressing free space does not extend the pause time of GC
• More predictable GC pause time
• Use scenarios that do not require high throughput in advance and require high response time.

basic concept:

card table : Card Table Since YGC needs to scan the entire Old area, the efficiency is very low, so JVM designed CardTable. If an object in an OLD area CardTable points to the Y area, set it to Dirty . The next time you scan, Only need to scan Dirty Card. In terms of structure, Card Table is implemented by BitMap

When judging whether the new generation object is alive (the reference has reached the old generation): Is it necessary to traverse the old generation (this is too efficient)?

BitMap table

CardTbale

JVM GC can be divided into MinorGC, MajorGC and FullGC . For Mirnor GC, its time-consuming is mainly determined by two factors:

1. Time to copy active objects
2. Time to scan the card table (the old generation object refers to the new generation object)

The Java virtual machine uses a data structure called CardTable (card table) to mark whether an object in a certain memory area in the old generation holds a reference to a new generation object. The number of card tables depends on the size of the old generation and each card. Corresponding to the memory size, each card corresponds to a bit in the card table. When an object in the old generation holds a reference to the new generation object, the JVM marks the location of the card corresponding to this object as dirty ( The bit bit is set to 1), so that it is not necessary to scan the entire old generation during Minor GC, but to scan the memory area corresponding to Card Dirty.

 

Collection Set : Those marked cards are counted as Collection Set.

RSet=RememeberedSet：

• Record the references of objects in other regions to this region.
• The cut-off of Rset is that the garbage collector does not need to scan the entire heap to find who has referenced the objects in the current partition, just scan the RSet.

New to old ratio: dynamic

• 5%-60%
• Generally do not need to be specified manually
• Don't specify it manually either, because this is the benchmark for G1 to predict the pause time.
• Throughput is reduced by 10%-15%, but its response time can reach 200ms.

When is GC triggered (note that G1 will still be FGC, when allocating objects is particularly fast)

• YGC
  • Not enough space in Eden
  • Multi-threaded parallel execution
• FGC
  • Insufficient space in Old
  • System.gc（）

MixedGC in G1

• Equivalent to a CMS
• XX：InitiatingHeapOccupacyPercent
  • The default value is more than 45% (can be specified, occupying heap memory space)
  • When O exceeds this value, start MixedGC

The process of MixedGC

• Initial mark STW
• Concurrent mark
• Final mark STW (re-mark)
• Screening and recycling STW (parallel)

Three-color mark:

• White: unmarked objects
• Gray: self is marked, member variables are not marked
• Black: Both self and member variables (referenced objects) have been marked as complete

Missing criteria: (both are met) Breaking one is destroying

• In the remarking process, black points to white. If the black is not rescanned, the label will be missed, and the white D object will be treated as if there is no new reference to it, and it will be recycled.
• In the process of concurrent marking, Mutator deletes all references from gray to white, which will result in missed labels, and the white exclusive should be recycled at this time.

Just break one of the above two conditions:

• incremental update --Incremental update, pay attention to the increase of references, re-mark black to gray, and rescan attributes next time ( used by CMS )
• SATB snapshot at the beginning-Focus on the deletion of references. When B-->D disappears, push this reference to the GC stack to ensure that D can still be scanned by GC. ( Used by G1 )

Why does G1 use SATB?

• If the first type is used, the black references will be scanned again, which is very inefficient
• Gray--"When the white reference disappears, if there is no black pointing to the white reference, it will be pushed to the stack (when I scan the thread next time, I will scan the stack which has changed, and only scan the reference to which white object), I get this application in the next scan. Due to the existence of RememeberedSet, there is no need to scan the entire heap to find white references. The efficiency is relatively high. SATB cooperates with RSet, which is natural. (Note that incremental update cannot cooperate with RSet, otherwise you still have to traverse it again) There is a difference between write barriers in GC and memory write barriers

RSet and the efficiency of assignment

• Due to the existence of RSet, every time you assign a reference to an object, you have to do some extra operations
• Refers to doing some extra records in RSet (called write barrier in GC)
• This write barrier is not equal to a memory barrier
• No Silver Bullet

 

Color pointer: (64 bit)

 

 

 

 

 

 

 

operation

1. -XX: What does MaxTenuringThreshold control? A: The age at which the subject entered the old age B: The percentage of memory garbage when FGC was triggered in the old age

2. In the production environment, I tend to set the maximum heap memory and the minimum heap memory as: (Why?) A: Same B: Different

3. The default garbage collector of JDK1.8 is: A: ParNew + CMS B: G1 C: PS + ParallelOld D: none of the above

4. What is response time priority?

5. What is throughput priority?

6. What is the difference between ParNew and PS?

7. What is the difference between ParNew and ParallelOld? (Different ages, different algorithms)

8. For long-term computing scenarios, you should choose: A: pause time B: throughput

9. Large-scale e-commerce websites should choose: A: pause time B: throughput

10. What are the most commonly used HotSpot garbage collectors?

11. What are the common HotSpot garbage collector combinations?

12. What is the default garbage collector of JDK1.7 1.8 1.9? How to check?

13. So-called tuning, what exactly is tuning?

14. If the PS + ParrallelOld combination is used, what can be done to make the system basically not produce FGC

15. If the ParNew + CMS combination is used, what can be done to make the system basically not produce FGC

    1. Increase JVM memory

    2. Increase the proportion of Young

    3. Raise the age of YO

    4. Increase the proportion of S area

    5. Avoid code memory leaks

16. Is G1 generational? Will the G1 garbage collector generate FGC?

17. If G1 produces FGC, what should you do?

    1. Expand memory
    2. Improve CPU performance (faster collection, fixed speed of business logic generating objects, faster garbage collection, larger memory space)
    3. Lower the threshold of MixedGC trigger to make MixedGC happen earlier (default is 45%)

18. Q: Can I dump casually in the production environment? Small heaps have little impact, large heaps will have service pauses or freezes (adding live can alleviate them), and there will be FGC before dump

19. Q: What are the common OOM problems? Stack heap MethodArea direct memory

GC commonly used parameters

• -Xmn -Xms -Xmx -Xss young generation minimum heap maximum stack space
• -XX:+UseTLAB use TLAB, open by default
• -XX:+PrintTLAB Print the usage of TLAB
• -XX:TLABSize set TLAB size
• -XX:+DisableExplictGC System.gc() does not work, FGC
• -XX:+PrintGC
• -XX:+PrintGCDetails
• -XX:+PrintHeapAtGC
• -XX:+PrintGCTimeStamps
• -XX:+PrintGCApplicationConcurrentTime (low) print application time
• -XX:+PrintGCApplicationStoppedTime (low) print pause time
• -XX:+PrintReferenceGC (low importance) records how many references of different reference types have been recovered
• -verbose:class class loading detailed process
• -XX:+PrintVMOptions
• -XX:+PrintFlagsFinal -XX:+PrintFlagsInitial must be used
• -Xloggc:opt/log/gc.log
• -XX:MaxTenuringThreshold upgrade age, the maximum value is 15
• Number of lock spins-XX:PreBlockSpin hot code detection parameter-XX:CompileThreshold escape analysis scalar replacement...These are not recommended to be set

Parallel common parameters

• -XX:SurvivorRatio
• -XX: PreTenureSizeThreshold How big is the large object?
• -XX:MaxTenuringThreshold
• -XX:+ParallelGCThreads Parallel collector thread number, also applicable to CMS, generally set to be the same as the number of CPU cores
• -XX:+UseAdaptiveSizePolicy automatically selects the size ratio of each area

CMS common parameters

• -XX:+UseConcMarkSweepGC
• -XX: ParallelCMSThreads CMS thread number
• -XX:CMSInitiatingOccupancyFraction What percentage of the old generation to use before starting CMS collection, the default is 68% (approximate value), if SerialOld lag occurs frequently, it should be reduced (frequent CMS recovery)
• -XX:+UseCMSCompactAtFullCollection to compress at FGC
• -XX:CMSFullGCsBeforeCompaction How many times does FGC perform compression
• -XX:+CMSClassUnloadingEnabled
• -XX: CMSInitiatingPermOccupancyFraction Perm recovery when reaching what proportion
• GCTimeRatio Set the percentage of GC time that occupies the running time of the program
• -XX:MaxGCPauseMillis pause time is a suggested time. GC will try to achieve this time by various means, such as reducing the young generation

G1 common parameters

• -XX:+UseG1GC
• -XX:MaxGCPauseMillis recommended value, G1 will try to adjust the number of blocks in the Young area to reach this value
• -XX:GCPauseIntervalMillisGC's pause interval target
• -XX:+G1HeapRegionSize partition size, it is recommended to increase the value gradually, 1 2 4 8 16 32. As the size increases, the garbage survival time is longer and the GC interval is longer, but the time of each GC will be longer. ZGC has made improvements (dynamic block size)
• G1NewSizePercent The minimum proportion of the new generation, the default is 5%
• G1MaxNewSizePercent The maximum proportion of the new generation, the default is 60%
• GCTimeRatio GC time recommended ratio, G1 will adjust the heap space according to this value
• ConcGCThreads number of threads
• InitiatingHeapOccupancyPercent Start G1 heap space occupation ratio