RFR: Add generations to freeset [v8]

[Kelvin Nilsen]

On Fri, 21 Apr 2023 17:17:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

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

Actually, I did not remove recompute_bounds() because we currently depend on a side effect of this function, which is to decide whether to allocate old_colllector regions left-to-right or right-to-left.  I've placed a comment in the code to clarify a future TODO action.  Is it ok to leave as is for now?  (Or should I try to sort this out right now?)

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

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