本文90%通过机器翻译,另外10%译者按照自己的理解进行翻译,和原文相比有所删减,可能与原文并不是一一对应,但是意思基本一致。

译者水平有限,如果错漏欢迎批评指正

译者@Bing Translator@InCerry,另外感谢@Hex@晓青@贾佬@黑洞百忙之中抽出时间帮忙review和检查错误。

原文链接:https://devblogs.microsoft.com/dotnet/put-a-dpad-on-that-gc/


这是在说什么?是的,我们有一个在区域【原文叫region】上叫做DPAD的新功能。区域是我们目前在.NET 6中用于替换段【原文叫segment】的新东西。在这篇博文中,我将首先对区域做一些介绍,然后谈谈DPAD功能。请注意,我们不太可能在.NET 6.0结束时正式支持区域,因为这涉及到很多工作--我们目前的计划是在clrgc.dll中把它作为一个实验性的功能,你可以通过配置来打开。事实上,这就是我希望从现在开始的大型GC功能的发布方式,我们首先将它们与独立的GC一起发布(即在clrgc.dll中),这样人们就可以尝试它们,然后我们在coreclr.dll中正式开启它们,这样它们就默认开启了。

译者注:

原本.NET的GC是分段式GC,也就是说GC管理内存的单位是段,而现在改了,改成区域了,另外这一段中Maoni大佬其实透露三个重要的信息:

  1. 段内存分配的方式结束了,将使用区域的方式来替代段内存分配。
  2. .NET 6.0中大概率不会支持区域,但是会通过clrgc.dll的方式独立提供,你可以通过配置的方法打开,大家要注意这个独立提供,因为从.NET Core 2.1开始我们就可以自定义GC了,也就是说你开心的话,可以自己写一个GC,然后替换掉.NET自带的GC;使用的环境变量是这个link,另外也有大佬实现了一个Zero GC link,你只需要实现几个接口,就可以自定义GC。
  3. 以后.NET上GC重大功能的发布都会遵循这样一个步骤:功能开发 => 单独发布到clrgc.dll => 公开测试修复bug => 正式发布到coreclr.dll

到目前为止,如你所知,我们一直在段上运作。段多年来为我们提供了很好的服务,但我开始注意到它的局限性,因为人们把更多种类的工作负载放在我们的框架上。段是我们内存管理的基础,所以从段转换成区域是件大事。当我们接近.NET 6发布时,我决定是时候摆脱段式了,所以这是我们的团队最近花费大量时间的地方。那么,段和区域之间的主要区别是什么?段是大的内存单位--在Server GC 64-bit上,如果段的大小是1GB、2GB或4GB(在工作站模式下更小-256MB),而区域是小得多的单位,它们默认为每个4MB。所以你可能会问,"所以它们更小,为什么有意义?"。要回答这个问题,首先让我们回顾一下段是如何工作的。

如果您看不明白上面的这一段文字,那么建议您先补一下基础的知识,微软的官方文档。里面详细的介绍了.NET GC的基础知识,包括什么是分代、垃圾回收的过程、服务器GC与工作站GC、并发GC、后台GC等等。

目前,当我们只有一个段时,SOH在堆上是这样的:

当我们有多个段时,它可以看起来像这样

或这样

蓝色和黄色的空间是一个段上所有已提交【已提交:是指由操作系统分配给应用程序使用的内存】的内存(关于Gen【代】开始的解释,请看这个视频,)。每个段都会记录该段上已提交的内容,以便我们知道是否需要提交更多。而该段上的所有空闲空间也是已提交的内存。当我们使用空闲空间来容纳对象时,这很有效,因为我们可以立即使用内存--它已经被提交。但是想象一下这样的场景:我们在某一代有空闲空间,比如说gen0,因为有一些异步IO正在进行,导致我们在gen0中降级了一堆pin对象,但我们实际上并没有使用(这可能是由于没有等待这么长时间来做下一次GC,或者我们已经积累了太多的活着的对象,这意味着GC暂停会太长)。如果我们能将这些空闲空间用于其他代,如果他们需要的话,那不是很好吗?gen2和LOH中的空闲空间也是一样的--你可能在gen2中有一些空闲空间,如果能用它们来分配一些大的对象就好了。我们在段上做撤销提交【uncommit:已提交的反向操作】,但只是在段的末端,也就是在该段上最后一个活对象之后(由每个段末端的浅灰色空间表示)。而如果你有pin对象,就阻止了GC收回段的末端,那么只能形成自由空间,而自由空间里是已提交的内存。当然,你可能会问,"为什么不直接把有大量自由空间的段的中间部分取消提交?"。但这需要记录,以记住段中间的哪些部分被解密,所以当我们想用它们来分配对象时,我们需要重新提交它们。而现在,我们已经进入了区域的概念,也就是让更小的内存量被GC单独操作。

