• 一个后台 JIT 编译器线程；
• GC sweeper 现场；
• 并发 GC marker 线程；

VM 在内部使用线程池 (dart::ThreadPool) 来管理 OS 线程，并且代码是围绕 dart::ThreadPool::Task 概念而不是围绕 OS 线程的概念构建的。

例如在 GC VM 中将 dart::ConcurrentSweeperTask 发布到全局 VM 的线程池，而不是生成专用线程来执行后台清除，并且线程池实现要么选择空闲线程，要么在没有可用线程时生成新线程；类似地，用于 isolate 来消息处理事件循环的默认实现实际上，并没有产生专用的事件循环线程，而是在新消息到达时将dart::MessageHandlerTask 发布到线程池。

dart::Isolate 类相当于一个 isolate ，dart::Heap 类相当于 isolate 的堆，dart::Thread 类描述了线程连接到 isolate 相关的状态。

请注意，该名称 Thread 可能会让人有些困惑，因为所有 OS 线程都附加到与 Mutator 相同的 isolate，将重用相同的 Thread 实例。有关 isolate 消息处理的默认实现，请参阅 Dart_RunLoop 和 dart::MessageHandler。

通过 JIT 运行源代码

本节将介绍当从命令行执行 Dart 时会发生什么：

// hello.dart
main() => print(‘Hello, World!’);

$ dart hello.dart
Hello, World!

Dart 2 VM 开始不再具有从原始代码直接执行 Dart 的能力，相反 VM 希望获得包含序列化内核 AST 的内核二进制文件（也称为 dill 文件）。将 Dart 源代码翻译成 Kernel AST 的任务是由通用前端 (CFE)处理的，CFE 是用 Dart 编写并在不同 Dart 工具上共享（例如 VM、dart2js、Dart Dev Compiler）。

为了保持直接从源代码执行 Dart ，这里托管一个名为 kernel service 的辅助 isolate，它处理将 Dart 源代码编译到内核中，然后 VM 运行生成的内核二进制文件。

然而这种设置并不是 CFE 和 VM 运行 Dart 代码的唯一方法，例如 Flutter 是将编译到 Kernel 的过程和从 Kernel 执行的过程完全分离，并将它们放在不同的设备上实现：编译发生在开发者机器（主机）上，执行在目标移动设备上处理，目标移动设备接收由 flutter 工具发送给它的内核二进制文件。

这里需要注意，该 Flutter 工具不处理 Dart 本身的解析， 相反它会生成另一个持久进程 frontend_server，它本质上是围绕 CFE 和一些 Flutter 特定的 Kernel-to-Kernel 转换的封装。

frontend_server 将 Dart 源代码编译为内核文件， 然后 flutter 将其发送到设备， 当开发人员请求热重载时 frontend_server 开始发挥作用：在这种情况下 frontend_server 可以重用先前编译中的 CFE 状态，并重新编译实际更改的库。

一旦内核二进制文件加载到 VM 中，它就会被解析以创建代表各种程序实体的对象，然而这个过程是惰性完成的：首先只加载关于库和类的基本信息，源自内核二进制文件的每个实体都保留一个指向二进制文件的指针，以便以后可以根据需要加载更多信息。

每当我们引用 VM 内部分配的对象时，我们都会使用 Untagged 前缀，因为这遵循了 VM 自己的命名约定：内部 VM 对象的布局由 C++ 类定义，名称以 Untagged头文件 runtime/vm/raw_object.h 开头。例如 dart::UntaggedClass 是描述一个 Dart 类 VM 对象， dart::UntaggedField 是一个 VM 对象

只有在运行时需要它时（例如查找类成员、分配实例等），有关类的信息才会完全反序列化，在这个阶段，类成员会从内核二进制文件中读取，然而在此阶段不会反序列化完整的函数体，只会反序列化它们的签名。

此时 methods 在运行时可以被成功解析和调用，因为已经从内核二进制文件加载了足够的信息，例如它可以解析和调用 main 库中的函数。

package:kernel/ast.dart 定义了描述内核 AST 的类； package:front_end 处理解析 Dart 源代码并从中构建内核 AST。dart::kernel::KernelLoader::LoadEntireProgram是 将内核 AST 反序列化为相应 VM 对象的入口点；pkg/vm/bin/kernel_service.dart 实现了内核服务隔离，runtime/vm/kernel_isolate.cc 将 Dart 实现粘合到 VM 的其余部分； package:vm 承载大多数基于内核的 VM 特定功能，例如各种内核到内核的转换；由于历史原因一些特定于 VM 的转换仍然存在于 package:kernel 中。

最初所有的函数都会有一个占位符，而不是它们的主体的实际可执行代码：它们指向 LazyCompileStub，它只是要求运行时系统为当前函数生成可执行代码，然后 tail-calls 这个新生成的代码。

