-
Bug
-
Resolution: Fixed
-
P2
-
11, 12, 13
-
b14
-
ppc
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8222587 | 12u-cpu | Volker Simonis | P2 | Resolved | Fixed | master |
JDK-8221841 | 12.0.2 | Volker Simonis | P2 | Closed | Fixed | b03 |
JDK-8221839 | 11.0.4 | Volker Simonis | P2 | Resolved | Fixed | b01 |
The C1 generated code for comparing two oops erroneously emits a 32-bit instead of an 64-bit compare instruction. Because oops are only compared for equality/inequality, this bug only becomes manifests for oops which are equal in their 32 least-significant bits but unequal otherwise. This means the two oops have to be exactly 4GB apart from each other in the heap or their 32 least significant bits have to be zero when compared to 'null'.
This makes the occurrence of this bug extremely unlikely, but when it happens, the consequences are usually a semantically wrong program execution and not a crash, which makes it very hard to detect.
This makes the occurrence of this bug extremely unlikely, but when it happens, the consequences are usually a semantically wrong program execution and not a crash, which makes it very hard to detect.
- backported by
-
JDK-8221839 [ppc64] Wrong oop compare in C1-generated code
-
- Resolved
-
-
JDK-8222587 [ppc64] Wrong oop compare in C1-generated code
-
- Resolved
-
-
JDK-8221841 [ppc64] Wrong oop compare in C1-generated code
-
- Closed
-
- relates to
-
JDK-8233019 java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit
-
- Resolved
-
-
JDK-8221483 TestOopCmp.java fails due to "Multiple garbage collectors selected"
-
- Resolved
-