作者 | Ben Evans
译者 | 张卫滨
策划 | 丁晓昀
OpenJDK提出了一个新的项目 ，代号为 Galahad，以便于将 GraalVM 社区版代码库中的一部分功能合并到 OpenJDK 中。
这是一项长期努力的最新进展，也就是在程序执行之前将 Java 应用编译为机器码的能力。乍看上去，这似乎有些奇怪，毕竟，一位新的 Java 开发人员最先了解到的一点就是“Java 不会编译成机器码，而是编译成 JVM 字节码”。
这句简单的格言有着深远的影响，其中最基础的就是，Java 平台依赖一个强大的运行时来执行，也就是 JVM。这个运行时实现了动态运行技术，比如类加载和反射，这些技术在提前编译（ahead-of-time，AOT）语言中并没有真正类似的特性。实际上，这是 Java 强大功能的起点，也是 Java 能够在 25 年左右的时间内一直位于软件舞台中央的重要原因。
尽管如此，人们始终对 Java 程序直接编译为机器代码并在没有 JVM 情况下独立运行的可能性抱有强烈的兴趣。这种期望有多种原因，比如为了减少 Java 程序达到峰值性能的时间，减少 Java 应用的内存需求，甚至只是为了避免将资源用到应用本身并不需要的运行时子系统中。
迄今为止，已经有多个项目尝试实现这种可能性。最近的一个，也可以说是到目前为止最成功的一个，就是 GraalVM 项目。这个项目并不是来自 OpenJDK，而是来源于 Oracle Labs 的一个研究性项目。它的第一个生产级别的版本 GraalVM 19.0 是在 2019 年 5 月份发布的。
从那时起，它一直作为一个独立项目来运作，具有与 OpenJDK 不同的发布周期，并且与 OpenJDK 的互动有限。在为数不多的 Java 增强提案（Java Enhancement Proposal，JEP）中，有两个是与 GraalVM 相关的：
- JEP 243：Java 级别的 JVM 编译器接口（Java-Level JVM Compiler Interface）
- JEP 295：提前编译（Ahead-of-Time Compilation）
这两个 JEP 都是在 Java 9 中出现的，它们一起将 Graal 编译器引入到了 OpenJDK 代码库中。
Graal 编译器是 GraalVM 的主要组件之一，它是一个操作 Java 字节码并生成机器码的编译器，可以在 JIT 或 AOT 模式下运行。在 JIT 模式下，它可以用来代替 C2（有时被称为“服务器编译器”）。值得注意的是，Graal 本身是用 Java 编写的，不像其他用于 JVM 的 JIT 编译器都是用 C 编写的。
在 Java 10 中，Graal 凭借 JEP 317 作为实验性的、基于 Java 的 JIT 编译器添加了进来。但是，在 Java 17（2021 年 9 月发布）中，AOT 和 JIT 编译器的实验性形式都被移除掉了。尽管如此，实验性的 Java 级 JVM 编译器接口（JVMCI）被保留了下来，因此，我们仍然可以使用外部构建的 Graal 编译器版本进行 JIT 编译。
如果最新的公告能够如期交付，将标志着 Graal 重新回到了 OpenJDK 代码库中。然而，更重要的也许是 GraalVM 流程和项目的变化。Galahad 将作为 OpenJDK 的一个子项目来运作，并维护单独的仓库，定期与主线仓库进行 rebase 操作。当功能就绪时，它们将被迁移到主线仓库。这与长期运行的成功项目（如 Loom 和 Lambda）所使用的模式是相同的。
Galahad 将 JDK 20 作为初始基线。这基本上就是代码和技术的起点而已，因为 JDK 20 已经进入了 Rampdown 阶段，所以至少在 JDK 21（预计 2023 年 9 月）之前，不可能有任何重新引入的 Graal 代码作为 Java 的一部分交付。目前，Galahad 将专注于贡献最新版本的 GraalVM JIT 编译器，并将其作为 C2 的替代方案进行集成。稍后，一些必要的 AOT 编译技术将被加入进来，以便于 Graal JIT 编译器在 JVM 启动时立即可用。
这是必要的，因为 Graal 本身就是用 Java 编写的，它可能会遭受我们广泛面临的启动缓慢问题：
- Hotspot 基于 C1 编译器和 Graal（如果可用的话）启动；
- Graal 会在 Java 解释器线程上执行，最初速度会很慢，直到它自己得到了编译。
将 Graal 编译器预编译为原生代码有可能会解决这个问题，有一个旧的 JEP 草案 提出了这种方式，但是目前还不知道它是否会被恢复或重新开始寻找新的方案。
需要注意的是，并不是所有的 GraalVM 代码库都会被提交至 OpenJDK，它只包含核心的 JIT 和 AOT 组件，以及原生镜像工具。甲骨文公司在 GralVM 企业版中的专有特性预计不会捐献给该项目。
Galahad 在项目之初就有一个值得关注的提交者名单，他们不仅来自甲骨文的 OpenJDK 和 GraalVM 团队，还有来自更广泛的 OpenJDK 社区的许多贡献者，包括来自 Red Hat 的 Andrew Dinn 和 Dan Heidinga 以及来自 AWS 的 Roman Kennke。Galahad 和 Leyden 项目（另一个研究 AOT 编译和相关技术的 OpenJDK 项目）之间的确切关系尚不清楚，但 Galahad 的一些贡献者也一直活跃在 Leyden 中。
尽管该项目仍处于早期阶段，但许多有影响力的社区成员对 Galahad 表示欢迎，认为它代表了在保持 Java 处于云原生技术栈的领先地位方面，这是一项重要的进展。
原文链接：
OpenJDK Proposes Project Galahad to Merge GraalVM Native Compilation(https://www.infoq.com/news/2022/12/openjdk-galahad-Dec22/)
相关阅读：
Oracle 将 GraalVM 贡献给 OpenJDK，以解决“采用障碍”(https://www.infoq.cn/article/NxuqQb5Xt6VaPu1mEWIG )
标准化原生 Java：拉近 GraalVM 和 OpenJDK 的距离](https://www.infoq.cn/article/SB6zvEdRIJuP2N4xkGak )
声明：本文为 InfoQ 翻译，未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐
清华应届硕士炮轰字节：恶意低薪，硕士白读还倒贴；马云不再实际控制蚂蚁；开源 ROM 魔趣创始人宣布删库跑路｜Q 资讯
百万用户逃离Twitter转向这个小众社交平台，互联网中心化终将走向大溃败？
芯片的后半场，“提速”依旧是第一要务，那除此之外呢？
日本软件业烂透了！谷歌日本高管揭秘回顾那些被遗忘的错误
