发现

任务

客服工单

发文章

Dart假造机运行原理

程序员 2024-9-15 22:41:38 123 0 来自 中国
一、Dart假造机

1.1 弁言

Dart VM是一种假造机，为高级编程语言Dart提供实行情况，但这并意味着Dart在D假造机上实行时，总是接纳解释实行或者JIT编译。 比方还可以利用Dart假造机的AOT管道将Dart代码编译为呆板代码，然后运行在Dart假造机的精简版情况，称之为预编译运行时(precompiled runtime)情况，该情况不包罗任何编译器组件，且无法动态加载Dart源代码。
1.2 假造机怎样运行Dart代码

Dart VM有多钟方式来实行代码：

  • 源码或者Kernel二进制(JIT)
  • snapshot

    • AOT snapshot
    • AppJIT snapshot

区别紧张在于什么机会以及怎样将Dart代码转换为可实行的代码。
1.3 Isolate构成

先来看看dart假造机中isolate的构成：


  • isolate堆是运该isolate中代码分配的全部对象的GC管理的内存存储；
  • vm isolate是一个伪isolate，内里包罗不可变对象，好比null，true，false；
  • isolate堆能引用vm isolate堆中的对象，但vm isolate不能引用isolate堆；
  • isolate相互之间不能相互引用
  • 每个isolate都有一个实行dart代码的Mutator thread，一个处置处罚假造机内部任务(好比GC, JIT等)的helper thread；
isolate拥有内存堆和控制线程，假造机中可以有许多isolate，但相互之间不能直接状态，只能通过dart特有的端口；isolate除了拥有一个mutator控制线程，尚有一些其他辅助线程：

  • 背景JIT编译线程；
  • GC清理线程；
  • GC并发标志线程；
线程和isolate的关系是什么呢？

  • 同一个线程在同一时间只能进入一个isolate，当必要进入另一个isolate则必须先退出当前的isolate；
  • 一次只能有一个Mutator线程关联对应的isolate，Mutator线程是实行Dart代码并利用假造机的公共的C语言API的线程
1.4 ThreadPool构成

假造机接纳线程池的方式来管理线程，界说在runtime/vm/thread_pool.h
ThreadPool的焦点成员变量：

  • all_workers_：记录全部的workers；
  • idle_workers：_记录全部空闲的workers;
  • count_started_：记录该线程池的汗青累计启动workers个数;
  • count_stopped_：记录该线程池的汗青累计关闭workers个数；
  • count_running_：记录该线程池当前正在运行的worker个数；
  • count_idle_：记录该线程池当前处于空闲的worker个数，也就是idle_workers的长度；
ThreadPool焦点方法：

  • Run(Task*): 实行count_running_加1，并将Task设置到该Worker，

    • 当idle_workers_为空，则创建新的Worker并添加到all_workers_队列头部，count_started_加1；
    • 当idle_workers_不为空，则取走idle_workers_队列头部的Worker，count_idle_减1；

  • Shutdown(): 将all_workers_和idle_workers_队列置为NULL，并将count_running_和count_idle_清零，将关闭的all_workers_个数累加到count_stopped_；
  • SetIdleLocked(Worker*)：将该Worker添加到idle_workers_队列头部，count_idle_加1， count_running_减1;
  • ReleaseIdleWorker(Worker*)：从all_workers_和idle_workers_队列中移除该Worker，count_idle_减1，count_stopped_加1；
对应关系图：
count_started_count_stopped_count_running_count_idle_Run()+1(无空闲worker)+1-1(有空闲worker)Shutdown()+all_workers_个数清零清零SetIdleLocked()-1+1ReleaseIdleWorker()+1-1可见，count_started_ - count_stopped_ = count_running_ + count_idle_；
二、JIT运行模式

2.1 CFE前端编译器

