-
Bug
-
Resolution: Fixed
-
P3
-
8, 11, 13
-
b24
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8225980 | 14 | Roland Westrelin | P3 | Resolved | Fixed | team |
| JDK-8244585 | 11.0.9-oracle | Roland Westrelin | P3 | Resolved | Fixed | b01 |
| JDK-8227141 | 11.0.5 | Roland Westrelin | P3 | Resolved | Fixed | b01 |
| JDK-8228771 | openjdk8u232 | Roland Westrelin | P3 | Resolved | Fixed | master |
With Shenandoah, we have a prototype where, rather than using an extra header field for the forwarding pointer, we use the mark word. When the shenandoah barrier is applied to an oop, the oop is first checked to be in cset which is done by converting the oop to an integer and extracting some of the bits of the address and then, if that test fails, the forwarding pointer is loaded by masking off some bits in the mark word. We're seeing a case where, in compiled code, the in cset test and the mark word load for the same oop use 2 different loads, i.e. the load of the field/array element is duplicated, it is reloaded between the in cset test and loading of the forwarding pointer.
- backported by
-
JDK-8225980 Matcher can cause oop field/array element to be reloaded
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- blocks
-
JDK-8224584 Shenandoah: Eliminate forwarding pointer word
-
- Resolved
-