RFR: Add generations to freeset [v8]

[Y. Srinivas Ramakrishna]

On Wed, 19 Apr 2023 15:27:57 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> ShenandoahFreeSet has not yet been modified to deal efficiently with the combination of old-gen and young-gen collection set reserves.  This PR makes changes so that we can distinguish between collector_is_free, old_collector_is_free, and mutator_is_free.  Further, it endeavors to keep each set of free regions tightly packed, so the range of regions representing each set is small.
>> 
>> In its current form, this no longer fails existing regression tests (except for known problems that are being addressed independently)
>
> 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

Another couple of comments.

Will finish review of remaining detailed stuff in the  free set dot cpp in next round.

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.

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

PR Review: https://git.openjdk.org/shenandoah/pull/250#pullrequestreview-1394629591
PR Review Comment: https://git.openjdk.org/shenandoah/pull/250#discussion_r1173021284