RFR: Move affiliation and mode out of ShenandoahGenerationalMode [v2]

[William Kemper]

On Thu, 6 Apr 2023 15:22:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `ShenandoahGenerationalMode` currently carries `ShenandoahRegionAffiliation` and `GenerationMode` definitions, plus some utility methods. This forces inclusions of `shenandoahGenerationalMode.hpp` in weird places. Plus, we expose generic helper methods in global symbol table, which might clash with symbols from other compilation units, producing linkage errors. We have the unspoken rule to prepend every Shenandoah-related global symbol with `(s|S)henandoah` to avoid this.
>> 
>> This PR moves `ShenandoahRegionAffiliation` into separate header file, includes it in few places. The usages are rewritten to use helper methods, which drastically limits the number of files we need to include new header into. It also renames it to `ShenandoahAffiliation`, since I believe there is not ambiguity here and shorter identifiers are more readable.
>> 
>> The same is done with `GenerationMode`, but PR cuts it a bit deeper by renaming it to `ShenandoahGenerationType`.
>> 
>> Most substitutions were done mechanically, but please review those with care. Thanks!
>> 
>> Testing:
>>  - [x] macos-aarch64-server-fastdebug build
>>  - [ ] macos-aarch64-server-fastdebug `hotspot_gc_shenandoah` (some pre-existing failures)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero builds

src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 93:

> 91:   ShenandoahSharedFlag _force_counters_update;
> 92:   GCCause::Cause       _requested_gc_cause;
> 93:   ShenandoahGenerationType       _requested_generation;

White space got a little weird here.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/246#discussion_r1160030395