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)
12304정성태9/1/2020314개발 환경 구성: 505. 윈도우 - (네트워크 어댑터의 우선 순위로 인한) 열거되는 IP 주소 순서를 조정하는 방법
12303정성태8/30/2020344개발 환경 구성: 504. ETW - 닷넷 프레임워크 기반의 응용 프로그램을 위한 명령행 도구 etrace 소개
12302정성태8/30/2020230.NET Framework: 936. C# - ETW 관련 Win32 API 사용 예제 코드 (5) - Private Logger파일 다운로드1
12301정성태8/30/2020198오류 유형: 641. error MSB4044: The "Fody.WeavingTask" task was not given a value for the required parameter "IntermediateDir".
12300정성태8/29/2020193.NET Framework: 935. C# - ETW 관련 Win32 API 사용 예제 코드 (4) CLR ETW Consumer파일 다운로드1
12299정성태10/9/2020226.NET Framework: 934. C# - ETW 관련 Win32 API 사용 예제 코드 (3) ETW Consumer 구현파일 다운로드1
12298정성태8/27/2020196오류 유형: 640. livekd - Could not resolve symbols for ntoskrnl.exe: MmPfnDatabase
12297정성태8/25/2020195개발 환경 구성: 503. SHA256 테스트 인증서 생성 방법
12296정성태8/29/2020245.NET Framework: 933. C# - ETW 관련 Win32 API 사용 예제 코드 (2) NT Kernel Logger파일 다운로드1
12295정성태8/24/2020194오류 유형: 639. Bitvise - Address is already in use; bind() in ListeningSocket::StartListening() failed: Windows error 10013: An attempt was made to access a socket ,,,
12293정성태9/24/2020265Windows: 171. "Administered port exclusions" 설명
12292정성태8/29/2020343.NET Framework: 932. C# - ETW 관련 Win32 API 사용 예제 코드 (1)파일 다운로드2
12291정성태8/15/2020269오류 유형: 638. error 1297: Device driver does not install on any devices, use primitive driver if this is intended.
12290정성태8/11/2020581.NET Framework: 931. C# - IP 주소에 따른 국가별 위치 확인 [1]파일 다운로드1
12289정성태8/6/2020328개발 환경 구성: 502. Portainer에 윈도우 컨테이너를 등록하는 방법
12288정성태8/5/2020289오류 유형: 637. WCF - The protocol 'net.tcp' does not have an implementation of HostedTransportConfiguration type registered.
12287정성태8/5/2020216오류 유형: 636. C# - libdl.so를 DllImport로 연결 시 docker container 내에서 System.DllNotFoundException 예외 발생
12286정성태8/5/2020251개발 환경 구성: 501. .NET Core 용 container 이미지 만들 때 unzip이 필요한 경우
12285정성태8/4/2020335오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/26/2020387디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/2020258디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd)
12282정성태8/2/2020225디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/2020411개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/2020318오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생
12279정성태7/29/2020245개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태8/2/2020226VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...