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

(번역글) .NET Internals Cookbook Part 2 - GC-related things

이번에도 .NET Internals Cookbook 시리즈의 2번째 글을 번역한 것입니다.

(번역글) .NET Internals Cookbook Part 1 - Exceptions, filters and corrupted processes
; https://www.sysnet.pe.kr/2/0/11838

.NET Internals Cookbook Part 2 - GC-related things
; https://blog.adamfurmanek.pl/2019/02/23/net-internals-cookbook-part-2/

(번역글) .NET Internals Cookbook Part 3 - Initialization tricks
; https://www.sysnet.pe.kr/2/0/11871

(번역글) .NET Internals Cookbook Part 4 - Type members
; https://www.sysnet.pe.kr/2/0/11872

(번역글) .NET Internals Cookbook Part 5 - Methods, parameters, modifiers
; https://www.sysnet.pe.kr/2/0/11873

(번역글) .NET Internals Cookbook Part 6 - Object internals
; https://www.sysnet.pe.kr/2/0/11874

(번역글) .NET Internals Cookbook Part 7 - Word tearing, locking and others
; https://www.sysnet.pe.kr/2/0/11876

(번역글) .NET Internals Cookbook Part 8 - C# gotchas
; https://www.sysnet.pe.kr/2/0/11877

(번역글) .NET Internals Cookbook Part 9 - Finalizers, queues, card tables and other GC stuff
; https://www.sysnet.pe.kr/2/0/11878

(번역글) .NET Internals Cookbook Part 10 - Threads, Tasks, asynchronous code and others
; https://www.sysnet.pe.kr/2/0/11879

(번역글) .NET Internals Cookbook Part 11 - Various C# riddles
; https://www.sysnet.pe.kr/2/0/11882

(번역글) .NET Internals Cookbook Part 12 - Memory structure, attributes, handles
; https://www.sysnet.pe.kr/2/0/11891





7. LOH(Large Object Heap)의 Compaction 방법?

GC의 동작 원리를 모르는 분들에게는 Compaction을 압축이라고 번역하면 오해가 생길 듯하고, 축소라고 번역해도 왠지 Heap의 크기 자체를 축소한다는 것으로 또 오해가 생길 것 같은데요. 그런 분들을 위해 다음의 글 3개를 먼저 읽어보실 것을 권합니다. ^^

닷넷 가비지 컬렉션 다시 보기 - Part I 기본 작동 방식
; http://www.simpleisbest.net/post/2011/04/01/Review-NET-Garbage-Collection.aspx

닷넷 가비지 컬렉션 다시 보기 - Part II 세대별 가비지 콜렉션
; http://www.simpleisbest.net/post/2011/04/05/Generational-Garbage-Collection.aspx

닷넷 가비지 컬렉션 다시 보기 - Part III LOH
; http://www.simpleisbest.net/post/2011/04/11/Large-Object-Heap-Intro.aspx

위의 글을 읽었다는 가정으로, GC가 사용하지 않는 객체 공간을 살아 있는 객체들로 이동시켜 조밀하게 만드는 작업을 "축소"라고 설명할 수 있습니다. 축소 작업은 원래 GC 2세대 힙까지만 적용될 뿐 LOH에는 성능상의 문제로 하지 않았었습니다. 그러다 .NET 4.5.1부터 GCSettings.LargeObjectHeapCompactionMode 속성을 CompactOnce로 설정하면 다음 번 발생하는 Full GC 때 LOH를 축소하는 기능이 생긴 것입니다. 참고로 이 옵션은 기본적으로 비활성 상태이기 때문에 4.5.1에서도 명시적인 설정을 하지 않는 한 동작하지 않습니다.





8. LOH에 할당되는 객체는?

일반적으로 LOH에 할당되는 객체의 기준은 85,000 바이트 크기라고 알려져 있습니다. (그리고 그 크기는 향후 얼마든지 달라질 수 있다고 꼭 언급이 됩니다.) 재미있는 것은 32비트의 경우 double 타입의 배열이 요소가 1,000개 이상일 때 85,000 크기가 안 되는데도 LOH에 할당되는 것을 확인할 수 있습니다.

