Microsoft MVP성태의 닷넷 이야기
.NET Framework: 763. .NET Core 2.1 - Tiered Compilation 도입 [링크 복사], [링크+제목 복사]
조회: 2455
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

.NET Core 2.1 - Tiered Compilation 도입

아래의 글에 tiered compilation에 대한 소개가 있습니다.

Announcing .NET Core 2.1
; https://blogs.msdn.microsoft.com/dotnet/2018/05/30/announcing-net-core-2-1/

"Adaptive optimization"이라고도 알려진 이것의 개념은 간단합니다. 이 옵션이 켜져 있으면 해당 응용 프로그램은 JIT 컴파일 시에 최적화보다는 빠른 속도를 위주로 기계어 번역을 하게 됩니다. 이 단계를 "first tier"라고 합니다. 그러다, 자주 실행되는 메서드가 있으면 그에 대해 감지하고 다시 최적화된 코드로 JIT 컴파일을 하는 식인데 이를 "second tier"라고 합니다.

과거 자바 런타임이 했던 방식과 유사한 면이 있습니다. 자바의 경우 최초 실행 시에 JIT하지 않고 바이트 언어를 그냥 인터프리팅 식으로 그때그때 해석해서 실행하는데, 자주 실행되는 함수라고 판단이 되면 그제서야 JIT를 해 기계어로 번역하는 식입니다.

"tiered compilation" 적용 방법은 프로젝트 파일에 TieredCompilation 옵션을 true로 설정하거나,

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <Description>A simple .NET Core global tool called "dotnetsay".</Description>
    ...[생략]...
    <TieredCompilation>true</TieredCompilation>
  </PropertyGroup>

  <ItemGroup Condition="'$(ContinuousIntegrationBuild)'=='true'">
    <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0-beta-62925-02" PrivateAssets="All"/>
  </ItemGroup>

</Project>

.NET Core 2.1 이상의 응용 프로그램을 실행 시 환경 변수에 COMPlus_TieredCompilation을 "1"로 설정하면 됩니다.

SET COMPlus_TieredCompilation="1"




혹시 눈으로 직접 확인해 볼 수 있을까요? ^^

그래서 예제 코드를 하나 준비해봤습니다.

using System;
using System.Reflection;
using System.Threading;

namespace ConsoleApp1
{
    // 빌드: .NET Core x64 + Release
    class Program
    {
        static void Main(string[] args)
        {
            Thread t = new Thread(CheckMethodJitAddress);
            t.IsBackground = true;

            Program pg = new Program();

            {
                pg.ManyCalls();
                CheckMethodJitAddress(false);
            }

            Console.ReadLine(); // first-tier 확인을 위해!
            t.Start(true);

            Thread.Sleep(1000);

            while (true)
            {
                pg.ManyCalls(); // 아마 이 루프의 어디선가 second-tier로 진행할 듯!
                Thread.Sleep(1000);
            }
        }

        public long ManyCalls()
        {
            long sum = 0;

            for (int i = 0; i < (Environment.TickCount % 10_000); i ++)
            {
                sum += i;
            }

            return sum;
        }

        private static void CheckMethodJitAddress(object obj)
        {
            do
            {
                MethodInfo mi = typeof(Program).GetMethod("ManyCalls");
                RuntimeMethodHandle rmh = mi.MethodHandle;

                Console.WriteLine(rmh.GetFunctionPointer().ToString("x"));
                Thread.Sleep(1000);
            } while ((bool)obj == true);
        }
    }
}

위의 코드를 실행하면, ManyCalls라는 메서드를 1초에 한 번씩 계속 실행하는데 다른 스레드에서는 그것의 FunctionPointer를 구해,

상황별 GetFunctionPointer 반환값 정리
; https://www.sysnet.pe.kr/2/0/1027

