-
Bug
-
Resolution: Fixed
-
P2
-
11, 13, 14
-
b13
GenericTaskQueue<E, F, N>::pop_global currently uses "defined SPARC || defined IA32 || defined AMD64" to select platforms which are multi-copy-atomic and hence don't require a memory fence.
This selection was introduced by JDK-8012144 (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/cd25d3be91c5) and is no longer up to date.
s390 is unnecessarily treated as weak memory model platform.
Background: GenericTaskQueue uses a memory access pattern which requires a full fence between two load accesses when four threads (or more) are involved on platforms which don't enforce the property called "multi-copy atomicity" (e.g. PPC64, arm).
This was analyzed here:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html
This selection was introduced by JDK-8012144 (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/cd25d3be91c5) and is no longer up to date.
s390 is unnecessarily treated as weak memory model platform.
Background: GenericTaskQueue uses a memory access pattern which requires a full fence between two load accesses when four threads (or more) are involved on platforms which don't enforce the property called "multi-copy atomicity" (e.g. PPC64, arm).
This was analyzed here:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html
- relates to
-
JDK-8165058 aarch64: should support CPU_NOT_MULTIPLE_COPY_ATOMIC dynamically
- Closed
-
JDK-8230392 Define AArch64 as MULTI_COPY_ATOMIC
- Closed
-
JDK-8230434 [C1, C2] Release barrier for volatile field stores in constructors implemented inconsistently
- Resolved