RFR: 8345169: Implement JEP 503: Remove the 32-bit x86 Port

[Vladimir Kozlov]

On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This PR implements JEP 503: Remove the 32-bit x86 Port.
> 
> The JEP is proposed to target 25, we would not integrate until JEP is ready. Reviews are appreciated meanwhile.
> 
> This is only the removal of obvious 32-bit x86 parts, mostly files with `x86_32` in their name.  Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64. The approach for removing x86_32 files only also makes this PR borderline trivial, and requires no additional testing beyond normal pre-integration checks.
> 
> The rest of the code is quite heavily intertwined with x86_64 and/or Zero, and would require accurate untangling. It would be much easier to review and test once we purge the free-standing parts of 32-bit x86 port, which is also a bulk of the port. The tangling with 32-bit x86 Zero is also why I did not touch most of the build system paths that handle x86. There is [JDK-8351148](https://bugs.openjdk.org/browse/JDK-8351148) umbrella that tracks further cleanup work. One can peek the final state that can be reached with all the cleanups in my earlier exploratory https://github.com/openjdk/jdk/pull/22567.
> 
> Additional testing:
>  - [x] Linux x86_32 Server fastdebug, `make bootcycle-images` (now fails configure)
>  - [x] Linux x86_64 Server fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_32 Zero fastdebug, `make bootcycle-images` (still works)
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)

To clarify. I am completely agree with changes in this PR - I approved it.

My concern is the **Title** of this PR and JBS entry.  So I want to understand the steps we do with this PR and following changes covered by numbers of subtask pointed by Aleksey.

So what, @iwanowww, you say is that this PR is **indeed** implementation of the JEP.
And all subtasks listed in Umbrella RFE are following up RFEs after we integrated the JEP.

Do I understand that correctly?

Why not do what Ioi did for AOT class loading JEP? I mean, to have depending PRs which are combined into one implementation push.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23906#issuecomment-2702316448