Microsoft MVP성태의 닷넷 이야기
.NET Framework: 729. windbg로 살펴보는 GC heap의 Segment 구조 [링크 복사], [링크+제목 복사]
조회: 3777
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
[test.pptx]    

windbg로 살펴보는 GC heap의 Segment 구조

지난번 GC 설명 글에서,

.NET Garbage Collection에 대한 정리
; https://www.sysnet.pe.kr/2/0/1862

링크한 다음의 글에는 Segment에 대한 이야기가 나옵니다.

How does the GC work and what are the sizes of the different generations?
; https://blogs.msdn.microsoft.com/tess/2008/04/17/how-does-the-gc-work-and-what-are-the-sizes-of-the-different-generations/

이 내용을 한번 정리해 보겠습니다. ^^

우선, 위의 글에서 예로 든 Server GC를 사용하는 응용 프로그램의 경우 총 192MB 크기의 힙이 점유되어 있는데, (2 CPU를 가진 시스템의) Server GC이므로 다음과 같은 구성으로 잡혀 있습니다.

Heap 0:
    Small Object 용 segment 64MB
    Large Object 용 segment 32MB

Heap 1:
    Small Object 용 segment 64MB
    Large Object 용 segment 32MB

당연히 Gen0, Gen1, Gen2객체는 64MB로 할당되는 small object 용 segment에서 시작합니다.

이것을 확인해 볼까요? ^^ 간단하게 코드를 만들어,

// .NET 4.7 + 32bit

using System;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Press ENTER key to exit...");
            Console.ReadLine();
        }
    }
}

실행 후 windbg로 연결해 힙을 보면,

0:007> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x04bf1018
generation 1 starts at 0x04bf100c
generation 2 starts at 0x04bf1000
ephemeral segment allocation context: none
 segment     begin  allocated      size
04bf0000  04bf1000  04bf5ff4  0x4ff4(20468)
Large object heap starts at 0x05bf1000
 segment     begin  allocated      size
05bf0000  05bf1000  05bf5500  0x4500(17664)
Total Size:              Size: 0x94f4 (38132) bytes.
------------------------------
GC Heap Size:    Size: 0x94f4 (38132) bytes.

콘솔 프로그램이기 때문에 Workstation GC가 사용되어 GC Heap의 수는 1입니다. 그리고 "ephemeral segment", 즉 small object heap으로 1개의 segment가 할당되어 있고,

 segment     begin  allocated      size
04bf0000  04bf1000  04bf5ff4  0x4ff4(20468)

Large object heap으로 또 1개의 segment가 할당되어 있습니다.

 segment     begin  allocated      size
05bf0000  05bf1000  05bf5500  0x4500(17664)

SOH(Small Object Heap)의 경우 segment 시작 주소는 04bf0000이지만 begin은 04bf1000로 나옵니다. 개인적인 의견으로 앞의 0x1000 바이트는 예약된 영역이 아닌가 생각됩니다. 그런 다음 할당이 04bf5ff4로 나오는데 04bf5ff4 - 04bf0000 = 0x5ff4로 겨우 24,564 바이트에 불과합니다. 아니... 전에는 64MB가 할당된다고 하면서 왜 24,564바이트일까요? 그 이유는, 64MB는 "예약(reserved)"영역이고 0x5ff4 바이트 공간은 commit 영역이기 때문입니다.

여기서 아쉬운 것은 "How does the GC work and what are the sizes of the different generations?" 글에서 소개할 당시의 sos 확장에서는 예약 영역의 크기까지도 출력이 되는 반면 현재 버전의 sos 확장에서는 그 부분이 누락되었습니다. 그렇긴 해도 해당 글에서 설명한 !address 명령어를 이용해 예약 크기를 살펴보는 것이 가능합니다.

예를 들어, SOH segment의 시작 주소 04bf0000를 !address로 살펴보면,

