如何看待方舟编译器开源maple engine，编译的程序终于可以运行起来了? 第1页

• 方舟编译器是一个体系，看文档的图也能明白，对标的是LLVM和GraalVM，但也不完全功能重叠；
• 至少在2019年6月（发布会的一两个月以后），手机上已经在跑着方舟了（贴吧的搞机大佬通过root后的手机获得了华为手机的系统固件）；第三方应用目前在不断适配中，已经越来越多了；
• 这次开源的Maple Engine，是Maple IR的执行引擎，不是以机器码的方式执行的，目前只有一个Threaded Code Interpreter，但是可以通过ffi和JNI实现native调用。LLVM曾经也设想过bitcode的分发方式，加上LLVM的JIT支持，也可以很高效，不过后来重点偏移了；
• 安卓上的方舟是可以静态编译的，但是目前方舟的x86 target还不完善，而安卓手机和华为的鲲鹏都是AArch64架构，安卓和PC上（Windows、Linux等）的执行环境（这里只说java的）也是不同的。这次开源的Maple Engine通过一些比较tricky的方式让java在Maple IR的基础上跑了起来，并且可以看出，很多runtime组件是直接复用手机里的方舟runtime的（可能有细微的修改）。侧面说明目前的runtime基础设施已经完成，但需要一定的适配以面对不同的执行环境；
• 很多牛x的编译器、语言框架已经消失在了历史的长河中，方舟编译器的未来也并不确定，华为可以说是国内投入基础软件研究最多的了，同时也是LLVM、GCC等的sponsor和contributor，我个人愿意持续关注它的进展。

懂的自然懂。

昨天第一时间下载下来，大致已经看完了。其实开源出来的代码并不是很多，很多组件还是以binary的形式提供的，而且只有X86的，不过毕竟AArch64的服务器一般人也没有，目前能搞到的也就是华为的鲲鹏（TaiShan服务器）。

推荐24G内存主要是为了编译OpenJDK获得Java core的.so。不过这能吓到我？摸鱼在我工作用的512G内存服务器试了一下，可能因为是CentOS的原因，构建脚本跑起来有问题，修改完构建脚本之后，编译链接又出了问题（这个估计确实就是ABI不兼容了）。最终还是摸鱼用ubuntu 18.04的docker镜像搞定了。

其实没必要重新编译OpenJDK的啊，只是在Object.java中增加了两个保留字段，没必要整个都编译一遍啊！

1. 下载Object.java，然后修改；
2. 用javac编译Object.java获得Object.class；
3. 因为已经安装了openjdk8，所以从jre/lib目录下面拷贝需要的jar过来就好了；
4. 解压rt.jar，替换java/lang/Object.class为我们重新编译的Object.class，再重新打包为jar包；
5. 构建libcore.so，执行后续操作。

首先先大致说明一下情况：

1. 这次开源的engine，其实是一个maple bytecode interpreter，所以binary size、performance等方面肯定是不能直接和JVM或者native binary比较的，也没有意义；
2. 流程大致是：
1. 先将Java core jars用jbc2mpl生成Maple IR；耗时间、内存的地方之一；
2. 然后用一个脚本处理生成的IR（进行了一些patch，目前还不明白具体的操作是做啥的）；耗时间、内存的地方之二；
3. patch之后，通过maple程序进行中端优化和转换，生成.s汇编。这个汇编里面包含的应该是Maple IR的bytecode，并不是x86指令，Maple IR是作为纯字节数据存储的（一堆.byte）。这个可能就是所谓的Maple Linker所接受的格式。耗时间、内存的地方之三；
4. 然后用gcc将MRT（以及关键的两个.cpp，mrt_primitive_class.cpp和mrt_module_init.cpp）、compiler runtime和.s汇编为libcore.so，并且通过mapleld.so.lds脚本定制了一下链接后section的对应关系（和在文件mrt_module_init.cpp中定义的extern变量对应了起来）。至此获得了Java运行时的动态库libcore.so，这个动态库并不算是native的，可以说就是把Maple IR打包为了ELF文件；
5. 之后用java2asm.sh、asm2so.sh将java源码编译为.so的过程，和编译libcore.so是一样的：生成.mpl，打patch，转换、优化、生成Maple Linker格式的. s，然后用gcc汇编、链接，生成.so（同样应该是ELF格式的Maple IR）；
6. run-app.sh执行最终生成的.so文件，其实是执行了一个叫mplsh（maple shell吗？）的程序，负责了各种依赖库的加载、执行环境准备、main函数的进入等。Maple IR在ELF文件中的位置，应该是通过mrt_module_init.cpp定义的extern变量以及导出函数定位的。从这些section可以获取class metadata、方法实现等信息；
7. 虽然整体其实应该（I'm not for sure）是在解释执行从Java Bytecode翻译过来的Maple IR，没有JVM的启动了，但是，为了执行能够成功，还是依赖于libjvm，因为其中的JNI调用，其实还是要调用libjvm里提供的，不然即使是一个println也跑不通；
3. 目前其实还是有挺多bug的，并不是所有的cases都能跑起来。

（以上基于构建、执行的脚本，以及一些个人猜测）

总结：整体的结构其实文档里的图描述得非常清晰明了，就是对那张图的完美实现（虽然感觉有一些tricky，但我个人愿意称之为perfect）。这是一个Maple IR的解释器实现，你可以理解为是LLVM的lli。算是为方舟编译器的工具链中增加了一个有趣、令人遐想的部分，以后可以用来执行python、js啥的也可以吧（链接上libpython或者libv8，但只是使用其中native部分的调用，而不是interpreter）。

这算是一个PoC（概念验证），和手机里用的方舟是不一样的，我也不苛求什么/笑哭/笑哭/笑哭。