《垃圾回收的算法与实现》作者中村成洋&相川光:高手对话,揭秘GC

本文仅用于学习和交流,不用于商业目的。非商业转载请注明作译者、出处,并保留本文的原始链接:http://www.ituring.com.cn/art...

访谈对象:

中村成洋
Network Applied Communication Laboratory Ltd. 研究员。因为偶然的机会对GC产生浓厚兴趣,其本人却说不清楚为何喜欢GC,当被人追问原因时,总是回答“是缘分”。现在是CRuby的commiter,每天致力于GC的改善。如你所猜,跟Ruby之父——松本行弘是同事。执笔本书的“实现篇”。

个人网站:http://www.narihiro.info/

图片描述

图片描述

相川光
游戏开发者。京都大学学习期间开始研究GC。热爱GC但讨厌打扫,除了GC之外还喜欢咖喱。执笔本书的“算法篇”。

访谈内容:

点击查看日文版

<p style="color: green;">《垃圾回收的算法与实现》深受中国读者的喜爱,图灵代表读者向两位作者的辛苦付出表示衷心的感谢!我们都知道写书不仅耗时费力,在出版后还容易遭受同行们的指责。这一点在技术书里尤为显著,两位是出于怎样的考虑,想要完成这部著作的呢?

图片描述

中村: 想当年我学习GC那会儿,关于GC公开的信息并不太多,学起来真是相当费劲。因此,我写这本书是为了那些像当年的我一样“想要学习GC!”的读者,为了让他们能够更轻松地学习GC。

写起来真是不容易啊……多亏了合著者、审校和编辑的大力帮助,我才能完成这本作品。现在回眼望去,大部分都是靠着初生牛犊不怕虎的冲劲儿……(笑)

相川: 本书面向的读者是那些对编程有一定了解的人群。为了方便阅读,我尽可能地缩减了对编程基础知识的介绍,尽可能地对各个算法进行了深入的剖析。此外,为了让读者体会到垃圾回收的有趣之处,我也下了一番功夫。

中国方面已经翻译了理查德·琼斯老师的著作《垃圾回收算法手册:自动内存管理的艺术》,想必也有不少人已经掌握了一些GC相关的知识。本书中还介绍了一些在该书出版时尚未问世的算法,希望大家能从这些不同的观点中获得乐趣。

<p style="color: green;">能否向读者简要介绍下GC在程序中的作用?

中村: GC是一种能自动释放并回收程序中产生的那些看不见的垃圾(不要的内存空间)的机制。

相川: 一句话概括的话,GC就是“自动内存管理系统”。它是一个能把不再需要的内存空间自动释放和回收的机制。借助GC,程序员可以不用担心忘记释放或重复释放了内存空间,可以提高编程的效率。

<p style="color: green;">**目前存在的多种GC算法大都是对标记-清除算法、引用计数法、复制法的拆分组合。根据您的认识,未来真正意义上的第四种算法应该是怎样的?

中村: 第四种算法啊……这可很难回答啊。我感觉这种算法应该非常简单,并且能够应用于现实世界。就像一下子恍然大悟——“啊!还有这种清扫方法呢!”经常做家务的人或许会比较容易有灵感吧。(笑)

相川: 三种基本算法问世已经过去了几十年,这期间完全没有新的算法出现。因此,我觉得“真正意义上的第四种算法”不会那么简单地被发明出来。

话说回来,还有一些采用不同于GC标准来进行内存管理的方法(比如基于空间的内存管理方法)。在不久的将来,如果出现一种全新的GC算法,估计也是从这类方法的灵感中衍生出来的吧。

<p style="color: green;">很多高级编程语言内部就搭载有GC。这对GC技术研究开发者而言是怎样的机遇,又有哪些挑战?

相川: 还没怎么普及的时候,人们对GC的要求非常有限,无非是“高速化”“节约内存”,等等。近年来,搭载GC的语言被用于多种用途和各种环境,人们对GC的要求也必然变得多样。像“减少耗电量”“缩减应用程序的中断时间”等,出现了以往从未有过的高要求。为了满足这些要求,GC应该还有很大的研究空间。

中村: GC领域是一块非常复杂且具有专业性的领域,不过世界上把GC作为专业来研究的技术人员却不多。

比如说,如果大家能用打游击的形式,时不时写一些开源的高级编程语言的GC,时不时为GC领域作一些贡献的话,过不多久,大家也就能光靠GC来糊口了。

<p style="color: green;">内存管理和垃圾回收会成为未来编程语言发展时的考虑标准么?

相川: 我认为有可能,或者可以说,已经成为未来编程语言发展的考虑标准了。只要没有极其特殊的原因,编程语言都应该统一配备GC。

将GC导入编程语言,大体上有三种方法:第一种是使用Java和Python等已经安装了GC的语言来实现编程语言;第二种则是使用像BoehmGC这样的库;第三种就是自己来实现了。

