Microsoft MVP성태의 닷넷 이야기
.NET Framework: 400. 눈으로 확인하는 LayoutKind 옵션 효과 [링크 복사], [링크+제목 복사],
조회: 33612
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)
(시리즈 글이 2개 있습니다.)
.NET Framework: 400. 눈으로 확인하는 LayoutKind 옵션 효과
; https://www.sysnet.pe.kr/2/0/1558

닷넷: 2250. PInvoke 호출 시 참조 타입(class)을 마샬링하는 [IN], [OUT] 특성
; https://www.sysnet.pe.kr/2/0/13609




눈으로 확인하는 LayoutKind 옵션 효과

와~~~ ^^ 재미있는 거 하나 또 배웠습니다. ^^

[제목] 객체의 메모리 레이아웃에 대하여
; http://www.csharpstudy.com/network/DevNote/Article/1009

이에 대해 제가 미진하게 테스트해서 올린 글이 있었는데요.

LayoutKind 옵션에 대해
; https://www.sysnet.pe.kr/2/0/1557

이 글에 대해 원글 저자이신 Alex님이 덧글을 달아주셨고 그래서 다시 정리해서 이렇게 글을 남깁니다. ^^




"[제목] 객체의 메모리 레이아웃에 대하여" 글에서 소개한 다음의 내용을 직접 확인하는 방법을 알아보겠습니다.

Sequential Layout은 Managed Memory에서 마샬링을 사용해 Unmanaged Memory로 옮길 때 각 필드의 순서가 Unmanaged Memory에서 유지되는 레이아웃이다. 위의 예제에서 MyStruct 구조체는 [StructLayout(LayoutKind.Sequential)]을 사용하고 있는데, 이는 Managed 메모리 영역에서는 순서가 어떨지 모르지만, Unmanaged Memory로 옮겨질 때는 반드시 필드 순서대로 데이타가 옮겨진다는 것을 의미한다.


즉, 위의 글에 따라 LayoutKind 옵션을 정리하면 다음과 같은 식입니다.

Layout 관리 메모리 필드 위치 보장 비관리 메모리 필드 위치 보장
Auto X X
Sequential X O
Explicit O O

그럼 이 옵션들이 실제로 그렇게 동작하는지 이제 확인해 보겠습니다. ^^

테스트 예제는 다음과 같이 구성해 보았습니다.

using System;
using System.Runtime.InteropServices;

namespace ConsoleApplication1
{
    [StructLayout(LayoutKind.Auto)]
    class MyClassA
    {
        public int i = 1;
        public string s = "2";
        public double d = 2;
        public byte b = 3;
    }

    [StructLayout(LayoutKind.Sequential, Pack = 1)] 
    class MyClassB
    {
        public int i = 1;
        [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 16)]
        public string s = "2";
        public double d = 3;
        public byte b = 4;
    }

    [StructLayout(LayoutKind.Explicit, Pack = 1)]
    class MyClassC
    {
        [FieldOffset(0)]
        public int i = 1;
        [FieldOffset(4)]
        [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 16)]
        public string s = "2";
        [FieldOffset(4 + 16)]
        public double d = 3;
        [FieldOffset(4 + 16 + 8)]
        public byte b = 4;
    }

    class Program
    {
        static void Main(string[] args)
        {
            MyClassA var1 = new MyClassA();
            MyClassB var2 = new MyClassB();
            MyClassC var3 = new MyClassC();

            Console.ReadLine();
        }
    }
}

windbg를 이용해 3개의 객체가 어떤 레이아웃으로 관리 힙에 할당되어 있는지 보려면 다음과 같은 명령어 과정을 거치면 됩니다.

0:006> .loadby sos clr

0:000> !name2ee *!ConsoleApplication1.MyClassA
Module:      720c1000
Assembly:    mscorlib.dll
--------------------------------------
Module:      007f2ed4
Assembly:    ConsoleApplication1.exe
Token:       02000002
MethodTable: 007f38b4
EEClass:     007f13ac
Name:        ConsoleApplication1.MyClassA

0:004> !dumpheap -mt 007f38b4
 Address       MT     Size
02492508 007f38b4       28     

Statistics:
      MT    Count    TotalSize Class Name
007f38b4        1           28 ConsoleApplication1.MyClassA
Total 1 objects

