RFR: Expand old on demand [v42]

[Kelvin Nilsen]

On Wed, 10 May 2023 23:45:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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 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.

Ideal: for abreviated cycles, we introduce a new phase that processes promote-in-palce regions and does not do 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

also explain what the argument means.

> 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)

It may be the reason that if we change the affiliations asynchronousnly during eva, then we have to change the generation capacities as well.

During allocations, we ask how much is available in young and/or old, and if we add or remove regions from either generation without adjust capacities, available will be wrong.

> 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).

Would be better to use an existing coalesce and fill function rather than repeating the code here.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190481291
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190486187
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190468710
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1190465175