Microsoft MVP성태의 닷넷 이야기
닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성 [링크 복사], [링크+제목 복사],
조회: 3789
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 3개 있습니다.)
.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개
; https://www.sysnet.pe.kr/2/0/12538

닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성
; https://www.sysnet.pe.kr/2/0/13537

닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성
; https://www.sysnet.pe.kr/2/0/13538




C# - NonGC(FOH) 영역에 .NET 개체를 생성

지난 글에서,

C# - Native 메모리에 .NET 개체를 생성
; https://www.sysnet.pe.kr/2/0/13537

.NET 개체를 임의로 네이티브 메모리에 생성하는 방법을 알아봤는데요, 재미있는 건 마이크로소프트도 이미 저 방식을 CLR 내부에서 사용하고 있었다는 점입니다. 그런 의미에서 FOH를 다시 한번 읽어보시면,

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

이번엔 새롭게 해석이 될 것입니다. 그리고 저 2개의 글을 이해하셨다면, 이제 아래의 글이 더욱 재미있을 것입니다. ^^

Exploring .NET frozen segments
; https://minidump.net/exploring-frozen-segments/

현재 FOH는 마이크로소프트 내부에서만 사용하고 있을 텐데, 위의 글에서는 숨겨져 있는 메서드를 사용해 우리도 FOH를 등록/해제할 수 있는 방법을 소개하고 있습니다.

핵심은 공개되지 않은 메서드 2개인데요, 따라서 현재는 Reflection으로 이렇게 감싸야 합니다.

using System.Reflection;

namespace ConsoleApp1;

internal class GCExtension
{
    internal static IntPtr RegisterFrozenSegment(IntPtr sectionAddress, nint sectionSize)
    {
        return (IntPtr)typeof(GC).GetMethod("_RegisterFrozenSegment", BindingFlags.NonPublic | BindingFlags.Static)!
            .Invoke(null, [sectionAddress, sectionSize])!;
    }

    internal static void UnregisterFrozenSegment(IntPtr segment)
    {
        typeof(GC).GetMethod("_UnregisterFrozenSegment", BindingFlags.NonPublic | BindingFlags.Static)!
            .Invoke(null, [segment]);
    }
}

그럼 ^^ 위의 메서드를 이용해서 지난 글에서처럼 닷넷 개체를 FOH에 등록해 볼까요? 이번엔 MyObject 사용자 개체 대신 문자열을 생성해 볼 텐데요, 코드는 다음과 같이 정리할 수 있습니다.

// https://minidump.net/exploring-frozen-segments/
public class StringExtension
{
    public static int GetAllocatedStringSize(ReadOnlySpan<char> data)
    {
        int headerSize = IntPtr.Size + IntPtr.Size + sizeof(int); // object header + method-table ptr + len(string)
        return headerSize + ((data.Length + 1) * sizeof(char));
    }

    public static unsafe string AllocateString(void* address, ReadOnlySpan<char> data)
    {
        var ptr = (byte*)address;

        // Write the header
        *(nint*)ptr = 0;
        ptr += sizeof(nint);

        // Retrieve the method-table pointer
        var mt = typeof(string).TypeHandle.Value;

        // Write it
        *(nint*)ptr = mt;
        ptr += sizeof(nint);

        *(int*)ptr = data.Length;
        ptr += sizeof(int);

        var destination = new Span<char>(ptr, data.Length + 1);

        data.CopyTo(destination);
        destination[^1] = '\0';

        var strRef = (nint)address + sizeof(nint);
        return Unsafe.As<nint, string>(ref strRef);
    }
}

이를 이용해 네이티브 메모리를 할당한 후 문자열 복사를 다음과 같이 할 수 있습니다.

string text = new string('c', short.MaxValue * 2);

int objectSize = StringExtension.GetAllocatedStringSize(text);

/* NativeMemory.AlignedAlloc
The current design of CoreCLR's FrozenObjectHeapManager has certain design limitations such as:
    * Large objects are not supported.
    * Objects requiring unusual data alignment are not supported.
*/
var allocated = NativeMemory.AlignedAlloc((nuint)objectSize, (nuint)IntPtr.Size);
NativeMemory.Clear(allocated, (nuint)objectSize);

// textOnNative == 네이티브 메모리에 보관한 문자열 개체
string textOnNative = StringExtension.AllocateString(allocated, text);