0:007> !address 04bf0000  
                                     
Mapping file section regions...
Mapping module regions...
Mapping PEB regions...
Mapping TEB and stack regions...
Mapping heap regions...
Mapping page heap regions...
Mapping other regions...
Mapping stack trace database regions...
Mapping activation context regions...

Usage:                  <unknown>
Base Address:           04bf0000
End Address:            04c02000
Region Size:            00012000 (  72.000 kB)
State:                  00001000          MEM_COMMIT
Protect:                00000004          PAGE_READWRITE
Type:                   00020000          MEM_PRIVATE
Allocation Base:        04bf0000
Allocation Protect:     00000004          PAGE_READWRITE


Content source: 1 (target), length: 12000

현재 commit된 페이지가 04bf0000 ~ 04c02000까지로 0x12000(73,728, 약 72KB)만큼의 크기가 됩니다. 이후 공간을 살펴볼까요?

0:007> !address 04c02000

Usage:                  <unknown>
Base Address:           04c02000
End Address:            05bf0000
Region Size:            00fee000 (  15.930 MB)
State:                  00002000          MEM_RESERVE
Protect:                <info not present at the target>
Type:                   00020000          MEM_PRIVATE
Allocation Base:        04bf0000
Allocation Protect:     00000004          PAGE_READWRITE

보는 바와 같이 05bf0000 주소까지 15.930MB만큼 예약(reserved)되어 있습니다. 그러니까, SOH의 연속 공간으로 총 16MB의 가상 주소가 점유된 것입니다. 이것을 그림으로 정리하면 다음과 같이 됩니다.

gc_segment_1.png

그런데 역시 이번에도 64MB가 아닙니다. 왜냐하면, "How does the GC work and what are the sizes of the different generations?" 글에서 언급한 것처럼,

How much it will allocate is depends on what framework version you use (including service packs or hotfixes), if you are running on x64 or x86 and what GC flavor the application is using (workstation or server)

환경에 따라 다르기 때문입니다. 즉, x86 + .NET 4.7의 Workstation GC에서는 SOH의 한 Segment 크기가 16MB입니다. 실제로 이 프로그램에서 Server GC 유형으로 설정해 실행하면 SOH의 한 Segment 크기가 32MB로 바뀌고 논리 CPU 만큼 생성됩니다. 예를 들어, 8개의 논리 CPU를 가진 시스템에서 x86 + .NET 4.7 + Server GC로 수행하면 32MB SOH 힙이 8개가 생성되어 총 256MB가 할당됩니다.




이어서 LOH도 유사하게 살펴볼 수 있는데요. 가만 보면, SOH의 예약 공간 주소의 끝 주소가 05bf0000로 되어 있고 LOH의 시작 주소가 05bf0000인 걸로 봐서 CLR은 초기 응용 프로그램 시작에서 SOH 예약 공간 다음에 이어서 LOH 공간을 예약하는 것으로 보입니다.

!address 명령어를 통해 살펴보면,

0:007> !address 05bf0000  

Usage:                  <unknown>
Base Address:           05bf0000
End Address:            05c02000
Region Size:            00012000 (  72.000 kB)
State:                  00001000          MEM_COMMIT
Protect:                00000004          PAGE_READWRITE
Type:                   00020000          MEM_PRIVATE
Allocation Base:        04bf0000
Allocation Protect:     00000004          PAGE_READWRITE


Content source: 1 (target), length: 12000

0:007> !address 05c02000

Usage:                  <unknown>
Base Address:           05c02000
End Address:            06bf0000
Region Size:            00fee000 (  15.930 MB)
State:                  00002000          MEM_RESERVE
Protect:                <info not present at the target>
Type:                   00020000          MEM_PRIVATE
Allocation Base:        04bf0000
Allocation Protect:     00000004          PAGE_READWRITE

