微软对OpenJDK做出第一个重大的贡献：在ARM上成功移植OpenJDK for Windows 10

随着ARM处理器在其笔记本电脑和云环境可用之后，微软对ARM处理器的热情更进一步。今年夏天，微软对OpenJDK做出了第一个重大贡献：将OpenJDK迁移至Windows 10 ARM（AArch64）的第一阶段。具体来讲，这意味着我们可以在Windows 10的ARM机器上开发和运行Java代码了。

移植工作是Monica Beckwith加入微软之后所领导的第一个项目。InfoQ联系到了她以及面向Java工程组SWE的主要负责人Martijn Verburg，和他们探讨了这对于Java社区意味着什么。我们是否已经可以切换至Surface Pro作为Java开发机器？我们能够从Azure上的ARM处理器中获取性能收益吗？

InfoQ：感谢你们花费时间来回答我们读者的问题。你们能首先简要介绍一下自己并描述一下在微软的角色和日常工作吗？

Martijn Verburg：大家好，我是Martijn Verburg，在微软我是面向Java工程组SWE的主要负责人。在此之前，人们知道我可能是因为我曾经担任jClarity（去年微软收购了它）的CEO的角色，或者作为AdoptOpenJDK和Jakarta EE指导委员会的成员之一。有一些谣言说我是“恶魔的开发人员”，但我是一位经理，所以这并不是真的。 Monica Beckwith：大家好，我是Monica，我是Arm64上Windows OpenJDK项目的领导者。我的日常工作包括改善OpenJDK的Hotspot VM。自从2006年Sun开始OpenJDK项目以来，我就一直在使用OpenJDK。我主要从事性能方面的工作，包括优化应用程序、JVM并探索GC算法，确保生成的代码与底层的硬件相匹配。在进入微软之前，我在Arm担任托管运行时环境的性能架构师。

InfoQ：这是微软对 OpenJDK 的第一个重大贡献。为什么会从 ARM 开始？最难解决的问题是什么？进展如何？你们做了哪些与众不同的事情呢？

Verburg：关于 ARM，微软在两个方面很感兴趣。我们的 Surface X Pro 产品线运行在 ARM 的硬件上，另外，我们在 2017 宣布计划在云基础设施上提供对 ARM 的实验性支持。 至于这种迁移所面临的挑战，从我的角度来讲，看到团队在如下这些方面所花费的时间和精力是非常有趣的：

• OpenJDK 社区将补丁切分为多个易于理解的块（在我们的场景中也就是四个补丁集）
• 测试（功能性、性能以及两者的回归测试）

当我们添加新的移植支持时，会添加全新的代码，然后（我个人认为）更复杂的事情是对共享代码的修改。对我们来说，不破坏已有的东西（Linux aarch64）是非常重要的，但是这确实耗费了许多工程周期来确保补丁是正确的并在两个平台完成整体测试。正是这种认真和专注让我对这个团体的努力感到特别自豪；他们为这种工作设定了很高的标准。感谢 Monica 的领导和她团队的工作；他们从头到尾都做到了这一点，而且表现得非常出色。 Beckwith：对于微软来说， Windows（10）支持 Arm （Windows 10 on Arm，WoA）是一项重大的举措。我们为开发人员所提供的第一个现代、基于云环境的 WoA 产品是 Surface Pro X 设备。 Arm64 拥有一个非常丰富的生态系统，随着 Arm 服务器的推出，显然我们需要有一个针对 Java 的移植，这样才能支持我们在“用 Arm 服务器处理器驱动数据中心创新”的投资。 Red Hat 在移植 OpenJDK 到 Arm64 的 Linux 上方面已经做得非常棒了。鉴于我们 Windows 开发人员的基础，所以将 Windows 移植作为对 OpenJDK 生态系统的第一个重要贡献是非常有意义的。我们想向 OpenJDK 社区传递这样一个信号：我们来这里是为了与 Java 平台协作并提供帮助的。 至于移植所面临的最大挑战：我认为在开始进行移植的时候，我们意识到将会接触 linux-aarch64 代码库和 windows-x86-64 代码库中的共享代码。我们想要确保“最小化我们的影响”，因为我们的目标不仅是推出对新平台的支持，还要支持、清理和合并我们所接触到的所有内容。 正如 Martijn 在前面所述，我们还投入了大量的精力为测试和构建过程搭建健壮的 CI，我们想要确保在所有的平台和组合上运行功能性测试。我们还在 windows-aarch64、linux-aarch64 和 windows-x86-64 测试平台上运行性能对比和回归测试。关于更多的细节，请参阅 JEP 388 的“测试”章节。

