RFR: 8352251: Implement Cooperative JFR Sampling [v15]

[Amit Kumar]

On Wed, 30 Apr 2025 17:02:12 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Configuration and test for jdk.SafepointLatency event
>
> The issue is that the CPU context can be retrieved here after the safepoint poll has been tested. That is causing a race, because a sample would be taken for an fp that is about to pop, breaking the invariant of the sampling mechanism.
> 
> It is only for some sensitive interpreter positions that we need to inspect the correct fp (the sender's fp), to avoid this race.
> 
> On x64, we signal that by preemptively moving rbp, first to update the CPU context and then by explicitly setting the sender_java_fp field in the LJF.
> 
> With your suggestion, we would always prioritize the sender fp (because it is always available), which is unnecessary and incorrect (biased), except for where we are about to pop an interpreter frame (but we can't decide when that is the case).
> 
> For testing, you will need to run some longer stress tests to see the effect of a racy sampling attempt.
> 
> To provoke taking more samples, you can decrease the sampling interval of JFR by setting the following in default.jfc and / or profile.jfc:
> 
> `diff --git a/src/jdk.jfr/share/conf/jfr/profile.jfc b/src/jdk.jfr/share/conf/jfr/profile.jfc
> index 4c9f4b4f8ec..75f8d75c580 100644
> --- a/src/jdk.jfr/share/conf/jfr/profile.jfc
> +++ b/src/jdk.jfr/share/conf/jfr/profile.jfc
> @@ -198,12 +198,12 @@
> 
>      <event name="jdk.ExecutionSample">
>        <setting name="enabled" control="method-sampling-enabled">true</setting>
> -      <setting name="period" control="method-sampling-java-interval">10 ms</setting>
> +      <setting name="period" control="method-sampling-java-interval">1 ms</setting>
>      </event>
> 
>      <event name="jdk.NativeMethodSample">
>        <setting name="enabled" control="method-sampling-enabled">true</setting>
> -      <setting name="period" control="method-sampling-native-interval">20 ms</setting>
> +      <setting name="period" control="method-sampling-native-interval">1 ms</setting>
>      </event>
> 
>      <event name="jdk.SafepointLatency">`
>      
>  Try running some longer stress test or benchmark, passing:
>  
>  `-XX:StartFlightRecording:settings=profile.jfc`

Hi @mgronlun , 
Is it possible to get head stream changes in this PR, if there is no objection from other architecture? 
 It would be good to have changes from https://github.com/openjdk/jdk/pull/23660 to implement the build-fix for s390x. 
Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/24296#issuecomment-2849857901