RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]

[Johannes Bechberger]

On Wed, 4 Jun 2025 05:28:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:
>> 
>>> 279:     stop_timer();
>>> 280:     Atomic::store(&_stop_signals, true);
>>> 281:     while (Atomic::load_acquire(&_active_signal_handlers) > 0) {
>> 
>> There can be a race when `handle_timer_signal` has already passed `_stop_signals` check but has not yet incremented `_active_signal_handlers`.
>
> Amy idea on how to fix it?

I added another _static_stop_signals field which should prevent this.

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:
>> 
>>> 470: 
>>> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
>>> 472:   assert(_instance != nullptr, "invariant");
>> 
>> There can be an arbitrary delay in async signal delivery.
>> It's unlikely, but not impossible for `_instance` to be deleted by the time signal handler is called. There should be a better way to synchronize with JFR shutdown.
>
> Any ideas? Or is it something for a later PR?

I added another `_static_stop_signals` field which should prevent this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125756115
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125755428