RFR: 8337789: JEP 509: JFR CPU-Time Profiling (Experimental) [v47]

[Johannes Bechberger]

On Mon, 12 May 2025 18:09:37 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify local trace stack
>
> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 322:
> 
>> 320:   bool acquire_cpu_time_jfr_out_of_safepoint_lock();
>> 321:   void acquire_cpu_time_jfr_dequeue_lock();
>> 322:   void release_cpu_time_jfr_queue_lock();
> 
> Why not just define cpu_time_jfr_lock()/cpu_time_jfr_unlock()? It’s kind of confusing reading the methods where these are used since we need to remember they are the same lock.

They are using the same lock, but the lock has four different states:
- enqueue: for enqueuing a new trace
- out of safepoint: for storing into JFR from the sampler thread
- dequeue: for dequeuing and storing into JFR at a safepoint
- unlocked: the base state

It is only possible to move between the base state and another state, but not between base states. This ensures that the three operations don't overlap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r2091150117