从我个人的观点看,希望大家还是能够自己来挑战一次GC的实现。

中村: 对的。有这个可能,确实,内存管理和GC已经在逐渐成为未来编程语言发展时的考虑标准了。而且我认为,硬件和OS方面还将会添加一些支持,好让人们更容易编写GC。

<p style="color: green;">下面的问题来自读者实践过程中遇到的问题。

<p style="color: green;">①进程级的垃圾回收实现问题 (erlang这门语言使用进程级的垃圾回收机制,效率非常高。erlang有一个衍生语言叫elixir,elixir的语法很像ruby,它也使用erlang的垃圾回收机制(基于beam)。您和ruby的作者是同事,对ruby应该很熟悉,能有机会介绍elixir语言的垃圾回收机制吗?)

中村: Erlang的GC看来相当有意思。据说Erlang在轻量级进程间不存在共享对象,所以可以分进程进行GC。而且对象都是immutable的,因此程序绝对不可能引用对象生成后的新建对象。

从语言规范角度而言,程序只能引用曾经存在过的对象。Erlang就是利用这种特殊性质来高效实现GC复制算法的。

详细情况我也不太清楚,这个问题就请各位读者来研究了。

<p style="color: green;">②.垃圾回收算法对移动设备性能的影响问题 (有些ios app使用javascript相关的技术,v8是底层引擎使用垃圾回收算法释放资源,但有些手机内存很少(比如1G运存的iphone),垃圾回收的频率会很高。请问这种情况下垃圾回收算法会影响移动应用体验吗?如果想优化体验,应该如何设置垃圾回收算法的参数?)

中村: 我认为这取决于应用程序的性质。

如果是高实时性的应用程序(如游戏等),就需要考虑GC的问题。不过,像是Twitter和Facebook这种实时性低的应用程序,就不用太在意了。

想优化体验的话,还请了解各种GC的用法,赋予合适的参数。大家可以采用很多方法,例如缩短GC的时间间隔,或是缩小堆的大小……如果情况还不能得到改善,或许就需要考虑GC的问题,在应用程序这边修改一下代码了。

不同情况有不同的解决办法,所以不能一概而论,不能一口咬定“就这么解决!”这正是GC的难点所在。

相川: 在分代GC中有很多参数需要调整,例如分代的数量、用于晋升的阈值等。这就需要具体情况具体分析,按照不同程序的特性来相应地调整参数,不过说实话,我这方面的经验不是很多。关于这方面的知识,建议读者参照下面的链接。https://docs.oracle.com/cd/E1...(日文)

<p style="color: green;">③.在数据处理领域,如若数据量很大,特别是T级别的,应该如何选择GC策略,保证系统稳定、减少GC对程序的影响?

相川: 这也需要根据程序的特性来谨慎地选择。

我个人认为,对于那些巨大的内存空间来说,GC复制算法会比较有用(因为GC复制算法相对其他算法而言缺点要少一些)。在某些情况下,如果采用了GC复制算法但“垃圾还是较多”,可能就需要采用其他算法了。

总而言之,选择的策略很大程度上是受程序动作左右的。

中村: 这个问题的答案也取决于实际数据的类型以及想要达成的目的。

如果是注重实时性的操作,就需要采用在内部运行GC的策略(例如并行GC)。要是像Web应用那样,不在乎出现一些停顿的话,也可以采用Stop the world的算法。如果要处理的数据是可以长期存活的数据,那么即使使用分代GC,减少对处理数据的GC试运行次数,也会有效果的。

<p style="color: green;">④.怎么看待HotSpot的GC?它与DalvikVM、Rubinius的差异在哪里?有无优劣之分?

中村: 我认为HotSpot的GC很棒。我对此深感佩服,居然能灵活运用这么复杂的东西……

GC的算法各有各的优点和缺点。因此,很难判断其优劣之分……

HotSpot配备了大量的GC算法,用户可以从中随意选择。而且HotSpot也为大家准备了丰富的调优选项。就用户能够根据用例来进行选择这一点而言,我认为HotSpot的GC比其他的语言处理程序更出类拔萃。相反地,用户也会因为选项太多而找不着北……这边可谓是相当复杂呢。

也有人在研究用机器学习来决定调优参数和GC算法,不过要实际应用起来似乎并不简单。

相川: HotSpotVM最先采用了Mostly-Concurrent GC 和G1GC这些最新的算法。考虑到开发成本中还必须包括解释器和虚拟机主体,不得不说这非常值得赞叹。

话说回来,不能单纯断定它就比其他编程环境优秀。因为GC的性能很大程度上受应用程序的动作左右。因此,如果大家可以根据应用程序的特性来选择GC算法、进行参数的调整的话,说不定就能将GC的潜能发挥到极限。

