CoreCLR源码探索(五) GC内存收集器的内部实现 调试篇
在上一篇中我分析了CoreCLR中GC的内部处理,
在这一篇我将使用LLDB实际跟踪CoreCLR中GC,关于如何使用LLDB调试CoreCLR的介绍可以看:
源代码
本篇跟踪程序的源代码如下:
using System;
using System.Runtime.InteropServices;
namespace ConsoleApplication
{
public class Program
{
public class ClassA { }
public class ClassB { }
public class ClassC { }
public static void Main(string[] args)
{
var a = new ClassA();
{ var b = new ClassB(); }
var c = new ClassC();
GCHandle handle = GCHandle.Alloc(c, GCHandleType.Pinned);
IntPtr address = handle.AddrOfPinnedObject();
Console.WriteLine((long)address);
GC.Collect();
Console.WriteLine("first collect completed");
c = null;
GC.Collect();
Console.WriteLine("second collect completed");
GC.Collect();
Console.WriteLine("third collect completed");
}
}
}
准备调试
环境和我的第三篇文章一样,都是ubuntu 16.04 LTS,首先需要发布程序:
dotnet publish
发布程序后,把自己编译的coreclr文件覆盖到发布目录中:
复制coreclr/bin/Product/Linux.x64.Debug
下的文件到程序目录/bin/Debug/netcoreapp1.1/ubuntu.16.04-x64/publish
下。
请不要设置开启服务器GC,一来是这篇文章分析的是工作站GC的处理,二来开启服务器GC很容易导致调试时死锁。
进入调试
准备工作完成以后就可以进入调试了
cd 程序目录/bin/Debug/netcoreapp1.1/ubuntu.16.04-x64/publish
lldb-3.6 程序名称
首先设置gc主函数的断点,然后运行程序
b gc1
r
我们停在了gc1函数,现在可以用bt
来看调用来源
这次是手动触发GC,调用来源中包含了GCInterface::Collect
和JIT生成的函数
需要显示当前的本地变量可以用fr v
,需要打印变量或者表达式可以用p
现在用n
来步过,用s
来步进继续跟踪代码
进入标记阶段
在上图的位置中用s
命令即可进入mark_phase
,继续步过到下图的位置
这时先让我们看下堆中的对象,加载CoreCLR提供的LLDB插件
plugin load libsosplugin.so
插件提供的命令可以查看这里的文档
执行dumpheap
查看堆中的状态
执行dso
查看堆和寄存器中引用的对象
执行dumpobj
查看对象的信息
在这一轮gc中对象a b c都会存活下来,
可能你会对为什么b能存活下来感到惊讶,对象b的引用分配在栈上,即时生命周期过了也不一定会失效(rsp不会移回去)
br s -n Promote -c "(long)*ppObject == 0x00007fff5c01a2b8" # -n 名称 -c 条件
c # 继续执行
接下来步进mark_object_simple
函数,然后步进gc_mark1
函数
me re -s8 -c3 -fx o # 显示地址中的内存,8个字节一组,3组,hex格式,地址是o
p ((CObjectHeader*)o)->IsMarked() # 显示对象是否标记存活
我们可以清楚的看到标记对象存活设置了MethodTable的指针|= 1
现在给PinObject
下断点
br s -n PinObject -c "(long)*pObjRef == 0x00007fff5c01a1a0"
c
可以看到只是调用Promote
然后传入GC_CALL_PINNED
继续步进到if (flags & GC_CALL_PINNED)
下的pin_object
可以看到pinned标记设置在同步索引块中
进入计划阶段
进入计划阶段后首先打印一下各个代的状态
p generation_table
使用这个命令可以看到gen 0 ~ gen 3的状态,最后一个元素是空元素不用在意
继续步过下去到下图的这一段
在这里我们找到了一个plug的开始,然后枚举已标记的对象,下图是擦除marked和pinned标记的代码
在这里我们找到了一个plug的结束
如果是Full GC或者不升代,在处理第一个plug之前就会设置gen 2的计划代边界
模拟压缩的地址
如果x越过原来的gen 0的边界,设置gen 1的计划代边界(原gen 1的对象变gen 2),
如果不升代这里也会设置gen 0的计划代边界
模拟压缩后把原地址与压缩到的地址的偏移值存到plug信息(plug前的一块内存)中
构建plug树
设置brick表,这个plug树跨了6个brick
如果升代,模拟压缩全部完成后设置gen 0的计划代边界
接下来如果不动里面的变量,将会进入清扫阶段(不满足进入压缩阶段的条件)
进入清扫阶段
这次为了观察对象c如何被清扫,我们进入第二次gc的make_free_lists
b make_free_lists
c
处理当前brick中的plug树
前面看到的对象c的地址是0x00007fff5c01a2e8,这里我们就看对象c后面的plug是如何处理的
br s -f gc.cpp -l 23070 -c "(long)tree > 0x00007fff5c01a2e8"
c
我们可以看到plug 0x00007fff5c01a300前面的空余空间中包含了对象c,空余空间的开始地址就是对象c
接下来就是在这片空余空间中创建free object和加到free list了,
这里的大小不足(< min_free_list)所以只会创建free object不会加到free list中
设置代边界,之前计划阶段模拟的计划代边界不会被使用
清扫阶段完成后这次的gc的主要工作就完成了,接下来让我们看重定位阶段和压缩阶段
进入重定位阶段
使用上面的程序让计划阶段选择压缩,需要修改变量,这里重新运行程序并使用以下命令
b gc.cpp:22489
c
expr should_compact = true
n
步过到下图的位置,s
步进到relocate_phase
函数
到这个位置可以看到用了和标记阶段一样的GcScanRoots
函数,但是传入的不是Promote
而是Relocate
函数
接下来下断点进入Relocate
函数
b Relocate
c
GCHeap::Relocate
函数不会重定位子对象,只是用来重定位来源于根对象的引用
一直走到这个位置然后进入gc_heap::relocate_address
函数
根据原地址和brick table找到对应的plug树
搜索plug树中old_address所属的plug
根据plug中的reloc修改指针地址
现在再来看relocate_survivors函数,这个函数用于重定位存活下来的对象中的引用
b relocate_survivors
c
接下来会枚举并处理brick,走到这里进入relocate_survivors_in_brick
函数,这个函数处理单个brick中的plug树
递归处理plug树种的各个节点
走到这里进入relocate_survivors_in_plug
函数,这个函数处理单个plug中的对象
图中的这个plug结尾被下一个plug覆盖过,需要特殊处理,这里继续进入relocate_shortened_survivor_helper
函数
当前是unpinned plug,下一个plug是pinned plug
枚举处理plug中的各个对象
如果这个对象结尾未被覆盖,则调用relocate_obj_helper
重定位对象中的各个成员
如果对象结尾被覆盖了,则调用relocate_shortened_obj_helper
重定位对象中的各个成员
在这里成员如果被覆盖会调用reloc_ref_in_shortened_obj修改备份数据中的成员,但是因为go_through_object_nostart
是一个macro这里无法调试内部的代码
接下来我们观察对象a的地址是否改变了
重新运行并修改should_compact
变量
b gc.cpp:22489
r
expr should_compact = true
plugin load libsosplugin.so
dso
我们可以看到对象a的地址在0x00007fff5c01a2b8,接下来给relocate_address
函数下断点
br s -n relocate_address -c "(long)(*pold_address) == 0x00007fff5c01a2b8"
c
我们可以看到地址由0x00007fff5c01a2b8变成了0x00007fff5c0091b8
接下来一直跳回plan_phase,下图可以看到重定位阶段完成以后新的地址上仍无对象,重定位阶段只是修改了地址并未复制内存,直到压缩阶段完成以后对象才会在新的地址
接下来看压缩阶段
进入压缩阶段
在重定位阶段完成以后走到下图的位置,步进即可进入压缩阶段
枚举brick table
处理单个brick table中的plug树
根据下一个tree的gap计算last_plug的大小
处理单个plug中的对象
上面的last_plug是pinned plug所以不移动,这里找了另外一个会移动的plug
下图可以看到整个plug都被复制到新的地址
这里再找一个结尾被覆盖过的plug看看是怎么处理的
首先把被覆盖的结尾大小加回去
然后把被覆盖的内容临时恢复回去
复制完再把覆盖的内容交换回来,因为下一个plug还需要用
最终在recover_saved_pinned_info会全部恢复回去
参考链接
https://github.com/dotnet/coreclr/blob/master/Documentation/botr/garbage-collection.md
https://github.com/dotnet/coreclr/blob/release/1.1.0/Documentation/building/linux-instructions.md
https://github.com/dotnet/coreclr/blob/release/1.1.0/Documentation/building/debugging-instructions.md
http://lldb.llvm.org/tutorial.html
http://lldb.llvm.org/lldb-gdb.html
写在最后
这一篇中我列出了几个gc中比较关键的部分,但是还有成千上百处可以探讨的部分,
如果你有兴趣可以自己试着用lldb调试CoreCLR,可以学到很多文档和书籍之外的知识,
特别是对于CoreCLR这种文档少注释也少的项目,掌握调试工具可以大幅减少理解代码所需的时间
写完这一篇我将暂停研究GC,下一篇开始会介绍JIT相关的内容,敬请期待
CoreCLR源码探索(五) GC内存收集器的内部实现 调试篇的更多相关文章
- CoreCLR源码探索(四) GC内存收集器的内部实现 分析篇
在这篇中我将讲述GC Collector内部的实现, 这是CoreCLR中除了JIT以外最复杂部分,下面一些概念目前尚未有公开的文档和书籍讲到. 为了分析这部分我花了一个多月的时间,期间也多次向Cor ...
- CoreCLR源码探索(三) GC内存分配器的内部实现
在前一篇中我讲解了new是怎么工作的, 但是却一笔跳过了内存分配相关的部分. 在这一篇中我将详细讲解GC内存分配器的内部实现. 在看这一篇之前请必须先看完微软BOTR文档中的"Garbage ...
- Golang源码探索(三) GC的实现原理(转)
Golang从1.5开始引入了三色GC, 经过多次改进, 当前的1.9版本的GC停顿时间已经可以做到极短.停顿时间的减少意味着"最大响应时间"的缩短, 这也让go更适合编写网络服务 ...
- Golang源码探索(三) GC的实现原理
Golang从1.5开始引入了三色GC, 经过多次改进, 当前的1.9版本的GC停顿时间已经可以做到极短. 停顿时间的减少意味着"最大响应时间"的缩短, 这也让go更适合编写网络服 ...
- CoreCLR源码探索(一) Object是什么
.Net程序员们每天都在和Object在打交道 如果你问一个.Net程序员什么是Object,他可能会信誓旦旦的告诉你"Object还不简单吗,就是所有类型的基类" 这个答案是对的 ...
- CoreCLR源码探索(二) new是什么
前一篇我们看到了CoreCLR中对Object的定义,这一篇我们将会看CoreCLR中对new的定义和处理 new对于.Net程序员们来说同样是耳熟能详的关键词,我们每天都会用到new,然而new究竟 ...
- CoreCLR源码探索(六) NullReferenceException是如何发生的
NullReferenceException可能是.Net程序员遇到最多的例外了, 这个例外发生的如此频繁, 以至于人们付出了巨大的努力来使用各种特性和约束试图防止它发生, 但时至今日它仍然让很多程序 ...
- CoreCLR源码探索(七) JIT的工作原理(入门篇)
很多C#的初学者都会有这么一个疑问, .Net程序代码是如何被机器加载执行的? 最简单的解答是, C#会通过编译器(CodeDom, Roslyn)编译成IL代码, 然后CLR(.Net Framew ...
- CoreCLR源码探索(八) JIT的工作原理(详解篇)
在上一篇我们对CoreCLR中的JIT有了一个基础的了解, 这一篇我们将更详细分析JIT的实现. JIT的实现代码主要在https://github.com/dotnet/coreclr/tree/m ...
随机推荐
- C++ 头文件系列 (bitset)
简介 该头文件有关位集,实际上是vector 位 位本质上对应bool的概念,只有0或1,true或false两种对立的值. 但很可惜,字节才是机器上最小的存储单元,所以bool基本上是由一个字节大小 ...
- java udp 发送小数数字(较难)
代码全部来自:http://825635381.iteye.com/blog/2046882,在这里非常感谢了,我运行测试了下,非常正确,谢谢啊 服务端程序: package udpServer; i ...
- 读书笔记 effective c++ Item 13 用对象来管理资源
1.不要手动释放从函数返回的堆资源 假设你正在处理一个模拟Investment的程序库,不同的Investmetn类型从Investment基类继承而来, class Investment { ... ...
- Maven入门-4.Maven的依赖
1.Maven的依赖1.1 添加依赖1.2 依赖范围(sope)依赖范围与classpath的关系1.3 依赖的传递性1.2.1 依赖传递性的冲突问题1. 第一种情况2. 第二种情况1.2.2 通过e ...
- JavaScript中国象棋程序(2) - 校验棋子走法
"JavaScript中国象棋程序" 这一系列教程将带你从头使用JavaScript编写一个中国象棋程序.这是教程的第2节. 这一系列共有9个部分: 0.JavaScript中国象 ...
- Asp.net MVC4 ExtJS权限管理系统源码 C#开发框架源码
开发环境:VS2010或以上 数据库:SQL Server 2008 r2 MVC版本:Asp.net mvc 4.0 ExtJs版本:ext-4.2 功能介绍 1.多标签,js动态加载模式,全a ...
- 了解 : angular $filter stateful
{{ abc | myFilter }} angular.module('myStatefulFilterApp', []) .filter('decorate', ['decoration', fu ...
- 高精度模板 Luogu P1932 A+B & A-B & A*B & A/B Problem
P1932 A+B & A-B & A*B & A/B Problem 题目背景 这个题目很新颖吧!!! 题目描述 求A.B的和差积商余! 输入输出格式 输入格式: 两个数两行 ...
- 【2017-02-24】循环嵌套、跳转语句、异常语句、迭代穷举、while
一.循环嵌套 1.格式 for() { for() { } } 2.执行顺序 先执行外边循环进到循环体发现里面的循环,开始执行里面的循环.等到里面的循环执行完毕,再执行外边的循环. 在外面循环第一次, ...
- TableView 多余分割线的处理
方法一,以下两个方法的实现 - (void)viewDidLoad { [super viewDidLoad]; self.tableView.tableFooterView = [[UIView a ...