[新闻] WebKit的新并发GC:Riptide

Filip Pizlo‏大大又发新文了:Introducing Riptide: WebKit’s Retreating Wavefront Concurrent Garbage Collector

这次讲的是WebKit / JavaScriptCore里名为“Riptide”的新的并发GC。这篇文章符合Filip大大的一贯风格,介绍了大量背景知识然后才深入到Riptide自身的具体情况。值得一读。

这个新GC其实去年年底就已经在WebKit的主干上打开了,让JavaScriptCore也终于赶上了时代的步伐用上了并发GC:(在JavaScript引擎中,这方面原本领先的是Chakra / ChakraCore)

Filip Jerzy Pizlo‏
@filpizlo

The WebKit retreating wavefront concurrent/parallel/generational GC is enabled on 64-bit as of r209694. Hopefully for good this time!

8:44 PM - 11 Dec 2016

Filip大大这篇博文本身写得还挺循序渐进的,所以即便没有太多背景知识也应该能读懂个大概。但如果想要更多背景知识的话,我还是强力推荐先阅读经典读物《The Garbage Collection Handbook》再去读Filip大大这篇文章。如果嫌整本大部头读起来太费劲,可以试试读这篇精简的演示稿:Concurrent Garbage Collection - GC Seminar

Filip大大这篇文章提到的“retreating wavefront barrier”不是什么新东西,文中也明确指出了。但他在提到其它使用相同概念的barrier的实现的时候列举得不太全,只列举了BDW(Boehm GC)和Chakra / ChakraCore。其实Oracle/Sun HotSpot VM里的CMS(Mostly Concurrent Mark-Sweep)、Go 1.5开始使用的Concurrent Mark-Sweep GC、Android Runtime(ART)里的CMS GC都用了完全一样的概念,Lua 5.1开始用的Tricolor Incremental Mark-Sweep对table的处理也是retreating wavefront的——当然实现细节各自不同。对这些实现有更多了解的同学可以借此理解Riptide是个怎样的基本概念。特别是HotSpot VM的CMS GC上,也同样反映出“并发GC与分代式GC使用完全相同的write barrier,使并发GC不对应用程序带来额外的throughput开销”的特征。

它们都使用了incremental update系的write barrier来发现在并发标记过程中改变的引用关系,而且使用这样的barrier的并发GC常常会有initial marking(或者叫root marking)和remarking(或者叫snapshot-at-the-end)这两个阶段是需要暂停应用线程的。

可以通过一些技巧来规避这两个暂停,例如说使用checkpointing(或者叫ragged safepoint)来处理initial marking使不同应用线程错开暂停的时间,又或者利用多个短暂停或一个可放弃的并发处理阶段来打散或减轻remarking的暂停时间。

从文中的介绍可以看到,Riptide使用的是stop-the-world的initial marking(外加一些constraints可能带来的stop-the-world),然后使用多个短暂停来打散remarking暂停的做法。具体的策略挺有趣的。

文章被以下专栏收录
18 条评论
推荐阅读