如何看待方舟编译器于 4 月 9 日新增加的开源内容？ 第1页

观望这个东西几个月了，预期上我是想拿它和 GraalVM 进行对标的，但是……就目前这个发展状况来看，方舟离我的预期还是差距很大。写这篇文章的时候我注意到19年8月华为收购了 Excelsior，也就是 Excelsior JET 的开发公司，所以我对未来方舟能发展起来还是报以期望，但就目前的状况来看，我觉得我是被愚弄了。

单纯技术上来说，方舟编译器并没有什么让人眼前一亮的突破。方舟的低暂停是以 ARC 配合其他兜底的 Tracing GC 算法，以吞吐量换低暂停，类似的策略在 CPyhon 上已经被大规模使用了，对于客户端来说不失为一种不错的选择，不过这种方案在现代 JVM 上有着相当强劲的对手，就是以 Zing C4 GC 为代表的一系列低暂停并发 GC，包括 JDK 11 开始支持的 zgc，以及 Redhat 开发并在 JDK 12 之后被大部分 OpenJDK 发行版内置的 Shenandoah GC。以 zgc 为例，它能够在 8MB ~ 12TB堆内存^[1]工作，并确保最大暂停时间低于 10ms，正常工作情况下暂停时间几乎都低于 1ms，作为 Tracing GC 相比 ARC 来说吞吐量上更有优势，配置合理的情况下也不会因为兜底 GC 发生过长暂停 。在 Hotspot 已经有较成熟实现的情况下，未来安卓加入类似 GC 算法的支持的可能性也不小，ARC+Tracing GC 的策略的优势就会大幅度减小。

方舟主打的把 Java 编译成机器码，也就是 AOT 编译，这也是从 GCJ^[2] 和 Excelsior JET^[3] 到 GraalVM 一直在做的事情。AOT 和 JIT 各有优劣，不过 AOT 的优势：启动速度快、内存占用低，对于客户端应用来说较为重要，但 AOT 也并非什么新鲜玩意，Excelsior JET 和 GraalVM 把这一点都做的比较成熟了，GraalVM 的 aot 编译甚至还能够和 Hotspot 协同工作，JDK 9 以上附带的 jaotc 工具就是基于 GraalVM 的技术实现的。

至于方舟所说的多语言协同，想法很不错，但是官网上

当前方舟编译器支持Java/Kotlin程序字节码的前端输入，其它编程语言的支持（如 C/C++/JS 等）还在规划中

hmmm……实现基础的平台虽然也不是什么简单的事，但是后期实现支持各种语言更是一个大问题。而且，隔壁 GraalVM 不仅也以多语言协同作为核心卖点之一，它用于协同的 Polyglot 机制也已经相对完善，在其上的 Sulong（LLVM 的实现，可以用来运行 C、C++、Rust 等极多语言）也较成熟；Graal.js（JavaScript 的实现）已经与 ECMAScript 2019 规范兼容，性能整体虽然逊于 V8，但预热后的峰值性能也已经有和 V8 相比的能力；GraalPython 处于早期阶段，但也能兼容运行不少 Python 包了，性能也明显强过最常用的 CPython。除了这些，GraalVM 目前还有 Ruby、WASM 和正则的实现，并且都在积极维护更新，致力于和主流实现兼容。方舟设计上没有优势，成熟度还停留在“还在规划中”，差距不言而喻。

当然，技术归技术，目前在安卓上也确实没有成熟的 Java 低暂停+ AOT 的方案，如果方舟能实现的话在成熟度上领先也是很不错的，我报以期望的也是这一点。然而我从官宣一直观望到现在，方舟编译器……至少在我能看见的部分，还是停留在demo的程度上，反而 GraalVM 在 AArch64 平台上日渐成熟，可以在 Android 和 iOS 上工作（Gluon Client Samples），哪怕安卓方面的成熟度，目前方舟公开部分也没什么优势。华为能收购 Excelsior，我相信方舟未来能够积极发展，但是在与其目标和功能相近，成熟度远高于它，并且被 Oracle 和开源社区一起支持的 GraalVM 面前，我认为方舟不说能赶上差距，就算想不被拉开更远都是一件难事。

参考

1. ^ JDK 13 以下是 8MB~4 TB
2. ^ 已废弃
3. ^ 已废弃，开发商被华为收购