github:https://github.com/Himself65/OpenArkCompiler
背景:
1.将多语言之间联合优化,比如c/c++、 java包括前端等,然后自己设计一个IR,不同的前端分析完后,然后转为统一的IR,这个是编译原理上常做的事;
https://github.com/Himself65/OpenArkCompiler/blob/master/doc/MapleIRDesign.md
2.由于目前形成了一个以移动端手机为中心的智能中心,但是不能满足目前Android7.0以后以上的AOT+JIT的联合编译解释的模式,说到底感觉无论是启动什么的还是慢。
方舟编译器把所有的Android系统上的框架全部编译为native层。减少java与C++ 之间的JNI调用开销。然后这个事交给开发者在编译的时候处理。
3.打造成自己的一个生态环,你要想用这个方舟编译器带来好的用户体验就得用我华为自己的runtime;要不然自己开发代价高。
4.同时对于jdk中内存回收机制,最常见的RC机制,需要进一步的优化;
一、方舟编译器的编译:
https://gitee.com/harmonyos/OpenArkCompiler/blob/master/doc/Development_Preparation.md
二、使用FZ编译HelloWorld:
参考https://zhuanlan.zhihu.com/p/81340230,感谢从Android源码中找到并提供java-core库。建议编译的时候编译成debug版本的。这样可以对照详细日志有利于后面的编译理解。
调用jbc2mpl处理.jar文件为xx.maple文件,即方舟编译器的中间文件;
三、过程分析:
可以看到#UBSTIDX对应的是上面java字节码反汇编以后的可读文件形式:
3.接着我们继续看一下HelloWorld.VatbleImpl.mpl文件
MCCIncRef:类似于dvmAddToReferenceTable,加入引用表
MCCDecRef:类似于dvmRemoveFromReferenceTable,从引用表中移除
以及MPL_CLEANUP_LOCALREFVARS,清除引用表。
同样的去看HelloWorld.VtableImpl.s文件,可以清晰的看到对于RC机制管理的相关函数的调用。
四、LLVM对java文件进行编译处理为IR:
同样的文件使用LLVM对java文件进行处理为LLVM-IR可以看到:与上面方舟编译器处理的结果有异曲同工之妙。