跳到主要内容

JEP 501: 把 32 位 x86 端口标记为废弃以便移除

QWen Max 中英对照 JEP 501: Deprecate the 32-bit x86 Port for Removal

概述​

弃用 32 位 x86 端口，并打算在未来的版本中移除它。这将从而弃用 JDK 中仅存的 Linux 32 位 x86 端口。实际上，这也将会弃用任何剩余的下游 32 位 x86 端口。在 32 位 x86 端口被移除后，与架构无关的 Zero 端口将是运行 32 位 x86 处理器上的 Java 程序的唯一方式。

目标​

  • 解锁需要平台特定支持的新功能，而无需实现32位 x86 回退。

  • 在相关文档、配置脚本和测试作业中将该端口及相关端口特定功能标记为已弃用待移除。

非目标​

  • 不会将任何其他 32 位端口弃用作为目标。

动机​

正如在最近的一次讨论中当前 32 位 x86 维护者和相关方所指出的，维护这个端口的成本超过了其带来的好处。保持与新特性（如 Loom、外部函数和内存 API (FFM)、向量 API、后期 GC 屏障扩展等）的一致性是一个巨大的机会成本。弃用并最终移除该端口将使 OpenJDK 开发人员能够加快新特性和增强功能的开发速度。

在 JDK 24 中弃用此端口将允许我们在 JDK 25 中移除它。

描述​

尝试配置 32 位 x86 构建将产生：

$ bash ./configure
...
checking compilation type... native
configure: error: The 32-bit x86 port is deprecated and may be removed in a future release. \
Use --enable-deprecated-ports=yes to suppress this error.
configure exiting with result code 1
$

构建配置选项 --enable-deprecated-ports=yes 将会抑制该错误并继续：

$ bash ./configure --enable-deprecated-ports=yes
...
checking compilation type... native
configure: WARNING: The 32-bit x86 port is deprecated and may be removed in a future release.
...
Build performance summary:
* Cores to use:   32
* Memory limit:   96601 MB

The following warnings were produced. Repeated here for convenience:
WARNING: The 32-bit x86 port is deprecated and may be removed in a future release.
$

不能保证该端口能够构建，更不用说正常工作了。

为了推动主线开发，我们已经在 JDK 源代码仓库中定义的 GitHub Actions 中禁用了 Linux 32 位 x86 构建（8338286）。作为此次弃用的一部分，我们将完全移除这些构建任务。

风险和假设​

  • 现代的JDK对于32位x86没有迫切的行业需求 —— 我们假设x86世界已经坚定地转向了64位领域。不再有新的仅支持32位的x86硬件被制造出来。剩下的32位x86部署都是遗留系统。行业的支持已经减少以适应这一现实。Windows 10是最后一个支持32位操作的Windows操作系统，将在2025年10月达到生命周期终止，并且Windows 32位x86端口已经从JDK中移除（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端口负担的情况下单独进行测试。

替代方案​

另一种选择是继续支持 32 位 x86。这将需要积极的维护者，他们可以提供可持续且性能良好的虚拟线程实现，以及未来的 JEP，以确保 32 位 x86 上的 JDK 继续满足 Java 开发者的期望。目前没有潜在的维护者愿意承担这一角色。