세대 별 GC(Garbage Collection) 방식에서 Card table의 사용 의미
그러고 보니 지난 글에서,
.NET GC - 하위 세대의 객체를 포함하는 상위 세대의 참조를 추적하기 위한 card-table
; https://www.sysnet.pe.kr/2/0/1670
Card-table에 대한 언급과 함께 JIT 컴파일 시의 JIT_WriteBarrierEAX 코드 출력만 언급하고 왜 사용하는지에 대한 이유를 설명하지 않고 넘어갔는데요. 사실 그 이유는, 위의 글에서 링크한 "
Generational Garbage Collection"에서 "
Tracking higher to lower generation references" 절에서 자세하게 설명하고 있습니다.
위의 글을 정리해서 풀어보면.
CLR이 선택한 "mark-sweep" 방식의 GC에서 가장 큰 단점은, 전체 heap에 대한 정리를 할 때 프로그램의 중지 시간이 너무 길 수 있다는 것입니다. 그리고 이에 대한 단점을 극복하기 위해 GC에 세대라는 개념을 도입하는 것인데요, 이렇게 해서 성능 향상이 된다는 근거는 다음의 가정을 바탕으로 합니다.
- 대부분의 개체는 0세대에서 소멸
- 수집된 90% 이상의 개체들이 지난번 GC 이후 새롭게 생성된 개체들
- 일단 GC 과정에서 살아남은 개체는 생명 주기가 길수 있다.
위의 가정에 따라, "세대별 GC" 모델에서는 Full GC의 수행 횟수는 낮추고 주로 0세대 개체만 빠르게 GC 함으로써 성능을 확보할 수 있습니다. 물론 이런 경우에도 2세대 힙까지 GC를 하게 되면 실행이 끊기는 현상이 나올 수 있습니다.
그런데 이 과정에서 왜? card-table을 두는 것이 효과가 있을까요?
GC는 해당 개체를 제거하기 위해서는 그 개체를 참조하는 "root 개체"가 없어야 합니다. 이러한 root 개체가 스레드 스택, CPU의 레지스터라면 빠르게 그 참조 여부를 알 수 있습니다. 스택은 기본적으로 1MB지만 실제 commit된 스택을 고려한다면 더 작을 수 있으며 CPU의 레지스터는 그 수가 더욱 한정적이기 때문에 GC 입장에서 성능에 치명적인 요소는 아닙니다.
그런데 문제는, "root 개체"가 다른 개체일 경우입니다. 그리고 그 개체들 중 특히 문제가 되는 것은 2세대에 있는 개체들로부터의 참조 여부를 가릴 때입니다.
일반적으로, Full GC 유형이라면 어차피 모든 heap을 열거해야 하므로 딱히 문제가 안 됩니다. 재미있는 것은, 세대별로 나눠 0세대만 혹은 1세대만 GC하는 경우 그것들의 "root 개체"가 2세대에 있는 개체인지 알아내기 위해 결국 2세대로 누적된 방대한 heap 영역을 모두 뒤져야 한다는 아이러니한 상황이 나오는 것입니다. (차라리 그럴 거면 애당초 Full GC만 하면 됩니다.)
이렇게, 낮은 세대의 개체를 GC하기 위해 Old 세대의 참조 개체가 있는지 빠르게 알 수 있는 방법으로 Card table이 해결책으로 나옵니다. 예를 들어 다음의 그림은 Gen0에 있는 개체를 참조하고 있는 Gen1의 개체가 있는지 알 수 있는 card table의 개념을 보여줍니다.
card table은 비트의 집합으로 되어 있고, Gen1의 전체 크기를 4KB 영역으로 나눠 1비트에 대응시킵니다. 가령, Gen1 메모리가 0x1000에서 시작한다고 가정했을 때 card_table의 첫 번째 비트가 1이면 0x1000 ~ 0x2000 사이의 Gen1 개체가 Gen 0의 개체를 참조하고 있다는 표시가 됩니다. 즉, 전체 Gen1 메모리를 뒤질 필요 없이 card-table에서 1비트로 표시된 4KB 구간의 집합만 검색하면 되는 것입니다. (물론, 대부분의 힙에서 1비트로 표시되면 성능이 개선될 수 없겠지만, "
Tracking higher to lower generation references" 절에서 언급하듯이 연구 결과에 따르면 실제로 old 개체가 ephemeral 개체(0, 1세대)를 참조하는 경우는 1% 이하라고 합니다.)
그렇다면, card_table에 old 개체가 young 개체를 가리키고 있다는 표시를 해야 하는데요, 그게 바로 이전에 살펴봤던 clr!JIT_WriteBarrierEAX 함수로 JIT 컴파일러에 의해 자동으로 추가되는 코드입니다.
.NET GC - 하위 세대의 객체를 포함하는 상위 세대의 참조를 추적하기 위한 card-table
; https://www.sysnet.pe.kr/2/0/1670
여기서 한 가지 재미있는 점은 아래의 코드에서,
class Program
{
public InnerType In;
static void Main(string[] args)
{
Program pg = new Program();
InnerType instance = new InnerType();
pg.In = instance;
}
}
class InnerType { }
pg 개체와 instance 개체의 세대 비교를 어떻게 하면 빠르게 할 수 있을지입니다. CLR의 경우 한 가지 다행인 점은, Gen1과 Gen0 개체는 동일한 ephemeral segment에 할당되어 있다는 점입니다. 따라서, pg 개체와 instance 개체가 같은 segment에 있고 그것이 ephemeral segment라면 연속적인 할당이 이뤄지므로 Gen0/1의 경계 주솟값만 비교하면 세대 차이를 알 수 있습니다. 반면 pg 개체와 instance 개체가 다른 segment에 있다고 판단이 되면 마찬가지로 어느 한 쪽만 ephemeral segment 내에 있는지 판단이 되면 자동으로 세대 차이를 알 수 있습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]