.NET 참조 개체 인스턴스의 Object Header를 확인하는 방법
사실, 원래는 StringBuilder에서 OutOfMemoryException의 원인만 밝히려고 했는데 쓰다 보니 궁금함이 꼬리를 물어서 이렇게 이야기가 길어졌군요. ^^
StringBuilder에서의 OutOfMemoryException 오류 원인 분석
; https://www.sysnet.pe.kr/2/0/1171
windbg - 힙에서 .NET 타입에 대한 배열을 찾는 방법
; https://www.sysnet.pe.kr/2/0/1172
.NET Array는 왜 12bytes의 기본 메모리를 점유할까?
; https://www.sysnet.pe.kr/2/0/1173
일반 참조형의 메모리 소비는 얼마나 될까요?
; https://www.sysnet.pe.kr/2/0/1174
그런데, 여기서 옛날에 읽었던 글이 하나 더 생각나는 바람에... ^^;
Safe Thread Synchronization
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2003/january/net-column-safe-thread-synchronization
위의 글에 보면, Managed Heap에서의 개체 메모리에 대한 정의가 다음과 같이 나옵니다.
이에 비춰서 지난번에 개체들의 메모리를 살펴봤을 때의 덤프 내용을 다시 한번 살펴볼까요?
=== ConsoleApplication1.Program 인스턴스의 메모리 덤프 ===
0:004> dd 026cbf90
026cbf90 00293810 00000000 00000000 00000000
026cbfa0 00000000 00000000 00000000 00000000
그림과 매치시켜 보면 아래와 같이 정의되는데요.
00293810 == MethodTable Pointer
00000000 == SyncBlock Index
00000000 == Object Fields
실제로는 3개의 공간이긴 해도 저런 식이 아니고 -4(64비트에서는 -8)바이트 위치에서 3개의 공간이 점유되어 다음과 같은 의미를 갖게 됩니다.
0:004> dd 026CBF8C
026CBF8C 00000000 00293810 00000000 00000000
026CBF9C 00000000 00000000 00000000 00000000
00000000 == Object Header (SyncBlock Index)
00293810 == MethodTable Pointer
00000000 == 핃드가 없어도 최소 1개의 공간을 점유
그리고 Object Header가 담고 있는 SyncBlock Index의 개념은 다음의 글에서 자세하게 설명하고 있습니다.
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2005/may/net-framework-internals-how-the-clr-creates-runtime-objects
재미있는 것은, SyncBlock Index의 기본값이 아마도 CLR 버전에 따라 달라지는 것 같습니다.
"
Safe Thread Synchronization" 글에서는 다음과 같이 lock이 걸리지 않은 상태에서는 -1 값으로 채워져 있다는 설명을 포함하고 있는데,
"
On the other hand, ObjectB's SyncBlockIndex field is set to -1 indicating that ObjectB doesn't have a SyncBlock associated with it for its use
"
"
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects" 글에서는 0 값으로 채워져 있다고 되어 있습니다.
"
For most object instances, there will be no storage allocated for the actual SyncBlock and the syncblk number will be zero
"
현재 버전에서 어느 쪽이 맞는지, 한번 확인을 해볼까요? ^^
비교를 위해 lock이 걸린 object와 그렇지 않았을 때의 메모리 구조를 확인해야 할 텐데요. 분석을 쉽게 하기 위해 다음과 같이 간단하게 코딩을 하고,
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Program[] pgList = new Program[0];
Thread.Sleep(-1);
}
}
}
windbg로 메모리를 덤프해 보면,
// 이전 글들의 예제에서 많이 포함했으므로, 이전 단계는 생략합니다.
0:000> !do 0228bf90
Name: System.Object[]
MethodTable: 72f86ba8
EEClass: 72d09688
Size: 16(0x10) bytes
Array: Rank 1, Number of elements 0, Type CLASS
Element Type:ConsoleApplication1.Program
Fields:
None
0:000> dd 0228bf8c (0x0228bf90 - 4 == 0228bf8c)
0228bf8c 00000000 72f86ba8 00000000 00163810
0228bf9c 00000000 00000000 00000000 00000000
0228bfac 00000000 00000000 00000000 00000000
덤프된 결과를 각각 다음과 같이 분석할 수 있습니다.
00000000 == SyncBlock Index
72f86ba8 == MethodTable (System.Object [])
00000000 == 배열의 수
00163810 == 배열 요소의 Type에 대한 MethodTable
아하... 사용되지 않는 SyncBlock Index의 값은 0이 맞군요. ^^ (각각의 글이 씌여진 시점에 따라 .NET의 버전 차이라고 의심되었으나, .NET 1.1/2.0/4.0 응용 프로그램에 대해서 동일한 결과값을 얻었습니다.)
본론으로 돌아가서, 이제 해당 object 에 대해 lock을 걸어서 컴파일 한 다음,
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Program[] pgList = new Program[0];
lock (pgList)
{
Thread.Sleep(-1);
}
}
}
}
windbg로 메모리를 덤프해 보면,
0:000> !do 026dbf90
Name: System.Object[]
MethodTable: 72f86ba8
EEClass: 72d09688
Size: 16(0x10) bytes
Array: Rank 1, Number of elements 0, Type CLASS
Element Type:ConsoleApplication1.Program
Fields:
None
ThinLock owner 1 (0077e0a8), Recursive 0
0:000> dd 026dbf8c (026dbf90 - 4 == 026dbf8c)
026dbf8c 00000001 72f86ba8 00000000 00283810
026dbf9c 00000000 00000000 00000000 00000000
026dbfac 00000000 00000000 00000000 00000000
이제는 SyncBlock Index 값이 1로 설정되어 있고 !DumpObject의 결과에는 "ThinLock owner 1 (0077e0a8), Recursive 0"이라는 출력 결과도 확인할 수 있습니다.
00000001 == SyncBlock Index
72f86ba8 == MethodTable (System.Object [])
00000000 == 배열의 수
00283810 == 배열 요소의 Type에 대한 MethodTable
'참조형'의 값은 모두 이렇게 데이터 구조에 "Object Header"를 가지고 있는 반면, 스택에 생성되는 '값형식'에서는 "Object Header"가 존재하지 않습니다.
바로 이 때문에 참조값에 대해서만 닷넷에서 lock 구문(Monitor.Enter 메서드)으로 사용할 수 있는 것입니다.
object lockInstance = new object();
lock (lockInstance) // 이 시점에 Object Header로 SyncBlock Index 값이 설정되고,
{
} // 이 시점에 SyncBlock == 0x00000000으로 해제됨.
try
{
Monitor.Enter(lockInstance); // 이 시점에 Object Header로 SyncBlock Index 값이 설정되고,
}
finally
{
Monitor.Exit(lockInstance); // 이 시점에 SyncBlockIndex == 0x00000000으로 해제됨.
}
int errorLock = 5;
lock (errorLock) // 컴파일 오류: 'int' is not a reference type as required by the lock statement
{
}
때로는 문서에서만 읽었던 이런 내용들을, 직접 확인해 보는 것도 그런대로 재미가 있군요. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]