출력합니다. JIT가 2번째가 되면 FunctionPointer의 주소가 바뀔 거라고 생각한 건데요, 의외로 계속 바뀌지 않고 그냥 고정된 값을 출력합니다. 음... ^^ 딴 방법을 이용해야 할 것 같습니다.

이를 위해 windbg를 이용해 봤는데요, sos 확장을 로드하고,

0:009> .loadby sos coreclr

ManyCalls의 JIT 이후의 기계어 코드 위치를 다음과 같이 확인할 수 있습니다.

0:009> !name2ee ConsoleApp1!ConsoleApp1.Program
Module:      00007ff7b2024578
Assembly:    ConsoleApp1.dll
Token:       0000000002000002
MethodTable: 00007ff7b2025560
EEClass:     00007ff7b21c1088
Name:        ConsoleApp1.Program

0:009> !dumpmt -md  00007ff7b2025560
EEClass:         00007ff7b21c1088
Module:          00007ff7b2024578
Name:            ConsoleApp1.Program
mdToken:         0000000002000002
File:            E:\ConsoleApp1\bin\Release\netcoreapp2.1\ConsoleApp1.dll
BaseSize:        0x18
ComponentSize:   0x0
Slots in VTable: 8
Number of IFaces in IFaceMap: 0
--------------------------------------
MethodDesc Table
           Entry       MethodDesc    JIT Name
00007ff807aa2020 00007ff807600988 PreJIT System.Object.ToString()
00007ff807aa2040 00007ff807600990 PreJIT System.Object.Equals(System.Object)
00007ff807aa2090 00007ff8076009b8 PreJIT System.Object.GetHashCode()
00007ff807aa20a0 00007ff8076009d8 PreJIT System.Object.Finalize()
00007ff7b21410b0 00007ff7b2025550    JIT ConsoleApp1.Program..ctor()
00007ff7b2141098 00007ff7b2025508    JIT ConsoleApp1.Program.Main(System.String[])
00007ff7b21410a0 00007ff7b2025520    JIT ConsoleApp1.Program.ManyCalls()
00007ff7b21410a8 00007ff7b2025538    JIT ConsoleApp1.Program.CheckMethodJitAddress(System.Object)

00007ff7b21410a0 값은 실제로 GetFunctionPointer가 반환한 값과 일치합니다. ManyCalls 메서드에 대해 좀더 살펴 보면,

0:009> !DumpMD /d 00007ff7b2025520
Method Name:          ConsoleApp1.Program.ManyCalls()
Class:                00007ff7b21c1088
MethodTable:          00007ff7b2025560
mdToken:              0000000006000002
Module:               00007ff7b2024578
IsJitted:             yes
Current CodeAddr:     00007ff7b2142010
Code Version History:
  CodeAddr:           00007ff7b2142010  (Tier 0)
  NativeCodeVersion:  0000000000000000

최초 한번 실행된 상태이기 때문에 "Tier 0" 단계임을 알 수 있습니다. 그리고 응용 프로그램을 계속 실행해 ManyCalls를 어느 정도 실행한 시점에 다시 windbg로 멈추고 덤프를 해보면,

0:010> !DumpMD /d 00007ff7b2025520
Method Name:          ConsoleApp1.Program.ManyCalls()
Class:                00007ff7b21c1088
MethodTable:          00007ff7b2025560
mdToken:              0000000006000002
Module:               00007ff7b2024578
IsJitted:             yes
Current CodeAddr:     00007ff7b21439e0
Code Version History:
  CodeAddr:           00007ff7b21439e0  (Tier 1)
  NativeCodeVersion:  000001e92a9693c0
  CodeAddr:           00007ff7b2142010  (Tier 0)
  NativeCodeVersion:  0000000000000000

보는 바와 같이 JIT CodeAddr 위치가 바뀌었고 Tier 1이라고 보여줍니다. 즉, 실제로 JIT가 대상 메서드에 대해 2번 발생한 것입니다.




