了解一下,Android 10中的ART虚拟机(9)-完结

缘起

继续从读书笔记的角度来系统的学习《Advanced Design and Implementation of Virtual Machines》。这本书是英文编写,全部、认真、深入的读下来非常考验人。我之前也只是读了60%,而且越到后面越没有耐心。想了想,JVM在系统层面上要达到一定水准,可能还是得精读一到两本这样的书籍。记读书笔记是我学习知识和技能的一种比较好的方式,伴随我至少20多年了。暂且给这次的读书笔记取名“关于VM的理论”。

本篇介绍最后两个部分:

本文是我们对ADIVM一书阅读笔记的结束。今天这篇文章会讲得稍显粗糙,毕竟,这属于高级部分——优化嘛....有些地方我只能整理个大概,让你知道作者在说什么(如果不整理的话,基本属于不知所云,完全搞不清状况的那种)。

GC基础知识回顾

先回顾下GC基础知识,也是我在《深入理解Android JVM ART》一书第十四章里的摘抄。

从大道理上说,一共有四种基础GC方法。

  • Mark Sweep

  • Copying Collection

  • Mark Compact

  • Reference Counting

下面是除Reference Counting之外的三种GC方法的示意图。

Mark Sweep的原理如上。大致是找到存活对象,然后把垃圾对象就地清理掉。这种方法理解起来相对简单,也没有什么附加操作。但实际使用时,会造成内存碎片。

Copying collection就是把存活对象拷贝到一个空闲区域。拷贝的时候可以重新排位置,让大家挤在一起。这样,内存碎片的问题就解决了。但这个拷贝肯定有开销,而且还存在拷贝前/后对象被引用的问题。另外,内存空间还要事先留一块做空闲区域,有点浪费。

Mark Compact其实和Copying差不多。只不过它不留单独一块空闲区域。而是移动....所谓的Compact(压缩,其实就是移动)

以上是三种基础GC的示意。接下来我们看看书中是怎么优化GC的。

GC优化之提高吞吐量(Throughput)

作者首先谈如何提高GC的吞吐量。这一章一上来就是一堆公式。我觉得主要难在如何定义和计算吞吐量上。我们先看看作者关心的是什么。

在讨论GC吞吐量时,作者的第一个优化设计考虑点是想讨论Partial Heap和Full Heap回收的时机选择问题。也就是minor/major GC如何搭配。注意,这基于了一个大前提,就是对Heap区域进行了划分。上面图中左下角是Heap的划分。右边是分类。

基于这么一个目的,整出了几个数学公式。下面是对原文内容的高度提炼。我感觉看不看都可以...BTW,我翻了下美亚上对这本书的评价,其中有一条说到,本书后面有一大堆引用材料。但是在正文里却一丁点没提到某个内容来自哪个文献。说实话,我对下面的吞吐量计算感觉模模糊糊的,但是又不知道是作者自己想出来的还是参考了哪些文献....

作者首先定义了吞吐量的计算公式,即APP运行期内总的回收内存大小/总的回收耗时。但这个太难计算,所以又定义了一个周期,即从一次major gc结束开始,到下一次major gc结束时结束。这个周期内包含一次major gc和若干个minor gc。假设每次minor gc的耗时差不多(都是Tminor),一次major gc的耗时差不多(都是Tmajor)。巴拉巴拉....

下面就到头晕的地方了....

上面的公式里其实做了不少假设。比如,minor gc后,应用大概都会分配dS大小的非垃圾内存.....但我感觉还不止这些假设,所以这一章其实难度挺大(现在理解美亚那个评论所体现的无奈了吧)。

最后,作者得到一个吞吐量计算公式。在Fmax/dS/Tmin/Tmax固定的情况下,解了一个微分方程。然后,下面又假设Fmin=16MB,做了一组吞吐量测试。这个逻辑确实跳跃太大(实在没明白这个图是怎么画出来的).....

上图左下角的优化前提条件以及最终的结论(早一点开始做Major GC)。

接着,对提高吞吐量的第二个设计考虑是使用分代GC还是不分代GC

以上是一些关键知识提炼。最终的结论如下:

按作者的测试结果,分代GC的吞吐量一开始比不分代GC低,但后面又高了。所以,作者提供的优化手段就是开始做不分代GC,吞吐量高。到某个点后,改做分代GC.....优化的思路就是这么简单粗暴。当然,具体怎么做到还是挺考验的。但目标确实就是这么直接..

提高吞吐量的最后一个设计考虑如下,这个主要从提高运行速度来看的。

GC优化之提高Scalability

GC的另一个优化是如何利用多核优势,提高吞吐量。这一章更枯燥,建议了解要做什么先..

上图中解释了concurrent gc和parallel gc的区别。concurrent gc强调的是mutator和collector的关系,并行工作。而parallel gc强调的是有多个collector的并行工作。

这一章讨论的内容见1、2、3的介绍。再次强调,本书的一个非常大的特点是很多同级的内容并不是并列关系。比如上图中所说的1和2。Object Traversal包含了Object Marking。另外,请注意Mark-Stack这个数据结构。这也是ART一书中GC部分常见的词。还有,书中说,根对象枚举由于需要暂停mutator的运行,Scalability对这个场景没有什么意义…

Traversal其实就是为了mark。但单独讲mark,只是mark这块还可以做一些别的优化设计…

针对多核,优化设计考虑点之一就是Parallel object traversal。由于被扫到的对象都要加到MarkStack里,这就变成一个典型的多写/多读的生产者/消费者模型。见下图解释:

