G1 gabage collector notes

Traditional: Eden Survivor 0 Survior 1   Old generation
G1:   Various size regions   (Free/Occupied)
Each region:  young(Eden or survivor)/old/humongous

Humongous object:
Object < 50% region size (normal allocation into eden)
Object >= 50% region size (humongous object, allocation into old generation directly)
Object > region size (allocation into contiguous regions into old generation, humongous region)

Collection set (candidate regions for GC)
Young collection set -> all young regions
Mix collection set -> all youn regions + a few candidate old regions based on "most garbage first" principle
Incremental compaction in G1 VS monolithic stop world for normal full GC

Remembered set:
tracking incoming reference
5% memory footprint overhead
tracking old-to-young references +  old-to-old references
more popular objects in remember set, it gets denser -> performance issue
Each old region has associated remember set, no need for young regions

Phases:
Young collection (stop the world)
Initial mark (stop the world)  triggered when initiating heap occupancy percent is reached
  -XX:InitiatingHeapOccupancyPercent (default 45%)
  -XX:ConcGCThreads=<n>

Root object scanning

Concurrent marking can be interrupted by young collection

Remark (stop the world)
Cleanup (stop the world)
Mixed collection

1.8.40  ClassUnloadingWithConcurrentMark  enabled by default
before 1.8.40 humongous objects are only collected during cleanup phase,  
after 1.8.40 humongous objects can be collected in young collection

Tuning options:
Mixed GC happens too frequently
Mixed GC pause too long  -> divide expensive collection further into smaller inexpensive collections

Strategy:
min number of old regions to include in the mixed collection set (-XX:G1MixedGcCountTarget=<n>)
max number of old regions to include in the mixed collection set (-XX:G1OldCSetRegionThresholdPercent=<p>)

Remove the expensive regions from mixed collection set
eliminate based on the liveness per old region    -XX:G1MixedGCLiveThresholdPercent = <p>  (default 85%)
eliminate expensive old regions towards the end of sorted array   -XX:G1HeapWastePercent = <p>  (default 5%)

Major contributor to GC pause:
ideally: copying live objects

others:

update remember set (problemetic)
other time (reference processing etc)

lots of long-lived humongous objects can cause evacuation failure
each humongous region can have 1 humongous object (wasted space)
promotion/evacuation failure can cause by fragmentation -> full GC

Prevent evacuation failure:

  • increase heap size
  • lower InitiatingHeapOccupancyPercent
  • increase marking threads
  • increase G1ReservePercent (make sure enough to space)

Always watch allocation rate/promotion rate and be aware of allocation spikes

https://www.youtube.com/watch?v=Io8hEdm6haw&list=PLy7t4z5SYNaRN2IDmjq_SSCrb9Sph4zAC&index=29

时间: 2024-11-07 15:09:49

G1 gabage collector notes的相关文章

G1 Garbage Collector and Shenandoah

http://www.diva-portal.se/smash/get/diva2:754515/FULLTEXT01.pdf https://is.muni.cz/th/ifz8g/GarbageCollection.pdf?so=nx https://www.researchgate.net/publication/306112816_Shenandoah_An_open-source_concurrent_compacting_garbage_collector_for_OpenJDK h

The The Garbage-First (G1) collector since Oracle JDK 7 update 4 and later releases

Refer to http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html for detail. 一些内容复制到这儿 The G1 Garbage Collector The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large memories

The Garbage-First (G1) collector

The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with a high probability, while achieving high throughput. The G1 garbag

G1 collector 介绍

背景:由于CMS算法产生空间碎片和其它一系列的问题缺陷,HotSpot提供了另外一种垃圾回收策略,G1(也就是Garbage First)算法,该算法在JDK7u4版本被正式推出,官网对此描述如下: The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage coll

Java Hotspot G1 GC的一些关键技术

G1 GC,全称Garbage-First Garbage Collector,通过-XX:+UseG1GC参数来启用,作为体验版随着JDK 6u14版本面世,在JDK 7u4版本发行时被正式推出,相信熟悉JVM的同学们都不会对它感到陌生.在JDK 9中,G1被提议设置为默认垃圾收集器(JEP 248).在官网中,是这样描述G1的: The Garbage-First (G1) collector is a server-style garbage collector, targeted for

转 G1垃圾收集器入门

转自:http://blog.csdn.net/zhanggang807/article/details/45956325 最近在复习Java GC,因为G1比较新,JDK1.7才正式引入,比较艰难的找到一篇写的很棒的文章,粘过来mark下.总结这篇文章和其他的资料,G1可以基本稳定在0.5s到1s左右的延迟,但是并不能保证更低的比如毫秒级(金融场景,所以说涉及到钱的,对技术要求真高),号称zing可以(但是一般做到低延时,在其他方面肯定有所损耗,比如吞吐),但是没有实际去研究过这种.另外,G1

JVM中的G1垃圾回收器

我们先回顾一下主流Java的垃圾回收器(HotSpot JVM).本文是针对堆的垃圾回收展开讨论的. 堆被分解为较小的三个部分.具体分为:新生代.老年代.持久代. 绝大部分新生成的对象都放在Eden区,当Eden区将满,JVM会因申请不到内存,而触发Young GC ,进行Eden区+有对象的Survivor区(设为S0区)垃圾回收,把存活的对象用复制算法拷贝到一个空的Survivor(S1)中,此时Eden区被清空,另外一个Survivor S0也为空.下次触发Young GC回收Eden+S

Java7与G1

Lucene 4.8开始不支持java6了,所以在下次版本升级之前我们要先升级至java7. 我使用1/3的全量索引(7.3G),进行测试,20并发,40万请求: sun jdk 1.6.0_26 平均响应时间为9.08ms sun java 7 update 55 平均响应时间为8.29ms 传说中的g1 garbage collector那么高大上,使用G1之后平均响应时间为8.35ms. 之前测的时候使用15G的xmx,g1响应时间接近cms,今天发现如果堆低于15G,g1性能将下降得很厉

G1 垃圾收集器入门

G1 垃圾收集器入门 概览 目的 这个教程覆盖了如何使用G1垃圾收集器和它是怎样被Hotspot JVM使用的,你会学到G1收集器内部是如何工作的,使用G1时的一些关键命令行开关和记录它的操作的一些选项. 完成耗时 大约1小时 介绍 这个OBE(Oracle By Example)覆盖了Java里的Java虚拟机G1垃圾回收的基本概念,在OBE的第一部分, 在介绍垃圾收集器和性能时会附带提供JVM的概览.下一部分回顾一下Hotspot JVM的CMS收集器如何工作.然后,一步一步来指导使用Hot