https://developers.redhat.com/blog/2021/02/01/how-red-hat-ported-openjdk-to-64-bit-arm-a-community-history/
Andrew Haley 2021年2月1日
对于Arm 公司来说已经过去了一年，该公司为计算机处理器设计精简指令集计算（RISC）架构。基于Arm的计算机将在可预见的未来中发挥重要作用的消息甚至已经传到了主流媒体。在2019年底，亚马逊网络服务发布了基于Arm的Graviton2服务器。2020年6月，苹果宣布了将Macintosh计算机迁移到Apple芯片（即Arm）上的计划。
对于我们在Arm服务器上已经工作了多年的人来说，这种转变已经来了很长时间。
在一开始的时候
回到2011年的一天。我在The Wrestlers（英国剑桥科技界最喜欢的泰国餐馆）与Red Hat的首席Arm架构师Jon Masters共进午餐。他分享了令人振奋的消息：Arm将生产64位架构，而Red Hat将向其移植Red Hat Enterprise Linux（RHEL）。为此，我们需要解决很多问题，但是其中一个特别困难。当时可用于新的64位体系结构的软件不包括Java。Java是许多企业软件的关键组成部分，因此，这一消息相当重要。
有人必须写一个端口。我听说有两名专家可以在大约一年内编写一个OpenJDK的准系统端口，但这只是我所知道的。如果我的团队打算做到这一点，我们将必须在工作中学习。
我为能从事如此艰巨的工作而感到兴奋，但是Red Hat如何证明在没有保证成功的情况下启动这个大型项目呢？我争辩说，除非我们这样做，否则我们必须付钱给某人。那会花很多钱，那么为什么不自己动手省钱呢？这将是很好的宣传，我们将能够建立联盟。但是还有另一个更深层次的理由将其保留在内部。我们一直在为OpenJDK建立支持团队。通过编写整个端口，我们将获得无法以其他任何方式获得的经验。红帽公司的管理层表示同意（从那时起就一直支持该项目），所以我们很高兴。
我决心成为该项目的工程师之一，但我不能一个人做。幸运的是，Andrew Dinn即将加入我们的Java团队。他从事Java已有很长时间，并且具有为Lisp机器和逻辑语言编写编译器的经验。他会很合适。
一件事让我担心：如果别人首先做了一个港口怎么办？这样一来，所有的努力和光荣的希望都将被浪费掉。预防该灾难的唯一方法是获得先发优势并在公共场所进行工作。快速完成，做好并免费提供。建造它，他们会来的。
开始项目
我们确实有一个问题，或者说是两个。首先，不存在AArch64处理器。同样，说服Arm Ltd.向我们提供所需的详细信息也不容易。Arm的Philippe Robin的坚持和帮助解决了文档编制问题，但是缺少硬件更加困难。可以在仿真下运行所有OpenJDK，但当时的仿真器非常慢。更糟糕的是，OpenJDK必须调出操作系统。在启动Java之前，我们需要在模拟器上引导所有Linux。
安德鲁·狄恩（Andrew Dinn）记得我们在一次会议上吃早餐的时候，我兴奋地告诉他，那天早上洗澡时，我想出了要做什么。我们将使用一个简单的功能性指令集模拟器，但仅针对我们自己生成的AArch64代码。OpenJDK JVM的其余部分是C ++。我们可以在基于Intel x86的PC上以全速本机运行。从C ++到Java的每个调用都会进入模拟器，从Java到C ++的每个调用都会离开模拟器并返回到x86代码。但是，我们在哪里可以得到AArch64仿真器库？“我们会写一个。”我说。“这是一个RISC。它能有多难？”
我们于2012年6月开始。安德鲁·迪恩（Andrew Dinn）花了一些时间来编写模拟器，而我继续编写汇编器和初始启动代码。几个月后，我们正在执行Java字节码。编写我们自己的模拟器的想法受到了启发。我们可以创建复杂的断点条件，甚至记录指令跟踪，以便我们可以在JVM崩溃时查看指令历史记录。结果，最初的移植进行得很快。回顾日志，我看到一个条目“足够了，世界！” 在2012年10月4日。这是重要的一天：尽可能输出“ Hello，World！” 在控制台上，Java必须执行一百万个字节代码中的大约四分之三而不会崩溃，并且必须执行大部分虚拟机。
然后有三个
到2013年夏天，我们三个人都在从事该项目。前Arm公司的Java专家Edward Nevill从Linaro加入了该项目。他是第一个获得实际硬件的人。我对我们的小型AArch64模拟器非常满意，以至于我很高兴其他人可以在真实的机器上调试我们的工作。我希望这是一个痛苦的过程。但是，除了刷新指令高速缓存的一个小问题和浮点标志的问题之外，所有这些都有效！我很惊讶。我们已经从Arm的文档中编写了自己的模拟器，编译器和汇编器。我们没有独立的验证，但我们做对了。
爱德华提供了巨大的帮助，到2014年初，我们有了一个工作港口。红帽开始向我们的合作伙伴交付早期版本，我们和其他人继续进行错误修复并提高了性能，2015年3月2日，AArch64端口成为OpenJDK主项目的一部分。Oracle非常棒，在棘手的集成过程中为我们提供了帮助和鼓励。
巩固和（非常）长尾巴
正常工作的JVM与非常好的JVM之间存在相当大的差异。我不知道在Intel / x86 OpenJDK上花了多少时间，但是必须花几十年的工程师时间。使AArch64端口具有竞争力对我们来说是一个真正的挑战，但是我们获得了帮助。来自AArch64硅生产商和其他公司的人们也加入了我们，现在来自世界各地的人们正在港口上工作。
这是红帽的开放和协作方法真正奏效的地方。通过与他人建立合作伙伴关系，我们在纯内部软件开发方面获得了巨大的成倍增长。
但这还不是全部。我们听说Oracle在64位Arm上运行Java，我想知道它是否是我们的端口。事实证明，该端口是专有的，基于Oracle已经拥有的（32位）Arm端口。我担心Java的创建者会获得比我们更好的性能。最终，有人使用了Oracle的端口，向我保证我不必担心。但是，我发现Oracle编写了自己的端口很奇怪。该公司从一开始就获得使用我们所有代码的许可。为什么还要再写一次？
最终，Oracle释放了其Arm 32位和64位端口。这就给我们留下了两个OpenJDK AArch64端口。然后，在2020年11月12日，甲骨文宣布已决定将其资源集中在单个64位Arm端口上：我们在Red Hat开始的AArch64端口。Oracle的JDK 8维护版本中的64位Arm支持现在也基于我们的端口。
最近，苹果大惊小怪地宣布了Apple M1芯片，它是AArch64的一种实现。OpenJDK已经为该处理器做好了准备，已经使用了五年。但是，有一个OpenJDK层专用于每种OS-CPU组合。有人必须做这项工作，我们很快有了两个志愿者：Microsoft和Azul，他们一起工作。Microsoft还将OS-CPU层移植到Windows / AArch64。
结论
那么，为什么所有这一切都发生了呢？OpenJDK开发人员社区做出了决定。我相信这是因为我们的小团队提早启动了工作端口，将其加入了OpenJDK主线，并欢迎所有想要参与的人。我们保持了尽可能多的讨论开放。人们自愿参加，我们成为了一个社区。我们在这个社区中所取得的成就远远超过了我们自己希望实现的目标。但是，如果我们在2014年初不释放该工作端口，则不会发生任何事情。
