Architecturally the ARMv8 spec says that it is not multi-copy-atomic, but I believe currently that all implementations ARE multi-copy-atomic.
The current aarch64 port does not define CPU_NOT_MULTIPLE_COPY_ATOMIC, so it could fail on future hardware.
The fix is NOT to require all aarch64 hardware to unnecessarily pay the price for some future HW, but to change CPU_NOT_MULTIPLE_COPY_ATOMIC and/or support_IRIW_for_not_multiple_copy_atomic_cpu to be dynamically set in VM_Version::get_processor_features().
[I really don't want someone in the future to define CPU_NOT_MULTIPLE_COPY_ATOMIC in a panic for all aarch64 chips!]
e.g. globalDefintions.hpp can define support_IRIW_for_not_multiple_copy_atomic_cpu to be a constant in the non-aarch64 case , otherwise it's defined as a variable in global_definitions_aarch64.hpp.
I think some discussion about this issue should be in aarch64 port somewhere, perhaps vm_version_aarch64.cpp.
The current aarch64 port does not define CPU_NOT_MULTIPLE_COPY_ATOMIC, so it could fail on future hardware.
The fix is NOT to require all aarch64 hardware to unnecessarily pay the price for some future HW, but to change CPU_NOT_MULTIPLE_COPY_ATOMIC and/or support_IRIW_for_not_multiple_copy_atomic_cpu to be dynamically set in VM_Version::get_processor_features().
[I really don't want someone in the future to define CPU_NOT_MULTIPLE_COPY_ATOMIC in a panic for all aarch64 chips!]
e.g. globalDefintions.hpp can define support_IRIW_for_not_multiple_copy_atomic_cpu to be a constant in the non-aarch64 case , otherwise it's defined as a variable in global_definitions_aarch64.hpp.
I think some discussion about this issue should be in aarch64 port somewhere, perhaps vm_version_aarch64.cpp.
- relates to
-
JDK-8229422 Taskqueue: Outdated selection of weak memory model platforms
- Resolved