当然,如果要加上负载均衡等处理,情况又会复杂多了。总之,作者在这一章里提到的三种优化方法都是更好解决多写/多读问题的。具体细节不讨论。有人会觉咱这篇文章里可能什么也没说。其实,你要是没有机会看到这篇文章的话,我有90%的几率预测你可能看不懂原文(或者是不知道原文在讨论什么)

接下来讨论的Parallel Object Marking。

正如我前面所说,上面两页图的内容在原文中是并列的标题。但显然Object Marking讨论的只是Traversal的一个小点....

最后,这一章还讨论一个优化设计点——Parallel Compaction。

先留着吧。等你看到原文这部分的时候再来回顾....

GC优化之提高Responsiveness

提高响应速度,这恐怕是很多键盘侠都能出来说道几句的地方。这个也是成熟技术了,我感觉主要手段还是concurrent....

优化设计考虑点之一——Concurrent Tracing。关键内容如下:

三个基本保证很重要。作者讨论相关GC方法时,最终要归结到满足这三个条件。

  • 不能漏掉一个存活对象

  • 可以保留一些垃圾对象,但最终要能回收它们

  • Tracing要能结束,不能陷入死胡同出不来。

Concurrent Tracing的整体情况如上图所示。首先,要明确Root根对象枚举完之后,才有concurrent之说。针对图中3中最后提到的问题,设计了下面三种办法。

本文只结束Snapshot-At-The-Beginning法。借助Write Barrier,当对象的成员变量被修改的时候,我们记住。注意看上面的示意图。

  • A.f1,f2,f3分别指向B、C、D三个对象。

  • 此时,A.f1赋值给了a,随后A.f1指向X。那么,A.f1原来指向的B对象就没有被记住。也不可能被找到。因为A被标记过了,不会再次被标记。

所以,借助Write-Barrier,我们主动记住B。相当于B也是被记住的对象。B需要被记住的原因是它可能是一个垃圾对象,也可能不是一个垃圾对象。不能现在就把它看做是垃圾对象(否则一旦被回收就会出问题。要注意的点是,mutator和collector此时是同时工作的)。SATB(Snapshot-At-The-Beginning)法就是这么个意思。里边还有一些变种方法。

接下来的优化设计考虑点是concurrent root-set enumeration。这个是有点难度。对这个优化点的真实含义需要仔细阅读原文。即它讨论的是多个mutator之间如何concurrent进行root-set枚举。

ART里,貌似没有使用“这么高级”(也可能是没有成熟实现)的办法。ART里线程栈中根对象的Visit属于NonCurrentRoot,是要暂停所有mutator后才能访问的....

Concurrent Moving Colleciton

这一章的安排也是中了我上面说内容并排的问题。前面三章从Throughput、Scalability、Responsiveness三个方面讲如何优化GC。这一章突然就是某个具体的GC方法...

ART里也有地方用到了concurrent moving gc法。注意下面的关键步骤。

CMC(Concurrent Moving Collection的缩写)优化设计考虑是一个出发点。就是mutator是否看到两个Obj A(一个是原Obj A,在From-Space里,一个是拷贝过去的Obj A',在To-Space里)。如果只看到To-Space里的Obj A,这个设计就叫To-Space Invariant。本篇主要介绍这个设计

注意2.a的处理。Rootset枚举完后,需要先把Root Set里的根对象移动到To-Space里。然后才恢复mutator的运行。

而关于2.b的处理,则借助了Read Barrier。见下图。

ART代码里会经常出现kUseBakerReadBarrier的常量。这个就是上图示意的Read-Barrier,其实严格来说是Load Barrier。因为不光Read,Write的时候也要做一些工作。这个方法最早是Baker提出来的.....

以上,就是和GC有关的优化部分。难度相当大。而且,原文也没有和参考文献做一个比较明确的关联,所以读起来会比较痛苦。我建议还是了解目的,具体怎么弄的,倒是可以结合ART的源码进行细致研究。

Lock实现和基于硬件的内存事务

本书最后两章分别讨论了对Lock的优化以及对基于硬件的内存事务技术在JVM上可能带来的帮助。

先看对Lock的介绍

说实话,我觉得不如直接看ART一书的第12.3节。ART的Lock综合了上图中提到的几种技术。上面的讨论其实更多像是一个回顾(当然,你要是不了解ART做法的话,不会有这种感觉)。这几项技术倒也不复杂,建议直接看我书(结合代码)算了。比这里讨论的强(我认为作者是在回顾这些优化技术,而不是提出什么新的东西)

本书最后一章介绍了基于硬件的事务内存技术在JVM实现里可能的用处。我不想讲太多,这个看下图的左下角一部分概要介绍即可。

JVM读书笔记总结

这本书总体上来说内容相当丰富。JVM本身是一门工程。工程的话,经验、某些领域优化的积累会相对较多,没有太多条条框框的理论(GC其实更多是一种优化)。在阅读ART源码的时候,注定会碰到本书提到的内容。所以,这本书应该是一本集成汇总类的书籍(其参考的各种文献材料也是后续做深入研究的宝库)。

最后的最后

  • 我期望的结果不是朋友们从我的书、文章、博客后学会了什么知识,干成了什么,而应该是说,神农,我可是踩在你的肩膀上的喔。

  • 关于学习方面的问题,我已经讨论完了。后面这个公众号将对一些基础的技术,新技术做一些学习和分享。也欢迎你的投稿。不过,正如我在公众号“联系方式”里说的那样——郑渊洁在童话大王《智齿》里有一句话令我印象深刻,大意是“我有权保持沉默,但你说的每一句话都可能成为我灵感的源泉”。所以,影响不是单向的,很可能我从你那学到的东西更多。

神农和朋友们的杂文集

长按识别二维码关注我们

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值