그런데 GetFunctionPointer 반환값은 무엇일까요? Tier 1 단계에서 해당 위치를 역어셈블 해보면,

0:010> u 00007ff7b21410a0
00007ff7`b21410a0 e93b290000      jmp     00007ff7`b21439e0
...[생략]...

보는 바와 같이 jmp문의 위치가 바로 GetFunctionPointer의 값입니다. jmp 문의 기계어를 보면 e93b290000인데, 5바이트 중 첫 번째 e9이 jmp이고 이후의 4바이트가 점프할 상대 변위(offset) 값입니다.

jmp     == e9
offset  == 3b290000

실제로 GetFunctionPointer가 반환한 00007ff7b21410a0 주소와 "!dumpmd"로 확인한 "Current CodeAddr"의 00007ff7b21439e0 주소의 차이를 보면,

0:010> ? 00007ff7`b21439e0 - 00007ff7`b21410a0
Evaluate expression: 10560 = 00000000`00002940

0:010> ? 00007ff7`b21439e0 - 00007ff7`b21410a0 - 5
Evaluate expression: 10555 = 00000000`0000293b

0000293b 값이 나옵니다. little endian 저장임을 감안하면 e93b290000 기계어 코드와 정확히 일치합니다.




windbg를 통해 알게 된 지식으로 이제 C#에서의 확인 코드를 다음과 같이 작성할 수 있습니다.

private static void CheckMethodJitAddress(object obj)
{
    do
    {
        MethodInfo mi = typeof(Program).GetMethod("ManyCalls");
        RuntimeMethodHandle rmh = mi.MethodHandle;

        IntPtr ptr = rmh.GetFunctionPointer();

        byte jmpCode = Marshal.ReadByte(ptr);    // jmp 문
        int offset = Marshal.ReadInt32(ptr + 1); // offset 값

        Console.WriteLine(jmpCode.ToString("x") + ": " + offset.ToString("x8"));

        Thread.Sleep(1000);
    } while ((bool)obj == true);
}

이렇게 바꾸고 실행하면 다음과 같은 출력 결과를 볼 수 있습니다.

called: 1
e9: 0000108b
e8: 0000041b
called: 2
e8: 0000041b
e8: 0000041b
...[생략]...
called: 28
e8: 0000041b
called: 29
e8: 0000041b
called: 30
e9: 0000392b
called: 31

보면 다음과 같은 공통점이 나옵니다.

1번째 호출: e9 0000108b
2번째 ~ 29번째 호출: e8 0000041b
30번째 호출: e9 0000392b

실제로 저 단계별로 windbg에서 점프 위치에 대한 값을 확인해 보면,

[1번째 호출]
0:010> u 00007ff7`ad9710a0
00007ff7`ad9710a0 e98b100000      jmp     00007ff7`ad972130
...[생략]...


[2번째 ~ 29번째 호출]
0:010> u 00007ff7`ad9710a0
00007ff7`ad9710a0 e8fbd4ab5f      call    coreclr!PrecodeFixupThunk (00007ff8`0d42e5a0)
...[생략]...


