RFR: Add generations to freeset [v8]

[Kelvin Nilsen]

On Thu, 20 Apr 2023 19:45:57 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 207 commits:
>> 
>>  - Merge remote-tracking branch 'origin' into add-generations-to-freeset
>>  - Respond to reviewer feedback
>>    
>>    Various improvements suggested by reviewers.  Mostly improved comments
>>    and some minor refactoring.
>>  - Add TODO comment for exapnsion of old-gen
>>  - Remove debug instrumentation
>>  - Merge master
>>  - Fix calculation of minimum fill size
>>    
>>    We were incorrectly using byte size rather than word size.
>>  - Fix error in ShenandoahFreeSet usage accounting
>>    
>>    We were incorrectly increasing used for plab padding.  That is
>>    old_collector memory and should not affect mutator usage.  This commit
>>    also includes some refactoring, additional assertions, and additional
>>    verification of consistent free-space accounting.
>>  - Fix typo in a comment
>>  - Fix white space
>>  - Merge remote-tracking branch 'GitFarmBranch/add-generations-to-freeset' into add-generations-to-freeset
>>  - ... and 197 more: https://git.openjdk.org/shenandoah/compare/016bf071...7319eeeb
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1016:
> 
>> 1014:   }
>> 1015:   reserve_regions(young_reserve, old_reserve);
>> 1016:   recompute_bounds();
> 
> If the `reserve_regions()` case is the only one where `recompute_bounds()` is called to batch the adjustments following mass movement and reshuffling of free regions into the three types of free sets, then what might work better (cf my previous comment about doing interval end-point adjustments incrementally whenever a set loses or receives a member rather than first add/remove one member and then do an `adjust_bounds_if_touched()`) would be to here have special versions of `add_` and `remove_` which affect the membership change but leave the intervals unchanged (as you do now), but only in the case of these mass adjustments of membership during a rebuild, then do a single sweep to set up the interval extrema at the end of the rebuild.

What you suggest might be slightly more efficient, but the code is probably cleaner if we just remove "recompute_bounds()" and compute the bounds incrementally as part of the rebuild() and reserve() process.  This happens only twice per GC cycle (at start of evac, and after update-refs).  In the next revision of this PR, I will offer the "simplified" API.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/250#discussion_r1174005402