RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]

Markus Grönlund mgronlun at openjdk.org
Wed May 14 15:29:59 UTC 2025


On Wed, 14 May 2025 14:28:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   validate_bcp
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 292:
> 
>> 290: // Sampling a thread in state _thread_in_Java
>> 291: // involves a platform-specific thread suspend and CPU context retrieval.
>> 292: bool JfrSamplerThread::sample_java_thread(JavaThread* jt) {
> 
> Why not just send a signal and let the target do everything including creating the request? Is it because enqueueing the request might need to allocate memory? Given that the sampling frequency is in the order of milliseconds, and the TTS for the target is sub-milliseconds we would just need a pretty small buffer if anything. Or is there something else I’m missing?

There are no signals on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089213951


More information about the hotspot-jfr-dev mailing list