Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일

C# - 고성능이 필요한 환경에서 GC가 발생하지 않는 네이티브 힙 사용

지난 발표에서,

.NET Conf 2019 Korea - "닷넷 17년의 변화 정리 및 닷넷 코어 3.0" 발표 자료
; https://www.sysnet.pe.kr/2/0/12030

Span을 설명하며 GC를 유발하지 않는 Native Heap 사용법을 소개했습니다.

public unsafe ref struct NativeMemory<T> where T : unmanaged
{
    int _size;
    IntPtr _ptr;

    public NativeMemory(int size)
    {
        _size = size;

        long lSize = _size;
        lSize *= sizeof(T);
                
        IntPtr bufSize = new IntPtr(lSize);
        _ptr = Marshal.AllocHGlobal(bufSize);
    }

    public Span<T> GetView()
    {
        return new Span<T>(_ptr.ToPointer(), _size);
    }

    // C# 8.0에서만 using과 함께 사용 가능
    public void Dispose()
    {
        if (_ptr == IntPtr.Zero)
        {
            return;
        }

        Marshal.FreeHGlobal(_ptr);
        _ptr = IntPtr.Zero;
    }
}

그런데... 정작 PPT에는 설명이 없어 이렇게 글로 남깁니다. ^^




저렇게 Native Heap에 만들어 사용했을 때의 장점이 뭘까요? 우선, 당연한 이야기지만 GC로부터 힙을 할당받지 않았기 때문에 GC의 관리 밖에 있으므로 가비지 컬렉션 동작 시에 아무런 부하를 주지 않는다는 것을 들 수 있습니다.

이런 결과를 비교한 것이 DotNetHistory17.zip에 포함된 예제 코드의 내용인데요, 간단하게 다음과 같이 GC 횟수를 출력하는 스레드를 실행해 두고,

static unsafe void Main(string[] args)
{
    Thread t = new Thread(checkGCFunc);
    t.IsBackground = true;
    t.Start();

    // ...[생략]...
}

private static void checkGCFunc(object obj)
{
    int old = 0;
    int checkCount = 0;

    // 5초마다 화면에 GC 횟수 출력
    while (true)
    {
        int count = 0;

        for (int i = 0; i < GC.MaxGeneration; i++)
        {
            count += GC.CollectionCount(i);
        }

        Console.WriteLine($"{checkCount++} : {(count - old)}");
        old = count;

        Thread.Sleep(5000);
    }
}


GC Heap으로부터 할당받는 다음의 무한 루프 예제를 실행하면,

static unsafe void Main(string[] args)
{
    Thread t = new Thread(checkGCFunc);
    t.IsBackground = true;
    t.Start();

    // 무한 루프를 돌며,
    while (true)
    {
        // GC Heap, 즉 관리 힙으로부터 배열 메모리를 할당
        int[] buf = new int[1024];
        {
            for (int i = 0; i < buf.Length; i++)
            {
                buf[i] = i;
            }
        }
    }
}

화면에는 5초마다 다음과 같은 식으로 GC 횟수가 평균 초당 2,000번 이상 실행되는 것을 확인할 수 있습니다.

0 : 0
1 : 2226
2 : 2149
3 : 2308
4 : 2279
5 : 2289
...

반면, Native Heap으로부터 할당받는 NativeMemory 타입을 활용하면,

// 무한 루프를 돌며,
while (true)
{
    // Native Heap, 즉 비-관리 힙으로부터 배열 메모리 할당
    using (NativeMemory<int> buf = new NativeMemory<int>(1024))
    {
        Span<int> viewBuf = buf.GetView();
        for (int i = 0; i < viewBuf.Length; i++)
        {
            viewBuf[i] = i;
        }
    }
}

5초마다 찍히는 출력에는 GC가 단 한 번도 발생하지 않는 것을 볼 수 있습니다.

0 : 0
1 : 0
2 : 0
3 : 0
...




그런데, 사실 이런 식의 비-관리 메모리를 할당하는 것은 C# 초기 버전에서도 가능했습니다. 어차피 unsafe 문맥에서 포인터 구문이 가능했기 때문인데, 이에 대해서는 예전 글을 통해 설명한 적이 있습니다.

int len = Int32.MaxValue;
IntPtr pBuf = Marshal.AllocCoTaskMem(len); // 비-관리 힙을 할당받아,

byte* ptr = (byte*)pBuf.ToPointer();

