windbg - 눈으로 확인하는 Workstation GC / Server GC
예전 글에서,
.NET Garbage Collection에 대한 정리
; https://www.sysnet.pe.kr/2/0/1862
ASP.NET을 제외하고 대부분의 닷넷 응용 프로그램이 Workstation GC를 사용한다고 했습니다. 실제로 일반 콘솔 프로그램을 만들어 실행한 후 windbg로 확인해 보면,
0:006> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x04e01018
generation 1 starts at 0x04e0100c
generation 2 starts at 0x04e01000
ephemeral segment allocation context: none
segment begin allocated size
04e00000 04e01000 04e05ff4 0x4ff4(20468)
Large object heap starts at 0x05e01000
segment begin allocated size
05e00000 05e01000 05e05500 0x4500(17664)
Total Size: Size: 0x94f4 (38132) bytes.
------------------------------
GC Heap Size: Size: 0x94f4 (38132) bytes.
위와 같이 GC Heap이 1개만 생성된 것을 볼 수 있습니다. 이 상태에서 app.config에 gcServer 설정을 추가하면,
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7" />
</startup>
<runtime>
<gcServer enabled="true"/>
</runtime>
</configuration>
논리 CPU 4개인 PC에서 다음과 같은 결과를 얻을 수 있습니다.
0:011> !eeheap -gc
Number of GC Heaps: 4
------------------------------
Heap 0 (030e3f08)
generation 0 starts at 0x04fc1018
generation 1 starts at 0x04fc100c
generation 2 starts at 0x04fc1000
ephemeral segment allocation context: none
segment begin allocated size
04fc0000 04fc1000 04fc1024 0x24(36)
Large object heap starts at 0x14fc1000
segment begin allocated size
14fc0000 14fc1000 14fc5500 0x4500(17664)
Heap Size: Size: 0x4524 (17700) bytes.
------------------------------
Heap 1 (030e9120)
generation 0 starts at 0x08fc1018
generation 1 starts at 0x08fc100c
generation 2 starts at 0x08fc1000
ephemeral segment allocation context: none
segment begin allocated size
08fc0000 08fc1000 08fc1024 0x24(36)
Large object heap starts at 0x16fc1000
segment begin allocated size
16fc0000 16fc1000 16fc1010 0x10(16)
Heap Size: Size: 0x34 (52) bytes.
------------------------------
Heap 2 (030ee338)
generation 0 starts at 0x0cfc1018
generation 1 starts at 0x0cfc100c
generation 2 starts at 0x0cfc1000
ephemeral segment allocation context: none
segment begin allocated size
0cfc0000 0cfc1000 0cfc1024 0x24(36)
Large object heap starts at 0x18fc1000
segment begin allocated size
18fc0000 18fc1000 18fc1010 0x10(16)
Heap Size: Size: 0x34 (52) bytes.
------------------------------
Heap 3 (030f3550)
generation 0 starts at 0x10fc1018
generation 1 starts at 0x10fc100c
generation 2 starts at 0x10fc1000
ephemeral segment allocation context: none
segment begin allocated size
10fc0000 10fc1000 10fc5ff4 0x4ff4(20468)
Large object heap starts at 0x1afc1000
segment begin allocated size
1afc0000 1afc1000 1afc1010 0x10(16)
Heap Size: Size: 0x5004 (20484) bytes.
------------------------------
GC Heap Size: Size: 0x9590 (38288) bytes.
보다시피 Heap 0, Heap 1, Heap 2, Heap 3까지 4개의 GC Heap이 생성되었습니다.
하는 김에 스레드 수도 확인해 보겠습니다.
Workstation GC의 경우,
0:006> ~*k
0 Id: 3da4.1828 Suspend: 1 Teb: 00b06000 Unfrozen
# ChildEBP RetAddr
00 00d5ee00 77a7e1f2 ntdll!NtReadFile+0xc
01 00d5ee64 72205947 KERNELBASE!ReadFile+0xe2
02 00d5eed4 72939a13 mscorlib_ni+0x475947
...[생략]...
18 00d5fa8c 00000000 ntdll!_RtlUserThreadStart+0x1b
1 Id: 3da4.2c8c Suspend: 1 Teb: 00b09000 Unfrozen
# ChildEBP RetAddr
00 02fffb60 77c33b16 ntdll!NtWaitForWorkViaWorkerFactory+0xc
01 02fffd58 74658654 ntdll!TppWorkerThread+0x296
02 02fffd6c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 02fffdb4 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 02fffdc4 00000000 ntdll!_RtlUserThreadStart+0x1b
2 Id: 3da4.2508 Suspend: 1 Teb: 00b0c000 Unfrozen
...[생략: 1번과 동일]...
3 Id: 3da4.2d70 Suspend: 1 Teb: 00b0f000 Unfrozen
...[생략: 1번과 동일]...
4 Id: 3da4.3b0c Suspend: 1 Teb: 00b12000 Unfrozen
# ChildEBP RetAddr
00 04dff5bc 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 04dff750 73e2ed0b KERNELBASE!WaitForMultipleObjectsEx+0x103
02 04dff7bc 73e2ec60 clr!DebuggerRCThread::MainLoop+0x99
03 04dff7ec 73e2eb8d clr!DebuggerRCThread::ThreadProc+0xd0
04 04dff818 74658654 clr!DebuggerRCThread::ThreadProcStatic+0xc4
05 04dff82c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
06 04dff874 77c64a47 ntdll!__RtlUserThreadStart+0x2f
07 04dff884 00000000 ntdll!_RtlUserThreadStart+0x1b
5 Id: 3da4.1d58 Suspend: 1 Teb: 00b15000 Unfrozen
# ChildEBP RetAddr
00 06eff378 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 06eff50c 73e881c7 KERNELBASE!WaitForMultipleObjectsEx+0x103
02 06eff53c 73df56ce clr!FinalizerThread::WaitForFinalizerEvent+0x8a
03 06eff56c 73eefdca clr!FinalizerThread::FinalizerThreadWorker+0x5f
04 06eff580 73eefe34 clr!ManagedThreadBase_DispatchInner+0x71
05 06eff624 73eeff01 clr!ManagedThreadBase_DispatchMiddle+0x7e
06 06eff680 73e0ced8 clr!ManagedThreadBase_DispatchOuter+0x5b
07 06eff6a8 73e0cf9f clr!ManagedThreadBase::FinalizerBase+0x33
08 06eff6e4 73d9b601 clr!FinalizerThread::FinalizerThreadStart+0xd4
09 06eff788 74658654 clr!Thread::intermediateThreadProc+0x55
0a 06eff79c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0b 06eff7e4 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0c 06eff7f4 00000000 ntdll!_RtlUserThreadStart+0x1b
# 6 Id: 3da4.21dc Suspend: 1 Teb: 00b18000 Unfrozen
# ChildEBP RetAddr
00 073cfc38 77caa6c9 ntdll!DbgBreakPoint
01 073cfc68 74658654 ntdll!DbgUiRemoteBreakin+0x39
02 073cfc7c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 073cfcc4 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 073cfcd4 00000000 ntdll!_RtlUserThreadStart+0x1b
위의 콜 스택 결과로 유추해 다음의 결과를 얻을 수 있습니다.
0번: Main Thread
1번: Thread Pools - Worker Thread
2번: Thread Pools - Worker Thread
3번: Thread Pools - Worker Thread
4번: (windbg로 인한) 디버거 스레드
5번: Finalizer Thread
6번: (windbg로 인한) 디버거 스레드
=== 총 7개
Server GC를 사용한 결과도 보면,
0:011> ~*k
0 Id: 3774.1a9c Suspend: 1 Teb: 00f3c000 Unfrozen
# ChildEBP RetAddr
00 00dcf2a0 77a7e1f2 ntdll!NtReadFile+0xc
01 00dcf304 72205947 KERNELBASE!ReadFile+0xe2
...[생략]...
15 00dcfeb8 74658654 MSCOREE!_CorExeMain_Exported+0x8
16 00dcfecc 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
17 00dcff14 77c64a47 ntdll!__RtlUserThreadStart+0x2f
18 00dcff24 00000000 ntdll!_RtlUserThreadStart+0x1b
1 Id: 3774.4998 Suspend: 1 Teb: 00f3f000 Unfrozen
# ChildEBP RetAddr
00 0337f9dc 77c33b16 ntdll!NtWaitForWorkViaWorkerFactory+0xc
01 0337fbd4 74658654 ntdll!TppWorkerThread+0x296
02 0337fbe8 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 0337fc30 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 0337fc40 00000000 ntdll!_RtlUserThreadStart+0x1b
2 Id: 3774.1620 Suspend: 1 Teb: 00f42000 Unfrozen
...[생략: 1번과 동일]...
3 Id: 3774.4484 Suspend: 1 Teb: 00f45000 Unfrozen
# ChildEBP RetAddr
...[생략: 1번과 동일]...
4 Id: 3774.4960 Suspend: 1 Teb: 00f48000 Unfrozen
# ChildEBP RetAddr
00 04f8fb84 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 04f8fd18 73e2ed0b KERNELBASE!WaitForMultipleObjectsEx+0x103
02 04f8fd84 73e2ec60 clr!DebuggerRCThread::MainLoop+0x99
03 04f8fdb4 73e2eb8d clr!DebuggerRCThread::ThreadProc+0xd0
04 04f8fde0 74658654 clr!DebuggerRCThread::ThreadProcStatic+0xc4
05 04f8fdf4 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
06 04f8fe3c 77c64a47 ntdll!__RtlUserThreadStart+0x2f
07 04f8fe4c 00000000 ntdll!_RtlUserThreadStart+0x1b
5 Id: 3774.1db4 Suspend: 1 Teb: 00f4b000 Unfrozen
# ChildEBP RetAddr
00 1daafc40 77a7ebe9 ntdll!NtWaitForSingleObject+0xc
01 1daafcb4 73e7008b KERNELBASE!WaitForSingleObjectEx+0x99
02 1daafce4 73e700d2 clr!CLREventWaitHelper2+0x33
03 1daafd34 73e70057 clr!CLREventWaitHelper+0x2a
04 1daafd6c 73e70152 clr!CLREventBase::WaitEx+0x152
05 1daafd84 73df9acf clr!CLREventBase::Wait+0x1a
06 1daafda8 73e3c69e clr!SVR::gc_heap::gc_thread_function+0x4d
07 1daafdc0 73e3c62f clr!SVR::gc_heap::gc_thread_stub+0x72
08 1daafdd4 74658654 clr!GCThreadStub+0x1f
09 1daafde8 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0a 1daafe30 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0b 1daafe40 00000000 ntdll!_RtlUserThreadStart+0x1b
6 Id: 3774.14f8 Suspend: 1 Teb: 00f4e000 Unfrozen
...[생략: 5번과 동일]...
7 Id: 3774.27a8 Suspend: 1 Teb: 00f51000 Unfrozen
...[생략: 5번과 동일]...
8 Id: 3774.26f4 Suspend: 1 Teb: 00f54000 Unfrozen
...[생략: 5번과 동일]...
9 Id: 3774.4830 Suspend: 1 Teb: 00f57000 Unfrozen
# ChildEBP RetAddr
00 1de2f728 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 1de2f8bc 73e881c7 KERNELBASE!WaitForMultipleObjectsEx+0x103
02 1de2f8ec 73df56ce clr!FinalizerThread::WaitForFinalizerEvent+0x8a
03 1de2f91c 73eefdca clr!FinalizerThread::FinalizerThreadWorker+0x5f
04 1de2f930 73eefe34 clr!ManagedThreadBase_DispatchInner+0x71
05 1de2f9d4 73eeff01 clr!ManagedThreadBase_DispatchMiddle+0x7e
06 1de2fa30 73e0ced8 clr!ManagedThreadBase_DispatchOuter+0x5b
07 1de2fa58 73e0cf9f clr!ManagedThreadBase::FinalizerBase+0x33
08 1de2fa94 73d9b601 clr!FinalizerThread::FinalizerThreadStart+0xd4
09 1de2fb2c 74658654 clr!Thread::intermediateThreadProc+0x55
0a 1de2fb40 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0b 1de2fb88 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0c 1de2fb98 00000000 ntdll!_RtlUserThreadStart+0x1b
10 Id: 3774.3a28 Suspend: 1 Teb: 00f5a000 Unfrozen
# ChildEBP RetAddr
00 1df6f5fc 77a7ebe9 ntdll!NtWaitForSingleObject+0xc
01 1df6f670 77a7eb42 KERNELBASE!WaitForSingleObjectEx+0x99
02 1df6f684 73e3d2bc KERNELBASE!WaitForSingleObject+0x12
03 1df6f69c 73e3d282 clr!ProfilingAPIAttachDetach::OverlappedResultHolder::Wait+0x13
04 1df6f6d8 73e3d15c clr!ProfilingAPIAttachServer::ConnectToClient+0x81
05 1df6f70c 73e3d0eb clr!ProfilingAPIAttachServer::ServiceOneClient+0x31
06 1df6f72c 73e3b77c clr!ProfilingAPIAttachServer::ExecutePipeRequests+0x3f
07 1df6f7b0 74658654 clr!ProfilingAPIAttachDetach::ProfilingAPIAttachThreadStart+0x6c
08 1df6f7c4 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
09 1df6f80c 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0a 1df6f81c 00000000 ntdll!_RtlUserThreadStart+0x1b
# 11 Id: 3774.21a8 Suspend: 1 Teb: 00f5d000 Unfrozen
# ChildEBP RetAddr
00 1e43fb40 77caa6c9 ntdll!DbgBreakPoint
01 1e43fb70 74658654 ntdll!DbgUiRemoteBreakin+0x39
02 1e43fb84 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 1e43fbcc 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 1e43fbdc 00000000 ntdll!_RtlUserThreadStart+0x1b
결과가 다음과 같이 정리됩니다.
0번: Main Thread
1번: Thread Pools - Worker Thread
2번: Thread Pools - Worker Thread
3번: Thread Pools - Worker Thread
4번: (windbg로 인한) 디버거 스레드
5번: GC Thread
6번: GC Thread
7번: GC Thread
8번: GC Thread
9번: Finalizer Thread
10번: (이유는 알 수 없지만 아마도 이것도 windbg로 인한 스레드인 듯!)
11번: (windbg로 인한) 디버거 스레드
=== 총 12개
여기서 재미있는 점이 하나 있는데요, Server GC의 경우 정확하게 4개의 GC dedicated thread가 나왔지만, Workstation GC의 경우 Concurrent GC이므로 역시 전용 GC Thread 하나가 있어야 하는데 없다는 것입니다. 혹시 GC가 발생하는 시점에만 활성화되는 걸까요? 그래서 소스 코드를 다음과 같이 바꿔봤습니다.
using System;
using System.Threading;
namespace ConsoleApp1
{
class Program
{
static volatile bool _loop = true;
static void Main(string[] args)
{
Thread t = new Thread(signalFunc);
t.Start();
byte[] buf = null;
while (_loop == true)
{
buf = new byte[1024 * 1024];
}
Console.WriteLine("Press ENTER key to exit...");
Console.ReadLine();
}
private static void signalFunc()
{
Console.ReadLine();
_loop = false;
}
}
}
할당 루프를 도는 동안 windbg로 붙여 다음의 전용 GC 스레드를 확인할 수 있었습니다.
6 Id: 49a8.37b0 Suspend: 1 Teb: 004bf000 Unfrozen
# ChildEBP RetAddr
00 06dceeb8 73e71544 clr!DecodeGCHdrInfo+0x1d7
01 06dceee4 73e71a1c clr!EECodeManager::GetGSCookieAddr+0x44
02 06dcef00 73e706df clr!StackFrameIterator::PreProcessingForManagedFrames+0x2d
03 06dcef20 73e71734 clr!StackFrameIterator::ProcessCurrentFrame+0x202
04 06dcef60 73e7033f clr!StackFrameIterator::NextRaw+0x4cc
05 06dcf224 73e70411 clr!Thread::StackWalkFramesEx+0xc2
06 06dcf558 73e74d85 clr!Thread::StackWalkFrames+0x9d
07 06dcf590 73ef274f clr!GCToEEInterface::GcScanRoots+0x108
08 06dcf5d0 73ef28b9 clr!WKS::gc_heap::background_mark_phase+0x42d
09 06dcf5f0 73ef20f8 clr!WKS::gc_heap::gc1+0x92
0a 06dcf610 73ef21a8 clr!WKS::gc_heap::bgc_thread_function+0x140
0b 06dcf614 73d9b601 clr!WKS::gc_heap::bgc_thread_stub+0x3c
0c 06dcf7b4 74658654 clr!Thread::intermediateThreadProc+0x55
0d 06dcf7c8 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0e 06dcf810 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0f 06dcf820 00000000 ntdll!_RtlUserThreadStart+0x1b
하지만 Enter 키를 한번 눌러 할당 루프를 빠져나온 다음 약간의 시간이 지나서 다시 windbg로 확인을 하니 위의 WKS::gc_heap 스레드가 사라졌습니다. 아마도 전용 GC 스레드는 필요할 때만 활성화되고 timeout 시간이 있는 듯합니다.
하나 더 실험을 해서 gcConcurrent 옵션을 false로 설정하면,
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7" />
</startup>
<runtime>
<gcConcurrent enabled="false" />
</runtime>
</configuration>
할당 루프를 도는 동안에도 WKS::gc_heap 콜 스택은 볼 수 없습니다.
참고로 다음의 영상을 보면,
How to identify CLR threads in a dump - 08
; https://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment/How-to-Identify-CLR-threads-in-a-dump-08
.NET 응용 프로그램의 콜 스택에서 다음과 같은 유형의 스레드를 확인할 수 있으며,
- Worker
- I/O Completion Port
- Gate
- Managed Debugger
- Timer
- Finalizer
- GC (Server GC)
콜 스택에 있는 함수 호출에 따라 다음과 같이 구분할 수 있다고 합니다.
ThreadpoolMgr::CompletionPortThreadStart ==> I/O Completion Port
DebuggerRCThread::ThreadProcStatic ==> Managed Debugger
SVR::gc_heap::gc_thread_function ==> GC Thread
SVR::GCHeap::FinalizerThreadStart ==> Finalizer
ThreadpoolMgr::TimerThreadStart ==> Timer
ThreadpoolMgr::WorkerThreadStart ==> Worker
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]