Microsoft MVP성태의 닷넷 이야기
.NET Framework: 729. windbg로 살펴보는 GC heap의 Segment 구조 [링크 복사], [링크+제목 복사]
조회: 3786
글쓴 사람
정성태 (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

비밀번호

댓글 쓴 사람
 




... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...
NoWriterDateCnt.TitleFile(s)
11661정성태8/21/20182437사물인터넷: 34. 트랜지스터 동작 - 컬렉터-이미터 간의 저항 측정파일 다운로드1
11660정성태9/4/20182269사물인터넷: 33. 세라믹 커패시터의 동작 방식파일 다운로드1
11659정성태8/19/20182444사물인터넷: 32. 9V 전압에서 테스트하는 PN2222A 트랜지스터파일 다운로드1
11658정성태8/18/20184070사물인터넷: 31. 커패시터와 RC 회로파일 다운로드3
11657정성태8/21/20183050사물인터넷: 30. 릴레이(Relay) 제어파일 다운로드3
11656정성태8/18/20181913사물인터넷: 29. 트랜지스터와 병렬로 연결한 LED파일 다운로드1
11655정성태8/18/20183237사물인터넷: 28. 저항과 병렬로 연결한 LED파일 다운로드1
11654정성태8/18/20182306사물인터넷: 27. 병렬 회로의 저항, 전압 및 전류파일 다운로드1
11653정성태8/18/20182177사물인터넷: 26. 입력 전압에 따른 LED의 전압/저항 변화파일 다운로드1
11652정성태9/11/20182035사물인터넷: 25. 컬렉터 9V, 베이스에 5V와 3.3V 전압으로 테스트하는 C1815 트랜지스터파일 다운로드1
11651정성태9/4/20184081사물인터넷: 24. 9V 전압에서 테스트하는 C1815 트랜지스터파일 다운로드3
11650정성태8/18/20182195사물인터넷: 23. 가변저항으로 분압파일 다운로드1
11649정성태8/14/20182424사물인터넷: 22. 저항에 따른 전류 테스트파일 다운로드1
11648정성태10/17/20183197사물인터넷: 21. 퓨즈를 이용한 회로 보호파일 다운로드3
11647정성태8/8/20182402오류 유형: 476. 음수의 음수는 여전히 음수가 되는 수(절대값이 음수인 수)
11646정성태8/8/20182130오류 유형: 475. gacutil.exe 실행 시 "Failure initializing gacutil" 오류 발생
11645정성태8/8/20182615오류 유형: 474. 닷넷 COM+ - Failed to load the runtime. [1]
11644정성태8/8/20183262디버깅 기술: 118. windbg - 닷넷 개발자를 위한 MEX Debugging Extension 소개
11643정성태8/12/20183464사물인터넷: 20. 아두이노 레오나르도 R3 호환 보드의 3.3v 핀의 LED 전압/전류 테스트 [1]파일 다운로드1
11642정성태8/3/20183451Graphics: 20. Unity - LightMode의 ForwardBase에 따른 _WorldSpaceLightPos0 값 변화
11641정성태8/3/20184927Graphics: 19. Unity로 실습하는 Shader (10) - 빌보드 구현파일 다운로드1
11640정성태8/3/20183525Graphics: 18. Unity - World matrix(unity_ObjectToWorld)로부터 Position, Rotation, Scale 값을 복원하는 방법파일 다운로드1
11639정성태8/2/20182852디버깅 기술: 117. windbg - 덤프 파일로부터 추출한 DLL을 참조하는 방법
11638정성태8/2/20182260오류 유형: 473. windbg - 덤프 파일로부터 추출한 DLL 참조 시 "Resolved file has a bad image, no metadata, or is otherwise inaccessible." 빌드 오류
11637정성태8/1/20183287Graphics: 17. Unity - World matrix(unity_ObjectToWorld)로부터 TRS(이동/회전/크기) 행렬로 복원하는 방법파일 다운로드1
11636정성태8/1/20185713Graphics: 16. 3D 공간에서 두 점이 이루는 각도 구하기파일 다운로드1
... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...