Garbage First Collector 이하 G1 Collector는 예전에 잠깐 소개한적이 있는데,
오늘 지금 하는 프로젝트에서 메모리 관련 이슈가 있어서 잠깐 살펴보았는데, 대략 적인 원리는 다음과 같다.
CMS (Concurrent Mark & Sweep)의 원리는
기존에, New 영역을 Old영역으로 보낸후에, Old 영역의 Object Tree를 Search해서 Dead Object를 Mark하고, Mark 된 Object들을 deallocate하는 방식이었다. 이 작업을 Concurrent Thread가 연속적으로 한다는 것인데, (Full GC 시간에 몰아서 하는 것이 아니라. )
G1 Collector는 메모리 구조 부터가 틀리다.
New/Old 영역을 Physical하게 따로 나누지 않고, 메모리를 Region이라는 일정 크기의 블럭으로 나눈다.
Region안에 있는 객체들이 다른 Region에 있는 객체들에 의해서 참조되는 지를 Remembered List를 이용하여 관리한다. 그리고, Region 단위로 Live Object가 있는지 없는지를 판단하여 해당 Regiion이 다 차면, 살아 있는 Object들을 다른 Region으로 copy한후 해당 Region을 모두 날려 버린다. 이러니 Fragmentation에 대한 문제가 많이 해결 된다.
Fragmentation이 없기(?) 때문에, 처음에 메모리를 Allocation할때, 기존 메모리 관리모델에서는 그 크기의 공간이 어디 있는지를 Search해야 했지만, G1 Collector의 경우, Region 단위로 빈공간을 찾기 때문에, Allocation의 효율성이 매우 높다.
아직 상세하게 살펴보지는 못했는데, 대강의 원리는 이렇게 되는것 같고.. 엔터프라이즈 자바 애플리케이션에서 그간 메모리 관리로 인한 Concern이 많았는데, (2G이상의 Heap을 사용할때 GC성능) G1 Collector가 이 문제를 시원하게 풀어줬으면 좋겠다
'성능과 튜닝 > JVM' 카테고리의 다른 글
VisualVM을 이용한 JVM 모니터링 (0) | 2013.09.05 |
---|---|
새로운 GC Collector G1. (1) | 2009.04.20 |
JVM 튜닝 (5) | 2008.03.12 |
Sun JVM HeapDump 얻기 (1) | 2007.11.28 |
-XX:PretenureSizeThreshold (0) | 2007.11.10 |