OpenJDK在ARM上安装在Windows 10上

微软对ARM处理器的热情又向前迈进了一步：今年夏天，微软对OpenJDK做出了第一个重大贡献：将OpenJDK移植到Windows10ARM(AArch64)的第一阶段。ARM处理器可以在笔记本电脑上使用，最近还可以在云环境中使用。具体地说，这意味着人们可以在Windows10ARM操作系统上开发和运行Java代码。

移植工作是OpenJDK的Windows on Arm64的莫妮卡·贝克维斯(Monica Beckwith)加入微软以来领导的第一个项目。InfoQ联系了她和Java工程组SWE组主要经理Martin jn Verburg，探讨这对Java社区意味着什么。是否已经可以切换到Surface Pro作为您的Java开发机器？我们能从Azure上ARM处理器的性能中获益吗？

InfoQ：感谢您抽出时间为我们的读者回答一些问题。我们可以先请你们自我介绍一下自己，描述一下你们在微软的角色和日常工作吗？

Verburg：大家好，我是Martjn Verburg，我是微软Java工程组的首席SWE组经理。你们中的一些人之前可能知道我是jClarity的首席执行官(微软去年收购了该公司)，或者是AdoptOpenJDK或雅加达EE的指导委员会成员之一。(有一些传言称我是恶魔般的开发商，但由于我是一名经理，这不可能是真的；-)。

Beckwith：大家好，我是Monica，是OpenJDK的Windows on Arm64项目的负责人。我的日常工作包括改进OpenJDK的HotSpot VM。自从Sun在2006年开始这个项目/工作以来，我就一直在使用OpenJDK。我主要从事性能方面的工作，致力于优化应用程序、JVM、GC启发式，并确保生成的代码与底层硬件产生共鸣。在加入微软之前，我在ARM担任托管运行时的性能架构师。

InfoQ：这是微软对OpenJDK的第一个重大贡献。您为什么开始使用ARM？要解决的最具挑战性的问题是什么？结果如何？（后来呢？）？你会有什么不同的做法呢？

Verburg：微软对ARM有两个感兴趣的领域：我们的Surface X Pro系列在ARM硬件上运行，2017年我们宣布打算在我们的云基础设施上试验ARM。

关于港口的挑战，从我的角度来看，看到团队在以下方面花费的时间和精力是很有趣的：

OpenJDK社区将补丁拆分成易于消化的块(在本例中为四个补丁集)。

当您要添加对新端口的支持时，需要添加全新的代码，然后(IMO)对共享代码进行更复杂的重新编写。对已经存在的(Linux Aarch64)不造成损害对我们来说真的很重要，但它确实需要大量的工程周期才能正确安装补丁，并在两个平台上进行彻底的测试。正是这种细心和关注让我为这个团队的努力感到特别自豪，他们为这类工作设定了很高的标准。感谢莫妮卡的领导和她团队的工作，他们从头到尾都做到了这一点，简直是非常出色。

Beckwith：在ARM(WOA)上启用Windows(10)是微软的一项重大努力。我们第一个面向以现代云计算环境为中心的开发人员的WoA产品是Surface Pro X设备。

ARM64拥有丰富的生态系统，随着ARM服务器的推出，我们显然需要一个Java端口来支持我们在数据中心使用ARM服务器处理器推动创新的投资。

RedHat在将OpenJDK移植到基于Arm64的Linux方面已经做得很好了。考虑到我们的Windows开发人员基础，让Windows端口成为我们对OpenJDK生态系统的第一个重大贡献对我们来说是有意义的。我们想向OpenJDK社区发出信号，我们来这里是为了在Java平台上进行协作和帮助。

至于最具挑战性的部分：我认为当我们开始研究移植时，我们意识到我们将涉及到linux-aarch64代码库和windows-x86-64代码库中的共享代码。我们希望确保将涟漪降到最低，因为我们的目标不仅是推出新的平台支持，而且还要支持/清理/合并我们接触到的所有内容。

正如上面提到的，我们还在测试和构建的健壮CI上投入了大量资金，我们希望确保在所有平台组合上运行功能测试。我们还在windows-aarch64、linux-aarch64和windows-x86-64测试平台上进行了性能比较和回归测试。有关更多详细信息，请参阅388年1月的测试部分。

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

