Simone华为方舟编译器原理已公布，应当如何看待？
的有关信息介绍如下：
写点不专业的分析，抛砖引玉。
更新一下。我突然想到了一个比较接近的，现成的项目：
.NET Native
将不同语言混合编译，这个知乎上曾有过类似提问：
只要编译到统一的IR，最后输出统一优化的native代码是完全可行的。
比如把Java的bytecode转换到LLVM的IR，把一些特殊的功能转化到函数调用，然后一股脑扔给后端去优化就行了。
当然编译出来的结果依旧需要挂上jvm这个runtime，就像你想要在代码里反射，那就必须存储元数据并留下runtime对这一功能的支持一样。
补充一下，而不是无脑转换扔进去优化就够的，参考
这个回答里讲到的Unladen Swallow项目，过多细节隐藏在runtime里也会大大限制后端优化的空间。
还有个问题就是本地堆和托管堆数据互相访问的问题。比如C里指针跑飞了就跑飞了，其他部分不主动去访问到错误区域就没事。但混合编译后如果在修改托管堆数据时跑飞了，就可能会大大影响托管环境。C++/CLI作为本地和托管的胶水语言，就有现成的设计结构。
这么做的好处其实在于可以消除函数调用，给后端更充分的优化空间，类似于C++的link-time optimization。
2.1讲的其实可以理解为AOT+LTCG，完全可以接受。
至于2.2，其实就是优化GC。
GC的实现与优劣知乎上也有很多讨论：
方舟编译器具体怎么做的？图片上压根没讲……
其实从Dalvik到ART，安卓的GC是有改进的，减少了暂停的时间与GC的次数。比如看这里
而ART GC的并发阶段其实也不需要stop the world的。
如果想不stop the world，那pauseless的GC也是现成就有的（虽然实际上还是会有那么一些pause time），比如
相关的内容其实应该at专业的R大，虽然看他好久没上知乎了。 @RednaxelaFX
除去改进Mark-Sweep/Compact算法的外，也可能是改用了引用计数的GC，毕竟Java语言应该是没有规定用何种GC方式的，而引用计数是符合“即用即释放”的描述的。
不过这还得考虑怎么解决循环引用，以及怎么应对连锁释放的波动等问题……
之前的传闻说开源的是编译器，而runtime不开源，这就好比开源了MSVC但不开源vcrt.dll一样。
不过如果连runtime都不给提供的话，那光这个编译器差不多也是废的了，毕竟没有runtime没法运行，总不能对照着API自己逆向一遍仿个满是bug的runtime吧……