0:004> !dumpobj 02492508
Name:        ConsoleApplication1.MyClassA
MethodTable: 007f38b4
EEClass:     007f13ac
Size:        28(0x1c) bytes
File:        d:\...\bin\Debug\ConsoleApplication1.exe
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
724d3c50  4000001       10         System.Int32  1 instance        1 i
724d2300  4000002        c        System.String  0 instance 02492524 s
724cb5a0  4000003        4        System.Double  1 instance 2.000000 d
724d36b4  4000004       14          System.Byte  1 instance        3 b

보시는 바와 같이 Auto 레이아웃의 MyClassA는 관리 힙에 할당된 필드의 메모리 순서가 제멋대로입니다. 이런 식으로 MyClassB, MyClassC를 확인하면 다음과 같습니다.

0:004> !dumpobj 02492534 
Name:        ConsoleApplication1.MyClassB
MethodTable: 007f394c
EEClass:     007f1400
Size:        28(0x1c) bytes
File:        d:\...\bin\Debug\ConsoleApplication1.exe
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
724d3c50  4000005       10         System.Int32  1 instance        1 i
724d2300  4000006        c        System.String  0 instance 02492524 s
724cb5a0  4000007        4        System.Double  1 instance 3.000000 d
724d36b4  4000008       14          System.Byte  1 instance        4 b

0:004> !dumpobj 02492550 
Name:        ConsoleApplication1.MyClassC
MethodTable: 007f39e4
EEClass:     007f14c8
Size:        40(0x28) bytes
File:        d:\...\bin\Debug\ConsoleApplication1.exe
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
724d3c50  4000009        4         System.Int32  1 instance        1 i
724d2300  400000a        8        System.String  0 instance 02492524 s
724cb5a0  400000b       18        System.Double  1 instance 3.000000 d
724d36b4  400000c       20          System.Byte  1 instance        4 b

이 정도면 관리 메모리에서의 필드 배치 검증은 되었겠죠! ^^




그럼, 비관리 메모리로 마샬링되었을 때의 필드 배치는 어떤 방법을 통해서 알 수 있을까요?

간단하게 Marshal.StructureToPtr 메서드를 이용하면 가능합니다. 따라서 이전 예제에서 다음과 같은 코드를 추가해 주면 됩니다.

int sizeofA = Marshal.SizeOf(var1);
int sizeofB = Marshal.SizeOf(var2);
int sizeofC = Marshal.SizeOf(var3);

IntPtr ptrA = Marshal.AllocCoTaskMem(sizeofA);
Marshal.StructureToPtr(var1, ptrA, false);

IntPtr ptrB = Marshal.AllocCoTaskMem(sizeofB);
Marshal.StructureToPtr(var2, ptrB, false);

IntPtr ptrC = Marshal.AllocCoTaskMem(sizeofC);
Marshal.StructureToPtr(var3, ptrC, false);

그런데, 이 예제를 실행시키면 2군데에서 런타임 오류가 발생합니다. MyClassA 타입의 경우 Auto Layout이 사용되었기 때문에 unmanaged 메모리로의 변환은 물론 크기까지도 가늠할 수 없기 때문에 Marshal.SizeOf 및 StructureToPtr 메서드에서 각각 다음과 같은 오류가 발생합니다.

Unhandled Exception: System.ArgumentException: Type 'ConsoleApplication1.MyClassA' cannot be marshaled as an unmanaged structure; no meaningful size or offset can be computed.
at System.Runtime.InteropServices.Marshal.SizeOfHelper(Type t, Boolean throwIfNotMarshalable)
at System.Runtime.InteropServices.Marshal.SizeOf(Object structure) at ConsoleApplication1.Program.Main(String[] args) in d:\...\ConsoleApplication1\Program.cs:line 52


Unhandled Exception: System.ArgumentException: The specified structure must be blittable or have layout information.
Parameter name: structure
at System.Runtime.InteropServices.Marshal.InternalStructureToPtr(Object structure, IntPtr ptr, Boolean fDeleteOld)
at System.Runtime.InteropServices.Marshal.StructureToPtr(Object structure, IntPtr ptr, Boolean fDeleteOld) at ConsoleApplication1.Program.Main(String[] args) in d:\...\ConsoleApplication1\ConsoleApplication1\Program.cs:line 57


따라서 그 부분은 주석 처리를 하고 진행합니다. ^^ (말인즉, MyClassA는 비관리 메모리의 필드 배치를 확인할 수 없습니다.)

int sizeofA = 100; //Marshal.SizeOf(var1);
int sizeofB = Marshal.SizeOf(var2);
int sizeofC = Marshal.SizeOf(var3);

