跳到主要内容

JEP 501：弃用 32 位 x86 端口并将其删除

概括​

弃用 32 位 x86 端口，并计划在将来的版本中将其删除。这将弃用 Linux 32 位 x86 端口，这是 JDK 中唯一剩下的 32 位 x86 端口。它还将有效地弃用任何剩余的下游 32 位 x86 端口。在删除 32 位 x86 端口后，与架构无关的 Zero 端口将成为在 32 位 x86 处理器上运行 Java 程序的唯一方式。

目标​

  • 解除需要平台特定支持的新功能必须实现 32 位 x86 回退的阻碍。

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

非目标​

  • 我们的目的并不是贬低任何其他 32 位端口。

动机​

正如最近涉及当前 32 位 x86 维护者和相关方的讨论中所指出的那样，维护此移植的成本超过了收益。与新功能（例如 Loom、外部函数和内存 API (FFM)、Vector 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.
$

没有任何保证说港口能够建成，更不用说正常运转了。

为了解除对主线开发的阻碍，我们已经在 J​​DK 源代码存储库 ( 8338286 ) 中定义的 GitHub Actions 中禁用了 Linux 32 位 x86 构建。作为此次弃用的一部分，我们将彻底删除这些构建作业。

风险和假设​

  • 业界对现代 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 开发人员的期望。没有潜在的维护者愿意担任这一角色。