RFR: Broaden plab region search

[William Kemper]

On Wed, 11 Jan 2023 16:33:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Recent testing revealed that old-gen heap regions were being ignored in the search to satisfy new PLAB allocation requests.  It was discovered that many of these regions are found within ranges of the ShenandoahFreeSet that are not considered to be "is_collector_free()".
> 
> This is a first step in a two-step change.  In this patch, we broaden the search for old-gen heap regions that have available memory to include regions that are not is_collector_free.  In a second step of this improvement, we intend to restructure the implementation of the ShenandoahFreeSet to better distinguish ranges of regions that hold young-gen survivors, which ranges hold old-gen, and which ranges are intended to serve as mutator allocations.
> 
> On an Extremem workload that allocates roughly 626 M/s in a total heap size of 49G with an old-gen usage of 18.7G, we saw significant improvements compared to mainline generational Shenandoah implementation:
> 
> 1. Concurrent GC passes decreased from 606 to 493 (19% improvement)
> 2. Degenerated GC passes decreased from 17 to 3 (82% improvement)
> 3. Full GCs decreased from 15 to 3 (80% improvement)
> 4. P50 latency for Customer Preparation Processing (CPP) improved from 1798 us to 1735 us (3.5%)
> 5. P100 latency for CPP improved from 25_636_285 us to 9_148_580 us (64% improvement)
> 
> Across a broad assortment of performance related CI tests, we also benefits on x86:
> 
> -74.24% extremem-phased/do_nothing_p99 p=0.00061
>   Control:      2.318s  (+/-941.25ms)         80
>   Test:         1.330s  (+/-  1.01s )         15
> 
> -15.70% extremem-phased/context_switch_count p=0.02032
>   Control:  28188.234   (+/-5868.23  )         80
>   Test:     24362.538   (+/-4260.19  )         15
> 
> -6.26% extremem-phased/do_nothing_p50 p=0.00246
>   Control:    603.203us (+/- 38.32us)         80
>   Test:       567.692us (+/- 50.34us)         15
> 
> And on aarch64:
> 
> +22.92% specjbb2015/sla_10000_jops p=0.01104
>   Control:   2607.153   (+/-799.74  )         90
>   Test:      3204.615   (+/-592.15  )         15
> 
> -5.85% extremem-phased/do_nothing_p50 p=0.00675
>   Control:    608.153us (+/- 44.52us)         90
>   Test:       574.538us (+/- 47.49us)         15

The workaround makes sense. Consider consolidating some of the log messages by reusing `ShenandoahGeneration::log_status`.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 245:

> 243:       heap->reset_old_evac_expended();
> 244:       heap->set_promoted_reserve(0);
> 245:       log_info(gc, ergo)("At end of Concurrent GC, old_available: " SIZE_FORMAT "%s out of total: " SIZE_FORMAT "%s,"

This looks a lot like the implementation of `ShenandoahGeneration::log_status` . Could consolidate these messages and reduce logging duplicate information.

src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 58:

> 56:   vmop_degenerated();
> 57:   ShenandoahHeap* heap = ShenandoahHeap::heap();
> 58:   if (heap->mode()->is_generational()) {

As above, consider using `ShenandoahGeneration::log_status`.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 179:

> 177:     size_t old_available = heap->old_generation()->available();
> 178:     size_t young_available = heap->young_generation()->available();
> 179:     log_info(gc, ergo)("At end of Full GC,  old_available: " SIZE_FORMAT "%s out of total: " SIZE_FORMAT "%s,"

Consider `ShenandoahGeneration::log_status`.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 3194:

> 3192:           } else {
> 3193:             // This object is not live so we don't verify dirty cards contained therein
> 3194:             assert(tams != nullptr, "If object is not live, ctx and tams should be non-null");

Might need to rebase these changes after integrating #197 .

-------------

Changes requested by wkemper (Committer).

PR: https://git.openjdk.org/shenandoah/pull/198