.NET 8 - NonGC Heap / FOH (Frozen Object Heap)
닷넷 5에 추가된 POH에 이어서,
닷넷 5에 추가된 POH (Pinned Object Heap)
; https://www.sysnet.pe.kr/2/0/12545
.NET 8에는 NonGC Heap이 추가되었는데요,
[출처:
NonGC Heap]
이것의 목적은 불멸 개체(Immortal object), 즉 해제할 필요가 없는 개체를 담아 놓는 보관소이기 때문에 (이름 그대로 NonGC이기에) GC의 관리를 받지 않는다는 특징이 있습니다. 결국 "Mark-n-Sweep" 과정을 거치지 않으므로 여기에 있는 개체들은 참조형 필드를 가져서도 안됩니다.
사실 이게 완전히 새로운 Heap은 아니고, 예전부터 CoreRT/NativeAOT에 의해 사용되던 FOH (Frozen Object Heap)을 .NET 8부터 NonGC Heap으로 새롭게 명명한 것이라고 합니다.
NonGC Heap
; https://github.com/dotnet/runtime/blob/main/docs/design/features/NonGC-Heap.md
FOH가 어떻게 .NET 8부터 성능 향상에 기여하게 되었는지 아래의 이슈에서 대략 확인할 수 있는데요,
FOH (Frozen Object Heap) work items
; https://github.com/dotnet/runtime/issues/76151
- Allocate string literals on FOH
- Allocate Type objects on FOH
- Optimize static readonly fields holding frozen objects to const handles
- Don't use write-barriers for FOH objects
- Allocate simple static readonly fields on FOH e.g. static readonly object SyncObj = new(); and arrays
- Allocate boxes statics on FOH
- Better heuristics for size of frozen segments:
- ...
일례로, "Allocate string literals on FOH"에 대해 잠깐 살펴보겠습니다. 지난 글에서,
C# - GCHandle 구조체의 메모리 분석
; https://www.sysnet.pe.kr/2/0/13535
문자열 리터럴의 경우 GCHandle은 POH에, 문자열 자체는 GC Heap에 보관되었다고 했습니다. 그런데, .NET 8부터는 어차피 문자열 리터럴이 프로그램 생명 주기 동안 삭제될 일은 없으므로 그 의미에 맞게 FOH에 넣는다고 합니다. 실제로 그런지 직접 눈으로 확인해 볼까요? ^^
간단하게 다음과 같이 코드를 만들고,
// 반드시 .NET 8+에서 빌드
namespace ConsoleApp3;
internal class Program
{
static void Main(string[] args)
{
Console.WriteLine(Program.Test());
Console.ReadLine();
}
public static string Test() => "Hello";
}
windbg를 붙여 Jit 코드를 확인해 보면,
0:014> !name2ee ConsoleApp3!ConsoleApp3.Program.Test
Module: 00007ff83c84e0a0
Assembly: ConsoleApp3.dll
Token: 0000000006000002
MethodDesc: 00007ff83c8700d8
Name: ConsoleApp3.Program.Test()
JITTED Code Address: 00007ff83c7c5fe0
0:014> !U /d 00007ff83c7c5fe0
...[생략]...
C:\temp\ConsoleApp1\ConsoleApp3\Program.cs @ 13:
>>> 00007ff8`3c7c5fe0 55 push rbp
00007ff8`3c7c5fe1 57 push rdi
00007ff8`3c7c5fe2 56 push rsi
00007ff8`3c7c5fe3 4883ec20 sub rsp,20h
00007ff8`3c7c5fe7 488bec mov rbp,rsp
00007ff8`3c7c5fea 833d3783080000 cmp dword ptr [00007ff8`3c84e328],0
00007ff8`3c7c5ff1 7405 je 00007ff8`3c7c5ff8
00007ff8`3c7c5ff3 e818aac95f call coreclr!JIT_DbgIsJustMyCode (00007ff8`9c460a10)
00007ff8`3c7c5ff8 48b8602b3000e7010000 mov rax,1E700302B60h ("Hello")
00007ff8`3c7c6002 488d6520 lea rsp,[rbp+20h]
00007ff8`3c7c6006 5e pop rsi
00007ff8`3c7c6007 5f pop rdi
00007ff8`3c7c6008 5d pop rbp
00007ff8`3c7c6009 c3 ret
(
.NET 7과는 달리) .NET 8부터는 GCHandle을 거치지 않고 저렇게 직접 1E700302B60h 문자열 개체를 접근하도록 바뀌었습니다. 그리고, 해당 개체가 저장된 영역은,
0:014> !eeheap
...[생략]...
========================================
Number of GC Heaps: 1
----------------------------------------
Small object heap
segment begin allocated committed allocated size committed size
generation 0:
02276e40f320 01e75cc00028 01e75cc1f0e0 01e75cc21000 0x1f0b8 (127160) 0x21000 (135168)
generation 1:
02276e40f270 01e75c800028 01e75c800028 01e75c801000 0x1000 (4096)
generation 2:
02276e40f1c0 01e75c400028 01e75c400028 01e75c401000 0x1000 (4096)
Frozen object heap
segment begin allocated committed allocated size committed size
01e758a088f0 01e700300008 01e700303bd0 01e700310000 0x3bc8 (15304) 0x10000 (65536)
Large object heap
segment begin allocated committed allocated size committed size
02276e40f3d0 01e75d000028 01e75d000028 01e75d001000 0x1000 (4096)
Pinned object heap
segment begin allocated committed allocated size committed size
02276e40ec40 01e75a400028 01e75a407ff0 01e75a411000 0x7fc8 (32712) 0x11000 (69632)
------------------------------
GC Allocated Heap Size: Size: 0x2ac48 (175176) bytes.
GC Committed Heap Size: Size: 0x45000 (282624) bytes.
Total bytes consumed by CLR: 0x331000 (3346432)
FOH 영역, 즉 NonGC Heap에 속합니다. 그러니까, Jitter 입장에서는 FOH에 할당된 개체의 경우 절대 없어지지 않는다는 확신을 가질 수 있으므로, GCHandle 등을 경유해 접근할 필요 없이 그냥 곧바로 개체 주소를 다루도록 바꾼 것입니다. 바로 이런 내용을, 문서에서는 다음과 같은 비교로 설명하고 있는 것입니다.
In pre-.NET 8.0 runtimes, the following C# code:
string Test() => "Hello";
produces the following codegen:
; Method Program:Test():System.String:this
mov rax, 0xAABBCCDDEEFF // GCHandle을 경유해
mov rax, gword ptr [rax] // 실제 개체를 접근
ret
...[생략]... By pinning the object itself instead, JIT can "bake" the direct reference, resulting in a more efficient codegen:
; Method Program:Test():System.String:this
mov rax, 0x112233445566 // GCHandle을 경유하지 않고 직접 접근
ret
이외에도 RuntimeType 개체 역시,
Type Test() => typeof(int);
기존에는 간접적으로 접근했지만,
; Method Test():System.Type:this
sub rsp, 40
mov rcx, 0x7FFC892DE5D8
call CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPE
nop
add rsp, 40
ret
; Total bytes of code: 25
이제는 직접 접근하기 때문에 성능이 향상되었다고 합니다.
; Method Test():System.Type:this
mov rax, 0x2C1802055E8 ; 'System.Int32' RuntimeType object
ret
; Total bytes of code: 11
한 가지 주의할 점이 있다면, FOH에 보관되는 개체의 경우 GetGeneration으로 세대를 확인하면,
string text = "Hello";
Console.WriteLine(GC.GetGeneration(text)); // 출력 결과: 2147483647 (int.MaxValue)
GC의 관리를 받지 않는다는 의미에서 int.MaxValue 값을 반환한다고 합니다. 따라서 혹시나 GetGeneration을 사용해서 그 반환값이 0~2라고 가정해 작성한 코드가 있다면 .NET 8부터는 달라지므로 주의를 해야 합니다.
개인적으로, NonGC Heap이 흥미로운 점이 하나 있는데요, 다른 GC Heap과는 달리, FOH의 경우에는 생성/삭제할 수 있는 방법을 (아직은 비공식적으로) 제공한다는 점입니다. 분량상 이것은 별도의 글로 다뤄보겠습니다. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]