第一次编译函数时，是通过未优化编译器完成的。

未优化编译器分两遍生成机器代码：

• 1、遍历函数体的序列化 AST 以生成函数体的控制流图( CFG )，CFG 由填充有中间语言( IL ) 指令的基本块组成。在此阶段使用的 IL 指令类似于基于堆栈的虚拟机的指令：它们从堆栈中获取操作数，执行操作，然后将结果推送到同一堆栈。

实际上并非所有函数都具有实际的 Dart / Kernel AST 主体，例如在 C++ 中定义的本地函数或由 Dart VM 生成的人工 tear-off 函数，在这些情况下，IL 只是凭空创建，而不是从内核 AST 生成。

• 2、生成的 CFG 使用一对多的底层 IL 指令直接编译为机器代码：每个 IL 指令扩展为多个机器语言指令。

在此阶段没有执行任何优化，未优化编译器的主要目标是快速生成可执行代码。

这也意味着：未优化的编译器不会尝试静态解析内核二进制文件中未解析的任何调用，VM 当前不使用基于虚拟表或接口表的调度，而是使用内联缓存实现动态调用。

内联缓存的原始实现，实际上是修补函数的 native 代码，因此得名内联缓存，内联缓存的想法可以追溯到 Smalltalk-80，请参阅 Smalltalk-80 系统的高效实现。

内联缓存背后的核心思想，是在特定的调用点中缓存方法解析的结果，VM 使用的内联缓存机制包括：

• 一个调用特定的缓存（ dart::UntaggedICData），它将接收者的类映射到一个方法，如果接收者是匹配的类，则应该调用该方法，缓存还存储一些辅助信息，例如调用频率计数器，用于跟踪给定类在此调用点上出现的频率；

• 一个共享查找 stub ，它实现了方法调用的快速路径。这个 stub 搜索给定的缓存，以查看它是否包含与接收者的类匹配的条目。如果找到该条目，则 stub 将增加频率计数器和 tail-calls 用缓存方法。否则 stub 将调用一个运行时系统助手来实现方法解析逻辑。如果方法解析成功，则缓存将被更新，后续调用将不需要进入运行时系统。

如下图所示，展示了与 animal.toFace() 调用关联的内联缓存的结构和状态，该缓存使用 Dog 的实例执行了两次，使用 Cat 的实例执行了一次C。

未优化的编译器本身足以执行任何 Dart 代码，然而它产生的代码相当慢，这就是为什么 VM 还实现了自适应优化编译管道的原因，自适应优化背后的想法是：使用运行程序的执行配置文件来驱动优化决策。

当未优化的代码运行时，它会收集以下信息：

• 如上所述，内联缓存收集有关在调用点观察到的接收器类型的信息；
• 函数和函数内的基本块相关联的执行计数器跟踪代码的热点区域；

当与函数关联的执行计数器达到一定阈值时，该函数被提交给后台优化编译器进行优化。

优化编译的启动方式与非优化编译的启动方式相同：通过遍历序列化内核 AST ，为正在优化的函数构建未优化的 IL。

然而不是直接将 IL 处理为机器代码，而是基于表单的优化 IL， 优化编译器继续将未优化的 IL 转换为静态单赋值(SSA) ，然后基于 SSA 的 IL 根据收集的类型反馈进行专业化的推测，并通过一系列Dart 的特定优化，例如：

• 内联（inlining）；
• 范围分析（range analysis）；
• 类型传播（ type propagation）；
• 代理选择（representation selection）；
• 存储加载和加载转发（store-to-load and load-to-load forwarding）；
• 全局值编号（global value numbering）；
• 分配下沉（,allocation sinking）等，；

最后使用线性扫描寄存器和简单的一对多降低 IL 指令，将优化的 IL 转化为机器代码。

编译完成后，后台编译器会请求 mutator 线程进入安全点并将优化的代码附加到函数中。

广义上讲，当与线程相关联的状态（例如堆栈帧、堆等）一致，并且可以在不受线程本身中断的情况下访问或修改时，托管环境（虚拟机）中的线程被认为处于安全点。通常这意味着线程要么暂停，要么正在执行托管环境之外一些代码，例如运行非托管 native 代码。

下次调用此函数时， 它将使用优化的代码。 某些函数包含非常长的运行循环，对于那些函数，在函数仍在运行时，将执行从未优化代码切换到优化代码是有意义的。

这个过程被称为堆栈替换( OSR )，它的名字是因为：一个函数版本的堆栈帧被透明地替换为同一函数的另一个版本的堆栈帧。

