Go 语言的垃圾回收演化历程:垃圾回收和运行时问题
Google Go 团队的成员 Richard L. Hudson (Rick) 近日在 Go 的官方博客和大家分享了他在2018年6月18日国际内存管理研讨会(ISMM)上发表的主题演讲稿。在过去的25年里,ISMM 一直是发布内存管理和垃圾回收论文的首选场所,而 Rick 也因其在内存管理方面的工作而被大家熟知。
Rick 是内存管理方面的专家,发明了 Train, Sapphire 和 Mississippi Delta 等算法,其中 GC stack maps 算法使得静态类型语言(比如:Modula-3, Java, C# 和 Go)的垃圾回收成为可能。他还发表了很多关于语言运行时内存管理、并发、并行、内存模型、事务内存的文章。Rick 作为 Google Go 团队的一员,负责 Go 的 GC 和运行时的问题。
Risk 在演讲稿中先是介绍了 Go GC 取得的成功。
Go 的应用程序中有数十万个堆栈(stacks),它们由 Go scheduler 调度程序管理,并总是在 GC safepoints 处被抢占。Go scheduler 调度程序将 Go routines 多路复用到 OS 线程上,希望每个 HW 线程使用一个 OS 线程来运行。通过复制它们并更新堆栈中的指针来管理堆栈及其大小,这是一个本地操作,因此它可以很好地扩展。
Go 语言包含两大可调节的方法来控制 GC,一个是 SetGCPercent,另一个则是 SetMaxHeap。前者可以调整你想要使用多少 CPU 以及你想要使用多少内存。后者尚未发布但正在内部使用和评估,它允许程序员设置最大的堆内存大小应该是多少,MaxHeap 还提供了更多的调度灵活性,运行时(runtime)可以将堆的大小调整为 MaxHeap。
而对于 Go 语言的 GC 延迟问题,开发团队为解决它们付出了巨大的心血。从2014年开始,最初的计划是做一个无 read barrier 的并发复制GC,因为读取的开销存在很大的不确定性,所以 Go 想要避免它们。
但当时由于编译器的性能限制所在,后来他们放弃了实现“复制”部分。
然后 Risk 谈到了最终推动 GC 延迟问题走向成功的 GC Pacer,它确定何时最佳地启动 GC 循环,当然它做的远不止这些,这只是基本方法。
谈到成功,自然也会有失败。Risk 和大家分享了类似 ROC(Request Oriented Collecter) 这种方案的失败尝试,他们采用 ROC 方案后,发现这反而降低了 write barrier 的速度。
谈到 Go 语言的未来方向方面,Risk 表示不打算增加 GC API surface,现在已经很合适,并且没有一个应用程序重要到足以让他们添加新标志。他们还将研究如何改进已经非常好的逃逸分析并优化 Go 的“面向价值(value-oriented)”编程。不仅在编程中,还包括为用户提供的工具中。在算法上,将关注设计空间的一些部分。
最后,Risk 表示希望摩尔定律在接下来的5年中能更好的体现在 RAM 而不是 CPU。
更多内容请查看原文 https://blog.golang.org/ismmkeynote
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
详细的多维度测评,看看哪个 Python 版本速度最快!
哪个版本的 Python 最快? 当然,这些问题由多种因素决定,其中的主要的因素是什么呢?我们又如何为自己的应用寻找最快的 Python 版本呢?带着这些问题,Hackermoon 上一位叫Anthony Shaw的作者为我们做了一些测试。 Anthony Shaw:Dimension Data 的 Talent 集团总监,Python 软件基金会成员,Apache 基金会成员 以下是对作者原文的翻译: 使用 Python 性能测试套件 正如之前我在speed.python.org 网站提到的,Python 核心开发团队非常重视性能问题,这对于比较官方基准和 CPython 版本非常有用。 如图,测试结果很难直观读取 其中不包含 PyPy 你可以通过执行 pip install performance 命令来下载测试套件,然后执行如下命令: pyperformance run --python={chosen_python_runtime} -o my_results.json 该命令会针对 Python 的目标版本多次运行一系列“实际”应用程序,并记录测试结果,取其平均值。 本文我对...
- 下一篇
Python 的后 Guido 时代: “独裁”是管理项目的最好制度?
有“终身仁慈独裁者(BDFL)”之称的 Python 创始人Guido van Rossum 宣布退出 Python 核心开发组决策层已有一周,从那以后社区发生了什么,治理项目的未来又将如何? Guido 在宣布退出决策层时明确表示不会任命继任者,但会作为一个普通的开发者待在 Python 核心开发组一段时间,并让社区来确定项目的治理进展。他还强调社区应重点管理两个主要问题:如何决定 PEP 的进展以及如何引入新的核心开发者。 Barry Warsaw提出了一种治理模式,建议将一个单一的 BDFL 与官方的顾问委员会保持一致。顾问委员会将帮助控制 BDFL,并防止做出任何片面的独裁决定。 而Red Hat 的Victor Stinner 提出可参考 PHP 的做法,对于 PEP,他希望可以像 PHP 那样,支持大多数人同意的投票,但投票权要保留给核心开发者。 到这里,社区围绕选择“民主”这个治理手段已经出现了不同的意见。所以民主是最好的选择吗?或者Barry Warsaw 的想法更适合语言的发展?说到民主,就离不开独裁,说到“独裁”,除了 BDFL,不得不提到的另一位人物就是Linus...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果