Verburg：我们对这种反应非常满意，在Reddit、Hacker News和各种Java社区属性中，这个端口都非常受欢迎。我认为最有说服力的评论其实是关于补丁的质量(正如Red Hat在Linux Aarch64移植方面的领先者Andrew Haley所说的那样)，以及对游戏机会感到兴奋的普通Java用户：-)。

Beckwith：我们觉得OpenJDK社区对我们的欢迎是张开双臂的，在我们的补丁审查/反馈方面为我们提供的支持是惊人的！我个人对我们收到的赞扬/报道感到谦卑。端口本身已经完成，我们正在启用更多功能。由于ARM64上的Windows是一个相对较新的平台，我们还在考虑如何启用本机组件和类似的依赖关系--例如，为了让“我的世界”在我们的端口上运行，我们需要确保LWJGL能够在新平台上运行。

InfoQ：什么时候可以安全地假设它在生产环境中使用是安全的？你也在使用这个平台来做你的努力吗？如果是这样的话，感觉如何？

弗伯格：我们对生产中的建议相当保守。在宣布生产准备就绪之前，我们有几个质量里程碑要完成：

我们需要确保我们通过了所有的AdoptOpenjDK质量保证套件。“我们在这里已经做得很好了。”

我们需要确保我们能够运行所有重要的行业功能和性能基准。我很高兴地告诉大家，莫尼卡、卢多维奇、伯恩哈德和球队在这里也取得了很大的进步。

以上所有这些都是完全可以实现的。我们知道该为所有人做些什么，这只是一项工程工作，在我们到达那里之前需要一些时间。

可以说，我们确实喝自己的香槟，但现阶段我不能对此发表更多评论。

贝克维斯：我的口头禅是信任，但要核实。我将其应用于任何有针对性的性能改进和我们上游的任何补丁。因此，我的拙劣建议是验证该端口如何适合您的环境，并请提供反馈。

现在戴上我的开发人员的帽子，我想要强调的是，我有简单的标准来确定此端口的状态-将临时回购集成到主线以及通过TCK和AQA测试的端口。

至于吃我们自己的狗粮-是的！我可以证明它很好吃！我的工作和测试系统之一是笔记本电脑环境中的Surface Pro X，我对它印象深刻。

InfoQ：在OpenJDK发布过程中有没有运行基准测试？与其他架构相比，ARM架构的表现如何？

弗伯格：整个主持人都跑了，我为团队在这件事上如此勤奋而自豪。与莫妮卡相比，我会在解释细节方面做得很差，所以让她来吧！

Beckwith：除了上面提到的测试之外，我还在我们的OpenJDK-aarch64GitHub repo上维护了一个工作负载状态页面。ARM64服务器非常有竞争力，我们已经看到了很好的结果。

InfoQ：似乎有一股对ARM处理器的淘金热：苹果正在转向他们自己的基于ARM的芯片，而AWS不久前发布了ARM服务器。使用它有什么好处？Azure很快也会支持ARM服务器吗？

Verburg：正是潜在的每台计算单位功耗的降低节省了成本(这反过来又导致了COGS的降低)，这让整个行业都在关注这一点。目前我们还不能对Azure的具体产品方向发表评论，但可以肯定的是，微软正在仔细考虑这一点。

Beckwith：随着Neoverse N1内核(ARM8.2ISA)的推出，ARM已经为服务器/云市场做好了很好的准备。ARM传统上支持较弱的内存模型，这意味着在多核环境中，当数据访问需要遵循定义的程序执行顺序时，软件需要介入，并通过在代码中包含警卫/屏障/栅栏来保证执行顺序。

在支持ARM8.1+ISA的平台上，由于新的原子指令，我们已经看到了改进，在Neoverse中，我们也看到了智能的障碍发布(比如在认为不必要的情况下完全消除这些障碍)。除此之外，由于采用了7纳米晶圆厂，我们还看到了功耗的降低和性能的提高。

InfoQ：Martjn，jClarity在大约一年前被微软收购，宣布的目的是帮助优化Azure Java工作负载。你和其他jClarity员工过去的一年过得怎么样？

