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

[Patricio Chilano Mateo]

On Wed, 14 May 2025 15:34:08 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> 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?
>
> Because we don't know when (or even if) a thread executing native code will return to the JVM.
> 
> Today, we have speedy delivery of samples for threads running in native, and we want to maintain this level of service, so we can't rely on them returning on their own for sample delivery. We need to get the samples sent out by the sampler thread.

Right, I meant for the sampling in java case. But I forgot there are no signal on Windows.

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

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