HotSpotVM有很多GC算法可供选择,可以说,比起其他编程环境,HotSpotVM更容易将GC的潜能发挥得淋漓尽致。

<p style="color: green;">中村先生为Ruby 2.0新增了Non-recursive Marking 和Bitmap Marking。能否向中国的读者介绍下Non-recursive Marking 和Bitmap Marking的原理? 目前为Ruby在GC方面的发展在做着哪些努力?

在GC处理过程中会出现函数递归的现象,Non-recursive Marking就是用来防止这种情况的。我自己设计了栈结构,实现了把对象分配到栈上进行处理。

Bitmap Marking有点复杂。Ruby采用的是标记清除GC。这个GC一开始会遍历所有存活的对象,进行标记。
标记操作则会设置对象的header field中的FL_MARK标志。然后GC会再一次遍历所有的对象,清除所有已经死亡的对象的标记。问题就在于,这里破坏了CoW的语义,要标记的所有页面都Dirty了。

而Bitmap Marking只会把对象的FL_MARK标志单独拿出来,作为位图存放在一部分空间里。这样既能充分利用CoW的机制,又能优化某些程序(例如在Linux中使用了fork())中内存的用量。

现在我已经不再研究Ruby的GC,归隐山林了……

<p style="color: green;">请两位老师给有志于加入GC技术开发的后辈们一些规划、建议?

中村: GC是一个很难找到答案,却又趣味横生、充满挑战的领域。我认为理论部分很重要,但更重要的是试着亲身去研究实现的那些让人搞不清楚的地方。建议大家可以先由浅入深,之后自己试着实际操作!

相川: GC是一个非常有趣又深奥的主题。大家如果读了这本书,对这点就应该深有体会。

如果大家能读一些GC相关的论文,实现GC,跟其他的技术人士讨论GC,进一步拓展本书中体验到的趣味性和奥秘之处,我会感到无上的荣幸。


——更多访谈


更多精彩,加入图灵访谈微信!


图灵访谈
对话国外知名技术作者,讲述国内码农精彩人生。你听得见他们,他们也听得见你。

对话国外知名技术作者,讲述国内码农精彩人生。你听得见他们,他们也听得见你。

3k 声望
1.2k 粉丝
0 条评论
推荐阅读
谷歌开发技术推广部中国市场负责人栾跃:接轨世界、推动创新(图灵访谈)
栾跃呼吁并鼓励中国的开发者们跟世界接轨、把中国的技术创新带向世界。另外,他还热心于组建开发者社区,推动技术分享。希望在互联网技术行业里,有更多的女性加入进来,写代码、做产品开发、做项目管理,等等。

图灵访谈2阅读 3k

年度最佳【golang】内存分配详解
这篇文章主要介绍Go内存分配和Go内存管理,会轻微涉及内存申请和释放,以及Go垃圾回收。从非常宏观的角度看,Go的内存管理就是下图这个样子,我们今天主要关注其中标红的部分。友情提醒:文章有点长,建议先收藏...

去去10023阅读 3.9k评论 2

记一次使用gdb诊断gc问题全过程
上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》 然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下: 从这个图中可以发现,我们GC有一些尖峰,...

扣钉日记2阅读 1.1k

封面图
【golang】GC详解
Golang从1.5开始引入了三色GC, 经过多次改进, 当前的1.9版本的GC停顿时间已经可以做到极短. 停顿时间的减少意味着"最大响应时间"的缩短, 这也让go更适合编写网络服务程序. 这篇文章将通过分析golang的源代码来讲...

去去10022阅读 4.5k

macos平台上编译jdk源码
&emsp; 对于java来说,很多工作都被jvm包揽了,比如内存分配和回收、其他系统级别调用。这其实就把操作系统底层的一些东西给屏蔽了,对于javaer来说,方便的同时也带来一些困惑(我还不是一个纯javaer),很多细...

开翻挖掘机1阅读 2.4k评论 5

谈JVM参数GC线程数ParallelGCThreads合理性设置
在讲这个参数之前,先谈谈JVM垃圾回收(GC)算法的两个优化标的:吞吐量和停顿时长。JVM会使用特定的GC收集线程,当GC开始的时候,GC线程会和业务线程抢占CPU时间,吞吐量定义为CPU用于业务线程的时间与CPU总消耗时...

京东云开发者3阅读 315

封面图
Electron 的 GUI 和 Ruby 的 CLI 的一种交互实践
在一个中大型的客户端研发团队中,会使用诸如 Ruby、Shell、Python 等脚本语言编写的脚本、命令行和 GUI 工具来完成各项任务。比如 iOS、Android 开发人员想在一台新电脑上开发一个新 App ,那么需要先在本地配置...

云音乐技术团队1阅读 315

封面图

对话国外知名技术作者,讲述国内码农精彩人生。你听得见他们,他们也听得见你。

3k 声望
1.2k 粉丝
宣传栏