.NET8極致效能最佳化Non-GC Heap

江湖評談發表於2023-11-25
GC

前言

.NET8裡面JIT引入了一個新的機制，叫做Non-GC Heap。JIT可以確保相關物件分配在Non-GC Heap上，該堆像其名稱一樣，不受GC管理。JIT需要保證這個物件沒有被GC引用，並且在這個物件的生命週期內一直是根物件(不會被GC消滅的物件)的狀態。原文:.NET8極致效能最佳化Non-GC Heap

概述

為什麼要引入這種機制？先來看一段程式碼:

public static string GetPrefix() => "https://";
static void Main(string[] args)
{
  GetPrefix ();
}

這裡的GetPrefix函式返回的是一個常量字串值，它的ASM如下:

mov  rax,185CAC02068h
mov  rax,qword ptr [rax]

兩個mov指令，第一個是物件指標的指標，第二個是物件的指標。雖然是簡單的兩個指令，但是背後的邏輯卻較為複雜，基本如下:
一個字串常量值，.NET7裡面JIT也會給這個字串常量值複製到一個堆分配到字串物件中，返回的是物件的二級指標。因為是堆物件，可能會被GC移動，每次都需要獲取新的地址，頻繁增加負擔。

這裡的問題在哪兒呢？一個字串常量值需要這麼多的步驟操作嗎？開銷是否太大，我們是否可以簡化它呢？有一個常規的很容易想到的方法，就是把這個字串常量值的地址給它固定起來，每次需要用到這個常量值，就直接去這個固定地址讀取，這樣行不行呢？GC堆很明顯不能硬編碼固定。

當然可以，做法就是把這個字串常量值放到POH(固定物件堆)上，不讓GC移動。這樣是減少了GC回收的時候移動的開銷，但是並沒有從根本上解決問題，因為固定物件同樣受到GC的管控，上面的步驟除了不能移動一樣不少，並且POH不會進行根物件的處理，可能會導致它們被回收，地址指向了其它的資料，進而錯誤。

特點

要徹底的解決這個問題，本篇的主角:Non-GC Heap出場了。它有三個特點:
1.JIT要保證這個物件沒有被GC引用
2.這個物件在生命週期內一直是根物件
3.它不能是可解除安裝上下文的一部分

你可以認為GC堆包括:小物件堆(SOH-小於85000位元組的物件），大物件堆(LOH-大於85000位元組的物件)，固定物件堆（POH）
而No-GC Heap超脫於GC Heap之外的FOH(凍結堆)。

JIT現在可以避免在生成的程式碼中訪問該物件時的間接定址，而是直接硬編碼物件的地址

GetPrefix函式的ASM在.NET8 Non-GC Heap裡面如下:

mov  rax,26180000218h
C3   ret

26180000218h為物件地址,一個mov直接返回。看似只簡化了一個mov,但是實際上它這種硬編碼固定模式地址，簡化的是整個字串常量值的原理，也就是把字串常量值分配到FOH裡面，而不是GC堆裡。效能極大的提升自不必多說。以下測量13倍的效能提升。

Method Job Mean Ratio
GetPrefix .NET 7 1.3450 ns
GetPrefix .NET 8 0.0729 ns

其它Non-GC Heap的操作

一:使用typeof(T)生成的RuntimeType物件

public Type GetTestsType() => typeof(Tests);

二:空陣列分配到Non-GC Heap上，使Array.Empty()更加高效

public string[] Test() => Array.Empty<string>();

它倆在.NET8裡面都類似於如下ASM，一個mov直接返回:

mov rax,1A0814EAEA8
ret

三:靜態值型別欄位關聯的堆物件，不包含任何GC引用的欄位

public partial class Tests
{
    private static readonly ConfigurationData s_config = ConfigurationData.ReadData();
    public TimeSpan GetRefreshInterval() => s_config.RefreshInterval;
    private struct ConfigurationData
    {
        public static ConfigurationData ReadData() => new ConfigurationData
        {
            Index = 0x12345,
            Id = Guid.NewGuid(),
            IsEnabled = true,
            RefreshInterval = TimeSpan.FromSeconds(100)
        };
        public int Index;
        public Guid Id;
        public bool IsEnabled;
        public TimeSpan RefreshInterval;
    }
}

RefreshInterval .NET7如下:

mov       rax,13D84001F78
mov       rax,[rax]
mov       rax,[rax+20]
ret

RefreshInterval .NET8如下:

mov       rax,20D9853AE48
mov       rax,[rax]
ret

四:代之間的GC引用判斷
程式碼:

public class Tests
{
    public void Write()
    {
        string dst = "old";
        Write(ref dst, "new");
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static void Write(ref string dst, string s) => dst = s;
}

Write在.NET7和.NET8上生成如下:

call      CORINFO_HELP_CHECKED_ASSIGN_REF
nop
ret

CORINFO_HELP_CHECKED_ASSIGN_REF是一個JIT幫助程式函式，其中包含所謂的“GC write barrier (GC寫屏障)”，一個小程式碼片段，用於讓GC跟蹤正在寫入的引用，因為它可能需要知道，例如，因為正在分配的物件可能是gen0，而目標可能是gen2。

微調下這個程式碼:

public class Tests
{
    public void Write()
    {
        string dst = "old";
        Write(ref dst);
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static void Write(ref string dst) => dst = "new";
}

實現的功能都是一樣的，只不過dst直接賦值了常量字串，記得上面常量字串的分配是在Non-GC Heap嗎？.NET7裡面還是需要幫助函式:

mov       rdx,1FF0E4014A0
mov       rdx,[rdx]
call      CORINFO_HELP_CHECKED_ASSIGN_REF
nop
ret

然.NET8裡面則是

mov       rax,1B3814EAEC8
mov       [rcx],rax
ret

因為.NET8意識到常量字串是在Non-GC Heap，不需要GC跟蹤判斷在那個程式碼，類似於card_table那種。所以最佳化掉了CORINFO_HELP_CHECKED_ASSIGN_REF

結尾

作者:江湖評談
歡迎關注公眾號:jianghupt，文章首發,以及更多高階內容分享。
image

相關文章