8248817: Windows: Improving common cross-platform code

[rnkovacs]

Not a clean backport. Differences to the original commit:

• The removed lines in stubGenerator_x86_32.cpp and stubGenerator_x86_64.cpp are slightly different on tip (comments - JDK-8234563, MP checks - JDK-8188764), but fundamentally the same.
• Changes to add, xchg and cmpxchg definitions in atomic_windows_x86.hpp needed to be adjusted to keep the original parameter orders (changed in JDK 14 by JDK-8234563).

Changes to os_windows_x86.cpp and os_windows_x86.hpp could be applied cleanly.

This is part of the Windows/AArch64 port.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8248817: Windows: Improving common cross-platform code

Reviewers

• Bernhard Urban-Forster (@lewurm - no project role)
• Martin Doerr (@TheRealMDoerr - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk11u-dev pull/300/head:pull/300
$ git checkout pull/300

Update a local copy of the PR:
$ git checkout pull/300
$ git pull https://git.openjdk.java.net/jdk11u-dev pull/300/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 300

View PR using the GUI difftool:
$ git pr show -t 300

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk11u-dev/pull/300.diff

[bridgekeeper]

👋 Welcome back rnkovacs! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 00: Full (02a7ac07)

[lewurm]

Looks good to me (but I'm not a formal reviewer).

[theRealAph]

Is it truly necessary to make such extensive changes to x86 code? I can understand why it's necessary to do such refactoring in head, but can't Windows x86 be mostly left alone, with Windows AArch64 added?

[TheRealMDoerr]

Changing so much x86 code in an Windows aarch64 preparation change is not so nice, but it's better than integrating half changes IMHO. Looks good and all tests are green. Good work!

[openjdk]

@rnkovacs This change now passes all automated pre-integration checks.

After integration, the commit message for the final commit will be:

8248817: Windows: Improving common cross-platform code

Reviewed-by: burban, mdoerr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 144 new commits pushed to the master branch:

• f12af7e: 8266182: Automate manual steps listed in the test jdk/sun/security/pkcs12/ParamsTest.java
• 28dec4f: 8223139: Rename mandatory policy-do routines.
• e1cbfa5: 8248187: [TESTBUG] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java fails with String is not properly drawn
• 6a784d2: 8143021: [TEST_BUG] Test javax/swing/JColorChooser/Test6541987.java fails
• 09ad2c0: 8256152: tests fail because of ambiguous method resolution
• 2990ff0: 8211171: move JarUtils to top-level testlibrary
• f7a75de: 8265524: Upgrading JSZip from v3.2.2 to v3.6.0
• 9f8c13c: 8233569: [TESTBUG] JTextComponent test bug6361367.java fails on macos
• a6ee356: 8234823: java/net/Socket/Timeouts.java testcase testTimedConnect2() fails on Windows 10
• 23c3845: 8229935: [TEST_BUG]: bug8132119.java inconsistently positions text
• ... and 134 more: https://git.openjdk.java.net/jdk11u-dev/compare/63fc945c1d4cdc893d89796804acfe0ce9341860...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@theRealAph, @TheRealMDoerr) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[theRealAph]

Changing so much x86 code in an Windows aarch64 preparation change is not so nice, but it's better than integrating half changes IMHO.

Understood, but one of the main reasons new ports are easily accepted into maintenance releases of OpenJDK is that they are pure additions, so there's little churn to existing code. Backports should be minimal, in order to minimize that churn, and I don't believe this one is.

[RealCLanger]

I think technically this one is reviewed but maintainers now need to take the decision whether to allow this or reject as being to much of churn. I suggest you add the fix request data to JBS and we will then take a decision.

[theRealAph]

I think technically this one is reviewed but maintainers now need to take the decision whether to allow this or reject as being to much of churn. I suggest you add the fix request data to JBS and we will then take a decision.

It's not technically reviewed: even if two people approve it, objections must be addressed.

I am still of the belief that the AArch64 code can be integrated without touching the x86 atomics. If I had a WIndows AArch64 system and enough time to figure out how to build and debug this stuff I'd do it myself, just to prove the point.

Hint: put the common atomic stuff in a separate place. Call it from the AArch64 code, but do not touch the x86 code.

[RealCLanger]

I think technically this one is reviewed but maintainers now need to take the decision whether to allow this or reject as being to much of churn. I suggest you add the fix request data to JBS and we will then take a decision.

It's not technically reviewed: even if two people approve it, objections must be addressed.

I am still of the belief that the AArch64 code can be integrated without touching the x86 atomics. If I had a WIndows AArch64 system and enough time to figure out how to build and debug this stuff I'd do it myself, just to prove the point.

Hint: put the common atomic stuff in a separate place. Call it from the AArch64 code, but do not touch the x86 code.

OK, I somehow overread the technical suggestion to try to find a way to do the changes only in the aarch64 code and leaving x86 alone. So, yes, if that would be possible it would probably be a more acceptable way of doing this backport.

[lewurm]

By coincidence, the relevant parts for the Windows/AArch64 backport are in #274 anyway. So I agree with Andrew, this PR with the x86 changes are not needed for the Windows/AArch64 backport.

[rnkovacs]

Sorry for the confusion - I might have only addressed this under #301:

Actually, the connection between #274 and #300 is administrative in nature (originally, refactorings of 3 different areas were reviewed under the same JBS bug), there's no real dependency.

You are both right, this patch is technically not needed for adding Windows/AArch64 support. I'm closing the PR.

[TheRealMDoerr]

Thanks! I'm glad that we don't need a partial backport.