마지막으로, 저렇게 구성한 네이티브 메모리를 FOH에 등록만 해주면 됩니다.

var segment = GCExtension.RegisterFrozenSegment((IntPtr)allocated, objectSize);

fixed (char* ptr = textOnNative)
{
    Console.WriteLine($"address of text: {(nint)ptr:x}");
}

Console.WriteLine($"address of AlignedAlloc: {(nint)allocated:x}");
Console.WriteLine($"address of FOH: {segment:x}");

Console.WriteLine("Press any key to exit...");
Console.ReadLine();

GCExtension.UnregisterFrozenSegment(segment);

실행 시 중간에 넣어둔 출력 결과가 이렇게 나오고,

address of text: 1e48045f18c
address of AlignedAlloc: 1e48045f178
address of FOH: 1e4e3b2d9d0

이와 함께 Console.ReadLine으로 걸렸을 때 windbg로 연결하면 이런 결과가 나옵니다.

0:014> !eeheap
...[생략]...
========================================
Number of GC Heaps: 1
----------------------------------------
Small object heap
         segment            begin        allocated        committed allocated size   committed size  
generation 0:
    0224f990f320     01e4e8400028     01e4e841f0e0     01e4e8421000 0x1f0b8 (127160) 0x21000 (135168)
generation 1:
    0224f990f270     01e4e8000028     01e4e8000028     01e4e8001000                  0x1000 (4096)   
generation 2:
    0224f990f1c0     01e4e7c00028     01e4e7c00028     01e4e7c01000                  0x1000 (4096)   
Frozen object heap
         segment            begin        allocated        committed allocated size   committed size  
    01e4e3aa7620     01e480000008     01e480003d30     01e480010000 0x3d28 (15656)   0x10000 (65536) 
    01e4e3b2d9d0     01e48045f180     01e48047f18a     01e48047f18a 0x2000a (131082) 0x20012 (131090)
Large object heap
         segment            begin        allocated        committed allocated size   committed size  
    0224f990f3d0     01e4e8800028     01e4e8820060     01e4e8821000 0x20038 (131128) 0x21000 (135168)
Pinned object heap
         segment            begin        allocated        committed allocated size   committed size  
    0224f990ec40     01e4e5c00028     01e4e5c07ff0     01e4e5c11000 0x7fc8 (32712)   0x11000 (69632) 
------------------------------
GC Allocated Heap Size:    Size: 0x6adea (437738) bytes.
GC Committed Heap Size:    Size: 0x85012 (544786) bytes.

Total bytes consumed by CLR: 0x39c012 (3784722)

우리가 출력한 "address of FOH"의 값이 segment 칼럼 값에 해당하고, "address of AlignedAlloc"에 +8을 한 값이 "begin" 칼럼으로 사용되고 있습니다. 그러니까, Object Header를 넘어서 Method Table을 가리키는 첫 번째 개체의 위치를 "begin"으로 나타내고 있는 것입니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




FOH의 특성상 불멸 객체만 담아둔다고 했는데요, 따라서 관리 개체의 메모리 구조만 맞춰서 저렇게 만들어 두면 GC의 영향도 받지 않으니 속도 향상에 나름 기여할 수 있습니다. 게다가 이를 기반으로 FOH 영역임을 런타임에서 인식할 수 있다면 RyuJit의 입장에서도 그 영역에 담긴 개체들은 불멸할 것임을 보증 받을 수 있으므로 코드 생성에 유리했을 것으로 추측이 됩니다.

그런데, 그런 의도와는 다르게 _RegisterFrozenSegment와 함께 _UnregisterFrozenSegment까지 만들어 두었다는 것이 재미있습니다. 물론 Unregister를 해도 영향은 없을 것입니다. 중요한 것은 네이티브 메모리를 해제만 하지 않으면 되기 때문인데, 어쨌든 닷넷 런타임 측에서도 아마 프로세스 종료 시점에나 Unregister/Free를 같이 하는 식이지 않을까 싶습니다.




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







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

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

비밀번호

댓글 작성자
 




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/20243128닷넷: 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/20242868닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/20242943닷넷: 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/20242869닷넷: 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/20243391디버깅 기술: 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/20243144Windows: 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/20243213닷넷: 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  ...