JDK-8243339 : AArch64: Obsolete UseBarriersForVolatile option
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2020-04-22
  • Updated: 2024-10-02
  • Resolved: 2020-05-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15 b25Fixed
Related Reports
CSR :  
JDK-8243456 - AArch64: Obsolete UseBarriersForVolatile option
Duplicate :  
JDK-8242469 - [aarch64] Remove UseBarriersForVolatile support for T88 variant 0
Duplicate :  
JDK-8241137 - AArch64: Volatile accesses are not sequentially consistent with VM option "-XX:+UseBarriersForVolatile"
Description
Running application with option "-XX:+UseBarriersForVolatile" might have memory consistent issue like that mentioned in JDK-8241137. Since "ldar/stlr" can work well stably, we'd better simply things by removing this flag and the alternative implementation for volatile memory access.

More detail discussion could be found from the two threads:
http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-March/008679.html
http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008706.html
Comments
Review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038163.html
27-05-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/fce873eab7a9 User: njian Date: 2020-05-27 07:18:18 +0000
27-05-2020
Hi, I'v created a CSR to obsolete this option in jdk15. Could you please take a look at it? Thank you!
22-05-2020
If it is okay for this code to remain exactly as-is for another release then yes you can deprecate it in 15 and mark it for obsoletion in 16 and expiration in 17. However if the code is actually currently broken such that it doesn't make sense to keep for another release then you can obsolete it immediately in15 (with justificiation in the CSR request) and mark for expiration in 16.. Whichever path you choose a CSR request is required.
22-04-2020
Got it! And thanks for your explanation! So I should make this flag DEPRECATED firstly. And before doing that, I need to have a CSR request for it, right?
22-04-2020
Any change to a product flag requires a CSR request. You cannot remove its use (obsoletion) and deprecate it at the same time as they are two different things. From arguments.cpp * DEPRECATED: An option that is supported, but a warning is printed to let the user know that * support may be removed in the future. Both regular and aliased options may be * deprecated. * * Add a deprecation warning for an option (or alias) by adding an entry in the * "special_jvm_flags" table and setting the "deprecated_in" field. * Often an option "deprecated" in one major release will * be made "obsolete" in the next. In this case the entry should also have its * "obsolete_in" field set. * * OBSOLETE: An option that has been removed (and deleted from globals.hpp), but is still accepted * on the command line. A warning is printed to let the user know that option might not * be accepted in the future. * * Add an obsolete warning for an option by adding an entry in the "special_jvm_flags" * table and setting the "obsolete_in" field. * * EXPIRED: A deprecated or obsolete option that has an "accept_until" version less than or equal * to the current JDK version. The system will flatly refuse to admit the existence of * the flag. This allows a flag to die automatically over JDK releases.
22-04-2020
OK. So I will firstly remove its usage in the compiler, and deprecate it by reporting warning at startup. So does it still need a CSR request?
22-04-2020
Please note that removing a product flag requires a CSR request. Normal process is to deprecate the flag with future obsoletion and then eventual removal. If the flag is already broken then immediate obsoletion can be justified.
22-04-2020