Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(번역글) .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가 구동되지 않게 됩니다.

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




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 8/12/2020 ]

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

비밀번호

댓글 쓴 사람
 



2020-08-12 03시57분
정성태
2020-08-12 04시49분
GC Pauses and Safe Points
; https://mattwarren.org/2016/08/08/GC-Pauses-and-Safe-Points/

1. GCSuspendEE_V1
2. GCSuspendEEEnd_V1 <-- suspension is done
3. GCStart_V1
4. GCEnd_V1 <-- actual GC is done
5. GCRestartEEBegin_V1
6. GCRestartEEEnd_V1 <-- resumption is done.

* Partially interruptible - can only be suspended at explicit GC poll locations (i.e. FC_GC_POLL calls) or when it calls into other methods.
* Fully interruptible - can be interrupted or suspended at any time
정성태

1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12126정성태1/25/2020656.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
12125정성태1/24/2020510VS.NET IDE: 141. IDE0019 - Use pattern matching
12124정성태1/24/20201149VS.NET IDE: 140. IDE1006 - Naming rule violation: These words must begin with upper case characters: ...
12123정성태1/23/2020909웹: 39. Google Analytics - gtag 함수를 이용해 페이지 URL 수정 및 별도의 이벤트 생성 방법
12122정성태1/22/2020814.NET Framework: 879. C/C++의 UNREFERENCED_PARAMETER 매크로를 C#에서 우회하는 방법(IDE0060 - Remove unused parameter '...')파일 다운로드1
12121정성태1/24/2020506VS.NET IDE: 139. Visual Studio - Error List: "Could not find schema information for the ..."파일 다운로드1
12120정성태1/20/2020775.NET Framework: 878. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 네 번째 이야기(IL 코드로 직접 구현)파일 다운로드1
12119정성태1/17/2020878디버깅 기술: 160. Windbg 확장 DLL 만들기 (3) - C#으로 만드는 방법
12118정성태1/17/2020880개발 환경 구성: 466. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 세 번째 이야기 [1]
12117정성태1/15/2020875디버깅 기술: 159. C# - 디버깅 중인 프로세스를 강제로 다른 디버거에서 연결하는 방법파일 다운로드1
12116정성태1/15/2020727디버깅 기술: 158. Visual Studio로 디버깅 시 sos.dll 확장 명령어를 (비롯한 windbg의 다양한 기능을) 수행하는 방법
12115정성태1/14/2020746디버깅 기술: 157. C# - PEB.ProcessHeap을 이용해 디버깅 중인지 확인하는 방법파일 다운로드1
12114정성태1/13/20201029디버깅 기술: 156. C# - PDB 파일로부터 심벌(Symbol) 및 타입(Type) 정보 열거 [1]파일 다운로드3
12113정성태1/12/20201455오류 유형: 590. Visual C++ 빌드 오류 - fatal error LNK1104: cannot open file 'atls.lib' [1]
12112정성태1/12/2020617오류 유형: 589. PowerShell - 원격 Invoke-Command 실행 시 "WinRM cannot complete the operation" 오류 발생
12111정성태3/23/20201656디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification) [12]
12110정성태6/23/20201104디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례 [5]파일 다운로드1
12109정성태1/10/2020835오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/2020670오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
12107정성태1/10/2020763.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
12106정성태1/8/2020861VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작 [1]
12105정성태1/8/2020790디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
12104정성태1/9/20201231DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [4]
12103정성태4/23/20202092DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
12102정성태1/6/20201339디버깅 기술: 152. User 권한(Ring 3)의 프로그램에서 _ETHREAD 주소(및 커널 메모리를 읽을 수 있다면 _EPROCESS 주소) 구하는 방법
12101정성태1/8/2020869.NET Framework: 876. C# - PEB(Process Environment Block)를 통해 로드된 모듈 목록 열람
1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...