编译器源代码位于 runtime/vm/compiler 目录中；编译管道入口点是 dart::CompileParsedFunctionHelper::Compile；IL 在 runtime/vm/compiler/backend/il.h 中定义；内核到 IL 的转换从 dart::kernel::StreamingFlowGraphBuilder::BuildGraph 开始，该函数还处理各种人工函数的 IL 构建；当 InlineCacheMissHandler 处理 IC 的未命中，dart::compiler::StubCodeCompiler::GenerateNArgsCheckInlineCacheStub 为内联缓存存根生成机器代码； runtime/vm/compiler/compiler_pass.cc 定义了优化编译器传递及其顺序； dart::JitCallSpecializer 大多数基于类型反馈的专业化。

需要强调的是，优化编译器生成的代码，是在基于应用程序执行配置文件的专业推测下假设的。

例如，一个动态调用点只观察到一个 C 类的实例作为一个接收方，它将被转换成一个可以直接调用的对象，并通过检查来验证接收方是否有一个预期的 C 类。然而这些假设可能会在程序执行期间被违反：

void printAnimal(obj) {
print(‘Animal {’);
print(’ ${obj.toString()}’);
print(’}’);
}

// Call printAnimal(…) a lot of times with an intance of Cat.
// As a result printAnimal(…) will be optimized under the
// assumption that obj is always a Cat.
for (var i = 0; i < 50000; i++)
printAnimal(Cat());

// Now call printAnimal(…) with a Dog - optimized version
// can not handle such an object, because it was
// compiled under assumption that obj is always a Cat.
// This leads to deoptimization.
printAnimal(Dog());

每当代码正在做一些假设性优化时，它可能会在执行过程中被违反，所以它需要保证当出现违反假设的情况下，可以恢复原本的执行。

这个恢复过程又被称为去优化：当优化版本遇到它无法处理的情况时，它只是将执行转移到未优化函数的匹配点，并在那里继续执行，函数的未优化版本不做任何假设，可以处理所有可能的输入。

VM 通常在去优化后丢弃函数的优化版本，而之后再次重新优化它时，会 使用更新的类型反馈。

VM 有两种方式保护编译器做出的推测性假设：

• 内联检查（例如CheckSmi，CheckClassIL 指令）验证假设在编译器做出此假设的使用站点是否成立。例如将动态调用转换为直接调用时，编译器会在直接调用之前添加这些检查。
• Global guards 会运行时丢弃优化代码，当依赖的内容变化时。例如优化编译器可能会观察到某个 C 类从未被扩展，并在类型传播过程中使用此信息。然而随后的动态代码加载或类终结可能会引入一个子类 C。此时运行时需要查找并丢弃在 C 没有子类的假设下编译的所有优化代码。运行时可能会在执行堆栈上找到一些现在无效的优化代码，在这种情况下受影响的帧将被标记为“去优化”，并在执行返回时取消优化。这种去优化被称为惰性去优化: 因为它被延迟执行，直到控制返回到优化的代码。

去优化器机制在 runtime/vm/deopt_instructions.cc 中，它本质上是一个解优化指令的微型解释器，它描述了如何从优化代码的状态，重建未优化代码的所需状态。去优化指令由 dart::CompilerDeoptInfo::CreateDeoptInfo 在编译期间针对优化代码中的每个潜在"去优化"位置生成。

从快照运行

VM 能够将 isolate 的堆，或位于堆中的更精确地序列化对象的图称为二进制快照，然后可以使用快照在启动 VM isolates 时重新创建相同的状态。

快照的格式是底层的，并且针对快速启动进行了优化：它本质上是一个要创建的对象列表以及有关如何将它们连接在一起的说明。

快照背后的最初想法：VM 无需解析 Dart 源和逐步创建内部 VM 数据结构，而是可以将所有必要的数据结构从快照中快速解包出来，然后进行 isolate up。

快照的想法源于 Smalltalk 图像，而后者又受到 Alan Kay 的硕士论文的启发。Dart VM 使用集群序列化格式，这类似于 《Parcels: a Fast and Feature-Rich Binary Deployment Technology》和《Clustered serialization with Fuel》论文中描述的技术。

最初快照不包括机器代码，但是后来在开发 AOT 编译器时添加了此功能。开发 AOT 编译器和带有代码的快照的动机：是为了允许在由于平台级别限制而无法进行 JIT 的平台上使用 VM。

写在最后

在技术领域内，没有任何一门课程可以让你学完后一劳永逸，再好的课程也只能是“师傅领进门，修行靠个人”。“学无止境”这句话，在任何技术领域，都不只是良好的习惯，更是程序员和工程师们不被时代淘汰、获得更好机会和发展的必要前提。

如果你觉得自己学习效率低，缺乏正确的指导，可以加入资源丰富，学习氛围浓厚的技术圈一起学习交流吧！

加入我们吧！群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的Android交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。

35岁中年危机大多是因为被短期的利益牵着走，过早压榨掉了价值，如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。

我们吧！群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的Android交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。

35岁中年危机大多是因为被短期的利益牵着走，过早压榨掉了价值，如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。