닷넷 GC에 새롭게 구현되는 DPAD(Dynamic Promotion And Demotion for GC)
이번엔 다음 글의 내용을 (대충 요약해서) 소개하려고 합니다. ^^
Put a DPAD on that GC!
; https://devblogs.microsoft.com/dotnet/put-a-dpad-on-that-gc/
DPAD(Dynamic Promotion And Demotion for GC)라는 기능이 추가되었고 이를 위해 기존의 Segment 단위의 힙 관리가 아닌, 좀 더 경량화된 Region 단위로 바뀔 예정이라고 합니다. 아울러 해당 구현을 clrgc.dll에 실험적으로 넣어 config 파일을 통해 제어할 수 있게 한다고. (이렇게 구현된 기능들은 나중에 coreclr.dll로 옮겨지고 기본값으로 적용될 거라고 합니다.)
자, 그럼 DPAD의 설명에 앞서 Region 단위의 관리가 무엇인지부터 설명할 필요가 있습니다.
우선 그동안 사용했던
GC Segment의 할당 규모는 예전 글에서 설명한 적이 있는데요,
Workstation GC: 32비트 - 16MB, 64비트 - 256MB
Server GC: 32비트 - 64MB, 64비트 - 4GB
Server GC with > 4 logical CPUs: 32비트 - 32MB, 64비트 - 2GB
Server GC with > 8 logical CPUs: 32비트 - 16MB, 64비트 - 1GB
이렇게 큰 segment 단위의 운용은 아무래도 부담스러울 수 있기 때문에 DPAD에서는 좀 더 작은 단위, 기본적으로는 4MB를 할당하는 것으로 Region이라는 이름을 붙인 것입니다.
그렇다면, 단적으로 말해서 segment의 크기가 4MB로 작아졌다고 해서 무슨 큰 의미가 있을까요? 이에 대한 설명이 도식과 함께 나옵니다.
기존의 단일 segment에서의 SOH(Small Object Heap) 레이아웃이,
위와 같이 단순하지만 실제로는 대부분 다중 segment가 할당되면서 아래와 같은 양상을 보이게 됩니다.
[다중 segment 사례 1]
[다중 segment 사례 2]
(위의 그림에서 파란색과 노란색의 블록들은 모두
사용되고 있는 메모리 영역입니다.)
그런데, 때로는 저렇게 크게 유지하는 segment의 중간에 자유 공간이 발생할 수 있습니다. 문제는, 현재의 세그먼트 방식에서는 저 중간의 영역을 재활용할 방법이 없다는 것입니다. 대표적으로 Gen2와 LOH에 Pinning 개체가 있어 GC의 compacting을 방해한다거나, Gen0이라 해도 비동기 I/O 도중 발생하는
pinning 개체가 GC 후에도 Gen0에 남아 있는 경우 세그먼트에 자유 공간이 생길 수 있습니다.
따라서, GC를 좀 더 작은 Region으로 나눠 다음과 같은 식으로 유지한다면,
개별 블록(Region)들이 비워졌을 때 Region Pool에 반환되고 다른 세대에서 좀 더 필요하면 해당 Region은 0세대에서 사용했던 것이라도 자유롭게 2세대 영역으로 재사용될 수 있는 것입니다.
물론 이것에는 장/단점이 있습니다. 기존의 segment는 적어도 연속적인 공간이라는 점과, 0세대와 1세대의 개체들이 같은 세그먼트에 존재한다는 가정을 할 수 있어 card-table의 운영이 매우 쉬웠습니다. 이에 대해서는 다음의 글에서 설명했습니다.
세대 별 GC(Garbage Collection) 방식에서 Card table의 사용 의미
; https://www.sysnet.pe.kr/2/0/12649
하지만, Region으로 나뉘게 되면 세대의 차이를 계산하기보다는 차라리 무조건적인 card-table의 비트 설정을 해야 합니다. 이런 방식은 기존의 Server-GC에서 했던 것이기 때문에 단지 Workstation GC 방식에서만 약간의 GC 지연을 발생시킵니다. 또는, Region으로 나뉜 탓에 "obj0.f = obj1"과 같은 연산에서 obj1의 0/1세대를 결정하기 위해 꽤나 무거운 연산을 수행해야 합니다.
따라서, Region을 도입하려면 저런 동작으로 인한 성능 저하를 충분히 만회시킬 수 있는 어떤 장점을 가져야 합니다.
당연히, 그것을 보완할 수 있으니까 이런 개선이 나왔을 텐데요, 그것이 바로 DPAD(Dynamic Promotion And Demotion for GC)입니다. 이름에서 나온 demotion은 사실
기존에도 (비록 그것이 pinning 상황에 한정되어 있지만) 동적으로 다뤄지고 있었습니다.
promition은 이미 잘 아시는 것처럼, GC에서 살아남은 개체들의 세대가 증가하는 것으로 현재 가장 상위인 2세대까지 가려면 2번의 GC를 필요로 하게 됩니다. 하지만, 그것을 API를 통해 제어할 수 있는, 즉 개발자가 특정 개체에 대해 처음부터 원하는 세대를 결정할 수 있도록 있게 만들 예정입니다. (이런 기능은 기존의 세그먼트 구조보다는 Region을 도입했을 때 구현이 쉽습니다.)
이렇게 개발자가 정할 수 있는 경우도 있지만, 때로는 특정 개체가 2세대까지 살아남을 수 있을지 판단할 수 없는 경우도 있습니다. 또는 수정 권한이 없는 라이브러리를 사용하는 경우에도 그 내부에서 할당되는 개체들은 제어할 수가 없습니다. 단적인 예로, 자료 구조에서 데이터의 크기를 2배로 늘려 재조정하는 경우, 신규 배열 버퍼는 크기가 85,000 보다 커서 (2세대에 준하는) LOH에 할당이 되고, 늘어난 크기에 들어갈 신규 개체들은 모두 Gen0에 위치하게 되는 경우가 있습니다. 그 예로, 아래의 그림은 크기가 4였던 배열을 가진 T[]가 2배 늘려 8까지 늘었을 때, 신규 개체들이 나머지 절반에 할당되는 것을 의미합니다. (표현을 위해 작은 배열을 사용했으므로 실제로는 아래의 상황에서는 신규 배열이 LOH에 할당되지는 않습니다.)
위의 그림을 세대별로 구분해 보면 아래와 같이 표현할 수 있는데,
(위의 그림에서, A0 개체가 3세대에 할당되어 있는데, 원래 LOH는 내부적인 세대 구분에서는 3세대,
POH는 4세대로 식별됩니다.)
결국 0세대에 있는 신규 개체들은 3세대의 힙에서 참조하고 있으므로 GC 과정에서 2세대까지 진화할 것이 (그사이 List 개체가 GC 대상이 되면 안 되겠지만, 사실 그럴 가능성은 잘 발생하지 않으므로) 분명합니다. 결국, 해당 개체들은 다음번 GC가 발생하면 세대를 올라가고,
그리고 다시 한번 GC까지 발생하는 부하를 거쳐,
어차피 가야 했을 2세대로 진화하게 됩니다. 그렇다면 애당초 해당 개체들을 2세대로 만들면 좋았겠지만, 기존의 세그먼트 구조에서는 그렇게 만드는 것이 쉽지 않습니다. 하지만 Region으로 나뉜 상태라면, 다음과 같이 Gen0에 엮일 개체들이,
Gen2로의 승격을 진행할 수 있다고 판단이 되면 해당 Region을 그냥 Gen2로 이어붙이면 되는 것입니다.
여기까지 읽으셨으면 이제 DPAD의 기능이 마치
게임 패드의 버튼을 사용하듯이 특정 Region에 대해 세대를 올리거나 내리는데 자유로울 수 있다는 것을 알 수 있을 것입니다. 즉, 말 그대로 "Promotion (세대를 올리거나)과 Demotion (세대를 내리는)" 것이 동적(Dynamically)으로 가능한 것입니다.
그러면서 글쓴이는, 위에서 든 사례 이외에 DPAD의 활용이 보다 더 다양한 상황에서 적용 가능할 거라고 언급하고 있습니다. 결국, Region으로 인한 card-table의 성능 하락을 충분히 상쇄할만한 성능 향상을 가져올 수 있다는 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]