C# - GCHandle 구조체의 메모리 분석
GCHandle을 역어셈블하면 다음과 같이 별다른 메모리 할당이 없지만,
// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
using System.Runtime.CompilerServices;
namespace System.Runtime.InteropServices
{
public partial struct GCHandle
{
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern IntPtr InternalAlloc(object? value, GCHandleType type);
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern void InternalFree(IntPtr handle);
#if DEBUG
// The runtime performs additional checks in debug builds
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern object? InternalGet(IntPtr handle);
#else
internal static unsafe object? InternalGet(IntPtr handle) =>
Unsafe.As<IntPtr, object>(ref *(IntPtr*)(nint)handle);
#endif
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern void InternalSet(IntPtr handle, object? value);
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern object? InternalCompareExchange(IntPtr handle, object? value, object? oldValue);
}
}
소스코드를 직접 찾아보면,
// https://github.com/microsoft/referencesource/blob/master/mscorlib/system/runtime/interopservices/gchandle.cs
namespace System.Runtime.InteropServices
{
// ...[생략]...
[StructLayout(LayoutKind.Sequential)]
[System.Runtime.InteropServices.ComVisible(true)]
public struct GCHandle
{
// ...[생략]...
// The actual integer handle value that the EE uses internally.
private IntPtr m_handle;
#if MDA_SUPPORTED
// The GCHandle cookie table.
static private volatile GCHandleCookieTable s_cookieTable = null;
static private volatile bool s_probeIsActive = false;
#endif
}
}
IntPtr 타입의 m_handle 필드를 하나 가지고 있습니다. windbg를 이용하면 좀 더 재미있는 사실들을 알 수 있는데요, 예를 들어, GCHandle로 다음과 같이 코드를 만들어,
using System.Runtime.InteropServices;
namespace ConsoleApp1;
internal class Program
{
static unsafe void Main(string[] args)
{
{
MyObject obj = new MyObject();
GCHandle gcHandle = GCHandle.Alloc(obj, GCHandleType.Pinned);
GCHandle* pHandle = &gcHandle;
Console.WriteLine($"{(nint)pHandle:x}");
fixed(int* pAge = &(obj.Age))
{
Console.WriteLine($"{(nint)pAge:x}");
}
Console.ReadLine();
gcHandle.Free();
}
}
}
public class MyObject
{
public int Age = 0;
}
실행하면 화면에는 이런 결과가 출력됩니다.
583bb7e8e0 // GCHandle의 스택 주소
1ee7640e100 // MyObject의 Age 필드가 위치한 힙 주소
이때 windbg를 붙여 GCHandle 정보를 살펴보면,
0:000> !name2ee System.Private.CoreLib.dll!System.Runtime.InteropServices.GCHandle
Module: 00007ff7b77d4000
Assembly: System.Private.CoreLib.dll
Token: 00000000020004FC
MethodTable: 00007ff7b7a8bcb0
EEClass: 00007ff7b7a72cf0
Name: System.Runtime.InteropServices.GCHandle
0:000> !DumpClass /d 00007ff7b7a72cf0
Class Name: System.Runtime.InteropServices.GCHandle
mdToken: 00000000020004FC
File: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.14\System.Private.CoreLib.dll
Parent Class: 00007ff7b77d0f88
Module: 00007ff7b77d4000
Method Table: 00007ff7b7a8bcb0
Vtable Slots: 5
Total Method Slots: 5
Class Attributes: 100109
NumInstanceFields: 1
NumStaticFields: 0
MT Field Offset Type VT Attr Value Name
00007ff7b7979270 40010ec 8 System.IntPtr 1 instance _handle
소스코드에서 봤던 바로 그 _handle 필드를 볼 수 있습니다. 아울러 화면에 출력된 GCHandle의 스택 주소를 이용해 그 값이 현재 무엇인지 덤프해 보면,
0:000> dq 583bb7e8e0 L1
00000058`3bb7e8e0 000001ee`736d15f1
...f1으로 1비트까지 설정된 주소를 가리키는, 아주 희한한 값이 나옵니다. 보통 64비트 시스템이면 8바이트 정렬일 것이고, 위의 경우 핸들이 추상화된 정보라는 것을 감안해도 정보를 담기 위해서는 적어도 1비트보다는 (보통은) 클 것이기 때문입니다. 확인을 위해 이 상태에서 gchandle 테이블을 나열해 보면,
0:000> !gchandles
Handle Type Object Size Data Type
000001EE736D1178 WeakShort 000001ee7641eaf0 40 System.Buffers.TlsOverPerCoreLockedStacksArrayPool`1[[System.Byte, System.Private.CoreLib]]
000001EE736D1180 WeakShort 000001ee76419320 72 System.Threading.Thread
...[생략]...
000001EE736D15F0 Pinned 000001ee7640e0f8 24 ConsoleApp1.MyObject
000001EE736D15F8 Pinned 000001ee76400200 24 System.Object
...[생략]...
원래 주소는 000001EE736D15F0임을 알 수 있습니다. 그러니까, 아마도 1비트가 표시된 것은 직접적인 메모리 주소라기보다는 어차피 8바이트 정렬이기 때문에 그 이하의 비트를 부가적인 정보를 보관하는 용도로 사용했을 거라는 추측을 할 수 있습니다. (실제로
윈도우 핸들의 경우 Lockbit 표시로 활용합니다.)
어쨌든, 000001ee`736d15f1의 실제 주소는 000001ee`736d15f0임을 알 수 있고, 해당 주소를 덤프해 보면 예상할 수 있는 그 값이 나옵니다.
0:000> dq 000001ee`736d15f0 L1
000001ee`736d15f0 000001ee`7640e0f8
000001ee`7640e0f8 값은 화면에 출력했던 MyObject의 Age 필드가 위치한 힙 주소(1ee7640e100)보다 정확히 0x08 앞에 위치한 값에 해당합니다. (왜냐하면
실제 데이터보다 앞선 MethodTable의 주소를 가리키기 때문입니다.)
정리해 보면, GCHandle 구조체는 Handle 테이블의 주소를 가리키고, 다시 그 핸들 테이블은 원래 개체에 대한 주소를 담고 있습니다.
참고로, GCHandle의 Pinning은 위의 코드에서처럼 명시적으로 사용하는 경우 외에도 JIT 컴파일러가 자동으로 Pinning하는 경우도 있습니다.
그 한 사례가 바로 코드에서 사용한 문자열 리터럴인데요, 간단하게 다음의 코드로 예를 들어 보면,
// (반드시) .NET 7 이하의 환경에서 빌드
namespace ConsoleApp2;
internal class Program
{
static void Main(string[] args)
{
Console.WriteLine(Program.Test());
Console.ReadLine();
}
public static string Test() => "Hello";
}
windbg에서 Program.Test 메서드의 jit 코드가 이렇게 나옵니다.
0:014> !name2ee ConsoleApp2!ConsoleApp2.Program.Test
Module: 00007ff83c8dcf50
Assembly: ConsoleApp2.dll
Token: 0000000006000007
MethodDesc: 00007ff83c8def50
Name: ConsoleApp2.Program.Test()
JITTED Code Address: 00007ff83c813bc0
0:014> !U /d 00007ff83c813bc0
Normal JIT generated code
ConsoleApp2.Program.Test()
ilAddr is 000001B28A1B20C1 pImport is 00000256A37FC0E0
Begin 00007FF83C813BC0, size 2d
c:\temp\ConsoleApp1\ConsoleApp2\Program.cs @ 13:
>>> 00007ff8`3c813bc0 55 push rbp
00007ff8`3c813bc1 57 push rdi
00007ff8`3c813bc2 56 push rsi
00007ff8`3c813bc3 4883ec20 sub rsp,20h
00007ff8`3c813bc7 488bec mov rbp,rsp
00007ff8`3c813bca 833d27960c0000 cmp dword ptr [00007ff8`3c8dd1f8],0
00007ff8`3c813bd1 7405 je 00007ff8`3c813bd8
00007ff8`3c813bd3 e8e828c45f call coreclr!JIT_DbgIsJustMyCode (00007ff8`9c4564c0)
00007ff8`3c813bd8 48b83084008cb2010000 mov rax,1B28C008430h
00007ff8`3c813be2 488b00 mov rax,qword ptr [rax]
00007ff8`3c813be5 488d6520 lea rsp,[rbp+20h]
00007ff8`3c813be9 5e pop rsi
00007ff8`3c813bea 5f pop rdi
00007ff8`3c813beb 5d pop rbp
00007ff8`3c813bec c3 ret
예상할 수 있듯이, 위의 코드에서 1B28C008430h 값은 gc handle 테이블의 위치이고, 그 주소([rax])에 보관하고 있는 값은 실제 String 개체를 가리킵니다.
0:014> dq 1B28C008430h L1
000001b2`8c008430 000001b2`8e815378
0:014> !do 000001b2`8e815378
Name: System.String
MethodTable: 00007ff83c7ffd18
EEClass: 00007ff83c7ea740
Tracked Type: false
Size: 32(0x20) bytes
File: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.14\System.Private.CoreLib.dll
String: Hello
Fields:
MT Field Offset Type VT Attr Value Name
00007ff83c77e8d8 4000308 8 System.Int32 1 instance 5 _stringLength
00007ff83c7a63a8 4000309 c System.Char 1 instance 48 _firstChar
00007ff83c7ffd18 4000307 100 System.String 0 static 000001b28e800218 Empty
0:014> db 000001b2`8e815378+0x0c LA
000001b2`8e815384 48 00 65 00 6c 00 6c 00-6f 00 H.e.l.l.o.
여기서 재미있는 건, 저런 식으로 Pinning한 개체는 GC Handle 테이블에 등록되지 않습니다.
0:014> !gchandles
Handle Type Object Size Data Type
000001B28A1C1178 WeakShort 000001b28e81ea98 40 System.Buffers.TlsOverPerCoreLockedStacksArrayPool`1[[System.Byte, System.Private.CoreLib]]
...[생략]...
000001B28A1C1DF8 AsyncPinned 000001b28e81ef88 72 System.Threading.OverlappedData
보는 바와 같이 1B28C008430h 주소는 저 범위(000001B28A1C1178 ~ 000001B28A1C1DF8)에 없는데요, 대신
POH 영역에 위치하게 됩니다.
0:014> !eeheap
...[생략]...
========================================
Number of GC Heaps: 1
----------------------------------------
Small object heap
segment begin allocated committed allocated size committed size
generation 0:
01f29fe0f320 01b28e800020 01b28e822fe8 01b28e831000 0x22fc8 (143304) 0x31000 (200704)
generation 1:
01f29fe0f270 01b28e400020 01b28e400020 01b28e401000 0x1000 (4096)
generation 2:
01f29fe0f1c0 01b28e000020 01b28e000020 01b28e001000 0x1000 (4096)
Large object heap
segment begin allocated committed allocated size committed size
01f29fe0f3d0 01b28ec00020 01b28ec00020 01b28ec01000 0x1000 (4096)
Pinned object heap
segment begin allocated committed allocated size committed size
01f29fe0ec40 01b28c000020 01b28c008c18 01b28c011000 0x8bf8 (35832) 0x11000 (69632)
------------------------------
GC Allocated Heap Size: Size: 0x2bbc0 (179136) bytes.
GC Committed Heap Size: Size: 0x45000 (282624) bytes.
Total bytes consumed by CLR: 0x295000 (2707456)
그런데, 저렇게 처리한 것이 잘 이해는 안 됩니다. 원래 POH 영역은 Pinning 시킨 데이터를 위한 공간입니다. 그런데, 문자열 리터럴의 경우 해당 문자열 자체는 generation 0 힙 위치에 저장하면서, 그 문자열을 가리키는 GCHandle 값만 (GCHandle 테이블이 아닌) POH 영역에 보관하고 있는 것입니다.
(2024-04-05: 업데이트)
Lesser known CLR GC Handles
; https://www.awise.us/2024/03/31/gc-handle.html
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]