InfoQ：社区对这些贡献的反应是什么？AArch64 可以让开发人员使用了吗？如果是这样的话，它的限制是什么？对于急于使用 AArch64 版本的开发人员，有什么建议吗？

Verburg：我们对社区的反应感到非常开心。在 Reddit、Hacker News 以及各种 Java 社区，这项移植得到了广泛的好评。我认为最能说明问题的是补丁的质量（正如 Red Hat 的 Linux Aarch64 移植项目的主管 Andrew Haley 所言）以及对游戏领域的机会感到兴奋的普通 Java 用户。 Beckwith：我们觉得 OpenJDK 社区向我们敞开了怀抱，在对我们的补丁进行审查和反馈方面提供了巨大的支持！我个人对我们收到的赞扬和报道感到惭愧。移植本身已经完成，我们正在实现进一步的特性。因为Arm64 之上的Windows 是一个相对较新的平台，所以我们也在关注原生组件和类似依赖的可用性，例如借助我们的移植运行Minecraft，我们需要确保 LWJGL 能够在新新平台上运行。

InfoQ：预计什么时候才能安全地在生产环境使用它呢？在你们的工作中在使用该平台吗？如果你们在使用它的话，感觉如何？

Verburg：对于生产环境的建议，我们会相当保守。在宣布生产环境就绪之前，我们还要经历多个质量相关的里程碑：

1. 代码需要完整合并到 OpenJDK jdk/jdk（即主线）。
2. 我们需要内部完成技术兼容性套件（Technical Compatibility Kit，TCK）测试。
3. 我们需要确保通过所有的 AdoptOpenjDK 质量保证（AdoptOpenjDK Quality Assurance）套件。在这一点上，我们已经做得很好了。
4. 我们需要确保能够运行所有重要的行业功能性和性能基准测试。我很高兴地告诉大家，Monica、Ludovic、Bernhard 以及我们的团队在这里也取得了很大的进步。

所有这些都是可以实现的。我们知道如何处理它们，这只是工程方面的工作，在完成之前之前我们需要一些时间。 我们确实在使用自己的成果，但是目前我不能发表更多的评论。 Beckwith：我的座右铭是“信任但要进行验证”。我将其用到了任何有针对性的性能改善和我们上游的补丁上。所以，我的建议是验证这个移植是否适合你们的环境，并且请为我们提供反馈。 现在，回到我的开发工作，我想要强调，我有一个简单的标准来确定该移植的状态：将staging 仓库集成会主线并且移植能够通过 TCK 和 AQA 测试。 我们确实在“吃自己的狗粮”，我可以证明它的味道真的很不错！我的一个工作和测试系统是笔记本配置的 Surface Pro X，它的表现让我印象深刻。

InfoQ：在 OpenJDK 的发布过程中会进行一些基准测试吗？相对于其他的架构，ARM 架构的表现如何？

Verburg：整个这些我们都已经做了。我对团队成员的努力感到自豪。在阐述细节方面，我比 Monica 差远了，所以让她来介绍吧。 Beckwith：除了上述知名的测试，我还在我们的 openjdk-aarch64 GitHub 仓库中维护了一个工作负载状态界面。Arm64 服务器非常具有竞争力，我们已经看到了非常棒的结果。

InfoQ：目前，似乎出现了针对 ARM 处理器的淘金潮：苹果正在将他们的芯片转向基于 ARM 的架构，AWS 也在不久之前发布了 ARM 服务器。那么使用该处理器的好处是什么？Azure 也会在不久之后支持 ARM 服务器吗？

Verburg：这会潜在地降低每个计算单元的能源消耗，实现成本的节省（反过来又会导致 COGS 的减少），这让整个行业都在关注这个问题。现阶段，我们不能评论 Azure 产品的具体方向，但是可以肯定的是，微软正在仔细研究这个问题。 Beckwith：随着 Neoverse N1 核心的引入（Arm 8.2 ISA），Arm 已经为服务器 / 云市场做好了充分的准备。传统上，Arm 支持较弱的内存模型，这意味着在多核环境中，当数据访问需要遵循预先定义的程序执行顺序时，就需要在软件层面介入，通过在代码中包含守卫 / 屏障 / 栅栏（guard/barrier/fence）来保证执行顺序。 对于支持 Arm 8.1+ ISA 的平台，我们已经看到了一些改善，这要归功于新的原子指令，在 Neoverse 中，我们也看到了智能设置屏障（如果确实不需要的话，可以完全消除它们）。除此之外，借助 7nm 的芯片，我们还看到了能耗的降低和性能的改善。

