From amitkumar at openjdk.org  Mon May  5 04:09:46 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 5 May 2025 04:09:46 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <A4oDXgAN7HZe4UTCZ5HzZvERVg1B47pCkoXH9oO74Yw=.5dad6c6d-e82e-44a9-86b0-16bf9702fa16@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
 <A4oDXgAN7HZe4UTCZ5HzZvERVg1B47pCkoXH9oO74Yw=.5dad6c6d-e82e-44a9-86b0-16bf9702fa16@github.com>
Message-ID: <YLB3lT7GAQzBSFl55p1nYHNEhWufwD2MIQSKUZLl7M4=.afc6c71a-e23d-47ef-9ca5-5c78c1f1a217@github.com>

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

From amitkumar at openjdk.org  Mon May  5 04:14:47 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 5 May 2025 04:14:47 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
Message-ID: <2qvWWnC2j2hZ4DuQAXedEor_hAzbqE9NMK4XpNtDrHc=.969bb3cc-c8d6-40af-8249-64b2c71c1011@github.com>

On Tue, 29 Apr 2025 16:47:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Configuration and test for jdk.SafepointLatency event

I think I will just do the merge locally and create the Patch. Once all other relativization PR merges, I will pass the conflict-free patch to you.

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

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

From jbechberger at openjdk.org  Mon May  5 08:11:52 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 5 May 2025 08:11:52 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
Message-ID: <oDH6PIq8DyK5-E08FGEfUXi58jYUNab_l1sNdJgjsns=.12ae028a-c396-4cd6-9dee-632c4bf33b2f@github.com>

On Tue, 29 Apr 2025 16:47:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Configuration and test for jdk.SafepointLatency event

Is there the possibility of adding a `bias` flag to the ExecutionSample events to record when an event has a clear safepoint bias? This could mark all samples where the sampler falls back on the safepoint frame.

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

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

From mgronlun at openjdk.org  Mon May  5 08:50:35 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 08:50:35 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into 8352251
 - Configuration and test for jdk.SafepointLatency event
 - include guards
 - push back pd constants into pd code
 - Attempt to build Windows-AARCH64
 - No invariants for sender_for_interpreter_frame
 - zero
 - Merge branch 'master' into 8352251
 - Refine SamplingLatency event description
 - Update default.jfc
 - ... and 9 more: https://git.openjdk.org/jdk/compare/8511220f...e448090e

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=15
  Stats: 3381 lines in 82 files changed: 2071 ins; 960 del; 350 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Mon May  5 08:50:35 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 08:50:35 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <A4oDXgAN7HZe4UTCZ5HzZvERVg1B47pCkoXH9oO74Yw=.5dad6c6d-e82e-44a9-86b0-16bf9702fa16@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
 <A4oDXgAN7HZe4UTCZ5HzZvERVg1B47pCkoXH9oO74Yw=.5dad6c6d-e82e-44a9-86b0-16bf9702fa16@github.com>
Message-ID: <psinsTZMJRUDAu-RGOyGSTvI4Rr5rPwLdnQySpAaI8A=.7b743380-e2c8-46fb-9cf5-644e95bb96dd@github.com>

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 #23660 to implement the build-fix for s390x. Thanks

HI Amit, now the PR has been merged with master and should contain your changes.

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

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

From mgronlun at openjdk.org  Mon May  5 14:11:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 14:11:47 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <oDH6PIq8DyK5-E08FGEfUXi58jYUNab_l1sNdJgjsns=.12ae028a-c396-4cd6-9dee-632c4bf33b2f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
 <oDH6PIq8DyK5-E08FGEfUXi58jYUNab_l1sNdJgjsns=.12ae028a-c396-4cd6-9dee-632c4bf33b2f@github.com>
Message-ID: <2hhZtg0s_JR2jF21GSogLB_giDKBqFa6wwcrdGMdXJI=.c3d46749-caae-4d00-99e4-f017686c6f56@github.com>

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

> Is there the possibility of adding a `bias` flag to the ExecutionSample events to record when an event has a clear safepoint bias? This could mark all samples where the sampler falls back on the safepoint frame.

The next phase, called "Sampling Accuracy," will address how to monitor and improve on safepoint biases and failures. It might involve separate events for failure reason tracking, so I prefer to delay the decision until then.

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

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

From mdoerr at openjdk.org  Mon May  5 15:23:49 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 May 2025 15:23:49 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v14]
In-Reply-To: <AI8yB_dU6eh-m39M8qetXAJ6FfZjZMsmhwWkLB8E5sQ=.9f325915-ce3c-4d8b-90ec-5353be39a0a1@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
 <OPkPMC-4FEOAlOt1LDEC7_SP2DxBYwBvpl-W_tqYw8g=.ebdf29cf-1327-44aa-8d23-3613e12e9d39@github.com>
 <NagMYeVwxCh1uObIFLz6aYLDsdxbPsH1BM61kdQLcS8=.c35ca519-9e87-4b87-86ed-a7fbe6e7b64f@github.com>
 <AI8yB_dU6eh-m39M8qetXAJ6FfZjZMsmhwWkLB8E5sQ=.9f325915-ce3c-4d8b-90ec-5353be39a0a1@github.com>
Message-ID: <1Rvls0nhGHse5bHwtvPjQqQ9dVkXd2hPWrbKL2hv-ow=.90e4bb43-6e29-48ba-beef-c239e16953e8@github.com>

On Wed, 30 Apr 2025 13:50:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Can we let _last_sender_Java_fp be a state field that can be tested?

I still couldn't hit any failures or errors with my simple version, but I understand that it might be problematic.

I have an implementation: https://github.com/TheRealMDoerr/jdk/commit/b2f83fae262f129f864e109d7adce169e28f0c7c
Please take a look. I hope we don't need more ;-)
I'm planning to run more test when I find more time.

If `_last_sender_Java_fp` is needed on all platforms, shouldn't it be better moved to shared javaFrameAnchor.hpp and javaThread.hpp?

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

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

From mgronlun at openjdk.org  Mon May  5 17:33:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 17:33:51 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
Message-ID: <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>

On Mon, 5 May 2025 08:50:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into 8352251
>  - Configuration and test for jdk.SafepointLatency event
>  - include guards
>  - push back pd constants into pd code
>  - Attempt to build Windows-AARCH64
>  - No invariants for sender_for_interpreter_frame
>  - zero
>  - Merge branch 'master' into 8352251
>  - Refine SamplingLatency event description
>  - Update default.jfc
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/8511220f...e448090e

> > Can we let _last_sender_Java_fp be a state field that can be tested?
> 
> I still couldn't hit any failures or errors with my simple version, but I understand that it might be problematic.
> 
> I have an implementation: [TheRealMDoerr at b2f83fa](https://github.com/TheRealMDoerr/jdk/commit/b2f83fae262f129f864e109d7adce169e28f0c7c) Please take a look. I hope we don't need more ;-) I'm planning to run more test when I find more time.
> 
> If `_last_sender_Java_fp` is needed on all platforms, shouldn't it be better moved to shared javaFrameAnchor.hpp and javaThread.hpp?

That is a good reflection. I followed _last_java_FP which is defined in platform specific files. Are we not using _last_java_FP on all platforms?

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

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

From mgronlun at openjdk.org  Mon May  5 17:41:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 17:41:47 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
Message-ID: <iXJOOKJzdLZUXY57pVdYBq95EEpF2vLaDrXx_2uDDzU=.c2060924-6d29-462d-83b2-6b2aaaaace09@github.com>

On Mon, 5 May 2025 17:31:37 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > Can we let _last_sender_Java_fp be a state field that can be tested?
> 
> I still couldn't hit any failures or errors with my simple version, but I understand that it might be problematic.
> 
> I have an implementation: [TheRealMDoerr at b2f83fa](https://github.com/TheRealMDoerr/jdk/commit/b2f83fae262f129f864e109d7adce169e28f0c7c) Please take a look. I hope we don't need more ;-) I'm planning to run more test when I find more time.
> 
> If `_last_sender_Java_fp` is needed on all platforms, shouldn't it be better moved to shared javaFrameAnchor.hpp and javaThread.hpp?

I removed the strongest assertions from jfrThreadSampling.cpp compute_top_frame() and compute_sender_frame(). Still, I would expect you occasionally to crash hard in the JfrVframeStream iterator during stack walking.

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

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

From mgronlun at openjdk.org  Mon May  5 18:18:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 18:18:48 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <iXJOOKJzdLZUXY57pVdYBq95EEpF2vLaDrXx_2uDDzU=.c2060924-6d29-462d-83b2-6b2aaaaace09@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
 <iXJOOKJzdLZUXY57pVdYBq95EEpF2vLaDrXx_2uDDzU=.c2060924-6d29-462d-83b2-6b2aaaaace09@github.com>
Message-ID: <hkpWcUxi1Ve6j7BlTTJsNnkj5_p1MrKgNg6AtJrDPns=.6adf870c-7078-4c7d-a2ac-e8965fa45d2f@github.com>

On Mon, 5 May 2025 17:38:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > Can we let _last_sender_Java_fp be a state field that can be tested?
> 
> I still couldn't hit any failures or errors with my simple version, but I understand that it might be problematic.
> 
> I have an implementation: [TheRealMDoerr at b2f83fa](https://github.com/TheRealMDoerr/jdk/commit/b2f83fae262f129f864e109d7adce169e28f0c7c) Please take a look. I hope we don't need more ;-) I'm planning to run more test when I find more time.
> 
> If `_last_sender_Java_fp` is needed on all platforms, shouldn't it be better moved to shared javaFrameAnchor.hpp and javaThread.hpp?

Implementation seems to be in the correct direction, but its missing locations in TemplateInterpreterGenerator and TemplateTable. Also, i do not see any pre-emptive move of the fp, which is required for fetching a correct (non-racy) CPU context.

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

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

From mdoerr at openjdk.org  Mon May  5 19:50:49 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 May 2025 19:50:49 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
Message-ID: <uLrPXlNLJs0AiHEyg8yHFCFLnFhvP2uoZoStq6ccjHM=.c508bb91-d2e8-48b5-81f3-5e4addb43943@github.com>

On Mon, 5 May 2025 17:31:37 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Are we not using _last_java_FP on all platforms?

The field `_last_Java_fp` is only needed on platforms which don't have a Back Chain.

> Implementation seems to be in the correct direction, but its missing locations in TemplateInterpreterGenerator and TemplateTable.

Yeah, I'll look into them later when the first part is correct.

> Also, i do not see any pre-emptive move of the fp, which is required for fetching a correct (non-racy) CPU context.

Isn't this problem already solved by using the `_last_sender_Java_fp`? Why do we need both, the frame pop before the safepoint check and the _last_sender_Java_fp trick?

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

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

From mgronlun at openjdk.org  Mon May  5 20:00:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 20:00:48 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <uLrPXlNLJs0AiHEyg8yHFCFLnFhvP2uoZoStq6ccjHM=.c508bb91-d2e8-48b5-81f3-5e4addb43943@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
 <uLrPXlNLJs0AiHEyg8yHFCFLnFhvP2uoZoStq6ccjHM=.c508bb91-d2e8-48b5-81f3-5e4addb43943@github.com>
Message-ID: <aPtaEj0iKWfYFW2q56iBUjBzf1RFj7eidYG_rFMr4Sc=.e517f571-857f-46e0-b344-7cf4e5256dfd@github.com>

On Mon, 5 May 2025 19:48:35 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Isn't this problem already solved by using the `_last_sender_Java_fp`? Why do we need both, the frame pop before the safepoint check and the _last_sender_Java_fp trick?

Because the sampler fetches the CPU context for threads running in state "_thread_in_Java". Without it, you can sample after the safepoint poll test is issued, but before the frame is popped. That sampled frame will represent something now being removed, and if the sender issues another call, also overwritten.

It may help to think about how the JIT methods works - they pop their frames before issuing the method return safepoint poll test.

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

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

From mdoerr at openjdk.org  Mon May  5 20:22:49 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 May 2025 20:22:49 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <aPtaEj0iKWfYFW2q56iBUjBzf1RFj7eidYG_rFMr4Sc=.e517f571-857f-46e0-b344-7cf4e5256dfd@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
 <uLrPXlNLJs0AiHEyg8yHFCFLnFhvP2uoZoStq6ccjHM=.c508bb91-d2e8-48b5-81f3-5e4addb43943@github.com>
 <aPtaEj0iKWfYFW2q56iBUjBzf1RFj7eidYG_rFMr4Sc=.e517f571-857f-46e0-b344-7cf4e5256dfd@github.com>
Message-ID: <lF3H9gto3t60EM4-YVUaBJDgumz1t6Yctc_QJ1VY3HQ=.05ebfbce-9011-4a82-8941-63427fe69198@github.com>

On Mon, 5 May 2025 19:56:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > Isn't this problem already solved by using the `_last_sender_Java_fp`? Why do we need both, the frame pop before the safepoint check and the _last_sender_Java_fp trick?
> 
> Because the sampler fetches the CPU context for threads running in state "_thread_in_Java". Without it, you can sample after the safepoint poll test is issued, but before the frame is popped. That sampled frame will represent something now being removed, and if the sender issues another call, also overwritten.
> 
> It may help to think about how the JIT methods works - they pop their frames before issuing the method return safepoint poll test.

Ok. This makes sense. Thanks for the explanation!
Just trying to understand: What if we have the frame pop before the safepoint check like in JIT compiled code. Do we still need the `_last_sender_Java_fp` trick in this case (assuming we handle it like in the JIT compiled case and use `StackWatermarkSet::after_unwind` in `InterpreterRuntime::at_unwind`)?

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

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

From mgronlun at openjdk.org  Mon May  5 21:00:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 5 May 2025 21:00:50 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <lF3H9gto3t60EM4-YVUaBJDgumz1t6Yctc_QJ1VY3HQ=.05ebfbce-9011-4a82-8941-63427fe69198@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
 <uLrPXlNLJs0AiHEyg8yHFCFLnFhvP2uoZoStq6ccjHM=.c508bb91-d2e8-48b5-81f3-5e4addb43943@github.com>
 <aPtaEj0iKWfYFW2q56iBUjBzf1RFj7eidYG_rFMr4Sc=.e517f571-857f-46e0-b344-7cf4e5256dfd@github.com>
 <lF3H9gto3t60EM4-YVUaBJDgumz1t6Yctc_QJ1VY3HQ=.05ebfbce-9011-4a82-8941-63427fe69198@github.com>
Message-ID: <EIJF7v7NXScM1WimcLyauIzfll4Gvlp1wf79fNG6ZOg=.3466d4a4-06a3-4bcf-a156-b7024de40198@github.com>

On Mon, 5 May 2025 20:19:51 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > > Isn't this problem already solved by using the `_last_sender_Java_fp`? Why do we need both, the frame pop before the safepoint check and the _last_sender_Java_fp trick?
> > 
> > 
> > Because the sampler fetches the CPU context for threads running in state "_thread_in_Java". Without it, you can sample after the safepoint poll test is issued, but before the frame is popped. That sampled frame will represent something now being removed, and if the sender issues another call, also overwritten.
> > It may help to think about how the JIT methods works - they pop their frames before issuing the method return safepoint poll test.
> 
> Ok. This makes sense. Thanks for the explanation! Just trying to understand: What if we have the frame pop before the safepoint check like in JIT compiled code. Do we still need the `_last_sender_Java_fp` trick in this case (assuming we handle it like in the JIT compiled case and use `StackWatermarkSet::after_unwind` in `InterpreterRuntime::at_unwind`)?

Yes, because StackWaterMarkSet unwind needs the "current frame"  as a starting point (for Interpreter frames, it's using fp instead of sp). That's why the ljf is still set "normally". But we add the _last_java_sender_fp specifically for the JFR sampler at this, and a two other sites. The JFR sampler selects the ljf over the CPU context. But In this case, because of StackWatermarkSet::after_unwind, we cannot use the _last_java_fp StackWatermarkSet is using. That would sample the frame that is about to pop. We need to sample the sender that we are returning to.

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

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

From mgronlun at openjdk.org  Tue May  6 07:43:21 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 6 May 2025 07:43:21 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <EIJF7v7NXScM1WimcLyauIzfll4Gvlp1wf79fNG6ZOg=.3466d4a4-06a3-4bcf-a156-b7024de40198@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
 <uLrPXlNLJs0AiHEyg8yHFCFLnFhvP2uoZoStq6ccjHM=.c508bb91-d2e8-48b5-81f3-5e4addb43943@github.com>
 <aPtaEj0iKWfYFW2q56iBUjBzf1RFj7eidYG_rFMr4Sc=.e517f571-857f-46e0-b344-7cf4e5256dfd@github.com>
 <lF3H9gto3t60EM4-YVUaBJDgumz1t6Yctc_QJ1VY3HQ=.05ebfbce-9011-4a82-8941-63427fe69198@github.com>
 <EIJF7v7NXScM1WimcLyauIzfll4Gvlp1wf79fNG6ZOg=.3466d4a4-06a3-4bcf-a156-b7024de40198@github.com>
Message-ID: <cKggs3w55NpLgV69hAzZJj3iVhZLT29F_hveIc7S6E0=.0f5347eb-b109-4be8-a48c-ec2d77303244@github.com>

On Mon, 5 May 2025 20:57:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > > Isn't this problem already solved by using the `_last_sender_Java_fp`? Why do we need both, the frame pop before the safepoint check and the _last_sender_Java_fp trick?
> 
> > 
> 
> > Because the sampler fetches the CPU context for threads running in state "_thread_in_Java". Without it, you can sample after the safepoint poll test is issued, but before the frame is popped. That sampled frame will represent something now being removed, and if the sender issues another call, also overwritten.
> 
> > 
> 
> > It may help to think about how the JIT methods works - they pop their frames before issuing the method return safepoint poll test.
> 
> 
> 
> Ok. This makes sense. Thanks for the explanation!
> 
> Just trying to understand: What if we have the frame pop before the safepoint check like in JIT compiled code. Do we still need the `_last_sender_Java_fp` trick in this case (assuming we handle it like in the JIT compiled case and use `StackWatermarkSet::after_unwind` in `InterpreterRuntime::at_unwind`)?

Sorry Martin, I did not read your reply detailed enough. That is surely an interesting idea - I did not want to shake things too much, but now I will attempt to try it.

Could solve the trick quite naturally, as you say.

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

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

From mgronlun at openjdk.org  Tue May  6 09:44:16 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 6 May 2025 09:44:16 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <cKggs3w55NpLgV69hAzZJj3iVhZLT29F_hveIc7S6E0=.0f5347eb-b109-4be8-a48c-ec2d77303244@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <qrxaBW53CO6wj1KAiCg9N5mrPUAMwWf_7snVBj0pSXI=.e01b57df-f85a-45e8-b45e-3a0f875c2da1@github.com>
 <uLrPXlNLJs0AiHEyg8yHFCFLnFhvP2uoZoStq6ccjHM=.c508bb91-d2e8-48b5-81f3-5e4addb43943@github.com>
 <aPtaEj0iKWfYFW2q56iBUjBzf1RFj7eidYG_rFMr4Sc=.e517f571-857f-46e0-b344-7cf4e5256dfd@github.com>
 <lF3H9gto3t60EM4-YVUaBJDgumz1t6Yctc_QJ1VY3HQ=.05ebfbce-9011-4a82-8941-63427fe69198@github.com>
 <EIJF7v7NXScM1WimcLyauIzfll4Gvlp1wf79fNG6ZOg=.3466d4a4-06a3-4bcf-a156-b7024de40198@github.com>
 <cKggs3w55NpLgV69hAzZJj3iVhZLT29F_hveIc7S6E0=.0f5347eb-b109-4be8-a48c-ec2d77303244@github.com>
Message-ID: <Q3l4H01I7cdaYwXk2wvyrUtwxdbFZWkrI_Z1nXEAl4I=.36cb7a14-f82c-4aee-ad23-f2dad78a221a@github.com>

On Tue, 6 May 2025 07:40:25 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > > > Isn't this problem already solved by using the `_last_sender_Java_fp`? Why do we need both, the frame pop before the safepoint check and the _last_sender_Java_fp trick?
> > 
> > 
> > > 
> > 
> > 
> > > Because the sampler fetches the CPU context for threads running in state "_thread_in_Java". Without it, you can sample after the safepoint poll test is issued, but before the frame is popped. That sampled frame will represent something now being removed, and if the sender issues another call, also overwritten.
> > 
> > 
> > > 
> > 
> > 
> > > It may help to think about how the JIT methods works - they pop their frames before issuing the method return safepoint poll test.
> > 
> > 
> > Ok. This makes sense. Thanks for the explanation!
> > Just trying to understand: What if we have the frame pop before the safepoint check like in JIT compiled code. Do we still need the `_last_sender_Java_fp` trick in this case (assuming we handle it like in the JIT compiled case and use `StackWatermarkSet::after_unwind` in `InterpreterRuntime::at_unwind`)?
> 
> Sorry Martin, I did not read your reply detailed enough. That is surely an interesting idea - I did not want to shake things too much, but now I will attempt to try it.
> 
> Could solve the trick quite naturally, as you say.

I remember now why I designed it this way. The reason is the other part of the solution, the hook to process enqueued sample requests. As you can see, in Interpreter::unwind(), there is a check for processing sample requests, like:

JFR_ONLY(Jfr::check_and_process_sample_request(current);)

The invariant here is that the frame about to be popped could have been sampled; therefore, an ljf at this point must "cover" it for stackwalking to locate it (it must be above or equal). If we pop before testing the safepoint poll, that frame is gone (now below the saved ljf).

Comparing again with a JIT frame, to be more exact, it is not true that the compiled frame is popped before the method return poll check: Specifically, only the explicit frame size is popped before issuing the return poll test. That is, the frame's return address is still on the stack. The reason this works is because JIT frame unwind test the sp. Therefore, it is possible capture the top frame even though it has been (partially) popped. We reconstruct it in the safepoint handler using the java_thread->saved_exception_pc().

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

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

From egahlin at openjdk.org  Tue May  6 11:51:30 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 6 May 2025 11:51:30 GMT
Subject: RFR: 8356224: JFR: Default value of @Registered is ignored
Message-ID: <HMGNSIrkRPGO3AlYqyEOTPSEKCa7ZRz4Uu0_5Zemfrk=.4c1023ce-607a-4262-b179-b1f56187a679@github.com>

Could I have a review of a change that fixes an issue with the Registered annotation. For details, see bug.

Testing: tier1 + jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25063/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356224
  Stats: 147 lines in 3 files changed: 107 ins; 6 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/25063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25063/head:pull/25063

PR: https://git.openjdk.org/jdk/pull/25063

From mgronlun at openjdk.org  Tue May  6 11:51:30 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 6 May 2025 11:51:30 GMT
Subject: RFR: 8356224: JFR: Default value of @Registered is ignored
In-Reply-To: <HMGNSIrkRPGO3AlYqyEOTPSEKCa7ZRz4Uu0_5Zemfrk=.4c1023ce-607a-4262-b179-b1f56187a679@github.com>
References: <HMGNSIrkRPGO3AlYqyEOTPSEKCa7ZRz4Uu0_5Zemfrk=.4c1023ce-607a-4262-b179-b1f56187a679@github.com>
Message-ID: <mBABkI-Wn7WJx6ySuIxhTUGVN7sPMe-FjlOWLfmEnx0=.c7754521-3ddf-4bb0-8caa-af3e94e9bc2a@github.com>

On Tue, 6 May 2025 10:52:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that fixes an issue with the Registered annotation. For details, see bug.
> 
> Testing: tier1 + jdk/jdk/jfr
> 
> Thanks
> Erik

Subtle. Well spotted.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25063#pullrequestreview-2817919557

From mdoerr at openjdk.org  Tue May  6 21:16:17 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 May 2025 21:16:17 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
Message-ID: <27ga1Z__QxsqWxH7c0G7UfqiaPYJAP17thdyn_Mj6j8=.374f6033-4a81-4f32-a9b1-ebf9e72c3fbb@github.com>

On Mon, 5 May 2025 08:50:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into 8352251
>  - Configuration and test for jdk.SafepointLatency event
>  - include guards
>  - push back pd constants into pd code
>  - Attempt to build Windows-AARCH64
>  - No invariants for sender_for_interpreter_frame
>  - zero
>  - Merge branch 'master' into 8352251
>  - Refine SamplingLatency event description
>  - Update default.jfc
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/8511220f...e448090e

Ok, seems like the issue is that you still need some fields of the old top frame's interpreter state. It is still usable on PPC64 after the top frame has been popped off because the ABI allows using some space below the SP which will still contain the required state fields. Seems like other platforms don't guarantee to preserve space below SP (could probably get overwritten by a signal handler).
I think your version is not nicely implementable on platforms which don't have an FP register, but I'll take a look and think about it.

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

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

From duke at openjdk.org  Fri May  9 03:11:02 2025
From: duke at openjdk.org (duke)
Date: Fri, 9 May 2025 03:11:02 GMT
Subject: Withdrawn: 8345500: Timeout in
 jdk.jfr.api.consumer.streaming.TestJVMCrash
In-Reply-To: <UM6vAPzvHNQVGL4uDHtBKAorx5VtBC0uaus43fExDX4=.c6aad20d-5b4c-4c2f-b77f-12a10d1af990@github.com>
References: <UM6vAPzvHNQVGL4uDHtBKAorx5VtBC0uaus43fExDX4=.c6aad20d-5b4c-4c2f-b77f-12a10d1af990@github.com>
Message-ID: <VYYt5nSZl64XcVztcJug-nWTjuWIczoGaITTkNPwA9Y=.dea36dd1-a315-4b2f-b534-e092c48a6d47@github.com>

On Thu, 16 Jan 2025 19:39:01 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> In this fix we add 1 second delay after we create a process.
> 
> On macOS we seem to be creating a process so quickly, that other threads need time to see it.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23163

From mark.reinhold at oracle.com  Fri May  9 20:57:17 2025
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Fri, 9 May 2025 20:57:17 +0000
Subject: New candidate JEP: 518: JFR Cooperative Sampling
Message-ID: <20250509205716.A216F814CAF@eggemoggin.niobe.net>

https://openjdk.org/jeps/518

  Summary: Improve the stability of the JDK Flight Recorder (JFR) when
  it asynchronously samples Java thread stacks.  Achieve this by walking
  call stacks only at safepoints, while minimizing safepoint bias.

- Mark

From bulasevich at openjdk.org  Sat May 10 22:28:54 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Sat, 10 May 2025 22:28:54 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
Message-ID: <DwOW2C-Gx6mIopTamGGJf-cpy-HReicJBtBdd3z3IIs=.5c60cc4f-c4d5-4e3a-b142-8b4d4bb06f01@github.com>

On Mon, 5 May 2025 08:50:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into 8352251
>  - Configuration and test for jdk.SafepointLatency event
>  - include guards
>  - push back pd constants into pd code
>  - Attempt to build Windows-AARCH64
>  - No invariants for sender_for_interpreter_frame
>  - zero
>  - Merge branch 'master' into 8352251
>  - Refine SamplingLatency event description
>  - Update default.jfc
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/8511220f...e448090e

Hi,

Could you please incorporate a minimal change into your patch to enable the ARM32 port? With this update, the ARM32 build will compile successfully and pass the hotspot and jdk tier1 jtreg tests. The full cooperative-sampling functionality and watermark barriers aren?t implemented yet and will require additional work, but this patch provides a safe bootstrap that lets everything build and run on ARM32.

https://github.com/bulasevich/jdk/commit/9fe1aee0.patch

Thanks!

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

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

From mgronlun at openjdk.org  Sun May 11 09:03:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 11 May 2025 09:03:58 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v17]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <-tyQF9uthRml5ueHpV5JLpX2GSFXl9eK6K1AfAb7mKM=.e255e95b-6ab9-477c-b29d-1ec4b414b58c@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  8350338: the minimal arm32 support

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/e448090e..42288d36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=15-16

  Stats: 101 lines in 3 files changed: 93 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Sun May 11 09:03:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 11 May 2025 09:03:58 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v16]
In-Reply-To: <DwOW2C-Gx6mIopTamGGJf-cpy-HReicJBtBdd3z3IIs=.5c60cc4f-c4d5-4e3a-b142-8b4d4bb06f01@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <DwOW2C-Gx6mIopTamGGJf-cpy-HReicJBtBdd3z3IIs=.5c60cc4f-c4d5-4e3a-b142-8b4d4bb06f01@github.com>
Message-ID: <f2OANKEztWdvmK0sbVgqwLnAR1RVC_efwywWxPSJ0tg=.e4efbe88-d6d7-4856-a7a4-8ab950bfbdcf@github.com>

On Sat, 10 May 2025 22:26:22 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Hi,
> 
> Could you please incorporate a minimal change into your patch to enable the ARM32 port? With this update, the ARM32 build will compile successfully and pass the hotspot and jdk tier1 jtreg tests. The full cooperative-sampling functionality and watermark barriers aren?t implemented yet and will require additional work, but this patch provides a safe bootstrap that lets everything build and run on ARM32.
> 
> https://github.com/bulasevich/jdk/commit/9fe1aee0.patch
> 
> Thanks!

Applied and committed. Thanks Boris!

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

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

From mgronlun at openjdk.org  Sun May 11 09:08:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 11 May 2025 09:08:47 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v18]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <Nyt8ddTgqHH3su9r6rPjvzghzzSLeFJRzGeEWy7yp3U=.fd3bfb67-f0e2-4c9f-8175-9f1db0d340a4@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into 8352251
 - 8350338: the minimal arm32 support
 - Merge branch 'master' into 8352251
 - Configuration and test for jdk.SafepointLatency event
 - include guards
 - push back pd constants into pd code
 - Attempt to build Windows-AARCH64
 - No invariants for sender_for_interpreter_frame
 - zero
 - Merge branch 'master' into 8352251
 - ... and 11 more: https://git.openjdk.org/jdk/compare/97d2a379...0a78858d

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=17
  Stats: 3482 lines in 85 files changed: 2164 ins; 965 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Sun May 11 09:21:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 11 May 2025 09:21:47 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v19]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <dqYr3PmymW96T281bC59rmgFFzNYlBznmEQ7MUVfcds=.ca1c70a8-4622-406c-951e-06665145de4c@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  adjust description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/0a78858d..deac50ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=17-18

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From egahlin at openjdk.org  Sun May 11 22:42:58 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 11 May 2025 22:42:58 GMT
Subject: Integrated: 8356224: JFR: Default value of @Registered is ignored
In-Reply-To: <HMGNSIrkRPGO3AlYqyEOTPSEKCa7ZRz4Uu0_5Zemfrk=.4c1023ce-607a-4262-b179-b1f56187a679@github.com>
References: <HMGNSIrkRPGO3AlYqyEOTPSEKCa7ZRz4Uu0_5Zemfrk=.4c1023ce-607a-4262-b179-b1f56187a679@github.com>
Message-ID: <w7c8A_yLgK1lb5inP-ma_FaAYsZ-P89t67tuvhXN-nE=.6afaa192-c776-4a07-85db-0f81c5db8691@github.com>

On Tue, 6 May 2025 10:52:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that fixes an issue with the Registered annotation. For details, see bug.
> 
> Testing: tier1 + jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 74f047b8
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74f047b84d949891fb72e2f1c9eca7b0b4bd22c4
Stats:     147 lines in 3 files changed: 107 ins; 6 del; 34 mod

8356224: JFR: Default value of @Registered is ignored

Reviewed-by: mgronlun

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

PR: https://git.openjdk.org/jdk/pull/25063

From mgronlun at openjdk.org  Mon May 12 18:49:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 12 May 2025 18:49:34 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v20]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <Z9rQ8gszBm_O1N2JYHTizkNWArA_TaZWF-3RyenyF6k=.ead6dc09-31b8-47e5-9e3e-b17903299746@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  tiny adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/deac50ba..e00ebe40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=18-19

  Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From egahlin at openjdk.org  Tue May 13 00:03:06 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 13 May 2025 00:03:06 GMT
Subject: RFR: 8356816: JFR: Move printing of metadata into separate class
Message-ID: <94wIO-XioHjnl18kXZgrZlZ8PhP7p1EM209X4kxG7is=.cd1191be-8902-4c70-bfd3-369d21ca2cf7@github.com>

Could I have a review of a PR that moves printing of metadata into a separate class?

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25195/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25195&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356816
  Stats: 311 lines in 3 files changed: 172 ins; 135 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25195/head:pull/25195

PR: https://git.openjdk.org/jdk/pull/25195

From mgronlun at openjdk.org  Tue May 13 08:05:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 13 May 2025 08:05:51 GMT
Subject: RFR: 8356816: JFR: Move printing of metadata into separate class
In-Reply-To: <94wIO-XioHjnl18kXZgrZlZ8PhP7p1EM209X4kxG7is=.cd1191be-8902-4c70-bfd3-369d21ca2cf7@github.com>
References: <94wIO-XioHjnl18kXZgrZlZ8PhP7p1EM209X4kxG7is=.cd1191be-8902-4c70-bfd3-369d21ca2cf7@github.com>
Message-ID: <WV8O4WJgZn6_-vVtxM4yBP5DUsOz_-3bhW6m9g2Kxa4=.be6e9a85-4941-4af1-9f41-ff682bc16d8e@github.com>

On Mon, 12 May 2025 23:53:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that moves printing of metadata into a separate class?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25195#pullrequestreview-2835694562

From eosterlund at openjdk.org  Tue May 13 09:34:58 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 May 2025 09:34:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v20]
In-Reply-To: <Z9rQ8gszBm_O1N2JYHTizkNWArA_TaZWF-3RyenyF6k=.ead6dc09-31b8-47e5-9e3e-b17903299746@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <Z9rQ8gszBm_O1N2JYHTizkNWArA_TaZWF-3RyenyF6k=.ead6dc09-31b8-47e5-9e3e-b17903299746@github.com>
Message-ID: <9vsM9qy1yvFUTy06BocsFnHw7DnQUUVUqvYjdS_fmT4=.504d92b7-7415-4967-b6b2-f0bbb50509b9@github.com>

On Mon, 12 May 2025 18:49:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny adjustments

Changes requested by eosterlund (Reviewer).

src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 195:

> 193:     return false;
> 194:   }
> 195:   if (is_valid_interpreter_frame(request, jt)) {

I don't know how I feel about this kind of "quacks like an interpreter frame" check, if that's then used to 100% trust, as opposed to 99.999% guessed, that we have found a real parsable interpreter frame. If the quacking song sounds right, we can safely retrieve the Method* and fully trust it to have been an actual method that the interpreter is in the middle of executing, instead of just unexpected bit noise that was really really good at quacking like a valid interpreter frame. It might be more okay if the safe stack walk from the next safepoint poll validates that we found the same frame and it had the same method, and hence only choose to trust the bcp from the quacking sounds of the signal handler. If it's wrong, then we might get a confusing sample with an inaccurate bci. But that's better than a crash.

Regardless of the solution domain, I think this looks like a problem worth fixing.

src/hotspot/share/runtime/safepointMechanism.cpp line 135:

> 133: }
> 134: 
> 135: static inline bool has_handshake_operation(JavaThread* jt, bool allow_suspend, bool check_async) {

This function sounds like it checks if there is a pending handshake operation, but it also does the actual processing of discovered handshake operations, which is a bit misleading. This refactoring looks a bit orthogonal to what you are doing. Could we revert this refactoring and revisit after the integration?

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

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2835512658
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2086364885
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2086075611

From eosterlund at openjdk.org  Tue May 13 09:34:59 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 May 2025 09:34:59 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v4]
In-Reply-To: <fRKNzH1iPzOIhuj-Vo-kpy-E_BMdN5Y8KIjw6WexYBs=.d30d7ea3-4c87-46e4-a7af-81701e79d4ae@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <bqk02feSnWOjq6uXOZtg4DpffZmK8A1eiE9yZaDN7aM=.e70706e0-fa5d-4fa4-a55e-1e1aba8eaa71@github.com>
 <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>
 <fRKNzH1iPzOIhuj-Vo-kpy-E_BMdN5Y8KIjw6WexYBs=.d30d7ea3-4c87-46e4-a7af-81701e79d4ae@github.com>
Message-ID: <R-IqoxLLnCLwRRM7O8QYWRJXVgqyjlTSr5I4lU2VIdQ=.384ca2b1-42cd-439e-bb6a-f8c564220b35@github.com>

On Sat, 19 Apr 2025 11:34:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 82:
>> 
>>> 80:   assert(jt->has_last_Java_frame(), "invariant");
>>> 81: 
>>> 82:   // For a request representing an interpreter frame, request._sample_sp is actually the frame pointer, fp.
>> 
>> :)
>
> Yeah...
> 
> ?\_(?)_/?

O_o

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2086096172

From egahlin at openjdk.org  Tue May 13 12:42:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 13 May 2025 12:42:59 GMT
Subject: Integrated: 8356816: JFR: Move printing of metadata into separate
 class
In-Reply-To: <94wIO-XioHjnl18kXZgrZlZ8PhP7p1EM209X4kxG7is=.cd1191be-8902-4c70-bfd3-369d21ca2cf7@github.com>
References: <94wIO-XioHjnl18kXZgrZlZ8PhP7p1EM209X4kxG7is=.cd1191be-8902-4c70-bfd3-369d21ca2cf7@github.com>
Message-ID: <WzeiYqvyInrWZKQvjkEfpn2aSmp61nyNKr7riwtP-_U=.5287a1cd-051f-45d6-b827-01b7415efc1f@github.com>

On Mon, 12 May 2025 23:53:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that moves printing of metadata into a separate class?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 14d372b1
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14d372b15bb49a98b0fc802e142fc76598123821
Stats:     311 lines in 3 files changed: 172 ins; 135 del; 4 mod

8356816: JFR: Move printing of metadata into separate class

Reviewed-by: mgronlun

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

PR: https://git.openjdk.org/jdk/pull/25195

From mdoerr at openjdk.org  Tue May 13 20:05:54 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 13 May 2025 20:05:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v16]
In-Reply-To: <27ga1Z__QxsqWxH7c0G7UfqiaPYJAP17thdyn_Mj6j8=.374f6033-4a81-4f32-a9b1-ebf9e72c3fbb@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <27ga1Z__QxsqWxH7c0G7UfqiaPYJAP17thdyn_Mj6j8=.374f6033-4a81-4f32-a9b1-ebf9e72c3fbb@github.com>
Message-ID: <JoWve9D9Pozf46jsxnAPH2XL1Vx1yoWjhFDmr-GJMDw=.38226919-c02c-4349-8936-dba3b2b74ef0@github.com>

On Tue, 6 May 2025 21:13:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I think your version is not nicely implementable on platforms which don't have an FP register, but I'll take a look and think about it.

Update: I was thinking about emulating `make_sender_fp_current` by modifying the Back Chain: `std(sender_fp, _abi0(callers_sp), R1_SP);`. This would also hide the top frame from the sampler such that it doesn't sample the top frame after the return safepoint check. However, this would break concurrent thread stack processing (used by ZGC and ShenandoahGC) which relies on the Back Chain: https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104
Maybe we can find a way to discard samples after the return safepoint check?

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

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

From mgronlun at openjdk.org  Tue May 13 20:22:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 13 May 2025 20:22:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v16]
In-Reply-To: <JoWve9D9Pozf46jsxnAPH2XL1Vx1yoWjhFDmr-GJMDw=.38226919-c02c-4349-8936-dba3b2b74ef0@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <27ga1Z__QxsqWxH7c0G7UfqiaPYJAP17thdyn_Mj6j8=.374f6033-4a81-4f32-a9b1-ebf9e72c3fbb@github.com>
 <JoWve9D9Pozf46jsxnAPH2XL1Vx1yoWjhFDmr-GJMDw=.38226919-c02c-4349-8936-dba3b2b74ef0@github.com>
Message-ID: <QrAXgcgzQNONGI8pavhwsYn3sCu51ugPZoYnU_0CNgs=.a662ea56-e81c-4c5c-9f48-3a11875141c3@github.com>

On Tue, 13 May 2025 20:03:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > I think your version is not nicely implementable on platforms which don't have an FP register, but I'll take a look and think about it.
> 
> Update: I was thinking about emulating `make_sender_fp_current` by modifying the Back Chain: `std(sender_fp, _abi0(callers_sp), R1_SP);`. This would also hide the top frame from the sampler such that it doesn't sample the top frame after the return safepoint check. However, this would break concurrent thread stack processing (used by ZGC and ShenandoahGC) which relies on the Back Chain:
> 
> https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104
> 
> Maybe we can find a way to discard samples after the return safepoint check?

Why would it break stack watermark processing for only this platform? Stack watermark processing relies on the ljf, not the CPU context. That's why we (still) set the ljf to the frame to be popped, and provide the sender java fp as a separate field.

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

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

From mgronlun at openjdk.org  Tue May 13 20:22:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 13 May 2025 20:22:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v20]
In-Reply-To: <9vsM9qy1yvFUTy06BocsFnHw7DnQUUVUqvYjdS_fmT4=.504d92b7-7415-4967-b6b2-f0bbb50509b9@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <Z9rQ8gszBm_O1N2JYHTizkNWArA_TaZWF-3RyenyF6k=.ead6dc09-31b8-47e5-9e3e-b17903299746@github.com>
 <9vsM9qy1yvFUTy06BocsFnHw7DnQUUVUqvYjdS_fmT4=.504d92b7-7415-4967-b6b2-f0bbb50509b9@github.com>
Message-ID: <rN3-nFbppB2C_FQZNQSifINZ1ts_5ipIMhOxlH4e9hA=.e5943173-375b-4f3f-9dcf-2abb8bde67a4@github.com>

On Tue, 13 May 2025 07:05:58 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tiny adjustments
>
> src/hotspot/share/runtime/safepointMechanism.cpp line 135:
> 
>> 133: }
>> 134: 
>> 135: static inline bool has_handshake_operation(JavaThread* jt, bool allow_suspend, bool check_async) {
> 
> This function sounds like it checks if there is a pending handshake operation, but it also does the actual processing of discovered handshake operations, which is a bit misleading. This refactoring looks a bit orthogonal to what you are doing. Could we revert this refactoring and revisit after the integration?

Absolutely, reverting now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2087568350

From mgronlun at openjdk.org  Tue May 13 20:27:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 13 May 2025 20:27:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v20]
In-Reply-To: <9vsM9qy1yvFUTy06BocsFnHw7DnQUUVUqvYjdS_fmT4=.504d92b7-7415-4967-b6b2-f0bbb50509b9@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <Z9rQ8gszBm_O1N2JYHTizkNWArA_TaZWF-3RyenyF6k=.ead6dc09-31b8-47e5-9e3e-b17903299746@github.com>
 <9vsM9qy1yvFUTy06BocsFnHw7DnQUUVUqvYjdS_fmT4=.504d92b7-7415-4967-b6b2-f0bbb50509b9@github.com>
Message-ID: <9QC2rr_04b2tgOm2azbUXZ9knwLad3Jm7eGh-eAyX58=.ca2ad426-3cf0-4323-ad54-dff88df333ba@github.com>

On Tue, 13 May 2025 09:32:29 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tiny adjustments
>
> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 195:
> 
>> 193:     return false;
>> 194:   }
>> 195:   if (is_valid_interpreter_frame(request, jt)) {
> 
> I don't know how I feel about this kind of "quacks like an interpreter frame" check, if that's then used to 100% trust, as opposed to 99.999% guessed, that we have found a real parsable interpreter frame. If the quacking song sounds right, we can safely retrieve the Method* and fully trust it to have been an actual method that the interpreter is in the middle of executing, instead of just unexpected bit noise that was really really good at quacking like a valid interpreter frame. It might be more okay if the safe stack walk from the next safepoint poll validates that we found the same frame and it had the same method, and hence only choose to trust the bcp from the quacking sounds of the signal handler. If it's wrong, then we might get a confusing sample with an inaccurate bci. But that's better than a crash.
> 
> Regardless of the solution domain, I think this looks like a problem worth fixing.

Excellent observation, Erik. It remains a risky construct because it still assumes that frames are laid out only according to the sanctioned schema, a fact we know is not invariant. I have managed to delay reading the Method* until we reach a safe point, and can guarantee that any Method* we attempt to pick up is valid.

Running tests. Stay tuned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2087576279

From eosterlund at openjdk.org  Tue May 13 20:41:54 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 May 2025 20:41:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v20]
In-Reply-To: <9QC2rr_04b2tgOm2azbUXZ9knwLad3Jm7eGh-eAyX58=.ca2ad426-3cf0-4323-ad54-dff88df333ba@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <Z9rQ8gszBm_O1N2JYHTizkNWArA_TaZWF-3RyenyF6k=.ead6dc09-31b8-47e5-9e3e-b17903299746@github.com>
 <9vsM9qy1yvFUTy06BocsFnHw7DnQUUVUqvYjdS_fmT4=.504d92b7-7415-4967-b6b2-f0bbb50509b9@github.com>
 <9QC2rr_04b2tgOm2azbUXZ9knwLad3Jm7eGh-eAyX58=.ca2ad426-3cf0-4323-ad54-dff88df333ba@github.com>
Message-ID: <J1Fom6qkqET8-weY5S7231mpsSy6di9UhIyToOBRhKA=.d7e6a993-319a-4a1d-95f3-b16035a2501f@github.com>

On Tue, 13 May 2025 20:25:01 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 195:
>> 
>>> 193:     return false;
>>> 194:   }
>>> 195:   if (is_valid_interpreter_frame(request, jt)) {
>> 
>> I don't know how I feel about this kind of "quacks like an interpreter frame" check, if that's then used to 100% trust, as opposed to 99.999% guessed, that we have found a real parsable interpreter frame. If the quacking song sounds right, we can safely retrieve the Method* and fully trust it to have been an actual method that the interpreter is in the middle of executing, instead of just unexpected bit noise that was really really good at quacking like a valid interpreter frame. It might be more okay if the safe stack walk from the next safepoint poll validates that we found the same frame and it had the same method, and hence only choose to trust the bcp from the quacking sounds of the signal handler. If it's wrong, then we might get a confusing sample with an inaccurate bci. But that's better than a crash.
>> 
>> Regardless of the solution domain, I think this looks like a problem worth fixing.
>
> Excellent observation, Erik. It remains a risky construct because it still assumes that interpreter frames are laid out only according to the sanctioned schema, a fact we know is not invariant. I have managed to delay reading the Method* until we reach a safe point, and can guarantee that any Method* we attempt to pick up is valid.
> 
> Running tests. Stay tuned.

Sounds promising!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2087595576

From mgronlun at openjdk.org  Wed May 14 00:09:39 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 14 May 2025 00:09:39 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v21]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <CDFUM7r2qac0XJdU7L1szGmtUC_d2UbQ4kf6FG6iC7Y=.d024e880-56b4-4f4a-9e4e-912af2f2e182@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Delay loading of Method* until safepoint
 - Merge branch 'master' into 8352251
 - tiny adjustments
 - adjust description
 - Merge branch 'master' into 8352251
 - 8350338: the minimal arm32 support
 - Merge branch 'master' into 8352251
 - Configuration and test for jdk.SafepointLatency event
 - include guards
 - push back pd constants into pd code
 - ... and 15 more: https://git.openjdk.org/jdk/compare/d1543429...f14e1c28

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=20
  Stats: 3468 lines in 85 files changed: 2154 ins; 955 del; 359 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Wed May 14 00:09:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 14 May 2025 00:09:40 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v20]
In-Reply-To: <J1Fom6qkqET8-weY5S7231mpsSy6di9UhIyToOBRhKA=.d7e6a993-319a-4a1d-95f3-b16035a2501f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <Z9rQ8gszBm_O1N2JYHTizkNWArA_TaZWF-3RyenyF6k=.ead6dc09-31b8-47e5-9e3e-b17903299746@github.com>
 <9vsM9qy1yvFUTy06BocsFnHw7DnQUUVUqvYjdS_fmT4=.504d92b7-7415-4967-b6b2-f0bbb50509b9@github.com>
 <9QC2rr_04b2tgOm2azbUXZ9knwLad3Jm7eGh-eAyX58=.ca2ad426-3cf0-4323-ad54-dff88df333ba@github.com>
 <J1Fom6qkqET8-weY5S7231mpsSy6di9UhIyToOBRhKA=.d7e6a993-319a-4a1d-95f3-b16035a2501f@github.com>
Message-ID: <HiwfmH1TbeWymmPiOPVuXqrnn5i-GJt_4O7aPblIM5Q=.32bd080d-a029-433c-a0ab-e447ed4d54e0@github.com>

On Tue, 13 May 2025 20:39:05 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Excellent observation, Erik. It remains a risky construct because it still assumes that interpreter frames are laid out only according to the sanctioned schema, a fact we know is not invariant. I have managed to delay reading the Method* until we reach a safe point, and can guarantee that any Method* we attempt to pick up is valid.
>> 
>> Running tests. Stay tuned.
>
> Sounds promising!

Please take a look at https://github.com/openjdk/jdk/pull/24296/commits/f14e1c288e6f54601f5e3ebaff9d82ec433a7ebd

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2087790333

From mgronlun at openjdk.org  Wed May 14 08:09:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 14 May 2025 08:09:28 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  validate_bcp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/f14e1c28..eb8a4044

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=20-21

  Stats: 11 lines in 2 files changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mdoerr at openjdk.org  Wed May 14 13:08:56 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 14 May 2025 13:08:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v16]
In-Reply-To: <QrAXgcgzQNONGI8pavhwsYn3sCu51ugPZoYnU_0CNgs=.a662ea56-e81c-4c5c-9f48-3a11875141c3@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <27ga1Z__QxsqWxH7c0G7UfqiaPYJAP17thdyn_Mj6j8=.374f6033-4a81-4f32-a9b1-ebf9e72c3fbb@github.com>
 <JoWve9D9Pozf46jsxnAPH2XL1Vx1yoWjhFDmr-GJMDw=.38226919-c02c-4349-8936-dba3b2b74ef0@github.com>
 <QrAXgcgzQNONGI8pavhwsYn3sCu51ugPZoYnU_0CNgs=.a662ea56-e81c-4c5c-9f48-3a11875141c3@github.com>
Message-ID: <kcSXEzzDdTBV-7-qQf8hE3mu-vWlOD7_eVI2kVryVlI=.d029daf6-4a7f-4b4c-9158-c6be08b6ad58@github.com>

On Tue, 13 May 2025 20:18:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Why would it break stack watermark processing for only this platform? Stack watermark processing relies on the ljf, not the CPU context. That's why we (still) set the ljf to the frame to be popped, and provide the sender java fp as a separate field.

This code uses the Back Chain on PPC64 which will miss one frame if we have modified the Back Chain:
https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104 

I've tried it and here's the extract from the hs_err file:
`assert(is_frame_safe(f)) failed: Frame must be safe`


V  [libjvm.so+0x1c9f670]  StackWatermark::assert_is_frame_safe(frame const&)+0xd0  (stackWatermark.cpp:180)
V  [libjvm.so+0x1ca3650]  StackWatermark::before_unwind()+0x1f0  (stackWatermark.inline.hpp:83)
V  [libjvm.so+0x1ca2b58]  StackWatermarkSet::before_unwind(JavaThread*)+0x58  (stackWatermarkSet.cpp:87)
V  [libjvm.so+0x1017210]  InterpreterRuntime::at_unwind(JavaThread*)+0x90  (interpreterRuntime.cpp:1182)
j  jdk.internal.classfile.impl.Util.writeList(Ljdk/internal/classfile/impl/BufWriterImpl;[Ljdk/internal/classfile/impl/Util$Writable;I)V+16 java.base at 25-internal


The difference on other platforms may be that they have several ways of finding the next frame. By FP register and by some kind of link. PPC64 only uses one way which is the Back Chain.

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

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

From cito at openjdk.org  Wed May 14 13:54:34 2025
From: cito at openjdk.org (Chihiro Ito)
Date: Wed, 14 May 2025 13:54:34 GMT
Subject: RFR: 8356945: jdk/jfr/event/os/TestProcessStart failed on Windows
 Subsystem for Linux
Message-ID: <JmcdTTm4wegEVhzdOreG9PvsuDshSTjjPfHBFg9d32s=.0b13ab29-37c0-43c0-a765-7160c400717a@github.com>

Currently, when this test is run on Windows Subsystem for Linux, dir is executed as an external process.
However, dir is a cmd.exe command, and dir.exe does not exist, so the test fails as shown below.

----------System.out:(0/0)----------
----------System.err:(19/2649)*----------
java.io.IOException: Cannot run program "dir" (in directory "D:\\dev\\jdk\\build\\windows-x86_64-server-release\\test-support\\jtreg_test_jdk_jdk_jfr_event_os_TestProcessStart_java\\scratch\\0\."): CreateProcess error=2, The system cannot find the file specified

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

Commit messages:
 - 8356945: jdk/jfr/event/os/TestProcessStart failed on Windows

Changes: https://git.openjdk.org/jdk/pull/25227/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25227&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356945
  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25227/head:pull/25227

PR: https://git.openjdk.org/jdk/pull/25227

From pchilanomate at openjdk.org  Wed May 14 15:04:02 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 14 May 2025 15:04:02 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
Message-ID: <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>

On Wed, 14 May 2025 08:09:28 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   validate_bcp

Hi Markus, added some comments below. I haven?t look in detail at the platform dependent changes yet but will do that too. Thanks.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 292:

> 290: // Sampling a thread in state _thread_in_Java
> 291: // involves a platform-specific thread suspend and CPU context retrieval.
> 292: bool JfrSamplerThread::sample_java_thread(JavaThread* jt) {

Why not just send a signal and let the target do everything including creating the request? Is it because enqueueing the request might need to allocate memory? Given that the sampling frequency is in the order of milliseconds, and the TTS for the target is sub-milliseconds we would just need a pretty small buffer if anything. Or is there something else I?m missing?

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 323:

> 321: // without thread suspension and CPU context retrieval,
> 322: // if we carefully order the loads of the thread state.
> 323: bool JfrSamplerThread::sample_native_thread(JavaThread* jt) {

This method now begs to be converted into a handshake, it?s pretty much the same logic. I wonder if you considered that already and found some issue. The handshake would also provide the necessary synchronization so there is no need for the extra sample_monitor and wait/notifies. I?m assuming you didn?t go for this because you would still need to add the extra separate flag check in `SafepointMechanism` for the sample in java case, and so you just kept both under it for consistency? But even the sample in java case could use handshakes, we would just need to install an async one (only executed by target) at the end after enqueueing the request. We would still need to keep the `Jfr::check_and_process_sample_request()` method separately but we can do that. I?ve been playing around with these changes: https://github.com/pchilano/jdk/commit/dacce47402c38a2b466c819d2cd6c643b0de09ba
I think it is simpler to read and removes some of the complexity of the current approach. What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2840430440
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089091415
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089084362

From pchilanomate at openjdk.org  Wed May 14 15:04:03 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 14 May 2025 15:04:03 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
 <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
Message-ID: <g6QE497Lvl6dqlb3ucuEXu2nNqZb1cX6sIQbUc3Y7Tg=.08bb3959-4eb9-4129-8578-fae889e130a7@github.com>

On Wed, 14 May 2025 14:25:35 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   validate_bcp
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 323:
> 
>> 321: // without thread suspension and CPU context retrieval,
>> 322: // if we carefully order the loads of the thread state.
>> 323: bool JfrSamplerThread::sample_native_thread(JavaThread* jt) {
> 
> This method now begs to be converted into a handshake, it?s pretty much the same logic. I wonder if you considered that already and found some issue. The handshake would also provide the necessary synchronization so there is no need for the extra sample_monitor and wait/notifies. I?m assuming you didn?t go for this because you would still need to add the extra separate flag check in `SafepointMechanism` for the sample in java case, and so you just kept both under it for consistency? But even the sample in java case could use handshakes, we would just need to install an async one (only executed by target) at the end after enqueueing the request. We would still need to keep the `Jfr::check_and_process_sample_request()` method separately but we can do that. I?ve been playing around with these changes: https://github.com/pchilano/jdk/commit/dacce47402c38a2b466c819d2cd6c643b0de09ba
> I think it is simpler to read and removes some of the complexity of the current approach. What do you think?

Also, for the sampling in native case, we could make it more cooperative by adding a handshake operation like the one for all threads but for a list of threads. That way we can try to distribute the work instead of going one by one (this can actually be done with the current code too with some changes).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089097185

From mgronlun at openjdk.org  Wed May 14 15:29:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 14 May 2025 15:29:59 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
 <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
Message-ID: <Yt3UXmsscHCBcJiw4PIYmlZrUe0q-e_6iBqO1Jt955Y=.86e08667-3dfe-4964-a639-15d0c24fab7f@github.com>

On Wed, 14 May 2025 14:28:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   validate_bcp
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 292:
> 
>> 290: // Sampling a thread in state _thread_in_Java
>> 291: // involves a platform-specific thread suspend and CPU context retrieval.
>> 292: bool JfrSamplerThread::sample_java_thread(JavaThread* jt) {
> 
> Why not just send a signal and let the target do everything including creating the request? Is it because enqueueing the request might need to allocate memory? Given that the sampling frequency is in the order of milliseconds, and the TTS for the target is sub-milliseconds we would just need a pretty small buffer if anything. Or is there something else I?m missing?

There are no signals on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089213951

From mgronlun at openjdk.org  Wed May 14 15:32:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 14 May 2025 15:32:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <g6QE497Lvl6dqlb3ucuEXu2nNqZb1cX6sIQbUc3Y7Tg=.08bb3959-4eb9-4129-8578-fae889e130a7@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
 <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
 <g6QE497Lvl6dqlb3ucuEXu2nNqZb1cX6sIQbUc3Y7Tg=.08bb3959-4eb9-4129-8578-fae889e130a7@github.com>
Message-ID: <WumNkwBEDWdBZh5iVnMaWXUymBKwROpNEuIW4ulqmxk=.a64cd3d5-f20a-4dc8-bdf0-79025d7ba808@github.com>

On Wed, 14 May 2025 14:31:27 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 323:
>> 
>>> 321: // without thread suspension and CPU context retrieval,
>>> 322: // if we carefully order the loads of the thread state.
>>> 323: bool JfrSamplerThread::sample_native_thread(JavaThread* jt) {
>> 
>> This method now begs to be converted into a handshake, it?s pretty much the same logic. I wonder if you considered that already and found some issue. The handshake would also provide the necessary synchronization so there is no need for the extra sample_monitor and wait/notifies. I?m assuming you didn?t go for this because you would still need to add the extra separate flag check in `SafepointMechanism` for the sample in java case, and so you just kept both under it for consistency? But even the sample in java case could use handshakes, we would just need to install an async one (only executed by target) at the end after enqueueing the request. We would still need to keep the `Jfr::check_and_process_sample_request()` method separately but we can do that. I?ve been playing around with these changes: https://github.com/pchilano/jdk/commit/dacce47402c38a2b466c819d2cd6c643b0de09ba
>> I think it is simpler to read and removes some of the complexity of the current approach. What do you think?
>
> Also, for the sampling in native case, we could make it more cooperative by adding a handshake operation like the one for all threads but for a list of threads. That way we can try to distribute the work instead of going one by one (this can actually be done with the current code too with some changes).

There might be opportunities for generalizations. The main reason was to keep much of the existing JFR sampler mechanism. It evolved more and more towards handshakes, I agree. Maybe we can generalize it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089219304

From mgronlun at openjdk.org  Wed May 14 15:36:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 14 May 2025 15:36:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
 <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
Message-ID: <Aaxq3eBHUuKlI92CU6R16jSjIQHz_ywIrDPFQ_iawjM=.df102464-7d79-4293-a4ab-dfa19a6a83b9@github.com>

On Wed, 14 May 2025 14:28:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   validate_bcp
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 292:
> 
>> 290: // Sampling a thread in state _thread_in_Java
>> 291: // involves a platform-specific thread suspend and CPU context retrieval.
>> 292: bool JfrSamplerThread::sample_java_thread(JavaThread* jt) {
> 
> Why not just send a signal and let the target do everything including creating the request? Is it because enqueueing the request might need to allocate memory? Given that the sampling frequency is in the order of milliseconds, and the TTS for the target is sub-milliseconds we would just need a pretty small buffer if anything. Or is there something else I?m missing?

Because we don't know when (or even if) a thread executing native code will return to the JVM.

Today, we have speedy delivery of samples for threads running in native, and we want to maintain this level of service, so we can't rely on them returning on their own for sample delivery. We need to get the samples sent out by the sampler thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089227116

From mark.reinhold at oracle.com  Wed May 14 15:59:48 2025
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Wed, 14 May 2025 15:59:48 +0000
Subject: New candidate JEP: 520: JFR Method Timing & Tracing
Message-ID: <20250514155948.436668155FE@eggemoggin.niobe.net>

https://openjdk.org/jeps/520

  Summary: Extend the JDK Flight Recorder (JFR) with facilities for
  method timing and tracing via bytecode instrumentation.

- Mark

From pchilanomate at openjdk.org  Wed May 14 16:01:03 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 14 May 2025 16:01:03 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <Aaxq3eBHUuKlI92CU6R16jSjIQHz_ywIrDPFQ_iawjM=.df102464-7d79-4293-a4ab-dfa19a6a83b9@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
 <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
 <Aaxq3eBHUuKlI92CU6R16jSjIQHz_ywIrDPFQ_iawjM=.df102464-7d79-4293-a4ab-dfa19a6a83b9@github.com>
Message-ID: <EprH0YvvldgOK_UhFLLk3xGoIrLinMvKcn_oqp8PhS0=.20dc4b33-538e-440b-bd10-3d87ede99ce7@github.com>

On Wed, 14 May 2025 15:34:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 292:
>> 
>>> 290: // Sampling a thread in state _thread_in_Java
>>> 291: // involves a platform-specific thread suspend and CPU context retrieval.
>>> 292: bool JfrSamplerThread::sample_java_thread(JavaThread* jt) {
>> 
>> Why not just send a signal and let the target do everything including creating the request? Is it because enqueueing the request might need to allocate memory? Given that the sampling frequency is in the order of milliseconds, and the TTS for the target is sub-milliseconds we would just need a pretty small buffer if anything. Or is there something else I?m missing?
>
> Because we don't know when (or even if) a thread executing native code will return to the JVM.
> 
> Today, we have speedy delivery of samples for threads running in native, and we want to maintain this level of service, so we can't rely on them returning on their own for sample delivery. We need to get the samples sent out by the sampler thread.

Right, I meant for the sampling in java case. But I forgot there are no signal on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2089271230

From shade at openjdk.org  Thu May 15 08:54:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 May 2025 08:54:28 GMT
Subject: RFR: 8356968: JFR: Compilation event should be enabled for all
 compilations by default
Message-ID: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>

In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. 

It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high.

Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0.

See more logs in the bug itself.

Additional testing:
 - [x] Ad-hoc tests with printing compilation events
 - [x] Linux x86_64 server fastdebug, `jdk_jfr`

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/25247/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25247&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356968
  Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25247/head:pull/25247

PR: https://git.openjdk.org/jdk/pull/25247

From egahlin at openjdk.org  Thu May 15 09:25:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 15 May 2025 09:25:51 GMT
Subject: RFR: 8356968: JFR: Compilation event should be enabled for all
 compilations by default
In-Reply-To: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
References: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
Message-ID: <DrLQVr28TCYSa3AEksZ0SuutMfQe9Lu30nRltnTG6KY=.2a4fec9d-9854-4cb8-b6e0-73d3b9337e28@github.com>

On Thu, 15 May 2025 08:49:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. 
> 
> It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high.
> 
> Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0.
> 
> See more logs in the bug itself.
> 
> Additional testing:
>  - [x] Ad-hoc tests with printing compilation events
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

The overhead of the event is low, I believe, but I think the concern was that too many events were generated with little value to the end user. The buffers will be filled, and other, more important events will be pushed out. That said, there are probably other JVM events, i.e., low-level GC or runtime events, that are on by default, which may be less interesting than the compilation event.

`jfr summary` lists the number of events and how much space they take up.

Maybe we should reprioritize them?

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

PR Comment: https://git.openjdk.org/jdk/pull/25247#issuecomment-2883148975

From shade at openjdk.org  Thu May 15 09:41:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 May 2025 09:41:50 GMT
Subject: RFR: 8356968: JFR: Compilation event should be enabled for all
 compilations by default
In-Reply-To: <DrLQVr28TCYSa3AEksZ0SuutMfQe9Lu30nRltnTG6KY=.2a4fec9d-9854-4cb8-b6e0-73d3b9337e28@github.com>
References: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
 <DrLQVr28TCYSa3AEksZ0SuutMfQe9Lu30nRltnTG6KY=.2a4fec9d-9854-4cb8-b6e0-73d3b9337e28@github.com>
Message-ID: <4-DQbYMwJKO5ePT-38nF3RvslKBjdbkrna6lGzW-7Vk=.e3253100-811e-4378-a479-7ac92c5bc1d5@github.com>

On Thu, 15 May 2025 09:22:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> The overhead of the event is low, I believe, but I think the concern was that too many events were generated with little value to the end user. 

I can see that. But the neat part about compilation events is that we are supposed to have a limited number of them. As system goes into steady state, compilations are supposed to become very rare. And if they are not, that is actually a signal something is really off, and we do want to know :)

> `jfr summary` lists the number of events and how much space they take up.

I think current overheads are fair.

For example, on javac HelloWorld workload, `jdk.Compilation` is about 1K events, about 25K in total (~ 25 bytes/event), on-par with system process, flags, settings events. Takes ~7% of the dump on javac Hello World, and that is likely a high estimate, as longer apps would likely start dumping much more events.


 $ ls -lah comp.jfr
-rw-rw-r-- 1 shade shade 365K May 14 14:00 comp.jfr

$ jfr summary comp.jfr | sort -k 3 -n -r | head -n 10
 jdk.CheckPoint                             14        134299
 jdk.Metadata                                1        107126
 jdk.SystemProcess                         546         32949
 jdk.Compilation                           946         23678
 jdk.ThreadDump                              2         18679
 jdk.BooleanFlag                           492         14607
 jdk.ActiveSetting                         356          8846
 jdk.ModuleExport                          504          5414
 jdk.LongFlag                              136          4237
 jdk.InitialEnvironmentVariable             73          3077
...

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

PR Comment: https://git.openjdk.org/jdk/pull/25247#issuecomment-2883196644

From mdoerr at openjdk.org  Thu May 15 10:45:01 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 15 May 2025 10:45:01 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v16]
In-Reply-To: <QrAXgcgzQNONGI8pavhwsYn3sCu51ugPZoYnU_0CNgs=.a662ea56-e81c-4c5c-9f48-3a11875141c3@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <hR-36NdtpfOeftDRt26-DGOPDig54Ezp1YrLw3rxd5k=.189265af-caff-408a-a515-5eeccbe3ed3a@github.com>
 <27ga1Z__QxsqWxH7c0G7UfqiaPYJAP17thdyn_Mj6j8=.374f6033-4a81-4f32-a9b1-ebf9e72c3fbb@github.com>
 <JoWve9D9Pozf46jsxnAPH2XL1Vx1yoWjhFDmr-GJMDw=.38226919-c02c-4349-8936-dba3b2b74ef0@github.com>
 <QrAXgcgzQNONGI8pavhwsYn3sCu51ugPZoYnU_0CNgs=.a662ea56-e81c-4c5c-9f48-3a11875141c3@github.com>
Message-ID: <FMiZBIbl3AlNRLlPS7E_sqGJi_-9Q4RriGhzYUfy0IY=.9223787d-8c59-461d-9eaf-f34af1992c33@github.com>

On Tue, 13 May 2025 20:18:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>>> I think your version is not nicely implementable on platforms which don't have an FP register, but I'll take a look and think about it.
>> 
>> Update: I was thinking about emulating `make_sender_fp_current` by modifying the Back Chain: `std(sender_fp, _abi0(callers_sp), R1_SP);`. This would also hide the top frame from the sampler such that it doesn't sample the top frame after the return safepoint check. However, this would break concurrent thread stack processing (used by ZGC and ShenandoahGC) which relies on the Back Chain: https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104
>> Maybe we can find a way to discard samples after the return safepoint check?
>
>> > I think your version is not nicely implementable on platforms which don't have an FP register, but I'll take a look and think about it.
>> 
>> Update: I was thinking about emulating `make_sender_fp_current` by modifying the Back Chain: `std(sender_fp, _abi0(callers_sp), R1_SP);`. This would also hide the top frame from the sampler such that it doesn't sample the top frame after the return safepoint check. However, this would break concurrent thread stack processing (used by ZGC and ShenandoahGC) which relies on the Back Chain:
>> 
>> https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104
>> 
>> Maybe we can find a way to discard samples after the return safepoint check?
> 
> Why would it break stack watermark processing for only this platform? Stack watermark processing relies on the ljf, not the CPU context. That's why we (still) set the ljf to the frame to be popped, and provide the sender java fp as a separate field.

@mgronlun: I don't think I can get the top frame hiding trick to work on PPC64.
What we need to do is to hide the top interpreter frame from the sampler after the return safepoint check, right?
If I hide it from the sampler, I will also hide it from the concurrent thread stack processing code. And that causes errors.
I think the top frame hiding trick only works on platforms which use an FP register. Platforms like PPC64 and s390 don't have that.
Can we use a different mechanism to prevent the sampler from taking snapshots between the return safepoint check and the frame pop?
E.g., we could set a field in the JavaThread before the safepoint check and clear it after the frame pop. The sampler would have to discard samples when the JavaThread's field is set.

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

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

From mgronlun at openjdk.org  Thu May 15 16:45:16 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 16:45:16 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  growable array constructur without default initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/eb8a4044..fdefd35e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=21-22

  Stats: 20 lines in 2 files changed: 13 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From pchilanomate at openjdk.org  Thu May 15 17:07:59 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 15 May 2025 17:07:59 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
Message-ID: <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>

On Thu, 15 May 2025 16:45:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   growable array constructur without default initialization

Changes requested by pchilanomate (Reviewer).

src/hotspot/cpu/x86/interp_masm_x86.cpp line 782:

> 780: void InterpreterMacroAssembler::call_VM_with_sender_Java_fp(Register fp_reg, Register tmp, address entry_point, bool store_bcp) {
> 781:   if (store_bcp) {
> 782:     save_bcp(fp_reg); // We must save the bcp, but need not restore it. This is because we have already popped the fp.

Why do we need to save the bcp? We already removed the frame from the sampler perspective.

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1059:

> 1057:   bind(L_continuation);
> 1058:   lea(sender_sp, Address(rbp, frame::sender_sp_offset * wordSize));
> 1059:   movptr(rbp, Address(sender_sp, (int)(ContinuationEntry::size()))); // Update the frame link.

Method enterSpecial already sets rbp so we can read from current rbp as with the normal case.

src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1168:

> 1166: 
> 1167:   // Remove activation
> 1168: 

Shouldn?t all this be done before we execute the result handler above?

src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1171:

> 1169:   // For asynchronous profiling to work correctly, we must remove the
> 1170:   // activation frame _before_ we test the method return safepoint poll.
> 1171:   // This is equivalent to how it is done for compiled frames.

We also have the compiled native frame case where there is no poll after removing the frame. Aren?t we missing handling that case?

src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 91:

> 89: static inline address continuation_frame_sender_pc(void* sp) {
> 90:   assert(sp != nullptr, "invariant");
> 91:   return static_cast<address>(sp) + (ContinuationEntry::size() + wordSize);

Seems we are missing a dereference.

src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 187:

> 185:     request._sample_sp = request._sample_bcp;
> 186:     // Get real bcp.
> 187:     void* const bcp = interpreter_frame_bcp(request);

Shouldn?t we get the bcp from the context instead? The one saved in the frame is not updated on each bytecode.

src/hotspot/share/runtime/javaThread.hpp line 232:

> 230:   inline void set_obj_deopt_flag();
> 231:   inline void clear_obj_deopt_flag();
> 232:   bool is_trace_suspend()      { return (_suspend_flags & _trace_flag) != 0; }

Can be removed. Same with the definition of `_trace_flag` in `SuspendFlags` and the usage in `has_special_runtime_exit_condition()`.

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

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2844409284
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091616535
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091612262
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091622683
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091623424
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091607251
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091608265
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091609346

From pchilanomate at openjdk.org  Thu May 15 17:08:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 15 May 2025 17:08:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v22]
In-Reply-To: <WumNkwBEDWdBZh5iVnMaWXUymBKwROpNEuIW4ulqmxk=.a64cd3d5-f20a-4dc8-bdf0-79025d7ba808@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <2EgLTW18zjaMwGnAx08LjCFzmmBgBBM5aWcJ4o7Z6gE=.077b059a-6d42-458e-9ca3-4f7b30106795@github.com>
 <0S1VdeXSDexUSb-xD49hgQf56uTtmdN7VY5LhRijeRU=.6588cb61-f2cd-45cf-ab36-5113481f6874@github.com>
 <g6QE497Lvl6dqlb3ucuEXu2nNqZb1cX6sIQbUc3Y7Tg=.08bb3959-4eb9-4129-8578-fae889e130a7@github.com>
 <WumNkwBEDWdBZh5iVnMaWXUymBKwROpNEuIW4ulqmxk=.a64cd3d5-f20a-4dc8-bdf0-79025d7ba808@github.com>
Message-ID: <SmkL8O-vaI3o8z8u5udoTbJaeeh401s6QJwy8prK9ik=.2e6a9091-809e-40c1-8cad-f0486c6a52ec@github.com>

On Wed, 14 May 2025 15:30:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Also, for the sampling in native case, we could make it more cooperative by adding a handshake operation like the one for all threads but for a list of threads. That way we can try to distribute the work instead of going one by one (this can actually be done with the current code too with some changes).
>
> There might be opportunities for generalizations. The main reason was to keep much of the existing JFR sampler mechanism. It evolved more and more towards handshakes, I agree. Maybe we can generalize it later.

Sure, we can leave it as a follow up. Note though that the handshake patch is mainly replacing the new sampler sync changes (_sample_monitor, _sample_request, SafepointMechanism changes, etc) since they pretty much mimic what we can do with handshakes already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091632646

From mgronlun at openjdk.org  Thu May 15 20:10:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 20:10:01 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
Message-ID: <Eaxo9YxcEKwUAsia6UE0b5AlTQat4NhgassAHwpb9S0=.7a6d3bf5-0cdd-4f4b-bd1c-2c67443a1c72@github.com>

On Thu, 15 May 2025 16:50:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   growable array constructur without default initialization
>
> src/hotspot/share/runtime/javaThread.hpp line 232:
> 
>> 230:   inline void set_obj_deopt_flag();
>> 231:   inline void clear_obj_deopt_flag();
>> 232:   bool is_trace_suspend()      { return (_suspend_flags & _trace_flag) != 0; }
> 
> Can be removed. Same with the definition of `_trace_flag` in `SuspendFlags` and the usage in `has_special_runtime_exit_condition()`.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091885262

From mgronlun at openjdk.org  Thu May 15 20:35:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 20:35:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
Message-ID: <iWmW14dKXWcI3VLGN8ELwIXOH1SSJbvVCeWJ5qHmh6M=.e4f0bd8a-6b67-47a2-87dc-f1175322efc6@github.com>

On Thu, 15 May 2025 16:55:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   growable array constructur without default initialization
>
> src/hotspot/cpu/x86/interp_masm_x86.cpp line 782:
> 
>> 780: void InterpreterMacroAssembler::call_VM_with_sender_Java_fp(Register fp_reg, Register tmp, address entry_point, bool store_bcp) {
>> 781:   if (store_bcp) {
>> 782:     save_bcp(fp_reg); // We must save the bcp, but need not restore it. This is because we have already popped the fp.
> 
> Why do we need to save the bcp? We already removed the frame from the sampler perspective.

It's needed for the stack walking code as part of InterpreterRuntime::at_unwind(), the last java frame (ljf) still points to the unpopped frame.

The ljf is used by both JFR_ONLY(Jfr::check_and_process_sample_request(current);) and later   StackWatermarkSet::before_unwind(current);

> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 187:
> 
>> 185:     request._sample_sp = request._sample_bcp;
>> 186:     // Get real bcp.
>> 187:     void* const bcp = interpreter_frame_bcp(request);
> 
> Shouldn?t we get the bcp from the context instead? The one saved in the frame is not updated on each bytecode.

That would, of course, be ideal, but I don't think there exists any abstraction to read the current bcp from the ucontext_t, abstracting it for all platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091914816
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091918747

From mgronlun at openjdk.org  Thu May 15 20:40:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 20:40:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
Message-ID: <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>

On Thu, 15 May 2025 16:52:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   growable array constructur without default initialization
>
> src/hotspot/cpu/x86/interp_masm_x86.cpp line 1059:
> 
>> 1057:   bind(L_continuation);
>> 1058:   lea(sender_sp, Address(rbp, frame::sender_sp_offset * wordSize));
>> 1059:   movptr(rbp, Address(sender_sp, (int)(ContinuationEntry::size()))); // Update the frame link.
> 
> Method enterSpecial already sets rbp so we can read from current rbp as with the normal case.

I don't think so. That was why I had to do all this special handling for the Continuations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091924241

From mgronlun at openjdk.org  Thu May 15 20:52:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 20:52:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
Message-ID: <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>

On Thu, 15 May 2025 20:37:49 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/cpu/x86/interp_masm_x86.cpp line 1059:
>> 
>>> 1057:   bind(L_continuation);
>>> 1058:   lea(sender_sp, Address(rbp, frame::sender_sp_offset * wordSize));
>>> 1059:   movptr(rbp, Address(sender_sp, (int)(ContinuationEntry::size()))); // Update the frame link.
>> 
>> Method enterSpecial already sets rbp so we can read from current rbp as with the normal case.
>
> I don't think so. That was why I had to do all this special handling for the Continuations.

If I recall, which I don't, as it has been too long, the issue here is that since the IP is still in the interpreter, the rbp referenced in the enterSpecial frame links to an EntryFrame, which is not interpreter code. At least, what is linked in the Continuation is Java code, which can also be compiled; in this case, we can handle it. However, the challenge is to move the rbp, knowing that your IP is still in interpreter code. Can I handle that situation? That becomes the question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091939042

From mgronlun at openjdk.org  Thu May 15 20:58:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 20:58:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
Message-ID: <lP-S5CESgBNAVSkrTu6KfMZVvXEVZfg6lX4CH7ySiY4=.d99133f9-5b6a-4f16-9177-d03ae11205b5@github.com>

On Thu, 15 May 2025 16:59:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   growable array constructur without default initialization
>
> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1168:
> 
>> 1166: 
>> 1167:   // Remove activation
>> 1168: 
> 
> Shouldn?t all this be done before we execute the result handler above?

Why do you think that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2091947746

From pchilanomate at openjdk.org  Thu May 15 21:54:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 15 May 2025 21:54:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
Message-ID: <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>

On Thu, 15 May 2025 20:49:22 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I don't think so. That was why I had to do all this special handling for the Continuations.
>
> If I recall, which I don't, as it has been too long, the issue here is that since the IP is still in the interpreter, the rbp referenced in the enterSpecial frame links to an EntryFrame, which is not interpreter code. At least, what is linked in the Continuation is Java code, which can also be compiled; in this case, we can handle it. However, the challenge is to move the rbp, knowing that your IP is still in interpreter code. Can I handle that situation? That becomes the question.

So we would just need to check when creating the request if the fp points to the ContinuationEntry, which is easy to do, and if so create the request with the sender (as I see you already do in one of the cases). This will also cover the case where the return pc is the return_barrier, which should in fact be more common than this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092007195

From pchilanomate at openjdk.org  Thu May 15 21:54:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 15 May 2025 21:54:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <lP-S5CESgBNAVSkrTu6KfMZVvXEVZfg6lX4CH7ySiY4=.d99133f9-5b6a-4f16-9177-d03ae11205b5@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <lP-S5CESgBNAVSkrTu6KfMZVvXEVZfg6lX4CH7ySiY4=.d99133f9-5b6a-4f16-9177-d03ae11205b5@github.com>
Message-ID: <CC0o3cw5q8ozKVOncZiwkrxSG0x0qC-iRAi_T8Jj5QU=.b4163852-ae78-42a1-8c23-10e2ae886abd@github.com>

On Thu, 15 May 2025 20:56:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1168:
>> 
>>> 1166: 
>>> 1167:   // Remove activation
>>> 1168: 
>> 
>> Shouldn?t all this be done before we execute the result handler above?
>
> Why do you think that?

Never mind, it should be fine to execute the result handler before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092008221

From pchilanomate at openjdk.org  Thu May 15 21:57:57 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 15 May 2025 21:57:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <iWmW14dKXWcI3VLGN8ELwIXOH1SSJbvVCeWJ5qHmh6M=.e4f0bd8a-6b67-47a2-87dc-f1175322efc6@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <iWmW14dKXWcI3VLGN8ELwIXOH1SSJbvVCeWJ5qHmh6M=.e4f0bd8a-6b67-47a2-87dc-f1175322efc6@github.com>
Message-ID: <BtpMcY9v0r8LFQzgvRB-8zgKIkwHSkIFq3U8GIn8wdQ=.073ed83e-1d1b-460c-92b8-7a41734d7f40@github.com>

On Thu, 15 May 2025 20:33:21 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 187:
>> 
>>> 185:     request._sample_sp = request._sample_bcp;
>>> 186:     // Get real bcp.
>>> 187:     void* const bcp = interpreter_frame_bcp(request);
>> 
>> Shouldn?t we get the bcp from the context instead? The one saved in the frame is not updated on each bytecode.
>
> That would, of course, be ideal, but I don't think there exists any abstraction to read the current bcp from the ucontext_t, abstracting it for all platforms.

We know which register we use in each platform so it should be same as getting any other register. You can always fallback to getting it from the frame as now for platforms other than x64 and aarch64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092012453

From mgronlun at openjdk.org  Thu May 15 22:05:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 22:05:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
Message-ID: <3z-gmWorKXSpMqwM7eGn2jbEmpWxjg87Z2HOGTH3g0U=.cdc1a5ad-3696-4e9b-8985-22c13c920507@github.com>

On Thu, 15 May 2025 16:59:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   growable array constructur without default initialization
>
> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1171:
> 
>> 1169:   // For asynchronous profiling to work correctly, we must remove the
>> 1170:   // activation frame _before_ we test the method return safepoint poll.
>> 1171:   // This is equivalent to how it is done for compiled frames.
> 
> We also have the compiled native frame case where there is no poll after removing the frame. Aren?t we missing handling that case?

Some subtleties are involved in SharedRuntime::generate_native_wrapper(). There are a few things to keep in mind there. First, the adapter is not part of the JIT code itself, it will not resolve to the nmethod, it will resolve to an AdapterStub. This is for the case where we take the CPU context directly. Some other aspects involved here are that the thread transitions to both thread in native and thread in native trans - during that time, the thread is ineligible for a Java sample. But, as is the case now, the thread transitions back to thread in Java, and there is still a valid ljf - so a sample could happen here, taking the ljf. Therefore, a poll needs to occur before issuing the return, or the reset ljf must happen before we return to Java, which is what I think I did for sampling accuracy. I will need to dig into that branch to find out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092019148

From mgronlun at openjdk.org  Thu May 15 22:05:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 22:05:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <3z-gmWorKXSpMqwM7eGn2jbEmpWxjg87Z2HOGTH3g0U=.cdc1a5ad-3696-4e9b-8985-22c13c920507@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <3z-gmWorKXSpMqwM7eGn2jbEmpWxjg87Z2HOGTH3g0U=.cdc1a5ad-3696-4e9b-8985-22c13c920507@github.com>
Message-ID: <svpb-OIEcqq1d6UtPv3amLClraDVglsC_dpXYjO9T4k=.93e98a40-eac6-4020-a56a-821b8d62160f@github.com>

On Thu, 15 May 2025 22:02:01 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1171:
>> 
>>> 1169:   // For asynchronous profiling to work correctly, we must remove the
>>> 1170:   // activation frame _before_ we test the method return safepoint poll.
>>> 1171:   // This is equivalent to how it is done for compiled frames.
>> 
>> We also have the compiled native frame case where there is no poll after removing the frame. Aren?t we missing handling that case?
>
> Some subtleties are involved in SharedRuntime::generate_native_wrapper(). There are a few things to keep in mind there. First, the adapter is not part of the JIT code itself, it will not resolve to the nmethod, it will resolve to an AdapterStub. This is for the case where we take the CPU context directly. Some other aspects involved here are that the thread transitions to both thread in native and thread in native trans - during that time, the thread is ineligible for a Java sample. But, as is the case now, the thread transitions back to thread in Java, and there is still a valid ljf - so a sample could happen here, taking the ljf. Therefore, a poll needs to occur before issuing the return, or the reset ljf must happen before we return to Java, which is what I think I did for sampling accuracy. I will need to dig into that branch to find out.

Excellent observation, Patricio, thank you for pointing this out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092020111

From eosterlund at openjdk.org  Thu May 15 22:10:54 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 15 May 2025 22:10:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
Message-ID: <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>

On Thu, 15 May 2025 16:45:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   growable array constructur without default initialization

Changes requested by eosterlund (Reviewer).

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 687:

> 685:   Label slow_path;
> 686:   Label fast_path;
> 687:   safepoint_poll(slow_path, this_fp, true /* at_return */, false /* acquire */, false /* in_nmethod */);

The way you moved the polling until after unwinding worries me a little bit.

First of all, you have to change the InterpreterRuntime::safepoint_poll and InterpreterRuntime::at_unwind functions that call StackWatermarkSet::before_unwind to call after_unwind instead, to better reflect what is happening now. That's doable and should be straight forward so that's good.

What I'm more worried about though, is what the JVMTI implications are. When single stepping in the debugger, it would seem that we now stop after unwinding instead of before. That seems like a change in debugger behaviour? I worry that previously you could see locals in the debugger before exiting while now you can't. I also have dark memories of seeing method exit JVMTI event assembly code that crops the expression stack assuming it belongs to the frame we are just returning from because that's how it worked. With fun code trying to deal with the oop maps being wrong across the event. Have you run any JVMTI method exit event tests?

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

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2845067455
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092023295

From mgronlun at openjdk.org  Thu May 15 22:26:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 22:26:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
Message-ID: <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>

On Thu, 15 May 2025 22:06:31 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   growable array constructur without default initialization
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 687:
> 
>> 685:   Label slow_path;
>> 686:   Label fast_path;
>> 687:   safepoint_poll(slow_path, this_fp, true /* at_return */, false /* acquire */, false /* in_nmethod */);
> 
> The way you moved the polling until after unwinding worries me a little bit.
> 
> First of all, you have to change the InterpreterRuntime::safepoint_poll and InterpreterRuntime::at_unwind functions that call StackWatermarkSet::before_unwind to call after_unwind instead, to better reflect what is happening now. That's doable and should be straight forward so that's good.
> 
> What I'm more worried about though, is what the JVMTI implications are. When single stepping in the debugger, it would seem that we now stop after unwinding instead of before. That seems like a change in debugger behaviour? I worry that previously you could see locals in the debugger before exiting while now you can't. I also have dark memories of seeing method exit JVMTI event assembly code that crops the expression stack assuming it belongs to the frame we are just returning from because that's how it worked. With fun code trying to deal with the oop maps being wrong across the event. Have you run any JVMTI method exit event tests?

The intent is to maintain the logical (Java and JVM) view that we have not popped the frame yet, which is why we still save the ljf to the original frame, just as before. Anything working with ljf, such as InterpreterRuntime::at_unwind(), should function as before. 

All tiers 1-6 pass, but I can double check all the JVMTI tests specifically, as they are as you say, tricky.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092040614

From mgronlun at openjdk.org  Thu May 15 22:33:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 22:33:01 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
 <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>
Message-ID: <OxCT9MHiZpeVOVQkq8wKpRJoLkPPPXrp0pnOMfDDZF4=.b6143634-1ec0-4979-a5e2-f0ddf4de6c01@github.com>

On Thu, 15 May 2025 22:24:10 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 687:
>> 
>>> 685:   Label slow_path;
>>> 686:   Label fast_path;
>>> 687:   safepoint_poll(slow_path, this_fp, true /* at_return */, false /* acquire */, false /* in_nmethod */);
>> 
>> The way you moved the polling until after unwinding worries me a little bit.
>> 
>> First of all, you have to change the InterpreterRuntime::safepoint_poll and InterpreterRuntime::at_unwind functions that call StackWatermarkSet::before_unwind to call after_unwind instead, to better reflect what is happening now. That's doable and should be straight forward so that's good.
>> 
>> What I'm more worried about though, is what the JVMTI implications are. When single stepping in the debugger, it would seem that we now stop after unwinding instead of before. That seems like a change in debugger behaviour? I worry that previously you could see locals in the debugger before exiting while now you can't. I also have dark memories of seeing method exit JVMTI event assembly code that crops the expression stack assuming it belongs to the frame we are just returning from because that's how it worked. With fun code trying to deal with the oop maps being wrong across the event. Have you run any JVMTI method exit event tests?
>
> The intent is to maintain the logical (Java and JVM) view that we have not popped the frame yet, which is why we still save the ljf to the original frame, just as before. Anything working with ljf, such as InterpreterRuntime::at_unwind(), should function as before. 
> 
> All tiers 1-6 pass, but I can double check all the JVMTI tests specifically, as they are as you say, tricky.

The description might not be detailed enough: we are updating one of the physical registers in a staged leave, but this is only visible to anyone directly inspecting the CPU context, such as a cpu sampler.  Anything logical, working in the JVM, especially ljfs, will work just as before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092045835

From mgronlun at openjdk.org  Thu May 15 22:33:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 22:33:02 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <OxCT9MHiZpeVOVQkq8wKpRJoLkPPPXrp0pnOMfDDZF4=.b6143634-1ec0-4979-a5e2-f0ddf4de6c01@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
 <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>
 <OxCT9MHiZpeVOVQkq8wKpRJoLkPPPXrp0pnOMfDDZF4=.b6143634-1ec0-4979-a5e2-f0ddf4de6c01@github.com>
Message-ID: <AEYLgwrpGxnJ7GpHH1fJkj3gafM8R_d2VattiCmkEAE=.7d8e8c1c-b096-46fc-9321-106f9b923fba@github.com>

On Thu, 15 May 2025 22:28:04 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The intent is to maintain the logical (Java and JVM) view that we have not popped the frame yet, which is why we still save the ljf to the original frame, just as before. Anything working with ljf, such as InterpreterRuntime::at_unwind(), should function as before. 
>> 
>> All tiers 1-6 pass, but I can double check all the JVMTI tests specifically, as they are as you say, tricky.
>
> The description might not be detailed enough: we are updating one of the physical registers in a staged leave, but this is only visible to anyone directly inspecting the CPU context, such as a cpu sampler.  Anything logical, working in the JVM, especially ljfs, will work just as before.

The JVMTI things should have already been done before we start to manipulate the rbp, just like before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092048878

From mgronlun at openjdk.org  Thu May 15 22:38:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 22:38:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <AEYLgwrpGxnJ7GpHH1fJkj3gafM8R_d2VattiCmkEAE=.7d8e8c1c-b096-46fc-9321-106f9b923fba@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
 <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>
 <OxCT9MHiZpeVOVQkq8wKpRJoLkPPPXrp0pnOMfDDZF4=.b6143634-1ec0-4979-a5e2-f0ddf4de6c01@github.com>
 <AEYLgwrpGxnJ7GpHH1fJkj3gafM8R_d2VattiCmkEAE=.7d8e8c1c-b096-46fc-9321-106f9b923fba@github.com>
Message-ID: <qTbw4t1egVbY11UGuJtfLy1iE_XXudoIfCzuxYuTo8M=.1a0a0007-f6e8-4073-bc7b-533f3c1dd2af@github.com>

On Thu, 15 May 2025 22:29:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The description might not be detailed enough: we are updating one of the physical registers in a staged leave, but this is only visible to anyone directly inspecting the CPU context, such as a cpu sampler.  Anything logical, working in the JVM, especially ljfs, will work just as before.
>
> The JVMTI things should have already been done before we start to manipulate the rbp, just like before.

"this_fp" means "this frame's fp", before it moved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092054957

From pchilanomate at openjdk.org  Thu May 15 22:38:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 15 May 2025 22:38:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
Message-ID: <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>

On Thu, 15 May 2025 21:49:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If I recall, which I don't, as it has been too long, the issue here is that since the IP is still in the interpreter, the rbp referenced in the enterSpecial frame links to an EntryFrame, which is not interpreter code. At least, what is linked in the Continuation is Java code, which can also be compiled; in this case, we can handle it. However, the challenge is to move the rbp, knowing that your IP is still in interpreter code. Can I handle that situation? That becomes the question.
>
> So we would just need to check when creating the request if the fp points to the ContinuationEntry, which is easy to do, and if so create the request with the sender (as I see you already do in one of the cases). This will also cover the case where the return pc is the return_barrier, which should in fact be more common than this case.

Also, thinking more about it if we are in the return_barrier case it?s the vthread that will continue executing. So one option could be to still create the request with the sender of the ContinuationEntry and just add a condition when processing it to check if the frame in the request is within the continuation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092054094

From pchilanomate at openjdk.org  Thu May 15 22:55:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 15 May 2025 22:55:53 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
Message-ID: <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>

On Thu, 15 May 2025 22:35:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> So we would just need to check when creating the request if the fp points to the ContinuationEntry, which is easy to do, and if so create the request with the sender (as I see you already do in one of the cases). This will also cover the case where the return pc is the return_barrier, which should in fact be more common than this case.
>
> Also, thinking more about it if we are in the return_barrier case it?s the vthread that will continue executing. So one option could be to still create the request with the sender of the ContinuationEntry and just add a condition when processing it to check if the frame in the request is within the continuation.

Another case we are missing is when we freeze. We should call `Jfr::check_and_process_sample_request` before copying the frames to the heap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092069972

From mgronlun at openjdk.org  Thu May 15 23:07:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 23:07:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
Message-ID: <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>

On Thu, 15 May 2025 22:53:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Also, thinking more about it if we are in the return_barrier case it?s the vthread that will continue executing. So one option could be to still create the request with the sender of the ContinuationEntry and just add a condition when processing it to check if the frame in the request is within the continuation.
>
> Another case we are missing is when we freeze. We should call `Jfr::check_and_process_sample_request` before copying the frames to the heap.

The check, or some version of it, is already in place.

Please check in JfrStackTrace.cpp:

if (method->intrinsic_id() == vmIntrinsicID::_Continuation_enterSpecial) {
    assert(JfrThreadLocal::is_vthread(jt), "invariant");
    const ContinuationEntry* const cont_entry = jt->last_continuation();
    assert(cont_entry != nullptr, "invariant");
    return cont_entry->is_virtual_thread();
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092078727

From mgronlun at openjdk.org  Thu May 15 23:07:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 May 2025 23:07:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
Message-ID: <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>

On Thu, 15 May 2025 23:04:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Another case we are missing is when we freeze. We should call `Jfr::check_and_process_sample_request` before copying the frames to the heap.
>
> The check, or some version of it, is already in place.
> 
> Please check in JfrStackTrace.cpp:
> 
> if (method->intrinsic_id() == vmIntrinsicID::_Continuation_enterSpecial) {
>     assert(JfrThreadLocal::is_vthread(jt), "invariant");
>     const ContinuationEntry* const cont_entry = jt->last_continuation();
>     assert(cont_entry != nullptr, "invariant");
>     return cont_entry->is_virtual_thread();
>   }

> Another case we are missing is when we freeze. We should call `Jfr::check_and_process_sample_request` before copying the frames to the heap.

Where do you suggest to place it best?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092078968

From pchilanomate at openjdk.org  Fri May 16 00:05:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 16 May 2025 00:05:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
Message-ID: <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkWgwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>

On Thu, 15 May 2025 23:05:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The check, or some version of it, is already in place.
>> 
>> Please check in JfrStackTrace.cpp:
>> 
>> if (method->intrinsic_id() == vmIntrinsicID::_Continuation_enterSpecial) {
>>     assert(JfrThreadLocal::is_vthread(jt), "invariant");
>>     const ContinuationEntry* const cont_entry = jt->last_continuation();
>>     assert(cont_entry != nullptr, "invariant");
>>     return cont_entry->is_virtual_thread();
>>   }
>
>> Another case we are missing is when we freeze. We should call `Jfr::check_and_process_sample_request` before copying the frames to the heap.
> 
> Where do you suggest to place it best?

Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092119637

From pchilanomate at openjdk.org  Fri May 16 00:05:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 16 May 2025 00:05:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkWgwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
Message-ID: <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>

On Fri, 16 May 2025 00:01:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> Another case we are missing is when we freeze. We should call `Jfr::check_and_process_sample_request` before copying the frames to the heap.
>> 
>> Where do you suggest to place it best?
>
> Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.

> Where do you suggest to place it best?
>
Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092120587

From fyang at openjdk.org  Fri May 16 05:02:54 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 16 May 2025 05:02:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
Message-ID: <E9wQ45-MK8HtPbh4gnTaeB4xO3W_Ynruw0MsfBijbIs=.92f4d996-c732-44ca-91cc-d6c7e18c608b@github.com>

On Thu, 15 May 2025 16:45:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   growable array constructur without default initialization

Hi, Could you please incorporate this change for riscv? Thanks.
https://github.com/RealFYang/jdk/commit/be8eac493bef865d7825848f0b31a06d95b08efc
This passed `hotspot_serviceability` and `jdk_svc` tests on linux-riscv64 platform with both release and fastdebug builds.

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

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

From mgronlun at openjdk.org  Fri May 16 08:49:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 08:49:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
Message-ID: <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>

On Fri, 16 May 2025 00:02:49 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.
>
>> Where do you suggest to place it best?
>>
> Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.

> Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.

Can you provide me with a technical snippet describing whtat you intend here? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092619809

From mgronlun at openjdk.org  Fri May 16 09:09:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 09:09:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
Message-ID: <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>

On Fri, 16 May 2025 08:47:27 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.

Its only the interpreter that needs special handling for this case, because of the rbp thingy. The JIT should just work as normal. Thats why I stop iff the sampled interpreter frame is enterSpecial and is a termination point for the virtual thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092651895

From eosterlund at openjdk.org  Fri May 16 15:54:55 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 May 2025 15:54:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <qTbw4t1egVbY11UGuJtfLy1iE_XXudoIfCzuxYuTo8M=.1a0a0007-f6e8-4073-bc7b-533f3c1dd2af@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
 <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>
 <OxCT9MHiZpeVOVQkq8wKpRJoLkPPPXrp0pnOMfDDZF4=.b6143634-1ec0-4979-a5e2-f0ddf4de6c01@github.com>
 <AEYLgwrpGxnJ7GpHH1fJkj3gafM8R_d2VattiCmkEAE=.7d8e8c1c-b096-46fc-9321-106f9b923fba@github.com>
 <qTbw4t1egVbY11UGuJtfLy1iE_XXudoIfCzuxYuTo8M=.1a0a0007-f6e8-4073-bc7b-533f3c1dd2af@github.com>
Message-ID: <MsqIetbETS23_mW6SKj4nBK9SThZgfe0WFktskiZmlI=.4b70397e-fb41-4b9d-af09-1b7f5b218245@github.com>

On Thu, 15 May 2025 22:36:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The JVMTI things should have already been done before we start to manipulate the rbp, just like before.
>
> "this_fp" means "this frame's fp", before it moved.

> The JVMTI things should have already been done before we start to manipulate the rbp, just like before.

What I'm worried about is that the new order crashes the JVM when using method exit events and force early return.

What we used to do:
1. You are at a random bytecode that may or may not have an oop in top-of-stack. For the sake of example, let's assume TOS is an int for this particular bytecode.

2. Force early return is invoked, saying "return with this oop". The expression stack is nuked, and the oop is placed top-of-stack. But the oop map for the current BCI says there should not be an oop there, so subsequent safepoint polls (I'm looking at you) are going to destroy the oop.

3. "The only safepoint poll" on the way out of the frame, is the super special method exit JVMTI event. It knows that it's doing something dangerous by safepointing after the early return value is installed. In JvmtiExport::post_method_exit we read the oop before it's destroyed, call out to the JVMTI callback that can safepoint and destroy the oop, and before proceeding it writes the retained and nice oop to the top-of-stack, hence manually avoiding the oop map mismatch.

Since you moved the safepoint poll to after the method exit event handling, it feels like safepointing is going to destroy the top-of-stack oop again, because we assume the oop maps for the BCI we are at are sane, but they are not because of JVMTI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093302245

From mgronlun at openjdk.org  Fri May 16 16:33:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 16:33:53 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <MsqIetbETS23_mW6SKj4nBK9SThZgfe0WFktskiZmlI=.4b70397e-fb41-4b9d-af09-1b7f5b218245@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
 <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>
 <OxCT9MHiZpeVOVQkq8wKpRJoLkPPPXrp0pnOMfDDZF4=.b6143634-1ec0-4979-a5e2-f0ddf4de6c01@github.com>
 <AEYLgwrpGxnJ7GpHH1fJkj3gafM8R_d2VattiCmkEAE=.7d8e8c1c-b096-46fc-9321-106f9b923fba@github.com>
 <qTbw4t1egVbY11UGuJtfLy1iE_XXudoIfCzuxYuTo8M=.1a0a0007-f6e8-4073-bc7b-533f3c1dd2af@github.com>
 <MsqIetbETS23_mW6SKj4nBK9SThZgfe0WFktskiZmlI=.4b70397e-fb41-4b9d-af09-1b7f5b218245@github.com>
Message-ID: <VtYr9JAtKolyJgFuengpaYeibFLFDowrmfc69SH_MD8=.3cece8fc-d4ba-4d70-83aa-6794c7656a6e@github.com>

On Fri, 16 May 2025 15:52:25 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> "this_fp" means "this frame's fp", before it moved.
>
>> The JVMTI things should have already been done before we start to manipulate the rbp, just like before.
> 
> What I'm worried about is that the new order crashes the JVM when using method exit events and force early return.
> 
> What we used to do:
> 1. You are at a random bytecode that may or may not have an oop in top-of-stack. For the sake of example, let's assume TOS is an int for this particular bytecode.
> 
> 2. Force early return is invoked, saying "return with this oop". The expression stack is nuked, and the oop is placed top-of-stack. But the oop map for the current BCI says there should not be an oop there, so subsequent safepoint polls (I'm looking at you) are going to destroy the oop.
> 
> 3. "The only safepoint poll" on the way out of the frame, is the super special method exit JVMTI event. It knows that it's doing something dangerous by safepointing after the early return value is installed. In JvmtiExport::post_method_exit we read the oop before it's destroyed, call out to the JVMTI callback that can safepoint and destroy the oop, and before proceeding it writes the retained and nice oop to the top-of-stack, hence manually avoiding the oop map mismatch.
> 
> Since you moved the safepoint poll to after the method exit event handling, it feels like safepointing is going to destroy the top-of-stack oop again, because we assume the oop maps for the BCI we are at are sane, but they are not because of JVMTI.

Hmm. That is a complicated case indeed. Thanks for explaining it in detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093355529

From eosterlund at openjdk.org  Fri May 16 18:01:56 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 May 2025 18:01:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
Message-ID: <2Hk4RU4Dp_kpas6yMwcQnS6bZgzpFzaFwSXI3SlkyLM=.38955a08-2a19-4493-9361-96f98df310e8@github.com>

On Thu, 15 May 2025 16:45:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   growable array constructur without default initialization

I'm happy with things except ensuring this horrible JVMTI force early return + method exit notification + GC stuff works. I'm off next week, so I'll leave it to someone that enjoys staring at JVMTI code more than I do to validate its correctness, unless this is still under review when I get back.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2847306237

From mgronlun at openjdk.org  Fri May 16 18:58:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 18:58:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <lOxE-OuPtf5XR_b2uXRvFApLbKYEB_tdvqitS7TFdDA=.9e055b20-fc3b-4f31-bc3d-e47d1e48dd73@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <2Hk4RU4Dp_kpas6yMwcQnS6bZgzpFzaFwSXI3SlkyLM=.38955a08-2a19-4493-9361-96f98df310e8@github.com>
 <lOxE-OuPtf5XR_b2uXRvFApLbKYEB_tdvqitS7TFdDA=.9e055b20-fc3b-4f31-bc3d-e47d1e48dd73@github.com>
Message-ID: <d_6rZpK7I3UJRA9IzC-peDiTmpoXUAp8BKGJbOY2FGc=.e6440519-d18b-4217-a7cc-e4998f6d3893@github.com>

On Fri, 16 May 2025 18:54:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I'm happy with things except ensuring this horrible JVMTI force early return + method exit notification + GC stuff works. I'm off next week, so I'll leave it to someone that enjoys staring at JVMTI code more than I do to validate its correctness, unless this is still under review when I get back.
>
>> I'm happy with things except ensuring this horrible JVMTI force early return + method exit notification + GC stuff works. I'm off next week, so I'll leave it to someone that enjoys staring at JVMTI code more than I do to validate its correctness, unless this is still under review when I get back.
> 
> Thanks so much for your help Erik. I am juggling some alternatives so see what we can do here.

> @mgronlun: I don't think I can get the top frame hiding trick to work on PPC64. What we need to do is to hide the top interpreter frame from the sampler after the return safepoint check, right? If I hide it from the sampler, I will also hide it from the concurrent thread stack processing code. And that causes errors. I think the top frame hiding trick only works on platforms which use an FP register. Platforms like PPC64 and s390 don't have that. Can we use a different mechanism to prevent the sampler from taking snapshots between the return safepoint check and the frame pop? E.g., we could set a field in the JavaThread before the safepoint check and clear it after the frame pop. The sampler would have to discard samples when the JavaThread's field is set.

Thanks Martin,

I am elaborating some alternative implementation ideas to help (dis)solve this.

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

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

From mgronlun at openjdk.org  Fri May 16 18:57:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 18:57:59 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <2Hk4RU4Dp_kpas6yMwcQnS6bZgzpFzaFwSXI3SlkyLM=.38955a08-2a19-4493-9361-96f98df310e8@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <2Hk4RU4Dp_kpas6yMwcQnS6bZgzpFzaFwSXI3SlkyLM=.38955a08-2a19-4493-9361-96f98df310e8@github.com>
Message-ID: <lOxE-OuPtf5XR_b2uXRvFApLbKYEB_tdvqitS7TFdDA=.9e055b20-fc3b-4f31-bc3d-e47d1e48dd73@github.com>

On Fri, 16 May 2025 17:58:57 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> I'm happy with things except ensuring this horrible JVMTI force early return + method exit notification + GC stuff works. I'm off next week, so I'll leave it to someone that enjoys staring at JVMTI code more than I do to validate its correctness, unless this is still under review when I get back.

Thanks so much for your help Erik. I am juggling some alternatives so see what we can do here.

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

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

From pchilanomate at openjdk.org  Fri May 16 20:15:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 16 May 2025 20:15:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
 <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
Message-ID: <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>

On Fri, 16 May 2025 09:05:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>>> Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.
>> 
>> Can you provide me with a technical snippet describing whtat you intend here? Thanks.
>
>> Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.
> 
> Its only the interpreter that needs special handling for this case, because of the rbp thingy. The JIT should just work as normal. Thats why I stop iff the sampled interpreter frame is enterSpecial and is a termination point for the virtual thread.

So there are two things here. My original comment was about the fact that enterSpecial always sets rbp so we shouldn?t need this special handling. The value fetched from the current rbp should give the same result, even for the return_barrier case (for which we currently do no special handling already). 

Then the other question is what kind of request will be created if we are in this case (rbp pointing to ContinuationEntry) and making sure it will be processed correctly later. If we are sampling after changing rbp to the ContinuationEntry in remove_activation, when building the request I see the pc will check for an interpreted frame and that `is_valid_interpreter_frame()` will also check. Then when processing the request, if this was a return_barrier case and we are still in the vthread context, in `compute_sender_frame()` we will eventually return the sender frame of enterSpecial and invalidate the request. Then we just proceed to record the stacktrace starting from this frame. So unless I missed something seems we need an extra check here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093624541

From mgronlun at openjdk.org  Fri May 16 21:03:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 21:03:03 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v24]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <A-DF3qabQBoF4KXymDLjvP3OUGkBRObK9ySsvBSe4ns=.4a08d26e-4e8f-4258-b764-cafadaefe910@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  additional checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/fdefd35e..71c284ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=22-23

  Stats: 24 lines in 3 files changed: 21 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Fri May 16 22:17:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 22:17:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
 <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
 <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>
Message-ID: <7TpSjJpmr2NBKyyQTbbNGeKz92YaMzKErireHTIsRq8=.52235f96-1914-4eb0-8146-908e4ce28344@github.com>

On Fri, 16 May 2025 20:13:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> Thanks. So if we create the request as mentioned before I?m not sure that check will do it. I see it?s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.
>> 
>> Its only the interpreter that needs special handling for this case, because of the rbp thingy. The JIT should just work as normal. Thats why I stop iff the sampled interpreter frame is enterSpecial and is a termination point for the virtual thread.
>
> So there are two things here. My original comment was about the fact that enterSpecial always sets rbp so we shouldn?t need this special handling. The value fetched from the current rbp should give the same result, even for the return_barrier case (for which we currently do no special handling already). 
> 
> Then the other question is what kind of request will be created if we are in this case (rbp pointing to ContinuationEntry) and making sure it will be processed correctly later. If we are sampling after changing rbp to the ContinuationEntry in remove_activation, when building the request I see the pc will check for an interpreted frame and that `is_valid_interpreter_frame()` will also check. Then when processing the request, if this was a return_barrier case and we are still in the vthread context, in `compute_sender_frame()` we will eventually return the sender frame of enterSpecial and invalidate the request. Then we just proceed to record the stacktrace starting from this frame. So unless I missed something seems we need an extra check for this.

That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).

My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote  NUMA node to boot.

Can you help me think out how to handle the Continuation specific things in parsing here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093729472

From mgronlun at openjdk.org  Fri May 16 22:17:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 22:17:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <svpb-OIEcqq1d6UtPv3amLClraDVglsC_dpXYjO9T4k=.93e98a40-eac6-4020-a56a-821b8d62160f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <3z-gmWorKXSpMqwM7eGn2jbEmpWxjg87Z2HOGTH3g0U=.cdc1a5ad-3696-4e9b-8985-22c13c920507@github.com>
 <svpb-OIEcqq1d6UtPv3amLClraDVglsC_dpXYjO9T4k=.93e98a40-eac6-4020-a56a-821b8d62160f@github.com>
Message-ID: <jm_u_p0SAuyJPDONwKuT7ewWaYktjH2sxvCl5gDZHeY=.844dee5e-e30e-4b72-8a17-7cc617eba29c@github.com>

On Thu, 15 May 2025 22:02:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Some subtleties are involved in SharedRuntime::generate_native_wrapper(). There are a few things to keep in mind there. First, the adapter is not part of the JIT code itself, it will not resolve to the nmethod, it will resolve to an AdapterStub. This is for the case where we take the CPU context directly. Some other aspects involved here are that the thread transitions to both thread in native and thread in native trans - during that time, the thread is ineligible for a Java sample. But, as is the case now, the thread transitions back to thread in Java, and there is still a valid ljf - so a sample could happen here, taking the ljf. Therefore, a poll needs to occur before issuing the return, or the reset ljf must happen before we return to Java, which is what I think I did for sampling accuracy. I will need to dig into that branch to find out.
>
> Excellent observation, Patricio, thank you for pointing this out.

Added an nmethod after unwind-poll check for the SharedRuntime::generate_native_wrapper() code to capture this race.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093731151

From mgronlun at openjdk.org  Fri May 16 22:17:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 22:17:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <7TpSjJpmr2NBKyyQTbbNGeKz92YaMzKErireHTIsRq8=.52235f96-1914-4eb0-8146-908e4ce28344@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
 <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
 <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>
 <7TpSjJpmr2NBKyyQTbbNGeKz92YaMzKErireHTIsRq8=.52235f96-1914-4eb0-8146-908e4ce28344@github.com>
Message-ID: <3VnPExZIw_l0F28PD_TNDtvEMH4q0W1taXb2bUsFcv4=.24335dc3-8eb5-4cdb-b98b-b93ecf2e0d8e@github.com>

On Fri, 16 May 2025 22:11:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> So there are two things here. My original comment was about the fact that enterSpecial always sets rbp so we shouldn?t need this special handling. The value fetched from the current rbp should give the same result, even for the return_barrier case (for which we currently do no special handling already). 
>> 
>> Then the other question is what kind of request will be created if we are in this case (rbp pointing to ContinuationEntry) and making sure it will be processed correctly later. If we are sampling after changing rbp to the ContinuationEntry in remove_activation, when building the request I see the pc will check for an interpreted frame and that `is_valid_interpreter_frame()` will also check. Then when processing the request, if this was a return_barrier case and we are still in the vthread context, in `compute_sender_frame()` we will eventually return the sender frame of enterSpecial and invalidate the request. Then we just proceed to record the stacktrace starting from this frame. So unless I missed something seems we need an extra check for this.
>
> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
> 
> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote  NUMA node to boot.
> 
> Can you help me think out how to handle the Continuation specific things in parsing here?

> > Where do you suggest to place it best?
> 
> Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.

Fixed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093730190

From mgronlun at openjdk.org  Fri May 16 22:17:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 16 May 2025 22:17:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <BtpMcY9v0r8LFQzgvRB-8zgKIkwHSkIFq3U8GIn8wdQ=.073ed83e-1d1b-460c-92b8-7a41734d7f40@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <iWmW14dKXWcI3VLGN8ELwIXOH1SSJbvVCeWJ5qHmh6M=.e4f0bd8a-6b67-47a2-87dc-f1175322efc6@github.com>
 <BtpMcY9v0r8LFQzgvRB-8zgKIkwHSkIFq3U8GIn8wdQ=.073ed83e-1d1b-460c-92b8-7a41734d7f40@github.com>
Message-ID: <rmXSYLY8Xza2KndPxsudp6BjQ_VSSDwI346iaPTceJg=.40365a2f-9f12-45dc-96b6-2c6068f18cd6@github.com>

On Thu, 15 May 2025 21:55:08 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> That would, of course, be ideal, but I don't think there exists any abstraction to read the current bcp from the ucontext_t, abstracting it for all platforms.
>
> We know which register we use in each platform so it should be same as getting any other register. You can always fallback to getting it from the frame as now for platforms other than x64 and aarch64.

I will try to see what can be done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093731977

From egahlin at openjdk.org  Sun May 18 13:45:31 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 18 May 2025 13:45:31 GMT
Subject: RFR: 8357187: JFR: User-defined defaults should be respected when an
 incorrect setting is set
Message-ID: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>

Could I have a review of PR that fixes user-defined default values for event settings?

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Remove comments
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25291/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25291&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357187
  Stats: 82 lines in 6 files changed: 63 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25291/head:pull/25291

PR: https://git.openjdk.org/jdk/pull/25291

From egahlin at openjdk.org  Sun May 18 13:53:06 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 18 May 2025 13:53:06 GMT
Subject: RFR: 8357187: JFR: User-defined defaults should be respected when
 an incorrect setting is set [v2]
In-Reply-To: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>
References: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>
Message-ID: <Fy0CxHwKJqNMJCrKfnqL9D2REbeMBljCXogfJXVhq5o=.0a390914-b771-4a1d-9e70-ed4dd39d48a9@github.com>

> Could I have a review of PR that fixes user-defined default values for event settings?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Remove 'off' comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25291/files
  - new: https://git.openjdk.org/jdk/pull/25291/files/ecd1b22b..184d65a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25291&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25291&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25291/head:pull/25291

PR: https://git.openjdk.org/jdk/pull/25291

From shade at openjdk.org  Mon May 19 08:07:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 May 2025 08:07:54 GMT
Subject: RFR: 8356968: JFR: Compilation event should be enabled for all
 compilations by default
In-Reply-To: <DrLQVr28TCYSa3AEksZ0SuutMfQe9Lu30nRltnTG6KY=.2a4fec9d-9854-4cb8-b6e0-73d3b9337e28@github.com>
References: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
 <DrLQVr28TCYSa3AEksZ0SuutMfQe9Lu30nRltnTG6KY=.2a4fec9d-9854-4cb8-b6e0-73d3b9337e28@github.com>
Message-ID: <C74ttjduFag0CHdzIK8d4s_et-Iq1g1ABHURvQq7CDs=.19b98a9a-935c-42fb-a13f-78fcd0e68558@github.com>

On Thu, 15 May 2025 09:22:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. 
>> 
>> It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high.
>> 
>> Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0.
>> 
>> See more logs in the bug itself.
>> 
>> Additional testing:
>>  - [x] Ad-hoc tests with printing compilation events
>>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`
>
> The overhead of the event is low, I believe, but I think the concern was that too many events were generated with little value to the end user. The buffers will be filled, and other, more important events will be pushed out. That said, there are probably other JVM events, i.e., low-level GC or runtime events, that are on by default, which may be less interesting than the compilation event.
> 
> `jfr summary` lists the number of events and how much space they take up.
> 
> Maybe we should reprioritize them?

@egahlin -- does summary analysis alleviate your concern about event overheads?

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

PR Comment: https://git.openjdk.org/jdk/pull/25247#issuecomment-2890039307

From egahlin at openjdk.org  Mon May 19 08:18:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 May 2025 08:18:51 GMT
Subject: RFR: 8356968: JFR: Compilation event should be enabled for all
 compilations by default
In-Reply-To: <DrLQVr28TCYSa3AEksZ0SuutMfQe9Lu30nRltnTG6KY=.2a4fec9d-9854-4cb8-b6e0-73d3b9337e28@github.com>
References: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
 <DrLQVr28TCYSa3AEksZ0SuutMfQe9Lu30nRltnTG6KY=.2a4fec9d-9854-4cb8-b6e0-73d3b9337e28@github.com>
Message-ID: <ilQkr50dG8Rb0WOeZm4P2xmpms4SF530J0Mfzb8yIgU=.ca96ffdd-9226-4f2d-9549-c7def410e4ba@github.com>

On Thu, 15 May 2025 09:22:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. 
>> 
>> It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high.
>> 
>> Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0.
>> 
>> See more logs in the bug itself.
>> 
>> Additional testing:
>>  - [x] Ad-hoc tests with printing compilation events
>>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`
>
> The overhead of the event is low, I believe, but I think the concern was that too many events were generated with little value to the end user. The buffers will be filled, and other, more important events will be pushed out. That said, there are probably other JVM events, i.e., low-level GC or runtime events, that are on by default, which may be less interesting than the compilation event.
> 
> `jfr summary` lists the number of events and how much space they take up.
> 
> Maybe we should reprioritize them?

> @egahlin -- does summary analysis alleviate your concern about event overheads?

No, some applications load new classes all the time. This is why we have the Class Load event turned off by default as well. We have over 150 events, so the budget per event is small.

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

PR Comment: https://git.openjdk.org/jdk/pull/25247#issuecomment-2890072527

From egahlin at openjdk.org  Mon May 19 08:45:33 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 May 2025 08:45:33 GMT
Subject: RFR: 8357187: JFR: User-defined defaults should be respected when
 an incorrect setting is set [v3]
In-Reply-To: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>
References: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>
Message-ID: <whz1C2dapg2CduRKElh5TL2DH17ckloQNx4Y21G-oTI=.53b000c6-8626-4f00-bc28-a13794a35c2b@github.com>

> Could I have a review of PR that fixes user-defined default values for event settings?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Use validRate() method for ThrottleSetting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25291/files
  - new: https://git.openjdk.org/jdk/pull/25291/files/184d65a3..b634faa9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25291&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25291&range=01-02

  Stats: 18 lines in 1 file changed: 9 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25291/head:pull/25291

PR: https://git.openjdk.org/jdk/pull/25291

From mgronlun at openjdk.org  Mon May 19 13:18:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 19 May 2025 13:18:51 GMT
Subject: RFR: 8357187: JFR: User-defined defaults should be respected when
 an incorrect setting is set [v3]
In-Reply-To: <whz1C2dapg2CduRKElh5TL2DH17ckloQNx4Y21G-oTI=.53b000c6-8626-4f00-bc28-a13794a35c2b@github.com>
References: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>
 <whz1C2dapg2CduRKElh5TL2DH17ckloQNx4Y21G-oTI=.53b000c6-8626-4f00-bc28-a13794a35c2b@github.com>
Message-ID: <S-9ctxUfmBL8r2IpauDTal46CQIjGZgFlLstA_lqBac=.1001809d-2e53-46c9-ba84-6564be992f8b@github.com>

On Mon, 19 May 2025 08:45:33 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of PR that fixes user-defined default values for event settings?
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use validRate() method for ThrottleSetting

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25291#pullrequestreview-2850737189

From egahlin at openjdk.org  Mon May 19 13:41:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 May 2025 13:41:59 GMT
Subject: Integrated: 8357187: JFR: User-defined defaults should be respected
 when an incorrect setting is set
In-Reply-To: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>
References: <faC65ZiAsu24byKDJ2A5yy9PIpstUWaf1lSBZZ-JXOI=.d468eb39-8af2-45a3-80a0-f06286429c90@github.com>
Message-ID: <3tF473MYBIpdmu-LhAHtRyG0rZUHxeWO3kNlVSSDDA0=.f31a0780-eba2-4cfb-9811-8727e09f36df@github.com>

On Sun, 18 May 2025 13:36:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes user-defined default values for event settings?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 265d6301
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/265d630125db448ba0cdc3ab7e938beb50e93ed0
Stats:     85 lines in 6 files changed: 65 ins; 4 del; 16 mod

8357187: JFR: User-defined defaults should be respected when an incorrect setting is set

Reviewed-by: mgronlun

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

PR: https://git.openjdk.org/jdk/pull/25291

From mgronlun at openjdk.org  Mon May 19 13:42:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 19 May 2025 13:42:47 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v25]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <roAUobAO7MnhN9R0atmHs1tZaDI2dk0D5wKiOn57JlY=.4a70a4d9-6fad-4281-aa30-b2033d269451@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  Redesign to avoid the pre-emptive fp move in the interpreter. Replace with a thread-local critical section sampling interrupt mask.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/71c284ae..4eb81314

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=23-24

  Stats: 674 lines in 33 files changed: 167 ins; 439 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mdoerr at openjdk.org  Mon May 19 14:11:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 19 May 2025 14:11:41 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v25]
In-Reply-To: <roAUobAO7MnhN9R0atmHs1tZaDI2dk0D5wKiOn57JlY=.4a70a4d9-6fad-4281-aa30-b2033d269451@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <roAUobAO7MnhN9R0atmHs1tZaDI2dk0D5wKiOn57JlY=.4a70a4d9-6fad-4281-aa30-b2033d269451@github.com>
Message-ID: <GBA7nW3TgDKUw1-RuhjZ5G1mnQBgH-OYMkze8tAvINw=.7214e935-2867-40d1-a3d2-a7c54b721057@github.com>

On Mon, 19 May 2025 13:42:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redesign to avoid the pre-emptive fp move in the interpreter. Replace with a thread-local critical section sampling interrupt mask.

Thank you so much! This is probably very helpful. I had planned to do some experiments on my own, but I was too busy with other issues.
I wonder if we really need memory barriers. The Java threads get suspended before we take a sample, right? So, I think the suspension mechanism should already prevent reordering of memory accesses.
I'll try it on PPC64 as soon as I find some time.

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

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

From mgronlun at openjdk.org  Mon May 19 14:18:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 19 May 2025 14:18:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v25]
In-Reply-To: <GBA7nW3TgDKUw1-RuhjZ5G1mnQBgH-OYMkze8tAvINw=.7214e935-2867-40d1-a3d2-a7c54b721057@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <roAUobAO7MnhN9R0atmHs1tZaDI2dk0D5wKiOn57JlY=.4a70a4d9-6fad-4281-aa30-b2033d269451@github.com>
 <GBA7nW3TgDKUw1-RuhjZ5G1mnQBgH-OYMkze8tAvINw=.7214e935-2867-40d1-a3d2-a7c54b721057@github.com>
Message-ID: <T93D-ULhBOpNZMf3L3jLpTOmYk7nhkKutpCRBFQjf24=.255c70f0-5e7f-4df7-87e5-f7d912e3ec81@github.com>

On Mon, 19 May 2025 14:06:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thank you so much! This is probably very helpful. I had planned to do some experiments on my own, but I was too busy with other issues. I wonder if we really need memory barriers. The Java threads get suspended before we take a sample, right? So, I think the suspension mechanism should already prevent reordering of memory accesses. I'll try it on PPC64 as soon as I find some time.

I was going to ping you about the updates, but you saw them already :)

The initial store load barrier is to prevent the safepoint poll from floating up, the other is to ensure the fp is moved before the crit sec release. Defensive, I know.

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

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

From mgronlun at openjdk.org  Mon May 19 14:11:41 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 19 May 2025 14:11:41 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v26]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <qU1yd8iKPsA0SlBcbOvpT41MZfnw7gwL8bkdGhzkFes=.9fd2d5a9-888e-4726-b3e7-6f3be66dc1e9@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  No platform specific changes needed for javaFrameAnchor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/4eb81314..46566a9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=24-25

  Stats: 16 lines in 5 files changed: 6 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Mon May 19 15:24:18 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 19 May 2025 15:24:18 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v27]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  leave jfr critsec after leave()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/46566a9b..9a179164

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=25-26

  Stats: 31 lines in 6 files changed: 18 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From egahlin at openjdk.org  Mon May 19 15:29:57 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 May 2025 15:29:57 GMT
Subject: Withdrawn: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <IJErhA0y4fcc-LMiz2WhK7trZw2jtcdMH-mKsbnAaEs=.e8e297a7-ed20-48cc-b8c5-7de55197bf74@github.com>
References: <IJErhA0y4fcc-LMiz2WhK7trZw2jtcdMH-mKsbnAaEs=.e8e297a7-ed20-48cc-b8c5-7de55197bf74@github.com>
Message-ID: <NoRQV6BBnyMJkOZ8dyoHZYHVyhRc7e0shhgfDVAMPho=.4e45db9f-c9bf-415a-be98-f8d36ac2937f@github.com>

On Mon, 24 Mar 2025 17:25:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr 
> 
> Thanks
> Erik

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/24205

From egahlin at openjdk.org  Mon May 19 15:42:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 May 2025 15:42:59 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
Message-ID: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>

Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.

Testing: tier 1-3, test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25306/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352738
  Stats: 7100 lines in 109 files changed: 6640 ins; 363 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From mgronlun at openjdk.org  Mon May 19 15:43:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 19 May 2025 15:43:00 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <L02Z-ljCR0Sa8feBJhRKhbK0H9a2eAx02gjAd1oMtr0=.ac80b8a5-be67-40e2-bf13-fd56495be5f1@github.com>

On Mon, 19 May 2025 15:24:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Great work, Erik!

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25306#pullrequestreview-2851236031

From mdoerr at openjdk.org  Tue May 20 15:44:00 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 20 May 2025 15:44:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v27]
In-Reply-To: <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>
Message-ID: <9JuikNPJed0zYSZzHebTe5hHY-pF1gAjCwSnAGJLhXs=.2e3e36fa-94b0-4e8c-b032-a0fd0c78e900@github.com>

On Mon, 19 May 2025 15:24:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   leave jfr critsec after leave()

Heads-up: I'm currently testing the PPC64 implementation: https://github.com/TheRealMDoerr/jdk/commit/9b9f0bfc06d63110d99ef32553a0dff58cf69136
Note that I'm not using memory barriers. I'm relying on synchronization by the suspend/resume mechanism (as well as the signal handler in case of async profiler). Especially the StoreLoad barrier in the remove_activation code has probably interpreter performance impact.

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

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

From mgronlun at openjdk.org  Tue May 20 16:16:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 16:16:05 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v27]
In-Reply-To: <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>
Message-ID: <xBqfGXn5x1Bu4y8oaNF2KG4vGidosHsL7pj9ZhXmjg8=.4b0bb9cb-ab7b-462b-8942-9c2d79e4e7e8@github.com>

On Mon, 19 May 2025 15:24:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   leave jfr critsec after leave()

> Heads-up: I'm currently testing the PPC64 implementation: [TheRealMDoerr at 9b9f0bf](https://github.com/TheRealMDoerr/jdk/commit/9b9f0bfc06d63110d99ef32553a0dff58cf69136) Note that I'm not using memory barriers. I'm relying on synchronization by the suspend/resume mechanism (as well as the signal handler in case of async profiler). Especially the StoreLoad barrier in the remove_activation code has probably interpreter performance impact.

That is great news Martin! Thanks for testing without the barriers. If you are ok without them on PPC, they are most likely not needed on any other platform.

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

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

From pchilanomate at openjdk.org  Tue May 20 16:25:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 20 May 2025 16:25:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v27]
In-Reply-To: <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>
Message-ID: <j-xs7l3Rzn94bu8_NKUckGV8Dhd8MjGg7GlFgbrGP7Q=.63275e07-210a-4bea-9cb0-8139054e0b2b@github.com>

On Mon, 19 May 2025 15:24:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   leave jfr critsec after leave()

I like the new simpler approach too. I agree that we shouldn?t need extra fences though. The sampling is done while the target is suspended so everything up to the pc in the context should have been executed and everything after will be executed on resume.

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

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

From pchilanomate at openjdk.org  Tue May 20 16:25:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 20 May 2025 16:25:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <3VnPExZIw_l0F28PD_TNDtvEMH4q0W1taXb2bUsFcv4=.24335dc3-8eb5-4cdb-b98b-b93ecf2e0d8e@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
 <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
 <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>
 <7TpSjJpmr2NBKyyQTbbNGeKz92YaMzKErireHTIsRq8=.52235f96-1914-4eb0-8146-908e4ce28344@github.com>
 <3VnPExZIw_l0F28PD_TNDtvEMH4q0W1taXb2bUsFcv4=.24335dc3-8eb5-4cdb-b98b-b93ecf2e0d8e@github.com>
Message-ID: <r_5YfoTxWPiGMb9o8HclgCHoYzkUtMDRR12DF05itJA=.1fd0b4ad-c90b-406e-aed1-dd8d78683a9a@github.com>

On Fri, 16 May 2025 22:12:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
>> 
>> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote  NUMA node to boot.
>> 
>> Can you help me think out how to handle the Continuation specific things in parsing here?
>
>> > Where do you suggest to place it best?
>> 
>> Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.
> 
> Fixed. Thanks.

> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
> 
> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote NUMA node to boot.
> 
> Can you help me think out how to handle the Continuation specific things in parsing here?
>
Ok, no need to bring it to cache since this has been fixed (modulo the extra check discussed) with the new approach. : )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2098390449

From pchilanomate at openjdk.org  Tue May 20 16:25:57 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 20 May 2025 16:25:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <r_5YfoTxWPiGMb9o8HclgCHoYzkUtMDRR12DF05itJA=.1fd0b4ad-c90b-406e-aed1-dd8d78683a9a@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
 <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
 <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>
 <7TpSjJpmr2NBKyyQTbbNGeKz92YaMzKErireHTIsRq8=.52235f96-1914-4eb0-8146-908e4ce28344@github.com>
 <3VnPExZIw_l0F28PD_TNDtvEMH4q0W1taXb2bUsFcv4=.24335dc3-8eb5-4cdb-b98b-b93ecf2e0d8e@github.com>
 <r_5YfoTxWPiGMb9o8HclgCHoYzkUtMDRR12DF05itJA=.1fd0b4ad-c90b-406e-aed1-dd8d78683a9a@github.com>
Message-ID: <yBI-yR4W07ahY0PPlWxQR0LlEBxuEfl1NNB8nmXrVIw=.5605b018-efb8-41d6-993e-b24e7c5f6cbb@github.com>

On Tue, 20 May 2025 16:21:46 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> > Where do you suggest to place it best?
>>> 
>>> Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.
>> 
>> Fixed. Thanks.
>
>> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
>> 
>> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote NUMA node to boot.
>> 
>> Can you help me think out how to handle the Continuation specific things in parsing here?
>>
> Ok, no need to bring it to cache since this has been fixed (modulo the extra check discussed) with the new approach. : )

> > > Where do you suggest to place it best?
> > 
> > 
> > Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.
> 
> Fixed. Thanks.
>
Thanks. Ideally we would avoid the extra overhead for the freeze fast path. We could always force the slow path when creating the sample request by setting _cont_fastpath_thread_state, which currently is only used for JVMTI to force the slow path on interpreted only mode. But I could take care of that as a follow up if you want. Can we inline the has_sample_request() check to avoid the call on the common case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2098392703

From mgronlun at openjdk.org  Tue May 20 16:35:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 16:35:06 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <yBI-yR4W07ahY0PPlWxQR0LlEBxuEfl1NNB8nmXrVIw=.5605b018-efb8-41d6-993e-b24e7c5f6cbb@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
 <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
 <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>
 <7TpSjJpmr2NBKyyQTbbNGeKz92YaMzKErireHTIsRq8=.52235f96-1914-4eb0-8146-908e4ce28344@github.com>
 <3VnPExZIw_l0F28PD_TNDtvEMH4q0W1taXb2bUsFcv4=.24335dc3-8eb5-4cdb-b98b-b93ecf2e0d8e@github.com>
 <r_5YfoTxWPiGMb9o8HclgCHoYzkUtMDRR12DF05itJA=.1fd0b4ad-c90b-406e-aed1-dd8d78683a9a@github.com>
 <yBI-yR4W07ahY0PPlWxQR0LlEBxuEfl1NNB8nmXrVIw=.5605b018-efb8-41d6-993e-b24e7c5f6cbb@github.com>
Message-ID: <0fxKzh-tgbmKPGDJ0Sp5FLj8G2JvOLxDrhYqgMfvU_E=.7609255a-5a5b-42e4-a4b7-8f448da220dd@github.com>

On Tue, 20 May 2025 16:22:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
>>> 
>>> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote NUMA node to boot.
>>> 
>>> Can you help me think out how to handle the Continuation specific things in parsing here?
>>>
>> Ok, no need to bring it to cache since this has been fixed (modulo the extra check discussed) with the new approach. : )
>
>> > > Where do you suggest to place it best?
>> > 
>> > 
>> > Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.
>> 
>> Fixed. Thanks.
>>
> Thanks. Ideally we would avoid the extra overhead for the freeze fast path. We could always force the slow path when creating the sample request by setting _cont_fastpath_thread_state, which currently is only used for JVMTI to force the slow path on interpreted only mode. But I could take care of that as a follow up if you want. Can we inline the has_sample_request() check to avoid the call on the common case?

> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
> 
> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote NUMA node to boot.
> 
> Can you help me think out how to handle the Continuation specific things in parsing here?

We reasoned out a way to accomplish this. But not only that, there is actually a way to write ALL sample requests, by selecting the thread id as a function of the sampled frame. This means a mounted vthread will be able to write a sample and attribute it correctly to its carrier thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2098410555

From mgronlun at openjdk.org  Tue May 20 16:44:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 16:44:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <0fxKzh-tgbmKPGDJ0Sp5FLj8G2JvOLxDrhYqgMfvU_E=.7609255a-5a5b-42e4-a4b7-8f448da220dd@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <ablxTTAB5sXVKD6ovZT9H4iRa3a6lyPjVrp19DGi3Mk=.58bba30b-ac9d-4eb0-831f-ce644fdb772d@github.com>
 <W0IvWDvPdyM-H82cAYNUI5M_JOWX1sUBTiHsDAjZ_VA=.1ea1befd-138f-45e6-93b6-06ce0cabdbcd@github.com>
 <cco97IoiE_nquy3Z9kGsB0y0hK4ehxlVqX0Tsgk6hGQ=.ce8fddbc-54a7-4c0b-b2cd-83ecf9226208@github.com>
 <BZPJyMfxAYk3n1OLF2erm4iipmfKnWzF_xUxDgWUGoQ=.d9ddddf7-b0d6-4199-8a1e-2e8e866d6b31@github.com>
 <3PjoZKUhJkZuuUx3C9u2FK0BVBNsZi18c4VWchBobTk=.26302b7d-59d1-4002-bc1a-7e422f63be6c@github.com>
 <nE2Iz2vPOB4e2ZxOh79_YuB8EBBJUxroQMGBlHaJwxE=.1f00e2f4-66b4-4ca5-b028-30657c5339cb@github.com>
 <BLtBVuES6lnxehcob1U3wMOzkFirKwWKH4_pc2KvZOE=.90c5e290-0c1e-4e52-b809-2d444522d8d7@github.com>
 <kQOxUpeh8Apjc_1hJnIFfLYykNaFWOefmkW
 gwEjLye8=.16d6a02f-f6a3-4268-b151-4ae4ab868c0b@github.com>
 <ovJ70lddHYd95OykyIpt9tqjWXNPVTsXDWTDIlQttAw=.1c083c13-941f-4c6b-ad9f-73285a8a80f4@github.com>
 <jIm-O9FcVAWHOcBKvUpaWXVqEP6esknSlyrGtIxW3OY=.a73103b4-d008-48d9-88f1-7a7c226e44db@github.com>
 <K-hBP7xAgEESljDgqGPlA8_c_mTM4Xa6BeujkSbB8xA=.59c35d1d-5390-4938-8476-1e188fec887c@github.com>
 <HksmrDD2Uw9uHBeLfZtSQ2q7n193-0MsNStSQqHOceY=.f1d6354b-7f3a-4657-8337-e6715ec83eba@github.com>
 <7TpSjJpmr2NBKyyQTbbNGeKz92YaMzKErireHTIsRq8=.52235f96-1914-4eb0-8146-908e4ce28344@github.com>
 <3VnPExZIw_l0F28PD_TNDtvEMH4q0W1taXb2bUsFcv4=.24335dc3-8eb5-4cdb-b98b-b93ecf2e0d8e@github.com>
 <r_5YfoTxWPiGMb9o8HclgCHoYzkUtMDRR12DF05itJA=.1fd0b4ad-c90b-406e-aed1-dd8d78683a9a@github.com>
 <yBI-yR4W07ahY0PPlWxQR0LlEBxuEfl1NNB8nmXrVIw=.5605b018-efb8-41d6-993e-b24e7c5f6cbb@github.com>
 <0fxKzh-tgbmKPGDJ0Sp5FLj8G2JvOLxDrhYqgMfvU_E=.7609255a-5a5b-42e4-a4b7-8f448da220dd@github.com>
Message-ID: <6EC2LTN0hcgPrLpiV1QeydWvtpExqmNQwNJkUiq0eUM=.c4cb5d36-3c4f-40a7-a162-08b275ba2e58@github.com>

On Tue, 20 May 2025 16:30:31 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>>> > > Where do you suggest to place it best?
>>> > 
>>> > 
>>> > Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.
>>> 
>>> Fixed. Thanks.
>>>
>> Thanks. Ideally we would avoid the extra overhead for the freeze fast path. We could always force the slow path when creating the sample request by setting _cont_fastpath_thread_state, which currently is only used for JVMTI to force the slow path on interpreted only mode. But I could take care of that as a follow up if you want. Can we inline the has_sample_request() check to avoid the call on the common case?
>
>> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
>> 
>> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote NUMA node to boot.
>> 
>> Can you help me think out how to handle the Continuation specific things in parsing here?
> 
> We reasoned out a way to accomplish this. But not only that, there is actually a way to write ALL sample requests, by selecting the thread id as a function of the sampled frame. This means a mounted vthread will be able to write a sample and attribute it correctly to its carrier thread.

> > > > Where do you suggest to place it best?
> > > 
> > > 
> > > Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.
> > 
> > 
> > Fixed. Thanks.
> 
> Thanks. Ideally we would avoid the extra overhead for the freeze fast path. We could always force the slow path when creating the sample request by setting _cont_fastpath_thread_state, which currently is only used for JVMTI to force the slow path on interpreted only mode. But I could take care of that as a follow up if you want. Can we inline the has_sample_request() check to avoid the call on the common case?

Yes, I will try to see what can be done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2098435447

From mgronlun at openjdk.org  Tue May 20 19:28:44 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 19:28:44 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v28]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <0HqJzaVPr2I8dnYqqZXuON5x-q1iCxMqiue7JDFHK1o=.82af2b28-156a-4821-a9af-6f0a61b486b4@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  Attribute sample to correct thread id as a function of frame

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/9a179164..d3b2c3eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=26-27

  Stats: 114 lines in 8 files changed: 44 ins; 36 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Tue May 20 21:09:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 21:09:17 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v29]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <KNrYQGkHClzVosJ7Fmi-OLpfywu9pMu81OH6ZQpVyEM=.6c405f46-03f6-49cb-8c57-497c645f0282@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  Parameter reordering and inlining

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/d3b2c3eb..b33c08ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=27-28

  Stats: 79 lines in 13 files changed: 49 ins; 15 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Tue May 20 21:24:16 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 21:24:16 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v30]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <myU4h62UtoaVBWHLuUJZgTvAMstEfK3CJE_ynKWBYp0=.33019492-f4c6-49d1-bd9f-965fdac3b6c5@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/b33c08ad..e7e6678a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=28-29

  Stats: 44 lines in 1 file changed: 0 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Tue May 20 21:24:16 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 21:24:16 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <VtYr9JAtKolyJgFuengpaYeibFLFDowrmfc69SH_MD8=.3cece8fc-d4ba-4d70-83aa-6794c7656a6e@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <kmZ5lWQOc3_GBaqb9acWjp9V0oR1_xlqwLLSKRhNfso=.e20a8d39-1061-4661-bdba-ef466f3a46b9@github.com>
 <TZg0XlNsc8RfYyugChNm6Mm5dOCKvoayF-TmhsH4BqI=.35b18651-6bb7-4037-9c55-f031204e2240@github.com>
 <OxCT9MHiZpeVOVQkq8wKpRJoLkPPPXrp0pnOMfDDZF4=.b6143634-1ec0-4979-a5e2-f0ddf4de6c01@github.com>
 <AEYLgwrpGxnJ7GpHH1fJkj3gafM8R_d2VattiCmkEAE=.7d8e8c1c-b096-46fc-9321-106f9b923fba@github.com>
 <qTbw4t1egVbY11UGuJtfLy1iE_XXudoIfCzuxYuTo8M=.1a0a0007-f6e8-4073-bc7b-533f3c1dd2af@github.com>
 <MsqIetbETS23_mW6SKj4nBK9SThZgfe0WFktskiZmlI=.4b70397e-fb41-4b9d-af09-1b7f5b218245@github.com>
 <VtYr9JAtKolyJgFuengpaYeibFLFDowrmfc69SH_MD8=.3cece8fc-d4ba-4d70-83aa-6794c7656a6e@github.com>
Message-ID: <FCxTVHKhyhVL9hhfjv5k97icDGyHS2w1F1OnPUxcfQI=.01d78d55-7cbd-4d5a-9e62-9c8d4a8ad2e7@github.com>

On Fri, 16 May 2025 16:30:49 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>>> The JVMTI things should have already been done before we start to manipulate the rbp, just like before.
>> 
>> What I'm worried about is that the new order crashes the JVM when using method exit events and force early return.
>> 
>> What we used to do:
>> 1. You are at a random bytecode that may or may not have an oop in top-of-stack. For the sake of example, let's assume TOS is an int for this particular bytecode.
>> 
>> 2. Force early return is invoked, saying "return with this oop". The expression stack is nuked, and the oop is placed top-of-stack. But the oop map for the current BCI says there should not be an oop there, so subsequent safepoint polls (I'm looking at you) are going to destroy the oop.
>> 
>> 3. "The only safepoint poll" on the way out of the frame, is the super special method exit JVMTI event. It knows that it's doing something dangerous by safepointing after the early return value is installed. In JvmtiExport::post_method_exit we read the oop before it's destroyed, call out to the JVMTI callback that can safepoint and destroy the oop, and before proceeding it writes the retained and nice oop to the top-of-stack, hence manually avoiding the oop map mismatch.
>> 
>> Since you moved the safepoint poll to after the method exit event handling, it feels like safepointing is going to destroy the top-of-stack oop again, because we assume the oop maps for the BCI we are at are sane, but they are not because of JVMTI.
>
> Hmm. That is a complicated case indeed. Thanks for explaining it in detail.

The safepoint poll check has been hoisted before the JVMTI stuff.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2098896624

From mgronlun at openjdk.org  Tue May 20 21:24:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 21:24:17 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
Message-ID: <x9HO3cukYiluEJeHyGkpqjvuVW03C5lso-z6Q4Ondo4=.9da2b1c0-a9ab-4b27-a8c2-53dd698b98d8@github.com>

On Thu, 15 May 2025 16:49:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   growable array constructur without default initialization
>
> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 91:
> 
>> 89: static inline address continuation_frame_sender_pc(void* sp) {
>> 90:   assert(sp != nullptr, "invariant");
>> 91:   return static_cast<address>(sp) + (ContinuationEntry::size() + wordSize);
> 
> Seems we are missing a dereference.

Thanks for noting this. It has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2098893937

From mgronlun at openjdk.org  Tue May 20 21:30:19 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 21:30:19 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v31]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <z39nU5MOJ8JgGdync2NFaA7YK99fDjGvCqNhjgpe4_k=.ccb8901a-388e-421d-8e2a-8a3eab1c4ba4@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Merge branch 'master' into 8352251
 - whitespace
 - Parameter reordering and inlining
 - Attribute sample to correct thread id as a function of frame
 - leave jfr critsec after leave()
 - No platform specific changes needed for javaFrameAnchor
 - Redesign to avoid the pre-emptive fp move in the interpreter. Replace with a thread-local critical section sampling interrupt mask.
 - additional checks
 - growable array constructur without default initialization
 - validate_bcp
 - ... and 25 more: https://git.openjdk.org/jdk/compare/cedd1a53...e4d3f78b

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=30
  Stats: 3233 lines in 75 files changed: 1959 ins; 950 del; 324 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Tue May 20 22:32:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 May 2025 22:32:47 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  skip level mismatch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/e4d3f78b..7d4c3e5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=30-31

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Wed May 21 10:44:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 10:44:01 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
Message-ID: <-hhrsRy3MadVDVJoQs2chfkrBWrH-LebAyu6EGlH7MQ=.0e30fb30-fc8e-4dc5-84ce-d238824cdcb2@github.com>

On Tue, 20 May 2025 22:32:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip level mismatch

> Hi, Could you please incorporate this change for riscv? Thanks. [RealFYang at be8eac4](https://github.com/RealFYang/jdk/commit/be8eac493bef865d7825848f0b31a06d95b08efc) This passed `hotspot_serviceability` and `jdk_svc` tests on linux-riscv64 platform with both release and fastdebug builds.

Thanks a lot for the patch.

Unfortunately we changed direction a bit after you submitted it, because of implementation difficulties on other platforms.

Can you please take a look at the new and simpler version?

Thanks
Markus

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

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

From shade at openjdk.org  Wed May 21 11:05:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 11:05:01 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
Message-ID: <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>

On Tue, 20 May 2025 22:32:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip level mismatch

I am taking a look how to unbreak Minimal and Zero again.

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

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

From mgronlun at openjdk.org  Wed May 21 11:13:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 11:13:01 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>
Message-ID: <vLy-qeTMzCuuYX-vN_FitqPY-u7frcqi2vVmkJOp7ck=.6d39699d-14d6-455b-85c9-62fdb7d0a238@github.com>

On Wed, 21 May 2025 11:02:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am taking a look how to unbreak Minimal and Zero again.

Hmm. I thought JFR was not defined for Zero?

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

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

From shade at openjdk.org  Wed May 21 11:19:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 11:19:04 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <vLy-qeTMzCuuYX-vN_FitqPY-u7frcqi2vVmkJOp7ck=.6d39699d-14d6-455b-85c9-62fdb7d0a238@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>
 <vLy-qeTMzCuuYX-vN_FitqPY-u7frcqi2vVmkJOp7ck=.6d39699d-14d6-455b-85c9-62fdb7d0a238@github.com>
Message-ID: <jZP-yCbpnl4Sg2hK0nRPuIydBhaaBA6AyvMi7O31c2Y=.bda15637-1f0a-4ea5-ab24-5e2da686e9b3@github.com>

On Wed, 21 May 2025 11:10:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > I am taking a look how to unbreak Minimal and Zero again.
> 
> Hmm. I thought JFR was not defined for Zero?

Yes. But there is an instance of the fairly common `#if` vs `#ifdef` trap here:


diff --git a/src/hotspot/share/runtime/safepointMechanism.cpp b/src/hotspot/share/runtime/safepointMechanism.cpp
index 57fbc9078c8..d4160161f19 100644
--- a/src/hotspot/share/runtime/safepointMechanism.cpp
+++ b/src/hotspot/share/runtime/safepointMechanism.cpp
@@ -32,7 +32,7 @@
 #include "runtime/safepointMechanism.inline.hpp"
 #include "runtime/stackWatermarkSet.hpp"
 #include "utilities/globalDefinitions.hpp"
-#ifdef INCLUDE_JFR
+#if INCLUDE_JFR
 #include "jfr/jfr.inline.hpp"
 #endif


"No JFR" is `#define INCLUDE_JFR 0`. Which means `#if INCLUDE_JFR` == `false`, but `#ifdef INCLUDE_JFR` == `true`.

The patch above fixes both Minimal and Zero Hotspot fastdebug builds for me locally. I am running full builds now.

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

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

From mgronlun at openjdk.org  Wed May 21 11:26:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 11:26:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <jZP-yCbpnl4Sg2hK0nRPuIydBhaaBA6AyvMi7O31c2Y=.bda15637-1f0a-4ea5-ab24-5e2da686e9b3@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>
 <vLy-qeTMzCuuYX-vN_FitqPY-u7frcqi2vVmkJOp7ck=.6d39699d-14d6-455b-85c9-62fdb7d0a238@github.com>
 <jZP-yCbpnl4Sg2hK0nRPuIydBhaaBA6AyvMi7O31c2Y=.bda15637-1f0a-4ea5-ab24-5e2da686e9b3@github.com>
Message-ID: <SFyhsylu-7zCl0a2YTQ3GjwO3ixf5Eb_kmUo8NC6zgE=.671ecef8-c573-4959-b675-9ffeb56696de@github.com>

On Wed, 21 May 2025 11:15:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > I am taking a look how to unbreak Minimal and Zero again.
> > 
> > 
> > Hmm. I thought JFR was not defined for Zero?
> 
> Yes. But there is an instance of the fairly common `#if` vs `#ifdef` trap here:
> 
> ```
> diff --git a/src/hotspot/share/runtime/safepointMechanism.cpp b/src/hotspot/share/runtime/safepointMechanism.cpp
> index 57fbc9078c8..d4160161f19 100644
> --- a/src/hotspot/share/runtime/safepointMechanism.cpp
> +++ b/src/hotspot/share/runtime/safepointMechanism.cpp
> @@ -32,7 +32,7 @@
>  #include "runtime/safepointMechanism.inline.hpp"
>  #include "runtime/stackWatermarkSet.hpp"
>  #include "utilities/globalDefinitions.hpp"
> -#ifdef INCLUDE_JFR
> +#if INCLUDE_JFR
>  #include "jfr/jfr.inline.hpp"
>  #endif
> ```
> 
> "No JFR" is `#define INCLUDE_JFR 0`. Which means `#if INCLUDE_JFR` == `false`, but `#ifdef INCLUDE_JFR` == `true`.
> 
> The patch above fixes both Minimal and Zero Hotspot fastdebug builds for me locally. I am running full builds now.

Arghh...that old crap again...

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

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

From mgronlun at openjdk.org  Wed May 21 11:26:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 11:26:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <SFyhsylu-7zCl0a2YTQ3GjwO3ixf5Eb_kmUo8NC6zgE=.671ecef8-c573-4959-b675-9ffeb56696de@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>
 <vLy-qeTMzCuuYX-vN_FitqPY-u7frcqi2vVmkJOp7ck=.6d39699d-14d6-455b-85c9-62fdb7d0a238@github.com>
 <jZP-yCbpnl4Sg2hK0nRPuIydBhaaBA6AyvMi7O31c2Y=.bda15637-1f0a-4ea5-ab24-5e2da686e9b3@github.com>
 <SFyhsylu-7zCl0a2YTQ3GjwO3ixf5Eb_kmUo8NC6zgE=.671ecef8-c573-4959-b675-9ffeb56696de@github.com>
Message-ID: <CKAmbY-Yh_DitKm3eD9b6P8Fwq4QwhfH81l3Mf27iN8=.8d5a8063-50a5-4687-a2e3-468ebb2eb5bd@github.com>

On Wed, 21 May 2025 11:23:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> diff --git a/src/hotspot/share/runtime/safepointMechanism.cpp b/src/hotspot/share/runtime/safepointMechanism.cpp
> index 57fbc9078c8..d4160161f19 100644
> --- a/src/hotspot/share/runtime/safepointMechanism.cpp
> +++ b/src/hotspot/share/runtime/safepointMechanism.cpp
> @@ -32,7 +32,7 @@
>  #include "runtime/safepointMechanism.inline.hpp"
>  #include "runtime/stackWatermarkSet.hpp"
>  #include "utilities/globalDefinitions.hpp"
> -#ifdef INCLUDE_JFR
> +#if INCLUDE_JFR
>  #include "jfr/jfr.inline.hpp"
>  #endif

I'll fix it - thanks for locating this, Aleksey.

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

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

From mgronlun at openjdk.org  Wed May 21 11:32:33 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 11:32:33 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v33]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  if vs ifdef apa

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/7d4c3e5a..d3aed1e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=31-32

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From shade at openjdk.org  Wed May 21 11:48:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 May 2025 11:48:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <SFyhsylu-7zCl0a2YTQ3GjwO3ixf5Eb_kmUo8NC6zgE=.671ecef8-c573-4959-b675-9ffeb56696de@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>
 <vLy-qeTMzCuuYX-vN_FitqPY-u7frcqi2vVmkJOp7ck=.6d39699d-14d6-455b-85c9-62fdb7d0a238@github.com>
 <jZP-yCbpnl4Sg2hK0nRPuIydBhaaBA6AyvMi7O31c2Y=.bda15637-1f0a-4ea5-ab24-5e2da686e9b3@github.com>
 <SFyhsylu-7zCl0a2YTQ3GjwO3ixf5Eb_kmUo8NC6zgE=.671ecef8-c573-4959-b675-9ffeb56696de@github.com>
Message-ID: <MXE3Got8AYLJMp5COE8tPUSRdmUK29Oe2X_fEnDkvJ0=.39d83af9-c291-4a2a-b813-a27250d20974@github.com>

On Wed, 21 May 2025 11:23:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> The patch above fixes both Minimal and Zero Hotspot fastdebug builds for me locally. I am running full builds now.

Yeah, that's apparently it. Full Minimal/Zero fastdebug builds pass. GHA seems happy as well.

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

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

From mgronlun at openjdk.org  Wed May 21 11:53:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 11:53:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <MXE3Got8AYLJMp5COE8tPUSRdmUK29Oe2X_fEnDkvJ0=.39d83af9-c291-4a2a-b813-a27250d20974@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <3MiOlPWgW_0vfBp_B9-3_mMlnBkaNeCdljyL9a8MibM=.08949c7c-3e05-4c4f-99e3-f69e89f8a523@github.com>
 <vLy-qeTMzCuuYX-vN_FitqPY-u7frcqi2vVmkJOp7ck=.6d39699d-14d6-455b-85c9-62fdb7d0a238@github.com>
 <jZP-yCbpnl4Sg2hK0nRPuIydBhaaBA6AyvMi7O31c2Y=.bda15637-1f0a-4ea5-ab24-5e2da686e9b3@github.com>
 <SFyhsylu-7zCl0a2YTQ3GjwO3ixf5Eb_kmUo8NC6zgE=.671ecef8-c573-4959-b675-9ffeb56696de@github.com>
 <MXE3Got8AYLJMp5COE8tPUSRdmUK29Oe2X_fEnDkvJ0=.39d83af9-c291-4a2a-b813-a27250d20974@github.com>
Message-ID: <nHFt7F-TO500un7mV7KwNakRcEFeDHJ2Y75LEWsEOlM=.01b3e324-1ef1-441a-bf49-460108a75f2f@github.com>

On Wed, 21 May 2025 11:46:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > The patch above fixes both Minimal and Zero Hotspot fastdebug builds for me locally. I am running full builds now.
> 
> Yeah, that's apparently it. Full Minimal/Zero fastdebug builds pass. GHA seems happy as well.

Thank you.

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

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

From egahlin at openjdk.org  Wed May 21 13:46:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 21 May 2025 13:46:52 GMT
Subject: RFR: 8356945: jdk/jfr/event/os/TestProcessStart failed on Windows
 Subsystem for Linux
In-Reply-To: <JmcdTTm4wegEVhzdOreG9PvsuDshSTjjPfHBFg9d32s=.0b13ab29-37c0-43c0-a765-7160c400717a@github.com>
References: <JmcdTTm4wegEVhzdOreG9PvsuDshSTjjPfHBFg9d32s=.0b13ab29-37c0-43c0-a765-7160c400717a@github.com>
Message-ID: <pvfzTwBZaITD0K-DEvu_c2CYLG_9NSHqZ2mxuOb9-lY=.90171bd2-9fcc-4bfa-b114-541d5d9d21f3@github.com>

On Wed, 14 May 2025 13:48:42 GMT, Chihiro Ito <cito at openjdk.org> wrote:

> Currently, when this test is run on Windows Subsystem for Linux, dir is executed as an external process.
> However, dir is a cmd.exe command, and dir.exe does not exist, so the test fails as shown below.
> 
> ----------System.out:(0/0)----------
> ----------System.err:(19/2649)*----------
> java.io.IOException: Cannot run program "dir" (in directory "D:\\dev\\jdk\\build\\windows-x86_64-server-release\\test-support\\jtreg_test_jdk_jdk_jfr_event_os_TestProcessStart_java\\scratch\\0\."): CreateProcess error=2, The system cannot find the file specified

Looks reasonable

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

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25227#pullrequestreview-2857798121

From cito at openjdk.org  Wed May 21 14:07:55 2025
From: cito at openjdk.org (Chihiro Ito)
Date: Wed, 21 May 2025 14:07:55 GMT
Subject: Integrated: 8356945: jdk/jfr/event/os/TestProcessStart failed on
 Windows Subsystem for Linux
In-Reply-To: <JmcdTTm4wegEVhzdOreG9PvsuDshSTjjPfHBFg9d32s=.0b13ab29-37c0-43c0-a765-7160c400717a@github.com>
References: <JmcdTTm4wegEVhzdOreG9PvsuDshSTjjPfHBFg9d32s=.0b13ab29-37c0-43c0-a765-7160c400717a@github.com>
Message-ID: <KMF3u6F7pz5YoNEtb1MGlNQbVLO8gttRnzu4z6QwKJI=.ad9ba413-d511-4471-bfa0-601640897c64@github.com>

On Wed, 14 May 2025 13:48:42 GMT, Chihiro Ito <cito at openjdk.org> wrote:

> Currently, when this test is run on Windows Subsystem for Linux, dir is executed as an external process.
> However, dir is a cmd.exe command, and dir.exe does not exist, so the test fails as shown below.
> 
> ----------System.out:(0/0)----------
> ----------System.err:(19/2649)*----------
> java.io.IOException: Cannot run program "dir" (in directory "D:\\dev\\jdk\\build\\windows-x86_64-server-release\\test-support\\jtreg_test_jdk_jdk_jfr_event_os_TestProcessStart_java\\scratch\\0\."): CreateProcess error=2, The system cannot find the file specified

This pull request has now been integrated.

Changeset: b63ec0ab
Author:    Chihiro Ito <cito at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b63ec0ab584cb941b44a39b6ff130224ed444b60
Stats:     4 lines in 1 file changed: 2 ins; 1 del; 1 mod

8356945: jdk/jfr/event/os/TestProcessStart failed on Windows Subsystem for Linux

Reviewed-by: egahlin

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

PR: https://git.openjdk.org/jdk/pull/25227

From mdoerr at openjdk.org  Wed May 21 15:55:05 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 May 2025 15:55:05 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v27]
In-Reply-To: <xBqfGXn5x1Bu4y8oaNF2KG4vGidosHsL7pj9ZhXmjg8=.4b0bb9cb-ab7b-462b-8942-9c2d79e4e7e8@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <-yrxn_9REmGxiNAZaOYWMEjCUyQ6G7d6wR2RIkZFDrY=.a4c241d7-da69-4c81-a9d2-b448b9bf899f@github.com>
 <xBqfGXn5x1Bu4y8oaNF2KG4vGidosHsL7pj9ZhXmjg8=.4b0bb9cb-ab7b-462b-8942-9c2d79e4e7e8@github.com>
Message-ID: <LohYAqrWVUkEmHCh6rXsDpoSJznbLFjxgZjS95mGsZs=.522e945b-0e24-469a-b634-fb067f2897a4@github.com>

On Tue, 20 May 2025 16:13:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > Heads-up: I'm currently testing the PPC64 implementation: [TheRealMDoerr at 9b9f0bf](https://github.com/TheRealMDoerr/jdk/commit/9b9f0bfc06d63110d99ef32553a0dff58cf69136) Note that I'm not using memory barriers. I'm relying on synchronization by the suspend/resume mechanism (as well as the signal handler in case of async profiler). Especially the StoreLoad barrier in the remove_activation code has probably interpreter performance impact.
> 
> That is great news Martin! Thanks for testing without the barriers. If you are ok without them on PPC, they are most likely not needed on any other platform.

Updated version (`InterpreterRuntime::at_unwind` before `notify_method_exit`): https://github.com/TheRealMDoerr/jdk/commit/20826e59b088e42cda50008b4a91b5895e0630b3

I have seen intermittent failures in TestResidentSetSizeEvent.java:

java.lang.RuntimeException: Should be non-zero: expected 0 > 0
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
	at jdk.jfr.event.runtime.TestResidentSetSizeEvent.verifyExpectedEventTypes(TestResidentSetSizeEvent.java:81)
	at jdk.jfr.event.runtime.TestResidentSetSizeEvent.main(TestResidentSetSizeEvent.java:92)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

I don't see any relationship to my changes. Could be related to large pages on the machine.

I'll try more tests.

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

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

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

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

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

PR: https://git.openjdk.org/jdk/pull/25368

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

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

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From mdoerr at openjdk.org  Wed May 21 21:46:56 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 May 2025 21:46:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v33]
In-Reply-To: <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
Message-ID: <fqTCe2KubQdJBCD4eVFbcsiXj96SZmPjroIRTTl1cQk=.4ae82818-d23e-4b62-83d4-e990fc762a53@github.com>

On Wed, 21 May 2025 11:32:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   if vs ifdef apa

We can escape here before `leave_jfr_critical_section`: https://github.com/openjdk/jdk/blob/d3aed1e7365d7934e439fff3956ae2ca4b5d4269/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L645
Is that ok for exceptions?

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

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

From mgronlun at openjdk.org  Wed May 21 21:54:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 21:54:38 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  fetch bcp from context

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/d3aed1e7..e502b84b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=32-33

  Stats: 199 lines in 15 files changed: 186 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Wed May 21 21:54:39 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 21:54:39 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v33]
In-Reply-To: <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
Message-ID: <GD7RbHvPmyQx4zRwTmRWULiAxyvfOODGOXFcIoNMjJo=.a66111e4-2bd5-4db0-a009-081484f199b0@github.com>

On Wed, 21 May 2025 11:32:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   if vs ifdef apa

Porter's note: with
[fetch bcp from context](https://github.com/openjdk/jdk/pull/24296/commits/e502b84b82678a5cbc27fff73752e70c3c9bf180)

Your platform has received this stub:

intptr_t* os::fetch_bcp_from_context(const void* ucVoid) {
  Unimplemented();
  return nullptr;
}

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

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

From mgronlun at openjdk.org  Wed May 21 21:59:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 21:59:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v33]
In-Reply-To: <fqTCe2KubQdJBCD4eVFbcsiXj96SZmPjroIRTTl1cQk=.4ae82818-d23e-4b62-83d4-e990fc762a53@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
 <fqTCe2KubQdJBCD4eVFbcsiXj96SZmPjroIRTTl1cQk=.4ae82818-d23e-4b62-83d4-e990fc762a53@github.com>
Message-ID: <luxkkGG2p_vjZrnPnaZVD1ptLWvPfWYeK0eDtyc7RgQ=.23d2c452-3af4-4aa3-b9cf-77f7a7e91b34@github.com>

On Wed, 21 May 2025 21:44:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We can escape here before `leave_jfr_critical_section`:
> 
> https://github.com/openjdk/jdk/blob/d3aed1e7365d7934e439fff3956ae2ca4b5d4269/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L645
> 
> Is that ok for exceptions?

Need to check but might need a leave_critical section in  InterpreterRuntime::throw_delayed_StackOverflowError.

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

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

From mgronlun at openjdk.org  Wed May 21 22:07:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 22:07:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
In-Reply-To: <rmXSYLY8Xza2KndPxsudp6BjQ_VSSDwI346iaPTceJg=.40365a2f-9f12-45dc-96b6-2c6068f18cd6@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <K12kWX7hAh4rYYCrhw_jbDd6HEJiAmgeylxFuHF3q2M=.9e98de9f-2cb6-4f01-bc73-6c2e71efed28@github.com>
 <djeNSD9KL_MqSz0T_CIPSSQSQq-KuqZHAcHTEcSmGQc=.c202326d-142b-4c32-b317-738a3e7ca837@github.com>
 <iWmW14dKXWcI3VLGN8ELwIXOH1SSJbvVCeWJ5qHmh6M=.e4f0bd8a-6b67-47a2-87dc-f1175322efc6@github.com>
 <BtpMcY9v0r8LFQzgvRB-8zgKIkwHSkIFq3U8GIn8wdQ=.073ed83e-1d1b-460c-92b8-7a41734d7f40@github.com>
 <rmXSYLY8Xza2KndPxsudp6BjQ_VSSDwI346iaPTceJg=.40365a2f-9f12-45dc-96b6-2c6068f18cd6@github.com>
Message-ID: <CucaUJXdEX-lgnBmMP7Crh9EvKq8aRsOVScSSdYpyXA=.a2b0abf2-993d-4353-ba04-6a2df9513962@github.com>

On Fri, 16 May 2025 22:15:25 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> We know which register we use in each platform so it should be same as getting any other register. You can always fallback to getting it from the frame as now for platforms other than x64 and aarch64.
>
> I will try to see what can be done.

Getting the bcp from the cpu context as per [fetch bcp from context](https://github.com/openjdk/jdk/pull/24296/commits/e502b84b82678a5cbc27fff73752e70c3c9bf180)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2101253319

From mgronlun at openjdk.org  Wed May 21 22:26:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 May 2025 22:26:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v33]
In-Reply-To: <luxkkGG2p_vjZrnPnaZVD1ptLWvPfWYeK0eDtyc7RgQ=.23d2c452-3af4-4aa3-b9cf-77f7a7e91b34@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
 <fqTCe2KubQdJBCD4eVFbcsiXj96SZmPjroIRTTl1cQk=.4ae82818-d23e-4b62-83d4-e990fc762a53@github.com>
 <luxkkGG2p_vjZrnPnaZVD1ptLWvPfWYeK0eDtyc7RgQ=.23d2c452-3af4-4aa3-b9cf-77f7a7e91b34@github.com>
Message-ID: <xT8sD6owIcBu3f5UzXMyj5H3YcLtXG_kaGjYOyT9ta0=.5b7da165-1357-47e9-a14b-42bd681b4346@github.com>

On Wed, 21 May 2025 21:57:36 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > We can escape here before `leave_jfr_critical_section`:
> > https://github.com/openjdk/jdk/blob/d3aed1e7365d7934e439fff3956ae2ca4b5d4269/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L645
> > 
> > Is that ok for exceptions?
> 
> Need to check but might need a leave_critical section in InterpreterRuntime::throw_delayed_StackOverflowError.

Will also, again, study in detail JVMTI PopFrame and ForceEarlyReturn to ensure it plays with the new model.

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

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

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <wrtUfsbfcWNXz5eMaykcIbLOPC5019cvCsig_cLn7L4=.bd0dab1a-ad1e-465c-852b-8fb66d81f401@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From kbarrett at openjdk.org  Thu May 22 06:22:32 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 22 May 2025 06:22:32 GMT
Subject: RFR: 8356016: Build fails by clang(XCode 16.3) on macOS after
 JDK-8347719
Message-ID: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>

Please review this change to avoid a forbidden function warning when building
with Xcode 16.3.  (Note: There's no warning with Xcode 16.2 or earlier.)

The jfr/test_networkUtilization.cpp gtest uses several C++ standard library
containers. There is a change in the standard library in Xcode 16.3 that
exposes a call to `free` in the header, and we normally forbid the direct use
of that function.

To address this problem we surround the `#includes` for standard library
container headers with `BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS`, suppressing any
such warnings from them.

While there, also made a few minor cleanups to that file's header usage.

Testing: mach5 tier1.
Built macosx-aarch64 with Xcode 16.3.

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

Commit messages:
 - cleanup includes

Changes: https://git.openjdk.org/jdk/pull/25380/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25380&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356016
  Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25380/head:pull/25380

PR: https://git.openjdk.org/jdk/pull/25380

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
 <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
Message-ID: <JR9YcwtR6e9rtwHNRjzrc_f3vDzGlX5P7HbsynNMOmQ=.58dcd998-ff73-4547-b619-1ba8fa12bd7d@github.com>

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <cRfyJRr23DS3mw4U7XMBE6rBHXIWxlQiEcNpKG-wZBw=.6a7bcbb9-9cb6-45dc-8ce6-40fefbd328ff@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/25368

From aph at openjdk.org  Thu May 22 08:13:03 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 22 May 2025 08:13:03 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
Message-ID: <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>

On Wed, 21 May 2025 21:54:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fetch bcp from context

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 673:

> 671:   strb(rscratch1, sampling_critical_section);
> 672:   membar(Assembler::StoreLoad);
> 673: }

Which store and load accesses does this StoreLoad fence separate?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2101922797

From shade at openjdk.org  Thu May 22 08:47:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 08:47:51 GMT
Subject: RFR: 8356016: Build fails by clang(XCode 16.3) on macOS after
 JDK-8347719
In-Reply-To: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>
References: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>
Message-ID: <ZjNBN0vvxHd2JDYq54ke3qXMrHIf6BA591RIp3knY1Q=.fe0ce145-8d19-4321-8a57-93812af7a22e@github.com>

On Thu, 22 May 2025 06:17:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to avoid a forbidden function warning when building
> with Xcode 16.3.  (Note: There's no warning with Xcode 16.2 or earlier.)
> 
> The jfr/test_networkUtilization.cpp gtest uses several C++ standard library
> containers. There is a change in the standard library in Xcode 16.3 that
> exposes a call to `free` in the header, and we normally forbid the direct use
> of that function.
> 
> To address this problem we surround the `#includes` for standard library
> container headers with `BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS`, suppressing any
> such warnings from them.
> 
> While there, also made a few minor cleanups to that file's header usage.
> 
> Testing: mach5 tier1.
> Built macosx-aarch64 with Xcode 16.3.

Looks fine, as long as test still compiles and works.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25380#pullrequestreview-2860343263

From mgronlun at openjdk.org  Thu May 22 09:40:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 09:40:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
 <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>
Message-ID: <S8VaTu2OZfmx0ZTYJfX6Npba679HPqijHGZ65NdZNWM=.595873b4-0a1f-46a2-9853-51aca1e85b1b@github.com>

On Thu, 22 May 2025 08:10:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fetch bcp from context
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 673:
> 
>> 671:   strb(rscratch1, sampling_critical_section);
>> 672:   membar(Assembler::StoreLoad);
>> 673: }
> 
> Which store and load accesses does this StoreLoad fence separate?

The crit sec to be stored before the poll test is issued.

Most likely not needed, because of implicit fences involved in thread suspension.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2102108634

From aph at openjdk.org  Thu May 22 10:26:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 22 May 2025 10:26:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <S8VaTu2OZfmx0ZTYJfX6Npba679HPqijHGZ65NdZNWM=.595873b4-0a1f-46a2-9853-51aca1e85b1b@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
 <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>
 <S8VaTu2OZfmx0ZTYJfX6Npba679HPqijHGZ65NdZNWM=.595873b4-0a1f-46a2-9853-51aca1e85b1b@github.com>
Message-ID: <-KApfpU-SEhxFdL4Co7etH8D0xFrb3lAl6tIeA9WAl8=.75c7a92d-28aa-43d8-9dcb-fa907213121c@github.com>

On Thu, 22 May 2025 09:38:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> The crit sec to be stored before the poll test is issued.
> 
> Most likely not needed, because of implicit fences involved in thread suspension.

OK, but reading `sampling_critical_section` doesn't seem to have any synchronization at all, so it doesn't much matter what you do when writing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2102212913

From shade at openjdk.org  Thu May 22 10:40:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 10:40:00 GMT
Subject: RFR: 8337789: JEP 509: JFR CPU-Time Profiling (Experimental) [v3]
In-Reply-To: <vi1b4ZQMnv0D_EY87SHq8QLMXkjAgrGPuuKpELiZGms=.b862565e-7a27-47f1-8dde-9b2435332753@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <vi1b4ZQMnv0D_EY87SHq8QLMXkjAgrGPuuKpELiZGms=.b862565e-7a27-47f1-8dde-9b2435332753@github.com>
Message-ID: <LOXIxlt9XOdrNo-omVJqaHe9gOdfqPlyX2DQvEN1_Qo=.c385d8fe-0169-4090-ae86-f942018376ba@github.com>

On Mon, 19 May 2025 17:06:09 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tests

You need to make a JEP sub-task and put the PR under it. Bots would rightfully disallow PRs for the root JEP issue :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2900736851

From shade at openjdk.org  Thu May 22 10:42:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 10:42:53 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <hAlod-puN4GvlyWPwCHGZ0PrfFcsIAfD0YOeK9tIAx0=.a3bcf118-116d-419f-80b9-f564904ba573@github.com>

On Mon, 19 May 2025 15:24:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

May want to say `/jep JEP-520` as well :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25306#issuecomment-2900745743

From mgronlun at openjdk.org  Thu May 22 11:05:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 11:05:02 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <-KApfpU-SEhxFdL4Co7etH8D0xFrb3lAl6tIeA9WAl8=.75c7a92d-28aa-43d8-9dcb-fa907213121c@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
 <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>
 <S8VaTu2OZfmx0ZTYJfX6Npba679HPqijHGZ65NdZNWM=.595873b4-0a1f-46a2-9853-51aca1e85b1b@github.com>
 <-KApfpU-SEhxFdL4Co7etH8D0xFrb3lAl6tIeA9WAl8=.75c7a92d-28aa-43d8-9dcb-fa907213121c@github.com>
Message-ID: <f6aNUpPpPZM93aKCgVAkk87U1jzZOl_sP5GdbvWV_9c=.137f9cb1-fc81-48af-868b-47d64f18e191@github.com>

On Thu, 22 May 2025 10:24:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The crit sec to be stored before the poll test is issued.
>> 
>> Most likely not needed, because of implicit fences involved in thread suspension.
>
>> The crit sec to be stored before the poll test is issued.
>> 
>> Most likely not needed, because of implicit fences involved in thread suspension.
> 
> OK, but reading `sampling_critical_section` doesn't seem to have any synchronization at all, so it doesn't much matter what you do when writing it.

Reading is only done when the thread is suspended. However, I need to know that the critical section is set before the poll.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2102277194

From mgronlun at openjdk.org  Thu May 22 11:05:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 11:05:03 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <f6aNUpPpPZM93aKCgVAkk87U1jzZOl_sP5GdbvWV_9c=.137f9cb1-fc81-48af-868b-47d64f18e191@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
 <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>
 <S8VaTu2OZfmx0ZTYJfX6Npba679HPqijHGZ65NdZNWM=.595873b4-0a1f-46a2-9853-51aca1e85b1b@github.com>
 <-KApfpU-SEhxFdL4Co7etH8D0xFrb3lAl6tIeA9WAl8=.75c7a92d-28aa-43d8-9dcb-fa907213121c@github.com>
 <f6aNUpPpPZM93aKCgVAkk87U1jzZOl_sP5GdbvWV_9c=.137f9cb1-fc81-48af-868b-47d64f18e191@github.com>
Message-ID: <4uXjYYm6_8VcxnjdJExdRIKdifbFMYJL6qC3HrlL38U=.c3da0410-eb57-445d-89d5-69923bc9d039@github.com>

On Thu, 22 May 2025 11:00:31 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>>> The crit sec to be stored before the poll test is issued.
>>> 
>>> Most likely not needed, because of implicit fences involved in thread suspension.
>> 
>> OK, but reading `sampling_critical_section` doesn't seem to have any synchronization at all, so it doesn't much matter what you do when writing it.
>
> Reading is only done when the thread is suspended. However, I need to know that the critical section is set before the poll.

The suspension mechanism should serialize all memory so that it appears to be set when read upon suspension.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2102279740

From mgronlun at openjdk.org  Thu May 22 11:21:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 11:21:54 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v35]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <uRu_T0nX6BUr1A_mJNZyJR_MwcUF7XxszY743mboPyU=.9a00352b-60c9-4a7a-b4b2-b01e0c70b459@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  remove barriers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/e502b84b..cc8719f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=33-34

  Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Thu May 22 11:21:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 11:21:55 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <4uXjYYm6_8VcxnjdJExdRIKdifbFMYJL6qC3HrlL38U=.c3da0410-eb57-445d-89d5-69923bc9d039@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
 <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>
 <S8VaTu2OZfmx0ZTYJfX6Npba679HPqijHGZ65NdZNWM=.595873b4-0a1f-46a2-9853-51aca1e85b1b@github.com>
 <-KApfpU-SEhxFdL4Co7etH8D0xFrb3lAl6tIeA9WAl8=.75c7a92d-28aa-43d8-9dcb-fa907213121c@github.com>
 <f6aNUpPpPZM93aKCgVAkk87U1jzZOl_sP5GdbvWV_9c=.137f9cb1-fc81-48af-868b-47d64f18e191@github.com>
 <4uXjYYm6_8VcxnjdJExdRIKdifbFMYJL6qC3HrlL38U=.c3da0410-eb57-445d-89d5-69923bc9d039@github.com>
Message-ID: <ytERdV6spKbl7LVhPjbeSm2Pv2xo3nM7dX5uaZXuwkI=.d6e62d54-b000-4fe8-92ba-1e7d6f2ab060@github.com>

On Thu, 22 May 2025 11:02:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Reading is only done when the thread is suspended. However, I need to know that the critical section is set before the poll.
>
> The suspension mechanism should serialize all memory so that it appears to be set when read upon suspension.

Barriers now removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2102306975

From shade at openjdk.org  Thu May 22 12:35:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 12:35:10 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>

On Mon, 19 May 2025 15:24:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Impressive work! I read it a bit superficially, here are comments/questions:

src/hotspot/share/jfr/instrumentation/jfrClassTransformer.cpp line 47:

> 45: #include "utilities/macros.hpp"
> 46: 
> 47: static void log_pending_exception(oop throwable) {

Put it under `JfrClassTransformer::`? Global symbols would eventually clash.

src/hotspot/share/jfr/instrumentation/jfrClassTransformer.cpp line 109:

> 107:   Handle pd(THREAD, ik->protection_domain());
> 108:   Symbol* const class_name = ik->name();
> 109:   const char* const klass_name = class_name != nullptr ? class_name->as_C_string() : "";

Unused `klass_name`?

src/hotspot/share/jfr/instrumentation/jfrClassTransformer.cpp line 131:

> 129:   assert(new_ik != nullptr, "invariant");
> 130:   assert(new_ik->name() != nullptr, "invariant");
> 131:   assert(strncmp(ik->name()->as_C_string(), new_ik->name()->as_C_string(), strlen(ik->name()->as_C_string())) == 0, "invariant");

Nit: I suspect `IK->name()` is an interned `Symbol`, so you can just compare those directly, without converting to `C_String`.

src/hotspot/share/jfr/instrumentation/jfrClassTransformer.cpp line 143:

> 141:     return nullptr;
> 142:   }
> 143:   return state != nullptr ? klass_being_redefined(ik, state) : nullptr;

Redundant `state != nullptr` check here.

src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 215:

> 213:   assert(JdkJfrEvent::is_a(ik), "invariant");
> 214:   if (has_annotation(ik, annotation_type, default_value, value)) {
> 215:        return true;

Unnecessary change.

src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 81:

> 79:                                                     jint* new_class_data_len,
> 80:                                                     unsigned char** new_class_data) {
> 81:   if (class_being_redefined == nullptr) {

OK, so this method is now completely empty. Do you even need it then? Or is it a part of some external API? If so, put a comment here, so no one removes it accidentally.

src/hotspot/share/jfr/jni/jfrJavaSupport.cpp line 942:

> 940:   typeArrayOop obj = oopFactory::new_typeArray(T_LONG, length, CHECK_NULL);
> 941:   ArrayAccess<>::arraycopy_from_native(&array->first(), obj, typeArrayOopDesc::element_offset<jlong>(0), length);
> 942:   array->clear();

This will trip someone at some point: the method name suggests we create the array of the incoming argument. But this method _also_clears the incoming array. Do we even need to clear it? Can this clearing be done in callers?

src/hotspot/share/jfr/jni/jfrUpcalls.cpp line 289:

> 287:   }
> 288: 
> 289:   // Call JVMUpcalls::onMethodTrace(byte[], long[] , String[], String[], int[])

Confused me a little: the signature here does not match the arguments we actually push. Maybe easier to just say `JVMUpcalls::onMethodTrace` without signature.

src/hotspot/share/jfr/jni/jfrUpcalls.cpp line 291:

> 289:   // Call JVMUpcalls::onMethodTrace(byte[], long[] , String[], String[], int[])
> 290:   JavaCallArguments args;
> 291:   JavaValue result(T_OBJECT);

Sounds more like `T_ARRAY`, as it returns `byte[]`? Likely does not matter for anything.

src/hotspot/share/jfr/metadata/metadata.xml line 1297:

> 1295:     <Field type="Method" name="method" label="Method" />
> 1296:     <Field type="long" name="invocations" label="Invocations" description = "The number of times the method was invoked"/>
> 1297:     <Field type="Tickspan" name="average" label="Average" description="An approximation of the wall-clock time it took for the method to execute"/>

Suggestion:

    <Field type="long" name="invocations" label="Invocations" description="The number of times the method was invoked "/>
    <Field type="Tickspan" name="average" label="Average" description="An approximation of the wall-clock time it took for the method to execute" />

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.

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp line 81:

> 79: 
> 80: bool JfrTraceIdEpoch::has_method_tracer_changed_tag_state() {
> 81:   return Atomic::load(&_method_tracer_state);

Checking: sure that no memory ordering is needed here? Sounds like this code consumes some state from another thread when checking this flag.


+  if (JfrTraceIdEpoch::has_method_tracer_changed_tag_state()) {
+    do_method_tracer_klasses();
+  }

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp line 54:

> 52: #define LEAKP_META_BIT                            (BIT << 2)
> 53: #define LEAKP_BIT                                 (LEAKP_META_BIT << META_SHIFT)
> 54: #define TIMING_BIT                                LEAKP_BIT // Alias

I guess there a reason to piggyback on leakp bit? Is this necessary? Sounds like there is still space for this bit? I guess it might be confusing when something like `SET_TIMING_BIT` sets `LEAKP_BIT`?

src/hotspot/share/jfr/support/methodtracer/jfrFilter.cpp line 73:

> 71:   if (name->equals("jdk.proxy1", 10)) {
> 72:     return false;
> 73:   }

Curious: what's `jdk.proxy1` module?

src/hotspot/share/jfr/support/methodtracer/jfrFilter.cpp line 231:

> 229:     } else if (mod == 3) {
> 230:       modification = "+timing +tracing";
> 231:     }

Common style: convert to `switch` and `ShouldNotReachHere()` the `default` case?

src/hotspot/share/jfr/support/methodtracer/jfrFilterManager.cpp line 81:

> 79: 
> 80: const JfrFilter* JfrFilterManager::current() {
> 81:   return Atomic::load(&_current);

Memory ordering question again: does it need `load_acquire`? For example, are we accessing `JfrFilter` contents from another thread? `xchg` installation covers the release part, we only need need `load_acquire` here.

src/hotspot/share/jfr/support/methodtracer/jfrMethodProcessor.cpp line 90:

> 88: 
> 89: static inline bool is_timing(int modification) {
> 90:   return modification == -1 ? false : (modification & 1) != 0;

Reliability: convert `1` and `2` magical numbers to symbolic constants somewhere?

src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 141:

> 139: 
> 140:   // 1. Is the ik the initial load, i.e.the first InstanceKlass, or a scratch klass, denoting a redefine / retransform?
> 141:   const Klass* const existing_klass = JfrClassTransformer::find_existing_klass(ik, THREAD);

Sounds like `JfrClassTransformer::find_existing_klass` can return `InstanceKlass*`, and thus we can avoid a whole lot of `InstanceKlass::cast`-s everywhere?

src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 192:

> 190: }
> 191: 
> 192: static inline void log_add(const InstanceKlass* ik) {

Move it under `JfrMethodTracer::log_add` to avoid symbol clash later.

src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 284:

> 282: static GrowableArray<jlong>* _current_unloaded_class_ids = nullptr;
> 283: static GrowableArray<jlong>* _stale_class_ids = nullptr;
> 284: static GrowableArray<jlong>* _empty_class_ids = nullptr;

Global symbols, move them under `JfrMethodTracer`?

src/hotspot/share/jfr/support/methodtracer/jfrTraceTagging.hpp line 31:

> 29: #include "memory/allStatic.hpp"
> 30: 
> 31: class InstanceKlass;;

Suggestion:

class InstanceKlass;

src/hotspot/share/oops/instanceKlass.hpp line 360:

> 358:   Method* method_with_idnum(int idnum) const;
> 359:   Method* method_with_orig_idnum(int idnum) const;
> 360:   Method* method_with_orig_idnum(int idnum, int version) const;

Checking: do you need these turned `const`, or this is just convenient touchup? If this is unnecessary, I would probably limit the changes to shared code.

src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java.rej line 1:

> 1: diff a/src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java b/src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java	(rejected hunks)

This checks in `.rej` file! Odd that bots have not complained about it. Please report this to Skara folks.

src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java line 208:

> 206:                     nativeControls.remove(n);
> 207:                     TypeLibrary.removeType(nativeType.getId());
> 208:                     pEventType.setAnnotations(nativeType.getAnnotationElements());

This looks like accidental removal. Is it?

src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java line 249:

> 247:     }
> 248: 
> 249:     private synchronized static void reset() {

Any sense to do  `synchronized` here, given that `timed{Methods,Classes}` are `ConcurrentHashMap`-s?

src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java line 273:

> 271:             JVM.exclude(current);
> 272:             long classId = Type.getKnownType(String.class).getId();
> 273:             long methodId = classId << 16 + 983059;

What's `983059`?

src/jdk.jfr/share/classes/jdk/jfr/tracing/MethodTracer.java line 53:

> 51:         long endTime = JVM.counterTime();
> 52:         long duration = endTime - startTime;
> 53:         if (MethodTraceEvent.enabled() && JVM.getEventWriter() != null) {

Comprehension check: This method is "only" called from the instrumented code. Do we then actually know that `MethodTraceEvent` is enabled? Can squeeze a few cycles bypassing this check.

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

PR Review: https://git.openjdk.org/jdk/pull/25306#pullrequestreview-2860740206
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102248620
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102255800
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102262165
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102264172
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102267383
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102271892
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102278626
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102288863
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102292285
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102294829
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102311652
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102320379
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102326390
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102338488
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102348149
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102352820
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102358055
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102363240
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102364937
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102394386
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102398712
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102402444
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102407122
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102412679
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102426431
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102430181
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2102445353

From shade at openjdk.org  Thu May 22 12:35:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 12:35:11 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <v_NGFtEdnjnNq_IKbb5tjvuYneH9dD7_tQoGCLTDT4U=.e9c592ea-ca85-4edb-a956-c8bd139eb05b@github.com>

On Thu, 22 May 2025 11:33:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/hotspot/share/jfr/support/methodtracer/jfrFilter.cpp line 73:
> 
>> 71:   if (name->equals("jdk.proxy1", 10)) {
>> 72:     return false;
>> 73:   }
> 
> Curious: what's `jdk.proxy1` module?

Sounds like from here:


src/java.base/share/classes/java/lang/reflect/Proxy.java:

        private static Module getDynamicModule(ClassLoader loader) {
            return dynProxyModules.computeIfAbsent(loader, (ld, clv) -> {
                // create a dynamic module and setup module access
                String mn = "jdk.proxy" + counter.incrementAndGet();


...but that looks to me that we can have more than 10 dynamic modules, so something like `jdk.proxy20` would mismatch here.

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

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

From egahlin at openjdk.org  Thu May 22 13:20:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 22 May 2025 13:20:56 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <wsCD_0aUTjAISB1SdbC0xFdFGS8KxHAgH4eSzbuIVwI=.4659f912-90ff-40a3-a9ad-ba96a86bb922@github.com>

On Thu, 22 May 2025 12:31:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/tracing/MethodTracer.java line 53:
> 
>> 51:         long endTime = JVM.counterTime();
>> 52:         long duration = endTime - startTime;
>> 53:         if (MethodTraceEvent.enabled() && JVM.getEventWriter() != null) {
> 
> Comprehension check: This method is "only" called from the instrumented code. Do we then actually know that `MethodTraceEvent` is enabled? Can squeeze a few cycles bypassing this check.

We can't be sure, but it's only called when java.lang.Object::<init> is instrumented. (The second check is needed to avoid recursion when allocating the EventWriter object).

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

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

From egahlin at openjdk.org  Thu May 22 13:27:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 22 May 2025 13:27:54 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <wtE86Id50VArg7_gSBKHn1kqxO_Vr2GXg4QhvHuiilg=.55378444-89b3-4780-a0fc-01754df41ce3@github.com>

On Thu, 22 May 2025 12:24:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java line 273:
> 
>> 271:             JVM.exclude(current);
>> 272:             long classId = Type.getKnownType(String.class).getId();
>> 273:             long methodId = classId << 16 + 983059;
> 
> What's `983059`?

It's just a method ID I happened to get when I instrumented some random method in java.lang.String. I can add a comment explaining it.

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

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

From mgronlun at openjdk.org  Thu May 22 13:29:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 13:29:53 GMT
Subject: RFR: 8356016: Build fails by clang(XCode 16.3) on macOS after
 JDK-8347719
In-Reply-To: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>
References: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>
Message-ID: <p2fcVrb970QGMcreOPLtbGeRNoET0rTWZjzBB9HdNoE=.0dbdedd5-c1ba-4b24-bb14-2cfebc0db152@github.com>

On Thu, 22 May 2025 06:17:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to avoid a forbidden function warning when building
> with Xcode 16.3.  (Note: There's no warning with Xcode 16.2 or earlier.)
> 
> The jfr/test_networkUtilization.cpp gtest uses several C++ standard library
> containers. There is a change in the standard library in Xcode 16.3 that
> exposes a call to `free` in the header, and we normally forbid the direct use
> of that function.
> 
> To address this problem we surround the `#includes` for standard library
> container headers with `BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS`, suppressing any
> such warnings from them.
> 
> While there, also made a few minor cleanups to that file's header usage.
> 
> Testing: mach5 tier1.
> Built macosx-aarch64 with Xcode 16.3.

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25380#pullrequestreview-2861232045

From mdoerr at openjdk.org  Thu May 22 14:51:00 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 22 May 2025 14:51:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
Message-ID: <A-83j7sxuLtMYtMJ5JF65gic4oFmSkO-xe7LjggVrxw=.ea08e38b-1c68-46bc-abae-b9d33778362f@github.com>

On Wed, 21 May 2025 21:54:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fetch bcp from context

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 191:

> 189:   return Interpreter::contains(pc);
> 190: }
> 191: #endif

Could probably be moved to os_posix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2102757839

From mdoerr at openjdk.org  Thu May 22 14:56:59 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 22 May 2025 14:56:59 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <-KApfpU-SEhxFdL4Co7etH8D0xFrb3lAl6tIeA9WAl8=.75c7a92d-28aa-43d8-9dcb-fa907213121c@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
 <cGo7lcX_KwtJ-qg8GPBlzI-d7vTr08kyQpzak6EySS0=.4a25e447-3ba7-42f4-aa45-11375f66198c@github.com>
 <S8VaTu2OZfmx0ZTYJfX6Npba679HPqijHGZ65NdZNWM=.595873b4-0a1f-46a2-9853-51aca1e85b1b@github.com>
 <-KApfpU-SEhxFdL4Co7etH8D0xFrb3lAl6tIeA9WAl8=.75c7a92d-28aa-43d8-9dcb-fa907213121c@github.com>
Message-ID: <vVNH_SXPLSmrLJnapWgNf07Ek6_Fszvns25NkkdkHoA=.3109f7f8-5d51-4fa3-a01e-e87dca614364@github.com>

On Thu, 22 May 2025 10:24:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The crit sec to be stored before the poll test is issued.
>> 
>> Most likely not needed, because of implicit fences involved in thread suspension.
>
>> The crit sec to be stored before the poll test is issued.
>> 
>> Most likely not needed, because of implicit fences involved in thread suspension.
> 
> OK, but reading `sampling_critical_section` doesn't seem to have any synchronization at all, so it doesn't much matter what you do when writing it.

@theRealAph: src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp contains 3 release barriers. I wonder if there are cases in which we need ordering which is not already covered by signal handler or suspend/resume mechanism.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2102771974

From mgronlun at openjdk.org  Thu May 22 15:32:20 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 15:32:20 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v36]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <rFe1Ta1dYnqOYfNhUIHQb_2V5T88PrhkQWuCQdujJjc=.77ffaaf0-e11e-458f-85d6-d1d7f8bf3914@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  leave jfr critical section before throw_delayed_StackOverflowException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/cc8719f9..62112c4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=34-35

  Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Thu May 22 15:36:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 15:36:59 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v33]
In-Reply-To: <xT8sD6owIcBu3f5UzXMyj5H3YcLtXG_kaGjYOyT9ta0=.5b7da165-1357-47e9-a14b-42bd681b4346@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
 <fqTCe2KubQdJBCD4eVFbcsiXj96SZmPjroIRTTl1cQk=.4ae82818-d23e-4b62-83d4-e990fc762a53@github.com>
 <luxkkGG2p_vjZrnPnaZVD1ptLWvPfWYeK0eDtyc7RgQ=.23d2c452-3af4-4aa3-b9cf-77f7a7e91b34@github.com>
 <xT8sD6owIcBu3f5UzXMyj5H3YcLtXG_kaGjYOyT9ta0=.5b7da165-1357-47e9-a14b-42bd681b4346@github.com>
Message-ID: <HSS6wcTwU6w1lJ8eAIirnrNmHQ6PJLfYws0483Cc5HI=.34714b7e-4f96-4cab-890f-4ee000046b5a@github.com>

On Wed, 21 May 2025 22:24:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > > We can escape here before `leave_jfr_critical_section`:
> > > https://github.com/openjdk/jdk/blob/d3aed1e7365d7934e439fff3956ae2ca4b5d4269/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L645
> > > 
> > > Is that ok for exceptions?
> > 
> > 
> > Need to check but might need a leave_critical section in InterpreterRuntime::throw_delayed_StackOverflowError.
> 
> Will also, again, study in detail JVMTI PopFrame and ForceEarlyReturn to ensure it plays with the new model.

Concluded that we can release the critical section before throwing DelayedStackOverflow.  The frame is set as the ljf, the thread enters into state thread in VM (unsampleable) , and throws. This throw will eventually end up in InterpreterRuntime::exception_handler_for_exception(). The choosen continuation points are InterpreterRuntime::remove_activation() (i.e. re-enter).

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

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

From mgronlun at openjdk.org  Thu May 22 16:01:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 16:01:50 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v37]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <52kFq04zEs7QxqEWuXr2PVln7suTdH-kfGLHWBdwm7s=.0144f8e9-8e61-4cb9-845d-53e69a819756@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  leave_jfr_critical_section in the correct location

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/62112c4b..5b4a7550

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=35-36

  Stats: 8 lines in 2 files changed: 4 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From liach at openjdk.org  Thu May 22 18:54:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 18:54:58 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <g9__TdjfzyL8peXK_OQmt4cskn9Qzyjy_5dj377Nyh4=.824c5606-c144-4775-8407-22c9a040b9a5@github.com>

On Mon, 19 May 2025 15:24:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Mainly looked at bytecode transformation; those look good.

src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 81:

> 79:         InitialSecurityPropertyEvent.class,
> 80:         MethodTraceEvent.class,
> 81:         MethodTimingEvent.class

Suggestion:

        MethodTimingEvent.class,

for future additions.

src/jdk.jfr/share/classes/jdk/jfr/internal/LogTag.java line 104:

> 102:      *  Covers usage of MethodTiming and MethodTrace events
> 103:      */
> 104:     JFR_METHODTRACE(16);

You can consider adding a trailing `,` and moving `;` onto a new line if addition to this enum is frequent.

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

PR Review: https://git.openjdk.org/jdk/pull/25306#pullrequestreview-2862226134
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2103182014
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2103184030

From egahlin at openjdk.org  Thu May 22 19:49:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 22 May 2025 19:49:56 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <5Ck_jxn_y53ZY8vCQIdAnKaOtUuzApJjxnRMyFN4XuQ=.55b2949f-018c-4d72-afc0-24ca182d5444@github.com>

On Thu, 22 May 2025 12:15:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java line 208:
> 
>> 206:                     nativeControls.remove(n);
>> 207:                     TypeLibrary.removeType(nativeType.getId());
>> 208:                     pEventType.setAnnotations(nativeType.getAnnotationElements());
> 
> This looks like accidental removal. Is it?

It's by design. When an event is defined in both metadata.xml and as a JDK event, we want the event metadata to be taken from Java. I don't remember exactly what the problem was in this case. Perhaps @RemoveFields was ignored, so there was a field mismatch.

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

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

From egahlin at openjdk.org  Thu May 22 19:59:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 22 May 2025 19:59:56 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <SYE859CFIE1FzjZDkX2b4u6HYpAFcykiNZxUfj-OF6A=.fc58e44a-af9b-481b-9510-bef0d2d1e2f5@github.com>

On Thu, 22 May 2025 12:22:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java line 249:
> 
>> 247:     }
>> 248: 
>> 249:     private synchronized static void reset() {
> 
> Any sense to do  `synchronized` here, given that `timed{Methods,Classes}` are `ConcurrentHashMap`-s?

It's only used by PlatformTracer::initialize(), so it can removed.

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

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

From mgronlun at openjdk.org  Thu May 22 21:18:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 21:18:40 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v38]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <GBuK6rC9EH2ZJ8S-DcVOX7i3JFsaXweB3FRi70U4ioQ=.4e399965-217a-4e00-8636-873ed45a50a3@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  Refactor interpreter ucontext assertion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/5b4a7550..7d7e6f45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=36-37

  Stats: 52 lines in 6 files changed: 12 ins; 36 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Thu May 22 21:18:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 21:18:40 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v34]
In-Reply-To: <A-83j7sxuLtMYtMJ5JF65gic4oFmSkO-xe7LjggVrxw=.ea08e38b-1c68-46bc-abae-b9d33778362f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <nsQJUrd0uDoRPT_V2caiMlUuDJ1MzpSrLaNQ7UAKTp8=.e3eae0a0-ccc7-430f-8078-269c469d38a6@github.com>
 <A-83j7sxuLtMYtMJ5JF65gic4oFmSkO-xe7LjggVrxw=.ea08e38b-1c68-46bc-abae-b9d33778362f@github.com>
Message-ID: <IosKAPTqNyr_P4O08jfOhwApoeEcXQBSbMWOiJTUcEA=.3c707adf-4d42-46f2-95e5-3d13341b1f34@github.com>

On Thu, 22 May 2025 14:48:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fetch bcp from context
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 191:
> 
>> 189:   return Interpreter::contains(pc);
>> 190: }
>> 191: #endif
> 
> Could probably be moved to os_posix. (Also works on AIX.)

Refactored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2103409874

From mgronlun at openjdk.org  Thu May 22 21:29:43 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 May 2025 21:29:43 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v39]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <KTOvKXu-44W0RLFmerOH0hsiRQzM-zK_IPTquvunXOY=.1ff4cb17-815b-4304-8d8c-ed932fe60b9e@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  include order

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/7d7e6f45..1cf582a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=37-38

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From kbarrett at openjdk.org  Fri May 23 06:57:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 23 May 2025 06:57:55 GMT
Subject: RFR: 8356016: Build fails by clang(XCode 16.3) on macOS after
 JDK-8347719
In-Reply-To: <ZjNBN0vvxHd2JDYq54ke3qXMrHIf6BA591RIp3knY1Q=.fe0ce145-8d19-4321-8a57-93812af7a22e@github.com>
References: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>
 <ZjNBN0vvxHd2JDYq54ke3qXMrHIf6BA591RIp3knY1Q=.fe0ce145-8d19-4321-8a57-93812af7a22e@github.com>
Message-ID: <ebfzvKVd91mH_xaQZuI-keksPurg9eSxf0Arpy9naa4=.2387e872-deb7-4b29-be77-eb11e371991e@github.com>

On Thu, 22 May 2025 08:45:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this change to avoid a forbidden function warning when building
>> with Xcode 16.3.  (Note: There's no warning with Xcode 16.2 or earlier.)
>> 
>> The jfr/test_networkUtilization.cpp gtest uses several C++ standard library
>> containers. There is a change in the standard library in Xcode 16.3 that
>> exposes a call to `free` in the header, and we normally forbid the direct use
>> of that function.
>> 
>> To address this problem we surround the `#includes` for standard library
>> container headers with `BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS`, suppressing any
>> such warnings from them.
>> 
>> While there, also made a few minor cleanups to that file's header usage.
>> 
>> Testing: mach5 tier1.
>> Built macosx-aarch64 with Xcode 16.3.
>
> Looks fine, as long as test still compiles and works.

Thanks for reviews @shipilev and @mgronlun

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

PR Comment: https://git.openjdk.org/jdk/pull/25380#issuecomment-2903452700

From kbarrett at openjdk.org  Fri May 23 06:57:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 23 May 2025 06:57:56 GMT
Subject: Integrated: 8356016: Build fails by clang(XCode 16.3) on macOS after
 JDK-8347719
In-Reply-To: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>
References: <45dfof9VZ_eVgFPTUdnTfP0iN0eXGEN5nz25Qp7B-QI=.0e1f84f1-4fc8-4e23-9b88-7bdc800d323c@github.com>
Message-ID: <DkwaNNw_9xsGVMXtLRu37m0pPyv3hOU4GcYf5JIyrXg=.7ec975ac-e2fb-4a7e-b99c-01630de3ab38@github.com>

On Thu, 22 May 2025 06:17:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to avoid a forbidden function warning when building
> with Xcode 16.3.  (Note: There's no warning with Xcode 16.2 or earlier.)
> 
> The jfr/test_networkUtilization.cpp gtest uses several C++ standard library
> containers. There is a change in the standard library in Xcode 16.3 that
> exposes a call to `free` in the header, and we normally forbid the direct use
> of that function.
> 
> To address this problem we surround the `#includes` for standard library
> container headers with `BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS`, suppressing any
> such warnings from them.
> 
> While there, also made a few minor cleanups to that file's header usage.
> 
> Testing: mach5 tier1.
> Built macosx-aarch64 with Xcode 16.3.

This pull request has now been integrated.

Changeset: ae7ae847
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae7ae847d4cb0dc2caf7bdc6a82673287cba8d30
Stats:     6 lines in 1 file changed: 2 ins; 2 del; 2 mod

8356016: Build fails by clang(XCode 16.3) on macOS after JDK-8347719

Reviewed-by: shade, mgronlun

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

PR: https://git.openjdk.org/jdk/pull/25380

From egahlin at openjdk.org  Fri May 23 13:38:58 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 23 May 2025 13:38:58 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <OKa66aIJr0GhpT3ukPQyTGJ5JFfp29UVZjz9s6Rlis0=.2754a21e-1b05-45e4-822d-9137ffca1f10@github.com>

On Thu, 22 May 2025 10:57:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 81:
> 
>> 79:                                                     jint* new_class_data_len,
>> 80:                                                     unsigned char** new_class_data) {
>> 81:   if (class_being_redefined == nullptr) {
> 
> OK, so this method is now completely empty. Do you even need it then? Or is it a part of some external API? If so, put a comment here, so no one removes it accidentally.

It's been dead code for a long time, but it makes sense to remove the method.

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

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

From mgronlun at openjdk.org  Fri May 23 13:53:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 13:53:58 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <0wt2f-07N3JH5DBh4OPJH6hWbAU_vSnFeeVjhFuseSg=.21f83971-097e-4a1b-9ca4-71ab27c1e99a@github.com>

On Thu, 22 May 2025 11:48:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 192:
> 
>> 190: }
>> 191: 
>> 192: static inline void log_add(const InstanceKlass* ik) {
> 
> Move it under `JfrMethodTracer::log_add` to avoid symbol clash later.

static functions, especially inlined ones, have internal linkage and will not cause global clashes.

> src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 284:
> 
>> 282: static GrowableArray<jlong>* _current_unloaded_class_ids = nullptr;
>> 283: static GrowableArray<jlong>* _stale_class_ids = nullptr;
>> 284: static GrowableArray<jlong>* _empty_class_ids = nullptr;
> 
> Global symbols, move them under `JfrMethodTracer`?

static so not needed.

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

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

From mgronlun at openjdk.org  Fri May 23 14:02:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 14:02:54 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>

On Thu, 22 May 2025 11:20:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> 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.

> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp line 81:
> 
>> 79: 
>> 80: bool JfrTraceIdEpoch::has_method_tracer_changed_tag_state() {
>> 81:   return Atomic::load(&_method_tracer_state);
> 
> Checking: sure that no memory ordering is needed here? Sounds like this code consumes some state from another thread when checking this flag.
> 
> 
> +  if (JfrTraceIdEpoch::has_method_tracer_changed_tag_state()) {
> +    do_method_tracer_klasses();
> +  }

Correct, should be Atomic::load_acquire()

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

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

From mgronlun at openjdk.org  Fri May 23 14:05:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 14:05:53 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <4hnPDil3Lp_IWSpV4SP5qfQsrqtklL0xidVFf-Uw5Kg=.58405790-31fb-43de-a9fb-fdbd1026ff10@github.com>

On Thu, 22 May 2025 11:26:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp line 54:
> 
>> 52: #define LEAKP_META_BIT                            (BIT << 2)
>> 53: #define LEAKP_BIT                                 (LEAKP_META_BIT << META_SHIFT)
>> 54: #define TIMING_BIT                                LEAKP_BIT // Alias
> 
> I guess there a reason to piggyback on leakp bit? Is this necessary? Sounds like there is still space for this bit? I guess it might be confusing when something like `SET_TIMING_BIT` sets `LEAKP_BIT`?

The number of available bits is precious and must be allocated with care.

Here we have a mutually exclusive situation that allows us to save bits.

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

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

From mgronlun at openjdk.org  Fri May 23 14:10:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 14:10:56 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <Je7acU4EhE5jHx4kTWO8-KujbO-WOlwyFXcrADZQ87U=.1d0b9b7c-5be9-4a85-87db-6202cd867b68@github.com>

On Thu, 22 May 2025 10:44:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/hotspot/share/jfr/instrumentation/jfrClassTransformer.cpp line 47:
> 
>> 45: #include "utilities/macros.hpp"
>> 46: 
>> 47: static void log_pending_exception(oop throwable) {
> 
> Put it under `JfrClassTransformer::`? Global symbols would eventually clash.

Its static so not a globally visible symbol.

> src/hotspot/share/jfr/support/methodtracer/jfrFilterManager.cpp line 81:
> 
>> 79: 
>> 80: const JfrFilter* JfrFilterManager::current() {
>> 81:   return Atomic::load(&_current);
> 
> Memory ordering question again: does it need `load_acquire`? For example, are we accessing `JfrFilter` contents from another thread? `xchg` installation covers the release part, we only need need `load_acquire` here.

Atomic::load_acquire() it should be, that's right - thanks.

> src/hotspot/share/oops/instanceKlass.hpp line 360:
> 
>> 358:   Method* method_with_idnum(int idnum) const;
>> 359:   Method* method_with_orig_idnum(int idnum) const;
>> 360:   Method* method_with_orig_idnum(int idnum, int version) const;
> 
> Checking: do you need these turned `const`, or this is just convenient touchup? If this is unnecessary, I would probably limit the changes to shared code.

The change is correct to improve const-correctness. If you work with a const Method*, then this is required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2104679792
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2104677815
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2104676648

From shade at openjdk.org  Fri May 23 14:47:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 May 2025 14:47:54 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
 <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>
Message-ID: <SJwgfpcBZ1k-Mzjmm7Pj4zNrecYbQgU7-khBlM9K9ww=.56b65ddd-20fa-4724-8ffd-df1d23a09153@github.com>

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

>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp line 81:
>> 
>>> 79: 
>>> 80: bool JfrTraceIdEpoch::has_method_tracer_changed_tag_state() {
>>> 81:   return Atomic::load(&_method_tracer_state);
>> 
>> Checking: sure that no memory ordering is needed here? Sounds like this code consumes some state from another thread when checking this flag.
>> 
>> 
>> +  if (JfrTraceIdEpoch::has_method_tracer_changed_tag_state()) {
>> +    do_method_tracer_klasses();
>> +  }
>
> Correct, should be Atomic::load_acquire()

Just so we are on the same page, the stores should be at least `Atomic::release_store`, but better even `Atomic::release_store_fence` to match `Atomic::load_acquire`.

>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp line 54:
>> 
>>> 52: #define LEAKP_META_BIT                            (BIT << 2)
>>> 53: #define LEAKP_BIT                                 (LEAKP_META_BIT << META_SHIFT)
>>> 54: #define TIMING_BIT                                LEAKP_BIT // Alias
>> 
>> I guess there a reason to piggyback on leakp bit? Is this necessary? Sounds like there is still space for this bit? I guess it might be confusing when something like `SET_TIMING_BIT` sets `LEAKP_BIT`?
>
> The number of available bits is precious and must be allocated with care.
> 
> Here we have a mutually exclusive situation that allows us to save bits.

Got it, thanks.

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

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

From mgronlun at openjdk.org  Fri May 23 14:57:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 14:57:53 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <SJwgfpcBZ1k-Mzjmm7Pj4zNrecYbQgU7-khBlM9K9ww=.56b65ddd-20fa-4724-8ffd-df1d23a09153@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
 <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>
 <SJwgfpcBZ1k-Mzjmm7Pj4zNrecYbQgU7-khBlM9K9ww=.56b65ddd-20fa-4724-8ffd-df1d23a09153@github.com>
Message-ID: <g8rrVlGMxaLr1TJuo6RRvfrCcHi_qQWcbxjG_cTocbU=.e4a5d4a5-58e9-407d-9b00-49fad68ea240@github.com>

On Fri, 23 May 2025 14:43:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Correct, should be Atomic::load_acquire()
>
> Just so we are on the same page, the stores should be at least `Atomic::release_store`, but better even `Atomic::release_store_fence` to match `Atomic::load_acquire`.

Why release_store_fence() over release_store() in this context?

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

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

From egahlin at openjdk.org  Fri May 23 15:21:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 23 May 2025 15:21:54 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <v_NGFtEdnjnNq_IKbb5tjvuYneH9dD7_tQoGCLTDT4U=.e9c592ea-ca85-4edb-a956-c8bd139eb05b@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
 <v_NGFtEdnjnNq_IKbb5tjvuYneH9dD7_tQoGCLTDT4U=.e9c592ea-ca85-4edb-a956-c8bd139eb05b@github.com>
Message-ID: <grHVe1kP5vT0v0P7Ao9_eSMJm7zf6tJiQ5IEhmNzHZc=.4bd0fb29-78a9-4b1e-b624-6122c283ce2a@github.com>

On Thu, 22 May 2025 11:34:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/jfr/support/methodtracer/jfrFilter.cpp line 73:
>> 
>>> 71:   if (name->equals("jdk.proxy1", 10)) {
>>> 72:     return false;
>>> 73:   }
>> 
>> Curious: what's `jdk.proxy1` module?
>
> Sounds like from here:
> 
> 
> src/java.base/share/classes/java/lang/reflect/Proxy.java:
> 
>         private static Module getDynamicModule(ClassLoader loader) {
>             return dynProxyModules.computeIfAbsent(loader, (ld, clv) -> {
>                 // create a dynamic module and setup module access
>                 String mn = "jdk.proxy" + counter.incrementAndGet();
> 
> 
> ...but that looks to me that we can have more than 10 dynamic modules, so something like `jdk.proxy20` would mismatch here.

It's not needed. I will remove.

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

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

From shade at openjdk.org  Fri May 23 15:27:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 May 2025 15:27:54 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <g8rrVlGMxaLr1TJuo6RRvfrCcHi_qQWcbxjG_cTocbU=.e4a5d4a5-58e9-407d-9b00-49fad68ea240@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
 <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>
 <SJwgfpcBZ1k-Mzjmm7Pj4zNrecYbQgU7-khBlM9K9ww=.56b65ddd-20fa-4724-8ffd-df1d23a09153@github.com>
 <g8rrVlGMxaLr1TJuo6RRvfrCcHi_qQWcbxjG_cTocbU=.e4a5d4a5-58e9-407d-9b00-49fad68ea240@github.com>
Message-ID: <zUM9uVLSt9Y7cSsKBsFAyA4D4DWVsTDPRvr35Azq0_0=.aab96d50-4489-407b-add7-adad7db678a2@github.com>

On Fri, 23 May 2025 14:55:21 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Just so we are on the same page, the stores should be at least `Atomic::release_store`, but better even `Atomic::release_store_fence` to match `Atomic::load_acquire`.
>
> Why release_store_fence() over release_store() in this context?

`release_store_fence` would get stronger seqcst mode, instead of more relaxed acquire/release with just `release_store`. My rule of thumb is to default to a strongest mode, unless we can prove weaker mode is sufficient. Acquire/release is okay for simple uni-directional pub/sub transfer, which this one _looks_ to be, but I am not 100% sure.

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

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

From jbechberger at openjdk.org  Fri May 23 16:37:40 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 23 May 2025 16:37:40 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v4]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <0wCu17xvBIjYJZnYLT90XFzsmQ-PY3WUyJw3e4nBBIo=.10693121-d72e-43df-88c5-6038f32ec4b1@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'pr/24296' of https://git.openjdk.org/jdk into parttimenerd_cooperative_cpu_time_sampler
 - Fix tests
 - Remove unused WhiteBox method
 - Read _active_signal_handlers atomically
 - Check whether raw_thread is not null and is JavaThread is signal handler
 - Tiny fixes
 - Fix uninitialized variable
 - Reduce diff
 - Refactor
 - Reduce diff
 - ... and 13 more: https://git.openjdk.org/jdk/compare/1cf582a0...eaca165d

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=03
  Stats: 2342 lines in 46 files changed: 2191 ins; 130 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From mgronlun at openjdk.org  Fri May 23 17:28:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 17:28:58 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <zUM9uVLSt9Y7cSsKBsFAyA4D4DWVsTDPRvr35Azq0_0=.aab96d50-4489-407b-add7-adad7db678a2@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
 <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>
 <SJwgfpcBZ1k-Mzjmm7Pj4zNrecYbQgU7-khBlM9K9ww=.56b65ddd-20fa-4724-8ffd-df1d23a09153@github.com>
 <g8rrVlGMxaLr1TJuo6RRvfrCcHi_qQWcbxjG_cTocbU=.e4a5d4a5-58e9-407d-9b00-49fad68ea240@github.com>
 <zUM9uVLSt9Y7cSsKBsFAyA4D4DWVsTDPRvr35Azq0_0=.aab96d50-4489-407b-add7-adad7db678a2@github.com>
Message-ID: <Zqxev1KJ6f4HQlnetve35GwlXJ3lJerQVSrjnow2gB4=.e599f181-38c0-4fbe-aaf9-28e4681cd759@github.com>

On Fri, 23 May 2025 15:24:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Why release_store_fence() over release_store() in this context?
>
> `release_store_fence` would get stronger seqcst mode, instead of more relaxed acquire/release with just `release_store`. My rule of thumb is to default to a strongest mode, unless we can prove weaker mode is sufficient. Acquire/release is okay for simple uni-directional pub/sub transfer, which this one _looks_ to be, but I am not 100% sure.

A good rule of thumb.

In this case, it is an unidirectional pub/sub transfer, so release_store() will be good enough.

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

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

From mgronlun at openjdk.org  Fri May 23 18:37:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 18:37:54 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <0FbAbkZbUIgv-nkUdVRwS9Hx5EOd8VvR0nljSMKV1Og=.e7a967dc-2563-449d-8224-620c3ad1ccbd@github.com>

On Mon, 19 May 2025 15:24:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp line 502:

> 500:     }
> 501:     assert(jic.trace_id() == JfrTraceId::load_raw(jic.instance_klass()), "invariant");
> 502:     assert(HAS_STICKY_BIT(jic.instance_klass()), "invariant");

Can you replace this with "JfrTraceId::has_sticky_bit(ik)" instead? Thanks.

src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 187:

> 185:   add_instrumented_class(ik, mp.methods());
> 186:   if (mp.has_timing()) {
> 187:     // After having installed the newly created klass into the list, perform and upcall to publish the associated TimedClass.

"perform and upcall" -> "perform an upcall" or "upcall to publish"

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

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

From mgronlun at openjdk.org  Fri May 23 19:26:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 19:26:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v33]
In-Reply-To: <HSS6wcTwU6w1lJ8eAIirnrNmHQ6PJLfYws0483Cc5HI=.34714b7e-4f96-4cab-890f-4ee000046b5a@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <mYcqIcZaEDsLuGbfQ2KWYNP4Bqocq_X3uTRxaO2v6i4=.4115dc61-1bcc-4c9a-8ae8-8deefacff351@github.com>
 <fqTCe2KubQdJBCD4eVFbcsiXj96SZmPjroIRTTl1cQk=.4ae82818-d23e-4b62-83d4-e990fc762a53@github.com>
 <luxkkGG2p_vjZrnPnaZVD1ptLWvPfWYeK0eDtyc7RgQ=.23d2c452-3af4-4aa3-b9cf-77f7a7e91b34@github.com>
 <xT8sD6owIcBu3f5UzXMyj5H3YcLtXG_kaGjYOyT9ta0=.5b7da165-1357-47e9-a14b-42bd681b4346@github.com>
 <HSS6wcTwU6w1lJ8eAIirnrNmHQ6PJLfYws0483Cc5HI=.34714b7e-4f96-4cab-890f-4ee000046b5a@github.com>
Message-ID: <guu9EbFjtksRnsoeoXUr3qkKIOD360C7K5PEtj1zuv4=.29200ee9-da29-4333-b79f-59b5c60f41fe@github.com>

On Thu, 22 May 2025 15:34:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > > We can escape here before `leave_jfr_critical_section`:
> > > https://github.com/openjdk/jdk/blob/d3aed1e7365d7934e439fff3956ae2ca4b5d4269/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L645
> > > 
> > > Is that ok for exceptions?
> > 
> > 
> > Need to check but might need a leave_critical section in InterpreterRuntime::throw_delayed_StackOverflowError.
> 
> Will also, again, study in detail JVMTI PopFrame and ForceEarlyReturn to ensure it plays with the new model.

All ok. Both use InterpreterMacroAssembler::remove_activation() as part of their post-sequence.

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

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

From egahlin at openjdk.org  Fri May 23 19:29:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 23 May 2025 19:29:53 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
 <_lQ4ROQqk0g4ZRKP9I7hA0JHxTFzxBeKdQxAyIGxfvo=.8788516a-bf6d-4198-aa4b-42b02f632d88@github.com>
Message-ID: <wnrS13q3TVqQPsuQdPrpKyvffiCQYd_r7VGZq4keyCw=.b4595ea3-666f-40a1-aa67-5e4d7c41379e@github.com>

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

From egahlin at openjdk.org  Fri May 23 19:33:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 23 May 2025 19:33:56 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
Message-ID: <hz2zqOHi3rl4iMUmO4HrCfFlsmf_t8_a_Ica1IRE6vc=.9bf3cc63-038e-4219-b337-146e508970bb@github.com>

On Thu, 22 May 2025 11:47:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 141:
> 
>> 139: 
>> 140:   // 1. Is the ik the initial load, i.e.the first InstanceKlass, or a scratch klass, denoting a redefine / retransform?
>> 141:   const Klass* const existing_klass = JfrClassTransformer::find_existing_klass(ik, THREAD);
> 
> Sounds like `JfrClassTransformer::find_existing_klass` can return `InstanceKlass*`, and thus we can avoid a whole lot of `InstanceKlass::cast`-s everywhere?

The method is also used by JfrEventClassTransformer, which uses the returned Klass* to call other members. The signature of those methods could probably also be updated, but I think it's better done separately.

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

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

From mgronlun at openjdk.org  Fri May 23 19:49:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 May 2025 19:49:56 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <-hhrsRy3MadVDVJoQs2chfkrBWrH-LebAyu6EGlH7MQ=.0e30fb30-fc8e-4dc5-84ce-d238824cdcb2@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <-hhrsRy3MadVDVJoQs2chfkrBWrH-LebAyu6EGlH7MQ=.0e30fb30-fc8e-4dc5-84ce-d238824cdcb2@github.com>
Message-ID: <VKfMWVxcB-WFGwKCWtmG5-TxM-f7zQ--B9njqgGy24Y=.327decaf-78c3-4aca-b96e-1cb51f5fa07c@github.com>

On Wed, 21 May 2025 10:41:04 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > Hi, Could you please incorporate this change for riscv? Thanks. [RealFYang at be8eac4](https://github.com/RealFYang/jdk/commit/be8eac493bef865d7825848f0b31a06d95b08efc) This passed `hotspot_serviceability` and `jdk_svc` tests on linux-riscv64 platform with both release and fastdebug builds.
> 
> Thanks a lot for the patch.
> 
> Unfortunately we changed direction a bit after you submitted it, because of implementation difficulties on other platforms.
> 
> Can you please take a look at the new and simpler version?
> 
> Thanks Markus

ping @RealFYang

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

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

From jbechberger at openjdk.org  Fri May 23 21:20:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 23 May 2025 21:20:39 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix compilation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/eaca165d..5e03c9cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=03-04

  Stats: 44 lines in 5 files changed: 18 ins; 5 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From egahlin at openjdk.org  Fri May 23 22:24:58 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 23 May 2025 22:24:58 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v2]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <lN0KDkY42nshm0llGv2AInjustfpUX7gCI0jABtNAf8=.ba548092-5b6f-45c1-8ba8-2b62d3d7dae9@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/2e5ade83..489fd830

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=00-01

  Stats: 117 lines in 16 files changed: 37 ins; 53 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From egahlin at openjdk.org  Fri May 23 23:36:25 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 23 May 2025 23:36:25 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v3]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <gYlYopwvvsjqIAFyQQy7WZWS5CtFGtFi59uaRpc6kkI=.d71b45ce-8067-46e7-99a3-99a288f0ce95@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Atomic::load_acquire(&_method_tracer_state);

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/489fd830..c274da49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From mgronlun at openjdk.org  Sat May 24 15:22:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 24 May 2025 15:22:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 103:

> 101:   volatile CPUTimeLockState _cpu_time_jfr_locked = UNLOCKED;
> 102:   volatile bool _has_cpu_time_jfr_requests = false;
> 103:   JfrCPUTimeTraceQueue _cpu_time_jfr_queue{0};

Please initialize these fields in the initializer list, like the other fields.

Also, what capacity will the JfrCPUTimeTraceQueue have with an initializer like the above - {0}? In GDB i see that the capacity is 10000. Each element is 48 bytes, meaning each thread now has an associated queue of 468 kb, almost 0.5 Mb. Is that correct?

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

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

From mgronlun at openjdk.org  Sat May 24 17:50:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 24 May 2025 17:50:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>
Message-ID: <sxAXms36CjUk_RnGyl3C67n1z0O_smuaFPuUe4dw2_g=.07425b0e-44fc-44e0-962f-e45edca52d75@github.com>

On Sat, 24 May 2025 15:19:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 103:
> 
>> 101:   volatile CPUTimeLockState _cpu_time_jfr_locked = UNLOCKED;
>> 102:   volatile bool _has_cpu_time_jfr_requests = false;
>> 103:   JfrCPUTimeTraceQueue _cpu_time_jfr_queue{0};
> 
> Please initialize these fields in the initializer list, like the other fields.
> 
> Also, what capacity will the JfrCPUTimeTraceQueue have with an initializer like the above - {0}? In GDB i see that the capacity is 10000. Each element is 48 bytes, meaning each thread now has an associated queue of 468 kb, almost 0.5 Mb. Is that correct?

I see that JfrCPUTimeTraceQueue::ensure_capacity_for_period() calculates and sets the queue size as a function of the sampling period (in my case its 1 ms).

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

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

From stuefe at openjdk.org  Sun May 25 08:15:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 25 May 2025 08:15:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <nd_M9g-WTf-wxIX7vW8i9Qy2JT39_tEij2EyN0hzkw8=.fea97937-082f-44ba-a7f9-95559f05aef4@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

@parttimenerd 

Drive-by comments:

The ThreadCrashProtection deeply worries me; I have argued against this technique several times in the past, so I will save us the time here. But I don't see it used anywhere in this PR, so is this a remnant from older versions?

The `NoResourceMark` technique does not work as you intend it to work. As a guarantee, this is way too weak.

You want to prevent any use of ResourceMark in a non-reentry way. Just guarding chunk allocation is not sufficient since whether or not we hit those asserts at testing time depends on chunk turnover during testing, and that is highly random, very rare, and very badly fuzzied. A customer could experience a much higher frequency of chunk turnovers if they e.g. enable various combination of log flags. You will never have a good test coverage for that.

To make the `NoResourceMark` safe, you need to guard every single arena allocation path. But I would guess that is way too expensive even for debug builds.

I still think the double-buffering-technique sketched out here https://bugs.openjdk.org/browse/JDK-8349578 is better, and it would be useful outside the context of asynchronous profiling. I'll slot in some days post JDK 25 to explore that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2907682934

From jbechberger at openjdk.org  Sun May 25 08:37:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 08:37:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <nd_M9g-WTf-wxIX7vW8i9Qy2JT39_tEij2EyN0hzkw8=.fea97937-082f-44ba-a7f9-95559f05aef4@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <nd_M9g-WTf-wxIX7vW8i9Qy2JT39_tEij2EyN0hzkw8=.fea97937-082f-44ba-a7f9-95559f05aef4@github.com>
Message-ID: <DmJ8ifkoyWV5C7g4YOi3tuAlXt2eweD5l6qKsC9hsHU=.d2efa7c0-70e5-4538-9423-44be1ed1f085@github.com>

On Sun, 25 May 2025 08:13:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The ThreadCrashProtection deeply worries me; I have argued against this technique several times in the past, so I will save us the time here. But I don't see it used anywhere in this PR, so is this a remnant from older versions?

You're right, I don't know how this ended up in this PR. I'll remove it.

> To make the NoResourceMark safe, you need to guard every single arena allocation path. But I would guess that is way too expensive even for debug builds.

Good to know, then I'll remove the NoResourceMark for now too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2907692503

From mgronlun at openjdk.org  Sun May 25 10:23:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 10:23:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/jfr.inline.hpp line 35:

> 33: inline bool Jfr::has_sample_request(JavaThread* jt) {
> 34:   assert(jt != nullptr, "invariant");
> 35:   return jt->jfr_thread_local()->has_sample_request() || jt->jfr_thread_local()->has_cpu_time_jfr_requests();

Only need a single dereference of jfr_thread_local() here, not two.

src/hotspot/share/jfr/metadata/metadata.xml line 966:

> 964: 
> 965:   <Event name="CPUTimeSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Sample"
> 966:     description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units."

What is the minimal practical sampling period allowed?

src/hotspot/share/jfr/metadata/metadata.xml line 972:

> 970:     <Field type="boolean" name="failed" label="Failed" description="Failed to obtain the stack trace" />
> 971:     <Field type="Tickspan" name="samplingPeriod" label="CPU Time Sampling Period"/>
> 972:     <Field type="boolean" name="biased" label="Biased" description="The sample is biased towards the frame at safepoint" />

"The sampled is biased towards the frame at safepoint". What does that mean? Are there three things involved? A sample, a frame and a safepoint? How are they related? See if you can clarify what you intend to communicate here.

src/hotspot/share/jfr/metadata/metadata.xml line 975:

> 973:   </Event>
> 974: 
> 975:   <Event name="CPUTimeSampleLoss" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Lost Samples" description="Records that the CPU time sampler lost samples because of internal throttling"

"Because of internal throttling" seems to blur into the concept of "throttling" unnecessarily. Is there an external and an internal throttling? How are they related? What is the difference?

It is probably better to avoid the term "throttling" altogether here

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 25:

> 23:  */
> 24: 
> 25: #include "gc/shared/barrierSet.hpp"

Is this used / needed?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:

> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
> 199: 
> 200:   // sample all marked threads out of safepoint

What is mean by "out of safepoint"?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 219:

> 217:   void stop_timer();
> 218: 
> 219:   void trigger_out_of_safepoint_sampling();

What is "out of safepoint sampling"?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 233:

> 231: }
> 232: 
> 233: JfrCPUTimeThreadSampler::~JfrCPUTimeThreadSampler() {

Can remove.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 561:

> 559:     case _thread_in_native:
> 560:       return true;
> 561:     case _thread_in_vm:

"_thread_in_vm"?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 694:

> 692:     while (iter.has_next()) {
> 693:       JavaThread *thread = iter.next();
> 694:       JfrThreadLocal* tl = thread->jfr_thread_local();

A JfrThreadLocal is never null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106152036
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106152299
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106152736
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153242
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153514
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153926
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106153992
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106154053
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106154497
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106154997

From mgronlun at openjdk.org  Sun May 25 10:26:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 10:26:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <Me59DcqMbE3o6__L1QWJbHWaiOQYH4I4l4BQQLhHvDk=.74c8a096-8d23-4661-813d-cec91e11c2f3@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:

> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
> 117:   JfrEventThrottler* const throttler = for_event(event_id);
> 118:   if (throttler == nullptr) {

Should never be possible and so not needed.

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

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

From mgronlun at openjdk.org  Sun May 25 10:30:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 10:30:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <1LRlNWC_mATPBRJpEYSjOUp7jt667-bfs1c-YYVvgnQ=.21099c26-1a70-4d39-9ba4-4bdfe9d87527@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 548:

> 546: #ifdef LINUX
> 547: 
> 548: bool JfrThreadLocal::acquire_cpu_time_jfr_enqueue_lock() {

Can you describe the lock protocol and why a thread must lock its thread-local queue?

Is it because sampling interrupts can interleave after you have started to process a sample as part of a previous interrupt?

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 373:

> 371: #ifdef LINUX
> 372:   void set_cpu_timer(timer_t timer) {
> 373:     _has_cpu_timer = true;

Does not necessarily have to be defined in the .hpp file. Please move to .cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106156788
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106156997

From jbechberger at openjdk.org  Sun May 25 10:38:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 10:38:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <1LRlNWC_mATPBRJpEYSjOUp7jt667-bfs1c-YYVvgnQ=.21099c26-1a70-4d39-9ba4-4bdfe9d87527@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <1LRlNWC_mATPBRJpEYSjOUp7jt667-bfs1c-YYVvgnQ=.21099c26-1a70-4d39-9ba4-4bdfe9d87527@github.com>
Message-ID: <viW35l259PrOKLerBDygCR7rsfyAFfTmpeMHKxpRx1E=.66259c28-6c7f-4225-8053-c62a106efed3@github.com>

On Sun, 25 May 2025 10:27:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 548:
> 
>> 546: #ifdef LINUX
>> 547: 
>> 548: bool JfrThreadLocal::acquire_cpu_time_jfr_enqueue_lock() {
> 
> Can you describe the lock protocol and why a thread must lock its thread-local queue?
> 
> Is it because sampling interrupts can interleave after you have started to process a sample as part of a previous interrupt?

Yes and they can interleave with the safepoint too.

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

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

From mgronlun at openjdk.org  Sun May 25 14:45:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 14:45:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <KVc1WVXPpMKZi4bfw9P8HHkeFF5u9BRrtoVvObNR7nQ=.a05b4bf4-d927-49f4-bb74-141e2e75b620@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 37:

> 35: 
> 36: #include "jfr/recorder/service/jfrOptionSet.hpp"
> 37: #include "jfr/recorder/service/jfrEvent.hpp"

Please check the order of includes.

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

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

From mgronlun at openjdk.org  Sun May 25 14:51:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 14:51:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <lP4Kv7sRdwyT6pWweIDVLqoc2c_JyjpzROfrDGvVDrM=.3d581bb7-d9d8-4c5c-b6cf-04c00f7a9f92@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 28:

> 26: #include "jfr/jfrEvents.hpp"
> 27: #include "jfr/periodic/sampling/jfrThreadSampler.hpp"
> 28: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"

Include order.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 355:

> 353: void JfrCPUTimeThreadSampler::sample_out_of_safepoint(JavaThread* thread) {
> 354:   assert(thread->jfr_thread_local() != nullptr, "invariant");
> 355:   JfrThreadLocal* tl = thread->jfr_thread_local();

Perhaps assert tl != nullptr here instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106223669
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106223067

From mgronlun at openjdk.org  Sun May 25 14:56:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 14:56:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 65:

> 63:   Thread* raw_thread = Thread::current_or_null_safe();
> 64:   JavaThread* jt;
> 65:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism

Is "!raw_thread->is_Java_thread()" even possible, if a timer is only associated with a JavaThread, and a thread deletes its timer before it destroys itself?

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

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

From mgronlun at openjdk.org  Sun May 25 15:07:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:07:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <IXJ8OwvQkG8qy4yW_2ZWZ8vmeA-o95Hg4KZkyZ2CVaQ=.8c4bce5c-2ba0-4ccd-858e-e78c71b8826e@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/recorder/jfrRecorder.cpp line 33:

> 31: #include "jfr/periodic/jfrOSInterface.hpp"
> 32: #include "jfr/periodic/sampling/jfrThreadSampler.hpp"
> 33: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"

Include order.

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

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

From mgronlun at openjdk.org  Sun May 25 15:18:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:18:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <0cZkhmGwTqb39aqwnIqJQC9fyQLXXjhhiLGSFEVbIoc=.05712bd8-1730-4452-9d47-c30a69a77ef2@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 590:

> 588:   // so samples might be skipped and we have to compute the actual period
> 589:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
> 590:   request._cpu_time_period = Ticks(period / 1000000000.0 * JfrTime::frequency()) - Ticks(0);

Are you treating JfrTime::frequency() as nanos here? JfrTime::frequency() can be in ticks, hence not a valid conversion.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 630:

> 628: 
> 629: bool JfrCPUTimeThreadSampler::create_timer_for_thread(JavaThread* thread, timer_t& timerid) {
> 630:   if (thread->osthread() == nullptr || thread->osthread()->thread_id() == 0){

When is this possible?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106229890
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106230710

From mgronlun at openjdk.org  Sun May 25 15:31:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:31:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:

> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
> 117:   JfrEventThrottler* const throttler = for_event(event_id);
> 118:   if (throttler == nullptr) {

Unfortunately, two checks have been introduced on the throttler hot path. Can we avoid this in some way?

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

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

From mgronlun at openjdk.org  Sun May 25 15:35:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:35:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>
Message-ID: <8S63YvUNvfsoC8kD3JjL-BZ78hTKz2MNz0A1T6Btt94=.51d84638-89f2-4192-b7dd-06a206c5613b@github.com>

On Sun, 25 May 2025 15:29:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:
> 
>> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
>> 117:   JfrEventThrottler* const throttler = for_event(event_id);
>> 118:   if (throttler == nullptr) {
> 
> Unfortunately, two checks have been introduced on the throttler hot path. Can we avoid this in some way?

Can the settings system be updated so the throttle bit is not set in the native settings struct?

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

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

From mgronlun at openjdk.org  Sun May 25 15:42:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:42:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168:

> 166:   assert(jt != nullptr, "invariant");
> 167: 
> 168:   biased = false;

Can be moved after the has_last_Java_frame() check.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:

> 360: #ifdef LINUX
> 361:   if (tl->has_cpu_time_jfr_requests()) {
> 362:     JfrTicks now = JfrTicks::now();

You should be able to reuse the already taken now, no?

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 375:

> 373:     }
> 374:     queue.clear();
> 375:     tl->release_cpu_time_jfr_queue_lock();

Is this releasing a different lock from the one acquired? "dequeue" lock vs "queue" lock?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106235901
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236251
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236738

From mgronlun at openjdk.org  Sun May 25 15:42:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:42:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>
Message-ID: <s5EzZFRWgVV2huuiUbfCn03h9WnRLApPiTlaFLzyf_M=.416b5768-3632-4100-bd48-6dd50367a537@github.com>

On Sun, 25 May 2025 15:36:59 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168:
> 
>> 166:   assert(jt != nullptr, "invariant");
>> 167: 
>> 168:   biased = false;
> 
> Can be moved after the has_last_Java_frame() check.

Alternatively its not needed, as it is initialized by the caller.

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

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

From mgronlun at openjdk.org  Sun May 25 15:46:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 15:46:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <JmMLQxtnXHlk8niCL3qIPCkP3IlbCciH7tbwpQEWGHs=.d196869b-b5a1-477c-8259-3340973e3ab5@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 564:

> 562: }
> 563: 
> 564: void JfrThreadLocal::set_has_cpu_time_jfr_requests(bool has_events) {

"has_events" seems to be an unfortunate naming. "has_requests" I guess?

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

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

From mgronlun at openjdk.org  Sun May 25 16:19:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 16:19:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 365:

> 363:   // idea: this ensures that the frames happened in native
> 364:   // maybe we can wrap this in #ifdef ASSERT if first_index is always 0
> 365:   s4 first_index = queue.size() - 1;

I'm afraid I don't understand this logic at all. If the intent is to share a sid over many requests, why are the individual requests passed to stacktrace.record_inner()?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 373:

> 371:     }
> 372:   }
> 373:   assert(first_index == 0, "invariant");

How is this possible?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106244737
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106244850

From mgronlun at openjdk.org  Sun May 25 19:50:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 19:50:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <p0olw0VtNkpCkEhtTxaBgGKtSfINaKBPKmudCl_8Dd0=.6dc3c631-27c4-4809-8626-efabb02f84ae@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 574:

> 572:   JfrThreadLocal* tl = jt->jfr_thread_local();
> 573:   if (!check_state(jt) ||
> 574:       jt->is_at_poll_safepoint() ||

jt->is_at_poll_safepoint() should be impossible after check_state()

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

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

From mgronlun at openjdk.org  Sun May 25 20:14:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 20:14:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>
Message-ID: <yguC8lxZCJ1mYXeaC41Fyh4n23SE4oSMTNxxbZDa5hQ=.b5f7a3bb-a647-4158-83bb-ccdbfd376902@github.com>

On Sun, 25 May 2025 14:54:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 65:
> 
>> 63:   Thread* raw_thread = Thread::current_or_null_safe();
>> 64:   JavaThread* jt;
>> 65:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism
> 
> Is "!raw_thread->is_Java_thread()" even possible, if a timer is only associated with a JavaThread, and a thread deletes its timer before it destroys itself?

Also, is raw_thread == nullptr even possible? For the same reasons.

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

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

From mgronlun at openjdk.org  Sun May 25 20:24:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 20:24:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <Eahg9W0VHfIBpRtgQav7gbPf4P8N8bsQWK7w9mDdjvg=.0478326a-b880-4725-bde5-4b4fa9603104@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 146:

> 144:   s4 lost_samples = Atomic::load_acquire(&_lost_samples);
> 145:   while (Atomic::cmpxchg(&_lost_samples, lost_samples, 0) != lost_samples) {
> 146:     lost_samples = Atomic::load_acquire(&_lost_samples);

You can save and reuse what cmpxchg returns to you.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 169:

> 167: }
> 168: 
> 169: static int64_t compute_sampling_period(double rate);

Why is this fwd declared?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 178:

> 176:   double _rate;
> 177:   bool _autoadapt;
> 178:   volatile int64_t _current_sampling_period_ns = -1;

Please initialize all variables in the constructor's initializer list instead of inline in the header file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106297053
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106297745
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106298076

From mgronlun at openjdk.org  Sun May 25 20:33:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 20:33:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 378:

> 376: 
> 377:   void unset_cpu_timer() {
> 378:     _has_cpu_timer = false;

Do we really need a separate bool to understand whether the thread has a timer? Can't that information be deduced from the timer_t?

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

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

From egahlin at openjdk.org  Sun May 25 20:42:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 25 May 2025 20:42:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java line 269:

> 267:         settingValues.put(EventNames.VirtualThreadSubmitFailed + "#threshold", "0 ns");
> 268:         settingValues.put(EventNames.SecurityProviderService + "#threshold", "0 ns");
> 269:         settingValues.put(EventNames.CPUTimeSampleLoss + "#threshold", "0 ns");

This should not be necessary for JVM events. JDK events are on the list because it was not possible to create instantaneous events in Java (it is now possible).

I see that the CPU Sample event has a duration. What does the duration field indicate when sampling?

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

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

From jbechberger at openjdk.org  Sun May 25 20:51:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 20:51:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
Message-ID: <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>

On Sun, 25 May 2025 20:30:50 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 378:
> 
>> 376: 
>> 377:   void unset_cpu_timer() {
>> 378:     _has_cpu_timer = false;
> 
> Do we really need a separate bool to understand whether the thread has a timer? Can't that information be deduced from the timer_t?

Do we want to make hard assumptions on timer_t?

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

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

From jbechberger at openjdk.org  Sun May 25 20:51:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 25 May 2025 20:51:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
Message-ID: <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>

On Sun, 25 May 2025 20:40:02 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java line 269:
> 
>> 267:         settingValues.put(EventNames.VirtualThreadSubmitFailed + "#threshold", "0 ns");
>> 268:         settingValues.put(EventNames.SecurityProviderService + "#threshold", "0 ns");
>> 269:         settingValues.put(EventNames.CPUTimeSampleLoss + "#threshold", "0 ns");
> 
> This should not be necessary for JVM events. JDK events are on the list because it was not possible to create instantaneous events in Java (it is now possible).
> 
> I see that the CPU Sample event has a duration. What does the duration field indicate when sampling?

How long the stack walking took. But it's probably irrelevant with the new design.

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

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

From mgronlun at openjdk.org  Sun May 25 20:54:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 20:54:47 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v40]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <7-ba2LTbmuKGwwMe7LNllRVg6XKj83PyHnULAwN1Tmc=.63e61a5d-fd37-4c9e-9fd2-c97cf7b50b95@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  const void* ucontext

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/1cf582a0..9ac38b83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=38-39

  Stats: 14 lines in 4 files changed: 3 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Sun May 25 21:11:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:11:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
Message-ID: <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>

On Sun, 25 May 2025 20:49:37 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 378:
>> 
>>> 376: 
>>> 377:   void unset_cpu_timer() {
>>> 378:     _has_cpu_timer = false;
>> 
>> Do we really need a separate bool to understand whether the thread has a timer? Can't that information be deduced from the timer_t?
>
> Do we want to make hard assumptions on timer_t?

You can have a field as a pointer: timer_t* timer and test it, timer != nullptr.

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

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

From mgronlun at openjdk.org  Sun May 25 21:28:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:28:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 601:

> 599: 
> 600:   if (jt->thread_state() == _thread_in_native &&
> 601:     tl->cpu_time_jfr_queue().size() > tl->cpu_time_jfr_queue().capacity() * 2 / 3) {

Is this testing what you intend? The precedence order is [*, / ], from left to right associativity

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

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

From mgronlun at openjdk.org  Sun May 25 21:32:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:32:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <y2X5AHjzs1u3xGHuaY0LA4sYrzCJKE4QeVS_JRRs5_M=.803399c0-b155-4cb1-b531-d584022d43e6@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 374:

> 372:       JfrCPUTimeThreadSampling::send_lost_event( now, JfrThreadLocal::thread_id(jt), queue.get_and_reset_lost_samples());
> 373:     }
> 374:     queue.clear();

queue.clear() is the same operation as queue.set_size(0) on line 368.

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

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

From egahlin at openjdk.org  Sun May 25 21:37:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 25 May 2025 21:37:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
 <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>
Message-ID: <4PG8JOwkZhQmiZfPk3R54_rlUKrW0e_8F-fv34WgtgY=.37bdee69-c849-4df1-b50b-0e6239f91c96@github.com>

On Sun, 25 May 2025 20:48:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> How long the stack walking took. But it's probably irrelevant with the new design.

It will probably confuse user more than help them.

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

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

From mgronlun at openjdk.org  Sun May 25 21:40:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 25 May 2025 21:40:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
Message-ID: <1EjAxFqZsL3bcgfK1d7eJWqpejhNG5MsInZmbJb1WFA=.e3c23329-a5a8-4fce-9296-22ffff247933@github.com>

On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 401:

> 399: 
> 400:   JfrCPUTimeTraceQueue& cpu_time_jfr_queue();
> 401:   void disable_cpu_time_jfr_queue();

Seems a bit strange that you can "disable" a queue. When is it enabled? Since the underlying implementation delegates to ensure_capacity for size == 0, and deallocates, perhaps a more appropriate name is "deallocate_cpu_time_jfr_queue()"?

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

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

From fyang at openjdk.org  Sun May 25 23:59:57 2025
From: fyang at openjdk.org (Fei Yang)
Date: Sun, 25 May 2025 23:59:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <VKfMWVxcB-WFGwKCWtmG5-TxM-f7zQ--B9njqgGy24Y=.327decaf-78c3-4aca-b96e-1cb51f5fa07c@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <-hhrsRy3MadVDVJoQs2chfkrBWrH-LebAyu6EGlH7MQ=.0e30fb30-fc8e-4dc5-84ce-d238824cdcb2@github.com>
 <VKfMWVxcB-WFGwKCWtmG5-TxM-f7zQ--B9njqgGy24Y=.327decaf-78c3-4aca-b96e-1cb51f5fa07c@github.com>
Message-ID: <OHnNDdPNF_zGY0FNDHK7kT3ZszzM6494UMU8DB58Lh0=.76683101-f391-4bb0-a175-52f1cf3e5c27@github.com>

On Fri, 23 May 2025 19:47:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>>> Hi, Could you please incorporate this change for riscv? Thanks. [RealFYang at be8eac4](https://github.com/RealFYang/jdk/commit/be8eac493bef865d7825848f0b31a06d95b08efc) This passed `hotspot_serviceability` and `jdk_svc` tests on linux-riscv64 platform with both release and fastdebug builds.
>> 
>> Thanks a lot for the patch.
>> 
>> Unfortunately we changed direction a bit after you submitted it, because of implementation difficulties on other platforms.
>> 
>> Can you please take a look at the new and simpler version?
>> 
>> Thanks
>> Markus
>
>> > Hi, Could you please incorporate this change for riscv? Thanks. [RealFYang at be8eac4](https://github.com/RealFYang/jdk/commit/be8eac493bef865d7825848f0b31a06d95b08efc) This passed `hotspot_serviceability` and `jdk_svc` tests on linux-riscv64 platform with both release and fastdebug builds.
>> 
>> Thanks a lot for the patch.
>> 
>> Unfortunately we changed direction a bit after you submitted it, because of implementation difficulties on other platforms.
>> 
>> Can you please take a look at the new and simpler version?
>> 
>> Thanks Markus
> 
> ping @RealFYang

@mgronlun : Thanks for the ping! New riscv version which reflects the latest changes: https://github.com/RealFYang/jdk/commit/cba533aac60476e4893fd57e2d459d69b95ecfbf
I performed tier1-3, hotspot_serviceability and jdk_svc tests on linux-riscv64 platform. Result looks good.

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

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

From jbechberger at openjdk.org  Mon May 26 06:31:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:31:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <yguC8lxZCJ1mYXeaC41Fyh4n23SE4oSMTNxxbZDa5hQ=.b5f7a3bb-a647-4158-83bb-ccdbfd376902@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>
 <yguC8lxZCJ1mYXeaC41Fyh4n23SE4oSMTNxxbZDa5hQ=.b5f7a3bb-a647-4158-83bb-ccdbfd376902@github.com>
Message-ID: <Czq2ZlXAaiBc6IFEwZ4HjHy5JiJ3cSrWdQ8OfDVwCf0=.82a7c7ad-44e0-498d-8a7a-7dd8c0e00a60@github.com>

On Sun, 25 May 2025 20:12:09 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 65:
>> 
>>> 63:   Thread* raw_thread = Thread::current_or_null_safe();
>>> 64:   JavaThread* jt;
>>> 65:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism
>> 
>> Is "!raw_thread->is_Java_thread()" even possible, if a timer is only associated with a JavaThread, and a thread deletes its timer before it destroys itself?
>
> Also, is raw_thread == nullptr even possible? For the same reasons.

`!raw_thread->is_Java_thread()` I found it during testing.

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

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

From jbechberger at openjdk.org  Mon May 26 06:31:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:31:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
Message-ID: <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>

On Sun, 25 May 2025 16:17:12 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 373:
> 
>> 371:     }
>> 372:   }
>> 373:   assert(first_index == 0, "invariant");
> 
> How is this possible?

Because we have a safepoint before the thread goes into native (as far as I understand). I'll remove the code above, because it is therefore not needed.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 590:
> 
>> 588:   // so samples might be skipped and we have to compute the actual period
>> 589:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
>> 590:   request._cpu_time_period = Ticks(period / 1000000000.0 * JfrTime::frequency()) - Ticks(0);
> 
> Are you treating JfrTime::frequency() as nanos here? JfrTime::frequency() can be in ticks, hence not a valid conversion.

Could you give me a hand with the conversion?

> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 375:
> 
>> 373:     }
>> 374:     queue.clear();
>> 375:     tl->release_cpu_time_jfr_queue_lock();
> 
> Is this releasing a different lock from the one acquired? "dequeue" lock vs "queue" lock?

These are not really different locks, as the lock has four different states. So it just changes the lock state from DEQUEUE to UNLOCKED.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106637673
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106642499
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106639331

From jbechberger at openjdk.org  Mon May 26 06:31:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:31:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
Message-ID: <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>

On Sun, 25 May 2025 21:09:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Do we want to make hard assumptions on timer_t?
>
> You can have a field as a pointer: timer_t* timer and test it, timer != nullptr.

Wouldn't I need to store it somewhere?

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

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

From jbechberger at openjdk.org  Mon May 26 06:34:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:34:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
Message-ID: <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>

On Sun, 25 May 2025 10:16:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:
> 
>> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
>> 199: 
>> 200:   // sample all marked threads out of safepoint
> 
> What is meant by "out of safepoint"?

Stack walking that occurs not at a safepoint, but during longer periods of a thread being in native. We can't walk the stack directly when we're in native, as we can't properly walk stacks in signal handlers. So we defer this to a separate thread.

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

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

From jbechberger at openjdk.org  Mon May 26 06:38:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 06:38:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
Message-ID: <qXLIwSFFMQ347gAA1-HPvS-hr7Qu9MPkfkw66Gwcjjs=.03777399-1f98-4435-8075-710872f2486d@github.com>

On Sun, 25 May 2025 10:08:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/metadata/metadata.xml line 966:
> 
>> 964: 
>> 965:   <Event name="CPUTimeSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Sample"
>> 966:     description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units."
> 
> What is the minimal practical sampling period allowed?

Depends on your system: It is configured via `CONFIG_HZ` at build time. This value is usually between 250 and 1000 Hz. We could proactively lower-bound the interval to 1ms or just state it in the description.

> src/hotspot/share/jfr/metadata/metadata.xml line 972:
> 
>> 970:     <Field type="boolean" name="failed" label="Failed" description="Failed to obtain the stack trace" />
>> 971:     <Field type="Tickspan" name="samplingPeriod" label="CPU Time Sampling Period"/>
>> 972:     <Field type="boolean" name="biased" label="Biased" description="The sample is biased towards the frame at safepoint" />
> 
> "The sample is biased towards the frame at safepoint". What does that mean? Are there three things involved? A sample, a frame and a safepoint? How are they related? See if you can clarify what you intend to communicate here.

Maybe better: "The sample is safepoint-biased"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106652540
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106653359

From jbechberger at openjdk.org  Mon May 26 08:16:04 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:16:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <sxAXms36CjUk_RnGyl3C67n1z0O_smuaFPuUe4dw2_g=.07425b0e-44fc-44e0-962f-e45edca52d75@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <gQnwUtBQ3ii_hbM-aK4KN5DHJfnvYhwwn0RwToF53lY=.bf0dbaa9-c7bf-4f1d-bbb1-bd218bd17f24@github.com>
 <sxAXms36CjUk_RnGyl3C67n1z0O_smuaFPuUe4dw2_g=.07425b0e-44fc-44e0-962f-e45edca52d75@github.com>
Message-ID: <--htE9vU4m2HJ_ZrauUWBuHcQA-w-SCvRLisaYA_9KI=.588586a8-5d20-4abe-90d4-87fc0a3304a9@github.com>

On Sat, 24 May 2025 17:48:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 103:
>> 
>>> 101:   volatile CPUTimeLockState _cpu_time_jfr_locked = UNLOCKED;
>>> 102:   volatile bool _has_cpu_time_jfr_requests = false;
>>> 103:   JfrCPUTimeTraceQueue _cpu_time_jfr_queue{0};
>> 
>> Please initialize these fields in the initializer list, like the other fields.
>> 
>> Also, what capacity will the JfrCPUTimeTraceQueue have with an initializer like the above - {0}? In GDB i see that the capacity is 10000. Each element is 48 bytes, meaning each thread now has an associated queue of 468 kb, almost 0.5 Mb. Is that correct?
>
> I see that JfrCPUTimeTraceQueue::ensure_capacity_for_period() calculates and sets the queue size as a function of the sampling period (in my case its 1 ms).

I reduced the base capacity to 500, but with far smaller values we risk many more lossed events. We should probably tune this value at the end.

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

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

From mgronlun at openjdk.org  Mon May 26 08:16:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:16:10 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
Message-ID: <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>

On Mon, 26 May 2025 06:23:08 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> You can have a field as a pointer: timer_t* timer and test it, timer != nullptr.
>
> Wouldn't I need to store it somewhere?

Of course. A pointer is less space compared to an inlined struct AND a bool.

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

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

From jbechberger at openjdk.org  Mon May 26 08:24:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:24:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
Message-ID: <UpJCmbSDSRS2F3kVksmroS6ZKHnFHcLOcCntPYEfiF8=.26c444b7-f433-4d2e-a5fe-8afd5f11435e@github.com>

On Sun, 25 May 2025 10:14:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 25:
> 
>> 23:  */
>> 24: 
>> 25: #include "gc/shared/barrierSet.hpp"
> 
> Is this used / needed?

Good catch

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 219:
> 
>> 217:   void stop_timer();
>> 218: 
>> 219:   void trigger_out_of_safepoint_sampling();
> 
> What is "out of safepoint sampling"?

See above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106811373
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106805944

From mgronlun at openjdk.org  Mon May 26 08:24:36 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:24:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
Message-ID: <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>

On Mon, 26 May 2025 06:32:03 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:
>> 
>>> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
>>> 199: 
>>> 200:   // sample all marked threads out of safepoint
>> 
>> What is meant by "out of safepoint"?
>
> Stack walking that occurs not at a safepoint, but during longer periods of a thread being in native. We can't walk the stack directly when we're in native, as we can't properly walk stacks in signal handlers. So we defer this to a separate thread.

A thread in native is still stackwalked at a safe location, a safepoint code position.

It's guaranteed by the last java frame (ljf).

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 373:
>> 
>>> 371:     }
>>> 372:   }
>>> 373:   assert(first_index == 0, "invariant");
>> 
>> How is this possible?
>
> Because we have a safepoint before the thread goes into native (as far as I understand). I'll remove the code above, because it is therefore not needed.

There is no safepoint when a thread goes from Java to native.

It's done on the way back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106808431
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106814829

From jbechberger at openjdk.org  Mon May 26 08:24:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:24:39 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
 <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
Message-ID: <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>

On Mon, 26 May 2025 08:08:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Wouldn't I need to store it somewhere?
>
> Of course. A pointer is less space compared to an inlined struct AND a bool.

But I would need to store the timer_t somewhere? Or where would `timer_t* time` point to?

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

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

From mgronlun at openjdk.org  Mon May 26 08:33:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:33:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
 <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
 <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>
Message-ID: <Pnw7JovgvmxwcPV_ls8Gm0kAqxOOok5wh-L4NoGpvXk=.7f383353-9966-4513-8950-38887927083e@github.com>

On Mon, 26 May 2025 08:19:16 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Of course. A pointer is less space compared to an inlined struct AND a bool.
>
> But I would need to store the timer_t somewhere? Or where would `timer_t* time` point to?

You store the pointer in JfrThreadLocal, instead of the inlined timer_t struct.

One benefit is that you can fwd declare the type and need not include its header.

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

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

From jbechberger at openjdk.org  Mon May 26 08:33:12 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 08:33:12 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
Message-ID: <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>

On Mon, 26 May 2025 08:18:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Stack walking that occurs not at a safepoint, but during longer periods of a thread being in native. We can't walk the stack directly when we're in native, as we can't properly walk stacks in signal handlers. So we defer this to a separate thread.
>
> A thread in native is still stackwalked at a safe location, a safepoint code position.
> 
> It's guaranteed by the last java frame (ljf).

Yes, but it might be an indeterminate time between entering and exiting the native thread state. So I need to walk them in between. Your sampler implementation also walks threads in native state.

>> Because we have a safepoint before the thread goes into native (as far as I understand). I'll remove the code above, because it is therefore not needed.
>
> There is no safepoint when a thread goes from Java to native.
> 
> It's done on the way back.

Ok, then I need my check. The check ensures that I only walk stacks that have the same top Java frame as the current frame (which is by design related to a stack trace in native). I don't want to walk non-native thread state stack traces here.

This is implemented to ensure that we also sample threads while they are in a long native period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106829651
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106825442

From mgronlun at openjdk.org  Mon May 26 08:33:15 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 08:33:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <Pnw7JovgvmxwcPV_ls8Gm0kAqxOOok5wh-L4NoGpvXk=.7f383353-9966-4513-8950-38887927083e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <SuEHFy9-Zfx1-H77q9KwRFva-cV9wlxxh-TRugiBAww=.e026344c-6ba3-4566-970b-f2e55b6c635f@github.com>
 <-eepT3kknzueohE5Uf3tmdNS3JzNb2un9WTKimB1T6U=.3af52ad7-16cd-4cf6-9b5f-1915b069000c@github.com>
 <KUb-pPrqxilQtzKfxlFf1LCTIPhCcCrIjz-IyzorOX4=.4a69ab91-49c4-47fe-9bcb-9d8741970cf6@github.com>
 <wJuLeiY5h58Q6H8e8dWelwn9KNllzS91eWXk81rr7SI=.3fd66d9b-c4ef-4944-a351-e8aafa5504af@github.com>
 <UqdJibBFSFlNHJKpkdoEWwogwkBl_VvdLAK7bQtKiTM=.fd41261e-f993-417f-b7d6-2d186dffa9ad@github.com>
 <zldzW1MoRGyx0oZ8A37sMiniLyBW0wRLaGUKlbN4fB4=.d6bcda49-04fb-4d67-9bd6-f4f5fca78450@github.com>
 <Pnw7JovgvmxwcPV_ls8Gm0kAqxOOok5wh-L4NoGpvXk=.7f383353-9966-4513-8950-38887927083e@github.com>
Message-ID: <wvfmtLUHoCUutf8l99iIy2F2Or95uZgWrBm6M6SHVT0=.78748013-9b21-4dcf-a50b-2c6b5e9cc911@github.com>

On Mon, 26 May 2025 08:27:51 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> But I would need to store the timer_t somewhere? Or where would `timer_t* time` point to?
>
> You store the pointer in JfrThreadLocal, instead of the inlined timer_t struct.
> 
> One benefit is that you can fwd declare the type and need not include its header.

C heap allocated.

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

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

From mgronlun at openjdk.org  Mon May 26 09:33:30 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 09:33:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
 <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
Message-ID: <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>

On Mon, 26 May 2025 08:30:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> A thread in native is still stackwalked at a safe location, a safepoint code position.
>> 
>> It's guaranteed by the last java frame (ljf).
>
> Yes, but it might be an indeterminate time between entering and exiting the native thread state. So I need to walk them in between. Your sampler implementation also walks threads in native state.

That's fine. Its the term "out of safepoint" which is a concept that does not refer to anything concrete.

"Sampling" is the process of saving and enqueing a JfrSampleRequest.

"Stackwalking" or "processing of enqueued requests" is another thing. Are you referring to the second here?

"out of safepoint" does not make any sense.

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

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

From jbechberger at openjdk.org  Mon May 26 09:33:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v6]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Vq37TpakBo68qWj62_9yzPKvHbNL5TuX1IDnyR-C7Ks=.16f00cf5-55a0-42bf-bca8-fdf1f33fc159@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with six additional commits since the last revision:

 - Improve names
 - Refactor
   
   Rename out_of_safepoint to thread_in_native and more
 - Refactoring
 - Revert ThreadCrashProtection change
 - Remove NoResourceMark
 - Reduce base queue capacity to 500 from 1000

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/5e03c9cf..403444f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=04-05

  Stats: 200 lines in 14 files changed: 41 ins; 92 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From mgronlun at openjdk.org  Mon May 26 09:33:31 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 09:33:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
 <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
 <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>
Message-ID: <5WvdzndVL_MnLpQtwnR30sJ6jYgWGMCeuZeQa07N_-0=.bc17d528-97dc-4427-ac9b-ec81e3b10e15@github.com>

On Mon, 26 May 2025 09:02:39 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Yes, but it might be an indeterminate time between entering and exiting the native thread state. So I need to walk them in between. Your sampler implementation also walks threads in native state.
>
> That's fine. Its the term "out of safepoint" which is a concept that does not refer to anything concrete.
> 
> "Sampling" is the process of saving and enqueing a JfrSampleRequest.
> 
> "Stackwalking" or "processing of enqueued requests" is another thing. Are you referring to the second here?
> 
> "out of safepoint" does not make any sense.

Walking from an ljf is walking at a safepoint by design. Its just that in this case, you delegate to another thread to do it.

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

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

From jbechberger at openjdk.org  Mon May 26 09:33:31 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <5WvdzndVL_MnLpQtwnR30sJ6jYgWGMCeuZeQa07N_-0=.bc17d528-97dc-4427-ac9b-ec81e3b10e15@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <hc5cErEigmX2_BMzkKl0FJOXNZrQTrYANNyywrVFd4s=.61e8cb5b-bb65-4f46-9ef4-388365b77a97@github.com>
 <9t7jUprNgsLfo7ZVTe9ukSKNqVCJynQ1_P0_E2JFOgU=.742c68c5-f2dc-4b6e-9954-d6e588f06830@github.com>
 <-4A-qolukZcY2Ho92YK_4-RpMlDgL5p4jsGWjUH-fXQ=.f86ecaf1-08c8-4160-b1e1-148c5e999c51@github.com>
 <6rzNgf0YrkkN0TpO3_f33ql__K_6QJg86GlViABXG7I=.c79c0f31-3c37-4a30-8f5a-b9fca3c092e2@github.com>
 <-02fNGjnXKgMwpbuNehBGW6_u0c3cMLxhnCNiYgPoXc=.80a98e2f-a90b-4bee-8902-3548964bf33b@github.com>
 <5WvdzndVL_MnLpQtwnR30sJ6jYgWGMCeuZeQa07N_-0=.bc17d528-97dc-4427-ac9b-ec81e3b10e15@github.com>
Message-ID: <FBWMl4ishFqhM9pPtT4f-fEXRYGNYsHIzGlAe2QAB48=.b87042d8-c438-46bd-9881-4283a3e85992@github.com>

On Mon, 26 May 2025 09:07:12 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> That's fine. Its the term "out of safepoint" which is a concept that does not refer to anything concrete.
>> 
>> "Sampling" is the process of saving and enqueing a JfrSampleRequest.
>> 
>> "Stackwalking" or "processing of enqueued requests" is another thing. Are you referring to the second here?
>> 
>> "out of safepoint" does not make any sense.
>
> Walking from an ljf is walking at a safepoint by design. Its just that in this case, you delegate to another thread to do it.

I improved the names (changed it to `thread_in_native_stackwalking`)

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

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

From jbechberger at openjdk.org  Mon May 26 09:33:36 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <0cZkhmGwTqb39aqwnIqJQC9fyQLXXjhhiLGSFEVbIoc=.05712bd8-1730-4452-9d47-c30a69a77ef2@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <0cZkhmGwTqb39aqwnIqJQC9fyQLXXjhhiLGSFEVbIoc=.05712bd8-1730-4452-9d47-c30a69a77ef2@github.com>
Message-ID: <C0xRqn7czRVsHqhUPRn3T3Nmoox2Pts8t8XJqJWfhlc=.f8f59d3e-2153-49fa-8a99-8b9dfd3720c1@github.com>

On Sun, 25 May 2025 15:16:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 630:
> 
>> 628: 
>> 629: bool JfrCPUTimeThreadSampler::create_timer_for_thread(JavaThread* thread, timer_t& timerid) {
>> 630:   if (thread->osthread() == nullptr || thread->osthread()->thread_id() == 0){
> 
> When is this possible?

I removed it.

> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:
> 
>> 360: #ifdef LINUX
>> 361:   if (tl->has_cpu_time_jfr_requests()) {
>> 362:     JfrTicks now = JfrTicks::now();
> 
> You should be able to reuse the already taken now, no?

Good catch.

> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 564:
> 
>> 562: }
>> 563: 
>> 564: void JfrThreadLocal::set_has_cpu_time_jfr_requests(bool has_events) {
> 
> "has_events" seems to be an unfortunate naming. "has_requests" I guess?

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106858516
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106862855
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106864886

From jbechberger at openjdk.org  Mon May 26 09:33:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
Message-ID: <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>

On Mon, 26 May 2025 06:28:25 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 590:
>> 
>>> 588:   // so samples might be skipped and we have to compute the actual period
>>> 589:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
>>> 590:   request._cpu_time_period = Ticks(period / 1000000000.0 * JfrTime::frequency()) - Ticks(0);
>> 
>> Are you treating JfrTime::frequency() as nanos here? JfrTime::frequency() can be in ticks, hence not a valid conversion.
>
> Could you give me a hand with the conversion?

My code is the inversion of


template <typename TimeSource, const int unit>
inline double conversion(typename TimeSource::Type& value) {
  return (double)value * ((double)unit / (double)TimeSource::frequency());
}

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

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

From jbechberger at openjdk.org  Mon May 26 09:33:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:33:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <s5EzZFRWgVV2huuiUbfCn03h9WnRLApPiTlaFLzyf_M=.416b5768-3632-4100-bd48-6dd50367a537@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <QaFphEcL0mDvlDqrxXioBNwzRBXF3IR8VtfkJh7PLzs=.1407671a-d4b0-47c8-9662-1b3239ffeaca@github.com>
 <s5EzZFRWgVV2huuiUbfCn03h9WnRLApPiTlaFLzyf_M=.416b5768-3632-4100-bd48-6dd50367a537@github.com>
Message-ID: <lsRdrCALyrsnVkVLuNOXrsL4HnMXk6q_EDQ5iZZwo7U=.4cbbdc3b-a2dd-4bee-a8c5-d0cb8ea7d336@github.com>

On Sun, 25 May 2025 15:37:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168:
>> 
>>> 166:   assert(jt != nullptr, "invariant");
>>> 167: 
>>> 168:   biased = false;
>> 
>> Can be moved after the has_last_Java_frame() check.
>
> Alternatively its not needed, as it is initialized by the caller.

I removed the assignment.

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

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

From jbechberger at openjdk.org  Mon May 26 09:40:38 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:40:38 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <4PG8JOwkZhQmiZfPk3R54_rlUKrW0e_8F-fv34WgtgY=.37bdee69-c849-4df1-b50b-0e6239f91c96@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <9AUaCpviyG2t26UeDQjbO7FyPgUol24MMJI3ifKSHHk=.40b5c84c-3598-42ce-8c19-c27da7ccc0b9@github.com>
 <hzDx2bL1U0jesiSW2AHxFci2LxAdNsQ91I3qa8DvQmw=.717c7b39-c6ee-4fbe-b471-81641e9386ba@github.com>
 <4PG8JOwkZhQmiZfPk3R54_rlUKrW0e_8F-fv34WgtgY=.37bdee69-c849-4df1-b50b-0e6239f91c96@github.com>
Message-ID: <VJahctNr9Ri4nLXlp4BC6G8k0GelGejgl7cwAOYzb-0=.7ede5f91-b4a6-4bf6-9f12-a4d15e966836@github.com>

On Sun, 25 May 2025 21:35:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> How long the stack walking took. But it's probably irrelevant with the new design.
>
>> How long the stack walking took. But it's probably irrelevant with the new design.
> 
> It will probably confuse user more than help them.

I removed it.

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

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

From jbechberger at openjdk.org  Mon May 26 09:48:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 09:48:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
Message-ID: <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>

On Sun, 25 May 2025 21:25:54 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 601:
> 
>> 599: 
>> 600:   if (jt->thread_state() == _thread_in_native &&
>> 601:     tl->cpu_time_jfr_queue().size() > tl->cpu_time_jfr_queue().capacity() * 2 / 3) {
> 
> Is this testing what you intend? The precedence order is [*, / ], from left to right associativity

I can't follow. This is testing whether the queue is more than two thirds full.

> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 374:
> 
>> 372:       JfrCPUTimeThreadSampling::send_lost_event( now, JfrThreadLocal::thread_id(jt), queue.get_and_reset_lost_samples());
>> 373:     }
>> 374:     queue.clear();
> 
> queue.clear() is the same operation as queue.set_size(0) on line 368.

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106957537
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106960969

From jbechberger at openjdk.org  Mon May 26 10:10:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 10:10:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v7]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HFfSy6DViA6MNcOMhC87efQ9Qy168ruh0yTTu1gePwQ=.c8c1143a-441c-46b6-bbd5-f473bf7135f8@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Improve queue walking in native
 - Rename and remove end_time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/403444f8..e3addfe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=05-06

  Stats: 68 lines in 7 files changed: 24 ins; 18 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 10:10:20 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 10:10:20 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
Message-ID: <3jd1OlChIF9OqHGiowJwsi_oCDx3kI1vwm2Rqx-PIZ0=.190480fc-bafb-4b67-a5da-6dd955737824@github.com>

On Sun, 25 May 2025 16:16:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 365:
> 
>> 363:   // idea: this ensures that the frames happened in native
>> 364:   // maybe we can wrap this in #ifdef ASSERT if first_index is always 0
>> 365:   s4 first_index = queue.size() - 1;
> 
> I'm afraid I don't understand this logic at all. If the intent is to share a sid over many requests, why are the individual requests passed to stacktrace.record_inner()?

I rewrote the code and store the first native request index directly in the queue. Therefore we only need to walk the queue once.

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

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

From mgronlun at openjdk.org  Mon May 26 10:27:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 10:27:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
 <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>
Message-ID: <UyvPo7VA8cLidMK4dY0PhJjiC7QSodP5TC207UMmcYM=.bf0020bc-63cc-46f2-8311-7d228a65619c@github.com>

On Mon, 26 May 2025 09:44:30 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 601:
>> 
>>> 599: 
>>> 600:   if (jt->thread_state() == _thread_in_native &&
>>> 601:     tl->cpu_time_jfr_queue().size() > tl->cpu_time_jfr_queue().capacity() * 2 / 3) {
>> 
>> Is this testing what you intend? The precedence order is [*, / ], from left to right associativity
>
> I can't follow. This is testing whether the queue is more than two thirds full.

I'm sorry, I read this wrong. In this case, it does not matter: (capacity * 2) / 3 == capacity * (2/3)

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

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

From jbechberger at openjdk.org  Mon May 26 10:31:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 10:31:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <UyvPo7VA8cLidMK4dY0PhJjiC7QSodP5TC207UMmcYM=.bf0020bc-63cc-46f2-8311-7d228a65619c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <b_-x5ulWfI1lm-qRhx5UFLzu9132d2KGLhfvorlgh7g=.9f6c5213-616d-47a9-8d67-ff5b5c77ca57@github.com>
 <ab9ZgXawgqfybGoyXmiKeGYvSa7qBbLGIu0kir4XiIQ=.6dc1c896-e5af-4b70-a1db-e7bed7f53f71@github.com>
 <UyvPo7VA8cLidMK4dY0PhJjiC7QSodP5TC207UMmcYM=.bf0020bc-63cc-46f2-8311-7d228a65619c@github.com>
Message-ID: <7u_T3IBu6hSXVH9Ebobv_Rdv8vOVaAPd_nxtyAHBq_o=.74c6955d-61c8-4c45-83df-5c402543bb61@github.com>

On Mon, 26 May 2025 10:25:28 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I can't follow. This is testing whether the queue is more than two thirds full.
>
> I'm sorry, I read this wrong. In this case, it does not matter: (capacity * 2) / 3 == capacity * (2/3)

I ignored the small underflow, so `size() * 3 > capacity() * 2` is more accurate, but far less readable.

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

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

From mgronlun at openjdk.org  Mon May 26 11:00:21 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 11:00:21 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v41]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <RKVYJXKL3TPtWhHZ3cJMOGjZ2zBFdrrD0shVi6j_Pjc=.6697c087-585c-48d4-9415-6e2d6857bd25@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  8352251-riscv-port

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/9ac38b83..44330f9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=39-40

  Stats: 185 lines in 10 files changed: 145 ins; 22 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Mon May 26 11:00:21 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 11:00:21 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v32]
In-Reply-To: <VKfMWVxcB-WFGwKCWtmG5-TxM-f7zQ--B9njqgGy24Y=.327decaf-78c3-4aca-b96e-1cb51f5fa07c@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kIL4Nc0_gp9VBmRa-t7YmEjMG36Pd4Pmpk3XVwD0KJ0=.7dec835f-364b-4e2a-8d16-b997fa2371f0@github.com>
 <-hhrsRy3MadVDVJoQs2chfkrBWrH-LebAyu6EGlH7MQ=.0e30fb30-fc8e-4dc5-84ce-d238824cdcb2@github.com>
 <VKfMWVxcB-WFGwKCWtmG5-TxM-f7zQ--B9njqgGy24Y=.327decaf-78c3-4aca-b96e-1cb51f5fa07c@github.com>
Message-ID: <VrYf-nxztOCa970PduxIdfprW1JGt-pxO--pGIQkir4=.08aa6238-05c9-45c2-854e-7e4191bb5cbd@github.com>

On Fri, 23 May 2025 19:47:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>>> Hi, Could you please incorporate this change for riscv? Thanks. [RealFYang at be8eac4](https://github.com/RealFYang/jdk/commit/be8eac493bef865d7825848f0b31a06d95b08efc) This passed `hotspot_serviceability` and `jdk_svc` tests on linux-riscv64 platform with both release and fastdebug builds.
>> 
>> Thanks a lot for the patch.
>> 
>> Unfortunately we changed direction a bit after you submitted it, because of implementation difficulties on other platforms.
>> 
>> Can you please take a look at the new and simpler version?
>> 
>> Thanks
>> Markus
>
>> > Hi, Could you please incorporate this change for riscv? Thanks. [RealFYang at be8eac4](https://github.com/RealFYang/jdk/commit/be8eac493bef865d7825848f0b31a06d95b08efc) This passed `hotspot_serviceability` and `jdk_svc` tests on linux-riscv64 platform with both release and fastdebug builds.
>> 
>> Thanks a lot for the patch.
>> 
>> Unfortunately we changed direction a bit after you submitted it, because of implementation difficulties on other platforms.
>> 
>> Can you please take a look at the new and simpler version?
>> 
>> Thanks Markus
> 
> ping @RealFYang

> @mgronlun : Thanks for the ping! New riscv version which reflects the latest changes: [RealFYang at cba533a](https://github.com/RealFYang/jdk/commit/cba533aac60476e4893fd57e2d459d69b95ecfbf) I performed tier1-3, hotspot_serviceability and jdk_svc tests on linux-riscv64 platform. Result looks good.

Thanks Fei for the patch. It has been integrated.

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

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

From mgronlun at openjdk.org  Mon May 26 11:00:21 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 11:00:21 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v40]
In-Reply-To: <7-ba2LTbmuKGwwMe7LNllRVg6XKj83PyHnULAwN1Tmc=.63e61a5d-fd37-4c9e-9fd2-c97cf7b50b95@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <7-ba2LTbmuKGwwMe7LNllRVg6XKj83PyHnULAwN1Tmc=.63e61a5d-fd37-4c9e-9fd2-c97cf7b50b95@github.com>
Message-ID: <9DRTEUBYRs0ClPHAGgEo_1wisMbOE6LzurMHGtWzhMo=.762b889a-3cf3-4549-8f7f-70bdbe0d5c9e@github.com>

On Sun, 25 May 2025 20:54:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   const void* ucontext

> 20826e5



> > > Heads-up: I'm currently testing the PPC64 implementation: [TheRealMDoerr at 9b9f0bf](https://github.com/TheRealMDoerr/jdk/commit/9b9f0bfc06d63110d99ef32553a0dff58cf69136) Note that I'm not using memory barriers. I'm relying on synchronization by the suspend/resume mechanism (as well as the signal handler in case of async profiler). Especially the StoreLoad barrier in the remove_activation code has probably interpreter performance impact.
> > 
> > 
> > That is great news Martin! Thanks for testing without the barriers. If you are ok without them on PPC, they are most likely not needed on any other platform.
> 
> Updated version (`InterpreterRuntime::at_unwind` before `notify_method_exit`): [TheRealMDoerr at 20826e5](https://github.com/TheRealMDoerr/jdk/commit/20826e59b088e42cda50008b4a91b5895e0630b3)
> 
> I have seen intermittent failures in TestResidentSetSizeEvent.java:
> 
> ```
> java.lang.RuntimeException: Should be non-zero: expected 0 > 0
> 	at jdk.test.lib.Asserts.fail(Asserts.java:715)
> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
> 	at jdk.jfr.event.runtime.TestResidentSetSizeEvent.verifyExpectedEventTypes(TestResidentSetSizeEvent.java:81)
> 	at jdk.jfr.event.runtime.TestResidentSetSizeEvent.main(TestResidentSetSizeEvent.java:92)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)
> ```
> 
> I don't see any relationship to my changes. Could be related to large pages on the machine.
> 
> I'll try more tests.

Are you happy with this version, Martin? https://github.com/TheRealMDoerr/jdk/commit/20826e59b088e42cda50008b4a91b5895e0630b3 ? Or do you want to do some more work?

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

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

From jbechberger at openjdk.org  Mon May 26 11:24:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 11:24:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v8]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <SiitD-ot9bi4Mrf8CsrKlAhd-8EnYZau0w9nJmC3WBU=.c14b6535-7d67-4403-a530-d091f664dc3c@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Move timer_t onto the heap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/e3addfe0..145fe20d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=06-07

  Stats: 40 lines in 3 files changed: 13 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 12:03:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 12:03:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v9]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Q5EObyE83819wq8UXD0B2PO3dNgE__-Axuq80n_7ZjU=.3332a829-4fa6-4ffa-ab3e-87739bfdec4a@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Improve throttle hot path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/145fe20d..d071acc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=07-08

  Stats: 16 lines in 1 file changed: 9 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 12:03:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 12:03:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <8S63YvUNvfsoC8kD3JjL-BZ78hTKz2MNz0A1T6Btt94=.51d84638-89f2-4192-b7dd-06a206c5613b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <11rBGpz6qVDpXa34hWmt7CyOnprzMHJPKIbz3z-QWgk=.b8a0e9a7-55c3-4287-9bf9-dca01ceecc3b@github.com>
 <8S63YvUNvfsoC8kD3JjL-BZ78hTKz2MNz0A1T6Btt94=.51d84638-89f2-4192-b7dd-06a206c5613b@github.com>
Message-ID: <pe7fzLwGPoXhMp0aJzRv0theyZyGJgJBzHvX9mkuFxs=.46149ce4-dcc1-40f7-bdca-c7be900516f3@github.com>

On Sun, 25 May 2025 15:33:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 118:
>> 
>>> 116: bool JfrEventThrottler::accept(JfrEventId event_id, int64_t timestamp /* 0 */) {
>>> 117:   JfrEventThrottler* const throttler = for_event(event_id);
>>> 118:   if (throttler == nullptr) {
>> 
>> Unfortunately, two checks have been introduced on the throttler hot path. Can we avoid this in some way?
>
> Can the settings system be updated so the throttle bit is not set in the native settings struct?

I just created a throttler which is always disabled. This uses a bit more memory, but doesn't need any special handling for CPUTimeSample events.

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

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

From jbechberger at openjdk.org  Mon May 26 12:29:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 12:29:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Don't mention throttling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d071acc9..cfbc25a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From mdoerr at openjdk.org  Mon May 26 12:44:00 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 26 May 2025 12:44:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v40]
In-Reply-To: <9DRTEUBYRs0ClPHAGgEo_1wisMbOE6LzurMHGtWzhMo=.762b889a-3cf3-4549-8f7f-70bdbe0d5c9e@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <7-ba2LTbmuKGwwMe7LNllRVg6XKj83PyHnULAwN1Tmc=.63e61a5d-fd37-4c9e-9fd2-c97cf7b50b95@github.com>
 <9DRTEUBYRs0ClPHAGgEo_1wisMbOE6LzurMHGtWzhMo=.762b889a-3cf3-4549-8f7f-70bdbe0d5c9e@github.com>
Message-ID: <3SpvnI5l8u2oquIZeZQfeeLViZWqUO02eBS7JpWRX5g=.16d84b55-3c8c-4e9e-87aa-13fd3cc3c132@github.com>

On Mon, 26 May 2025 10:57:11 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Are you happy with this version, Martin? https://github.com/TheRealMDoerr/jdk/commit/20826e59b088e42cda50008b4a91b5895e0630b3 ? Or do you want to do some more work?

I'll rebase and send you an updated version.

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

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

From mgronlun at openjdk.org  Mon May 26 14:06:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 14:06:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
Message-ID: <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>

On Mon, 26 May 2025 08:44:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Could you give me a hand with the conversion?
>
> My code is the inversion of
> 
> 
> template <typename TimeSource, const int unit>
> inline double conversion(typename TimeSource::Type& value) {
>   return (double)value * ((double)unit / (double)TimeSource::frequency());
> }

(value * (unit / frequency)) != (value / unit * frequency)

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

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

From egahlin at openjdk.org  Mon May 26 14:13:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 14:13:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
Message-ID: <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>

On Mon, 26 May 2025 12:29:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't mention throttling

Having four views for the CPU-Time events seems excessive, especially since it's an experimental event. Is it possible to reduce this to two views: the hot-methods table and a "form" view where all the aggregates are displayed?

Labels should use headline-style capitalization, capitalize the first and last words, and all nouns, pronouns, adjectives, verbs and adverbs. Do not include ending punctuation.
https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jfr/jdk/jfr/Label.html

Also, put (Experimental) at the end of the title.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2909886888

From jbechberger at openjdk.org  Mon May 26 14:13:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:13:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
Message-ID: <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>

On Mon, 26 May 2025 14:04:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> My code is the inversion of
>> 
>> 
>> template <typename TimeSource, const int unit>
>> inline double conversion(typename TimeSource::Type& value) {
>>   return (double)value * ((double)unit / (double)TimeSource::frequency());
>> }
>
> (value * (unit / frequency)) != (value / unit * frequency)

The mentioned conversion is from ticks to time unit:

nanos = ticks * 1_000_000_000 / frequency

therefore

nanos / 1_000_000_000 * frequency = ticks

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

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

From jbechberger at openjdk.org  Mon May 26 14:16:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:16:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
Message-ID: <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>

On Mon, 26 May 2025 14:11:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Also, put (Experimental) at the end of the title.

This is added automatically. If I add "(Experimental)" to the title, then I get "X (Experimental) (Experimental)"

> "form" view where all the aggregates are displayed?

I'm unsure how to implement this using the SQL version that is used for the views

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2909896289

From jbechberger at openjdk.org  Mon May 26 14:25:45 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:25:45 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v11]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <hJefdgnpEdzy9PX2g2v17uvOxsE8Sa8214EVnYthA_w=.63783f40-3033-461e-be30-0354fbcb4453@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix default.jfc and profile.jfc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/cfbc25a0..8cfedaee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=09-10

  Stats: 3 lines in 3 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From egahlin at openjdk.org  Mon May 26 14:25:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 14:25:46 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
Message-ID: <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>

On Mon, 26 May 2025 14:14:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is added automatically. If I add "(Experimental)" to the title, then I get "X (Experimental) (Experimental)"

Sweet.

> I'm unsure how to implement this using the SQL version that is used for the views

I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2909912821

From mgronlun at openjdk.org  Mon May 26 14:46:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 14:46:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
Message-ID: <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>

On Mon, 26 May 2025 14:09:35 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> (value * (unit / frequency)) != (value / unit * frequency)
>
> The mentioned conversion is from ticks to time unit:
> 
> nanos = ticks * 1_000_000_000 / frequency
> 
> therefore
> 
> nanos / 1_000_000_000 * frequency = ticks

Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.

Does it look right in the jfr parser alt JMC?

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

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

From mdoerr at openjdk.org  Mon May 26 14:51:58 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 26 May 2025 14:51:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v41]
In-Reply-To: <RKVYJXKL3TPtWhHZ3cJMOGjZ2zBFdrrD0shVi6j_Pjc=.6697c087-585c-48d4-9415-6e2d6857bd25@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <RKVYJXKL3TPtWhHZ3cJMOGjZ2zBFdrrD0shVi6j_Pjc=.6697c087-585c-48d4-9415-6e2d6857bd25@github.com>
Message-ID: <Wwk9CVkUm8MK6q0Op3qebcQBtnQBdheeoABdXsscgXI=.2c8a1f93-f743-4ec6-8a30-bc88181b1995@github.com>

On Mon, 26 May 2025 11:00:21 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8352251-riscv-port

Rebased version is here: https://github.com/TheRealMDoerr/jdk/commit/e98c21e6d5d8c6bb468418a845547cdc27b8c703
I think I have all parts which have been implemented for other platforms. I can continue testing the whole PR after it is integrated.

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

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

From jbechberger at openjdk.org  Mon May 26 14:57:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 14:57:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v12]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <ehSHEuuUy_evOHMDtT_xHUpIBUWkL3EYmA_tTmkzusQ=.6a6929d6-3bbc-4bcd-bb4b-ce51a6cbffbc@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix MacOS build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8cfedaee..d89ae716

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=10-11

  Stats: 9 lines in 2 files changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From mgronlun at openjdk.org  Mon May 26 14:59:46 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 14:59:46 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v42]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  PPC64 implementation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/44330f9f..0eb039a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=40-41

  Stats: 231 lines in 14 files changed: 151 ins; 45 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Mon May 26 15:04:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 15:04:57 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v42]
In-Reply-To: <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>
Message-ID: <wsEbrFxplWUA4LZdWZx_Qdsffn42zwdAvq9OOkSw8Nc=.99cf2e1b-9ea9-46a9-88c8-aa8408fd6900@github.com>

On Mon, 26 May 2025 14:59:46 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PPC64 implementation.

> Rebased version is here: [TheRealMDoerr at e98c21e](https://github.com/TheRealMDoerr/jdk/commit/e98c21e6d5d8c6bb468418a845547cdc27b8c703) I think I have all parts which have been implemented for other platforms. I can continue testing the whole PR after it is integrated.

Great. Integrated.

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

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

From jbechberger at openjdk.org  Mon May 26 15:07:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:07:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
Message-ID: <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>

On Mon, 26 May 2025 14:44:04 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The mentioned conversion is from ticks to time unit:
>> 
>> nanos = ticks * 1_000_000_000 / frequency
>> 
>> therefore
>> 
>> nanos / 1_000_000_000 * frequency = ticks
>
> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.
> 
> Does it look right in the jfr parser alt JMC?

It looks good in the jfr tool:


16:56:22      0.112 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  2.00 ms  false
16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22     0.0221 ms scala.concurrent.impl.Pro... UCT-akka.actor.default-di...  false                  2.00 ms  false
16:56:22     0.0184 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.114 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.109 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.113 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.109 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22     0.0197 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.108 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.108 ms java.util.concurrent.Fork... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
16:56:22      0.107 ms scala.collection.immutabl... UCT-akka.actor.internal-d...  false                  1.00 ms  false


But I can't find the event at all in JMC

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

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

From mgronlun at openjdk.org  Mon May 26 15:12:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 15:12:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
Message-ID: <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>

On Mon, 26 May 2025 15:05:32 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.
>> 
>> Does it look right in the jfr parser alt JMC?
>
> It looks good in the jfr tool:
> 
> 
> 16:56:22      0.112 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  2.00 ms  false
> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22     0.0221 ms scala.concurrent.impl.Pro... UCT-akka.actor.default-di...  false                  2.00 ms  false
> 16:56:22     0.0184 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.114 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.109 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.113 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.109 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22     0.0197 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.108 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.108 ms java.util.concurrent.Fork... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
> 16:56:22      0.107 ms scala.collection.immutabl... UCT-akka.actor.internal-d...  false                  1.00 ms  false
> 
> 
> But I can't find the event at all in JMC

You need to expand the Event Browser section and locate your event, Johannes.

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

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

From jbechberger at openjdk.org  Mon May 26 15:15:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:15:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
 <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
Message-ID: <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIolnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>

On Mon, 26 May 2025 15:09:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> It looks good in the jfr tool:
>> 
>> 
>> 16:56:22      0.112 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  2.00 ms  false
>> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22     0.0221 ms scala.concurrent.impl.Pro... UCT-akka.actor.default-di...  false                  2.00 ms  false
>> 16:56:22     0.0184 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.114 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.109 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.113 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.109 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22     0.0197 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.108 ms akka.actor.dungeon.Childr... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.109 ms akka.actor.ChildActorPath... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.108 ms java.util.concurrent.Fork... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.111 ms scala.collection.immutabl... UCT-akka.actor.default-di...  false                  1.00 ms  false
>> 16:56:22      0.107 ms scala.collection.immutabl... UCT-akka.actor.internal-d...  false                  1.00 ms  false
>> 
>> 
>> But I can't find the event at all in JMC
>
> You need to expand the Event Browser section and locate your event, Johannes.

![Screenshot From 2025-05-26 17-12-24](https://github.com/user-attachments/assets/9898d788-df61-4391-920a-fbecfa6b360c)

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

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

From mgronlun at openjdk.org  Mon May 26 15:31:45 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 15:31:45 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v43]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <KjP2LZJPgK0UYqSLaTQx4D-TJP5b8d4K6NPERNZXNp4=.38b4cc0e-d5fb-46d6-91cd-9c411a866189@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge branch 'master' into 8352251
 - PPC64 implementation.
 - 8352251-riscv-port
 - const void* ucontext
 - include order
 - Refactor interpreter ucontext assertion
 - leave_jfr_critical_section in the correct location
 - leave jfr critical section before throw_delayed_StackOverflowException
 - remove barriers
 - fetch bcp from context
 - ... and 37 more: https://git.openjdk.org/jdk/compare/a300c356...dd7d1597

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=42
  Stats: 3797 lines in 112 files changed: 2409 ins; 1017 del; 371 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From jbechberger at openjdk.org  Mon May 26 15:35:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:35:44 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v13]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <coxWff1b1pcDwUsPoDDML8tZhd-BQQBpDSiu42lr064=.48d2588f-32ca-4660-9987-45db30782e67@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Improve one warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d89ae716..ae0747d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 15:35:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:35:44 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIolnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
 <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
 <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIo
 lnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>
Message-ID: <P8kH7ZBeJHGFTWWpslbONejf85daez5nR9_eyIlOTvc=.e61c5dc8-26c8-4a2b-adfc-26e4881b6bb0@github.com>

On Mon, 26 May 2025 15:12:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> You need to expand the Event Browser section and locate your event, Johannes.
>
> ![Screenshot From 2025-05-26 17-12-24](https://github.com/user-attachments/assets/9898d788-df61-4391-920a-fbecfa6b360c)

> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.

I don't. I represent it as a Tickspan, as I substract two TimeInstants:


  TimeInterval<Rep, TimeSource> operator-(const TimeInstant<Rep, TimeSource>& start) const {
    return TimeInterval<Rep, TimeSource>(*this, start);
  }

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

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

From jbechberger at openjdk.org  Mon May 26 15:42:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:42:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <P8kH7ZBeJHGFTWWpslbONejf85daez5nR9_eyIlOTvc=.e61c5dc8-26c8-4a2b-adfc-26e4881b6bb0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <-jt0xLxet--HfywermXtEScCiQQMg6Jae2R027T-Si8=.f0bf6ea8-654e-4ec0-8b83-7d90fa44249c@github.com>
 <OvSHJsue44RDXYOx3xB9OQLWfUqwzRaqpbcTfrvAiOg=.d047d20c-6832-406e-ae6e-2df8f11866a6@github.com>
 <NRc-m2QHG13s8bc08DHRXkdj8gEH3OSs34GA5uyKg6g=.a9ddd1cc-fead-4003-959e-6600502b6af8@github.com>
 <ia9xuY4vfxJiKPNxvsLjyo1bH_NOwhaSGAKo3NRJLrQ=.3c211d11-c87d-4062-b49c-53694a76e98d@github.com>
 <fmXDFHyZUXI37Gb81iJgMwGRqcZQRANiDZD1Ep1CZjk=.eafedd5e-019b-4ebb-9785-abac258542cc@github.com>
 <RqXxMrriJdHBHbxnX0SHU7lRkC2-McIExbwZMrWsrpk=.338d8310-8d5b-486a-a1e6-16db9870b4fc@github.com>
 <IvOxxTJOC3-6XWlMl4zfH29AFtc3wL0JDzuKZu4Fxwc=.48b42520-4cfc-4327-9374-0c0d8cf24359@github.com>
 <Dfkwq7EUo42_OOOLUihiA4CngebVVRrj6hu_dRFvnrM=.c96f76ef-7391-43d3-abd3-1f59c3249e21@github.com>
 <KnlfHUANnhmWMuNgmco0gG57hGfmF0HUsIo
 lnkYUagA=.6f122507-0d5d-423f-8974-14fdacc9095f@github.com>
 <P8kH7ZBeJHGFTWWpslbONejf85daez5nR9_eyIlOTvc=.e61c5dc8-26c8-4a2b-adfc-26e4881b6bb0@github.com>
Message-ID: <jMGsShGuugUFc9CksRSD2FAz_0ue-g2-asHqO0ByixA=.3cdf480c-1281-4d59-a532-b4948c323a2c@github.com>

On Mon, 26 May 2025 15:31:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> ![Screenshot From 2025-05-26 17-12-24](https://github.com/user-attachments/assets/9898d788-df61-4391-920a-fbecfa6b360c)
>
>> Sorry, you represent the sampling period value as ticks, not nanos. Its a Tickspan after all.
> 
> I don't. I represent it as a Tickspan, as I substract two TimeInstants:
> 
> 
>   TimeInterval<Rep, TimeSource> operator-(const TimeInstant<Rep, TimeSource>& start) const {
>     return TimeInterval<Rep, TimeSource>(*this, start);
>   }

Regarding JMC: I had to enable the experimental events in the preferences. Now it shows:

![image](https://github.com/user-attachments/assets/d31efde1-6075-4be6-b61f-91e5786637de)

So all is fine.

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

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

From egahlin at openjdk.org  Mon May 26 15:45:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 15:45:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
Message-ID: <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>

On Mon, 26 May 2025 14:20:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.

I have a Mac, so I could not try it with an actual recording, but something like this:

[application.cpu-time-statistics]
label = "CPU Time Samples Statistics"
form = "COLUMN 'Successful Samples', 'Failed Samples', 'Total Samples', 'Lost Samples'
        SELECT COUNT(T.failed), COUNT(F.failed), Count(A.failed), SUM(L.lostSamples)
        FROM 
          CPUTimeSample AS T,
          CPUTimeSample AS F,
          CPUTimeSample AS A,
          CPUTimeSampleLoss AS L
        WHERE
          T.failed = 'true' AND
          F.failed = 'false'"


 I removed biased, because I wonder If we should have such a field? There can be many types of biases, and the implementation may change in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2910137003

From jbechberger at openjdk.org  Mon May 26 15:48:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 15:48:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
Message-ID: <H4taesXEidY4TfbhEwOzeokgu9vA3yJ3Qwkj5u0yQPU=.5407cdc1-ec19-4d66-8b7a-7d8a6ea657ed@github.com>

On Mon, 26 May 2025 15:42:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I removed biased, because I wonder If we should have such a field? There can be many types of biases, and the implementation may change in the future.

This signifies that the sample has a known bias. It is important for the user to distinguish between biased and unbiased samples.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2910142902

From eosterlund at openjdk.org  Mon May 26 15:49:58 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 26 May 2025 15:49:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v42]
In-Reply-To: <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>
Message-ID: <YIV6ZBwzoWxLNC1lQm1HvQs34711b2-xExOBBN3S5bo=.11e8d810-511e-428f-97d1-202a2f2cdb29@github.com>

On Mon, 26 May 2025 14:59:46 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PPC64 implementation.

I see you fixed the JVMTI issue. This looks good to me now.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2868802316

From mgronlun at openjdk.org  Mon May 26 15:49:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 15:49:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v42]
In-Reply-To: <YIV6ZBwzoWxLNC1lQm1HvQs34711b2-xExOBBN3S5bo=.11e8d810-511e-428f-97d1-202a2f2cdb29@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>
 <YIV6ZBwzoWxLNC1lQm1HvQs34711b2-xExOBBN3S5bo=.11e8d810-511e-428f-97d1-202a2f2cdb29@github.com>
Message-ID: <4rDagTr31nV5cS4kLjFXnYaJbkwTx3HgpfKHEss5o5I=.ffeec056-1d5d-4622-a2cd-f7cebc5ecc23@github.com>

On Mon, 26 May 2025 15:47:11 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> I see you fixed the JVMTI issue. This looks good to me now.

Thank you very much, Erik!

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

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

From egahlin at openjdk.org  Mon May 26 15:54:02 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 15:54:02 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v43]
In-Reply-To: <KjP2LZJPgK0UYqSLaTQx4D-TJP5b8d4K6NPERNZXNp4=.38b4cc0e-d5fb-46d6-91cd-9c411a866189@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <KjP2LZJPgK0UYqSLaTQx4D-TJP5b8d4K6NPERNZXNp4=.38b4cc0e-d5fb-46d6-91cd-9c411a866189@github.com>
Message-ID: <uqiKRmEOAQjJqarP7cGwKybMSykU6jQ-kpb5DPoKgUg=.b9798899-2e14-4692-b891-3a5134e5dd9b@github.com>

On Mon, 26 May 2025 15:31:45 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:
> 
>  - Merge branch 'master' into 8352251
>  - PPC64 implementation.
>  - 8352251-riscv-port
>  - const void* ucontext
>  - include order
>  - Refactor interpreter ucontext assertion
>  - leave_jfr_critical_section in the correct location
>  - leave jfr critical section before throw_delayed_StackOverflowException
>  - remove barriers
>  - fetch bcp from context
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/a300c356...dd7d1597

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2868809523

From amitkumar at openjdk.org  Mon May 26 15:54:03 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 26 May 2025 15:54:03 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v42]
In-Reply-To: <4rDagTr31nV5cS4kLjFXnYaJbkwTx3HgpfKHEss5o5I=.ffeec056-1d5d-4622-a2cd-f7cebc5ecc23@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>
 <YIV6ZBwzoWxLNC1lQm1HvQs34711b2-xExOBBN3S5bo=.11e8d810-511e-428f-97d1-202a2f2cdb29@github.com>
 <4rDagTr31nV5cS4kLjFXnYaJbkwTx3HgpfKHEss5o5I=.ffeec056-1d5d-4622-a2cd-f7cebc5ecc23@github.com>
Message-ID: <9rCm3yi_dSbTi4SWZmCAzQ_KLu5gO1oiyCwIE7zpu-E=.96ba9213-f973-4127-b2cc-e46ef0a450fc@github.com>

On Mon, 26 May 2025 15:47:36 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I see you fixed the JVMTI issue. This looks good to me now.
>
>> I see you fixed the JVMTI issue. This looks good to me now.
> 
> Thank you very much, Erik!

Hi @mgronlun , 

Please include the minimal build fix for s390x from here: https://github.com/offamitkumar/jdk/commit/916efec64073eb1c81efa3f02b173f01f8700e16 . I need to port some other enhancement before I can complete this one. So I am planning it for later.

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

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

From mgronlun at openjdk.org  Mon May 26 16:30:23 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 16:30:23 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v44]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  s390 port: build fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/dd7d1597..a16bef98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=42-43

  Stats: 44 lines in 2 files changed: 44 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

PR: https://git.openjdk.org/jdk/pull/24296

From eosterlund at openjdk.org  Mon May 26 16:30:23 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 26 May 2025 16:30:23 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v44]
In-Reply-To: <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>
Message-ID: <UoImDkchGQkFc8nfP4Hc3wzogLR-uAJB_oAuJHbIy_U=.8b5aa350-42dd-4de3-a2dc-bcece7794b3b@github.com>

On Mon, 26 May 2025 16:27:28 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390 port: build fix

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2868859840

From mgronlun at openjdk.org  Mon May 26 16:30:23 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 16:30:23 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v42]
In-Reply-To: <4rDagTr31nV5cS4kLjFXnYaJbkwTx3HgpfKHEss5o5I=.ffeec056-1d5d-4622-a2cd-f7cebc5ecc23@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <CEGOuhzymoQo_8fUO9ETiACFb4MV-khMwXsBsLDTDMY=.dbd7335d-f513-40c4-866f-d87cdbf79385@github.com>
 <YIV6ZBwzoWxLNC1lQm1HvQs34711b2-xExOBBN3S5bo=.11e8d810-511e-428f-97d1-202a2f2cdb29@github.com>
 <4rDagTr31nV5cS4kLjFXnYaJbkwTx3HgpfKHEss5o5I=.ffeec056-1d5d-4622-a2cd-f7cebc5ecc23@github.com>
Message-ID: <WVQlZg4yRSt2vst1o5o1atGfWz_WsWmoekhxY8ZEVD4=.44d86c0e-e2df-43ca-94f7-6e9eefeab2ba@github.com>

On Mon, 26 May 2025 15:47:36 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I see you fixed the JVMTI issue. This looks good to me now.
>
>> I see you fixed the JVMTI issue. This looks good to me now.
> 
> Thank you very much, Erik!

> Hi @mgronlun ,
> 
> Please include the minimal build fix for s390x from here: [offamitkumar at 916efec](https://github.com/offamitkumar/jdk/commit/916efec64073eb1c81efa3f02b173f01f8700e16) . I need to port some other enhancement before I can complete this one. So I am planning it for later.

Thanks Amit. Integrated.

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

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

From egahlin at openjdk.org  Mon May 26 16:51:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 16:51:00 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v44]
In-Reply-To: <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>
Message-ID: <DYQ2PoADLnDra83g6_WKpZKgG-wAzSjkBrFm858oNTY=.3ed8b015-c140-40c3-966e-3a85052856ad@github.com>

On Mon, 26 May 2025 16:30:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390 port: build fix

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2868885467

From mgronlun at openjdk.org  Mon May 26 16:58:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 16:58:58 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v44]
In-Reply-To: <UoImDkchGQkFc8nfP4Hc3wzogLR-uAJB_oAuJHbIy_U=.8b5aa350-42dd-4de3-a2dc-bcece7794b3b@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>
 <UoImDkchGQkFc8nfP4Hc3wzogLR-uAJB_oAuJHbIy_U=.8b5aa350-42dd-4de3-a2dc-bcece7794b3b@github.com>
Message-ID: <7wDBWRRJbpCZgM21Qs97rOLRb2F24BRTpImk7qqGfW4=.9071b055-e0ba-47cf-b293-f837e2ad03d4@github.com>

On Mon, 26 May 2025 16:26:36 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   s390 port: build fix
>
> Marked as reviewed by eosterlund (Reviewer).

Thank you, @fisk and @egahlin, for your reviews!

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

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

From jbechberger at openjdk.org  Mon May 26 18:36:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 18:36:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v14]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <zLfDb2lWdLmGbdR2Xuyf0JVf16NFKpMsOahsI0qF24E=.2caecb86-0386-4d1b-b92b-75dfd1a489d8@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix other platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ae0747d4..f64b1dcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=12-13

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From mgronlun at openjdk.org  Mon May 26 18:41:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 18:41:06 GMT
Subject: Integrated: 8352251: Implement JEP 518: JFR Cooperative Sampling
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <cjuma3zSq9WWv0UbEfH3mSbGnydq2bq3f7ZCKJbwgio=.c47c856e-eb9e-46dc-a05a-9bb6056aef8f@github.com>

On Fri, 28 Mar 2025 15:38:59 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: bbceab07
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbceab072555d5e2f5d3e99ae07a5ca5e909d7dc
Stats:     3841 lines in 114 files changed: 2453 ins; 1017 del; 371 mod

8352251: Implement JEP 518: JFR Cooperative Sampling

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Boris Ulasevich <bulasevich at openjdk.org>
Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: eosterlund, egahlin

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

PR: https://git.openjdk.org/jdk/pull/24296

From mgronlun at openjdk.org  Mon May 26 18:46:09 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 26 May 2025 18:46:09 GMT
Subject: RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v44]
In-Reply-To: <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <f-8oDn5V1OEeJUKBfryFh2ZJJ2fakLO6pkvVtVDJRlA=.ea4dfe62-dcb2-4410-a5aa-b2cc99a90f23@github.com>
Message-ID: <eaHRH4vqa1eSC7OE5NfZcWiXI4g0SgGSvC-kaciCy7g=.0daa170c-7763-47df-8fbb-90f02d92ab78@github.com>

On Mon, 26 May 2025 16:30:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390 port: build fix

Thank you all for contributing, reviewing, providing recommendations, and supporting getting this feature ready for JDK 25.

Many thanks
Markus

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

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

From jbechberger at openjdk.org  Mon May 26 19:32:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 19:32:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v15]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <5ph_cQumwYk_z6UyCLNm4WeqAieMPisNb14hsbYoWQQ=.9ae3bb91-4d12-4d85-ab9c-f71ba84b8705@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into parttimenerd_cooperative_cpu_time_sampler
 - Fix other platforms
 - Improve one warning
 - Fix MacOS build
 - Fix default.jfc and profile.jfc
 - Don't mention throttling
 - Improve throttle hot path
 - Move timer_t onto the heap
 - Improve queue walking in native
 - Rename and remove end_time
 - ... and 73 more: https://git.openjdk.org/jdk/compare/bbceab07...57da22e0

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=14
  Stats: 2353 lines in 45 files changed: 2207 ins; 129 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Mon May 26 19:38:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 19:38:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v16]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/57da22e0..d49b0084

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=14-15

  Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From duke at openjdk.org  Mon May 26 20:01:02 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 26 May 2025 20:01:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v16]
In-Reply-To: <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>
Message-ID: <MCBovFN0yoB2i4SPcKxOFZVCnn8wHr1IYqBEBWC7Lek=.a5ab8a91-1e49-4ef3-ad98-3976e5056948@github.com>

On Mon, 26 May 2025 19:38:16 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove mistake

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 89:

> 87:   }
> 88:   if (event_id == JfrCPUTimeSampleEvent) {
> 89:     return _disabled_cpu_time_sample_throttler;

Why do you need to make a "disabled" throttler? Shouldn't the rate limiting always be done by the arguments given to `timer_create`? The actual JFR throttling mechanism used by `ObjectAllocationSample` doesn't really fit this use-case anyway since you can already pre-determine the rate at which events are emitted (while with `ObjectAllocationSample` you can't).

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

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

From jbechberger at openjdk.org  Mon May 26 20:07:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 20:07:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v16]
In-Reply-To: <MCBovFN0yoB2i4SPcKxOFZVCnn8wHr1IYqBEBWC7Lek=.a5ab8a91-1e49-4ef3-ad98-3976e5056948@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <CGumlbay8qOyRuLI0jxeues7032i1mUDkD7hFfl8NSY=.6eef75a2-4ddb-4021-b33e-33e6abe72e4b@github.com>
 <MCBovFN0yoB2i4SPcKxOFZVCnn8wHr1IYqBEBWC7Lek=.a5ab8a91-1e49-4ef3-ad98-3976e5056948@github.com>
Message-ID: <bV7g_mEAOh_hC2XVWiACfk0DbNtEU4pD2Py5Q_-Rli4=.09a041e8-e268-45d9-85cf-9f261a13b457@github.com>

On Mon, 26 May 2025 19:58:26 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove mistake
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 89:
> 
>> 87:   }
>> 88:   if (event_id == JfrCPUTimeSampleEvent) {
>> 89:     return _disabled_cpu_time_sample_throttler;
> 
> Why do you need to make a "disabled" throttler? Shouldn't the rate limiting always be done by the arguments given to `timer_create`? The actual JFR throttling mechanism used by `ObjectAllocationSample` doesn't really fit this use-case anyway since you can already pre-determine the rate at which events are emitted (while with `ObjectAllocationSample` you can't).

This just makes the code simpler and avoids two additional checks on the throttler hot-path. The _disabled_cpu_time_sample_throttler is like `nullptr` but without the `nullptr` check.

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

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

From jbechberger at openjdk.org  Mon May 26 20:57:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 26 May 2025 20:57:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove assertion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d49b0084..d91f5672

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From egahlin at openjdk.org  Mon May 26 23:44:07 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 26 May 2025 23:44:07 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v4]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <9o0ojKIbEPKwQUkZnk_qqWN72m2Xy3AsISogayRxCWE=.70a73b1c-979e-49b0-8366-00d19beb0bfb@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge
 - Atomic::load_acquire(&_method_tracer_state);
 - Reviewer feedback
 - Initial

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

Changes: https://git.openjdk.org/jdk/pull/25306/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=03
  Stats: 7082 lines in 108 files changed: 6624 ins; 363 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From mgronlun at openjdk.org  Tue May 27 11:13:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 11:13:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 174:

> 172:   assert(request._sample_pc != nullptr, "invariant");
> 173:   assert(jt != nullptr, "invariant");
> 174:   assert(jt->thread_state() == _thread_in_Java, "invariant");

What?

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

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

From mgronlun at openjdk.org  Tue May 27 11:39:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 11:39:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <b5nUwZhN6Dk2oqzi_tcSc3Flvs1CeSGLZ761vEQT_sw=.2322d705-ef84-4738-8036-4ab43e14b877@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 195:

> 193: 
> 194:     public boolean hasThreshold() {
> 195:         if (hasCutoff || isCPUTimeMethodSampling) {

This is not a duration event anymore, right?

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

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

From jbechberger at openjdk.org  Tue May 27 12:01:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 27 May 2025 12:01:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>
Message-ID: <VLpx6yp9rr4wOVVsvTbMO1ox9kwD2SWHgJbMSoKPv3I=.80dae640-ec33-43b4-8af7-c58e8535cb19@github.com>

On Tue, 27 May 2025 11:11:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion
>
> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 174:
> 
>> 172:   assert(request._sample_pc != nullptr, "invariant");
>> 173:   assert(jt != nullptr, "invariant");
>> 174:   assert(jt->thread_state() == _thread_in_Java, "invariant");
> 
> What?

I also call this method for native stack traces in my implementation. As I have to walk native stack traces at stackwalks.

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

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

From mgronlun at openjdk.org  Tue May 27 12:31:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 12:31:04 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
Message-ID: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>

Greetings,

SonarCloud identified this issue today following the integration of [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).

It's a remnant from increased sampling pressure during development.

A change will be coming in this area, just not yet.

Restoring sampling limits.

Testing: jdk_jfr

Thanks SonarCloud!

Markus

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

Commit messages:
 - restore thread sample limits

Changes: https://git.openjdk.org/jdk/pull/25464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25464&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357829
  Stats: 6 lines in 1 file changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25464/head:pull/25464

PR: https://git.openjdk.org/jdk/pull/25464

From egahlin at openjdk.org  Tue May 27 12:36:43 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 27 May 2025 12:36:43 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v5]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <IKBsMlWDRMNsf5WGL4dGNUAEz4uxhc6EfBHk2FaQ-4E=.5948fa9c-b9a4-4354-b3d2-0b1bce05a192@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Remove METHOD_FLAG_USED_PREVIOUS_EPOCH_BIT(method)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/585a929a..5f5a42aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=03-04

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From mgronlun at openjdk.org  Tue May 27 13:54:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 13:54:02 GMT
Subject: RFR: 8357830: JfrVframeStream::_cont_entry shadows super-class field
Message-ID: <eM31Z_0ZH4D1DQpAall8eIqJ7UUJtHWZliDUnttsHU4=.138b6c6e-0eb1-4d5e-a600-17233f20a023@github.com>

Greetings,

SonarCloud has a report that `JfrVframeStream::_cont_entry` shadows the super-class field of the same name.

Fixed and inlined the constructor.

Testing: jdk_jfr

Thanks
Markus

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

Commit messages:
 - avoid shadowing super-class field _cont_entry and inline

Changes: https://git.openjdk.org/jdk/pull/25465/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25465&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357830
  Stats: 92 lines in 3 files changed: 35 ins; 56 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25465/head:pull/25465

PR: https://git.openjdk.org/jdk/pull/25465

From mgronlun at openjdk.org  Tue May 27 14:16:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 14:16:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <a7YIW_NTpUuJR96eQ7a6AOa9Wk8zs-4MsbtbzrhnLfE=.30a02b7e-8bfd-4ea9-a256-80f5a9e7ad3d@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java line 54:

> 52: interface B3 {}
> 53: 
> 54: >>>>>>>> bbceab072555d5e2f5d3e99ae07a5ca5e909d7dc:test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java

merge error?

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

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

From mgronlun at openjdk.org  Tue May 27 14:21:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 14:21:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 36:

> 34: #include "runtime/mutexLocker.hpp"
> 35: 
> 36: #ifdef LINUX

Can things now be fwd declared in the .hpp and includes move to the .cpp instead?

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

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

From jbechberger at openjdk.org  Tue May 27 14:46:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 27 May 2025 14:46:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
Message-ID: <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>

On Tue, 27 May 2025 14:17:46 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion
>
> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 36:
> 
>> 34: #include "runtime/mutexLocker.hpp"
>> 35: 
>> 36: #ifdef LINUX
> 
> Can things now be fwd declared in the .hpp and includes move to the .cpp instead?

No, because I need the `timer_t` in the arguments of the methods. Or should I use a wrapper class and a pointer to it?

> test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java line 54:
> 
>> 52: interface B3 {}
>> 53: 
>> 54: >>>>>>>> bbceab072555d5e2f5d3e99ae07a5ca5e909d7dc:test/langtools/tools/javac/diags/examples/SubtypeDoesntImplementSealed.java
> 
> merge error?

good catch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109398525
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2109395879

From shade at openjdk.org  Tue May 27 14:49:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 14:49:51 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
Message-ID: <w2Se8iXFy44T3qi5fL5LXlZAH9np90AG5R8x0KF6IJI=.ea3844d6-103d-42ca-93dc-68c753ff3ed2@github.com>

On Tue, 27 May 2025 12:26:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> SonarCloud identified this issue today following the integration of [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> It's a remnant from increased sampling pressure during development.
> 
> A change will be coming in this area, just not yet.
> 
> Restoring sampling limits.
> 
> Testing: jdk_jfr
> 
> Thanks SonarCloud!
> 
> Markus

OK, so limitless stack trace is something that we did not want to do? Nice. I need to spend more time with static analysis reports :P

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25464#pullrequestreview-2871410456

From mgronlun at openjdk.org  Tue May 27 15:27:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 15:27:55 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v5]
In-Reply-To: <IKBsMlWDRMNsf5WGL4dGNUAEz4uxhc6EfBHk2FaQ-4E=.5948fa9c-b9a4-4354-b3d2-0b1bce05a192@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <IKBsMlWDRMNsf5WGL4dGNUAEz4uxhc6EfBHk2FaQ-4E=.5948fa9c-b9a4-4354-b3d2-0b1bce05a192@github.com>
Message-ID: <MCIfrIGtMVF1LnhjCqoWA39Vq_HBxWkwBZkq2je8HJ8=.41bb2b88-5a71-4c99-8a39-6156e2ff7012@github.com>

On Tue, 27 May 2025 12:36:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove METHOD_FLAG_USED_PREVIOUS_EPOCH_BIT(method)

src/hotspot/share/jfr/support/methodtracer/jfrMethodTracer.cpp line 218:

> 216: // jvmtiRedefineClassses::redefine_single_class() has finished so we are still at a safepoint.
> 217: // If the original klass is not already in the list, add it and also dynamically tag all
> 218: // artifacts that have the sticky bit set. If the klass represents has an associated TimedClass,

"If the klass represents" -> "if the klass has an associated..."

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

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

From mgronlun at openjdk.org  Tue May 27 16:03:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:03:53 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <w2Se8iXFy44T3qi5fL5LXlZAH9np90AG5R8x0KF6IJI=.ea3844d6-103d-42ca-93dc-68c753ff3ed2@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
 <w2Se8iXFy44T3qi5fL5LXlZAH9np90AG5R8x0KF6IJI=.ea3844d6-103d-42ca-93dc-68c753ff3ed2@github.com>
Message-ID: <BJCOmI0pFYBFx2Eytib7PhvCQ-39xxws-SsEpHi_3fY=.3f955205-1a88-487a-a0a7-581260344ebd@github.com>

On Tue, 27 May 2025 14:47:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OK, so limitless stack trace is something that we did not want to do? Nice. I need to spend more time with static analysis reports :P

Its because of the Threads_lock. Thanks for finding and reporting this!

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

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913133914

From shade at openjdk.org  Tue May 27 16:23:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 May 2025 16:23:51 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <BJCOmI0pFYBFx2Eytib7PhvCQ-39xxws-SsEpHi_3fY=.3f955205-1a88-487a-a0a7-581260344ebd@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
 <w2Se8iXFy44T3qi5fL5LXlZAH9np90AG5R8x0KF6IJI=.ea3844d6-103d-42ca-93dc-68c753ff3ed2@github.com>
 <BJCOmI0pFYBFx2Eytib7PhvCQ-39xxws-SsEpHi_3fY=.3f955205-1a88-487a-a0a7-581260344ebd@github.com>
Message-ID: <npONy-41VlWnrGGo7ky8_yijmDv3d2GiBL94gFjdOr8=.0fcd55d2-1780-44cf-af26-3aaed9ce8621@github.com>

On Tue, 27 May 2025 16:01:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Its because of the Threads_lock. 

OK, I understand it is pre-[JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), but I gotta ask. Are we talking about this one?

https://github.com/openjdk/jdk/blob/c29537740efb04e061732a700582d43b1956cff4/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L231-L232

Do you actually need that lock? I would have thought `ThreadListHandle` blocks anything bad to happen with the threads in the list until you release that iterator. This is the whole thing about Thread SMR to allow this kind of safe thread handling without taking extra locks. Maybe I don't see some other code lurking somewhere that wants it, e.g. thread states?

Since TLH is supposed to guard the thread list stability by itself, maybe we can move that lock acquisition within the thread-walking loop, so that we don't hoard the lock for sampling _all_ threads, just do it one by one...

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

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913202119

From mgronlun at openjdk.org  Tue May 27 16:23:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:23:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
Message-ID: <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>

On Tue, 27 May 2025 14:44:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 36:
>> 
>>> 34: #include "runtime/mutexLocker.hpp"
>>> 35: 
>>> 36: #ifdef LINUX
>> 
>> Can things now be fwd declared in the .hpp and includes move to the .cpp instead?
>
> No, because I need the `timer_t` in the arguments of the methods. Or should I use a wrapper class and a pointer to it?

It can be a timer_t*

Then it's fwd declarable.

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

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

From mgronlun at openjdk.org  Tue May 27 16:31:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:31:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
Message-ID: <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>

On Tue, 27 May 2025 16:20:58 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> No, because I need the `timer_t` in the arguments of the methods. Or should I use a wrapper class and a pointer to it?
>
> It can be a timer_t*
> 
> Then it's fwd declarable.

If it's typedeffed as an int or a pointer (in sys/types.h or signal.h), then it won't even need a forward declaration. Try without it and see what happens.

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

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

From jbechberger at openjdk.org  Tue May 27 16:31:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 27 May 2025 16:31:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
 <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
Message-ID: <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>

On Tue, 27 May 2025 16:27:02 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> It can be a timer_t*
>> 
>> Then it's fwd declarable.
>
> If it's typedeffed as an int or a pointer (in sys/types.h or signal.h), then it won't even need a forward declaration. Try without it and see what happens.

It seems to normally be a pointer. I'll try the forward declaration later.

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

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

From mgronlun at openjdk.org  Tue May 27 16:36:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:36:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
 <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
 <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>
Message-ID: <0lQMp4kZ_KxQuIziy-O5n3IOGXDSld1ciyLF2ksJP88=.e56674fd-b89b-4d7b-877c-da3c3c6639f9@github.com>

On Tue, 27 May 2025 16:29:05 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> If it's typedeffed as an int or a pointer (in sys/types.h or signal.h), then it won't even need a forward declaration. Try without it and see what happens.
>
> It seems to normally be a pointer. I'll try the forward declaration later.

Don't worry if it's too hard. It would just be a nice thing to eliminate these special includes from the header file.

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

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

From mgronlun at openjdk.org  Tue May 27 16:46:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:46:50 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <npONy-41VlWnrGGo7ky8_yijmDv3d2GiBL94gFjdOr8=.0fcd55d2-1780-44cf-af26-3aaed9ce8621@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
 <w2Se8iXFy44T3qi5fL5LXlZAH9np90AG5R8x0KF6IJI=.ea3844d6-103d-42ca-93dc-68c753ff3ed2@github.com>
 <BJCOmI0pFYBFx2Eytib7PhvCQ-39xxws-SsEpHi_3fY=.3f955205-1a88-487a-a0a7-581260344ebd@github.com>
 <npONy-41VlWnrGGo7ky8_yijmDv3d2GiBL94gFjdOr8=.0fcd55d2-1780-44cf-af26-3aaed9ce8621@github.com>
Message-ID: <oaYuloODRYSqj75MDMk_WTprQwLXdBB3S4eo39nsGp8=.64a78e1a-a123-46b2-89b9-fa54d9eb0e2a@github.com>

On Tue, 27 May 2025 16:21:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Its because of the Threads_lock.
> 
> OK, I understand it is pre-[JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), but I gotta ask. Are we talking about this one?
> 
> https://github.com/openjdk/jdk/blob/c29537740efb04e061732a700582d43b1956cff4/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L231-L232
> 
> Do you actually need that lock? I would have thought `ThreadListHandle` blocks anything bad to happen with the threads in the list until you release that iterator. This is the whole thing about Thread SMR to allow this kind of safe thread handling without taking extra locks. Maybe I don't see some other code lurking somewhere that wants it, e.g. thread states?
> 
> Since TLH is supposed to guard the thread list stability by itself, maybe we can move that lock acquisition within the thread-walking loop, so that we don't hoard the lock for sampling _all_ threads, just do it one by one...

It's not needed because of TLH - it's required to not sample through safepoints, which cannot be handled gracefully by some GCs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913265687

From mgronlun at openjdk.org  Tue May 27 16:49:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:49:53 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
Message-ID: <BAMnTQvtelNG7J94Jsg2GGmDLDYgadADac3hqK4bZTA=.4a771d56-ae57-4b21-8f02-7b7d6d616eb6@github.com>

On Tue, 27 May 2025 12:26:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> SonarCloud identified this issue today following the integration of [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> It's a remnant from increased sampling pressure during development.
> 
> A change will be coming in this area, just not yet.
> 
> Restoring sampling limits.
> 
> Testing: jdk_jfr
> 
> Thanks SonarCloud!
> 
> Markus

Longer term we should work away having to acquire this lock altogether.

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

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913272494

From mgronlun at openjdk.org  Tue May 27 16:52:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 16:52:53 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
Message-ID: <lBQfHnA3z8HxPy1A20VLD8yhzJmX6L_qdB9J4Ed-9Jk=.0c5f3a92-f0bd-48ad-9c50-75ff25da9026@github.com>

On Tue, 27 May 2025 12:26:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> SonarCloud identified this issue today following the integration of [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> It's a remnant from increased sampling pressure during development.
> 
> A change will be coming in this area, just not yet.
> 
> Restoring sampling limits.
> 
> Testing: jdk_jfr
> 
> Thanks SonarCloud!
> 
> Markus

I think I understand a way to accomplish that now - thanks for lifting the discussion!

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

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913279069

From mgronlun at openjdk.org  Tue May 27 17:20:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 17:20:52 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
Message-ID: <oQMnNWmEuyeNXCOmRoroygI1lH4-DYEhm8qSvu2UKTI=.0160b644-e9c6-4ee0-b01b-313065036ee5@github.com>

On Tue, 27 May 2025 12:26:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> SonarCloud identified this issue today following the integration of [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> It's a remnant from increased sampling pressure during development.
> 
> A change will be coming in this area, just not yet.
> 
> Restoring sampling limits.
> 
> Testing: jdk_jfr
> 
> Thanks SonarCloud!
> 
> Markus

Detailing the consequences provided by JFR Cooperative Sampling - that lock should no longer be needed! Testing :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913354215

From mgronlun at openjdk.org  Tue May 27 17:28:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 May 2025 17:28:51 GMT
Subject: RFR: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <oQMnNWmEuyeNXCOmRoroygI1lH4-DYEhm8qSvu2UKTI=.0160b644-e9c6-4ee0-b01b-313065036ee5@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
 <oQMnNWmEuyeNXCOmRoroygI1lH4-DYEhm8qSvu2UKTI=.0160b644-e9c6-4ee0-b01b-313065036ee5@github.com>
Message-ID: <Vn1OKzYBq__3O0YH54c5WlceMfwezVxk0CeW1tkX01g=.b9e27d76-86d1-46f3-9b9e-8a0736c44521@github.com>

On Tue, 27 May 2025 17:18:11 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Detailing the consequences provided by JFR Cooperative Sampling - that lock should no longer be needed! Testing :)

Premature excitement is the root of all disappointments. There might still be an issue when sampling a virtual thread in native code; in that case, the sampler thread needs the vthread oop...

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

PR Comment: https://git.openjdk.org/jdk/pull/25464#issuecomment-2913375350

From egahlin at openjdk.org  Tue May 27 22:07:11 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 27 May 2025 22:07:11 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v6]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <1voacmczdjMZOfRulRDFsKl_7xs_iEes8drGkaxdJ48=.b984838e-e32d-40cc-98cb-6993c1ee19f6@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/5f5a42aa..4b28ae9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From mgronlun at openjdk.org  Wed May 28 08:59:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 28 May 2025 08:59:59 GMT
Subject: Integrated: 8357829: Commented out sample limit in
 JfrSamplerThread::task_stacktrace
In-Reply-To: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
References: <GYOl-ZZy-gXtXKGcTZm8E-88BI9L-p6ZyPE6-0QZ2rs=.2619362b-46a9-4de7-9a90-c7e5f38738a4@github.com>
Message-ID: <f2GBI8Byw4QFcQG46SS_z07xvJdXx5_Jy9iIivDY8pA=.1079548d-e043-4ac6-a002-bad79088add8@github.com>

On Tue, 27 May 2025 12:26:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> SonarCloud identified this issue today following the integration of [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> It's a remnant from increased sampling pressure during development.
> 
> A change will be coming in this area, just not yet.
> 
> Restoring sampling limits.
> 
> Testing: jdk_jfr
> 
> Thanks SonarCloud!
> 
> Markus

This pull request has now been integrated.

Changeset: f02190bc
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f02190bc30bf3d203a5012140a72023622fc2d77
Stats:     6 lines in 1 file changed: 3 ins; 1 del; 2 mod

8357829: Commented out sample limit in JfrSamplerThread::task_stacktrace

Reviewed-by: shade

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

PR: https://git.openjdk.org/jdk/pull/25464

From mgronlun at openjdk.org  Wed May 28 09:11:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 28 May 2025 09:11:28 GMT
Subject: RFR: 8357911: JFR: Fix subtle xor method tagging bug
Message-ID: <Ut28ZyN-2qu-KzE20F-U0jXJ9D-5MVJ3-Gsc51ayXCI=.636b26e3-ff40-4b80-9b87-810bb95d927d@github.com>

Greetings,

Please see problem description in JIRA issue.

Testing: jdk_jfr

Thanks
Markus

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

Commit messages:
 - 8357911

Changes: https://git.openjdk.org/jdk/pull/25484/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25484&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357911
  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25484/head:pull/25484

PR: https://git.openjdk.org/jdk/pull/25484

From jbechberger at openjdk.org  Wed May 28 09:14:03 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:14:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <0lQMp4kZ_KxQuIziy-O5n3IOGXDSld1ciyLF2ksJP88=.e56674fd-b89b-4d7b-877c-da3c3c6639f9@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <IsFrKFnUVakddhb4JAk5Jq1AMVKZn8jedOLbqRXSPjs=.449cd5dc-14fd-4b07-adda-87deb4a36043@github.com>
 <YP4fzYyoQwsgDdbnCxHZ42RU2c-qWOR1m2h2YhXadoU=.828e3fe3-3b78-451b-8a61-72ab7c06ea52@github.com>
 <IF7-iAufZkMm_vh6eaFe-2JzaWehjRPPx2y91FVItmA=.47dc3de1-540c-4076-8891-8c495b2adf16@github.com>
 <vxljNS3ehcA59e_yVShM2o77Gk7Xs0sG7DcxyEJODiU=.2acb7a63-f3d8-4ad2-9321-cc495dd3c9c3@github.com>
 <TgWEByf1t6vPVb12QM2Jo3_Wnl884B6STrWNgLo3Kj4=.2a6b167c-aa00-47bf-b206-437581c2f2da@github.com>
 <0lQMp4kZ_KxQuIziy-O5n3IOGXDSld1ciyLF2ksJP88=.e56674fd-b89b-4d7b-877c-da3c3c6639f9@github.com>
Message-ID: <VKtJxfbq_wppvFd1-FN-psD4E_q99-n9VxCTaUu_2Uc=.da074f23-2836-4c4e-a0e5-e86707f64e75@github.com>

On Tue, 27 May 2025 16:34:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> It seems to normally be a pointer. I'll try the forward declaration later.
>
> Don't worry if it's too hard. It would just be a nice thing to eliminate these special includes from the header file.

The signal.h is apparently included in the `globaldefinitions_gcc`, so no need to include it.

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

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

From mgronlun at openjdk.org  Wed May 28 09:14:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 28 May 2025 09:14:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
Message-ID: <Nkmt86d0RFZsvPU6Y_tpYDB6UUKL4iHtGAp99VYEDu8=.e29bdafa-78bf-4fcc-92a6-7bd33fc43273@github.com>

On Mon, 26 May 2025 20:57:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 89:

> 87: 
> 88: #ifdef LINUX
> 89:   timer_t* _cpu_timer = nullptr;

initialize in initializer-list, please.

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

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

From jbechberger at openjdk.org  Wed May 28 09:32:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:32:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v17]
In-Reply-To: <b5nUwZhN6Dk2oqzi_tcSc3Flvs1CeSGLZ761vEQT_sw=.2322d705-ef84-4738-8036-4ab43e14b877@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <b5nUwZhN6Dk2oqzi_tcSc3Flvs1CeSGLZ761vEQT_sw=.2322d705-ef84-4738-8036-4ab43e14b877@github.com>
Message-ID: <13TF0svCL8PZgux4OPldxyf6kx-4PI3Yqg05aNTdOAE=.74ce218e-84d1-4a30-a8b2-b5e661ba2476@github.com>

On Tue, 27 May 2025 11:36:41 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 195:
> 
>> 193: 
>> 194:     public boolean hasThreshold() {
>> 195:         if (hasCutoff || isCPUTimeMethodSampling) {
> 
> This is not a duration event anymore, right?

Yes

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

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

From jbechberger at openjdk.org  Wed May 28 09:40:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:40:39 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v18]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <xZ11RXOveumCsU4jiaGffoqAFuLRIb76Xm6fjoyKkrw=.2df6b01f-3186-4f39-967b-79a1cda9c25c@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Tiny fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/d91f5672..298ea428

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=16-17

  Stats: 77 lines in 6 files changed: 5 ins; 60 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Wed May 28 09:50:45 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 09:50:45 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v19]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Y7B2yGEeYJiqxZ85INmSF7wvQ373cADOqTs1o88rmvM=.a894babd-e82a-4ef8-b0d5-dc97d37c9aba@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Tiny fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/298ea428..7c3ec247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Wed May 28 10:32:20 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 10:32:20 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v20]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HMOe2arlJm-rSgF5a5xFzv3WkL86y2AwUpYNhi5k9EU=.c77d8203-c4c0-4261-bfac-3814f3b125fe@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix builds on non Linux platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/7c3ec247..ca6debcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=18-19

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From egahlin at openjdk.org  Wed May 28 12:03:17 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 12:03:17 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v7]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <LYiHbvYEy4B_NS1qb02cBXhZRhDs4xuGjgBYE0smM9o=.23809721-85c9-4745-8ca9-4c2b42a84152@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/4b28ae9d..53787227

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From egahlin at openjdk.org  Wed May 28 12:10:50 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 12:10:50 GMT
Subject: RFR: 8357830: JfrVframeStream::_cont_entry shadows super-class
 field
In-Reply-To: <eM31Z_0ZH4D1DQpAall8eIqJ7UUJtHWZliDUnttsHU4=.138b6c6e-0eb1-4d5e-a600-17233f20a023@github.com>
References: <eM31Z_0ZH4D1DQpAall8eIqJ7UUJtHWZliDUnttsHU4=.138b6c6e-0eb1-4d5e-a600-17233f20a023@github.com>
Message-ID: <dDbqxY879oPSpgoa1rmCv8dmFxNbSd0uTZlT_ro-Wkg=.0dc94df2-9367-48a8-acdf-3f05888aaf49@github.com>

On Tue, 27 May 2025 13:49:02 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> SonarCloud has a report that `JfrVframeStream::_cont_entry` shadows the super-class field of the same name.
> 
> Fixed and inlined the constructor.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25465#pullrequestreview-2874754275

From mgronlun at openjdk.org  Wed May 28 12:15:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 28 May 2025 12:15:55 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v7]
In-Reply-To: <LYiHbvYEy4B_NS1qb02cBXhZRhDs4xuGjgBYE0smM9o=.23809721-85c9-4745-8ca9-4c2b42a84152@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <LYiHbvYEy4B_NS1qb02cBXhZRhDs4xuGjgBYE0smM9o=.23809721-85c9-4745-8ca9-4c2b42a84152@github.com>
Message-ID: <6r-WpuR0SB1Mq2eYgVzo_jvZlMcb9VN64vshuX9XHpM=.0e6e529b-2afe-4c9d-960f-391e97baa082@github.com>

On Wed, 28 May 2025 12:03:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25306#pullrequestreview-2874769092

From egahlin at openjdk.org  Wed May 28 13:48:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 13:48:53 GMT
Subject: RFR: 8357911: JFR: Fix subtle xor method tagging bug
In-Reply-To: <Ut28ZyN-2qu-KzE20F-U0jXJ9D-5MVJ3-Gsc51ayXCI=.636b26e3-ff40-4b80-9b87-810bb95d927d@github.com>
References: <Ut28ZyN-2qu-KzE20F-U0jXJ9D-5MVJ3-Gsc51ayXCI=.636b26e3-ff40-4b80-9b87-810bb95d927d@github.com>
Message-ID: <Gj47uF4VAd2nt2EfIs_zYPaw9po8VdeJvb4h-1BV8Co=.86894cf3-430e-41e1-adca-7d27c55b400b@github.com>

On Wed, 28 May 2025 09:06:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Please see problem description in JIRA issue.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25484#pullrequestreview-2875185499

From mgronlun at openjdk.org  Wed May 28 13:55:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 28 May 2025 13:55:59 GMT
Subject: Integrated: 8357911: JFR: Fix subtle xor method tagging bug
In-Reply-To: <Ut28ZyN-2qu-KzE20F-U0jXJ9D-5MVJ3-Gsc51ayXCI=.636b26e3-ff40-4b80-9b87-810bb95d927d@github.com>
References: <Ut28ZyN-2qu-KzE20F-U0jXJ9D-5MVJ3-Gsc51ayXCI=.636b26e3-ff40-4b80-9b87-810bb95d927d@github.com>
Message-ID: <cZb2xrAMlHGjm7AvP1p-FDJXxnq2rwYVejmrys3-fA0=.e9be5f4c-4226-4be9-a600-863b6c0ab234@github.com>

On Wed, 28 May 2025 09:06:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Please see problem description in JIRA issue.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 1a65719a
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a65719ab336336f94777df85bafeeef2c4d5b56
Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod

8357911: JFR: Fix subtle xor method tagging bug

Reviewed-by: egahlin

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

PR: https://git.openjdk.org/jdk/pull/25484

From mgronlun at openjdk.org  Wed May 28 13:56:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 28 May 2025 13:56:00 GMT
Subject: Integrated: 8357830: JfrVframeStream::_cont_entry shadows super-class
 field
In-Reply-To: <eM31Z_0ZH4D1DQpAall8eIqJ7UUJtHWZliDUnttsHU4=.138b6c6e-0eb1-4d5e-a600-17233f20a023@github.com>
References: <eM31Z_0ZH4D1DQpAall8eIqJ7UUJtHWZliDUnttsHU4=.138b6c6e-0eb1-4d5e-a600-17233f20a023@github.com>
Message-ID: <jHsR_0SoTQeIMiIZ-o_mNwCd3lufrPRnthiWB8eW3LM=.11c50ecd-fbfd-4bdd-8736-d455d63ee7ba@github.com>

On Tue, 27 May 2025 13:49:02 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> SonarCloud has a report that `JfrVframeStream::_cont_entry` shadows the super-class field of the same name.
> 
> Fixed and inlined the constructor.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 016cc4f3
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/016cc4f333d1a59a7cd534cb7ee4c373087efd10
Stats:     92 lines in 3 files changed: 35 ins; 56 del; 1 mod

8357830: JfrVframeStream::_cont_entry shadows super-class field

Reviewed-by: egahlin

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

PR: https://git.openjdk.org/jdk/pull/25465

From egahlin at openjdk.org  Wed May 28 15:11:14 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 15:11:14 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v8]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <xZf09ICrmTMy2DNsZVMaHddNbuhFGutIfiiVdejMN24=.9cc065ac-c993-41d2-b3d0-a912958282f8@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge
 - Fix comment
 - Improve comment
 - Remove METHOD_FLAG_USED_PREVIOUS_EPOCH_BIT(method)
 - Merge
 - Atomic::load_acquire(&_method_tracer_state);
 - Reviewer feedback
 - Initial

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

Changes: https://git.openjdk.org/jdk/pull/25306/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=07
  Stats: 7075 lines in 107 files changed: 6621 ins; 363 del; 91 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From jbechberger at openjdk.org  Wed May 28 15:27:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 15:27:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v21]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HDnDGi516BVT8c8-bDmpYeTs80k937xo2RVXPi7pSv4=.bb01c91b-87f1-48d5-b1e9-1f08e1ff3d12@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits:

 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Fix builds on non Linux platforms
 - Tiny fixes
 - Tiny fixes
 - Remove assertion
 - Remove mistake
 - Merge branch 'master' of https://git.openjdk.org/jdk into parttimenerd_cooperative_cpu_time_sampler
 - Fix other platforms
 - Improve one warning
 - Fix MacOS build
 - ... and 79 more: https://git.openjdk.org/jdk/compare/e3f85c96...14f1d068

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=20
  Stats: 2339 lines in 45 files changed: 2164 ins; 159 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Wed May 28 17:19:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 17:19:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v22]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <1IqxrA9yctj4oWW6HVBY1T6xzpgLc80f8ZYo088QAlE=.c99ef9df-563d-4b0b-bdb0-433f2e0022db@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Replace views with cpu-time-statistics view

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/14f1d068..4a2cbac3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=20-21

  Stats: 22 lines in 1 file changed: 0 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From shade at openjdk.org  Wed May 28 17:23:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 May 2025 17:23:01 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v8]
In-Reply-To: <xZf09ICrmTMy2DNsZVMaHddNbuhFGutIfiiVdejMN24=.9cc065ac-c993-41d2-b3d0-a912958282f8@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <xZf09ICrmTMy2DNsZVMaHddNbuhFGutIfiiVdejMN24=.9cc065ac-c993-41d2-b3d0-a912958282f8@github.com>
Message-ID: <Q2f7rij22r5K-nnS59bb9hWQMkTJWys-SBROEMewlrY=.4006e574-7b73-4bb6-8f49-b8552adbcf9b@github.com>

On Wed, 28 May 2025 15:11:14 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge
>  - Fix comment
>  - Improve comment
>  - Remove METHOD_FLAG_USED_PREVIOUS_EPOCH_BIT(method)
>  - Merge
>  - Atomic::load_acquire(&_method_tracer_state);
>  - Reviewer feedback
>  - Initial

Looks like some of my comments were not fully addressed, these ones that I caught on second read:

src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 215:

> 213:   assert(JdkJfrEvent::is_a(ik), "invariant");
> 214:   if (has_annotation(ik, annotation_type, default_value, value)) {
> 215:      return true;

Unnecessary change?

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp line 72:

> 70: void JfrTraceIdEpoch::set_method_tracer_tag_state() {
> 71:   assert_locked_or_safepoint(ClassLoaderDataGraph_lock);
> 72:   Atomic::store(&_method_tracer_state, true);

Well, now that `has_method_tracer_changed_tag_state` does `Atomic::load_acquire`, the stores should be `Atomic::release_store` at very least? The fact these are done under the CLDG lock is not really enough.

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

PR Review: https://git.openjdk.org/jdk/pull/25306#pullrequestreview-2875844744
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2112382006
PR Review Comment: https://git.openjdk.org/jdk/pull/25306#discussion_r2112387605

From shade at openjdk.org  Wed May 28 17:23:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 May 2025 17:23:02 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v8]
In-Reply-To: <SYE859CFIE1FzjZDkX2b4u6HYpAFcykiNZxUfj-OF6A=.fc58e44a-af9b-481b-9510-bef0d2d1e2f5@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <OyHxfrOW01XhwggvVy29a1hjI5I-CyfnK9hoi7JCTRo=.d9442209-f3f7-4329-8074-ac24c8ec66ce@github.com>
 <SYE859CFIE1FzjZDkX2b4u6HYpAFcykiNZxUfj-OF6A=.fc58e44a-af9b-481b-9510-bef0d2d1e2f5@github.com>
Message-ID: <v2By9-VzK0HEDNNjeiE0Bx1-M-OXU32J2AdacAXhkHA=.cfd1d3e4-b8db-49cd-be2b-41af4d3ce880@github.com>

On Thu, 22 May 2025 19:56:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java line 249:
>> 
>>> 247:     }
>>> 248: 
>>> 249:     private synchronized static void reset() {
>> 
>> Any sense to do  `synchronized` here, given that `timed{Methods,Classes}` are `ConcurrentHashMap`-s?
>
> It's only used by PlatformTracer::initialize(), so it can be removed.

Should it be removed in this PR then?

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

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

From jbechberger at openjdk.org  Wed May 28 17:57:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 28 May 2025 17:57:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
Message-ID: <E6DVl6uikV7YtSz6hh_pbzcJQKZo-q9Q9cvYS2RH1uA=.e1b4a248-b466-4f08-b8f5-40c5211ee900@github.com>

On Mon, 26 May 2025 15:42:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.
> 
> I have a Mac, so I could not try it with an actual recording, but something like this:
> 
> ```
> [application.cpu-time-statistics]
> label = "CPU Time Samples Statistics"
> form = "COLUMN 'Successful Samples', 'Failed Samples', 'Total Samples', 'Lost Samples'
>         SELECT COUNT(S.startTime), COUNT(F.startTime), Count(A.startTime), SUM(L.lostSamples)
>         FROM 
>           CPUTimeSample AS S,
>           CPUTimeSample AS F,
>           CPUTimeSample AS A,
>           CPUTimeSampleLoss AS L
>         WHERE
>           S.failed = 'false' AND
>           F.failed = 'true'"
> ```

I implemented this now and removed the other statistics related views.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2917155602

From egahlin at openjdk.org  Wed May 28 20:52:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 20:52:41 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v9]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <FK_YOMFxsQZiUTJnv3iXhS2DFCcHMd9AgES0K0xtQ9I=.1d14fde3-eec7-497f-a39a-8b5559d9b7ab@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Add back sticky bit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/2ca64a1b..73025f1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From egahlin at openjdk.org  Wed May 28 21:14:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 21:14:36 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v10]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <Sz3MV3Vd0Po4eLiRB5pNlwlnzJbgPox6YBirAcqh0bY=.86a06956-b628-42a3-804d-c5c6d12b0e6b@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation and synchronized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/73025f1f..06ad6faf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=08-09

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From egahlin at openjdk.org  Wed May 28 21:23:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 21:23:55 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v8]
In-Reply-To: <Q2f7rij22r5K-nnS59bb9hWQMkTJWys-SBROEMewlrY=.4006e574-7b73-4bb6-8f49-b8552adbcf9b@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <xZf09ICrmTMy2DNsZVMaHddNbuhFGutIfiiVdejMN24=.9cc065ac-c993-41d2-b3d0-a912958282f8@github.com>
 <Q2f7rij22r5K-nnS59bb9hWQMkTJWys-SBROEMewlrY=.4006e574-7b73-4bb6-8f49-b8552adbcf9b@github.com>
Message-ID: <IGcOI1Rj6AAStWi82Z9JGJyrSGyiszxVYil2xo__NCk=.6c018470-f51b-4b37-9360-925700d9cd1a@github.com>

On Wed, 28 May 2025 17:20:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks like some of my comments were not fully addressed, these ones that I caught on second read:

Sorry about that. I remember fixing synchronized, but maybe it was in the wrong branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/25306#issuecomment-2917644195

From egahlin at openjdk.org  Wed May 28 22:03:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 28 May 2025 22:03:13 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v11]
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <GM-vh4Wcqq80dt8lYYflNetcKd3-IIfcfnWTfmOQgB0=.31d4db05-31f3-4802-b344-6f4e3becb5e0@github.com>

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Atomic::release_store

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25306/files
  - new: https://git.openjdk.org/jdk/pull/25306/files/06ad6faf..31d602be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25306&range=09-10

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25306/head:pull/25306

PR: https://git.openjdk.org/jdk/pull/25306

From shade at openjdk.org  Thu May 29 07:52:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 May 2025 07:52:56 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v11]
In-Reply-To: <GM-vh4Wcqq80dt8lYYflNetcKd3-IIfcfnWTfmOQgB0=.31d4db05-31f3-4802-b344-6f4e3becb5e0@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <GM-vh4Wcqq80dt8lYYflNetcKd3-IIfcfnWTfmOQgB0=.31d4db05-31f3-4802-b344-6f4e3becb5e0@github.com>
Message-ID: <ST7q4L2hNJICCySom4rRFhDgN7IMziez88Wd24kQCi0=.d2ae59c2-84f0-499a-99db-fc10447b286d@github.com>

On Wed, 28 May 2025 22:03:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
>> 
>> Testing: tier 1-3, test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Atomic::release_store

Looks OK to me, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25306#pullrequestreview-2877416905

From egahlin at openjdk.org  Thu May 29 08:17:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 29 May 2025 08:17:54 GMT
Subject: RFR: 8352738: Implement JEP 520: JFR Method Timing and Tracing
 [v11]
In-Reply-To: <g9__TdjfzyL8peXK_OQmt4cskn9Qzyjy_5dj377Nyh4=.824c5606-c144-4775-8407-22c9a040b9a5@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
 <g9__TdjfzyL8peXK_OQmt4cskn9Qzyjy_5dj377Nyh4=.824c5606-c144-4775-8407-22c9a040b9a5@github.com>
Message-ID: <yzf4v0-lK-g609b_YlYBHCRq4gwdJ68ho8sCAqnTVk0=.3dfff369-858a-4035-99f5-dc2cab74bc9e@github.com>

On Thu, 22 May 2025 18:52:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Atomic::release_store
>
> Mainly looked at bytecode transformation; those look good.

Thanks for the reviews, @liach, @mgronlun, and @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/25306#issuecomment-2918665324

From egahlin at openjdk.org  Thu May 29 08:34:08 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 29 May 2025 08:34:08 GMT
Subject: Integrated: 8352738: Implement JEP 520: JFR Method Timing and Tracing
In-Reply-To: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
References: <rAiuA3V8DNvMcxncvZyUeKUO2dr4Bhwn3_CzfhTFM7o=.730c4daf-2809-491d-979b-11388e685392@github.com>
Message-ID: <VapcD0l3Y94rWfXBqbHR5SOzdXPFC22EIBliPu-_ic8=.2b68bcce-27d1-4e0d-b18e-c37d9a92df57@github.com>

On Mon, 19 May 2025 15:24:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately.
> 
> Testing: tier 1-3, test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 07f5b762
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07f5b762a09e4fe9f7ba71368593f6dfa0ff8f6e
Stats:     7075 lines in 107 files changed: 6621 ins; 363 del; 91 mod

8352738: Implement JEP 520: JFR Method Timing and Tracing

Co-authored-by: Markus Gr?nlund <mgronlun at openjdk.org>
Reviewed-by: shade, mgronlun

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

PR: https://git.openjdk.org/jdk/pull/25306

From jbechberger at openjdk.org  Thu May 29 16:26:47 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 29 May 2025 16:26:47 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v23]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <qZnVk7hAyH7Lq9NmXV4oPPwLSvkZtYFE70nxKTe8olg=.49c2f926-58c8-4ddd-bfc9-beb394090da1@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 93 commits:

 - Fix merge
 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Fix merge mistake
 - Replace views with cpu-time-statistics view
 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Fix builds on non Linux platforms
 - Tiny fixes
 - Tiny fixes
 - Remove assertion
 - Remove mistake
 - ... and 83 more: https://git.openjdk.org/jdk/compare/79aff26c...adcbec51

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=22
  Stats: 2303 lines in 44 files changed: 2157 ins; 130 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From jbechberger at openjdk.org  Thu May 29 21:56:21 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 29 May 2025 21:56:21 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix tiny issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/adcbec51..16faa421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=22-23

  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From dtabata at openjdk.org  Fri May 30 09:07:59 2025
From: dtabata at openjdk.org (Daishi Tabata)
Date: Fri, 30 May 2025 09:07:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
Message-ID: <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>

On Thu, 29 May 2025 21:56:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tiny issue

src/hotspot/share/jfr/metadata/metadata.xml line 975:

> 973:   </Event>
> 974: 
> 975:   <Event name="CPUTimeSampleLoss" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Lost Samples" description="Records that the CPU time sampler lost samples"

I'm not a reviewer, but I just wanted to comment something I noticed.
The JEP document says CPUTimeSampleLos'**t**', but the implementation says CPUTimeSampleLos'**s**'. Which one is correct?
A sentence from the JEP document:

Another new event,?`jdk.CPUTimeSampleLost`, is emitted when samples are lost ...

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

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

From jbechberger at openjdk.org  Fri May 30 09:23:05 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 30 May 2025 09:23:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
 <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>
Message-ID: <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@github.com>

On Fri, 30 May 2025 09:04:44 GMT, Daishi Tabata <dtabata at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix tiny issue
>
> src/hotspot/share/jfr/metadata/metadata.xml line 975:
> 
>> 973:   </Event>
>> 974: 
>> 975:   <Event name="CPUTimeSampleLoss" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Lost Samples" description="Records that the CPU time sampler lost samples"
> 
> I'm not a reviewer, but I just wanted to comment something I noticed.
> The JEP document says CPUTimeSampleLos'**t**', but the implementation says CPUTimeSampleLos'**s**'. Which one is correct?
> A sentence from the JEP document:
> 
> Another new event,?`jdk.CPUTimeSampleLost`, is emitted when samples are lost ...

Thanks for catching this mistake. I'll fix it this afternoon.

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

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

From jbechberger at openjdk.org  Fri May 30 10:17:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 30 May 2025 10:17:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove debug printf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/16faa421..3a10d552

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=23-24

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

PR: https://git.openjdk.org/jdk/pull/25302

From vyazici at openjdk.org  Fri May 30 10:55:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 10:55:26 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot]
Message-ID: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>

Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.

`stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.

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

Commit messages:
 - Remove redundant assert
 - Discard changes unrelated with build and tools
 - Revert superfluous changes
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357993
  Stats: 13 lines in 4 files changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25542/head:pull/25542

PR: https://git.openjdk.org/jdk/pull/25542

From mgronlun at openjdk.org  Sat May 31 10:13:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:13:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
Message-ID: <wUE0E1SOPvEUeUT2TFEBU5MzoG9Al1WPRvxB4Nm9kvc=.b4595e9f-75b3-49b8-92a4-ebf938195bb0@github.com>

On Fri, 30 May 2025 10:17:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug printf

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 36:

> 34: #if defined(LINUX)
> 35: 
> 36: #include "memory/padded.hpp"

What is padded? If not, this should go.

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

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

From mgronlun at openjdk.org  Sat May 31 10:13:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:13:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <VLpx6yp9rr4wOVVsvTbMO1ox9kwD2SWHgJbMSoKPv3I=.80dae640-ec33-43b4-8af7-c58e8535cb19@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <s7h-5xRPJ_llg0eGf2S3W7aSFJyZkiuZPXKvKTSe_a8=.76154ba5-5fec-477d-9136-f4f59a9ea199@github.com>
 <59lPKJ5Zis_2FZevjCLN_rogzJwfr4tS_7_mvJ0Ggyo=.9aef1bbf-2e7d-4be2-8271-15d139205736@github.com>
 <VLpx6yp9rr4wOVVsvTbMO1ox9kwD2SWHgJbMSoKPv3I=.80dae640-ec33-43b4-8af7-c58e8535cb19@github.com>
Message-ID: <BziKr0wbQDb_5pUJqeGmHkwdclyoOF1NvrYivbwxEZw=.aa000c09-133b-40a8-ad9b-a3039b755501@github.com>

On Tue, 27 May 2025 11:58:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 174:
>> 
>>> 172:   assert(request._sample_pc != nullptr, "invariant");
>>> 173:   assert(jt != nullptr, "invariant");
>>> 174:   assert(jt->thread_state() == _thread_in_Java, "invariant");
>> 
>> What?
>
> I also call this method for native stack traces in my implementation. As I have to walk native stack traces at stackwalks.

Assert for thread->state() == _thread_in_native then.

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

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

From mgronlun at openjdk.org  Sat May 31 10:26:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:26:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
Message-ID: <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>

On Fri, 30 May 2025 10:17:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug printf

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 363:

> 361: }
> 362: 
> 363: void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {

I still don't understand what the purpose is for this routine.

I understand that this is to handle the situation where a thread is in state _thread_in_native, and cannot be handled immediately. But what problem are you trying to solve?

It seems there is some convoluted logic to only locate and process those requests that correspond to samples where the thread would be in native? But what purpose does that serve?

In JFR Cooperative Sampling, we allow the sampler thread to drain the entire sample request queue for a thread when it is found to be running in state _thread_in_native, on the premise that we cannot know or guarantee if or when a thread will return to the VM.

This seems to be some kind of semi-solution that does not solve anything:

1. If you don't care about samples being processed and delivered swiftly, you don't even need the sampler thread to process native frames - do nothing and let the thread process everything on return from native (those native requests are still valid (the ljf is still valid).
2. If you want swift delivery of samples, you drain the entire queue, not just some native samples.

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

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

From mgronlun at openjdk.org  Sat May 31 10:30:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:30:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>
Message-ID: <pXBgCadMd6rhXAIKzn9Jgg64BPblP5w9I7VWb-4i454=.083df9a4-9de2-4011-9a74-0c8fde423989@github.com>

On Sat, 31 May 2025 10:22:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug printf
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 363:
> 
>> 361: }
>> 362: 
>> 363: void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
> 
> I still don't understand what the purpose is for this routine.
> 
> I understand that this is to handle the situation where a thread is in state _thread_in_native, and cannot be handled immediately. But what problem are you trying to solve?
> 
> It seems there is some convoluted logic to only locate and process those requests that correspond to samples where the thread would be in native? But what purpose does that serve?
> 
> In JFR Cooperative Sampling, we allow the sampler thread to drain the entire sample request queue for a thread when it is found to be running in state _thread_in_native, on the premise that we cannot know or guarantee if or when a thread will return to the VM.
> 
> This seems to be some kind of semi-solution that does not solve anything:
> 
> 1. If you don't care about samples being processed and delivered swiftly, you don't even need the sampler thread to process native frames - do nothing and let the thread process everything on return from native (those native requests are still valid (the ljf is still valid).
> 2. If you want swift delivery of samples, you drain the entire queue, not just some native samples.

Secondly, if you only want to process native requests that are equal to or correspond to a specific native site, you should only need to call stacktrace.record() inner for one of the sample requests, not all, and reuse the sid for all the requests.

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

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

From mgronlun at openjdk.org  Sat May 31 10:43:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 10:43:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
Message-ID: <CRTBE7yyj-RP26N7o896T9PKWzzZPa-KOazE3ez74BQ=.69adda67-70d8-4877-a711-eec22ab8780b@github.com>

On Fri, 30 May 2025 10:17:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug printf

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 139:

> 137: 
> 138:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread
> 139:   static void trigger_is_thread_in_native_stackwalking();

Is it sampling that is triggered? Sampling refers to the asynchronous signal received from the OS.

You are asking for the sampler thread to process JFR Sample Requests, right? That is, already taken samples.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 263:

> 261:     // Yet another instance of safepoint bias,to be addressed with
> 262:     // more exact and stricter versions when parsable blobs become available.
> 263:     biased = true;

Careful here. This site CAN be biased, but it's also the fallthrough from the processing in 250-259, which is a direct sample hit, i.e., non-biased.

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 89:

> 87:   _has_cpu_time_jfr_requests(false),
> 88:   _cpu_time_jfr_queue(0),
> 89:   _wants_is_thread_in_native_stackwalking(false)

This field name can be improved.

"_do_async_processing_of_cpu_time_jfr_requests"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117694262
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117694730
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2117693395

From egahlin at openjdk.org  Sat May 31 12:29:24 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 31 May 2025 12:29:24 GMT
Subject: RFR: 8356698: JFR: @Contextual
Message-ID: <K1QvEnSd5D3c6-ybeArew0KpF4etzE8e3mgKB8NjTdI=.640a837f-ea43-4c2f-9566-09a015601f11@github.com>

Could I have a review of a new annotation that can be used to annotate a field as contextual. 

Testing: jdk/jdk/jfr + tier1

Thanks
Erik

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

Commit messages:
 - Simplification and cleanup
 - Merge
 - Remove mistakenly added file
 - Update
 - Whitspace
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25249/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25249&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356698
  Stats: 706 lines in 6 files changed: 698 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25249/head:pull/25249

PR: https://git.openjdk.org/jdk/pull/25249

From egahlin at openjdk.org  Sat May 31 13:18:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 31 May 2025 13:18:44 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
Message-ID: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>

Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).

Testing: test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25559/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351594
  Stats: 1230 lines in 37 files changed: 1028 ins; 87 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From jbechberger at openjdk.org  Sat May 31 13:24:59 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sat, 31 May 2025 13:24:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <pXBgCadMd6rhXAIKzn9Jgg64BPblP5w9I7VWb-4i454=.083df9a4-9de2-4011-9a74-0c8fde423989@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <5m2Crvg9Rakc8MuHPBBMIJhDBXH500qA3TuPNbpwuCI=.a6d91fc8-1623-46d8-91a6-479da8513faa@github.com>
 <pXBgCadMd6rhXAIKzn9Jgg64BPblP5w9I7VWb-4i454=.083df9a4-9de2-4011-9a74-0c8fde423989@github.com>
Message-ID: <1VvaCskuxVSYYFKdGKY9oUY2f2ADU31_qal8jmabmRI=.02487cd6-850e-49e9-a735-2ad257286bb4@github.com>

On Sat, 31 May 2025 10:28:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 363:
>> 
>>> 361: }
>>> 362: 
>>> 363: void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
>> 
>> I still don't understand what the purpose is for this routine.
>> 
>> I understand that this is to handle the situation where a thread is in state _thread_in_native, and cannot be handled immediately. But what problem are you trying to solve?
>> 
>> It seems there is some convoluted logic to only locate and process those requests that correspond to samples where the thread would be in native? But what purpose does that serve?
>> 
>> In JFR Cooperative Sampling, we allow the sampler thread to drain the entire sample request queue for a thread when it is found to be running in state _thread_in_native, on the premise that we cannot know or guarantee if or when a thread will return to the VM.
>> 
>> This seems to be some kind of semi-solution that does not solve anything:
>> 
>> 1. If you don't care about samples being processed and delivered swiftly, you don't even need the sampler thread to process "native" sample requests - do nothing and let the thread itself process everything on return from native (those native requests are still valid (the ljf is still valid).
>> 2. If you want swift delivery of samples, you drain the entire queue, not just some native samples.
>
> Secondly, if you only want to process native requests that are equal to or correspond to a specific native site, you should only need to call stacktrace.record() inner for one of the sample requests, not all, and reuse the sid for all the requests.

You're right, I'll be just draining the whole queue.

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

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

From mgronlun at openjdk.org  Sat May 31 19:03:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 19:03:50 GMT
Subject: RFR: 8356698: JFR: @Contextual
In-Reply-To: <K1QvEnSd5D3c6-ybeArew0KpF4etzE8e3mgKB8NjTdI=.640a837f-ea43-4c2f-9566-09a015601f11@github.com>
References: <K1QvEnSd5D3c6-ybeArew0KpF4etzE8e3mgKB8NjTdI=.640a837f-ea43-4c2f-9566-09a015601f11@github.com>
Message-ID: <Uta6O__bclaGO6dEE-mfCjpStTIyh2ql9m5s3EFWRsw=.24d09dcf-1ece-4b0d-bc8a-8b5b5b634269@github.com>

On Thu, 15 May 2025 12:46:54 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a new annotation that can be used to annotate a field as contextual. 
> 
> Testing: jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

A very nice addition and an excellent demo example for showcasing the capabilities is provided in the test: TestPrintContextual.java

src/jdk.jfr/share/classes/jdk/jfr/events/MethodTraceEvent.java line 39:

> 37: public final class MethodTraceEvent extends AbstractJDKEvent {
> 38: 
> 39:     @Contextual

Should the MethodTraceEvent's method field really have this annotation? Or is it a remnant from testing?

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25249#pullrequestreview-2884461033
PR Review Comment: https://git.openjdk.org/jdk/pull/25249#discussion_r2118169044

From mgronlun at openjdk.org  Sat May 31 20:15:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 20:15:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 39:

> 37:  * example, {@code "100/s"}).
> 38:  * <p>
> 39:  * If the event class annotated with {@code Throttle} are filtered by other

"is filtered"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118216821

From mgronlun at openjdk.org  Sat May 31 20:19:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 20:19:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <99eWsd--g2GrdhR2r9_HY7JMWK2RZJZ7ahwatYCvXU4=.50bb0e3f-5ee2-41b7-bf66-0d83e8d08c52@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 148:

> 146:             return true;
> 147:         }
> 148:         if (superClass != null) {

Does this also need to search superClass's super?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118221175

From mgronlun at openjdk.org  Sat May 31 21:12:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:12:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <vKdKE5fLsvlLISgHCtv-hd4fsDPY9ziU6odImrFsAGM=.441615c8-e981-46fd-9a37-39218703002e@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:

> 254:             // }
> 255:             getEventConfiguration(codeBuilder);
> 256:             codeBuilder.aload(0);

Can issue a dup() here if you want to avoid the second aload(0).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118257554

From mgronlun at openjdk.org  Sat May 31 21:17:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:17:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Dbuu94cHaFlQPlttifkqqPt53bkI1_7PouvQlThOw40=.f7a88efa-c25a-408d-8fc8-4d4ac6d74898@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 257:

> 255:             getEventConfiguration(codeBuilder);
> 256:             codeBuilder.aload(0);
> 257:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_START_TIME);

In native,we use the endTime for duration events? Is there a need to synchronize the two?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118261907

From mgronlun at openjdk.org  Sat May 31 21:27:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:27:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:

> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);

Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 590:

> 588:     private void setDuration(CodeBuilder codeBuilder, Consumer<CodeBuilder> expression) {
> 589:         codeBuilder.aload(0);
> 590:         expression.accept(codeBuilder);

dont know what expression.accept() does, but does it really consume the this pointer? I see its pushed again (aload(0)) if its throttled below?

src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 59:

> 57:     // static boolean shouldThrottleCommit(long timestamp)
> 58:     public boolean shouldThrottleCommit(long timestamp) {
> 59:         return throttler.sample(timestamp);

Can we assert on isEnabled?

src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 77:

> 75:             return rawDuration;
> 76:         }
> 77:         long endTime = startTime + rawDuration;

I see now that you are using endTime as well, nice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118272073
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118272829
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118277498
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118279057

From mgronlun at openjdk.org  Sat May 31 21:38:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 31 May 2025 21:38:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <i-9qmnjV-4cag2uwXDkuIsfyZKhgx8vm_wJHJinIz1Y=.8b8466a6-8e87-4327-87ee-b3fdb6591af2@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 62:

> 60:     // Not synchronized in fast path, but uses volatile reads.
> 61:     public boolean sample(long ticks) {
> 62:         if (disabled) {

This volatile load is somewhat disappointing. Do you think it is needed? What happens if it is read without happens-before? It just creates an event that will most likely get discarded by the recorder engine on reset (if its set on setting update). If it's set to disabled, then the recorder engine has most likely stopped already, so the event will be discarded. Event settings are set with no visibility guarantees as to exact when they apply, so it should not really matter when it goes to disabled.

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 74:

> 72:                 }
> 73:             }
> 74:             return activeWindow.sample();

In native, a ticks value outside of the window is not returned true.

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 76:

> 74:             return activeWindow.sample();
> 75:         }
> 76:         return current.sample();

This could result in sampling in an already expired window.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118281909
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118282232
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2118283830