int i = 0;
for (i = 0; i < len; i++)
{
    *(ptr + i) = 10; // 배열처럼 접근
}

Console.WriteLine(*(ptr + len - 1));
Console.WriteLine();

Marshal.FreeCoTaskMem(pBuf);

그런데, 위와 같은 식으로 직접 Pointer 연산을 통해 접근하는 것은 자칫 인덱스 접근을 잘못하게 되는 경우 AV(Access Violation) 예외가 발생해 프로세스(EXE)의 비정상 종료 문제를 야기할 수 있습니다.

가령, AllocCoTaskMem으로 1,000 바이트를 할당받았는데 byte * 포인터의 "*ptr + 1001" 연산을 하면 확률(운)에 따라 AV 예외를 접하게 됩니다. 이로 인해 비-관리 메모리는 사실상 "관리 프로세스"의 안전함에 반하므로 가능한 쓰지 않는 것이 일반적이었는데, 이런 문제를 해결한 것이 바로 C# 7.2에 추가된 Span 타입입니다.

C# 7.2 - Span<T>
; https://www.sysnet.pe.kr/2/0/11534

Span 타입은 비-관리 메모리에 대해 관리 포인터를 이용한 안정성을 제공하기 때문에 할당받은 Native Heap의 크기를 벗어나는 연산을 해도,

IntPtr ptr = Marshal.AllocCoTaskMem(1000); // native heap으로부터 메모리를 할당받아,

try
{
    // Span 타입의 도움을 받으면,
    Span<byte> bytes = new Span<byte>(ptr.ToPointer(), size);
    bytes[1000 + 1] = 6; // 할당받은 native heap의 범위를 벗어나 지정해도,
}
catch (System.IndexOutOfRangeException ex) // 안전하게 예외 처리
{
    // "1000 + 1" 접근 시 예외 발생
}
finally
{
    Marshal.FreeCoTaskMem(ptr);
}

안전하게 예외 처리가 됩니다. 따라서 Span 타입의 도입으로 비-관리 메모리를 안전한 영역으로 끌어냈기 때문에 C# 7.2부터는 관리 메모리와 별다른 차이 없이 - 개발자가 원한다면 얼마든지 사용해도 좋은 자원이 된 것입니다.




그나저나, GC Heap을 사용하지 않으니 혹시 gcAllowVeryLargeObjects를 사용하지 않아도,

<gcAllowVeryLargeObjects> Element
; https://docs.microsoft.com/ko-kr/dotnet/framework/configure-apps/file-schema/runtime/gcallowverylargeobjects-element

NativeMemory와 같은 타입이라면 자유로운 배열 크기를 생성할 수 있지 않을까요? 일단 이전 글에서 설명한 것처럼,

닷넷 - 배열 크기의 한계
; https://www.sysnet.pe.kr/2/0/11142

재현 코드)
int arrCount = 0X7FEFFFFF + 1;
int[] intarr1 = new int[arrCount]; // System.OutOfMemoryException: 'Array dimensions exceeded supported range.'

닷넷의 경우 배열 (크기가 아닌) 요소의 한계가 2,146,435,071 (0X7FEFFFFF)로 정해져 있습니다. 아쉽게도 이 한계는 NativeMemory 같은 식의 타입을 사용해 우회해도 극복할 수 없습니다. 왜냐하면 Span의 indexer 코드 자체가 이미 int 값을 인자로 받기 때문에,

public readonly ref struct Span<T>
{
    // ...[생략]...

    public ref T this[int index]
    {
        get
        {
            throw null;
        }
    }

    // ...[생략]...
}

Int32.MaxValue 범위 밖의 요소를 지정할 수 없습니다. 그래도 그나마 위로할 수 있는 것은 0X7FEFFFFF이 아닌 Int32.MaxValue 범위까지 쪼끔 확장되었다는 정도가 되겠습니다.




그런데, 이걸 사용하면 정말 빠를까요? 실제로 간단하게 테스트를 해보면,

