RFR (S) 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation
Aleksey Shipilev
shade at redhat.com
Mon Mar 23 12:04:09 UTC 2020
On 3/19/20 1:21 PM, Aleksey Shipilev wrote:
> RFE:
> https://bugs.openjdk.java.net/browse/JDK-8241139
>
> Was following up on why JLinkTest fails with Shenandoah. Figured out the dynamic work distribution
> in mark-compact leaves alive regions in the middle of the heap. It is a generic problem with current
> mark-compact implementation, as which regions get into each worker slice is time-dependent.
>
> Consider the worst case scenario: two workers would have their slices interleaved, once slice is
> fully alive, and other is fully dead. In the end, mark-compact would finish with the same
> interleaved heap. A humongous allocation then fails. We need to plan the parallel sliding more
> accurately. See the code comments about what new plan does.
>
> Webrev:
> https://cr.openjdk.java.net/~shade/8241139/webrev.01/
>
> Testing: hotspot_gc_shenandoah; known-failing test; tier{1,2,3} (passed with previous version,
> running with new version now); eyeballing shenandoah-visualizer
Found the issue about distributing the tail: we cannot blindly do round-robin selection after every
worker is full, because that unbalances the work again! So ditched that part for:
607 if (old_wid == wid) {
608 // Circled back to the same worker? This means liveness data was
609 // miscalculated. Bump the live_per_worker limit so that
610 // everyone gets the piece of the leftover work.
611 live_per_worker += ShenandoahHeapRegion::region_size_words();
612 }
Full webrev:
https://cr.openjdk.java.net/~shade/8241139/webrev.02/
Testing: hotspot_gc_shenandoah {fastdebug,release}; tier{1,2,3} in progress
--
Thanks,
-Aleksey
More information about the hotspot-gc-dev
mailing list