-
Bug
-
Resolution: Fixed
-
P4
-
22
-
b18
-
riscv
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8317487 | 21.0.2 | Robbin Ehn | P4 | Resolved | Fixed | b02 |
JDK-8317739 | 17.0.10 | Robbin Ehn | P4 | Resolved | Fixed | b01 |
JDK-8317674 | 17.0.9 | Robbin Ehn | P4 | Resolved | Fixed | b08 |
When loading the to be exchanged narrow oop with load reserved word it automatically sign extends it.
The branch not equal instruction always compares the full register (64-bit), if the compare narrow oop is not sign extended it fails.
(even if the 4 byte narrow oops are identical)
We have only seen this issue with Shenandoah and gcc 10/11.
Modified tests:
FAILED: gc/shenandoah/compiler/TestReferenceCAS.java#C1
FAILED: gc/shenandoah/compiler/TestReferenceCAS.java#C1-2
FAILED: gc/shenandoah/compiler/TestReferenceCAS.java#C2
FAILED: gc/shenandoah/compiler/TestReferenceCAS.java#FULL
FAILED: gc/shenandoah/compiler/TestReferenceCAS.java#Xint
Passed: gc/shenandoah/compiler/TestReferenceCAS.java#Xint-G1
Since we fail with Xint only the issue seems to be with Unsafe_CompareAndExchangeReference.
A bigger about this is that there may be more places where we don't notice this, but can result in very unexpected behavior as any branch compare may fail.
The issue is not reproduce with gcc 12/13.
- backported by
-
JDK-8317487 RISC-V: Zero extended narrow oop passed to Atomic::cmpxchg
- Resolved
-
JDK-8317674 RISC-V: Zero extended narrow oop passed to Atomic::cmpxchg
- Resolved
-
JDK-8317739 RISC-V: Zero extended narrow oop passed to Atomic::cmpxchg
- Resolved
- blocks
-
JDK-8316186 RISC-V: Remove PlatformCmpxchg<4>
- Resolved
- links to
-
Commit openjdk/jdk17u-dev/056ba2d7
-
Commit openjdk/jdk17u/8afd87b1
-
Commit openjdk/jdk21u/9ffec67a
-
Commit openjdk/jdk/2d154fcd
-
Review openjdk/jdk17u-dev/1858
-
Review openjdk/jdk17u/381
-
Review openjdk/jdk21u/210
-
Review openjdk/jdk/15917