如果您看不懂上面这段文字,那么说明您需要翻阅一下下面这些资料,来了解已提交内存、pin对象、固定对象堆等等

有了区域,各代人看起来是统一的,我们不再有这种 "短暂的片段 "概念。我们有gen0和gen1区域,就像我们有gen2区域一样。

当然,每一代的区域数量可能有很大的不同。但它们都由这些小的内存单元组成。LOH的区域确实更大(LOH是SOH区域大小的8倍,所以每个32MB)。当我们释放一个区域时,我们将其返回到自由区域池中,该池中的区域可以被任何一代抓取,甚至在需要时被任何其他堆抓取。因此,你不会再看到这样的情况:你在gen2或LOH中有一些巨大的空闲空间,但它们很长时间都没有被使用(如果你的应用程序的行为经历了一些阶段,其中一个阶段可能比另一个阶段生存更多的内存,而GC认为没有必要做一个完整的压缩GC,这种情况就可能发生)。

在GC工作中,我们总是要做出权衡。有了区域,我们确实获得了很多灵活性。但我们也不得不放弃一些东西。有一件事使段非常有吸引力,那就是我们确实有一个连续的短暂范围,因为gen0和gen1总是生活在短暂的段上,而且总是紧挨着。当我们在写 屏障中设置卡片时【在GC有一个card tables,用来记录对象之间的跨代引用,另外就是实现写屏障,详细可以翻阅《.NET Core底层入门》P289】,我们利用了这个优势。如果你做obj0.f = obj1,并且我们检测到obj1不在短暂的范围内。我们不需要设置卡片,因为我们不需要它(只有当obj1比obj0处于更年轻的一代时才需要设置卡片,如果obj1不在短暂的范围内,这意味着它要么在gen2,要么在LOH/POH,这些都被逻辑上认为是第二代的一部分(但内部被追踪为gen3和gen4,我在这篇文章中互换使用LOH和gen3)。而这意味着它要么与obj0处于同一代,要么处于比obj0更早的一代)。) 但是我们只对工作站GC做了这个优化,因为服务器GC有多个短暂的范围,我们不想在写屏障代码时要和所有的范围进行比较。在区域中,我们要么无条件地设置卡片(这将使Workstation GC的暂停倒退一些,但对Server GC保持相同的性能),要么在写屏障中检查obj1的区域,这将比在最优化的写屏障类型中检查短暂范围更昂贵。不过区域带来的好处应该比这更有说服力。

现在我们可以谈一谈DPAD功能。DPAD是动态升级和降级的意思。严格来说,降级已经是动态的了,因为它只根据Pin对象的情况动态发生。如果你读过我的备忘录,那里解释了降级(如果你没读过,我强烈建议你读mem-doc)。基本上,降级意味着一个对象不会像正常情况下那样得到提升。对于段来说,降级意味着我们将暂存段的一个范围设置为 "降级范围",这个范围只能从暂存段的中间一点到该段的末端。换句话说,我们永远不会把短暂段中间的一个范围设置为降级范围。这正是因为对于段,gen1必须在短暂段的gen0之前(在同一个堆上)。所以我们不能有一个gen1的部分,接着是gen0的部分,然后再接着是gen1的部分。

升级是GC中一个常见的概念--它意味着如果一个对象存活了一代,它现在被认为是上一代的一部分。因此,如果你在SOH上有一个长期生存的小对象,它最终会被提升到gen2。但这意味着这需要2次GC才能实现。我正计划提供一个API,让用户可以选择告诉GC将一个新的对象直接分配到某一代,所以你可以将你知道会存活到gen2的对象直接分配到gen2中(到目前为止我还没有实现这个API,因为有区域的支持也会更容易,所以我正计划在我们转换到区域时实现它)。但这并不包括所有的情况,因为有时用户很难知道一个对象是否会 "很可能存活到gen2"。而且你可能正在使用一个库,对这些对象的分配没有控制。一个非常明显的情况是,这种情况会发生在数据基础设施的大小调整上。比方说,你或你使用的库分配了一个List,它需要增加容量。所以它分配了一个新的T[]对象,可以容纳两倍于旧对象的元素数量。现在它为第二部分创建了一堆子元素。现在,如果新的数组足够大,可以上LOH,而且新的子元素都是小对象,所以它们在gen0 -

