随着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：对于生产环境的建议，我们会相当保守。在宣布生产环境就绪之前，我们还要经历多个质量相关的里程碑：

代码需要完整合并到OpenJDK jdk/jdk（即主线）。

我们需要内部完成技术兼容性套件（Technical Compatibility Kit，TCK）测试。

我们需要确保通过所有的AdoptOpenjDK质量保证（AdoptOpenjDK Quality Assurance）套件。在这一点上，我们已经做得很好了。

我们需要确保能够运行所有重要的行业功能性和性能基准测试。我很高兴地告诉大家，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

创作场景

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