IntPtr ptrA = Marshal.AllocCoTaskMem(sizeofA);
// Marshal.StructureToPtr(var1, ptrA, false);

이제 Console.ReadLine 부근에 BP(BreakPoint)를 잡은 후 예제를 Visual Studio에서 실행하면 ptrB, ptrC의 주소에 직렬화된 객체의 필드 값들을 확인할 수 있습니다.

layoutkind_field_info_1.png

이를 통해 ptrB, ptrC의 값들을 하나씩 분석해 보면 다음과 같은 결과가 나옵니다.

== ptrB ==

0x006584A8  01 00 00 00 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ....2....................
0x006584C1  00 08 40 04 ab ab ab ab ab ab ab ab fe ee fe 00 00 00 00 00 00 00 00 f8 8b  ..@.???????????........??

01 00 00 00                                     : int 4bytes == 0x00000001
32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : TStr 16bytes == "2"
00 00 00 00 00 00 00 08 40                      : double 8bytes == 3 (부동 소수점 표현)
04                                              : byte 1byte == 4


== ptrC ==

0x00DAE988  01 00 00 00 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ....2....................
0x00DAE9A1  00 08 40 04 ab ab ab ab ab ab ab ab fe ee fe 00 00 00 00 00 00 00 00 9e 7e  ..@.???????????........?~

01 00 00 00                                     : int 4bytes == 0x00000001
32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : TStr 16bytes == "2"
00 00 00 00 00 00 00 08 40                      : double 8bytes == 3 (부동 소수점 표현)
04                                              : byte 1byte == 4

보시는 것처럼 MyClassB, MyClassC의 필드 배치가 정확하게 일치합니다. 따라서 Sequential, Explicit 유형의 클래스는 비관리 메모리에서 필드의 정의에 따른 위치가 그대로 보존됨을 알 수 있습니다.

이 때문에 일단 이런 식으로 직렬화된 클래스는 다음과 같이 C/C++에 전달하는 것도 가능합니다.

// ==== C++ Win32 DLL
#pragma pack(1)

typedef struct tagMyClassB
{
    int i;
    char s[16];
    double d;
    BYTE b;
} MyClassB;

typedef struct tagMyClassC
{
    int i;
    char s[16];
    double d;
    byte b;
} MyClassC;

WIN32PROJECT1_API void fnWin32Project1(MyClassB *ptr)
{
    printf("i: %d\n", ptr->i);
    printf("s: %S\n", ptr->s);
    printf("d: %lf\n", ptr->d);
    printf("b: %d\n\n", ptr->b);
}

WIN32PROJECT1_API void fnWin32Project2(MyClassC *ptr)
{
    printf("i: %d\n", ptr->i);
    printf("s: %S\n", ptr->s);
    printf("d: %lf\n", ptr->d);
    printf("b: %d\n\n", ptr->b);
}

using System;
using System.Runtime.InteropServices;

namespace ConsoleApplication1
{
    // ...[생략]...

    class Program
    {
        [DllImport("Win32Project1.dll", CallingConvention = CallingConvention.Cdecl)]
        static extern void fnWin32Project1(IntPtr cl);
        [DllImport("Win32Project1.dll", CallingConvention = CallingConvention.Cdecl)]
        static extern void fnWin32Project2(IntPtr cl);

        static void Main(string[] args)
        {
            MyClassA var1 = new MyClassA();
            MyClassB var2 = new MyClassB();
            MyClassC var3 = new MyClassC();

            // ...[생략]...

            fnWin32Project1(ptrB);
            fnWin32Project2(ptrC);

            Console.ReadLine();
        }
    }
}




(취소시킨) 아래의 글을 쓰면서 제가 가장 궁금했던 것은,

LayoutKind 옵션에 대해
; https://www.sysnet.pe.kr/2/0/1557

굳이 Sequential에서 관리/비관리 메모리의 구조가 다를 이유가 있었을까 하는 점입니다. 제가 생각하기에는 그것이 매우 비효율적인 작업이라고 여겼기 때문인데요. 이번 테스트를 통해서 오히려 그것이 효율적인 메모리 관리임을 알게 되었습니다.

MyClassB, MyClassC의 windbg 결과를 좀 더 살펴보면 왜 그것이 효율적인지에 대한 답이 나옵니다.