// 32비트 실행 (64비트에서는 모두 0)
Console.WriteLine(GC.GetGeneration(new double[998])); // 0
Console.WriteLine(GC.GetGeneration(new double[999])); // 0
Console.WriteLine(GC.GetGeneration(new double[1000])); // 2
Console.WriteLine(GC.GetGeneration(new double[1001])); // 2

Console.WriteLine(GC.GetGeneration(new float[998 * 2])); // 0
Console.WriteLine(GC.GetGeneration(new float[999 * 2])); // 0
Console.WriteLine(GC.GetGeneration(new float[1000 * 2])); // 0
Console.WriteLine(GC.GetGeneration(new float[1001 * 2])); // 0

그 이유는, LOH 힙이 항상 8바이트 정렬을 따르기 때문에 double 타입의 배열이 LOH에 할당되면 좀 더 성능이 좋아지기 때문이라고 합니다. 따라서 4바이트 정렬인 float 배열이라면 동일한 메모리 공간을 점유하는데도 LOH에 할당되지 않습니다. 반면 64비트에서는 double에 대한 이런 혜택이 없다고.





9. 코드 실행 중에 외부 요인으로 발생하는 예외를 막을 수 있을까?

여기서의 "외부 요인으로 발생하는 예외"란 코드 스스로 실행하는 중에 발생하는 null 참조 예외나 FileNotFound 예외 등이 아닌 OutOfMemoryException, StackOverflowException, ThreadAbortException으로 대표되는 Asynchronous exceptions을 의미합니다.

예를 들어, .NET 코드를 실행하는 A 스레드에 대해 다른 B 스레드에서 A 스레드로 ThreadAbortException을 발생시키는 경우 그 예외를 막을 수 있느냐는 것입니다. 마이크로소프트는 CLR 2부터 아래의 글에서 설명한,

CER(Constrained Execution Region)이란?
; https://www.sysnet.pe.kr/2/0/11868

CER을 사용해 그것이 가능하도록 만들었습니다.





10. GC되는 객체를 되살릴 수 있을까?

일반적으로는 GC되는 객체를 살릴 수 없지만, 해당 객체의 Finalize 메서드를 정의해 그 안에서 참조를 다시 유지해주는 코드를 넣는다면 살릴 수 있습니다.

using System;
using System.Runtime.CompilerServices;

namespace ConsoleApp1
{
    class Program
    {
        public static Foo StrongReference = null;

