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

[Y. Srinivas Ramakrishna]

On Tue, 14 Oct 2025 23:03:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have t
 his information passed through function calls, now do so.
>
> 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

@earthling-amzn : is it possible to add the stack retrace and the test that elicited the assertion failure to the ticket as an archival forensic trail?

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

PR Comment: https://git.openjdk.org/jdk/pull/27703#issuecomment-3417455849