-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8282322: AArch64: Provide a means to eliminate all STREX family of instructions #8779
Conversation
👋 Welcome back dchuyko! A progress list of the required criteria for merging this PR into |
Webrevs
|
This looks reasonable enough, but I take it that this would create an OpenJDK build that would not run on AArch64 systems without LSE instructions. Might it not be a better idea to build with outline-atomics, and use them in OpenJDK? That would also solve your problem, and we wouldn't have AArch64 Linux OpenJDK binaries which don't work on all systems. Note that atomic_bsd_aarch64.hpp already does this. I'm also concerned about code rot with options like this one. atomic_linux_aarch64_lse.S would not be tested in any standard configuration. |
Forget that, we already do so with extra-cflags. |
What's the advantage of defining the new hardlse VM feature over using the existing |
There is another way to achieve what you want, which is less disruptive and I believe more useful. I just did this:
and built OpenJDK with your configury, and it achieves exactly what you want: a HotSpot that uses LSE throughout. If you, therefore, add an option to build with host compiler's atomics, just like BSD does, you'll get what you need with almost no code changes. |
That's not a bad idea either. In fact, maybe I prefer it to my own suggestion. |
Thanks a lot for the great comments. Both suggestions make sense to me. The resulting code can be driven by the compiler flags in the configuration. As I see it:
Some concerns:
|
I literally just tried this:
with the obvious and
|
This comment was marked as outdated.
This comment was marked as outdated.
Non-Linux systems don't use this stuff at all, so don't worry about it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Configure files need a bit more work.
New variant turns on using LSE atomics statically when __ARM_FEATURE_ATOMICS compiler feature is on. Prefetch is left only to non-LSE case, the kernel seems to do the same. |
/label -build |
@magicus |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me.
@dchuyko This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
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 261 new commits pushed to the
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. ➡️ To integrate this PR with the above commit message to the |
Is this dead, or... ? |
Andrew, looks like Dima will be good to go once you re-review it. |
@theRealAph I have made the latest edits as per your comments and they are pending review. |
Fine by me, but note where we are in rampdown. |
/integrate |
Going to push as commit a13af65.
Your commit was automatically rebased without conflicts. |
Andrew, thanks for taking a look. This change is now for the master, later we can also consider update releases. |
You'll have to take your chances with that. I'm not sure that it qualifies for a backport under any of the usual criteria, but we can discuss that. |
On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
--with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/8779/head:pull/8779
$ git checkout pull/8779
Update a local copy of the PR:
$ git checkout pull/8779
$ git pull https://git.openjdk.org/jdk pull/8779/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 8779
View PR using the GUI difftool:
$ git pr show -t 8779
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/8779.diff