JEP 501: Deprecate the 32-bit x86 Port for Removal | 弃用 32 位 x86 端口以供删除
概述
计划弃用 32 位 x86 端口，并打算在未来版本中将其移除。这将导致 Linux 32 位 x86 端口被弃用，这是 JDK 中唯一剩余的 32 位 x86 端口。实际上，这也意味着任何剩余的下游 32 位 x86 端口也将被弃用。在 32 位 x86 端口被移除后，在 32 位 x86 处理器上运行 Java 程序的唯一方式将是使用与架构无关的 Zero 端口。
目标
- 解锁需要特定平台支持的新特性，无需实现 32 位 x86 回退。
- 在相关文档、配置脚本和测试作业中标记该端口及其相关的端口特定特性，标明其已被弃用并将在未来移除。
非目标
- 不计划弃用任何其他 32 位端口。
动机
正如最近一次 讨论 中提到的那样，涉及当前 32 位 x86 维护者及相关方的意见，维持这个端口的成本超过了收益。与新特性的维护同步（如 Loom、外部函数和内存 API(FFM)、向量 API、后期 GC 屏障扩展等）是一个重大的机会成本。弃用并最终移除该端口将允许 OpenJDK 开发者加速新特性和增强功能的发展。
在 JDK 24 中弃用此端口将使我们能够在 JDK 25 中将其移除。
描述
尝试配置一个 32 位 x86 构建将会产生：
bash
$ 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
$ 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 开发者的期望。目前没有潜在的维护者愿意承担这个角色。