.NET8极致性能优化Non-GC Heap
前言
.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.欢迎关注。文章首发地。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
eBPF 的发展演进 --- 从石器时代到成为神(一)
1. 前言 技术的发展往往是积跬步而至千里的。Linux从92年诞生,发展至今已经覆盖大小各类的信息基础设施。是什么样的力量,让Linux能够始终保持发展活力,又如何看待Linux之上出现的新的技术趋势? 本文试图通过梳理eBPF的演进过程,探索Linux内核的发展动力来源与发展轨迹,与大家一同畅想eBPF给内核技术、Linux生态带来的全新变局。 2. eBPF概览 2.1. 实现原理 大家可能都知道图灵机,这是一个可计算理论模型,可以用来判断计算机的计算能力。图灵机是目前有可能实现的计算能力最强的理论模型,目前我们常用的计算机,理论上都是等价于图灵机的。 BPF的出现,是对计算能力的渴求,其原理就是通过IR模拟一台RISC指令集的计算机嵌入到内核中,将内核内部的静态编译逻辑转变为更加灵活的动态编译逻辑,使内核获得近似于图灵机的动态逻辑定制能力。而从classic BPF到extended BPF的发展,是将这一计算方式进一步夯实和通用化。 BPF的出现乃至到eBPF的进一步发展,为内核带来了巨大的改变,使内核具备了更加强大、可编程的动态变化的能力。这种能力在各种需要定制化...
- 下一篇
构建高效数据流转的 ETL 系统:数据库 + Serverless 函数计算的最佳实践
作者|柳下 概述 随着企业规模和数据量的增长,数据的价值越来越受到重视。数据的变化和更新变得更加频繁和复杂,因此及时捕获和处理这些变化变得至关重要。为了满足这一需求,数据库 CDC(Change Data Capture)技术应运而生。然而,从 ETL 架构的角度来看,CDC 仅满足了数据的提取(Extract)能力。 为了实现完整的 ETL 架构,并完成高效、实时的数据集成、处理和同步,阿里云 Serverless 函数计算(FC)与数据库 CDC 技术深度融合。助力企业构建完整的 ETL 架构,实现数据的提取、转换和加载。通过将 CDC 作为事件驱动的数据源,将数据变化作为事件触发 Serverless 函数的执行,可以实现实时的数据处理和同步,有助于提升业务决策和分析的准确性和效率。 架构介绍 下面将从 ETL 模型入手,逐步讲述 FC + CDC 如何适配符合 ETL 模型的业务。 ETL 模型 在大数据领域,承载数据流转、加工业务的系统架构都可抽象为 ETL 模型,它由三个主要步骤组成:提取(Extract)、转换(Transfomr)和加载(Load)。 提取:从数据源中提...
相关文章
文章评论
共有0条评论来说两句吧...