JEP draft: Deprecate 32-bit x86 Port for Removal

Summary

Deprecate the 32-bit x86 port, with the intent to remove it in a future release.

Goals

• Unblock new features that require platform-specific support from requiring to implement 32-bit x86 fallbacks.

• Mark the port, and related port-specific features, as deprecated for removal in the relevant documentation, configuration scripts, and test jobs.

Non-Goals

• It is not a goal to deprecate any other 32-bit port.

• It is not a goal to deprecate 32-bit x86 Zero.

Motivation

As noted in [recent RFC][https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009223.html] by current 32-bit x86 maintainer and interested parties, the cost for maintaining 32-bit x86 is outweighing the benefits for doing so. Maintaining parity with new features (Loom, FFM, Vector extensions, late GC barrier expansion, etc) is a major opportunity cost. Deprecating and eventually removing the port would allow OpenJDK developers to accelerate the development of new features and enhancements.

Description

An attempt to configure a 32-bit x86 build will produce the following output:

$ 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
$

The build configuration option --enable-deprecated-ports=yes will suppress the error and continue:

$ 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.
$

There would be no guarantee the port would build and function.

Risks and Assumptions

No industry need for 32-bit x86. We assume that x86 world had firmly moved to 64-bit realm. This is corroborated by the fact that no new 32-bit-only x86 hardware is being manufactured. The remaining 32-bit x86 deployments are old legacy ones. The industry support dwindles down to match this reality. Windows 10, the last Windows operating system to support 32-bit operation, will reach End of Life in October 2025: https://learn.microsoft.com/lifecycle/products/windows-10-home-and-pro. Windows 32-bit x86 port has been already deprecated: https://openjdk.org/jeps/449. Debian plans to stop supporting 32-bit x86 in the nearest future. https://lists.debian.org/debian-devel-announce/2023/12/msg00003.html

Enough margin for backport safety. Not having 32-bit x86 maintained in mainline would mean the backports from mainline to actively supported LTS releases would be more complicated, as they would have to be reconciled with 32-bit x86 port there. We assume that the majority of older 32-bit x86 stacks are still on JDK 8, where we do not backport often, which mitigates this risk. There would still be additional work for 32-bit x86 maintainers in LTS-es to make sure their builds work.

Other 32-bit port maintenance is not significantly affected. 32-bit x86 provides a vehicle for maintaining 32-bit cleanliness, which indirectly benefits maintenance of other 32-bit ports, notably ARM32. We assume that we can maintain ARM32 port easily.

Fallback options can be tested separately. We assume that fallback options (Loom's 1:1 scheduler, FFM Fallback Linker) can be tested separately, without a burden of maintaining the whole 32-bit x86 platform.

Alternatives

The alternative would be to continue to support 32-bit x86. This would require active maintainers who can provide a sustainable and performant implementation of Virtual Threads, as well as future JEPs, to ensure that the JDK on 32-bit x86 continues to meet the expectations of Java developers. There are no prospective maintainers who are willing to take that role.