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

Xiaolong Peng xpeng at openjdk.org
Mon Mar 24 23:41:11 UTC 2025


On Mon, 24 Mar 2025 23:14:36 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> > 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.
> 
> This would be by design and, as you discovered, was because a suitable GCIdMark scope was missing which would have supplied the correct ID. It is important that the JFR event issues from the intended scope for the corresponding ID for which the metrics/event are being generated. In particular, if there are multiple concurrent GC ID's in progress, with a common pool of worker threads that multiplex this work, any appropriate event metrics should be correctly attributed to the right ID in question.
> 
> I am making general comments here without knowledge of the specific details, sorry! :-)

Thank you @ysramakrishna for reviewing the PR, appreciate it! 

Yes, it is a simple bug related to the GCIdMark scope,  so the fix is to make sure GCIdMark scope is correct. For common pool of worker threads, each thread should copy the gc_id to local with the constructor GCIdMark(gc_id), there some existing examples doing this in hotspot, e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/workerThread.cpp#L68

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

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


More information about the shenandoah-dev mailing list