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

[Zhengyu Gu]

On Mon, 5 May 2025 08:11:35 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 66:
>> 
>>> 64:       }
>>> 65:     } while (Atomic::cmpxchg(&_head, elementIndex, elementIndex + 1) != elementIndex);
>>> 66:     _data[elementIndex] = element;
>> 
>> I question the correctness of the implementation. Consider following scenario:
>> T1: equeue(): after complete CAS successfully, e.g. `_head = 3, elementIndex = 2`
>> T2: dequeue(): after complete CAS successfully, `_head = 2, elementIndex = 3`
>> T2: read `_data[--elementIndex]` // _data[2] has yet set 
>> T1: write `_data[elementIndex] = element` // set _data[2] value
>
> You're right. But this seems to be an inherent problem of stacks. I'm going to use the previous lockless queue implementation for the fresh frames queue. The problem should not occur with the thread-local queues though?

Hotspot does have an implementation of [lock free stack]( https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/lockFreeStack.hpp), but you have to deal with ABA problem.

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

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