InfoQ：大约在一年前，jClarity 被微软收购，其宣称的目的是帮助 Azure 的 Java 工作负载。过去的一年中，您和 jClarity 其他的人过的怎么样呢？

Verburg：这是一个非常棒的旅程。学习新的公司系统是很有挑战性的，我们从 Google Docs 和 Slack 迁移到了 Office 365 和 MS Teams。同世界各地买来的其他 Java VM 主机、工具和基础设施专家构建共同的文化也需要时间。跨越六个不同时区的团队建设本身就很有挑战性，但通过一些创造性的思维，这些问题都是可以解决的。 我们已经能够继续推进 jClarity 的愿景，也就是 ML 引导的性能诊断，我们现在能够通过一个完整的 VM 工程团队影响 Java 的核心，所以我们很高兴最初的想法能够持续发挥更大的影响力。 我对其他被收购的创业公司的建议是需要六到九个月的时间才能真正适应，只有到那时，你才能考虑按照以前的节奏继续前进（然后最终超越它）。 我们现在又进入了一个快速发展的阶段，生产出了一些令人赞叹的软件，所以我个人感觉我们又回到了快速发展的创业公司的节奏，但是，现在是一个资源充足的公司，而且懂得如何经营企业。

InfoQ：Martijn，jClarity 被微软收购对 AdoptOpenJDK 意味着什么呢？它是否会带来与公司相关的繁琐的决策过程？

Verburg：微软有一个非常明确的策略，那就是我们会成为 AdoptOpenJDK 的平等合作伙伴，而不会因为它的体量造成不适当的影响。起初，因为整个 jClarity 都在忙于开始适应新的角色，肯定会有一些混乱。 但是，比起在 jClarity，现在情况已经有所改善，因为我们可以让更多的人力加入到这个项目的基础设施、构建和测试中来，还有一些受欢迎的 Azure 计算能力！Adopt 依然由指导委员会进行管理，我很高兴地说，没有任何事情受到公司繁文缛节的拖累和约束。事实证明，微软最近在开源方面做得非常好，所以我们被鼓励继续从事我们正在做的事情。

InfoQ：微软还为 OpenJDK 做了很多贡献，从技术上来讲，其中哪些是最困难的？

Verburg：我认为 Stack Allocation 提案和 Windows ARM 64 移植在工作量 / 复杂性方面大致相当。它们都需要深入研究 Hotspot 的运行方式，这需要大量的专业知识并且要非常仔细，以便于在没有损失的情况下提供新的收益。 Beckwith：正如 Martijn 所述，stack allocation 是我们最大的工作之一。我们也在研究内联改进和其他类似 JIT 的优化。

InfoQ：ARM 移植和整个团队接下来的工作是什么呢？

Verburg：对于 ARM 移植，我们需要进行最后的完善，通过 TCK 的运行测试，JEP 目标则是 Java 的主版本发布。我想 Monica 在这方面可以提供更多有趣的细节。 总的来说，团队将继续致力于 OpenJDK 的改进，这将对第一方和第三方 Java 工作负载产生积极的影响。我们正在研究 Azure 和 Minecraft 等子公司的内部和客户工作负载，看看我们可以在哪里创造最大价值。我要强调的是，这项工作将会在 OpenJDK 项目的上游继续进行；微软在 OpenJDK 是好公民，我们很高兴能回馈这个美妙的社区！ 我们还将考虑将 jClarity 的基于 ML 性能诊断的 IP 集成到各种 Azure 服务中，但目前还没有具体的产品发布。 最后但同样重要的是，你还将看到来自我们的更多社区推广，包括 AdoptOpenJDK 的持续支持（以 Eclipse Adoptium 的形式转移到了 Eclipse 基金会），以及通过我们的 Java at Microsoft 博客和@javaatmicrosoft Twitter 账号源源不断地发布文章、帖子和材料。 Beckwith：我们的一些重要里程碑如下所示：

• 将 staging 仓库合并至上游
• JDK 发布版并不是唯一的目标，还要完整地集成和交付 Arm64 上 Windows 的移植。
• 我们期待实现 TCK 合规检验。

就个人而言，我还希望推动支持 OpenJFX、Minecraft 以及类似的原生组件。 就团队来讲，我希望能够不断优化 JVM 并与 Java/JVM 路线图进行集成和保持一致，尤其是一些有益的生态系统项目，举例来说 Panama、Metropolis、Valhalla 等。

原文链接：

OpenJDK Comes to Windows 10 on ARM