Remove the source code and build support for the 32-bit x86 port. This port was deprecated for removal in JDK 24 (JEP 501) with the express intent to remove it in a future release.
GoalsUnblock new features that require platform-specific support from having to implement 32-bit x86 fallbacks.
Remove all code paths that apply only to 32-bit x86.
Simplify the JDK's build and test infrastructure.
It is not a goal to remove or change 32-bit support for any other architecture.
It is not a goal to remove the 32-bit x86 port from past releases.
As noted when we deprecated this port in JEP 501:
DescriptionThe cost of maintaining this port outweighs the benefits. Maintaining parity with new features, such as Loom, the Foreign Function & Memory API (FFM), the Vector API, 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.
At present the 32-bit x86 port can still be be built, although it is not supported and not guaranteed to perform well.
We will find and remove build and code support for 32-bit x86. Given the high cohesion between the 32-bit and 64-bit portions of the x86-specific code in the HotSpot JVM, we expect the deeper cleanups to take considerable time and have many on-going conflicts with the ever-changing HotSpot code. This is why we intend to remove the 32-bit x86 port early in the JDK 25 timeframe and then perform a series of follow-up cleanups in shared code, before large features begin integrating.
We will modify the JDK build system to remove support for compiling on 32-bit x86 platforms, as well as update the JDK documentation to reflect the removal of 32-bit x86 support.
Risks and AssumptionsThe original risks and assumptions from JEP 501 apply here:
There is no pressing industry need for 32-bit x86 with modern JDKs — We assume that the x86 world has moved firmly to the 64-bit realm. No new 32-bit-only x86 hardware is being manufactured. The remaining 32-bit x86 deployments are legacies. Industry support has dwindled to match this reality. Windows 10, the last Windows operating system to support 32-bit operation, will reach End of Life in October 2025, and the Windows 32-bit x86 port has already been removed from the JDK (JEP 479). Debian plans to stop supporting 32-bit x86 in the near future.
There is enough margin for backport safety with releases that still support 32-bit x86 — Not having the Linux 32-bit x86 port in the main line means that backports from the main line to actively supported LTS releases will be more complicated, since they will have to be reconciled with the Linux 32-bit x86 port still in those releases. We assume that the majority of older Linux 32-bit x86 application stacks are still on JDK 8, to which we do not backport often, which mitigates this risk. There will still be additional work for Linux 32-bit x86 maintainers in newer LTS releases to make sure their builds work.
The maintenance of other 32-bit ports is not significantly affected — Linux 32-bit x86 provides a vehicle for maintaining 32-bit cleanliness, which indirectly benefits the maintenance of other 32-bit ports, notably ARM32. We assume that we can continue to maintain the ARM32 port easily enough.
Fallback options can be tested separately — We assume that existing fallback mechanisms, such as Loom's 1:1 scheduler and FFM’s fallback linker, can be tested separately, without the burden of maintaining the whole Linux 32-bit x86 port.
Additionally, we assume that JEP 501 gave sufficient warning for vendors and users to consider migration paths from 32-bit x86.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4