通过上文的描述,Maoni大佬的团队计划实现一个GC的API,可以让用户指定你的对象分配到某一代中(默认都是从G0开始)。

比如我们经常会有这样一些场景,我们在程序启动的时候会去读一些数据,将它们缓存到内存中,这些缓存直到程序关闭才会释放,也就是说开发者能知道最终它会到gen2;如果没有这个API,那么你缓存的对象将从gen0开始,经过两次GC才到gen2,一般缓存的数据都比较大,导致GC在标记和整理过程中会花更多的实际,而且可能由于可用内存不足,会频繁的去申请空间;如果有了这个API,开发者就能将对象直接分配到gen2,避免了gen0和gen1的GC,也避免了频繁扩容空间。

(为了说明问题,我只展示了一个8元素的数组和4个新的孩子,如果这是一个对象[],显然它需要更多的元素才能进入LOH)

在片段的情况下,我们会看到这样的情况:

由于新的数组被认为是gen2的一部分,这意味着所有在gen0中创建的新元素都将存活到gen2中(除非gen2的GC很快发生,并发现父数组已经死亡,这有可能发生,但可能性不大;如果真的发生,那就非常不幸了,因为你花了这么大代价创建一个大对象,却马上把它抛弃)。但要做到这一点,它至少需要经过两次GC。我们很有可能首先观察到一个gen0或gen1的GC,这个GC会让这些孩子生存到gen1。

然后下一个gen1的GC会发现他们都还活着,因为他们被LOH中的那个阵列保持着活力。现在它把它们都提升到Gen2

在这种情况下,我们更愿意直接将它们分配到gen2。但是这对段来说是很难做到的。我们可以跟踪哪些对象由这些对象组成,或者主要由这些对象组成,但是当我们做标记时,我们不知道哪些对象会一起形成插头【Plug,被翻译成插头,详情可以看《.NET内存管理宝典》P371和《.NET Core底层入门》P323】。而当我们在形成插头时,我们已经失去了这些信息。我们可以在更大的颗粒度上跟踪这些信息。但你猜怎么着,这基本上就像区域一样!因为我们想把这些信息划分到不同的区域。因为我们想把一个区段划分成更小的单位来跟踪这些信息。所以对于区域来说,这是很容易的。当我们做标记时,我们确切地知道每个区域上有多少存活下来的东西--当我们标记每个对象时,我们跟踪我们需要把存活下来的字节归于哪个区域。所以我们知道有多少存活是由卡片标记完成的。

对于区域,当我们遇到一个主要由对象组成的区域时,如这些因卡片标记而被保留的子对象,我们有一个选择:

我们可以选择将这个区域直接分配到gen2 :

因此,该区域被并入gen2。属于gen0的另一个区域的幸存者被压缩到gen1区域,gen0得到一个新的区域用于分配。

在目前的实现中,我只对那些主要被像这样的对象填满的区域做了这个工作。由于区域很小,很可能有些区域被这些东西填满,然后我们有另一个区域部分被这些东西填满,部分被一些真正的临时对象填满。把它们分开的复杂性是不值得的(你可以把它看作是我们回到了这个特定区域的片段情况)。

当我们这样做时,会有一些复杂的情况(对于GC来说,几乎总是有一些复杂的情况......)。一个例子是,由于我们现在只是让gen0的对象在gen2中生存,我们需要确保如果它们指向任何不是gen2的代,就需要为这些对象设置卡片。当我们在重新定位阶段通过活着的对象时,我们会这样做(因为无论如何我们已经必须通过每个对象)。