看看dart是怎样直接明确并实行dart源码
// gityuan.dartmain() => print('Hello Gityuan!');//dart位于flutter/bin/cache/dart-sdk/bin/dart$ dart gityuan.dartHello, World!说明：

  • Dart假造机并不能直接从Dart源码实行，而是实行dill二进制文件，该二进制文件包罗序列化的Kernel AST(抽象语法树)。
  • Dart Kernel是一种从Dart中衍生而来的高级语言，计划之初用于步调分析与转换(transformations)的中间产物，可用于代码天生与后端编译器，该kernel语言有一个内存表现，可以序列化为二进制或文本。
  • 将Dart转换为Kernel AST的是CFE(common front-end）通用前端编译器。
  • 天生的Kernel AST可交由Dart VM、dev_compiler以及dart2js等各种Dart工具直接利用。
2.2 kernel service

有一个辅助类isolate叫作kernel service，其焦点工作就是CFE，将dart转为Kernel二进制，然后VM可直接利用Kernel二进制运行在主isolate内里运行。
2.3 debug运行

将dart代码转换为kernel二进制和实行kernel二进制，这两个过程也可以分离开来，在两个差别的呆板实行，好比host呆板实行编译，移动装备实行kernel文件。
图解：

  • 这个编译过程并不是flutter tools自身完成，而是交给另一个历程frontend_server来实行，它包罗CFE和一些flutter专有的kernel转换器。
  • hot reload：热重载机制正是依靠这一点，frontend_server重用上一次编译中的CFE状态，只重新编译现实更改的部分。
2.4 RawClass内部布局

假造机内部对象的定名约定：利用C++界说的，其名称在头文件raw_object.h中以Raw开头，好比RawClass是形貌Dart类的VM对象，RawField是形貌Dart类中的Dart字段的VM对象。
1）将内核二进制文件加载到VM后，将对其举行分析以创建表现各种步调实体的对象。这里接纳了懒加载模式，一开始只有库和类的根本信息被加载，内核二进制文件中的每一个实体都会生存指向该二进制文件的指针，以便后续可根据必要加载更多信息。
2）仅在以后必要运行时，才完全反序列化有关类的信息。（比方查找类的成员变量，创建类的实例对象等），便会从内核二进制文件中读取类的成员信息。 但功能完备的主体(FunctionNode)在此阶段并不会反序列化，而只是获取其署名。
7.png 到此，已从内核二进制文件加载了充足的信息以供运行时乐成分析和调用的方法。
全部函数的主体都具有占位符code_，而不是现实的可实行代码：它们指向LazyCompileStub，该Stub只是简朴地要求体系Runtime为当前函数天生可实行代码，然后对这些新天生的代码举行尾部调用。
2.5 检察Kernel文件格式

gen_kernel.dart利用CFE将Dart源码编译为kernel binary文件(也就是dill)，可利用dump_kernel.dart能反解kernel binary文件，下令如下所示：
//将hello.dart编译成hello.dill$ cd <FLUTTER_ENGINE_ROOT>$ dart third_party/dart/pkg/vm/bin/gen_kernel.dart          \       --platform out/android_debug/vm_platform_strong.dill \       -o hello.dill                                        \       hello.dart//转储AST的文本表现情势$ dart third_party/dart/pkg/vm/bin/dump_kernel.dart hello.dill hello.kernel.txtgen_kernel.dart文件，必要平台dill文件，这是一个包罗全部焦点库(dart:core, dart:async等)的AST的kernel binary文件。如果Dart SDK已经编译过，可直接利用out/ReleaseX64/vm_platform_strong.dill，否则必要利用compile_platform.dart来天生平台dill文件，如下下令:
//根据给定的库列表，来天生platform和outline文件$ cd <FLUTTER_ENGINE_ROOT>$ dart third_party/dart/pkg/front_end/tool/_fasta/compile_platform.dart \       dart:core                                                        \               third_party/dart/sdk/lib/libraries.json                          \       vm_outline.dill vm_platform.dill vm_outline.dill                 2.6 未优化编译器

初次编译函数时，这是通过未优化编译器来完成的。
未优化的编译器分两步天生呆板代码：

  • AST -> CFG: 对函数主体的序列化AST举行遍历，以天生函数主体的控制流程图(CFG)，CFG是由添补中间语言（IL）指令的根本块构成。此阶段利用的IL指令雷同于基于堆栈的假造机的指令：它们从堆栈中获取利用数，实行利用，然后将效果压入同一堆栈
  • IL -> 呆板指令：利用一对多的IL指令，将天生的CFG直接编译为呆板代码：每个IL指令扩展为多条呆板指令。
在此阶段没有实行优化，未优化编译器的紧张目的是快速天生可实行代码。
2.7 内联缓存

未优化编译过程，编译器不会实行静态分析任何未在Kernel二进制文件中分析的调用，因此（MethodInvocation或PropertyGet AST节点）的调用被编译为完全动态的。假造机当前不利用任何情势的基于假造表(virtual table)或接口表(interface table)的调理，而是利用内联缓存实现动态调用。
假造机的内联缓存的焦颔首脑是缓存方法分析后的站点效果信息，对于内联缓存最初是为了办理函数的当地代码：

  • 站点调用的特定缓存(RawICData对象)将担当者的类映射到方法，缓存中记录着一些辅助信息，好比方法和根本块的调用频次计数器，该计数器记录着被跟踪类的调用频次；
  • 共享的查找存根，用于实现方法调用的快速路径。该存根在给定的高速缓存中举行搜索，以检察其是否包罗与吸收者的种别匹配的条目。 如果找到该条目，则存根将增长频率计数器和尾部调用缓存的方法。否则，存根将调用体系Runtime来分析方法实现的逻辑，如果方法分析乐成，则将更新缓存，而且随后的调用无需进入体系Runtime。
2.8 编译优化

未优化编译器产生的代码实行比力慢，必要自顺应优化，通过profile配置文件来驱动优化计谋。内联优化，当与某个功能关联的实行计数器到达某个阈值时，该功能将提交给背景优化编译器举行优化。
优化编译的方式与未优化编译的方式雷同：通过序列化内核AST来构建未优化的IL。但是，优化编译器不是直接将IL编译为呆板码，而是将未优化的IL转换为基于静态单分配（SSA）情势的优化的IL。
对基于SSA的IL通过基于网络到的范例反馈，内联，范围分析，范例传播，表现选择，存储到加载，加载到加载转发，全局值编号，分配吸收等一系列经典和Dart特定的优化来举行专业化推测。末了，利用线性扫描寄存器分配器和一个简朴的一对多的IL指令。优化编译完成后，背景编译器会哀求mutator线程输入安全点，并将优化的代码附加到该函数。下次调用该函数时，它将利用优化的代码。
别的，有些函数包罗很长的运行循环，因此在函数仍在运行时将实行从未优化的代码切换到优化的代码是故意义的，此过程之以是称为“堆栈更换”（OSR）。
VM还具有可用于控制JIT并使其转储IL以及用于JIT正在编译的功能的呆板代码的标志
$ dart --print-flow-graph-optimized         \       --disassemble-optimized              \       --print-flow-graph-filter=myFunc     \       --no-background-compilation          \       hel.dart2.9 反优化

优化是基于统计的，大概出现违反优化的情况
void printAnimal(obj) {  print('Animal {');  print('  ${obj.toString()}');  print('}');}// 大量调用的情况下，会推测printAnimal假设总是Cat的情况下来优化代码for (var i = 0; i < 50000; i++)  printAnimal(Cat());// 此处出现的是Dog，优化版本失效，则触发反优化printAnimal(Dog());每当只要优化版本遇到无法办理的情况，它就会将实行转移到未优化功能的匹配点，然后继续实行，这个规复过程称为去优化：未优化的功能版本不做任何假设，可以处置处罚全部大概的输入。
假造机通常会在实行一次反优化后，放弃该功能的优化版本，然后在以后利用优化的范例反馈再次对其举行重新优化。假造机掩护编译器举行推测性假设的方式有两种：

  • 内联查抄（比方CheckSmi，CheckClass IL指令），以验证假设是否在编译器做出此假设的利用场所建立。比方，将动态调用转换为直接调用时，编译器会在直接调用之前添加这些查抄。 在此类查抄中发生的取消优化称为“火急优化”，由于它在到达查抄时就急于发生。
  • 运行时在更改优化代码所依靠的内容时，将会抛弃优化代码。比方，优化编译器大概会发现某些类从未扩展过，而且在范例传播过程中利用了此信息。 但是，随后的动态代码加载或类终极确定大概会引入C的子类，导致假设无效。此时，运行时必要查找并抛弃全部在C没有子类的假设下编译的优化代码。 运行时大概会在实行堆栈上找到一些如今无效的优化代码，在这种情况下，受影响的帧将被标志为不优化，而且当实行返回时将举行不优化。 这种取消优化称为延长取消优化，由于它会延长到控制权返回到优化代码为止。
三、Snapshots运行模式

3.1 通过Snapshots运行

1）假造机有本领将isolate的堆（驻留在堆上的对象图）序列化成二进制的快照，启动假造机isolate的时间可以从快照中重新创建雷同的状态。
12.png Snapshot的格式是低级的，而且针对快速启动举行了优化，本质上是要创建的对象列表以及怎样将它们毗连在一起的说明。那是快照背后的原始头脑：取代分析Dart源码并渐渐创建假造机内部的数据布局，这样假造机通过快照中的全部须要数据布局来快速启动isolate。
2）最初，快照不包罗呆板代码，但是厥后在开辟AOT编译器时添加了此功能。开辟AOT编译器和带代码快照的动机是为了答应假造机在由于平台级别限定而无法举行JIT的平台上利用。
带代码的快照的工作方式险些与平常快照雷同，只是有一点点差别：它们包罗一个代码部分，该部分与快照的别的部分差别，不必要反序列化。该代码节的放置方式使其可以在映射到内存后直接成为堆的一部分
3.2 通过AppJIT Snapshots运行

引入AppJIT快照可镌汰大型Dart应用步调（如dartanalyzer或dart2js）的JIT预热时间。当这些工具用于小型项目时，它们耗费的现及时间与VM耗费的JIT编译这些应用步调的时间一样多。
AppJIT快照可以办理此标题：可以利用一些模拟练习数据在VM上运行应用步调，然后将全部天生的代码和VM内部数据布局序列化为AppJIT快照。然后可以分发此快照，而不是以源（或内核二进制）情势分发应用步调。如果出现实际数据上的实行配置文件与培训期间观察到的实行配置文件不匹配，快照开始的VM仍可以接纳JIT模式实行。
3.3 通过AppAOT Snapshots运行

AOT快照最初是为无法举行JIT编译的平台引入的，对于无法举行JIT意味着：

  • AOT快照必须包罗应用步调实行期间大概调用的每个功能的可实行代码;
  • 可实行代码不得依靠于实行期间大概违反的任何推测性假设
为了满足这些要求，AOT编译过程会举行全局静态分析（范例流分析, TFA），以确定从已知入口点会集可访问应用步调的哪些部分，分配了哪些类的实例以及范例如安在步调中活动。 全部这些分析都是守旧的：这意味着它们会在精确性方面堕落，与可以在性能方面堕落的JIT形成光显对比，由于它始终可以取消优化为未优化的代码以实现精确的行为。
然后，全部大概到达的功能都将编译为当地代码，而无需举行任何推测性优化。但是，范例流信息仍用于专门化代码（比方，取消假造化调用），编译完全部函数后，即可获取堆的快照。
终极的快照snapshot可以运行在预编译Runtime，该Runtime是Dart VM的特殊变体，此中不包罗诸如JIT和动态代码加载工具之类的组件。
AOT编译工具没有包罗进Dart SDK。
//必要构建正常的dart可实行文件和运行AOT代码的runtime$ tool/build.py -m release -a x64 runtime dart_precompiled_runtime// 利用AOT编译器来编译APP$ pkg/vm/tool/precompiler2 hello.dart hello.aot//实行AOT快照$ out/ReleaseX64/dart_precompiled_runtime hello.aotHello, World!3.3.1 Switchable Calls

1）纵然举行了全局和局部分析，AOT编译的代码仍大概包罗无法静态的去假造化的调用站点。为了赔偿此AOT编译代码和运行时，接纳JIT中利用的内联缓存技能的扩展。此扩展版本称为可切换召唤 （Switchable Calls）。
JIT部分已经形貌过，与调用站点关联的每个内联缓存均由两部分构成：一个缓存对象（由RawICData实例表现）和一个要调用的本机代码块（比方InlineCacheStub）。在JIT模式下，运行时只会更新缓存本身。但在AOT运行时中，可以根据内联缓存的状态选择同时更换缓存和要调用的本机代码。
最初，全部动态召唤均以未链接状态开始。初次调用此类召唤站点时，将调用UnlinkedCallStub，它只是调用运行时资助步调DRT_UnlinkedCall来链接此召唤站点。
2）如果大概，DRT_UnlinkedCall实行将召唤站点转换为单态状态。在这种状态下，召唤站点变成直接召唤，该召唤通过特殊的单态入口点进入方法，该入口点验证吸收方是否具有预期的类。
在上面的示例中，假设第一次实行obj.method（）时，obj是C的实例，而obj.method则分析为C.method。
下次实行雷同的调用站点时，它将直接调用C.method，从而绕过任何范例的方法查找过程。但是，它将通过特殊的入口点(已验证obj仍然是C的实例)进入C.method。如果不是这种情况，将调用DRT_MonomorphicMiss并将实行选择下一个调用站点状态。
3）C.method大概仍然是调用的有效目的，比方obj是C的扩展类但不覆盖C.method的D类的实例。在这种情况下，查抄召唤站点是否可以转换为由SingleTargetCallStub实现的单个目的状态（见RawSingleTargetCache）。
17.png 此存根基于以下毕竟：对于AOT编译，大多数类都利用继续条理布局的深度优先遍向来分配整数ID。如果C是具有D0，…，Dn子类的基类，而且没有一个覆盖C.method，则C.:cid <= classId（obj）<= max（D0.:cid，…，Dn .:cid）表现obj.method分析为C.method。在这种情况下，我们可以将类ID范围查抄（单个目的状态）用于C的全部子类，而不是与单个类（单态）举行比力
否则，召唤站点将切换为利用线性搜索内联缓存，雷同于在JIT模式下利用的缓存。
末了，如果线性数组中的查抄数量高出阈值，则召唤站点将切换为利用雷同字典的布局
四、附录

4.1 源码说明

整个过程相干的焦点源码，简要说明：

  • runtime/vm/isolate.h： isolate对象
  • runtime/vm/thread.h：与毗连到isolate对象的线程关联的状态
  • runtime/vm/heap/heap.h： isolate的堆
  • raw_object.h： 假造机内部对象
  • ast.dart：界说形貌内核AST的类
  • kernel_loader.cc：此中的LoadEntireProgram()方法用于将内核AST反序列化为相应假造机对象的入口点
  • kernel_service.dart：实现了Kernel Service isolate
  • kernel_isolate.cc：将Dart实现粘合到VM的别的部分
  • pkg/front_end：用于分析Dart源码和构建内核AST
  • pkg/vm: 托管了大多数基于内核的VM特定功能，比方各种内核到内核的转换；由于汗青缘故起因，某些转换还位于pkg/kernel;
  • runtime/vm/compiler: 编译器源码
  • runtime/vm/compiler/jit/compiler.cc：编译管道入口点
  • runtime/vm/compiler/backend/il.h： IL的界说
  • runtime/vm/compiler/frontend/kernel_binary_flowgraph.cc： 此中的BuildGraph(), 内核到IL的翻译开始，处置处罚各种人工功能的IL的构建
  • runtime/vm/stub_code_x64.cc：此中StubCode::GenerateNArgsCheckInlineCacheStub()，为内联缓存存根天生呆板代码
  • runtime/vm/runtime_entry.cc：此中InlineCacheMissHandler()处置处罚IC没有掷中的情况
  • runtime/vm/compiler/compiler_pass.cc: 界说优化编译器的遍历及其次序
  • runtime/vm/compiler/jit/jit_call_specializer.h：举行大多数基于范例反馈的专业化
  • runtime/vm/deopt_instructions.cc： 反优化过程
  • runtime/vm/clustered_snapshot.cc：处置处罚快照的序列化和反序列化。API函数家族Dart_CreateXyzSnapshot[AsAssembly]负责写出堆的快照，好比 Dart_CreateAppJITSnapshotAsBlobs 和Dart_CreateAppAOTSnapshotAsAssembly。
  • runtime/vm/dart_api_impl.cc： 此中Dart_CreateIsolate可以选择获取快照数据以开始isolate。
  • pkg/vm/lib/transformations/type_flow/transformer.dart: TFA（范例流分析）以及基于TFA效果转换的切入点
  • runtime/vm/compiler/aot/precompiler.cc：此中Precompiler:oCompileAll()是整个AOT编译的切入点
本文转自 http://gityuan.com/2019/10/05/dart_vm/，如有侵权，请接洽删除。

举报

您需要登录后才可以回帖 登录 | 立即注册
程序员
优秀作者 助人为乐 人气作者
文章
412
问答
412
粉丝
0

所属分类: 问答交流

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-11-22 16:50, Processed in 0.200159 second(s), 35 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表