RFR: 8352588: GenShen: Enabling JFR asserts when getting GCId [v6]

[Xiaolong Peng]

On Mon, 24 Mar 2025 22:27:45 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> ### Root cause
>> Shenandoah has its own way to generate gc id([link](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L234), [link](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahController.hpp#L43)), but when it runs a specific GC cycle, it still use the default GCIdMark([link](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp#L389)) to generate a gc id and set it to NamedThread::_gc_id. Once the specific GC cycle finishes, the NamedThread::_gc_id is restored to the original value which is `undefined`, which causes the asserts when Enabling JFR, in release build it should cause invalid GC id in some of JFR events.
>> 
>> ### Solution
>> it is confusing that Shenandoah generates its own gc id but not use it for GC logging and JFR, the solution is fairly simple, the control thread just need inject gc id with GCIdMark(gc_id) it generates in `ShenandoahControlThread::run_service` and `ShenandoahGenerationalControlThread::run_gc_cycle`
>> 
>> In the test, I also noticed the value of gc_id generated by Shenandoah control thread starts from 1, which is different from the default behavior of GCIdMark which generates id starting from 0, this PR will also fix it.  
>> 
>> ### Test
>> - [x] TEST=gc/shenandoah/TestWithLogLevel.java TEST_VM_OPTS="-XX:StartFlightRecording"
>> - [x] TEST=hotspot_gc_shenandoah
>> - [x] GHA
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ShenandoahController::_gc_count related refactor

Thanks for the reviews and suggestions!

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

PR Comment: https://git.openjdk.org/jdk/pull/24166#issuecomment-2752786931