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

[Markus Grönlund]

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?

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.

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

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