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

[Aleksey Shipilev]

On Fri, 7 Mar 2025 07:18:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You could add a couple of lines to the build code and it would not be possible to build 32-bit, so that is a necessary but not sufficient condition to claim to implement the JEP IMO.

Agreed. This is why this PR removes the actual implementation of the port as well. Even if you can coerce build system to pass the arch checks, x86_32 would not build, because there is no x86_32 port in the sources anymore. There are only assorted, heavily-intertwined-with-x86-64 leftovers around Hotspot subsystems that were needed to support the port. We will deal with those leftovers at leisurely pace after the port is gone.

> @dholmes-ora: I'm not looking for one big PR, I'm looking for multiple PR's as proposed but which all fall under the JEP umbrella. Until the JEP is targeted then nothing can be integrated anyway. This is what, I thought, dependent PR's were designed for.
> @magicus  Instead, that honor should fall on an umbrella JBS issue, which is dependent on this PR, but also the other planned updates. Before these are done, we can't really say that the JEP is implemented.

I believe we are in agreement that we do not want to cobble all removals/cleanups into a singular PR/changeset. We _can_ convert the umbrella RFE for post-JEP cleanups as the implementation task subtasks. I.e. do:

 - JDK-XXXXX: Implement JEP 503: Remove the 32-bit x86-port (<---- this would be an umbrella, without a changeset)
    - JDK-XXXXX: JEP 503: Remove the x86_32 files and builds support (<---- this would be this PR)
    - JDK-XXXXX: JEP 503: Remove code blocks that handle UseSSE < 2
    - JDK-XXXXX: JEP 503: Remove dead IA32 code blocks
    ...

Then we manually close umbrella issue as "implemented" when subtasks are done. 

What I dislike about this approach is that we are committing to doing free-standing post- x86-32 cleanups under the JEP umbrella. This runs into several problems: a) some cleanups are very deep, intertwined with x86-64, connected to x86-32-zero, and might even be rejected, like deep cleaning in `MacroAssembler` ([JDK-8351162](https://bugs.openjdk.org/browse/JDK-8351162)); b) some cleanups would only be discovered later, and would require yet another umbrella tasks for post-JEP work anyway.

Are you agreeing to this, @dholmes-ora, @magicus? This would create more work for ourselves and our fellow engineers in JDK 25 timeframe. If you are insisting we need to do it this way, can I count on your prompt reviews in these new JEP subtasks?

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

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