RFR: 8352588: GenShen: Enabling JFR asserts when getting GCId [v6]
duke
duke at openjdk.org
Tue Mar 25 23:53:08 UTC 2025
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
@pengxiaolong
Your change (at version 57c43ef3417dec14a80e3f4dcab7d3666e93b033) is now ready to be sponsored by a Committer.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24166#issuecomment-2752787229
More information about the shenandoah-dev
mailing list