IBM JDK 의 Concurrent Generational Collector

Concurrent Generational Collector

Concurrent Generational Collector는 gcpolicy(-Xgcpolicy:gencon) 옵션에 의해 활성화된다.
IBM JDK 1.5에서 새롭게 추가되었으며
Sun Hotspot JVM의 CMS Collector와 매우 유사한 기법을 사용한다.

Concurrent Generational Collector에 의한 GC Dump에는 다음과 같은 로그가 기록된다.

...
<af type="nursery" id="91" timestamp="Tue Oct 23 00:34:50 2007" intervalms="27.674">
  <minimum requested_bytes="32" />
  <time exclusiveaccessms="0.053" />
  <nursery freebytes="0" totalbytes="38255104" percent="0" />
  <tenured freebytes="92785912" totalbytes="372438528" percent="24" >
    <soa freebytes="92785912" totalbytes="372438528" percent="24" />
    <loa freebytes="0" totalbytes="0" percent="0" />
  </tenured>
  <gc type="scavenger" id="91" totalid="101" intervalms="27.755">
    <flipped objectcount="161001" bytes="9015948" />
    <tenured objectcount="300702" bytes="16428048" />
    <refs_cleared soft="0" weak="0" phantom="0" />
    <finalization objectsqueued="0" />
    <scavenger tiltratio="60" />
    <nursery freebytes="30438400" totalbytes="40268800" percent="75" tenureage="1" />
    <tenured freebytes="74960120" totalbytes="372438528" percent="20" >
      <soa freebytes="74960120" totalbytes="372438528" percent="20" />
      <loa freebytes="0" totalbytes="0" percent="0" />
    </tenured>
    <time totalms="86.476" />
  </gc>
  <nursery freebytes="30436352" totalbytes="40268800" percent="75" />
  <tenured freebytes="74960120" totalbytes="372438528" percent="20" >
    <soa freebytes="74960120" totalbytes="372438528" percent="20" />
    <loa freebytes="0" totalbytes="0" percent="0" />
  </tenured>
  <time totalms="86.610" />
</af>
...

Concurrent Generational Collector는 Generation에 기반한다.
따라서 Minor GC와 Major GC와 같은 구분이 존재한다.
IBM JVM에서는 Scavenger GC와 Global GC라는 용어가 사용된다.

위의 예에서 af type="nursery", gc type="scavenger"가 의미하는 것은
Nursery, 즉 Young Generation에서 GC가 발생했으며,
Scavenger GC, 즉 Minor GC가 발생했다는 것을 의미한다.

그렇담, jdk 1.5 이전에는??

 => Response Time 최적화 Collector 가 유사하더군요..

Response Time 최적화 Collector는 Mark and Sweep+Compaction 기법에 약간의 변화를 가한다.
Mark and Sweep 단계를 되도록이면 Application Thread를 멈추지 않는 상태에서 Concurrent 하게 진행한다.
즉 Concurrent Mark 단계와 Concurrent Sweep 단계를 추가로 두어서
Mark and Sweep에 의한 Pause Time을 최소화한다.
Concurrent Mark와 Concurrent Sweep 단계는 Application Thread와 같이 동작하며,
그 만큼 Applicaiton Thread의 CPU 자원을 소모한다.
따라서 Throughput 최적화 Collector에 비해 Throughput이 다소 떨어질 수 있다.

※ 참고로, 일전에 지원했던 사이트의 모 시스템에서 성능테스트 시 Full GC 에 의한 pause time 을 최소화하기 위해
    위의 옵션 (-Xgcpolicy:gencon) 을 적용하여 해결하였던 사례가 있었습니다. 오픈이후 1년이 지난 지금까지 무리없이 운영되고 있답니다~