.NET8 极致性能优化 Non-GC Heap

  • 2023-11-29 09:38:45
  • 阅读:6次

前言

.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

热门内容