0:004> !name2ee *!ConsoleApplication1.MyClassB
Module:      720c1000
Assembly:    mscorlib.dll
--------------------------------------
Module:      00922ed4
Assembly:    ConsoleApplication1.exe
Token:       02000003
MethodTable: 0092394c
EEClass:     00921418
Name:        ConsoleApplication1.MyClassB

0:004> !dumpheap -mt 0092394c
 Address       MT     Size
025c25bc 0092394c       28     

Statistics:
      MT    Count    TotalSize Class Name
0092394c        1           28 ConsoleApplication1.MyClassB
Total 1 objects

위의 결과를 보면 Sequential로 지정된 MyClassB에 할당된 객체의 크기는 총 28바이트입니다. 반면 Explicit로 지정된 MyClassC에 할당된 객체의 크기는 40바이트로 나옵니다.

0:004> !name2ee *!ConsoleApplication1.MyClassC
Module:      720c1000
Assembly:    mscorlib.dll
--------------------------------------
Module:      00922ed4
Assembly:    ConsoleApplication1.exe
Token:       02000004
MethodTable: 009239e4
EEClass:     009214e0
Name:        ConsoleApplication1.MyClassC


0:004> !dumpheap -mt 009239e4
 Address       MT     Size
025c25d8 009239e4       40     

Statistics:
      MT    Count    TotalSize Class Name
009239e4        1           40 ConsoleApplication1.MyClassC
Total 1 objects

왜 이렇게 메모리 크기의 차이가 심하게 발생하는지 각각에 할당된 힙 메모리 사용을 한번 살펴볼까요? ^^

0:004> db 025c25bc 
025c25bc  4c 39 92 00 00 00 00 00-00 00 08 40 ac 25 5c 02  L9.........@.%\.
025c25cc  01 00 00 00 04 00 00 00-00 00 00 00 e4 39 92 00  .............9..
025c25dc  01 00 00 00 ac 25 5c 02-00 00 00 00 00 00 00 00  .....%\.........

4c 39 92 00             : 0x0092394c == MethodTable
00 00 00 00-00 00 08 40 : Offset 위치 0x04 - System.Double 값
ac 25 5c 02             : Offset 위치 0x0c - System.String의 힙 주소 == 0x025c25ac
01 00 00 00             : Offset 위치 0x10 - System.Int32 값
04 00 00 00             : Offset 위치 0x14 - System.Byte 값 (마지막 4바이트 정렬)

Sequential 형식의 MyClassB는 24바이트에 syncblock 4바이트까지 더해져 총 28바이트가 소비됩니다.

반면 Explicit 형식의 MyClassC는 중간에 쓸데없이 12바이트 영역의 메모리가 차지하게 됩니다.

0:004> db 025c25d8 
025c25d8  e4 39 92 00 01 00 00 00-ac 25 5c 02 00 00 00 00  .9.......%\.....
025c25e8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 08 40  ...............@
025c25f8  04 00 00 00 00 00 01 00-18 7d 4d 72 00 00 00 00  .........}Mr....

e4 39 92 00             : 0x009239e4 == MethodTable
01 00 00 00             : Offset 위치 0x04 - System.Int32 값
ac 25 5c 02             : Offset 위치 0x08 - System.String의 힙 주소 == 0x025c25ac
00 00 00 00 00 00 00 00 00 00 00 00 : Explicit로 인해 필요 없이 소비된 12바이트
00 00 00 00 00 00 08 40 : Offset 위치 0x18 - System.Double 값
04 00 00 00             : Offset 위치 0x20 - System.Byte 값 (마지막 4바이트 정렬)

즉, 관리 메모리와 비관리 메모리의 레이아웃을 맞추기 위해 Explicit는 오히려 관리 메모리의 저장 효율을 떨어뜨리고 있는 것입니다. 물론, 1:1로 매핑되기 때문에 비관리 메모리로의 복사는 빠를 것입니다.

이로 인해 결론이 정리되는군요. ^^

Layout 용도
Auto 비관리 메모리에 전달되지 않는 모든 닷넷 클래스
Sequential Offset 위치를 지정해야 할 특별한 이유가 없고, 마샬링 성능이 중요하지 않다면?
Explicit Offset 위치를 지정해야 하거나, 마샬링 성능이 중요한 경우

(첨부 파일은 위의 코드에 사용된 예제를 담고 있습니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2021]

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

비밀번호

댓글 작성자
 



