Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
 

.NET Array는 왜 12 bytes 의 기본 메모리를 점유할까?

지난 번 글을 살펴보면서, System.Char [] 개체가 기본적으로 12 바이트의 크기를 점유하는 것을 확인했습니다.

StringBuilder 에서의 OutOfMemoryException 오류 원인 분석
; https://www.sysnet.pe.kr/2/0/1171

그냥 숫자를 맞추려고 그랬던 것인지... 아니면 실제로 12 bytes를 점유하고 있는지 어디 확인해 볼까요? ^^




예제는, 지난 번 상황을 그대로 이어가겠습니다.

0:000> .loadby sos clr

0:000> !dumpheap -stat
total 0 objects
Statistics:
      MT    Count    TotalSize Class Name
79ba6524        1           12 System.Nullable`1[[System.Boolean, mscorlib]]
79ba5938        1           12 System.Collections.Generic.ObjectEqualityComparer`1[[System.Type, mscorlib]]
79ba4b44        1           12 System.Security.Permissions.ReflectionPermission
79ba0e48        1          112 System.AppDomain
... [생략] ...
79ba28b8       49         2248 System.Int32[]
79b9f92c      699        28864 System.String
79b56ba8      873        45644 System.Object[]
79b9faf8   105054      2941512 System.Text.StringBuilder
79ba1d08   105075   1681842372 System.Char[]
Total 213250 objects

우선, 그 12 bytes가 혹시 Array 자체가 소유한 인스턴스 필드 때문에 발생한 것이 아닐까요? 이를 확인하려면 .NET Reflector 를 통해서 추적하는 것이 가능하지만, 기왕에 windbg 명령어를 익힐 겸 Method Table 주소에서 찾아가는 방법을 설명해 보겠습니다.

위의 "dumpheap" 결과에서 출력된 "System.Char[]" 의 "MT(Method Table)" 값을 이용하여 "EEClass"를 알아낼 수 있습니다. EEClass는 .NET Reflection 의 Type 정보와 유사하다고 생각하시면 됩니다.

0:000> !dumpmt 79ba1d08   
EEClass:      798d9878
Module:       79881000
Name:         System.Char[]
mdToken:      02000000
File:         C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
BaseSize:        0xc
ComponentSize:   0x2
Slots in VTable: 28
Number of IFaces in IFaceMap: 6

BaseSize == 0xc (12) 로 설정된 것으로 보아 "System.Char[]" 개체 하나에 12 바이트를 소비하는 것은 맞는 것 같습니다. 이제 클래스 자체를 검사해 보면,

0:000> !DumpClass 798d9878
Class Name:      System.Char[]
mdToken:         02000000
File:            C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Parent Class:    798d8ad8
Module:          79881000
Method Table:    79ba1d08
Vtable Slots:    18
Total Method Slots:  1c
Class Attributes:    2101  
Transparency:        Transparent
NumInstanceFields:   0
NumStaticFields:     0

보시는 바와 같이 Instance Fields 가 0 이므로, 그 자체의 메모리 소비는 없습니다. 그럼, 혹시 상속받은 것이 아닐까요? 이를 알아보기 위해 "Parent Class"를 다시 찾아보면,

0:000> !DumpClass 798d8ad8
Class Name:      System.Array
mdToken:         02000031
File:            C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Parent Class:    79883ef8
Module:          79881000
Method Table:    79b9f75c
Vtable Slots:    18
Total Method Slots:  3b
Class Attributes:    102081  Abstract, 
Transparency:        Transparent
NumInstanceFields:   0
NumStaticFields:     0

아하~~~ 익히 알고 있던 데로 "System.Char[]" 개체가 System.Array 를 상속받아 처리된 것이군요. 게다가 System.Array 역시 Instance Fields == 0 이고, 다시 한번 상위 클래스로 이동해 보겠습니다.

0:000> !DumpClass 79883ef8
Class Name:      System.Object
mdToken:         02000002
File:            C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Parent Class:    00000000
Module:          79881000
Method Table:    79b9f568
Vtable Slots:    4
Total Method Slots:  a
Class Attributes:    102001  
Transparency:        Transparent
NumInstanceFields:   0
NumStaticFields:     0

