建设网站后期需要哪些,推广之家app,罗湖做网站的,南昌网站建设制作与维护一#xff1a;背景 写这一篇的目的主要是因为.NET领域内几本关于阐述GC方面的书#xff0c;都是纯理论#xff0c;所以懂得人自然懂#xff0c;不懂得人也没法亲自验证#xff0c;这一篇我就用 windbg 源码 让大家眼见为实。二#xff1a;为什么要引入后台GC 1. 后台GC到… 一背景 写这一篇的目的主要是因为.NET领域内几本关于阐述GC方面的书都是纯理论所以懂得人自然懂不懂得人也没法亲自验证这一篇我就用 windbg 源码 让大家眼见为实。二为什么要引入后台GC 1. 后台GC到底解决了什么问题解决什么问题得先说有什么问题我们知道 阻塞版GC 有一个显著得特点就是在 GC 触发期间所有的用户线程都被 暂停了这里的 暂停 是一个统称画图如下这种 STWStop The World 模式相信大家都习以为常了但这里有一个很大的问题不管当前 GC 是临时代还是全量还是压缩或者标记all in 全冻结这种简单粗暴的做法肯定是不可取的也是 后台GC 引入的先决条件。那 后台GC 到底解决了什么问题?解决在 FullGC 模式下的 标记清除 回收期间放飞用户线程。虽然这是一个很好的 Idea但复杂度绝对上了几个档次。三后台GC 详解 1. 后台 GC代码 骨架图源码面前了无秘密在coreclr 项目的 garbage-collection.md 文件中描述了 后台GC 的代码流程图。GarbageCollectGeneration(){SuspendEE();garbage_collect();RestartEE();}garbage_collect(){generation_to_condemn();// decide to do a background GC// wake up the background GC thread to do the workdo_background_gc();}do_background_gc(){init_background_gc();start_c_gc ();//wait until restarted by the BGC.wait_to_proceed();}bgc_thread_function(){while (1){// wait on an event// wake upgc1();}}gc1(){background_mark_phase();background_sweep();}可以清楚的看到就是在做 标记清除 且核心逻辑都在 background_mark_phase() 函数中实现了标记的三个阶段 1.初始标记 2.并发标记 3.最终标记 , 其中 并发标记 阶段用户线程是正常运行的实现了将原来整个暂停 优化到了 2个小暂停。2. 流程图分析为了方便说明将三阶段画个图如下特别声明阶段2的重启是在 background_sweep() 方法中而不是 最终标记background_mark_phase 阶段。初始标记这个阶段用户线程处于暂停状态bgc 要做的事情就是从 线程栈 和 终结器队列 中寻找用户根实现引用图遍历然后再让所有用户线程启动简化后的代码如下void gc_heap::background_mark_phase()
{dprintf(3, (BGC: stack marking));GCScan::GcScanRoots(background_promote_callback,max_generation, max_generation,sc);dprintf(3, (BGC: finalization marking));finalize_queue-GcScanRoots(background_promote_callback, heap_number, 0);restart_vm();
}接下来怎么验证 阶段1 是暂停状态呢为了方便讲述先上一段测试代码internal class Program{static Liststring list new Liststring();static void Main(string[] args){Debugger.Break();for (int i 0; i int.MaxValue; i){list.Add(String.Join(,, Enumerable.Range(0, 100)));if (i % 10 0) list.RemoveAt(0);}}}然后用 windbg 在 background_mark_phase 函数下一个断点bp coreclr!WKS::gc_heap::background_mark_phase 即可。0:009 bp coreclr!WKS::gc_heap::background_mark_phase
0:009 g
Breakpoint 1 hit
coreclr!WKS::gc_heap::background_mark_phase:
00007ff9e7bf73f4 488bc4 mov rax,rsp
0:008 !t -specialLock DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception0 1 55d8 00000000006336B0 2a020 Preemptive 0000000000000000:0000000000000000 000000000062d650 -00001 MTA (GC) 6 2 568c 0000000000662F40 21220 Preemptive 0000000000000000:0000000000000000 000000000062d650 -00001 Ukn (Finalizer) 8 4 5730 0000000000676A90 21220 Preemptive 0000000000000000:0000000000000000 000000000062d650 -00001 Ukn OSID Special thread type0 55d8 SuspendEE 5 5688 DbgHelper 6 568c Finalizer 8 5730 GC可以清楚的看到0号线程显示了 SuspendEE 字样表示此时所有托管线程处于冻结状态。并发标记这个阶段就是各玩各的用户线程在正常执行bgc在后台进一步标记因为是并行所以存在 bgc 已标记好的对象引用关系被 用户线程 破坏所以 bgc 用 reset_write_watch 函数借助 windows 的内存页监控目的就是把那些脏页找出来在下一个阶段来修正简化后的代码如下void gc_heap::background_mark_phase()
{disable_preemptive(true);//脏页监控reset_write_watch(TRUE);revisit_written_pages(TRUE, TRUE);dprintf(3, (BGC: handle table marking));GCScan::GcScanHandles(background_promote,max_generation, max_generation,sc);disable_preemptive(false);
}要想验证此时的用户线程是放飞的可以在 revisit_written_pages 函数下一个断点即可使用命令bp coreclr!WKS::gc_heap::revisit_written_pages 。0:008 !t -specialLock DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception0 1 55d8 00000000006336B0 2a020 Cooperative 000000000D1FD920:000000000D1FE120 000000000062d650 -00001 MTA 6 2 568c 0000000000662F40 21220 Preemptive 0000000000000000:0000000000000000 000000000062d650 -00001 Ukn (Finalizer) 8 4 5730 0000000000676A90 21220 Cooperative 0000000000000000:0000000000000000 000000000062d650 -00001 Ukn OSID Special thread type5 5688 DbgHelper 6 568c Finalizer 8 5730 GC看到没有那个 SuspendEE 神奇的消失了而且 0 号线程的 GC 模式也改成了 Cooperative表示可允许操控 托管堆。最终标记等 bgc 在后台做的差不多了就可以再来一次 SupendEE将 并发标记 期间由用户线程造成的脏引用进行最终一次修正修正的数据来源就是监控到的 Windows脏页代码就不上了我们聊下怎么去验证阶段二又回到了 SuspendEE 状态可以在 background_sweep() 函数下一个断点, 命令: bp coreclr!WKS::gc_heap::background_sweep 。0:000 bp coreclr!WKS::gc_heap::background_sweep
0:000 g
coreclr!WKS::gc_heap::background_sweep:
00007ff9e7b7a2e0 4053 push rbx
0:008 !t -specialLock DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception0 1 55d8 00000000006336B0 2a020 Preemptive 0000000000000000:0000000000000000 000000000062d650 -00001 MTA 6 2 568c 0000000000662F40 21220 Preemptive 0000000000000000:0000000000000000 000000000062d650 -00001 Ukn (Finalizer) 8 4 5730 0000000000676A90 21220 Preemptive 0000000000000000:0000000000000000 000000000062d650 -00001 Ukn (GC) OSID Special thread type5 5688 DbgHelper 6 568c Finalizer 8 5730 GC SuspendEE哈哈可以看到那个 SuspendEE 又回来了。3. 后台GC 只会在 fullGC 模式下吗这是最后一个要让大家眼见为实的问题在gc触发期间内部会维护一个 gc_mechanisms 结构体其中就记录了当前 GC 触发的种种信息可以用 windbg 把它导出来看看便知。0:008 x coreclr!*settings*
00007ff9e7f82e90 coreclr!WKS::gc_heap::settings class WKS::gc_mechanisms
0:008 dt coreclr!WKS::gc_heap::settings 00007ff9e7f82e900x000 gc_index : 0xb30x008 condemned_generation : 0n20x00c promotion : 0n10x010 compaction : 0n00x014 loh_compaction : 0n00x018 heap_expansion : 0n00x01c concurrent : 10x020 demotion : 0n00x024 card_bundles : 0n10x028 gen0_reduction_count : 0n00x02c should_lock_elevation : 0n00x030 elevation_locked_count : 0n00x034 elevation_reduced : 0n00x038 minimal_gc : 0n00x03c reason : 0 ( reason_alloc_soh )0x040 pause_mode : 1 ( pause_interactive )0x044 found_finalizers : 0n10x048 background_p : 0n00x04c b_state : 0 ( bgc_not_in_process )0x050 allocations_allowed : 0n10x054 stress_induced : 0n00x058 entry_memory_load : 0x490x060 entry_available_physical_mem : 0x000000010a50d0000x068 exit_memory_load : 0从 condemned_generation2 可知当前触发的是 2 代GC原因是代满了 reason : 0 ( reason_alloc_soh ) 。四总结 看的再多还不如实操一遍如果觉得手工编译 coreclr 源码麻烦可以考虑下 windbg好了本篇就聊这么多希望对你有帮助。
