자바 / 가비지 컬렉터 /
G1 Garbage Collector 1/2
- server-style garbage collector
- multi-processor machines 를 target 으로 한다.
- 높은 처리량(througput)을 달성하면서 높은 확률로 garbage collection pause time 목표를 충족시키다.
- Oracle JDK 7 update 4 부터 지원시작
- 다음과 같은 어플리케이션을 위해 디자인 됐다.
- CMS collector 와 같은 응용 프로그램 스레드와 동시에 작동 하는 application.
- pause time 을 유발하는 긴 GC가 없이 여유 공간을 compact 하는 application
- 더 예측 가능한 GC pause durations가 필요한 application
- 많은 throughput performance 를 희생하고 싶지 않은 application.
- 훨씬 더 큰 Java 힙이 필요하지 않는 application.
G1은 CMS (Concurrent Mark-Sweep Collector)의 장기 교체 계획이다.
- cms 참고글 : Concurrent Mark Sweep (CMS) collector
G1과 CMS를 비교해서, G1의 더 나은 점은
- G1이 compacting collector
- G1 은 충분히 압축한다
- allocation을 위한 fine-grained free list 들의 사용을 완전하게 피하고, 대신에 region 들에 의존하기 위해서 --> 연속된 메모리로 옮겨놓는 것, 이로 인해 분산되어있는 것들에 대한 접근을위해 리스트를 traverse 해야 하지만, 한곳에 모아놓으면 traverse time 을 줄이는 것 같다.
- 이는 collector의 일부를 상당히 단순화하고 잠재적인 fragmentation 문제를 대부분 제거한다
- G1 은 충분히 압축한다
- 또한 G1은 CMS collector 보다 좀 더 예측 가능한 garbage collection pauses를 제공하며 사용자가 원하는 desired pause 목표를 지정할 수 있다.
G1 동작 overview
오래된 garbage collectors (직렬, 병렬, CMS)는 모두 heap을 fixed memory size의
- young generation
- old generation
- permanent generation
의 세 섹션으로 구성한다.
모든 메모리 객체는 이 세 섹션 중 하나에 들어간다.
G1 collector는 다른 접근 방식을 취한다.
heap은 equal-sized heap regions 의 집합으로 나뉜다. 각각의 region은 virtual memroy 의 연속된 범위이다.
heap ---> heap region
|
+---> heap region
|
+---> heap region
특정 region 집합에는 이전 collector와 동일한 역할 (eden, survivor, old)이 할당되지만 정의된 fixed size 는 없다. 이것이 메모리 사용에 있어서 더 큰 유연성을 제공한다.
marking phase
garbage collections 을 수행 할 때 G1은 CMS collector(Concurrent Mark-Sweep Collector)와 유사한 방식으로 작동한다.
G1은 동시 전역 마킹 단계(concurrent global marking phase)를 수행하여 heap 전체에서 객체의 liveness 를 결정한다.
마크 단계가 완료되면 G1은 어느 region이 많이 비어 있는지 알게 된다. 이 region에서 먼저 collect하여 일반적으로 많은 양의 여유 공간을 생성한다. 이러한 garbage collection 방법이 Garbage-First 라고 불리는 이유이다.
reclaimable heap region
이름에서 알 수 있듯이 G1은 회수 가능한(reclaimable) object들, 즉 garbage로 가득 찬 heap region에 수집 및 압축 활동(collection and compaction activity)을 집중시킨다.
G1은 pause prediction model(정지 예측 모델)을 사용하여 user-defined pause time target(유저가 정의한 정지 시간 목표)를 충족시키고 지정된 pause time target를 기반해서 "수집 할 영역(region)의 수"를 선택합니다.
evacuation
G1 이 reclamation 을 할 만큼 오래(ripe)됐다고 판단한 region은 evacuation(방출) 을 사용하여 garbage collect 가 된다.
G1은 "힙의 하나 이상의 region"에서 "힙의 단일 region"으로 객체를 복사하고 프로세스에서 둘 영역 모두의 메모리를 압축하고 해제한다. --> 여러개로 흩어진 region 을 하나의 연속된 공간으로 모으고, 이것을 하나의 region 으로 처리한다?
이러한 evacuation은 multi processors 에서 병렬로 수행되어 pause times을 줄이고 처리량을 증가시킨다.
따라서 G1은 각각의 garbage collection에서 지속적으로 동작하여 단편화를 줄이고 user-defined pause times 내에서 작업한다.
이것은 이전의 두 가지 방법으로는 불가능하다. CMS (Concurrent Mark Sweep) garbage collector 는 압축(compact)을 수행하지 않는다. ParallelOld garbage collection은 전체 힙 압축(whole-heap compaction) 만 수행하므로 상당한 pause times이 발생한다.
G1은 real-time collector가 아니다. 즉, real-time os 처럼 time critical 하지 않다. 높은 확률로 pause time target를 충족하지만, 절대적으로 확신할 수 있는 것은 아니다.
이전 collection 의 데이터를 기반으로 G1은 사용자가 지정한 target time 내에 collect 할 수있는 "region의 수"를 추정한다.
따라서 collector 는 region을 수집하는 비용에 대해 reasonably accurate model(합리적으로 정확한 모델)을 갖고있고, 이 모델을 사용하여 pause time target 내에 어느 region 을 collect 할지 얼마나 많은 region 을 collect 할 지를 결정한다.
참고 : G1에는 concurrent (애플리케이션 스레드와 함께 실행 (예 : refinement, marking, cleanup))와 parallel (멀티 스레드, 예를 들어 stop-the-world) 단계가 있다. full garbage collection은 여전히 단일 스레드이지만, 잘 tuning 하면 애플리케이션이 full GC를 피할 수 있다.
G1 발자국
ParallelOldGC 또는 CMS collector에서 G1으로 마이그레이션하면 JVM 프로세스 크기가 더 커질 수 있다. 이것은 Remembered Sets 및 Collection Sets과 같은 "accounting" data structures 때문이다.
RSets
- Remembered Sets(RSets)는 특정 region 에 대한 obejct referece 들을 추적한다.
- heap에는 region 당 하나의 RSet이 있다.
- RSet을 사용해서 region의 병렬 및 독립 collection이 가능하게 한다.
- RSets의 전체 foot printing 영향은 5 % 미만이다.
CSets
- Collection Sets(CSets) GC에서 collect 될 region 들의 집합.
- CSet의 모든 라이브 데이터는 GC 중에 evacuated 된다.(copied / moved).
- regions 의 집합은 Eden, survivor 및 / 또는 old generation 이 될 수 있다.
- CSets는 JVM 크기에 1 % 미만의 영향을 미친다.
G1의 권장 사용 사례
G1의 첫 번째 초점은 limited GC latency time 의 큰 heap이 필요한 애플리케이션을 실행하는 사용자에게 솔루션을 제공하는 것이다.
약 6GB 이상의 힙 크기와 0.5 초 미만의 안정적이고 예측 가능한 pause time 을 의미한다.
CMS 또는 ParallelOldGC garbage collector로 실행중인 응용 프로그램 중 G1로 전환하는 것이 좋은 경우(다음중 하나에 해당하면 G1 을 사용하는 것이 좋다.)
- Full GC duration이 너무 길거나 너무 자주 일어난다.
- object allocation rate 의 비율 또는 object promotion 비율이 크게 다르다.
- 원하지 않는 긴 garbage collection 또는 compaction pauses (0.5-1 초 이상)
참고 :
- CMS 또는 ParallelOldGC를 사용하고 있고 응용 프로그램에 garbage collection pauses가 길지 않으면 현재 collector를 유지하는 것이 좋다.
- 최신 JDK를 사용해도 G1 collector 를 꼭 사용하지 않아도 된다.
댓글 없음:
댓글 쓰기