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

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)
11384정성태12/5/20174225오류 유형: 437. Visual C++ - Cannot open include file: 'SDKDDKVer.h'
11383정성태9/18/20194415디버깅 기술: 110. 비동기 코드 실행 중 예외로 인한 ASP.NET 프로세스 비정상 종료 현상 [1]
11382정성태12/4/20175573오류 유형: 436. System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired 예외 발생 시 "[Pre-Login] initialization=48; handshake=1944;" 값의 의미
11381정성태11/30/20173278.NET Framework: 702. 한글이 포함된 바이트 배열을 나눈 경우 한글이 깨지지 않도록 다시 조합하는 방법(두 번째 이야기)파일 다운로드1
11380정성태11/30/20173831디버깅 기술: 109. windbg - (x64에서의 인자 값 추적을 이용한) Thread.Abort 시 대상이 되는 스레드를 식별하는 방법
11379정성태11/30/20173079오류 유형: 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/20174661.NET Framework: 701. 한글이 포함된 바이트 배열을 나눈 경우 한글이 깨지지 않도록 다시 조합하는 방법 [1]파일 다운로드1
11377정성태11/29/20174333.NET Framework: 700. CommonOpenFileDialog 사용 시 사용자가 선택한 파일 목록을 구하는 방법 [3]파일 다운로드1
11376정성태11/28/20174724VS.NET IDE: 123. Visual Studio 편집기의 \r\n (crlf) 개행을 \n으로 폴더 단위로 설정하는 방법
11375정성태11/28/20173023오류 유형: 434. Visual Studio로 ASP.NET 디버깅 중 System.Web.HttpException - Could not load type 오류
11374정성태8/9/20185489사물인터넷: 14. 라즈베리 파이 - (윈도우의 NT 서비스처럼) 부팅 시 시작하는 프로그램 설정
11373정성태7/16/20183960오류 유형: 433. Raspberry Pi/Windows 다중 플랫폼 지원 컴파일 관련 오류 기록
11372정성태10/2/20186969사물인터넷: 13. 윈도우즈 사용자를 위한 라즈베리 파이 제로 W 모델을 설정하는 방법 [3]
11371정성태11/25/20174366오류 유형: 432. Hyper-V 가상 스위치 생성 시 Failed to connect Ethernet switch port 0x80070002 오류 발생
11370정성태11/25/20173486오류 유형: 431. Hyper-V의 Virtual Switch 생성 시 "External network" 목록에 특정 네트워크 어댑터 항목이 없는 경우
11369정성태5/15/20204647사물인터넷: 12. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 키보드 및 마우스로 쓰는 방법 (절대 좌표, 상대 좌표, 휠) [1]
11368정성태11/25/20177484.NET Framework: 699. UDP 브로드캐스트 주소 255.255.255.255와 192.168.0.255의 차이점과 이를 고려한 C# UDP 서버/클라이언트 예제 [2]파일 다운로드1
11367정성태11/25/20177988개발 환경 구성: 337. 윈도우 운영체제의 route 명령어 사용법
11366정성태11/25/20174097오류 유형: 430. 이벤트 로그 - Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.
11365정성태11/25/20173077오류 유형: 429. 이벤트 로그 - User Policy could not be updated successfully
11364정성태8/9/20183776사물인터넷: 11. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스로 쓰는 방법 (절대 좌표) [2]
11363정성태8/9/20184266사물인터넷: 10. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스 + 키보드로 쓰는 방법 (두 번째 이야기)
11362정성태12/26/20194666오류 유형: 428. 윈도우 업데이트 KB4048953 - 0x800705b4 [2]
11361정성태11/22/20174694오류 유형: 427. 이벤트 로그 - Filter Manager failed to attach to volume '\Device\HarddiskVolume??' 0xC03A001C
11360정성태11/22/20176037오류 유형: 426. 이벤트 로그 - The kernel power manager has initiated a shutdown transition.
11359정성태11/16/20176082오류 유형: 425. 윈도우 10 Version 1709 (OS Build 16299.64) 업그레이드 시 발생한 문제 2가지
... 31  32  33  34  35  36  [37]  38  39  40  41  42  43  44  45  ...