[30번째 호출]
0:010> u 00007ff7`ad9710a0
00007ff7`ad9710a0 e96b340000      jmp     00007ff7`ad974510
...[생략]...

위의 결과를 바탕으로 대략 결론이 유추됩니다. 처음 메서드 호출 시 Tier-0 JIT를 빠르게 한 다음 그 이후의 호출에서는 최적화 JIT을 하기 보다는 최적화를 할 조건을 갖출 때까지의 판단 코드가 있는 PrecodeFixupThunk를 경유해서 호출이 되다가 30번째 호출이 되었을 때 비로소 Tier-1 JIT를 하게 되는 것입니다.

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




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 6/8/2018 ]

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

비밀번호

댓글 쓴 사람
 




... 16  17  18  19  20  21  22  23  24  25  26  27  28  [29]  30  ...
NoWriterDateCnt.TitleFile(s)
11587정성태7/5/20182311.NET Framework: 786. ASP.NET - HttpCookieCollection을 다중 스레드에서 사용할 경우 무한 루프 현상
11586정성태7/5/20182762Math: 37. GeoGebra 기하 (14) - 삼각형의 무게 중심파일 다운로드1
11585정성태7/5/20182757Math: 36. GeoGebra 기하 (13) - 삼각형의 외심과 외접하는 원파일 다운로드1
11584정성태7/5/20183239Math: 35. GeoGebra 기하 (12) - 삼각형의 내심과 내접하는 원파일 다운로드1
11583정성태7/5/20182044.NET Framework: 785. public으로 노출되지 않은 다른 어셈블리의 delegate 인스턴스를 Reflection으로 생성하는 방법파일 다운로드1
11582정성태5/8/20193661.NET Framework: 784. C# - 제네릭 인자를 가진 타입을 생성하는 방법 [1]파일 다운로드1
11581정성태7/4/20183219Math: 34. GeoGebra 기하 (11) - 3대 작도 불능 문제의 하나인 임의 각의 3등분파일 다운로드1
11580정성태7/4/20182390Math: 33. GeoGebra 기하 (10) - 직각의 3등분파일 다운로드1
11579정성태7/4/20182581Math: 32. GeoGebra 기하 (9) - 임의의 선분을 한 변으로 갖는 정삼각형파일 다운로드1
11578정성태7/3/20182553Math: 31. GeoGebra 기하 (8) - 호(Arc)의 이등분파일 다운로드1
11577정성태7/3/20182890Math: 30. GeoGebra 기하 (7) - 각의 이등분파일 다운로드1
11576정성태7/3/20182643Math: 29. GeoGebra 기하 (6) - 대수의 4칙 연산파일 다운로드1
11575정성태7/2/20183137Math: 28. GeoGebra 기하 (5) - 선분을 n 등분하는 방법파일 다운로드1
11574정성태7/2/20182610Math: 27. GeoGebra 기하 (4) - 선분을 n 배 늘이는 방법파일 다운로드1
11573정성태7/2/20182501Math: 26. GeoGebra 기하 (3) - 평행선
11572정성태7/1/20182239.NET Framework: 783. C# 컴파일러가 허용하지 않는 (유효한) 코드를 컴파일해 테스트하는 방법
11571정성태7/1/20182304.NET Framework: 782. C# - JIRA에 등록된 Project의 Version 항목 추가하는 방법파일 다운로드1
11570정성태7/2/20183490Math: 25. GeoGebra 기하 (2) - 임의의 선분과 특정 점을 지나는 수직선파일 다운로드1
11569정성태7/1/20182951Math: 24. GeoGebra 기하 (1) - 수직 이등분선파일 다운로드1
11568정성태7/12/20185458Math: 23. GeoGebra 기하 - 컴퍼스와 자를 이용한 작도 프로그램 [1]
11567정성태6/28/20182727.NET Framework: 781. C# - OpenCvSharp 사용 시 포인터를 이용한 속도 향상파일 다운로드1
11566정성태6/28/20185414.NET Framework: 780. C# - JIRA REST API 사용 정리 [4]파일 다운로드1
11565정성태6/28/20182880.NET Framework: 779. C# 7.3에서 enum을 boxing 없이 int 변환하기 - 세 번째 이야기파일 다운로드1
11564정성태6/27/20182970.NET Framework: 778. (Unity가 사용하는) 모노 런타임의 __makeref 오류
11563정성태6/27/20182613개발 환경 구성: 386. .NET Framework Native compiler 프리뷰 버전 사용법
11562정성태6/26/20182314개발 환경 구성: 385. 레지스트리에 등록된 원격지 스크립트 COM 객체 실행 방법
... 16  17  18  19  20  21  22  23  24  25  26  27  28  [29]  30  ...