了解一下，Android 10中的ART虚拟机(8)

缘起

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

本篇 介绍第III部分中的：

• 第九章“Garbage Collection Support”

• 第十章“Runtime Helpers”

• 第十一章“Exception-Throwing”

• 第十二章“Finalization and Weak References”

• 第十三章“Modularity Design of VM”

正式开始本篇之前，我有必要推荐一本书。

推荐一本书 《深入理解Kotlin协程》

有个年轻的小伙伴Benny写了一本《深入理解Kotlin协程》的书。

书封皮最后有我写的推荐语，但很可惜是被阉割过的（ 我 理解出版社编辑的做法 ，他们并不清楚技术人对技术观点，认识上的“反复无常 ” ）。

如何正确看待协程？我个人是有一个相当大的转变的。先看推荐语的原文——

我最开始对kotlin和协程是比较“轻视”的，觉得它们无非是语法糖以及线程相关知识的新坛装旧酒。但随着我对JVM以及近些年来一些现代高级编程语言的深入学习，我突然意识到Kotlin其实远不只是基于Java，它天然就包含很多现代高级语言的特性。而协程在kotlin语言的加持下针对并发编程的痛点上更是进了一大步。很难得Benny能深入撰写一本这样的关于协程方面的论著。这本书并不简单，但值得各位读者深入学习。

其实， 周志明老师在深入理解JVM最新版的书里也提到， 协程 很可能在Java后续版本 得到支持，当然也是JDK里提供的——一个比较类似的例子就是C++11里STL搞了一个并发库一样。

本篇介绍什么

本篇内容见下图，对应原书中的第III部分最后的9到13章。

这几章内容看起来是相对比较痛苦的。痛苦的感觉是不知道讲了什么，不知道有什么用。所以，我们先大概说下这几章讨论的是什么问题。BTW，这几章之间的关联关系并不大，你可以选择感兴趣的阅读。

• 第九章Garbage Collection Support：主要讲JVM中如何实现对root对象的枚举。尤其是在遍历调用栈时，哪些寄存器里存的是对象这类问题。与之有关的一个经常碰到的词叫GC-Map。我在《深入理解Android JVM ART》一书里也简单的提到过这个对应的一个词叫StackMap。但这块内容非常复杂。

• 第十章Runtime-Helpers：看章节名称肯定是不知道在讲什么。Runtime-helper是书里经常提到的一个词，其根源是作者基于JVM模块化设计思路之上（第十三章Modularity Design of VM），将某些功能抽在一起集中研究。我在ART里并没有看到这样的一个单独模块。但与之有关的功能肯定是有的。比如，书中提到的Runtime-Helper，其价值在于“When Java code execution needs the VM-services, a runtime-helper is called that helps

  transition the control from the Java world to the native world

  ”。在这里，native word包括JNI层以及JVM自身的服务（例如抛异常，例如MONITORENTER的实现等）。另外，我想说下，这种划分是从模块化设计角度来看的，但离具体场景有些远，不太好学习（虽然这一章最后列了一些场景....）。这一章我不太想讲太多，比较干瘪。

• 第十一章"Exception-Throwing"：这一章内容非常明确，就是将异常投递。我在研究ART里异常投递的时候，碰到的最大困难还是在于栈回溯和寄存器有关的内容。我曾经在去上海参加Droidconf 2018大会的火车上思考了好几个小时。当然，看了这本书之后我有了一些新的感受。上篇好像也提过，就是我们对汇编开发时对函数调用的不熟悉。如果有汇编写函数调用，栈都是要自己维护和处理的。哪些寄存器干什么用都是套路。只可惜我们对这些套路都不太了解。

• 第十二章"Finalization and Weak References"。专门介绍大GC领域里的"小众"知识。这个在ART一书里的"14.8 Java Reference对象的处理"一节中有非常详细的介绍。本文拟简单说几句

• 第十三章"Modularity Design of VM"：以Apache Harmony为例介绍VM的模块化设计。这一章肯定不如我大ART那本书了，真刀实枪 的 干源码还是更直接点。要是没看过源码，光看书里写得这几页能学到什么？ 我打算介绍下ART里的各个模块。

ART里的各种模块

我把 ART里（以写书的7.0为主）各种比较常见的模块列了下。 相对来说，这些名字取得还是比较达意的，基本一看就能想到是干什么的

但是，你要说这些模块有没有“模块化的设计”？肯定有，也可能没有。什么意思呢？

• 肯定有：ART里有很多接口类，比如CodeGenerator、Assembler等。都可以通过接口类来解决不同CPU架构上的机器码生成。这肯定是解耦的，这是很明显的模块化的设计。

• 可能没有：所谓的抽象也只是行为的解耦，但数据结构解耦不了。数据结构如果无法解耦，完全意义上的模块化设计也做不到。说白了，模块和模块之间还是耦合很厉害。可惜这本书在第十三章“模块化设计”里说的都是行为上的模块化。但其实数据结构无法解耦导致了巨大的学习困难。

Soft-Reference对象回收顺序的考虑

关于 Reference， 本文 不打算 说太多基础知识，因为每个搞Java开发的，都自认为了解它。 但正如我在 ART一书第14章14.8节 书里所说 ， “ Java Reference 是很多公司面试 Java 开发者 时必问的知识点。 从某种角度来看，这说明大家对 JavaReference 的知识是 即熟悉又陌生。 熟悉它的理由是大部分开发者都能说出几种 Reference 的差别以及各自适合的使用场景，而对它陌生的原因也很简单。 毕竟，我们很少有机会能通过虚拟机的源代码来真正了解 Reference 。 可以这么说，在没有看到源代码之前，我们只是知其然。 看完源代码后，我们就能做到知其所以然 ”。