System.Object 까지 거슬러 왔고, Parent Class == 00000000 인 것으로 보아 최상위 개체입니다. 물론, Instance Fields == 0 이므로 역시 자체적으로 할당된 메모리는 없습니다.




12 바이트 영역에는 그럼 어떤 값들이 채워져 있을까요? 이를 확인하기 위해 메모리의 값을 쉽게 판단할 수 있는 '문자열'을 선택해보겠습니다.

0:000> !dumpheap -mt 79ba1d08 <== 값 79ba1d08 은 "System.Char []" 의 MT 값
 Address       MT     Size
...[생략]...
7e106c78 79ba1d08       24     
7e106e8c 79ba1d08       24     
7e10706c 79ba1d08       24     
7e107694 79ba1d08      524     
7e1078f0 79ba1d08       44     
7e107938 79ba1d08       44     
7e107b7c 79ba1d08      272     
7e108260 79ba1d08      272     
7e108884 79ba1d08      100     
7e108934 79ba1d08      100     
7e108e08 79ba1d08      156     
7e1090ac 79ba1d08       16     
7e1090d8 79ba1d08      524     
7e109558 79ba1d08       12     
7e109564 79ba1d08     1588     
7e109bb0 79ba1d08       16     
7e109bc0 79ba1d08      176     
total 0 objects
Statistics:
      MT    Count    TotalSize Class Name
79ba1d08   105213   1684052028 System.Char[]
Total 105213 objects

오호... 마침 12 바이트 짜리가 눈에 띄는데요. do(DumpObject) 명령어를 내려서 살펴보면,

0:000> !do 7e109558
Name:        System.Char[]
MethodTable: 79ba1d08
EEClass:     798d9878
Size:        12(0xc) bytes
Array:       Rank 1, Number of elements 0, Type Char
Element Type:System.Char
Content:     
Fields:
None

요소가 하나도 없는데도 12 바이트를 차지하고 있으니, 다시 한번 증명이 되고 있습니다. 그 다음, 44 바이트를 점유하고 있는 문자열을 선택해 볼까요? 계산대로라면 (44 - 12) / 2 (unicode) = 16 글자를 포함하고 있을 텐데요. DumpObject 역시 동일하게 결과를 출력해 주고 있습니다.

0:000> !do 7e1078f0
Name:        System.Char[]
MethodTable: 79ba1d08
EEClass:     798d9878
Size:        44(0x2c) bytes
Array:       Rank 1, Number of elements 16, Type Char
Element Type:System.Char
Content:     mscorlib.resourc
Fields:
None

나아가서, DumpObject 명령어로 정제된 출력결과가 아닌 메모리 상의 Raw 데이터를 한번 확인해 보겠습니다. 이를 위해 windbg 의 "View" / "Memory (Alt+5)" 를 선택해서 직접 Object 의 주소 값을 입력해 44 바이트 까지의 값을 확인해 보면 다음과 같이 나옵니다.

dump_array_1.png

7e1078f0 08 1d ba 79 10 00 00 00 6d 00 73 00 63 00 6f 00 72 00 6c 00 69 00 62  ...y....m.s.c.o.r.l.i.b
7e107907 00 2e 00 72 00 65 00 73 00 6f 00 75 00 72 00 63 00 00 00 00 00        ...r.e.s.o.u.r.c.....

색상별로 분리하면 "mscorlib.resourc" 문자열에 해당하는 값을 제외하고 앞단에 8바이트, 뒷단에 4바이트가 배치된 것을 알 수 있습니다.

08 1d ba 79 10 00 00 00   ...y....
6d 00 73 00 63 00 6f 00   72 00 6c 00 69 00 62 00 2e 00 72 00 65 00 73 00 6f 00 75 00 72 00 63 00    m.s.c.o.r.l.i.b...r.e.s.o.u.r.c
00 00 00 00               ....

부가적인 바이트들을 4 바이트로 나눠서 살펴보면 2개 정도는 의미가 드러납니다.

