-
Bug
-
Resolution: Fixed
-
P3
-
8, 8-shenandoah, 11, 11-shenandoah, 12, 13
-
b14
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8222600 | 12u-cpu | Roman Kennke | P3 | Resolved | Fixed | master |
JDK-8222053 | 12.0.2 | Roman Kennke | P3 | Resolved | Fixed | b03 |
JDK-8226499 | 11.0.5-oracle | Roman Kennke | P3 | Resolved | Fixed | b02 |
JDK-8221829 | 11.0.4 | Roman Kennke | P3 | Resolved | Fixed | b01 |
A user reported misbehaving off-heap access. It looks like a C2 compilation failure that seems to only trigger with Shenandoah:
https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-March/009060.html
Eg with G1 generates this assembly for swapping two array elements:
mov (%r8),%r9d
mov (%r10),%r11d
mov %r9d,(%r10)
mov %r11d,(%r8)
While with Shenandoah we get this:
mov (%r9),%ecx
mov %ecx,(%r10,%r11,1)
mov %ecx,(%r9)
I.e. the two loads seem to have been wrongly coalesced into one.
Even though that is only triggered by Shenandoah, it seems to be a legit and generic C2 problem.
https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-March/009060.html
Eg with G1 generates this assembly for swapping two array elements:
mov (%r8),%r9d
mov (%r10),%r11d
mov %r9d,(%r10)
mov %r11d,(%r8)
While with Shenandoah we get this:
mov (%r9),%ecx
mov %ecx,(%r10,%r11,1)
mov %ecx,(%r9)
I.e. the two loads seem to have been wrongly coalesced into one.
Even though that is only triggered by Shenandoah, it seems to be a legit and generic C2 problem.
- backported by
-
JDK-8221829 C2 Compilation failure when accessing off-heap memory using Unsafe
- Resolved
-
JDK-8222053 C2 Compilation failure when accessing off-heap memory using Unsafe
- Resolved
-
JDK-8222600 C2 Compilation failure when accessing off-heap memory using Unsafe
- Resolved
-
JDK-8226499 C2 Compilation failure when accessing off-heap memory using Unsafe
- Resolved
- relates to
-
JDK-8162101 C2: Handle "wide" aliases for unsafe accesses
- Resolved