RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing

[Erik Gahlin]

On Fri, 23 May 2025 13:59:29 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp line 67:
>> 
>>> 65: 
>>> 66: bool JfrTraceIdEpoch::is_synchronizing() {
>>> 67:   return Atomic::load_acquire(&_synchronizing);
>> 
>> This suggests the writes to `_synchronizing` should be releases. One might think `OrderAccess::fence`-s in  `{begin|end}_epoch_shift` and do it, but at least in `begin_epoch_shift`, the fence is misplaced, should be "ops; fence(); releasing-store". Maybe you want to just `Atomic::release_store_fence(&_synchronizing, ...)` them instead.
>
> JfrTraceIdEpoch::is_synchronizing() is a remnant from the old days when we attempted to force CompilerThreads running in native into the correct epoch.
> 
> It is unused and can be deleted.

I created a separate issue for removing the is_synchronizing() method and the associated field. It can be fixed after this JEP is integrated. https://bugs.openjdk.org/browse/JDK-8357671

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2105290067