RFR: 8328220: GenShen: Move generational mode operational parameters out of ShenandoahHeap

[William Kemper]

On Mon, 18 Mar 2024 23:33:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> * Many fields previously defined in `ShenandoahHeap` have been moved to `ShenandoahOldGeneration`.
>> * Generational specific serviceability has been moved to `ShenandoahGenerationalHeap`.
>> * Methods for sizing the old generation have been moved to `ShenandoahGenerationalHeap`.
>> * `ShenandoahGenerationalHeap::heap()` now asserts that the generational mode is active.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 82:
> 
>> 80:                                                             size_t cur_young_garbage) const {
>> 81: 
>> 82:   auto heap = ShenandoahGenerationalHeap::heap();
> 
> I have noticed that you "auto" in a few places but not in others (any reason why it's been done selectively? :-). Is there a more desirable end-state between the possible idiomatic alternatives?

It should mostly be in places where I wanted the declared type to be `ShenandoahGenerationalHeap`.

> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 45:
> 
>> 43:   // be positive simultaneously.
>> 44:   size_t _region_surplus;
>> 45:   size_t _region_deficit;
> 
> This is an excellent comment and begs the question whether having an ssize_t to halve the representable range but carrying the surplus/deficit information as a sign would be better or worse for any reason. One variable is better than two is an argument in favor of one variable, but there may be reasons to need the greater range or problems with manipulating these where they are used?

Yes, I thought about that, but it seemed to invasive for this change.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529490128
PR Review Comment: https://git.openjdk.org/shenandoah/pull/406#discussion_r1529487674