弗伯格：这真是一次了不起的旅行！学习新的公司系统，从Google Docs和Slake迁移到Office365和MS团队都存在挑战。与我们从世界各地购买的其他Java虚拟机、工具和基础架构专家建立共同的文化也需要时间。跨六个不同时区的团队建设带来了自身的挑战，但只要有一些创造性的想法，这些挑战是可以解决的。

我们能够继续在内部推动ML领导的性能诊断的jClarity愿景，我们现在能够通过一个完整的VM工程小组来影响Java的核心，所以我们非常高兴我们最初的北极星继续伴随着更广泛的影响范围。

我对其他被收购的初创公司的建议是，需要6到9个月的时间才能真正适应环境，只有到那时，你才能考虑以之前的速度前进(然后最终超过它)。

我们现在已经到了那个阶段，我们再次行动非常迅速，并生产了一些令人惊叹的软件，所以我现在个人觉得，我重新执掌着一家快速发展的初创公司，但也是一个资源非常雄厚的公司，也知道如何做企业：-)。

InfoQ：Martjn，微软收购jClarity对AdoptOpenJDK的努力意味着什么？它是否带来了有时与公司相关的繁琐的决策过程？

Verburg：微软有一个非常明确的政策，那就是我们将成为AdoptOpenJDK的平等合作伙伴，而不是仅仅因为它的规模而产生不适当的影响。紧随其后的是，当整个jClarity团队忙于开始他们的新角色时，肯定会有一些混乱。

然而，现在的情况实际上已经超过了jClarity的情况，因为我们可以为项目带来更多的基础设施、构建和测试方面的人力，以及一些受欢迎的Azure计算能力！我们的采用继续由指导委员会的管理当局运营，我很高兴地说，没有任何事情会慢下来，也没有因为公司的繁文缛节而受到束缚。事实证明，微软这些天非常清楚如何做开源，所以我们一直被鼓励继续做我们正在做的事情：-)。

InfoQ：微软对OpenJDK还有很多其他贡献，技术上最难解决的是哪一个？

Verburg：我认为Stack分配提案和Windows ARM 64端口在努力/复杂性方面大致相当，它们都代表了深度潜水热点工作，这需要极大的专业知识和细心，才能提供新的好处而不会倒退。

Beckwith：正如Martjn已经指出的，堆栈分配是我们较大的工作之一。我们还在研究内联改进和其他类似的JIT优化。

InfoQ：ARM移植的下一步是什么，以及整个团队的下一步是什么？

Verburg：对于ARM移植，它现在需要最后的润色，在TCK上通过测试，JEP的目标是Java主要版本发布。我想Monica可以在这里提供更多有趣的细节！

总的来说，该小组将继续致力于OpenJDK的改进，这将对第一方和第三方Java工作负载产生积极影响。我们正在研究Azure和诸如“我的世界”等子公司的内部和客户工作负载，看看我们可以在哪里实现最大价值。我要强调的是，这项工作将继续呈现在OpenJDK项目的上游，微软将在这里成为OpenJDK的好公民，我们很高兴能回馈那里美好的社区！

我们还将寻求将jClarity关于基于ML的性能诊断的IP集成到各种Azure服务中，但目前还没有具体的产品发布。

最后但同样重要的是，您还将看到更多的社区推广活动来自我们，包括对AdoptOpenJDK的持续支持(以Eclipse Adoptium的身份转移到Eclipse基金会)，以及通过我们的Java at Microsoft博客和@javaatmicrosoft Twitter帐户源源不断的文章、帖子和材料。

确定JDK版本不仅要针对Windows，而且要完全集成和交付Windows on Arm64端口。

就我个人而言，我还希望推动OpenJFX、Minworld和类似产品的本地组件的实现。

至于团队-我们希望确保我们不断优化JVM，最重要的是与Java/JVM路线图很好地集成和协调，特别是当我们可以通过巴拿马、大都会、瓦尔哈拉项目设想一些有益的生态系统时-仅举几例。

InfoQ上上周内容的综述每周二都会发布。加入一个超过25万名高级开发人员的社区。查看示例。

选择您的国家/地区我同意InfoQ.com按照本隐私声明中的说明处理我的数据。