所以双关语(部分)的意思是,这个DPAD功能有点像D-pad......你可以告诉一个区域它需要去哪个方向--向上或向下(在GC术语中是指年长或年轻)。有很多情况下,我们想动态地提升或降低一个区域,我上面举的例子只是其中之一。重点是,有了区域,我们可以动态地指定一个我们希望一个区域最终处于的代数,因为代数不再是连续的,而且没有特定的顺序,代数必须是相对的(当然,正如你在上面看到的,有一些实施细节需要为不同的场景所关注)。这比我们以前用分段做的有限的降级要灵活得多。而当我们在GC结束时对区域进行线程化处理时,我们只需要将它们线程化到它们所分配的区域。随着我对DPAD的初步检查,我已经实现了3个场景,我们将动态地促进或降级区域。在未来,我们会实现更多。

译者注

从maoni大佬的这篇文章我们可以看到主流的GC设计都越来越趋于一致了,第一眼看到region的时候我就想到了JVM上的ZGC(多占用一些内存和牺牲一定的吞吐量来达到亚毫秒级的STW时间),而目前看来.NET也在做类似的事情,不过我也不敢肯定,那么region能为我们带来什么呢,有得也有失:

  • 通常情况下会有更少的内存占用,特殊情况下更多的内存占用。因为region的一般来说只有4MB大小,而segment会有1GB~4GB大小,另外对于pin住的对象,segment也不能很好的进行处理,从而造成了内存碎片,会占用跟多的空间;region还有的有点就是释放后会返回到一个池中,哪个代需要使用就可以分配给哪个代,这比segment模式更加灵活,更能复用已申请的内存。为什么会说通常情况下,那是因为同样使用1GB内存region的数量肯定比segment要多,所以需要有额外的空间来记录region的引用,当堆很大(比如TB级别以上),可能会占用更多的内存。
  • 更少的STW时间。region很小,所以进行"标记-整理"中整理的步骤时,可以将整个region升代,加快了整理的的速度。
  • 吞吐量的下降。由于region上gen0和gen1不会在连续的地址空间上,所以内存屏障付出的代价会更大,从而造成吞吐量的下降,在此之前.NET的GC都是为吞吐量和P99延时优化的。

现在关于DPAD的代码已经合并到main分支中了,详情可以看这个PR,相信很快就能和我们见面,不过看了maoni大佬提交的代码,发现个有趣的东西。

  • Region只支持64位操作系统。从下图中的提交来看,限定了只有64位操作系统才能使用,让我不禁想到ZGC的染色指针,通过染色指针来减少写屏障的使用,进一步降低STW时间。如果支持了染色指针那么标记可能也会采用三色标记,主流的GC算法也趋于一致了。

  • 和Hex大佬讨论了一下,后面觉得除了azul的C4算法以外.NET GC也有可能会采用CoCo算法来实现,CoCo也是一种低延时的算法,具体可以看看这篇论文,而且已经有人在.NET上实现了这个。

如果您想更详细的了解.NET的GC和整个实现的原理,您可以看.NET Runtime部分的源码和.NET GC架构师Maoni大佬的博客,另外也有两本不错的书推荐。

  • 《.NET Core底层入门》:由国内精通C++ 汇编的大佬从2017年阅读CLR源码后编写,写的十分详细并且具有极大的参考意义,主要是介绍CoreCLR的,中间GC的部分也写的很清楚。

  • 《.NET 内存管理宝典》:由国外研究.NET GC的大佬编写,主要围绕着.NET的内存分配、GC执行流程、问题诊断进行介绍,是一本不可多得的好书。

其它文章

