Microsoft MVP성태의 닷넷 이야기
.NET Framework: 695. windbg - .NET string의 x86/x64 메모리 할당 구조 [링크 복사], [링크+제목 복사]
조회: 3607
글쓴 사람
홈페이지
첨부 파일
 

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/




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

[연관 글]





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

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)
11402정성태12/16/201714411.NET Framework: 707. OpenCV 응용 프로그램을 C#으로 구현 - OpenCvSharp [2]파일 다운로드1
11401정성태12/15/20176565.NET Framework: 706. C# - SharpDX + DXGI를 이용한 윈도우 화면 캡처 소스 코드 + Direct2D 출력파일 다운로드1
11400정성태12/14/20176515.NET Framework: 705. C# - SharpDX + DXGI를 이용한 윈도우 화면 캡처 소스 코드 [3]파일 다운로드1
11399정성태12/13/20172830.NET Framework: 704. Win32 API의 UnionRect를 닷넷 BCL의 Rectangle.Union으로 바꿀 때 주의 사항
11398정성태12/13/20173295오류 유형: 442. ASP.NET Core Web Application (on .NET Framework) 프로젝트에서 외부 라이브러리 동적 로드 시 런타임 버전 문제파일 다운로드1
11397정성태12/12/20174483.NET Framework: 703. 양자 컴퓨팅을 위한 마이크로소프트의 Q# 언어
11396정성태12/8/201714853개발 환경 구성: 343. Visual Studio - 리눅스 용 프로젝트의 인텔리센스를 위한 헤더 파일 처리 방법 [3]
11395정성태12/8/20173370오류 유형: 441. 이벤트 로그 - Time Provider NtpClient: No valid response has been received from domain controller
11394정성태12/8/20173157개발 환경 구성: 342. 비주얼 스튜디오에서 실행하던 ASP.NET Core (.NET Framework) 응용 프로그램을 명령행에서 실행하는 방법
11393정성태12/7/20174858Windows: 145. 윈도우 10 빌드 17046부터 WSL에서 백그라운드 작업 지원 [3]
11392정성태12/7/20172468개발 환경 구성: 341. openSUSE에 닷넷 코어 설치
11391정성태12/7/20173171개발 환경 구성: 340. WSL을 이용해 윈도우 PC 1대에서 openSUSE 응용 프로그램을 Visual Studio로 개발하는 방법 [1]
11390정성태12/7/20179118개발 환경 구성: 339. WSL을 이용해 윈도우 PC 1대에서 Linux 응용 프로그램을 Visual Studio로 개발하는 방법 [3]
11389정성태12/7/20173004오류 유형: 440. .NET Core 오류 - 0x80131620 Unable to load DLL 'libuv'
11388정성태10/4/20184708개발 환경 구성: 338. WSL 또는 Ubuntu에 닷넷 코어 설치 [2]
11387정성태12/6/20174643오류 유형: 439. 이벤트 로그 - Data Sharing Service 서비스의 %%3239247874 오류 메시지
11386정성태12/5/20173096오류 유형: 438. Hyper-V - '...' failed to add device 'Virtual CD/DVD Disk'
11385정성태12/14/20178052VC++: 121. DXGI를 이용한 윈도우 화면 캡처 소스 코드(Visual C++) [3]파일 다운로드1
11384정성태12/5/20174098오류 유형: 437. Visual C++ - Cannot open include file: 'SDKDDKVer.h'
11383정성태9/18/20194289디버깅 기술: 110. 비동기 코드 실행 중 예외로 인한 ASP.NET 프로세스 비정상 종료 현상 [1]
11382정성태12/4/20175388오류 유형: 436. System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired 예외 발생 시 "[Pre-Login] initialization=48; handshake=1944;" 값의 의미
11381정성태11/30/20173171.NET Framework: 702. 한글이 포함된 바이트 배열을 나눈 경우 한글이 깨지지 않도록 다시 조합하는 방법(두 번째 이야기)파일 다운로드1
11380정성태11/30/20173757디버깅 기술: 109. windbg - (x64에서의 인자 값 추적을 이용한) Thread.Abort 시 대상이 되는 스레드를 식별하는 방법
11379정성태11/30/20172977오류 유형: 435. System.Web.HttpException - Session state has created a session id, but cannot save it because the response was already flushed by the application.
11378정성태11/29/20174585.NET Framework: 701. 한글이 포함된 바이트 배열을 나눈 경우 한글이 깨지지 않도록 다시 조합하는 방법 [1]파일 다운로드1
11377정성태11/29/20174240.NET Framework: 700. CommonOpenFileDialog 사용 시 사용자가 선택한 파일 목록을 구하는 방법 [3]파일 다운로드1
... 31  32  33  34  [35]  36  37  38  39  40  41  42  43  44  45  ...