08 1d ba 79 ==> 0x79ba1d08 (MethodTable)
10 00 00 00 ==> 0x00000010 (배열 요소 크기?)
나머지 32 바이트는 문자열
00 00 00 00 ==> 0x00000000 (?)

0x79ba1d08 값은 워낙 특정하다 보니 MethodTable 값과 일치하는 것을 우연이라고 보기에는 어렵겠죠? 반면에 문자열 크기라고 계산된 0x00000010 값은 왠지 우연의 일치일 수 있으므로 다른 Char 배열을 하나 더 선정해서 확인해 보는 것이 좋겠습니다.

0:000> !do 7e10706c
Name:        System.Char[]
MethodTable: 79ba1d08
EEClass:     798d9878
Size:        22(0x16) bytes
Array:       Rank 1, Number of elements 5, Type Char
Element Type:System.Char
Content:     en-us
Fields:
None

7e10706c 08 1d ba 79 05 00 00 00 65 00 6e 00 2d 00 75 00 73 00 00 00 00 00  ...y....e.n.-.u.s.....

08 1d ba 79 ==> 0x79ba1d08 (MethodTable)
05 00 00 00 ==> 0x00000005 (5글자: 배열 요소 크기)
65 00 6e 00 2d 00 75 00 73 00 ==> e.n.-.u.s.
00 00 00 00 ==> 0x000000 (?)

아하... 이 정도면 확정적이군요. 그렇다면, 마지막의 "0x00000000" 4바이트 값은 무엇일까요? 사실 이것은 제가 잘못 계산한 것입니다. 관리 객체의 크기라고 나온 것은 0x7e10706c 포인터가 가리키는 주소로부터 계산하는 것이 아니고, 그것의 -4 바이트 옵셋에 위치한 Object Header를 포함한 크기이기 때문입니다. 따라서, 다음과 같이 계산하는 것이 맞습니다.

7e10706c 08 1d ba 79 05 00 00 00 65 00 6e 00 2d 00 75 00 73 00 00 00 00 00  ...y....e.n.-.u.s.....

xx xx xx xx ==> OBJECT HEADER (4바이트)
08 1d ba 79 ==> 0x79ba1d08 (MethodTable)
05 00 00 00 ==> 0x00000005 (5글자: 배열 요소 크기)
65 00 6e 00 2d 00 75 00 73 00 ==> e.n.-.u.s.




(변경 2017-10-25: *** 아래의 규칙은 현재 사용이 안 되는 것 같습니다. 즉, 요소의 타입에 대한 MethodTable을 따로 포함하지 않습니다. 혹시 이런 경우가 있다면 덧글 부탁드립니다.)

배열이라고 해서 모두 12 bytes 값이 점유되는 것은 아닙니다. 일례로 지난 번에 살펴 본 ".NET 타입에 대한 배열"의 경우에는 기본적으로 16 bytes 값을 소비합니다. 아래는, 직접 확인하기 위해 ConsoleApplication1.Program [] 에 대해 시도한 처리 결과를 보여주고 있습니다.

0:004> .loadby sos clr

0:004> ~0s
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll - 
eax=00000000 ebx=00000001 ecx=00000000 edx=00000000 esi=002dedf4 edi=00000000
eip=7762fd81 esp=002dedb0 ebp=002dee18 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!NtDelayExecution+0x15:
7762fd81 83c404          add     esp,4

0:000> !dso
PDB symbol for clr.dll not loaded
OS Thread Id: 0x1b2c (0)
ESP/REG  Object   Name
002DEF28 0254bf90 System.Object[]    (ConsoleApplication1.Program[])
002DEF2C 0254bf90 System.Object[]    (ConsoleApplication1.Program[])
002DEF30 0254bf80 System.Object[]    (System.String[])
002DEFE4 0254bf80 System.Object[]    (System.String[])
002DF184 0254bf80 System.Object[]    (System.String[])
002DF1B8 0254bf80 System.Object[]    (System.String[])

0:000> !do 0254bf90 
Name:        System.Object[]
MethodTable: 72f86ba8
EEClass:     72d09688
Size:        16(0x10) bytes
Array:       Rank 1, Number of elements 0, Type CLASS
Element Type:ConsoleApplication1.Program
Fields:
None

