RFR: Add generations to freeset [v8]

[Y. Srinivas Ramakrishna]

On Thu, 20 Apr 2023 01:55:47 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 63:
> 
>> 61: 
>> 62: inline bool ShenandoahFreeSet::in_mutator_set(size_t idx) const {
>> 63:   bool is_mutator_free = _mutator_free_bitmap.at(idx);
> 
> Should line 63 go after the assert on the next line 64?

Also, it sounds like, in the general case, the assertion check `idx < _max` should apply also to the `probe_` version above? I agree that the other assertion below at line 66 may not apply there.

> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 537:
> 
>> 535:       remove_from_mutator_set(idx);
>> 536:       assert(!in_collector_set(idx) && !in_old_collector_set(idx), "Region cannot be in multiple free sets");
>> 537:       adjust_mutator_bounds_if_touched(idx);
> 
> Would it be too expensive if `remove_from_mutator_set()` and `add_to_mutator_set()` were to always adjust the bounds if needed (i.e. we traffick an extremal element into or out of the set). Adjustments at additions are of course much less expensive. Then, the interval end-points would always stay faithful to membership index extrema, establishing a good invariant.
> 
> Is the concern that the adjustments necessitated when removing elements might be  too expensive to do at each removal (addition is no problem).

(Similarly at other `adjust_bounds_` methods and their uses below.)

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

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