최초 commit은 72KB이고 총 예약 크기는 16MB임을 알 수 있습니다. 동일한 프로그램을 Server GC로 보면 LOH의 commit 크기가 8KB이고 예약은 16MB인 것을 확인할 수 있습니다.




다시 !eeheap 명령어 결과로 가서,

0:007> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x04bf1018
generation 1 starts at 0x04bf100c
generation 2 starts at 0x04bf1000
ephemeral segment allocation context: none
 segment     begin  allocated      size
04bf0000  04bf1000  04bf5ff4  0x4ff4(20468)
Large object heap starts at 0x05bf1000
 segment     begin  allocated      size
05bf0000  05bf1000  05bf5500  0x4500(17664)
Total Size:              Size: 0x94f4 (38132) bytes.
------------------------------
GC Heap Size:    Size: 0x94f4 (38132) bytes.

이번에는 Gen 0, 1, 2 각각의 시작 주소가 다음과 같습니다.

Gen 0 0x04bf1018
Gen 1 0x04bf100c
Gen 2 0x04bf1000

그림으로 정리해 보면 다음과 같습니다.

gc_segment_3.png

이 정도면 이제 CLR GC Heap의 구조가 머릿속에 그려질 것입니다.




그렇다면, SOH 힙의 구조를 알았으니 이제 힙에 어떤 객체들이 할당되어 있는지 열람할 수 있습니다. 시작은 Gen2 주소부터 하면, 이렇게 나옵니다.

0:007> !do 0x04bf1000
Free Object
Size:        12(0xc) bytes

"Free Object"라고 나오는데, 아직 한 번도 2세대 GC가 구동된 적이 없는 상태이기 때문에 reserved 의미로 할당된 듯 합니다. 이후 0x04bf100c 주소부터는 Gen 1세대 객체들인데요.

0:007> !do 0x04bf100c
Free Object
Size:        12(0xc) bytes

역시 1세대 GC도 구동된 적이 없기 때문에 reserved 의미로 1개의 빈 객체가 할당된 것 같습니다. 0세대 객체가 위치한 0x04bf1018 주소도 첫 번째 객체는 "Free Object"로 나옵니다.

0:007> !do 04bf1018
Free Object
Size:        12(0xc) bytes

음... 아무래도 0, 1, 2 세대의 첫 번째 객체는 "Free Object"로 고정된 것 같습니다. (순전히 저의 예상입니다.)

하지만, 이후부터는 정상적으로 객체들이 나옵니다.

0:007> !do 04bf1018 + c
Name:        System.Exception
MethodTable: 70eefc1c
EEClass:     709d6558
Size:        84(0x54) bytes
File:        C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
70eefad4  400028f        4        System.String  0 instance 00000000 _className
70ee4b18  4000290        8 ...ection.MethodBase  0 instance 00000000 _exceptionMethod
...[생략]...
70eb254c  40002a1       38 ...ializationManager  0 instance 00000000 _safeSerializationManager
70eefe74  400028e       5c        System.Object  0   shared   static s_EDILock
    >> Domain:Value  02c0cfe8:NotInit  <<


0:007> !do 04bf1018 + c + 54
Name:        System.OutOfMemoryException
MethodTable: 70eefd70
EEClass:     70a78e04
Size:        84(0x54) bytes
File:        C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
70eefad4  400028f        4        System.String  0 instance 00000000 _className
70ee4b18  4000290        8 ...ection.MethodBase  0 instance 00000000 _exceptionMethod
...[생략]...
70eb254c  40002a1       38 ...ializationManager  0 instance 00000000 _safeSerializationManager
70eefe74  400028e       5c        System.Object  0   shared   static s_EDILock
    >> Domain:Value  02c0cfe8:NotInit  <<

이런 식으로 Segment 별로 할당된 CLR 객체를 모두 열람할 수 있습니다.




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





[최초 등록일: ]
[최종 수정일: 1/20/2018 ]

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

비밀번호

댓글 쓴 사람
 




