-
Enhancement
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
b20
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8245372 | 14u-cpu | Aleksey Shipilev | P4 | Resolved | Fixed | master |
JDK-8244754 | 14.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b06 |
This poses problems for JDK-8243291. Consider JDK-8243291 applied. Then consider a region that allocates TLAB after final-mark. That TLAB would be past URWM, and so would not be walked by update-refs code, so it does not need to be retired. But then we allocate GCLAB into the same region and *move* URWM. Then GC update-refs code comes and walks this mess, discovers TLAB is not retired, boom, heap is not parsable, GC crash.
Since ShenandoahAllowMixedAllocs is for allocating GC stuff when evac reserve is depleted, when there are no free regions to steal from mutator view -- that is, the last-ditch attempt -- we might as well get rid of it.
Since ShenandoahAllowMixedAllocs is for allocating GC stuff when evac reserve is depleted, when there are no free regions to steal from mutator view -- that is, the last-ditch attempt -- we might as well get rid of it.
- backported by
-
JDK-8244754 Shenandoah: ditch ShenandoahAllowMixedAllocs
-
- Resolved
-
-
JDK-8245372 Shenandoah: ditch ShenandoahAllowMixedAllocs
-
- Resolved
-
- blocks
-
JDK-8243291 Shenandoah: no need to retire TLABs at Init Update Refs
-
- Resolved
-