0:000> dd 0254bf90 
0254bf90  72f86ba8 00000000 00193810 00000000
0254bfa0  00000000 00000000 00000000 00000000
0254bfb0  00000000 00000000 00000000 00000000
0254bfc0  00000000 00000000 00000000 00000000
0254bfd0  00000000 00000000 00000000 00000000
0254bfe0  00000000 00000000 00000000 00000000
0254bff0  00000000 00000000 00000000 00000000
0254c000  00000000 00000000 00000000 00000000

보시는 것처럼, 0254bf90 위치로부터 12바이트가 소비되고 나머지 4바이트는 OBJECT HEADER 크기입니다. 값의 의미는 다음과 같습니다.

xxxxxxxx: -4 옵셋에 위치한 OBJECT HEADER
72f86ba8: System.Object [] 형에 대한 MethodTable 값
00000000: 배열의 요소 수
00193810: ConsoleApplication.Program 타입에 대한 MethodTable 값

즉, 배열 자체의 타입은 System.Object[] 이지만 내부에 저장될 요소 - "Element Type" 정보도 함께 보관하고 있는 것입니다.





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

[연관 글]





[최초 등록일: ]
[최종 수정일: 10/25/2017 ]

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

비밀번호

댓글 쓴 사람
 



2013-12-30 12시17분
windbg에서 확인해 보는 관리 힙의 인스턴스 구조
; http://www.sysnet.pe.kr/2/0/1559
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12127정성태1/25/202031.NET Framework: 881. C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)파일 다운로드1
12126정성태1/25/202029.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
12125정성태1/24/202011VS.NET IDE: 141. IDE0019 - Use pattern matching
12124정성태1/24/202016VS.NET IDE: 140. IDE1006 - Naming rule violation: These words must begin with upper case characters: ...
12123정성태1/23/202038웹: 39. Google Analytics - gtag 함수를 이용해 페이지 URL 수정 및 별도의 이벤트 생성 방법
12122정성태1/22/202071.NET Framework: 879. C/C++의 UNREFERENCED_PARAMETER 매크로를 C#에서 우회하는 방법(IDE0060 - Remove unused parameter '...')파일 다운로드1
12121정성태1/24/202047VS.NET IDE: 139. Visual Studio - Error List: "Could not find schema information for the ..."파일 다운로드1
12120정성태1/20/202089.NET Framework: 878. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 네 번째 이야기(IL 코드로 직접 구현)파일 다운로드1
12119정성태1/17/202079디버깅 기술: 160. Windbg 확장 DLL 만들기 (3) - C#으로 만드는 방법
12118정성태1/17/202094개발 환경 구성: 466. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 세 번째 이야기
12117정성태1/15/202060디버깅 기술: 159. C# - 디버깅 중인 프로세스를 강제로 다른 디버거에서 연결하는 방법파일 다운로드1
12116정성태1/15/202064디버깅 기술: 158. Visual Studio로 디버깅 시 sos.dll 확장 명령어를 (비롯한 windbg의 다양한 기능을) 수행하는 방법
12115정성태1/14/202042디버깅 기술: 157. C# - PEB.ProcessHeap을 이용해 디버깅 중인지 확인하는 방법파일 다운로드1
12114정성태1/13/202098디버깅 기술: 156. C# - PDB 파일로부터 심벌(Symbol) 및 타입(Type) 정보 열거파일 다운로드3
12113정성태1/12/202067오류 유형: 590. Visual C++ 빌드 오류 - fatal error LNK1104: cannot open file 'atls.lib'
12112정성태1/12/202035오류 유형: 589. PowerShell - 원격 Invoke-Command 실행 시 "WinRM cannot complete the operation" 오류 발생
12111정성태1/12/202099디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification)
12110정성태1/12/202082디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례파일 다운로드1
12109정성태1/10/202028오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/202034오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
12107정성태1/10/2020119.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
12106정성태1/8/202088VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작
12105정성태1/8/202090디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
12104정성태1/9/2020194DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [2]
12103정성태1/12/2020140DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...