作者丨赵钰莹
闭源时被质疑是否真的存在这样一个编译器，开源后又被喷技术含量不可，方舟编译器怎样就这么难？本文，鸿蒙开源主管及方舟编译器架构师初次完好揭露共享了方舟编译器的根底架构。
1
方舟编译器怎样这么难？
自 8 月 31 日正式开源，方舟编译器的谈论热度到达高潮，知乎论题《怎样看待方舟编译器于 2019 年 8 月 31 日开源？》累计被阅读了五百多万次，网友合计宣布了八百多条谈论。由于本次开源放出的代码较少，不少网友都抛出了疑问，比方运转时方面的方案，开源的原因，开发出来的使用是否只能在华为手机上运转以及未来方案怎样做生态等，十年磨出的方舟编译器，一朝开源怎样就面临这么困难的地步呢？
事实上，比较于过往十年的研制进程，现在的境况或许还算不上最困难的。
2009 年，华为榜首个编译团队建立，起先是为了无线基站范畴的 DSP 功用问题。
2014 年，Open64 的开山祖师 Fred Chow 参加，这对华为后来的编译器开展，包含现在的方舟编译器都产生了重要影响。
2017 年，华为手机的销量十分之高，又开端呈现许多新的问题。其时，整个混合履行形式里，解说履行的占比十分高，而履行功用比较低，JIT 在后台生成 JIT 代码的进程又会耗费许多 CPU 资源，编一个函数需求的时刻也很长。此外，由于优化不完善，虚拟机的中止时刻十分长，特别内存不足时，会导致许多卡顿。
依据上述原因，整个团队谈论出两条可行的处理方案：一是在现有虚拟机的根底上修正；二是重整旗鼓，从头做一套能够履行 Java 的运转环境和编译器。榜首条路相对简略省劲，但只能处理部分问题，华为终究挑选了第二条道路，这就促进了现在方舟编译器的诞生。
在方舟编译器的设计上，Fred Chow 的一篇论文供给了很好的思路：依据一致的 IR 既支撑多种编程言语表明，又支撑后端多芯片代码的指定构成。这就构成了方舟编译器的理论根底。在这个理论根底上，方舟编译器团队依据 MAPLE IR 做了更杂乱的优化和更广义的操控流剖析。
2019 年 4 月份，华为发布方舟编译器（ArkCompiler），一同在 8 月底将其编译结构代码开源，并方案后续完好开源方舟编译器的一切代码。可是，开源后的方舟编译器受到了五湖四海开发者的高度重视，面临现在开源出来的少数代码，很难让人信赖这是一个多言语、跨渠道、高效的编程环境。
所以，整个团队初次揭露了方舟编译器的根底架构和源码剖析。
2
方舟编译器源码剖析
8 月 31 日，华为方舟编译器开源了编译器结构部分源码，包含编译器中心表明（IR，Intermediate Representation）和言语编译完结，一同调配编译器其它二进制组件，完结 Java 程序到 aarch64 汇编指令的编译进程。
在华为的描绘中，开发者可依据开源代码和二进制，编译构建出编译器东西链，测验对 Java 程序进行编译。社区参加者能够经过结构源码学习方舟编译器的编译器中心表明（IR）及根本的中端编译结构，了解方舟编译器的架构思维，并参加诸如对编译器中端优化的奉献。方舟编译器是为支撑多种编程言语、多种芯片渠道的联合编译、运转而设计的一致编程渠道，包含编译器、东西链、运转时等要害部件。
就现在可见的规模，整个方舟编译器的开源部分代码由 C、C++ 的头文件、源码和汇编代码组成，C 言语的头文件占了绝大部分，现在供给的代码一共有七万多行，注释大约有一万多行，还有许多空行，加起来大约有 10 万行代码，而其间的注释十分之少。每个文件的巨细全体也不是很大，单个超过了 2000 多行，大部分在 1000 行以下。
从代码内容来看，首要是与中心代码相关的部分，当然也包含了 Phase、IPA，但实践里边首要是阶段性办理的辅佐代码，真实相关的代码现在还没有呈现。huawei_secure_c 的文件中存放了许多要害代码，比方内存复制等要害函数。依据选取的几个测试用例，现在对 Java 1.6 及以上版别的支撑都没有问题，从 Java 到 IR 的翻译仍是比较顺利，只不过在第三库版别支撑上或许会有问题。
至于上文说到的中心代码，依据 MAPLE 的文档，首要有如下几个特色：
尽或许保存源代码信息；
高层次树状层次化结构；
低层次与指令一一对应；
可扩展——支撑新的言语和操控结构。
方舟根底架构与 IR 中心表明
现在开源的方舟根底架构一部分是关于 Java/Kotlin 的编程言语完结，由于这两类言语强依靠虚拟机，方舟编译器去掉了虚拟机之后，补全了一些功用在里边；另一部分是后续优化和剖析的根底支撑，比方开源了 SSA 的表明。
方舟编译器架构师在近期的共享中表明，Maple IR 设计时根本考虑了三件作业：
1、IR 存在于三种不同的格局中：
Binary，首要用来做分发，或许是真实履行时需求考虑功率问题；
中心言语需求有可读性，由于程序员很关怀代码的履行进程；
存在 In-memory 的进程，也便是安排中心言语在内存的存储。
2、分层设计，Maple 的整个主意来源于 Open64 的开山祖师 Fred Chow，而 Open64 其时的设计是五层结构。方舟编译器总结和学习了 Open64 的经历，构成了一个分层的设计，按需来挑选不同层次。这样能够让高层言语快速回到原代码，大多数编译器都会支撑这一功用，许多的使用场景都可用到。此外，高层的中心表明对完结挨近原言语的优化会比较便利。比方，方舟编译器保存了较高层 Class 类型，这样做 TBAA 和 Devirtual 相对简略。
3、高层结构更挨近原言语。原言语的代码最为精简，方舟编译器期望中心结构也能够愈加精简，比方分发格局更小。一同，期望能够重用编译优化才能，当引进新言语时，能够尽量削减改动。分层之后引进新言语，能够只改高层，高层拓宽后，底层一切优化坚持不变。
在中心言语的部分，方舟编译器架构师表明可分为两部分看待：类型和操作符。
在类型上，Maple 编译器中有一个 Global tab 的表明，一切大局符号都保存在这儿。榜首项便是 type tab，这个的完结便是 MirType 的一个 vector。MirType 的界说根本上就只要这几项，首要要看类型究竟是什么类型。其次，类型里边的 Primitive Type 是什么姿态，比方说是一个 Int 或许更杂乱的结构体。
依据最根底的 MirType，能够扩展出 Structure 结构。之后信息愈加丰厚，比方会有父类的一些 Field，还有 VTab、ITa 等。依据 MirStructType，能够扩展出高层结构，方舟编译器会保存 Class 信息，这部分现在来看对剖析和优化的协助十分大。
在操作符上，方舟编译器支撑 Memory 的操作，也有结构化的操作符。除了支撑传统调用，还支撑许多 Java 特有的调用。
在内存办理上，方舟编译器现在是以 RC 为主，GC 为辅。开发者或许对 GC 比较了解，这儿讲下对 RC 的一些支撑。RC 是一个比较简略了解的作业，多一个引证就加一，少了就减一，思维比较简略。在真实使用中，方舟编译器加一的状况根本就四种：
一个目标引证了另一个目标，进行加一；
栈包含寄存器里的变量要去引证目标，再次加一；
静态或许大局变量多加一个引证的话，也要加一；
函数回来目标，也要加一。
减一的场景也比较简略，比方局部变量 Last Use 后，由于局部变量现已死掉，指向的本来目标要进行减一操作；假如某个变量被从头赋值，本来指向的堆目标也要进行减一操作。
在这种办法下，一个特别简略的函数或许要进行一系列加减操作，每次操作或许都要加锁，根本程序很难跑起来。所以，整个团队又开端从三个视点对此进行优化：
榜首，削减刺进，许多变量间的 Live Range 或许是堆叠的，堆叠后前面加一，后边减一的操作就能够不做了；假如真实没有办法防止刺进，就看怎样削减每一次操作的开支，方舟编译器有一个逃逸剖析，最首要的结果是看变量会不会被多线程拜访。假如变量的值被单线程拜访，就不需求加锁，只需求加一或减一操作，然后确保不被提早开释就能够。
第二，RC 操作是比较费事的作业，方舟编译器现在供给 Annotation 的办法，Annotation 的作用应该是最好的，但对程序员要求较高，假如程序员加的不对，内存或许会呈现走漏。别的，方舟编译器也供给自学习的办法。
第三，方舟编译器以 RC 为主，GC 为辅。假如一些环没有被 RC 开释掉，能够从被 GC 开释掉的环里学到一些规矩，把这些规矩写成一个文件或许放到内存里，辅导下一次运转时的内存开释。
如上图，绿色的部分现已完结，黄色的部分还在开发中，而蓝色的部分还在规划中，华为期望与社区进行共建。
接下来，方舟编译器团队会敞开跨言语全程序优化才能。对 Android 而言，从 Java 到 C 或许从 C 到 Java 的调用，整个次数会十分多，并且每一次调用的开支也比较大。假如能够把这一部分做好，大约能够前进 10% 到 20% 的功用。
别的，整个团队还做了一些安全编译，比方把运转时过错移到编译时做，由于在运转时的状态下，Bug 很难查找，假如在编译时就对问题进行报警，这样对开发者比较友爱。
3
生态是绕不过的难题
现在方舟编译器的代码保管在华为云与码云渠道（gitee.com），恪守的开源协议是我国首个开源协议——木兰宽松许可证，这样做的意图也是为了躲避其他协议潜在的开源危险。在未来走向敞开办理今后，方舟编译器将依照所挂靠组织的形式来保管。开发者可经过代码保管渠道参加社区奉献，包含文档奉献和代码奉献，一同也可在此渠道上反应相关问题和需求。
在生态构建方面，许多开发者都以为这是方舟编译器需求迈过的一道大坎。其实，做生态不一定只要开源这一条途径，苹果没有开源却仍然有大批开发者愿意为其渠道开发使用，鸿蒙 OS 的开源主管表明，华为之所以挑选开源方舟编译器，一是真的期望得到广阔开发者的协助，和许多编译器范畴优异的学者和从业人员一同前进；二是期望取得广阔开发者的信赖。
可是现在，许多开发者都觉得难以参加，由于没有 Runtime，敞开的源代码也十分少。华为方舟编译器架构师表明方舟编译器其实有一个 Runtime，用来完结各种与运转相关的信息，比方 Java 反射、JNI 调用、内存办理、内存收回机制等，但现在只要 6 万行代码，是一个十分轻量级，只供给必备内容的 Runtime。
现在开发者能够先在华为手机上运转 ，一同华为也期望社区能够一同经过开源的办法做一个简略的 Runtime。后续会依照方案赶快敞开一切源代码，由于代码开源需求进行许多整理和整改，时刻上期望各位开发者多些耐性。假如开发者期望参加社区构建，能够考虑以下几个视点：
共建方舟 IR。其完结在方舟 IR 的规范还没有彻底定下来，处在逐步开展的进程中，华为期望和我们一同把规范做得更好。这儿边也有许多应战性的作业，由于不同的高档言语有不同的特征，类型体系、内存办理机制、内存目标模型都或许不同，期望我们能够构成更好的规范，支撑更多言语表达；
多言语前端，现在的编译器只做了 Java，C++ 还在内部开发中，其实还有更多言语，包含 JS，也期望社区中的广阔开发者一起建造；
多芯片后端，华为内部只做了 ARM64 的后端，ARM32 还在规划中，但或许有一些厂家用 X86，开发者能够结合自己的芯片做一些后端开发用到自己的产品中；
对编译算法有爱好的同学，能够在中端和后端做一些编译算法优化，包含数组越界查看消除、锁优化等，这或许对我们都有优点。
4
结束语
方舟编译器的愿景便是构建多言语、跨渠道、高效的编程环境。面向未来，华为做了许多全场景才智化场景的测验，怎样全场景下进行高效编程以及在整个 IR 层面，怎样进行优化等都是极具应战的使命，方舟编译器未来相同期望与硬件更好结合，而这些都需求更多开发者参加其间。
方舟编译器主页：
https://piler.cn
官方主库：
https://code.opensource.huaweicloud.com/HarmonyOS/OpenArkCompiler/home
Gitee 镜像库房：
https://gitee.com/harmonyos/OpenArkCompiler
点个在看少个 bug