2016-11-01 04시28분
[요원009] 맨 위에,
"보시는 바와 같이 Auto 레이아웃의 MyClassA는 관리 힙에 할당된 필드의 메모리 순서가 제멋대로입니다. 이런 식으로 MyClassB, MyClassC를 확인하면 다음과 같습니다."

라는 코멘트를 보면, MyClassA, B, C의 필드 메모리 순서가 똑같아 보이는데, 제가 잘못 이해한 건가요?
[guest]
2016-11-01 04시35분
Name 순을 보시면 안되고, 굵은 글씨체로 부각시킨 Offset 순서를 보셔야 합니다. Offset 내용이 10, c, 4, 14로 되어 있는데, 따라서 메모리상의 순서는 d, s, i, b가 됩니다.
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13917정성태4/30/202544VS.NET IDE: 199. Directory.Build.props에 정의한 속성에 대해 Condition 제약으로 값을 변경하는 방법
13916정성태4/23/2025446디버깅 기술: 221. WinDbg 분석 사례 - ASP.NET HttpCookieCollection을 다중 스레드에서 사용할 경우 무한 루프 현상 - 두 번째 이야기
13915정성태4/13/20251652닷넷: 2331. C# - 실행 시에 메서드 가로채기 (.NET 9)파일 다운로드1
13914정성태4/11/20251970디버깅 기술: 220. windbg 분석 사례 - x86 ASP.NET 웹 응용 프로그램의 CPU 100% 현상 (4)
13913정성태4/10/20251204오류 유형: 950. Process Explorer - 64비트 윈도우에서 32비트 프로세스의 덤프를 뜰 때 "Error writing dump file: Access is denied." 오류
13912정성태4/9/2025863닷넷: 2330. C# - 실행 시에 메서드 가로채기 (.NET 5 ~ .NET 8)파일 다운로드1
13911정성태4/8/20251091오류 유형: 949. WinDbg - .NET Core/5+ 응용 프로그램 디버깅 시 sos 확장을 자동으로 로드하지 못하는 문제
13910정성태4/8/20251257디버깅 기술: 219. WinDbg - 명령어 내에서 환경 변수 사용법
13909정성태4/7/20251725닷넷: 2329. C# - 실행 시에 메서드 가로채기 (.NET Framework 4.8)파일 다운로드1
13908정성태4/2/20252138닷넷: 2328. C# - MailKit: SMTP, POP3, IMAP 지원 라이브러리
13907정성태3/29/20251933VS.NET IDE: 198. (OneDrive, Dropbox 등의 공유 디렉터리에 있는) C# 프로젝트의 출력 경로 변경하기
13906정성태3/27/20252190닷넷: 2327. C# - 초기화되지 않은 메모리에 접근하는 버그?파일 다운로드1
13905정성태3/26/20252220Windows: 281. C++ - Windows / Critical Section의 안정화를 위해 도입된 "Keyed Event"파일 다운로드1
13904정성태3/25/20251902디버깅 기술: 218. Windbg로 살펴보는 Win32 Critical Section파일 다운로드1
13903정성태3/24/20251522VS.NET IDE: 197. (OneDrive, Dropbox 등의 공유 디렉터리에 있는) C++ 프로젝트의 출력 경로 변경하기
13902정성태3/24/20251737개발 환경 구성: 742. Oracle - 테스트용 hr 계정 및 데이터 생성파일 다운로드1
13901정성태3/9/20252112Windows: 280. Hyper-V의 3가지 Thread Scheduler (Classic, Core, Root)
13900정성태3/8/20252346스크립트: 72. 파이썬 - SQLAlchemy + oracledb 연동
13899정성태3/7/20251806스크립트: 71. 파이썬 - asyncio의 ContextVar 전달
13898정성태3/5/20252124오류 유형: 948. Visual Studio - Proxy Authentication Required: dotnetfeed.blob.core.windows.net
13897정성태3/5/20252367닷넷: 2326. C# - PowerShell과 연동하는 방법 (두 번째 이야기)파일 다운로드1
13896정성태3/5/20252178Windows: 279. Hyper-V Manager - VM 목록의 CPU Usage 항목이 항상 0%로 나오는 문제
13895정성태3/4/20252220Linux: 117. eBPF / bpf2go - Map에 추가된 요소의 개수를 확인하는 방법
13894정성태2/28/20252250Linux: 116. eBPF / bpf2go - BTF Style Maps 정의 구문과 데이터 정렬 문제
13893정성태2/27/20252197Linux: 115. eBPF (bpf2go) - ARRAY / HASH map 기본 사용법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...