Microsoft MVP성태의 닷넷 이야기
닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [링크 복사], [링크+제목 복사],
조회: 3885
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 9개 있습니다.)
.NET Framework: 497. .NET Garbage Collection에 대한 정리
; https://www.sysnet.pe.kr/2/0/1862

.NET Framework: 728. windbg - 눈으로 확인하는 Workstation GC / Server GC
; https://www.sysnet.pe.kr/2/0/11445

.NET Framework: 729. windbg로 살펴보는 GC heap의 Segment 구조
; https://www.sysnet.pe.kr/2/0/11446

.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap)
; https://www.sysnet.pe.kr/2/0/12545

.NET Framework: 1029. C# - GC 호출로 인한 메모리 압축(Compaction)을 확인하는 방법
; https://www.sysnet.pe.kr/2/0/12572

.NET Framework: 1059. 세대 별 GC(Garbage Collection) 방식에서 Card table의 사용 의미
; https://www.sysnet.pe.kr/2/0/12649

.NET Framework: 1060. 닷넷 GC에 새롭게 구현되는 DPAD(Dynamic Promotion And Demotion for GC)
; https://www.sysnet.pe.kr/2/0/12653

.NET Framework: 2024. .NET 7에 도입된 GC의 메모리 해제에 대한 segment와 region의 차이점
; https://www.sysnet.pe.kr/2/0/13083

닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap)
; https://www.sysnet.pe.kr/2/0/13536




.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]
non_gc_heap_1.png

이것의 목적은 불멸 개체(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의 경우에는 생성/삭제할 수 있는 방법을 (아직은 비공식적으로) 제공한다는 점입니다. 분량상 이것은 별도의 글로 다뤄보겠습니다. ^^





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

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/23/2024]

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

비밀번호

댓글 작성자
 



2024-02-02 10시23분
정성태

1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13577정성태3/9/20243920닷넷: 2229. C# - 닷넷을 위한 난독화 도구 소개 (예: ConfuserEx)
13576정성태3/8/20243127닷넷: 2228. .NET Profiler - IMetaDataEmit2::DefineMethodSpec 사용법
13575정성태3/7/20243477닷넷: 2227. 최신 C# 문법을 .NET Framework 프로젝트에 쓸 수 있을까요?
13574정성태3/6/20243201닷넷: 2226. C# - "Docker Desktop for Windows" Container 환경에서의 IPv6 DualMode 소켓
13573정성태3/5/20243106닷넷: 2225. Windbg - dumasync로 분석하는 async/await 호출
13572정성태3/4/20243387닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상파일 다운로드1
13571정성태3/1/20243068닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13570정성태2/29/20242950닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/20242867닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/20242942닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/20242885오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/20242988오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20242867닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/20243212Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20243286디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20243232오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20243505닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20243390디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20244181오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20243472닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20243143Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20243238Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20243558닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20243147VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20243212닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20243248닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...