RFR: 8369068: GenShen: Generations still aren't reconciled assertion failure [v2]

[William Kemper]

On Wed, 22 Oct 2025 01:05:28 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Remove _gc_generation from ShenandoahHeap
>>  - Little cleanup, remove one active generation usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>>  - Fix build
>>  - Use existing _generation field instead of Heap::_gc_generation where possible
>>  - Only shenandoah vm operations participate in active/gc generation scheme
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 851:
> 
>> 849:     }
>> 850: 
>> 851:     if (!_generation->is_global()) {
> 
> Is this ever `_generation->is_old()` ? I am guessing this is either global or young? I am guessing for the case of update_refs for a mixed collection we still pass in the `young` gen here?
> 
> It might be a good idea wherever we have a `_generation` field member in a class to indicate what it represents. In most cases, it's probably clear that it represents the generation subject to collection in that cycle. But for mixed collection sets, what does the `_generation` field represent?

I changed this to check if `_generation->is_young` because it will never be old here and this is more direct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453545886