... [31]  32  33  34  35  36  37  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
11578정성태7/3/20182633Math: 31. GeoGebra 기하 (8) - 호(Arc)의 이등분파일 다운로드1
11577정성태7/3/20183005Math: 30. GeoGebra 기하 (7) - 각의 이등분파일 다운로드1
11576정성태7/3/20182741Math: 29. GeoGebra 기하 (6) - 대수의 4칙 연산파일 다운로드1
11575정성태7/2/20183285Math: 28. GeoGebra 기하 (5) - 선분을 n 등분하는 방법파일 다운로드1
11574정성태7/2/20182713Math: 27. GeoGebra 기하 (4) - 선분을 n 배 늘이는 방법파일 다운로드1
11573정성태7/2/20182573Math: 26. GeoGebra 기하 (3) - 평행선
11572정성태7/1/20182309.NET Framework: 783. C# 컴파일러가 허용하지 않는 (유효한) 코드를 컴파일해 테스트하는 방법
11571정성태7/1/20182402.NET Framework: 782. C# - JIRA에 등록된 Project의 Version 항목 추가하는 방법파일 다운로드1
11570정성태7/2/20183611Math: 25. GeoGebra 기하 (2) - 임의의 선분과 특정 점을 지나는 수직선파일 다운로드1
11569정성태7/1/20183066Math: 24. GeoGebra 기하 (1) - 수직 이등분선파일 다운로드1
11568정성태7/12/20185853Math: 23. GeoGebra 기하 - 컴퍼스와 자를 이용한 작도 프로그램 [1]
11567정성태6/28/20182811.NET Framework: 781. C# - OpenCvSharp 사용 시 포인터를 이용한 속도 향상파일 다운로드1
11566정성태6/28/20185586.NET Framework: 780. C# - JIRA REST API 사용 정리 [4]파일 다운로드1
11565정성태6/28/20182993.NET Framework: 779. C# 7.3에서 enum을 boxing 없이 int 변환하기 - 세 번째 이야기파일 다운로드1
11564정성태6/27/20183107.NET Framework: 778. (Unity가 사용하는) 모노 런타임의 __makeref 오류
11563정성태6/27/20182715개발 환경 구성: 386. .NET Framework Native compiler 프리뷰 버전 사용법
11562정성태6/26/20182413개발 환경 구성: 385. 레지스트리에 등록된 원격지 스크립트 COM 객체 실행 방법
11561정성태6/26/20185141.NET Framework: 777. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! [3]파일 다운로드1
11560정성태3/2/20192361.NET Framework: 776. C# 7.3 - 초기화 식에서 변수 사용 가능(expression variables in initializers)파일 다운로드1
11559정성태1/27/20205510개발 환경 구성: 384. 영문 설정의 Windows 10 명령행 창(cmd.exe)의 한글 지원 [3]
11558정성태6/25/20182906.NET Framework: 775. C# 7.3 - unmanaged(blittable) 제네릭 제약파일 다운로드1
11557정성태6/22/20183426.NET Framework: 774. C# - blittable 타입이란?파일 다운로드1
11556정성태6/25/20186168.NET Framework: 773. C# 7.3 - 구조체의 고정 크기를 갖는 fixed 배열 필드에 대한 직접 접근 가능 [1]파일 다운로드1
11555정성태6/25/20182826.NET Framework: 772. C# 7.3 - 사용자 정의 타입에 fixed 적용 가능(Custom fixed)파일 다운로드1
11554정성태6/25/20182850.NET Framework: 771. C# 7.3 - 자동 구현 속성에 특성 적용 가능(Attribute on backing field)
11553정성태6/25/20183266.NET Framework: 770. C# 7.3 - 개선된 메서드 선택 규칙 3가지(Improved overload candidates)파일 다운로드1
... [31]  32  33  34  35  36  37  38  39  40  41  42  43  44  45  ...