        static void Main(string[] args)
        {
            Created();

            while (true)
            {
                Console.WriteLine("Created, cleaning up.");
                GC.Collect();
                GC.WaitForPendingFinalizers();

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

                Program.StrongReference.Print();
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        private static void Created()
        {
            Foo foo = new Foo();
            foo = null;
        }
    }

    public class Foo
    {
        int n = 1;

        public void Print()
        {
            Console.WriteLine(n);
        }

        ~Foo()
        {
            Program.StrongReference = this;
            n++;
            Console.WriteLine("Finalizing...");
        }
    }
}

/*
실행 결과:

Created, cleaning up.
Finalizing...

Press any key to continue... <ENTER>

2

Press any key to continue... <ENTER>

2

Press any key to continue...
*/

보는 바와 같이, Finalizer(~Foo 메서드)에서 static 변수를 root 참조로 설정함으로써 GC가 되는 과정에서 다시 객체를 되살리고 있습니다. 재미를 위해, GC를 비켜나간 후에 다음 번 GC가 되기 전 Program.StrongReference = null을 설정하도록 바꾸면 어떻게 될까요?

static void Main(string[] args)
{
    Created();

    while (true)
    {
        Console.WriteLine("Created, cleaning up.");
        GC.Collect();
        GC.WaitForPendingFinalizers();

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

        Program.StrongReference.Print();
        Program.StrongReference = null;
    }
}

얼핏 생각하면, 이런 경우 GC가 될 때마다 반복적으로 ~Foo 메서드가 실행되어 계속 되살아나야 할 듯싶은데 실제로 해 보면 다음과 같이 두 번째 GC 후 예외가 발생합니다.

Created, cleaning up.
Finalizing...

Press any key to continue... <ENTER>

2

Press any key to continue... <ENTER>


Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
   at ConsoleApp1.Program.Main(String[] args) in C:\cookbook_part_2_gc\cookbook_series2_sample\q10\ConsoleApp1\Program.cs:line 24

이유는, ~Foo 메서드가 실행되지 않기 때문입니다. GC는 해당 객체가 생성되는 시점에 Finalizer를 종료 큐에 등록할 뿐 참조를 살렸다고 해서 제거한 Finalizer를 종료 큐에 다시 넣지는 않습니다. 따라서 한 번 GC 과정을 밟은 객체의 경우 종료 큐에서 Finalizer가 없어진 상태이므로 위의 코드에서는 ~Foo 소멸자가 두 번째부터는 실행되지 않는 것입니다.

대신 종료 큐에 GC.ReRegisterForFinalize 메서드를 이용해 다시 넣는 것도 가능합니다. 이를 이용해 소멸자를 다음과 같이 정의하면,

~Foo()
{
    Program.StrongReference = this;
    GC.ReRegisterForFinalize(this);
    n++;
    Console.WriteLine("Finalizing...");
}

이번에는 다음과 같은 결과를 볼 수 있습니다.

Created, cleaning up.
Finalizing...

Press any key to continue... <ENTER>

2
Finalizing...

Press any key to continue... <ENTER>

3
Finalizing...

Press any key to continue...





11. VM Hoarding 이란?

GC는 세대를 거듭하면서 힙의 크기가 커집니다. 그런데 Heap 메모리를 연속적인 선형 공간으로 단일하게 유지하는 것이 아니라 "Segment"라는 블록 단위로 유지합니다. 그래서 일정 크기의 Segment를 생성한 후 그것이 다 차게 되면 다시 Segment를 할당해서 Heap의 크기를 늘리는 식입니다. 그런데 Segment를 생성 후 객체를 할당하다가 GC가 되어 해당 Segment가 통째로 비어 있게 될 수도 있습니다. 그렇게 되면 CLR은 Segment 자체를 해제해 버립니다. 대개의 경우 이 동작이 문제가 없겠으나 대량의 객체를 자주 할당하고 해제하는 작업을 반복하는 상황이라면 잦은 Segment 생성/해제가 반복되어 성능에 영향을 줄 수 있습니다.

바로 이런 문제를 해결하기 위해 CLR 2.0부터 CLR 호스팅 시에 설정할 수 있는 STARTUP_HOARD_GC_VM 옵션을 제공합니다. 이 옵션이 설정되면, 비어 있는 Segment를 곧바로 해제하지 않고 대기 목록에 넣어 다음 번 Segment 요청 시 곧바로 대기 목록의 Segment를 반환해 사용할 수 있도록 합니다.

좀 더 자세한 사항은 다음의 글에서 확인할 수 있습니다.

Large Object Heap Uncovered (an old MSDN article)
; https://blogs.msdn.microsoft.com/maoni/2016/05/31/large-object-heap-uncovered-from-an-old-msdn-article/





12. GC를 끌 수 있을까?

GC.TryStartNoGCRegion 메서드를 호출하면 됩니다.

예를 들어 다음과 같이 호출하면,

bool result = GC.TryStartNoGCRegion(50_000, 10_000);
if (result == true)
{
    // do your work...
}

if (GCSettings.LatencyMode == GCLatencyMode.NoGCRegion)
{
   GC.EndNoGCRegion();
}

현재 LOH에 10,000 바이트의 여유 공간이 있고 일반 Segment에 40,000 바이트의 여유 공간이 있다면 GC.EndNoGCRegion 메서드가 호출되기까지 지정된 바이트 내의 메모리를 필요로 한다면 GC가 구동되지 않게 됩니다.

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




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 5/9/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)
11902정성태5/21/2019492오류 유형: 539. mstest 실행 시 "The directory name is invalid." 오류 발생
11901정성태5/21/2019820오류 유형: 538. msbuild 오류 - Could not find a part of the path '%LOCALAPPDATA%\Temp\2\.NETFramework,Version=v4.0.AssemblyAttributes.cs'
11900정성태5/18/2019757오류 유형: 537. "sfc /scannow" 실행 중 시스템이 부팅되는 현상
11899정성태5/17/2019937Linux: 9. Linux에서 윈도우의 OutputDebugString 대신 사용할 수 있는 syslog [1]
11898정성태5/20/2019824VC++: 130. C++ string의 c_str과 data 함수의 차이점 [3]
11897정성태5/16/20191412오류 유형: 536. Visual Studio - "Developer Pack"을 설치했는데도 "대상 프레임워크" 목록에 나오지 않는 경우 [1]
11896정성태5/15/2019949개발 환경 구성: 440. C#, C++ - double의 Infinity, NaN 표현 방식파일 다운로드1
11895정성태5/12/2019906.NET Framework: 832. ML.NET Model Builder - 회귀(Regression), 다중 분류(Multi-class classification) 예제파일 다운로드1
11894정성태5/12/20191209VS.NET IDE: 135. Visual Studio - ML.NET Model Builder 소개 [1]
11893정성태5/10/2019860오류 유형: 535. C# 6.0 이상의 문법을 컴파일 시 오류가 발생한다면?
11892정성태5/10/2019648웹: 38. HTTP Cookie의 expires 시간 형식(RFC7231)
11891정성태5/9/2019841.NET Framework: 831. (번역글) .NET Internals Cookbook Part 12 - Memory structure, attributes, handles
11890정성태5/8/2019656개발 환경 구성: 439. "Visual Studio Enterprise is required to execute the test." 메시지와 관련된 코드 기록
11889정성태5/8/2019697개발 환경 구성: 438. mstest, QTAgent의 로그 파일 설정 방법
11888정성태5/8/2019950.NET Framework: 830. C# - 비동기 호출을 취소하는 CancellationToken의 간단한 예제 코드파일 다운로드1
11887정성태5/8/2019948.NET Framework: 829. C# - yield 문을 사용할 수 있는 메서드의 조건
11886정성태5/8/2019949오류 유형: 534. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 [2]
11885정성태5/7/2019530오류 유형: 533. mstest.exe 실행 시 "File extension specified '.loadtest' is not a valid test extension." 오류 발생
11884정성태5/5/2019994.NET Framework: 828. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 두 번째 이야기
11883정성태5/3/20191068.NET Framework: 827. C# - 인터넷 시간 서버로부터 받은 시간을 윈도우에 적용하는 방법파일 다운로드1
11882정성태5/9/2019719.NET Framework: 826. (번역글) .NET Internals Cookbook Part 11 - Various C# riddles파일 다운로드1
11881정성태4/28/2019971오류 유형: 532. .NET Core 프로젝트로 마이그레이션 시 "CS0579 Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute" 오류 발생
11880정성태4/25/2019612오류 유형: 531. 이벤트 로그 오류 - Task Scheduling Error: m->NextScheduledSPRetry 1547, m->NextScheduledEvent 1547
11879정성태10/21/2019842.NET Framework: 825. (번역글) .NET Internals Cookbook Part 10 - Threads, Tasks, asynchronous code and others파일 다운로드1
11878정성태5/9/2019788.NET Framework: 824. (번역글) .NET Internals Cookbook Part 9 - Finalizers, queues, card tables and other GC stuff파일 다운로드1
11877정성태5/9/2019795.NET Framework: 823. (번역글) .NET Internals Cookbook Part 8 - C# gotchas파일 다운로드1
1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...