class Program
{
    static unsafe void Main(string[] args)
    {
        int bufSize = 1024;

        Action<int> a1 = (count) =>
        {
            while (count-- > 0)
            {
                int[] buf = new int[bufSize];
                buf[0] = 0;
                buf[bufSize - 1] = 0;
            }
        };

        Action<int> a2 = (count) =>
        {
            while (count-- > 0)
            {
                using (NativeMemory<int> buf = new NativeMemory<int>(bufSize))
                {
                    Span<int> viewBuf = buf.GetView();
                    viewBuf[0] = 0;
                    viewBuf[bufSize - 1] = 0;
                }
            }
        };

        Action<int, Action<int>> perfTest = (count, action) =>
        {
            Stopwatch st = new Stopwatch();
            st.Start();
            action(count);
            st.Stop();

            Console.WriteLine(st.ElapsedMilliseconds);
        };

        perfTest(1, a1);
        perfTest(1, a2);

        perfTest(1000000, a1);
        perfTest(1000000, a2);
    }
}

의외로 그냥 GC가 발생하도록 했을 때와 그다지 큰 차이는 없습니다.

[x64 + Release]

관리 힙 = 483
NativeHeap = 102

왜냐하면, 이것은 해당 예제 코드가 그다지 복잡한 상황이 아니어서 2세대 GC까지 수행되지 않으므로 그런 것입니다. 2세대 GC가 발생하도록 위의 예제 코드에서 bufSize = 40960으로 바꾸면 다음과 같은 결과를 얻을 수 있습니다.

[x64 + Release]

관리 힙 = 8848
NativeHeap = 275

관리 힙의 경우 2세대 GC 처리를 동반하면서 9초 가까운 실행 시간이 걸린 반면 비-관리 힙을 사용한 경우 275ms 내에 처리를 끝내고 있습니다. 이 정도면, Game Loop 등과 같은 고속 처리를 요구하는 환경 등에서 써먹으면 꽤나 성능 향상을 기대할 수 있을 것입니다.

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




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





[최초 등록일: ]
[최종 수정일: 10/21/2019 ]

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

비밀번호

댓글 쓴 사람
 




1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12133정성태2/7/2020219디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태2/20/2020344.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기)파일 다운로드1
12131정성태1/27/2020328개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법
12130정성태1/26/2020188VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/2020553.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법
12128정성태1/26/2020198오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
12127정성태1/28/2020265.NET Framework: 881. C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)파일 다운로드1
12126정성태1/25/2020230.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
12125정성태1/24/2020137VS.NET IDE: 141. IDE0019 - Use pattern matching
12124정성태1/24/2020427VS.NET IDE: 140. IDE1006 - Naming rule violation: These words must begin with upper case characters: ...
12123정성태1/23/2020217웹: 39. Google Analytics - gtag 함수를 이용해 페이지 URL 수정 및 별도의 이벤트 생성 방법
12122정성태1/22/2020238.NET Framework: 879. C/C++의 UNREFERENCED_PARAMETER 매크로를 C#에서 우회하는 방법(IDE0060 - Remove unused parameter '...')파일 다운로드1
12121정성태1/24/2020170VS.NET IDE: 139. Visual Studio - Error List: "Could not find schema information for the ..."파일 다운로드1
12120정성태1/20/2020267.NET Framework: 878. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 네 번째 이야기(IL 코드로 직접 구현)파일 다운로드1
12119정성태1/17/2020294디버깅 기술: 160. Windbg 확장 DLL 만들기 (3) - C#으로 만드는 방법
12118정성태1/17/2020281개발 환경 구성: 466. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 세 번째 이야기
12117정성태1/15/2020258디버깅 기술: 159. C# - 디버깅 중인 프로세스를 강제로 다른 디버거에서 연결하는 방법파일 다운로드1
12116정성태1/15/2020218디버깅 기술: 158. Visual Studio로 디버깅 시 sos.dll 확장 명령어를 (비롯한 windbg의 다양한 기능을) 수행하는 방법
12115정성태1/14/2020178디버깅 기술: 157. C# - PEB.ProcessHeap을 이용해 디버깅 중인지 확인하는 방법파일 다운로드1
12114정성태1/13/2020375디버깅 기술: 156. C# - PDB 파일로부터 심벌(Symbol) 및 타입(Type) 정보 열거 [1]파일 다운로드3
12113정성태1/12/2020357오류 유형: 590. Visual C++ 빌드 오류 - fatal error LNK1104: cannot open file 'atls.lib'
12112정성태1/12/2020153오류 유형: 589. PowerShell - 원격 Invoke-Command 실행 시 "WinRM cannot complete the operation" 오류 발생
12111정성태3/23/2020543디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification) [1]
12110정성태1/12/2020274디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례파일 다운로드1
12109정성태1/10/2020203오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/2020151오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...