JEP 503：移除 32 位 x86 移植

原文：JEP 503- Remove the 32-bit x86 Port
作者：
日期：2025-10-26

所有者阿列克谢·希皮列夫（Aleksey Shipilev）
类型特性
范围实现
状态已关闭 / 已交付
发布版本25
组件HotSpot/ 其他
讨论组hotspot - dev@openjdk.org
工作量M
持续时间M
相关内容JEP 501：将 32 位 x86 移植标记为待移除
审核人马克·莱因霍尔德（Mark Reinhold）
创建时间2024 年 11 月 28 日 09:59
更新时间2025 年 8 月 1 日 18:15
问题编号8345168

摘要

移除 32 位 x86 移植的源代码及构建支持。该移植在 JDK 24 中已被标记为待移除（JEP 501），明确计划在未来版本中移除。

目标

  • 不再阻碍那些需要特定平台支持的新特性，使其无需为 32 位 x86 实现回退方案。
  • 移除仅适用于 32 位 x86 的所有代码路径。
  • 简化 JDK 的构建和测试基础设施。

非目标

  • 无意移除或改变对其他任何架构的 32 位支持。
  • 无意从过往版本中移除 32 位 x86 移植。

动机

正如我们在 JEP 501 中标记该移植为待移除时所指出的：

维护这个移植的成本超过了收益。在新特性（如 Loom、外部函数与内存 API（FFM）、向量 API、后期垃圾回收屏障扩展等）上保持一致性，存在巨大的机会成本。标记并最终移除该移植，将使 OpenJDK 开发者能够加快新特性和增强功能的开发。

描述

目前，32 位 x86 移植仍可构建，尽管它不受支持，也不能保证性能良好。

我们将查找并移除对 32 位 x86 的构建和代码支持。鉴于 HotSpot JVM 中 x86 特定代码的 32 位和 64 位部分之间的高度内聚性，我们预计深度清理工作将耗费大量时间，并且会与不断变化的 HotSpot 代码产生诸多持续冲突。这就是为什么我们打算在 JDK 25 开发初期移除 32 位 x86 移植，然后在大型特性开始集成之前，对共享代码进行一系列后续清理。

我们将修改 JDK 构建系统，移除在 32 位 x86 平台上编译的支持，并更新 JDK 文档以反映对 32 位 x86 支持的移除。

风险与假设

JEP 501 中的原始风险与假设在此同样适用：

  • 现代 JDK 对 32 位 x86 没有迫切的行业需求 —— 我们认为 x86 领域已坚定地转向 64 位。不再生产仅支持 32 位的新 x86 硬件。剩余的 32 位 x86 部署属于遗留系统。行业支持已相应减少以匹配这一现实。Windows 10 是最后一个支持 32 位操作的 Windows 操作系统，将于 2025 年 10 月终止支持，并且 JDK 中已移除 Windows 32 位 x86 移植（JEP 479）。Debian 计划在不久的将来停止支持 32 位 x86。
  • 对于仍支持 32 位 x86 的版本，回退安全性有足够空间 —— 主线中没有 Linux 32 位 x86 移植意味着从主线回退到积极支持的长期支持（LTS）版本将更加复杂，因为必须与这些版本中仍然存在的 Linux 32 位 x86 移植进行协调。我们假设大多数较旧的 Linux 32 位 x86 应用程序堆栈仍在使用 JDK 8，而我们不常对其进行回退，这降低了风险。在较新的 LTS 版本中，Linux 32 位 x86 维护者仍需额外工作，以确保他们的构建能够正常运行。
  • 其他 32 位移植的维护不受显著影响 —— Linux 32 位 x86 为保持 32 位代码的整洁提供了途径，这间接有利于其他 32 位移植（尤其是 ARM32）的维护。我们假设我们仍能够较为轻松地维护 ARM32 移植。
  • 回退选项可以单独测试 —— 我们假设现有的回退机制，如 Loom 的 1:1 调度器和 FFM 的回退链接器，可以单独测试，而无需承担维护整个 Linux 32 位 x86 移植的负担。

此外，我们假设 JEP 501 已向供应商和用户发出足够警告，让他们考虑从 32 位 x86 迁移的路径。