windbg - .NET string의 x86/x64 메모리 할당 구조
예전에 다음의 글에서,
string.GetHashCode는 hash 값을 cache 할까?
; https://www.sysnet.pe.kr/2/0/1152
string 객체의 heap 메모리 레이아웃에 대해 이야기했었는데요. x86에 이어 x64에 대해서도 정리해야 할 것 같아서 좀 더 내용을 보강해 기록해 둡니다. ^^
우선 값을 테스트하기 쉽게 예제 프로그램을 다음과 같이 만듭니다.
using System;
namespace ConsoleApp1
{
class Program
{
public string A = new string('a', 0);
public string B = new string('b', 1);
public string C = new string('c', 2);
public string D = new string('d', 3);
public string E = new string('e', 4);
public string F = new string('f', 5);
public string G = new string('g', 6);
public string H = new string('h', 7);
public string I = new string('i', 8);
public string J = new string('j', 9);
static void Main(string[] args)
{
Program pg = new Program();
Pass(pg);
}
private static void Pass(Program pg)
{
lock (pg.A)
lock (pg.B)
lock (pg.C)
lock (pg.D)
lock (pg.E)
lock (pg.F)
lock (pg.G)
lock (pg.H)
lock (pg.I)
lock (pg.J)
Console.ReadLine();
}
}
}
x86 빌드로 windbg에서 길이가 0인 A 필드의 값을 조사해 보겠습니다.
0:000> !DumpObj /d 033b1228
Name: System.String
MethodTable: 5c761d64
EEClass: 5c2ff624
Size: 14(0xe) bytes
File: C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String:
Fields:
MT Field Offset Type VT Attr Value Name
5c763c04 400026f 4 System.Int32 1 instance 0 m_stringLength
5c7627ac 4000270 8 System.Char 1 instance 0 m_firstChar
5c761d64 4000274 48 System.String 0 shared static Empty
>> Domain:Value 013b5778:NotInit <<
ThinLock owner 1 (013c48f0), Recursive 0
!do에 전달한 033b1228 값은 A 필드의 주솟값인데 그 크기가 14(0xe) 바이트라고 나옵니다. Size가
Object header를 포함한 크기이기 때문에 다음과 같이 해당 주솟값을 기준으로 -4를 하고, 0xe 바이트만큼 덤프하면 그것이 필드 A가 점유한 메모리가 됩니다.
0:000> db 033b1228-4 Le
033b1224 01 00 00 80 64 1d 76 5c-00 00 00 00 00 00 ....d.v\......
이를 분석하면 다음과 같이 해석할 수 있습니다.
01 00 00 80: Object Header
64 1d 76 5c: System.String 타입의 MethodTable 주소
00 00 00 00: m_stringLength
00 00 : null
그다음 메모리 주소까지 덤프를 해볼까요?
0:000> db 033b1228-4 Le+12
033b1224 01 00 00 80 64 1d 76 5c-00 00 00 00 00 00 00 00 ....d.v\........
033b1234 00 00 00 00 a0 21 76 5c-00 00 00 00 00 00 00 00 .....!v\........
위에 보는 바와 같이 033b1234 주소에는 또 다른 참조 객체가 저장된 듯한 패턴을 보이고 있습니다. 즉, String 객체를 저장한 14바이트 이후의 2바이트는 4바이트 정렬을 위해 패딩된 데이터인 것입니다. 그래서 다음과 같이 정리할 수 있습니다.
01 00 00 80: Object Header
64 1d 76 5c: System.String 타입의 MethodTable 주소
00 00 00 00: m_stringLength
00 00 : null
00 00 : 4바이트 정렬을 위한 패딩
문자를 한 개 담고 있는 B 필드의 값도 조사해 보겠습니다.
0:000> !DumpObj /d 033b30fc
Name: System.String
MethodTable: 5c761d64
EEClass: 5c2ff624
Size: 16(0x10) bytes
File: C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String: b
Fields:
MT Field Offset Type VT Attr Value Name
5c763c04 400026f 4 System.Int32 1 instance 1 m_stringLength
5c7627ac 4000270 8 System.Char 1 instance 62 m_firstChar
5c761d64 4000274 48 System.String 0 shared static Empty
>> Domain:Value 013b5778:NotInit <<
ThinLock owner 1 (013c48f0), Recursive 0
B 객체의 크기가 2바이트 늘어났는데 마찬가지로 다음과 같이 메모리 덤프를 해 확인할 수 있습니다.
0:000> db 033b30fc-4 L10
033b30f8 01 00 00 00 64 1d 76 5c-01 00 00 00 62 00 00 00 ....d.v\....b...
역시 각각의 필드의 의미는 다음과 같습니다.
01 00 00 00: Object Header
64 1d 76 5c: System.String 타입의 MethodTable 주소
01 00 00 00: m_stringLength
62 00 : 문자열(UTF-16)
00 00 : null
하지만 이번에는 2바이트 패딩이 필요없습니다. 왜냐하면 B 객체의 크기가 4바이트 정렬을 위한 공간을 꽉 차게 점유하고 있기 때문입니다. 실제로 다음 메모리 영역까지 덤프해 보면 곧바로 C 필드가 공간을 점유한 메모리 패턴을 확인할 수 있습니다.
0:000> db 033b30fc-4 L10+10
033b30f8 01 00 00 00 64 1d 76 5c-01 00 00 00 62 00 00 00 ....d.v\....b...
033b3108 01 00 00 00 64 1d 76 5c-02 00 00 00 63 00 63 00 ....d.v\....c.c.
그런데 여기서 잠깐 짚고 넘어갈 점이 있습니다. "
string.GetHashCode 는 hash 값을 cache 할까?" 글에서 GetHashCode가 (x86의 CPU 워드 크기인) 4바이트만큼 계산을 해도 정상적으로 동작할 수 있었던 것이 바로 위와 같은 메모리 할당 방식 때문입니다.
즉, 글자가 1개 있어도 2바이트를 점유하고 있으므로 null 문자 공간까지 합치면 4바이트가 되어 안전합니다. 설령, 글자가 없어도 null 문자 2바이트와 4바이트 메모리 정렬로 인한 패딩 2바이트가 자동으로 붙기 때문에 역시 안전하게 4바이트 씩 접근할 수 있는 것입니다. 당연하지만 문자 2개를 가진 필드 C에 대해서도 같은 계산 방식으로 메모리 레이아웃을 파악할 수 있습니다.
0:000> !DumpObj /d 033b310c
Name: System.String
MethodTable: 5c761d64
EEClass: 5c2ff624
Size: 18(0x12) bytes
File: C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String: cc
Fields:
MT Field Offset Type VT Attr Value Name
5c763c04 400026f 4 System.Int32 1 instance 2 m_stringLength
5c7627ac 4000270 8 System.Char 1 instance 63 m_firstChar
5c761d64 4000274 48 System.String 0 shared static Empty
>> Domain:Value 013b5778:NotInit <<
ThinLock owner 1 (013c48f0), Recursive 0
마찬가지로 점유 영역을 덤프해 보면,
0:000> db 033b310c-4 L12
033b3108 01 00 00 00 64 1d 76 5c-02 00 00 00 63 00 63 00 ....d.v\....c.c.
033b3118 00 00
이번에도 4바이트씩 데이터를 열람하는 것이 가능하도록 메모리 구성이 되어 있습니다.
01 00 00 00: Object Header
64 1d 76 5c: System.String 타입의 MethodTable 주소
02 00 00 00: m_stringLength
63 00 63 00: 문자열(UTF-16)
00 00 : null
물론 위에서 2바이트가 모자라지만 4바이트 정렬 규칙에 의해 마지막에 00 00 2바이트가 패딩되어 있는 것을 다음과 같이 확인할 수 있습니다.
0:000> db 033b310c-4 L12+e
033b3108 01 00 00 00 64 1d 76 5c-02 00 00 00 63 00 63 00 ....d.v\....c.c.
033b3118 00 00 00 00 01 00 00 00-64 1d 76 5c 03 00 00 00 ........d.v\....
x86에서의 규칙을 이해하면 x64 CLR에서 왜 string 객체가 다른 참조 객체에 비해 4바이트를 더 점유하고 있는지 그 이유를 알 수 있게 됩니다. 즉, x64에서는 CPU 워드 크기인 8바이트만큼 한꺼번에 문자들을 처리할 수 있도록 string 객체의 메모리 관리가 되고 있는 것입니다.
확인을 위해 같은 예제 코드를 x64로 빌드하고 역시 windbg로 살펴보겠습니다.
먼저 빈 문자열을 담은 A 필드는 다음과 같이 26바이트를 점유하고 있습니다.
0:000> !DumpObj /d 00000165bff21420
Name: System.String
MethodTable: 00007ffef8466948
EEClass: 00007ffef7d650e0
Size: 26(0x1a) bytes
File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String:
Fields:
MT Field Offset Type VT Attr Value Name
00007ffef8469288 400026f 8 System.Int32 1 instance 0 m_stringLength
00007ffef8467b00 4000270 c System.Char 1 instance 0 m_firstChar
00007ffef8466948 4000274 90 System.String 0 shared static Empty
>> Domain:Value 00000165be2e2840:NotInit <<
ThinLock owner 1 (00000165be311fe0), Recursive 0
역시 메모리 덤프를 하고,
0:000> db 00000165bff21420-8 L1a
00000165`bff21418 00 00 00 00 01 00 00 80-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff21428 00 00 00 00 00 00 00 00-00 00 ..........
개별적으로 분석해 보면 이렇게 나옵니다.
00 00 00 00 01 00 00 80: Object Header
48 69 46 f8 fe 7f 00 00: System.String 타입의 MethodTable 주소
00 00 00 00 : m_stringLength
00 00 : null
00 00 00 00 : 추가 4바이트 (8바이트 정렬을 위해!)
그런데 이상하지 않습니까? null 2바이트 문자와 함께 8바이트 정렬을 하려면 6바이트가 있어야 하는데 4바이트만 더 추가한 것입니다. 왜냐하면, 최소 4바이트만 추가해 주면 어차피 8바이트 메모리 정렬에 의해 다음 참조 객체까지 6바이트가 더 패딩이 되기 때문입니다. 실제로 메모리를 조금 더 덤프해 보면 다음과 같이 패딩된 데이터를 확인할 수 있습니다.
0:000> db 00000165bff21420-8 L1a+16
00000165`bff21418 00 00 00 00 01 00 00 80-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff21428 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000165`bff21438 00 00 00 00 00 00 00 00-40 70 46 f8 fe 7f 00 00 ........@pF.....
즉, 4바이트를 추가함으로써 8바이트 정렬의 경계를 언제나 넘어가게 되어 8바이트 패딩으로 인한 접근 공간이 확보되는 것입니다. 따라서, 항상 string 데이터를 접근할 때 8바이트 씩 한꺼번에 읽는 것이 가능합니다.
이해를 돕기 위해 문자가 1개 할당된 B 필드를 보겠습니다.
0:000> !DumpObj /d 00000165bff23e90
Name: System.String
MethodTable: 00007ffef8466948
EEClass: 00007ffef7d650e0
Size: 28(0x1c) bytes
File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String: b
Fields:
MT Field Offset Type VT Attr Value Name
00007ffef8469288 400026f 8 System.Int32 1 instance 1 m_stringLength
00007ffef8467b00 4000270 c System.Char 1 instance 62 m_firstChar
00007ffef8466948 4000274 90 System.String 0 shared static Empty
>> Domain:Value 00000165be2e2840:NotInit <<
ThinLock owner 1 (00000165be311fe0), Recursive 0
다음은 분석 결과입니다.
0:000> db 00000165bff23e90-8 L1c
00000165`bff23e88 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff23e98 01 00 00 00 62 00 00 00-00 00 00 00 ....b.......
00 00 00 00 01 00 00 00: Object Header
48 69 46 f8 fe 7f 00 00: System.String 타입의 MethodTable 주소
01 00 00 00 : m_stringLength
62 00 : 문자열
00 00 : null
00 00 00 00 : 추가 4바이트 (8바이트 정렬을 위해!)
이번에는 "62 00 00 00"과 "00 00 00 00" 추가 4바이트로 인해 문자열 접근을 8바이트로 한꺼번에 가져올 수 있습니다. 하지만 어차피 8바이트 정렬이 되어야 하기 때문에 이후 4바이트가 패딩됩니다.
0:000> db 00000165bff23e90-8 L1c+14
00000165`bff23e88 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff23e98 01 00 00 00 62 00 00 00-00 00 00 00 00 00 00 00 ....b...........
00000165`bff23ea8 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
2글자가 포함된 필드 C도 보겠습니다.
0:000> !DumpObj /d 00000165bff23eb0
Name: System.String
MethodTable: 00007ffef8466948
EEClass: 00007ffef7d650e0
Size: 30(0x1e) bytes
File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String: cc
Fields:
MT Field Offset Type VT Attr Value Name
00007ffef8469288 400026f 8 System.Int32 1 instance 2 m_stringLength
00007ffef8467b00 4000270 c System.Char 1 instance 63 m_firstChar
00007ffef8466948 4000274 90 System.String 0 shared static Empty
>> Domain:Value 00000165be2e2840:NotInit <<
ThinLock owner 1 (00000165be311fe0), Recursive 0
분석 결과,
0:000> db 00000165bff23eb0-8 L1e
00000165`bff23ea8 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff23eb8 02 00 00 00 63 00 63 00-00 00 00 00 00 00 ....c.c.......
00 00 00 00 01 00 00 00: Object Header
48 69 46 f8 fe 7f 00 00: System.String 타입의 MethodTable 주소
02 00 00 00 : m_stringLength
63 00 63 00 : 문자열
00 00 : null
00 00 00 00 : 추가 4바이트 (8바이트 정렬을 위해!)
이번에도 역시 문자열을 8바이트 단위로 한꺼번에 접근할 수 있습니다. "63 00 63 00" 4바이트에 "00 00" null 2바이트와 무조건 추가한 4바이트 중 앞의 2바이트로 인해 8바이트 접근이 안전하게 됩니다. 그리고 전체 데이터의 8바이트 정렬을 위해 2바이트가 패딩됩니다.
0:000> db 00000165bff23eb0-8 L1e+12
00000165`bff23ea8 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff23eb8 02 00 00 00 63 00 63 00-00 00 00 00 00 00 00 00 ....c.c.........
00000165`bff23ec8 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
마지막으로 3개의 글자를 가진 필드 D도 보겠습니다.
0:000> !DumpObj /d 00000165bff23ed0
Name: System.String
MethodTable: 00007ffef8466948
EEClass: 00007ffef7d650e0
Size: 32(0x20) bytes
File: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String: ddd
Fields:
MT Field Offset Type VT Attr Value Name
00007ffef8469288 400026f 8 System.Int32 1 instance 3 m_stringLength
00007ffef8467b00 4000270 c System.Char 1 instance 64 m_firstChar
00007ffef8466948 4000274 90 System.String 0 shared static Empty
>> Domain:Value 00000165be2e2840:NotInit <<
ThinLock owner 1 (00000165be311fe0), Recursive 0
같은 방식으로 분석하고,
0:000> db 00000165bff23ed0-8 L20
00000165`bff23ec8 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff23ed8 03 00 00 00 64 00 64 00-64 00 00 00 00 00 00 00 ....d.d.d.......
00 00 00 00 01 00 00 00: Object Header
48 69 46 f8 fe 7f 00 00: System.String 타입의 MethodTable 주소
03 00 00 00 : m_stringLength
64 00 64 00-64 00 : 문자열
00 00 : null
00 00 00 00 : 추가 4바이트 (어차피 8바이트 정렬을 이끌기 위해서도 점유할 공간이었음)
"64 00 64 00 64 00 00 00"까지 8바이트 단위 접근이 가능했습니다. 추가 4바이트를 붙이지 않아도 되지만, 어차피 전체 데이터의 8바이트 정렬을 위해 4바이트를 점유해도 상관없으므로 일관된 규칙으로 4바이트를 무조건 객체 데이터 공간으로 넣은 것입니다. 물론 대신 이번에는 별도의 패딩 공간이 필요하지 않습니다.
0:000> db 00000165bff23ed0-8 L20+10
00000165`bff23ec8 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
00000165`bff23ed8 03 00 00 00 64 00 64 00-64 00 00 00 00 00 00 00 ....d.d.d.......
00000165`bff23ee8 00 00 00 00 01 00 00 00-48 69 46 f8 fe 7f 00 00 ........HiF.....
즉, 언제나/무조건 4바이트 추가 영역을 넣음으로써 문자열 데이터를 8바이트 씩 접근하는 것을 보장해 줍니다.
참고로 검색해 보면 제 글과는 다른 관점으로 다룬 글이 나옵니다.
Of memory and strings
; https://codeblog.jonskeet.uk/2011/04/05/of-memory-and-strings/
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]