Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

세대 별 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_image_thumb_7.png

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 내에 있는지 판단이 되면 자동으로 세대 차이를 알 수 있습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 5/16/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2022-12-03 10시38분
Segment가 Region으로 바뀌면서,

.NET 7에 도입된 GC의 메모리 해제에 대한 segment와 region의 차이점
; https://www.sysnet.pe.kr/2/0/13083

card table 관련 코드도 바뀌는데, 이에 대한 자세한 설명을 아래의 글에서 볼 수 있습니다.

Write barrier optimizations in regions
; https://maoni0.medium.com/write-barrier-optimizations-in-regions-984bde6c0ffc
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13184정성태12/5/202227개발 환경 구성: 652. ml64.exe와 link.exe x64 실행 환경 구성
13183정성태12/4/202225오류 유형: 830. MASM + CRT 함수를 사용하는 경우 발생하는 컴파일 오류 정리
13182정성태12/4/202256Windows: 217. Windows 환경에서의 Hello World x64 어셈블리 예제 (MASM 버전)
13181정성태12/3/202254Linux: 54. 리눅스/WSL - hello world 어셈블리 코드 x86/x64 (nasm)
13180정성태12/2/202260.NET Framework: 2074. C# - 스택 메모리에 대한 여유 공간 확인하는 방법파일 다운로드1
13179정성태12/2/202232Windows: 216. Windows 11 - 22H2 업데이트 이후 Terminal 대신 cmd 창이 뜨는 경우
13178정성태12/1/2022112Windows: 215. Win32 API 금지된 함수 - IsBadXxxPtr 유의 함수들이 안전하지 않은 이유파일 다운로드1
13177정성태11/30/202261오류 유형: 829. uwsgi 설치 시 fatal error: Python.h: No such file or directory
13176정성태11/29/202255오류 유형: 828. gunicorn - ModuleNotFoundError: No module named 'flask'
13175정성태11/29/202278오류 유형: 827. Python - ImportError: cannot import name 'html5lib' from 'pip._vendor'
13174정성태11/28/2022104.NET Framework: 2073. C# - VMMap처럼 스택 메모리의 reserve/guard/commit 상태 출력파일 다운로드1
13173정성태11/27/2022195.NET Framework: 2072. 닷넷 응용 프로그램의 스레드 스택 크기 변경
13172정성태11/25/2022241.NET Framework: 2071. 닷넷에서 ESP/RSP 레지스터 값을 구하는 방법파일 다운로드1
13171정성태11/25/2022201Windows: 214. 윈도우 - 스레드 스택의 "red zone"
13170정성태11/24/2022347Windows: 213. 윈도우 - 싱글 스레드는 컨텍스트 스위칭이 없을까요?
13169정성태11/23/2022358Windows: 212. 윈도우의 Protected Process (Light) 보안 [1]파일 다운로드2
13168정성태11/22/2022317제니퍼 .NET: 31. 제니퍼 닷넷 적용 사례 (9) - DB 서비스에 부하가 걸렸다?!
13167정성태11/21/2022312.NET Framework: 2070. .NET 7 - Console.ReadKey와 리눅스의 터미널 타입
13166정성태11/20/2022240개발 환경 구성: 651. Windows 사용자 경험으로 WSL 환경에 dotnet 런타임/SDK 설치 방법
13165정성태11/18/2022252개발 환경 구성: 650. Azure - "scm" 프로세스와 엮인 서비스 모음
13164정성태11/18/2022410개발 환경 구성: 649. Azure - 비주얼 스튜디오를 이용한 AppService 원격 디버그 방법
13163정성태11/17/2022261개발 환경 구성: 648. 비주얼 스튜디오에서 안드로이드 기기 인식하는 방법
13162정성태11/15/2022646.NET Framework: 2069. .NET 7 - AOT(ahead-of-time) 컴파일
13161정성태11/14/2022486.NET Framework: 2068. C# - PublishSingleFile로 배포한 이미지의 역어셈블 가능 여부 (난독화 필요성) [2]
13160정성태11/11/2022566.NET Framework: 2067. C# - PublishSingleFile 적용 시 native/managed 모듈 통합 옵션
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...