Skip to content
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

8253464: ARM32 Zero: atomic_copy64 is incorrect, breaking volatile stores #299

Closed

Conversation

@shipilev
Copy link
Contributor

@shipilev shipilev commented Sep 22, 2020

There is a regression introduced by addition of ARMv7-specific block by JDK-8211387. It readily manifests as crash during jcstress initialization, and investigation points at broken volatile stores. Reverting JDK-8211387 from head JDK makes ARM32 start and run jcstress.

The underlying reason seems to be the half-done atomic_copy64: it does the load with exclusive load, but then defers to the C++ store. Somewhere during handing over the value from the asm load to C++ store and/or C++ store itself, we garble the value. The way out is to implement the whole thing in asm.

Also see StubGenerator::generate_atomic_load_long and StubGenerator::generate_atomic_store_long in stubGenerator_arm.cpp, that do roughly the same thing and were the basis for this implementation.

Attention @theRealAph, @bulasevich.

Testing:

  • ARM32 Linux zero release jcstress run

Progress

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

Issue

  • JDK-8253464: ARM32 Zero: atomic_copy64 is incorrect, breaking volatile stores

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/299/head:pull/299
$ git checkout pull/299

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 22, 2020

👋 Welcome back shade! 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.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Sep 22, 2020

@shipilev The following label will be automatically applied to this pull request: hotspot-runtime.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label (add|remove) "label" command.

Loading

@openjdk openjdk bot added the rfr label Sep 22, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 22, 2020

Webrevs

Loading

uint32_t flag_w;
asm volatile ("ldrexd %[tmp_r], [%[src]]\n"
"clrex\n"
"1:\n"
Copy link
Contributor

@bulasevich bulasevich Sep 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change is good.
Minor remarks: I don't see reason of tmp_r(_w) naming and I'd prefer meaningful label name.

Loading

Copy link
Contributor Author

@shipilev shipilev Sep 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are five operands, I'd prefer to use symbolic names to avoid confusion.

"1:" is the local numeric label, it does not show up in (and potentially conflict with) symbol table. Meaningful names would necessarily be symbolic labels.

Does that resolve your concerns?

Loading

Copy link
Contributor

@bulasevich bulasevich Sep 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good

Loading

Copy link
Contributor

@theRealAph theRealAph left a comment

OK. It's fugly, but as far as I know there really is no better way to do it. From what I remember (it's been a while) even LDREXD wasn't guaranteed to be atomic unless accompanied by a corresponding STREXD at the same address. However, later versions of the Arm ARM do state that LDREXD is single-copy atomic, so we're good.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Sep 23, 2020

@shipilev 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 more details.

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

8253464: ARM32 Zero: atomic_copy64 is incorrect, breaking volatile stores

Reviewed-by: aph

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 19 new commits pushed to the master branch:

  • 0bc01da: 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks
  • 812b39f: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary
  • 5f1d612: 8253397: Ensure LogTag types are sorted
  • b8ea80a: 8253457: Remove unimplemented register stack functions
  • e4d0e5a: 8253516: ZGC: Remove card table functions
  • 3fe5886: 8252696: Loop unswitching may cause out of bound array load to be executed
  • 226faa5: 8253241: Update comment on java_suspend_self_with_safepoint_check()
  • bd67975: 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry
  • bddb822: 8253240: No javadoc for DecimalFormatSymbols.hashCode()
  • c68a31d: 8253499: Problem list runtime/cds/DeterministicDump.java
  • ... and 9 more: https://git.openjdk.java.net/jdk/compare/8c02bdbf13bc8258bbdb6c45fd3b3ba4c6f8971b...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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

Loading

@openjdk openjdk bot added the ready label Sep 23, 2020
@shipilev
Copy link
Contributor Author

@shipilev shipilev commented Sep 23, 2020

/integrate

Loading

@openjdk openjdk bot closed this Sep 23, 2020
@openjdk openjdk bot added integrated and removed ready labels Sep 23, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Sep 23, 2020

@shipilev Since your change was applied there have been 19 commits pushed to the master branch:

  • 0bc01da: 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks
  • 812b39f: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary
  • 5f1d612: 8253397: Ensure LogTag types are sorted
  • b8ea80a: 8253457: Remove unimplemented register stack functions
  • e4d0e5a: 8253516: ZGC: Remove card table functions
  • 3fe5886: 8252696: Loop unswitching may cause out of bound array load to be executed
  • 226faa5: 8253241: Update comment on java_suspend_self_with_safepoint_check()
  • bd67975: 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry
  • bddb822: 8253240: No javadoc for DecimalFormatSymbols.hashCode()
  • c68a31d: 8253499: Problem list runtime/cds/DeterministicDump.java
  • ... and 9 more: https://git.openjdk.java.net/jdk/compare/8c02bdbf13bc8258bbdb6c45fd3b3ba4c6f8971b...master

Your commit was automatically rebased without conflicts.

Pushed as commit c21690b.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Loading

@openjdk openjdk bot removed the rfr label Sep 23, 2020
@shipilev shipilev deleted the JDK-8253464-zero-atomic-copy64 branch Sep 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants