RFR: Expand old on demand [v42]

[Kelvin Nilsen]

On Mon, 8 May 2023 18:41:49 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR describes several proposed changes to dynamically adjust the sizes of old-gen and young-gen.  In general, the objective is to keep old-gen as small as possible so that there is an abundance of memory available for the young-gen allocation runway.
>> 
>> This PR now passes all GHA pre-integration tests and other internal CI tests.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 104:

> 102: 
> 103: // Returns bytes of old-gen memory consumed by selected aged regions
> 104: size_t ShenandoahHeuristics::select_aged_regions(size_t old_available, size_t num_regions, bool preselected_regions[]) {

should probably call this preslected_region_candidates[]

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 222:

> 220:   }
> 221:   heap->set_pad_for_promote_in_place(promote_in_place_pad);
> 222:   heap->set_promotion_potential(promo_potential);

An issue: if we're skipping aging cycles, this is overly conservative.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 285:

> 283:         bool is_candidate;
> 284:         // This is our candidate for later consideration.
> 285:         if (is_generational && collection_set->is_preselected(i)) {

Can we hoist the testfor is_generational() so we don't ahve to repeat it so many times.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 342:

> 340:     }
> 341:   }
> 342:   heap->reserve_promotable_humongous_regions(humongous_regions_promoted);

would be nice to eliminate this, and do all usage accounting at time regions are re-affiliated (promoted in place).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 362:

> 360:   size_t immediate_percent = (total_garbage == 0) ? 0 : (immediate_garbage * 100 / total_garbage);
> 361:   collection_set->set_immediate_trash(immediate_garbage);
> 362: 

If we could introduce a new phase to do promote-in-place (indepedent of evacuation phase), then we could avoid some redundancy.  What's not implemented currently is that if the only reason we did evacuation was for promote in place, we SHOULD not have to update refs.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 176:

> 174:   virtual void initialize();
> 175: 
> 176:   virtual size_t evac_slack(size_t region_to_be_recycled);

should be regions_to_be_recycled

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 933:

> 931: }
> 932: 
> 933: void ShenandoahHeapRegion::set_affiliation(ShenandoahAffiliation new_affiliation, bool defer_affiliated_region_count_updates) {

Let's think about whether we need this defer_affiliated_region_count_updates variable.

(would be cleaner to not have this)

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 1065:

> 1063:     heap->set_promoted_reserve(promo_reserve);
> 1064: 
> 1065:     // TODO: adjust bounds in the free set

Remove this comment: the bounds are adjusted already.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 1073:

> 1071:   heap->card_scan()->reset_object_range(bottom(), end());
> 1072:   heap->card_scan()->mark_range_as_dirty(bottom(), top() - bottom());
> 1073: 

We could defer this c&f until we start the next old cycle.  The only problem is that when we do the next marking cycle, it only c&fs the regions that were in the mixed-evac candidate set.  (so an alternative approach would be to tally these up).

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190472804
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190471315
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190473313
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190479134
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190480783
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190486096
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190467176
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190462276
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190464870