[翻译]在GC上加入DPAD的更多相关文章

  1. Dapper简易教程(翻译自Github上StackExchange/Dapper)

    本文源自:https://github.com/cnxy/Dapper-zh-cn 本博客作者与Github上作者(cnxy)实为同一个作者.由于笔者翻译水平有限,文本中错误难免,欢迎指正! 本文翻译 ...

  2. 关于GC(上):Apache的POI组件导致线上频繁FullGC问题排查及处理全过程

    某线上应用在进行查询结果导出Excel时,大概率出现持续的FullGC.解决这个问题时,记录了一下整个的流程,也可以作为一般性的FullGC问题排查指导. 1. 生成dump文件 为了定位FullGC ...

  3. asp.net 之 GC (垃圾回收机制)

    今天抽时间好好整理了下GC相关知识,看了CSDN和博客园的几篇文章,有了一定的简单了解,决定根据个人理解整合一份随笔写下来,望诸位指教. 一:基础问题 1.首先需要知道了解什么是GC? GC如其名,就 ...

  4. jvm系列(十):如何优化Java GC「译」

    本文由CrowHawk翻译,是Java GC调优的经典佳作. 本文翻译自Sangmin Lee发表在Cubrid上的"Become a Java GC Expert"系列文章的第三 ...

  5. C# Language Specification 5.0 (翻译)第三章 基本概念

    应用程序启动 拥有进入点(entry point)的程序集称应用程序(application).当运行一应用程序时,将创建一新应用程序域(application domain).同一个应用程序可在同一 ...

  6. jvm系列(七):如何优化Java GC「译」

    本文由CrowHawk翻译,地址:如何优化Java GC「译」,是Java GC调优的经典佳作. Sangmin Lee发表在Cubrid上的”Become a Java GC Expert”系列文章 ...

  7. jvm系列(十):如何优化Java GC「

    转自:https://www.cnblogs.com/ityouknow/p/7653129.html 本文由CrowHawk翻译,地址:如何优化Java GC「译」,是Java GC调优的经典佳作. ...

  8. [翻译]Go与C#的比较,第二篇:垃圾回收

    Go vs C#, part 2: Garbage Collection | by Alex Yakunin | ServiceTitan - Titan Tech | Medium 目录 译者注 什 ...

  9. 「入门篇」初识JVM (下下) - GC

    垃圾收集主要是针对堆和方法区进行:程序计数器.虚拟机栈和本地方法栈这三个区域属于线程私有的,只存在于> 线程的生命周期内,线程结束之后也会消失,因此不需要对这三个区域进行垃圾回收. GC - J ...

随机推荐

  1. 推荐一些学习MySQL的资源

    前言: 在日常工作与学习中,无论是开发.运维.还是测试,对于数据库的学习是不可避免的,同时也是日常工作的必备技术之一.在互联网公司,开源数据库用得比较多的当属MySQL了,相信各位小伙伴关注我的原因也 ...

  2. CLS的探索:Python如何让日志免费云化

    前言 日志服务(Cloud Log Service,CLS)是腾讯云提供的一站式日志服务平台,提供了从日志采集.日志存储到日志检索,图表分析.监控告警.日志投递等多项服务,协助用户通过日志来解决业务运 ...

  3. 2019c#将PDF转图片

    两种方法: 第一种是用O2S.Components.PDFRender4NET 大家可以去网上查找无水印版本 但是有的时候带颜色的字就变空白了 不知道为什么 第二种是用PdfiumViewer 这种方 ...

  4. DataGear 变更部署数据库为SQL Server填坑指南(含转写后的SQL server代码及SQL server配置文件)

    1. 引言 2. 配置数据库链接 3. 引入数据库驱动 4. 手动初始化数据库 5. 改写SQL 6. 其他 7. 参考 1. 引言 DataGear默认使用Derby数据库作为系统的元数据库,至于待 ...

  5. font

    font属性简写 front: font-style font-variant font-weight font-size/line-height font-family 说明: 值之间空格隔开 注意 ...

  6. yum 命令详解-yum仓库配置文件详解

    yum安装的优点 1.必须得有网络,通过网络获取软件. 2.管理rpm包 3.自动解决依耐 4.命令简单好用 5.生产最佳实践 yum命令详解 # linux安装软件的三种方式 1.rpm安装 2.源 ...

  7. WPF 2D图形 Shape入门(一)--Shape

    本文是篇WPF Shape的入门文章 Shape 首先看看shape的继承链关系: 一个Shape具有哪些重要属性: 属性 说明 DefiningGeometry 默认的几何形状 RenderedGe ...

  8. docker-ce 安装

    配置源 确认版本 添加镜像加速器 https://docs.docker.com/engine/release-notes/19.03/ for centos wget -O /etc/yum.rep ...

  9. Element-ui Popconfirm气泡确认框的确认及取消事件不生效

    Element-ui 官方文档对 Popconfirm气泡确认框的一些属性及事件的描述不够详细,导致第一次使用时会遇到各种各样的问题 对确定事件及取消事件描述如下: 但是如果给组件绑定@confirm ...

  10. [leetcode] 212. 单词搜索 II(Java)

    212. 单词搜索 II 这leetcode的评判机绝对有问题!!同样的代码提交,有时却超时!害得我至少浪费两个小时来寻找更优的答案= =,其实第一次写完的代码就可以过了,靠!!!第207位做出来的 ...