From jbechberger at openjdk.org  Sun Jun  1 07:13:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:13:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <CRTBE7yyj-RP26N7o896T9PKWzzZPa-KOazE3ez74BQ=.69adda67-70d8-4877-a711-eec22ab8780b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <CRTBE7yyj-RP26N7o896T9PKWzzZPa-KOazE3ez74BQ=.69adda67-70d8-4877-a711-eec22ab8780b@github.com>
Message-ID: <2nYqo0wpUrLLJV9iDRLwj5xjV06waCzu8Ma8YSAToIY=.1059ee96-77f8-47e6-8797-3f2b47783311@github.com>

On Sat, 31 May 2025 10:37: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:
>> 
>>   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 operating system (OS).
> 
> You are asking for the sampler thread to process already taken JFR Sample Requests in the queue, right?

Yes and I like your implied name better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2118819169

From jbechberger at openjdk.org  Sun Jun  1 07:17:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:17:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <wUE0E1SOPvEUeUT2TFEBU5MzoG9Al1WPRvxB4Nm9kvc=.b4595e9f-75b3-49b8-92a4-ebf938195bb0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <wUE0E1SOPvEUeUT2TFEBU5MzoG9Al1WPRvxB4Nm9kvc=.b4595e9f-75b3-49b8-92a4-ebf938195bb0@github.com>
Message-ID: <V-gvB668d9MPgwPjeP-3P0XrPHxVjucgac6D4W-Rz0E=.669ebaad-4785-49b3-b0b2-aff587479747@github.com>

On Sat, 31 May 2025 10:09:15 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.hpp line 36:
> 
>> 34: #if defined(LINUX)
>> 35: 
>> 36: #include "memory/padded.hpp"
> 
> What is padded? If not, this should go.

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2118820425

From jbechberger at openjdk.org  Sun Jun  1 07:22:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:22:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@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>
 <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@github.com>
Message-ID: <dw0nEvtOhHk5pe5VLBy_RF29x_ACwQ_UTjAVZykGKmc=.41920e11-799a-40a2-a258-3e796c260196@github.com>

On Fri, 30 May 2025 09:19:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> 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.

I fixed it by changing the JEP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2118825477

From jbechberger at openjdk.org  Sun Jun  1 07:26:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:26:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@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:

 - Refactoring
 - Remove convoluted native trace logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/3a10d552..439763a3

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

  Stats: 56 lines in 5 files changed: 3 ins; 27 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 mgronlun at openjdk.org  Sun Jun  1 13:04:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:04:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <uywTbPrvFb9SBmQLpDMleEV0RC8q34PCf5UA-mtW58s=.0cd920f6-c263-46dc-a01f-3692354906d4@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 42:

> 40: #include "runtime/javaThread.hpp"
> 41: #include "runtime/osThread.hpp"
> 42: #include "runtime/safepointMechanism.hpp"

Not needed, since you have the .inline.hpp

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 102:

> 100: 
> 101: u4 JfrCPUTimeTraceQueue::size() const {
> 102:   return Atomic::load(&_head);

Is this read from multiple threads? In that case, load_acquire().

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 threads that are in native state (and requested to be sampled)

We are not really "sampling", but processing their queues, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119128911
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119129239
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119129708

From mgronlun at openjdk.org  Sun Jun  1 13:08:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:08:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 367:

> 365:     JfrCPUTimeSampleRequest& request = queue.at(i);
> 366:     JfrStackTrace stacktrace;
> 367:     traceid tid = JfrThreadLocal::thread_id(thread);

Check the tid as a function of the JfrSampleRequest, like we do in JFR Cooperative Sampling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119130991

From mgronlun at openjdk.org  Sun Jun  1 13:12:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:12:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <S5eA8KfkIZtoUbXMgpvjF84gfCbUuvH9EvxhrieGc0I=.ec24e1d0-0084-41a0-aaff-ace3a2de96e7@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 413:

> 411:   }
> 412:   if (Atomic::load(&count) % 1000 == 0) {
> 413:     log_info(jfr)("CPU thread sampler sent %zu events, lost %d, biased %zu\n", Atomic::load(&count), Atomic::load(&_lost_samples_sum), Atomic::load(&biased_count));

put this logging under jfr+debug or log+trace please

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119137014

From egahlin at openjdk.org  Sun Jun  1 13:12:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 13:12:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
Message-ID: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>

On Sat, 31 May 2025 20:13:01 GMT, Markus Gr?nlund <mgronlun 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"

Will fix

> 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?

The annotation is inherited so  superClass's super will be included.

> 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).

I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

> 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?

The duration is added later, in throttle. There is no this.endTime field to read here.

> 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?

We need "this" on stack before the arguments are loaded in expression which is to be used at the end of the method by putfield

> 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?

Between the time of the enabled() check and this method, the state may change, so it could lead to false positives in testing.

> 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.

I think we can skip it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136217
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135926
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135820
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134807
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134400
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119132932
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136976

From mgronlun at openjdk.org  Sun Jun  1 13:23:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:23:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 557:

> 555:   if (!check_state(jt) ||
> 556:       jt->is_JfrRecorder_thread()) {
> 557:       queue.increment_lost_samples();

is_JfrRecorder_thread() will not appear here since it's excluded and would have returned nullptr from get_java_thread_if_valid().

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 558:

> 556:       jt->is_JfrRecorder_thread()) {
> 557:       queue.increment_lost_samples();
> 558:       tl->set_do_async_processing_of_cpu_time_jfr_requests(false);

Why is this restored here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119142346
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119142510

From jbechberger at openjdk.org  Sun Jun  1 13:43:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 13:43:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>
Message-ID: <DJve2ZIp1xOIaKtcTQXQM3sYintlrZJQWx1oRLTFIDY=.73ad47ec-2d86-4f18-8d9b-4cb1d398b2a8@github.com>

On Sun, 1 Jun 2025 13:19:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 558:
> 
>> 556:       jt->is_JfrRecorder_thread()) {
>> 557:       queue.increment_lost_samples();
>> 558:       tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 
> Why is this restored here?

Because I shouldn't sample if the thread isn't in native state anymore. The thread is probably sampled anyway on the outgoing safepoint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119157906

From mgronlun at openjdk.org  Sun Jun  1 15:07:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:07:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <ZN_PiDKlmt3Y5b62nsc8F4LAvzx6-soxIS8q1I7oe5E=.49f21270-e9c2-45ae-a184-a28045de9ffb@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:

> 360:   drain_enqueued_requests(now, tl, jt, current);
> 361: #ifdef LINUX
> 362:   if (tl->has_cpu_time_jfr_requests()) {

You are having all threads traverse over this lock, even though the cpu time sampler is disabled by default. Can it be improved?

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 604:

> 602: 
> 603: bool JfrThreadLocal::has_cpu_time_jfr_requests() {
> 604:   return Atomic::load(&_has_cpu_time_jfr_requests);

Atomic::load_acquire()

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 620:

> 618: 
> 619: bool JfrThreadLocal::wants_async_processing_of_cpu_time_jfr_requests() {
> 620:   return Atomic::load(&_do_async_processing_of_cpu_time_jfr_requests);

Atomic::load_acquire()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119242319
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119243305
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119243393

From jbechberger at openjdk.org  Sun Jun  1 15:07:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 15:07:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <ZN_PiDKlmt3Y5b62nsc8F4LAvzx6-soxIS8q1I7oe5E=.49f21270-e9c2-45ae-a184-a28045de9ffb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <ZN_PiDKlmt3Y5b62nsc8F4LAvzx6-soxIS8q1I7oe5E=.49f21270-e9c2-45ae-a184-a28045de9ffb@github.com>
Message-ID: <62JxxY-xn3fwz0PnhcnIH6DOWBQUPIq_fhDD_7YrSmA=.bfbb317a-403e-4826-a3ed-c364882e821b@github.com>

On Sun, 1 Jun 2025 15:01:06 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:
> 
>> 360:   drain_enqueued_requests(now, tl, jt, current);
>> 361: #ifdef LINUX
>> 362:   if (tl->has_cpu_time_jfr_requests()) {
> 
> You are having all threads traverse over this lock, even though the cpu time sampler is disabled by default. Can it be improved?

Not without allocating in the signal handler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119243238

From mgronlun at openjdk.org  Sun Jun  1 15:27:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:27:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 332:

> 330:     JavaThread* jt = tlh.list()->thread_at(i);
> 331:     JfrThreadLocal* tl = jt->jfr_thread_local();
> 332:     if (tl != nullptr && tl->wants_async_processing_of_cpu_time_jfr_requests()) {

tl is never nullptr.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 344:

> 342: 
> 343: // equals operator for JfrSampleRequest
> 344: inline bool operator==(const JfrSampleRequest& lhs, const JfrSampleRequest& rhs) {

Can be removed.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 574:

> 572: 
> 573:   if (queue.enqueue(request)) {
> 574:     tl->set_has_cpu_time_jfr_requests(true);

This should only need to be set when enqueuing the first entry.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 581:

> 579: 
> 580:   if (jt->thread_state() == _thread_in_native &&
> 581:       queue.size() > queue.capacity() * 2 / 3) {

Is this logic still valid? You are only asking for a async processing depending on the load factor of the queue?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 586:

> 584:     JfrCPUTimeThreadSampling::trigger_async_processing_of_cpu_time_jfr_requests();
> 585:   } else {
> 586:     tl->set_do_async_processing_of_cpu_time_jfr_requests(false);

Was it true before and needed a reset?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119250661
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119250887
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119248176
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119248824
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119249381

From jbechberger at openjdk.org  Sun Jun  1 15:27:06 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 15:27:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
Message-ID: <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>

On Sun, 1 Jun 2025 15:18:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 574:
> 
>> 572: 
>> 573:   if (queue.enqueue(request)) {
>> 574:     tl->set_has_cpu_time_jfr_requests(true);
> 
> This should only need to be set when enqueuing the first entry.

You're right

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 581:
> 
>> 579: 
>> 580:   if (jt->thread_state() == _thread_in_native &&
>> 581:       queue.size() > queue.capacity() * 2 / 3) {
> 
> Is this logic still valid? You are only asking for a async processing depending on the load factor of the queue?

Yes, so I only start the thread walking if necessary

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119248709
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119250511

From mgronlun at openjdk.org  Sun Jun  1 15:35:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:35:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <GH6dTFPiJ18tIADVnfmghTTdyTpVngHjCeJ5-FZLBGc=.e10c9936-ae8f-4a1a-8a3e-e86828a8e926@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 536:

> 534: }
> 535: 
> 536: volatile size_t count__ = 0;

unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119258988

From jbechberger at openjdk.org  Sun Jun  1 15:39:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 15:39:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <GH6dTFPiJ18tIADVnfmghTTdyTpVngHjCeJ5-FZLBGc=.e10c9936-ae8f-4a1a-8a3e-e86828a8e926@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <GH6dTFPiJ18tIADVnfmghTTdyTpVngHjCeJ5-FZLBGc=.e10c9936-ae8f-4a1a-8a3e-e86828a8e926@github.com>
Message-ID: <6Idy8j9wbNr9udYMhsW0BQmhb8dQvc_p20vCYtg5kZc=.6380eee6-bd1b-45d0-bca8-c8068e59bd36@github.com>

On Sun, 1 Jun 2025 15:32:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 536:
> 
>> 534: }
>> 535: 
>> 536: volatile size_t count__ = 0;
> 
> unused?

Yes.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 586:
> 
>> 584:     JfrCPUTimeThreadSampling::trigger_async_processing_of_cpu_time_jfr_requests();
>> 585:   } else {
>> 586:     tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 
> Was it true before and needed a reset?

I could check this before setting

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119260755
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119261558

From mgronlun at openjdk.org  Sun Jun  1 15:43:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:43:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <66tRvhjE2LrwccsAYmRycS6QLF2KdRg-XHfk-scr-wg=.c7f269f0-301a-4da3-ae54-7f6bc7a440b1@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 587:

> 585: }
> 586: 
> 587: bool JfrThreadLocal::acquire_cpu_time_jfr_native_lock() {

It appears that the lock state 'NATIVE' is redundant; an asynchronous request for queue drainage only requires the dequeue lock state. NATIVE can be removed to simplify the lock protocol.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119268003

From mgronlun at openjdk.org  Sun Jun  1 18:12:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:12:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
Message-ID: <PJG8IRqXcZw2wOgKlNq4-TnPH0eVgwnE-G9a4EXSD04=.4acea933-5451-43eb-86c5-502f5dcbf1ac@github.com>

On Sun, 1 Jun 2025 15:24:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 344:
> 
>> 342: 
>> 343: // equals operator for JfrSampleRequest
>> 344: inline bool operator==(const JfrSampleRequest& lhs, const JfrSampleRequest& rhs) {
> 
> Can be removed.

Unless you still want to try the ljf JfrSampleRequest optimization for the native ljf, which I kind of like now that I understand it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119386104

From mgronlun at openjdk.org  Sun Jun  1 18:13:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:13:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
Message-ID: <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>

On Sun, 1 Jun 2025 15:23:06 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 581:
>> 
>>> 579: 
>>> 580:   if (jt->thread_state() == _thread_in_native &&
>>> 581:       queue.size() > queue.capacity() * 2 / 3) {
>> 
>> Is this logic still valid? You are only asking for async processing assistance depending on the load factor of the queue?
>
> Yes, so I only start the thread walking if necessary

I see. With a bounded queue as used in this solution, it can work quite nicely, that is, if the thread is actually on CPU in native, and just not waiting - if waiting (which is most likely) then pending requests could take a long time to be sent to consumers.

I also understand better the optimization you tried as part of async walk in native and frames. Also quite nice, to walk from the last JfrSampleRequest and do equals to "batch" the top JFR sample requests that are the same (i,.e taken for the ljf). Maybe you can retry that again, but then you need to save the sid AND the tid to be reused for the top equal requests (you only need stacktrace.record_inner() for one request). Its a nice optimization.

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:
>> 
>>> 360:   drain_enqueued_requests(now, tl, jt, current);
>>> 361: #ifdef LINUX
>>> 362:   if (tl->has_cpu_time_jfr_requests()) {
>> 
>> You are having all threads traverse over this test, even though the cpu time sampler is disabled by default. Can it be improved?
>
> Not without allocating in the signal handler

How so?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119385303
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119389715

From mgronlun at openjdk.org  Sun Jun  1 18:25:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:25:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <GxaSY3WuT4Bz_JbcHS9H0b_CyJgBjWWtxrQDqcd80ec=.826e247c-1a11-45ef-967e-6fa617b3cee6@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:

> 248:     }
> 249: 
> 250:     biased = true;

Perhaps set on entry, and only keep the single biased = false below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119396997

From mgronlun at openjdk.org  Sun Jun  1 18:31:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:31:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <GxaSY3WuT4Bz_JbcHS9H0b_CyJgBjWWtxrQDqcd80ec=.826e247c-1a11-45ef-967e-6fa617b3cee6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <GxaSY3WuT4Bz_JbcHS9H0b_CyJgBjWWtxrQDqcd80ec=.826e247c-1a11-45ef-967e-6fa617b3cee6@github.com>
Message-ID: <F-CBr0NN-RfUyFcEAFg5iXYy54V3PYkCITteBLT3ofU=.d67cfd9c-210e-4459-873b-6676b7d98dc5@github.com>

On Sun, 1 Jun 2025 18:22:10 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:
> 
>> 248:     }
>> 249: 
>> 250:     biased = true;
> 
> Perhaps set on entry, and only keep the single biased = false below?

Also, note you have a direct hit in line 221--222 above - it's biased = false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119404072

From mgronlun at openjdk.org  Sun Jun  1 19:05:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:05:53 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: <e6_OvsZFxNg64ypSkFBoDjvls1ijTSSdXgWS0Xx0VTU=.0a41a851-5870-47fd-866b-e52414125574@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 130:

> 128:     }
> 129: 
> 130:     private long amortizedDebt(ThrottlerWindow expired) {

amortizeDept (in the present) - like this is the value we will be using to amortize (in the future)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119457164

From mgronlun at openjdk.org  Sun Jun  1 19:10:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:10: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: <FEIE0-ddPBZ6gsmBek0zuu2lPmoaQLWsz8h-BfMk5fM=.17498c82-6f01-46f6-b22d-1d63a2b011a2@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 148:

> 146:         return nextGeometric(adjustBoundary(projectProbability), randomGenerator.nextDouble());
> 147:     }
> 148:      double projectPopulationSize(ThrottlerWindow expired) {

not private?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119459623

From mgronlun at openjdk.org  Sun Jun  1 19:18:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:18:54 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: <RlRa2RB5v1Qm646gChkE1yYwCT8WcKm10nqp2sdgMVk=.071fc361-fe53-43aa-9eeb-9ae1d62388e4@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 142:

> 140:     private long deriveSamplingInterval(double sampleSize, ThrottlerWindow expired) {
> 141:         double populationSize = projectPopulationSize(expired);
> 142:         if (adjustBoundary(populationSize) <= adjustBoundary(sampleSize)) {

Do you need all these adjustBoundary() calls? It only checks if a double value is 0 or 1. Population and sample sizes will be much larger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119471003

From mgronlun at openjdk.org  Sun Jun  1 19:25:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:25: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: <mldyqnpMWfzVdJXfKIrPjo4IUM4GBepsN-oCqS8ycfU=.9704ab37-e319-4289-ad1f-9e0dde646602@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/ThrottlerWindow.java line 49:

> 47:         measuredPopulationSize.set(0);
> 48:         endTicks = JVM.counterTime() +
> 49:         JVMSupport.nanosToTicks(1_000_000L * parameters.windowDurationMillis);

indent to make it clear it assigns.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119475462

From egahlin at openjdk.org  Sun Jun  1 20:56:50 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 20:56:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@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

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

  Some reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/73943e7a..d0097506

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

  Stats: 10 lines in 3 files changed: 1 ins; 1 del; 8 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 egahlin at openjdk.org  Sun Jun  1 21:10:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 21:10:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
Message-ID: <alGBSpA2d3llrqNVFIf8r5jDHTM517LXhzVO_r5XK3E=.28742e7a-e306-46d4-9533-683fdb8e80a4@github.com>

On Sat, 31 May 2025 21:20:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> 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?

We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.

We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119593028

From egahlin at openjdk.org  Sun Jun  1 21:49:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 21:49:51 GMT
Subject: RFR: 8356698: JFR: @Contextual
In-Reply-To: <Uta6O__bclaGO6dEE-mfCjpStTIyh2ql9m5s3EFWRsw=.24d09dcf-1ece-4b0d-bc8a-8b5b5b634269@github.com>
References: <K1QvEnSd5D3c6-ybeArew0KpF4etzE8e3mgKB8NjTdI=.640a837f-ea43-4c2f-9566-09a015601f11@github.com>
 <Uta6O__bclaGO6dEE-mfCjpStTIyh2ql9m5s3EFWRsw=.24d09dcf-1ece-4b0d-bc8a-8b5b5b634269@github.com>
Message-ID: <15zlaAo42KfRzTTaIwKcXlhLsKeEkQQwQVnBBCWt5eU=.c90b11b8-b4cb-42c1-9c21-8f18bf7fe1b2@github.com>

On Sat, 31 May 2025 18:58:29 GMT, Markus Gr?nlund <mgronlun 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
>
> 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?

I think it can be useful if a contextual GUI is created where users can drill down into tables and see all events that occur during a method call. For example, if you want to troubleshoot a slow login:

    $ java -XX:StartFlightRecording:method-trace=LoginService::login ...

| Context Types
|-----------------------------------
| Order::id
| **MethodTrace::method** (selected)
| Trace::span
| Trace::name                            

|Context Values
|-----------------------------------
| **LoginService::login(String, String)** (selected)


Start Time      | Event Type                   | Duration 
--------------|-----------------------|-------------
20:05:02.45   | jdk.JavaMonitorEnter  |  25 ms
 20:05:03.12  | jdbc.ExecuteQuery      |  2 s

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25249#discussion_r2119629183

From dholmes at openjdk.org  Mon Jun  2 04:35:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 04:35:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

Just some drive-by comments mainly on your acquire/release usage. I'm not at all clear what memory accesses you are trying to coordinate with those.

src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 176:

> 174:   JfrEventSetting::set_enabled(JfrCPUTimeSampleEvent, rate > 0);
> 175:   JfrCPUTimeThreadSampling::set_rate(rate, autoadapt == JNI_TRUE);
> 176:   return JNI_TRUE;

What is the point of having a boolean return type if you always return true?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 59:

> 57:   Thread* raw_thread = Thread::current_or_null_safe();
> 58:   JavaThread* jt;
> 59:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism

Suggestion:

  if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parallelism

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 119:

> 117:   _data = new_data;
> 118:   _capacity = capacity;
> 119: }

I assume there is a lock protecting this so it happens atomically?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 122:

> 120: 
> 121: bool JfrCPUTimeTraceQueue::is_full() const {
> 122:   return Atomic::load_acquire(&_head) >= _capacity;

I don't see why acquire semantics would be needed here. Also how can it be > capacity?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 126:

> 124: 
> 125: bool JfrCPUTimeTraceQueue::is_empty() const {
> 126:   return Atomic::load_acquire(&_head) == 0;

Acquire semantics are definitely not needed here.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 130:

> 128: 
> 129: s4 JfrCPUTimeTraceQueue::lost_samples() const {
> 130:   return Atomic::load_acquire(&_lost_samples);

Again acquire semantics seem highly dubious here - what loads are you synchronizing with?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 139:

> 137: 
> 138: u4 JfrCPUTimeTraceQueue::get_and_reset_lost_samples() {
> 139:   s4 lost_samples = Atomic::load_acquire(&_lost_samples);

Again acquire semantics seem highly dubious here - what loads are you synchronizing with?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 151:

> 149:     set_capacity(capacity);
> 150:   }
> 151: }

Seems an odd definition - typically `ensure_capacity` will grow a data structure to ensure it has sufficient capacity, and if already larger than needed that is fine. Suggestion `change_capacity`, or more traditionally `resize`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 237:

> 235: 
> 236: void JfrCPUTimeThreadSampler::trigger_async_processing_of_cpu_time_jfr_requests() {
> 237:   Atomic::release_store(&_is_async_processing_of_cpu_time_jfr_requests_triggered, true);

What prior stores are you ensuring should be visible by using release semantics here?

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2886627655
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119983062
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119983911
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120016607
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120011705
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120012200
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120014449
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120014541
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120020174
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120021034

From dholmes at openjdk.org  Mon Jun  2 04:35:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 04:35:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <Czq2ZlXAaiBc6IFEwZ4HjHy5JiJ3cSrWdQ8OfDVwCf0=.82a7c7ad-44e0-498d-8a7a-7dd8c0e00a60@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>
 <Czq2ZlXAaiBc6IFEwZ4HjHy5JiJ3cSrWdQ8OfDVwCf0=.82a7c7ad-44e0-498d-8a7a-7dd8c0e00a60@github.com>
Message-ID: <7wOUvZZtjrX3TpgT9JQLm-8qTAax6PrXtfHwMJpNX4M=.13a7c6cc-e037-4108-b392-7ff30d279c05@github.com>

On Mon, 26 May 2025 06:29:03 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Also, is raw_thread == nullptr even possible? For the same reasons.
>
> `!raw_thread->is_Java_thread()` I found it during testing.

What thread was it, and how did it reach this code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119984783

From kbarrett at openjdk.org  Mon Jun  2 05:48:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 2 Jun 2025 05:48:59 GMT
Subject: RFR: 8358205: Remove unused JFR array allocation code
In-Reply-To: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
References: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
Message-ID: <iWTEjYP4K_zFpxQSNPXWhABHrzJUIrd3QxIRkc6WLZY=.51e3dd0f-57ce-42c5-800d-adecec9a7a0a@github.com>

On Fri, 30 May 2025 18:10:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The JFR code is using ObjArray->allocate() directly rather than going through oopFactory.  In Valhalla, the oopFactory code is being changed to account for new array shapes and attributes, so all code should call that instead.  Turns out this function is unused, so this change removes it.  Tested with tier1-7 with a ShouldNotReachHere(), then jdk/jfr tests with the removal.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25553#pullrequestreview-2886834584

From jbechberger at openjdk.org  Mon Jun  2 08:44:01 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:44:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <uywTbPrvFb9SBmQLpDMleEV0RC8q34PCf5UA-mtW58s=.0cd920f6-c263-46dc-a01f-3692354906d4@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <uywTbPrvFb9SBmQLpDMleEV0RC8q34PCf5UA-mtW58s=.0cd920f6-c263-46dc-a01f-3692354906d4@github.com>
Message-ID: <yE-WI5e9DNtoD4z_3cQ3nwU-IjXjmN_Ea19CfTqUDRE=.cfa23e87-ce78-4dcb-9638-7f6ffac97c03@github.com>

On Sun, 1 Jun 2025 13:01:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> 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 threads that are in native state (and requested to be sampled)
> 
> We are not really "sampling", but processing their queues, no?

You're correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120450563

From jbechberger at openjdk.org  Mon Jun  2 08:47:01 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:47:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>
Message-ID: <3d549Fxkhzd6v0fAVFEBOcxZ7hBKI1ZAUafLClp7Npw=.70183618-7dbf-4e05-bcc8-fd1216741c66@github.com>

On Sun, 1 Jun 2025 13:05:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 367:
> 
>> 365:     JfrCPUTimeSampleRequest& request = queue.at(i);
>> 366:     JfrStackTrace stacktrace;
>> 367:     traceid tid = JfrThreadLocal::thread_id(thread);
> 
> Check the tid as a function of the JfrSampleRequest, like we do in JFR Cooperative Sampling.

You mean ` const traceid tid = in_continuation ? tl->vthread_id_with_epoch_update(jt) : JfrThreadLocal::jvm_thread_id(jt);`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120458307

From jbechberger at openjdk.org  Mon Jun  2 08:53:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:53:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <3d549Fxkhzd6v0fAVFEBOcxZ7hBKI1ZAUafLClp7Npw=.70183618-7dbf-4e05-bcc8-fd1216741c66@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>
 <3d549Fxkhzd6v0fAVFEBOcxZ7hBKI1ZAUafLClp7Npw=.70183618-7dbf-4e05-bcc8-fd1216741c66@github.com>
Message-ID: <DWN-Va0XnzSIlWA4adYve6dRuQgW7QZcZnmlDUmW0ys=.b293bff9-7121-4a96-b5c6-ca9d980f948c@github.com>

On Mon, 2 Jun 2025 08:44:01 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 367:
>> 
>>> 365:     JfrCPUTimeSampleRequest& request = queue.at(i);
>>> 366:     JfrStackTrace stacktrace;
>>> 367:     traceid tid = JfrThreadLocal::thread_id(thread);
>> 
>> Check the tid as a function of the JfrSampleRequest, like we do in JFR Cooperative Sampling.
>
> You mean ` const traceid tid = in_continuation ? tl->vthread_id_with_epoch_update(jt) : JfrThreadLocal::jvm_thread_id(jt);`?

I implemented this in this function now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120473792

From jbechberger at openjdk.org  Mon Jun  2 08:57:04 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:57:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <DJve2ZIp1xOIaKtcTQXQM3sYintlrZJQWx1oRLTFIDY=.73ad47ec-2d86-4f18-8d9b-4cb1d398b2a8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>
 <DJve2ZIp1xOIaKtcTQXQM3sYintlrZJQWx1oRLTFIDY=.73ad47ec-2d86-4f18-8d9b-4cb1d398b2a8@github.com>
Message-ID: <rNihgxVesNTYLgvhEpoOHiDkGJYkyb0Fqw2O1JrcDFM=.7c641eca-9381-4286-b47c-d85d1814c7d3@github.com>

On Sun, 1 Jun 2025 13:41:44 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 558:
>> 
>>> 556:       jt->is_JfrRecorder_thread()) {
>>> 557:       queue.increment_lost_samples();
>>> 558:       tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
>> 
>> Why is this restored here?
>
> Because I shouldn't sample if the thread isn't in native state anymore. The thread is probably sampled anyway on the outgoing safepoint.

But you might be right, I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120481274

From jbechberger at openjdk.org  Mon Jun  2 09:01:05 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:01:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
Message-ID: <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>

On Sun, 1 Jun 2025 18:10:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Not without allocating in the signal handler
>
> How so?

Because we need to add the threads from the signal handler. So any kind of growing array or set would not work, especially if we want to remove the threads from within the signal handler again.

This is certainly an area of future optimization, albeit this doesn't seem to have any measurable performance impact in my renaissance benchmark runs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120492743

From vyazici at openjdk.org  Mon Jun  2 09:02:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 09:02:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
Message-ID: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>

On Sun, 1 Jun 2025 20:56:50 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
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some reviewer feedback

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:

> 28: import java.util.concurrent.locks.ReentrantLock;
> 29: import jdk.jfr.internal.PlatformEventType;
> 30: public final class Throttler {

**Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.

Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we

- Revamp the JavaDoc and document the used algorithm?
- Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)

### References

- Resilience4j:
  - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
  - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
- Guava:
  - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
  - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120496703

From jbechberger at openjdk.org  Mon Jun  2 09:05:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:05:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
Message-ID: <kjtklorYzkvVeGAK8ei4bmKWxHn-r66MkW06sLNLdKM=.dcd25136-5252-4389-b292-f9aa98f0350d@github.com>

On Sun, 1 Jun 2025 18:00:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Yes, so I only start the thread walking if necessary
>
> I see. With a bounded queue as used in this solution, it can work quite nicely, that is, if the thread is actually on CPU in native, and just not waiting - if waiting (which is most likely) then pending requests could take a long time to be sent to consumers.
> 
> I also understand better the optimization you tried as part of async walk in native and frames. Also quite nice, to walk from the last JfrSampleRequest and do equals to "batch" the top JFR sample requests that are the same (i,.e taken for the ljf). Maybe you can retry that again, but then you need to save the sid AND the tid to be reused for the top equal requests (you only need stacktrace.record_inner() for one request). Its a nice optimization.

The problem is when in between queue processing a new JFR chunk is started. This caused problems before.

I would leave these kinds of optimizations for later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120501728

From jbechberger at openjdk.org  Mon Jun  2 09:09:04 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:09:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <PJG8IRqXcZw2wOgKlNq4-TnPH0eVgwnE-G9a4EXSD04=.4acea933-5451-43eb-86c5-502f5dcbf1ac@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <PJG8IRqXcZw2wOgKlNq4-TnPH0eVgwnE-G9a4EXSD04=.4acea933-5451-43eb-86c5-502f5dcbf1ac@github.com>
Message-ID: <lt-zhwrdlz61ZYE6mh4kkVmo-M49cFGu0TrtwiFCl5c=.1bab99e5-1f59-4862-9af0-0b0c237c59b0@github.com>

On Sun, 1 Jun 2025 18:03:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 344:
>> 
>>> 342: 
>>> 343: // equals operator for JfrSampleRequest
>>> 344: inline bool operator==(const JfrSampleRequest& lhs, const JfrSampleRequest& rhs) {
>> 
>> Can be removed.
>
> Unless you still want to try the ljf JfrSampleRequest optimization for the native ljf, which I kind of like now that I understand it.

As I said, it's a great optimization. But it needs some work. I therefore remove this method for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120511048

From jbechberger at openjdk.org  Mon Jun  2 09:28:01 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:28:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>
Message-ID: <rtV4SDWYrn4P64uGvC5yAw_8qzeCUMeOwz7Ly7I9EZA=.32e3ceba-ff3d-42f1-aa0f-3e60606ad03f@github.com>

On Mon, 2 Jun 2025 04:28:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 119:
> 
>> 117:   _data = new_data;
>> 118:   _capacity = capacity;
>> 119: }
> 
> I assume there is a lock protecting this so it happens atomically?

This happens before the signal handler is attached to thread. So it does happen before any parallelism is introduced on thread creation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120557327

From egahlin at openjdk.org  Mon Jun  2 10:02:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 2 Jun 2025 10:02:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
 <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
Message-ID: <Vm8I6uPuFb9c9HvLs2k2AlmzzND58RLMNQSzaUJtIdY=.ed8d5612-b376-4ff3-9335-7286d5f1423c@github.com>

On Mon, 2 Jun 2025 08:59:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:
> 
>> 28: import java.util.concurrent.locks.ReentrantLock;
>> 29: import jdk.jfr.internal.PlatformEventType;
>> 30: public final class Throttler {
> 
> **Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.
> 
> Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we
> 
> - Revamp the JavaDoc and document the used algorithm?
> - Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)
> 
> ### References
> 
> - Resilience4j:
>   - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
>   - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
> - Guava:
>   - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
>   - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

I don't think we want to write the algorithm in the specification. It would make it harder for us to make adjustments in the future. The contract is x events per time unit without details on how JFR adapts the sampling. The algorithm is the same one used by the jdk.ObjectAllocationSample event, which has been in use since JDK 16, but implemented in native code and with a gtest:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/support/jfrAdaptiveSampler.cpp
 
The code in the PR is a method per method port of that code. It's hard to write stable tests that include timestamps. We have tried that in the past for other settings/events, but it only resulted in false positives.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120643350

From mgronlun at openjdk.org  Mon Jun  2 10:08:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 10:08:52 GMT
Subject: RFR: 8356698: JFR: @Contextual
In-Reply-To: <15zlaAo42KfRzTTaIwKcXlhLsKeEkQQwQVnBBCWt5eU=.c90b11b8-b4cb-42c1-9c21-8f18bf7fe1b2@github.com>
References: <K1QvEnSd5D3c6-ybeArew0KpF4etzE8e3mgKB8NjTdI=.640a837f-ea43-4c2f-9566-09a015601f11@github.com>
 <Uta6O__bclaGO6dEE-mfCjpStTIyh2ql9m5s3EFWRsw=.24d09dcf-1ece-4b0d-bc8a-8b5b5b634269@github.com>
 <15zlaAo42KfRzTTaIwKcXlhLsKeEkQQwQVnBBCWt5eU=.c90b11b8-b4cb-42c1-9c21-8f18bf7fe1b2@github.com>
Message-ID: <WRwhhewPpZbVvpAalh3luskqxt4-qk3cmnY49jQ7It0=.84be18ee-2425-4b21-b0e8-a4c17ba2c662@github.com>

On Sun, 1 Jun 2025 21:46:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I think it can be useful if a contextual GUI is created where users can drill down into tables and see all events that occur during a method call. For example, if you want to troubleshoot a slow login:
> 
> ```
> $ java -XX:StartFlightRecording:method-trace=LoginService::login ...
> ```
> 
> Context Types
> Order::id
> **MethodTrace::method** (selected)
> Trace::id
> Trace::name
> Start Time 	Duration 	Context Values
> 20:05:02.10 	5.0 s 	**LoginService::login(String, String)** (selected)
> 20:05:08.10 	80 ms 	**LoginService::login(String, String)**
> 20:05:10.10 	75 ms 	**LoginService::login(String, String)**
> Start Time 	Event Name 	Duration
> 20:05:02.45 	Java Monitor Enter 	25 ms
> 20:05:03.12 	JDBC Execute Query 	4.7 s
> 
> or some other known aspect of the program that has been problematic in the past and now have been annotated, for example:
> 
> ```
> $ java -XX:StartFlightRecording:method-trace=@com.example.UpdateOrder ...
> ```

I could not agree more.

A GUI picking up these innovations, making them conveniently accessible and easily understandable to the end user would be fantastic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25249#discussion_r2120658143

From mgronlun at openjdk.org  Mon Jun  2 10:14:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 10:14:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
 <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
Message-ID: <nh7gTI3xUYTtMZigep1TusR2Pzu1QSdZ-zYjoMA00fs=.2ba97d70-8644-4975-8df0-96af982fc49c@github.com>

On Sun, 1 Jun 2025 13:07:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> 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).
>
> I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

No big deal, we can look into the details later.

>> 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?
>
> We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.
> 
> We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

No big deal, we can look into this later if the need arises.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120675164
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120676832

From mgronlun at openjdk.org  Mon Jun  2 10:21:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 10:21:50 GMT
Subject: RFR: 8358205: Remove unused JFR array allocation code
In-Reply-To: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
References: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
Message-ID: <ul1CxZQnym1uQJF2GvgTQ_s07pugdCEgIOZ2wmsIZYo=.fb15cba2-be64-4068-9f3e-8be48ef0678c@github.com>

On Fri, 30 May 2025 18:10:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The JFR code is using ObjArray->allocate() directly rather than going through oopFactory.  In Valhalla, the oopFactory code is being changed to account for new array shapes and attributes, so all code should call that instead.  Turns out this function is unused, so this change removes it.  Tested with tier1-7 with a ShouldNotReachHere(), then jdk/jfr tests with the removal.

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25553#pullrequestreview-2887708018

From shade at openjdk.org  Mon Jun  2 11:25:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 11:25:36 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization
Message-ID: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>

Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `jdk_jfr`

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

Commit messages:
 - Fix

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

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

From mgronlun at openjdk.org  Mon Jun  2 11:26:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:26:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
Message-ID: <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>

On Mon, 2 Jun 2025 08:58:28 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> How so?
>
> Because we need to add the threads from the signal handler. So any kind of growing array or set would not work, especially if we want to remove the threads from within the signal handler again.
> 
> This is certainly an area of future optimization, albeit this doesn't seem to have any measurable performance impact in my renaissance benchmark runs.

I don't understand what allocation has to do with anything. I'm talking about code branch layout to avoid having to test "has_cpu_time_jfr_requests()" when we know it will be false by default.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120846868

From mgronlun at openjdk.org  Mon Jun  2 11:28:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:28:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <kjtklorYzkvVeGAK8ei4bmKWxHn-r66MkW06sLNLdKM=.dcd25136-5252-4389-b292-f9aa98f0350d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <kjtklorYzkvVeGAK8ei4bmKWxHn-r66MkW06sLNLdKM=.dcd25136-5252-4389-b292-f9aa98f0350d@github.com>
Message-ID: <7Cy88EZJj1ZgHXaAoCY9m1PnB6UAGDJxgK9PI3BVYBQ=.a4fbad7a-19fa-4e1e-999e-8773d2fd7fb1@github.com>

On Mon, 2 Jun 2025 09:02:05 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I see. With a bounded queue as used in this solution, it can work quite nicely, that is, if the thread is actually on CPU in native, and just not waiting - if waiting (which is most likely) then pending requests could take a long time to be sent to consumers.
>> 
>> I also understand better the optimization you tried as part of async walk in native and frames. Also quite nice, to walk from the last JfrSampleRequest and do equals to "batch" the top JFR sample requests that are the same (i,.e taken for the ljf). Maybe you can retry that again, but then you need to save the sid AND the tid to be reused for the top equal requests (you only need stacktrace.record_inner() for one request). Its a nice optimization.
>
> The problem is when in between queue processing a new JFR chunk is started. This caused problems before.
> 
> I would leave these kinds of optimizations for later.

Then I would recommend you drain immediately when the thread is in native, not waiting for the queue to fill up to 2/3. The reason is because the solution is based on CPU time samples and most threads that are _thread_in_native are waiting (i.e. they will not get their queues filled while in native).

I would recommend dropping the second clause about testing the queue size altogether.

That way you will not get threads stuck with a lot of events a long time in native, not being delivered.

Revive it later when you begin to attack the optimizations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120855119

From jbechberger at openjdk.org  Mon Jun  2 11:32:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:32:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@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:

 - Tiny fixes
 - Minor changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/439763a3..6a83d759

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

  Stats: 90 lines in 9 files changed: 24 ins; 29 del; 37 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 Jun  2 11:40:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:40:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
 <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
Message-ID: <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>

On Mon, 2 Jun 2025 11:22:45 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Because we need to add the threads from the signal handler. So any kind of growing array or set would not work, especially if we want to remove the threads from within the signal handler again.
>> 
>> This is certainly an area of future optimization, albeit this doesn't seem to have any measurable performance impact in my renaissance benchmark runs.
>
> I don't understand what allocation has to do with anything. I'm talking about code branch layout to avoid having to test "has_cpu_time_jfr_requests()" when we know it will be false by default.

Ah. Sorry. Is it about reading the atomic boolean flag again?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120882396

From mgronlun at openjdk.org  Mon Jun  2 11:40:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:40:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
Message-ID: <yws6UutVipWNH_X-1TlXn5fdStmMPVwYPHoQ08i50yU=.a1be8704-fa72-4e42-b659-8c8d5a820905@github.com>

On Mon, 2 Jun 2025 11:32:27 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 two additional commits since the last revision:
> 
>  - Tiny fixes
>  - Minor changes

src/hotspot/share/runtime/thread.hpp line 59:

> 57: class SafeThreadsListPtr;
> 58: class ThreadClosure;
> 59: class ThreadCrashProtection;

Should not be needed.

src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java line 276:

> 274:      * Set the maximum event emission rate for the CPU time sampler
> 275:      *
> 276:      * Setting rate to 0 turns off the CPU time method sampler.

"CPU time method sampler" -> "CPU time sampler"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120878701
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120882161

From egahlin at openjdk.org  Mon Jun  2 11:46:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 2 Jun 2025 11:46:53 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization
In-Reply-To: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
Message-ID: <Iiz619VeZWMB-Op2R7qAbp8eWetwlDLCtqUY7_cBYOQ=.c3bc9db6-d50d-4ee7-b408-5a371884ee64@github.com>

On Mon, 2 Jun 2025 11:19:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

All event settings modifications happen with the "metadata" lock, so only one thread at a time can modify the state in MethodSetting. I think it's sufficient to remove volatile in that class. It's misleading. 

See:
https://github.com/openjdk/jdk/blob/83cb0c6de5988de526545d0926c2c6ef60efc1c7/src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java#L225

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

PR Comment: https://git.openjdk.org/jdk/pull/25584#issuecomment-2930235431

From jbechberger at openjdk.org  Mon Jun  2 11:51:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:51:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v28]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <sVaHpNMgf-TsfTtdtJxjTnuDOwh7mXSpyFlmRarJbm0=.b39f6f38-73ea-433d-bab4-73cf82bae3a3@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 three additional commits since the last revision:

 - Remove header includes
 - Always trigger async processing
 - Remove one atomic read

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/6a83d759..e482ad37

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

  Stats: 21 lines in 6 files changed: 3 ins; 6 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 mgronlun at openjdk.org  Mon Jun  2 11:51:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:51:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
Message-ID: <XvGb3wmX32U98zV_WzO_f4t2TOKE8BvWTzGruWNMEpM=.0d58117a-c8ff-4f24-aea4-ead1a707abde@github.com>

On Mon, 2 Jun 2025 11:32:27 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 two additional commits since the last revision:
> 
>  - Tiny fixes
>  - Minor changes

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 35:

> 33: 
> 34: #include "jfr/recorder/jfrRecorder.hpp"
> 35: #include "jfr/recorder/service/jfrRecorderService.hpp"

The two includes above are not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120890097

From mgronlun at openjdk.org  Mon Jun  2 11:51:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:51:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
 <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
 <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>
Message-ID: <TehCtTdgnEpUSwB-Uzu9sLEY8IogJy0CU9iPfWN8lzw=.c1cfb727-5b39-4a89-8c7e-97b0a8a0df0b@github.com>

On Mon, 2 Jun 2025 11:37:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I don't understand what allocation has to do with anything. I'm talking about code branch layout to avoid having to test "has_cpu_time_jfr_requests()" when we know it will be false by default.
>
> Ah. Sorry. Is it about reading the atomic boolean flag again?

Right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120897042

From jbechberger at openjdk.org  Mon Jun  2 11:51:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:51:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <TehCtTdgnEpUSwB-Uzu9sLEY8IogJy0CU9iPfWN8lzw=.c1cfb727-5b39-4a89-8c7e-97b0a8a0df0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
 <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
 <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>
 <TehCtTdgnEpUSwB-Uzu9sLEY8IogJy0CU9iPfWN8lzw=.c1cfb727-5b39-4a89-8c7e-97b0a8a0df0b@github.com>
Message-ID: <ypAajeBnvOXtI7KLkPb7CXV1cK982tqyo4ZduXD6cVg=.a58b69a3-3045-4070-b500-cd22dc97cb31@github.com>

On Mon, 2 Jun 2025 11:43:54 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Ah. Sorry. Is it about reading the atomic boolean flag again?
>
> Right.

I pass it through now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120906973

From coleenp at openjdk.org  Mon Jun  2 11:54:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Jun 2025 11:54:00 GMT
Subject: RFR: 8358205: Remove unused JFR array allocation code
In-Reply-To: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
References: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
Message-ID: <ofSrLyqFCA76lyA96ZDIzdFxX7AJHgygm3z6m7uurXY=.3dd52157-d571-4653-80b5-40a25bdbdb31@github.com>

On Fri, 30 May 2025 18:10:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The JFR code is using ObjArray->allocate() directly rather than going through oopFactory.  In Valhalla, the oopFactory code is being changed to account for new array shapes and attributes, so all code should call that instead.  Turns out this function is unused, so this change removes it.  Tested with tier1-7 with a ShouldNotReachHere(), then jdk/jfr tests with the removal.

Thank you for reviewing, Kim and Markus.

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

PR Comment: https://git.openjdk.org/jdk/pull/25553#issuecomment-2930287718

From coleenp at openjdk.org  Mon Jun  2 11:54:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Jun 2025 11:54:00 GMT
Subject: Integrated: 8358205: Remove unused JFR array allocation code
In-Reply-To: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
References: <4iPujAp0lL_pVhcjlfMX42dIqE7Aw5X8FZr2k5cSFGo=.139bdd20-c798-4335-9ebd-cf0748e7d339@github.com>
Message-ID: <W9s_nse3BG6I6Ay_kfu0fCwDZC_bLaM0uRq85iCHBGc=.bcf2535c-0fe7-4c25-aa3e-95fd14c3c703@github.com>

On Fri, 30 May 2025 18:10:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The JFR code is using ObjArray->allocate() directly rather than going through oopFactory.  In Valhalla, the oopFactory code is being changed to account for new array shapes and attributes, so all code should call that instead.  Turns out this function is unused, so this change removes it.  Tested with tier1-7 with a ShouldNotReachHere(), then jdk/jfr tests with the removal.

This pull request has now been integrated.

Changeset: c22af0c2
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c22af0c29ea89857c5cf57dd127b5c739130b2f1
Stats:     50 lines in 5 files changed: 0 ins; 45 del; 5 mod

8358205: Remove unused JFR array allocation code

Reviewed-by: kbarrett, mgronlun

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

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

From shade at openjdk.org  Mon Jun  2 11:55:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 11:55:51 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization
In-Reply-To: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
Message-ID: <GiQbAbk7y05FpxfY4KOOYyC6iy9VYxmRiO-3KcnmgYU=.b1b7bf63-c320-4fec-ab92-30e33a55406a@github.com>

On Mon, 2 Jun 2025 11:19:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

Ah, cool, so no bug. I still think it is cleaner to do `PlatformTracer.ensureInitialized()`. I can drop the locking/volatile from there, if you think that is unnecessary. I'd prefer to keep it multi-thread safe to avoid future accidents, though.

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

PR Comment: https://git.openjdk.org/jdk/pull/25584#issuecomment-2930310946

From erwan.viollet at gmail.com  Mon Jun  2 13:30:19 2025
From: erwan.viollet at gmail.com (Erwan Viollet)
Date: Mon, 2 Jun 2025 15:30:19 +0200
Subject: JFR: Scrubbing sensitive information from events
Message-ID: <CACX82zeW1sQRHAYZW52GLtWczKVAt=Q5_=arHHSnYRKz_QXOmg@mail.gmail.com>

Hello,

I am currently looking into how to remove sensitive information from JFR
events. The main events that typically contain sensitive information:
jdk.SystemProcess,  jdk.InitialSystemProperty, jdk.JVMInformation.
Passwords from command lines can typically be found in these events.

Dropping these events altogether is not ideal, as we need them to make
relevant performance recommendations to users (e.g. suggesting JVM or
system setting adjustments).

Dropping them or scrubbing them on the backend side (after the fact)
requires decompressing and re-writing these events, which is wasteful in
terms of both compute and storage. The approach is not perfect, as we still
end up intaking and temporarily storing sensitive information.

Ideally, we would like to be able to scrub or redact only the sensitive
fields within these events (for example, using a simple regex or
pattern-based rule), rather than dropping the whole event. We also want to
avoid handling this only after the event has already been written to the
JFR file, as that does not fully mitigate the risk of exposing sensitive
data.

At present, it appears there is no public API or supported mechanism to
intercept or scrub JFR events in-process, before they are persisted. What
would you think of an API accepting custom scrubbing patterns so that
sensitive data never leaves the JVM in an unredacted state?

Are there any plans or discussions in this area? I am fairly new to the JFR
world, so it is likely that I missed previous discussions around this.

Thank you, Best regards,

Erwan Viollet,

Profiling team, Datadog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250602/7e80ff7a/attachment.htm>

From jbechberger at openjdk.org  Mon Jun  2 13:50:49 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 13:50:49 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@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 bug related to async stack walking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/e482ad37..09ca4fed

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

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 Jun  2 14:52:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 14:52:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <JE0Ncb1yoA_5a1zaUVn9lFW7aWNyJUrqcHLhCdtu-ws=.c1e6fdee-2017-49ad-bf4c-a2c8f7e5c3fd@github.com>

On Mon, 2 Jun 2025 13:50:49 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 bug related to async stack walking

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 349:

> 347:   const frame top_frame = thread->last_frame();
> 348:   bool in_continuation = is_in_continuation(top_frame, thread);
> 349:   for (u4 i = 0; i < queue.size(); i++) {

Realized this drainage is entirely wrong!

You are not using the sample requests in the queue to build individual stack traces for events; instead, you are using the same top frame (the last Java frame) for all of them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121391177

From mgronlun at openjdk.org  Mon Jun  2 15:04:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:04:12 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>

On Mon, 2 Jun 2025 13:50:49 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 bug related to async stack walking

src/hotspot/share/jfr/jfr.inline.hpp line 41:

> 39: inline void Jfr::check_and_process_sample_request(JavaThread* jt) {
> 40:   JfrThreadLocal* tl = jt->jfr_thread_local();
> 41:   bool has_cpu_time_sample_request = tl->has_cpu_time_jfr_requests();

Why this change?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 191:

> 189:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
> 190: 
> 191:   // process the queues for all threads that are in native state (and requested to be sampled)

"requested to be processed" I guess.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 270:

> 268: void JfrCPUTimeThreadSampler::enroll() {
> 269:   if (Atomic::cmpxchg(&_disenrolled, true, false)) {
> 270:     log_info(jfr)("Enrolling CPU thread sampler");

log_trace, please.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 279:

> 277: void JfrCPUTimeThreadSampler::disenroll() {
> 278:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
> 279:     log_info(jfr)("Disenrolling CPU thread sampler");

log_trace, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121414317
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121416556
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121426574
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121428073

From jbechberger at openjdk.org  Mon Jun  2 15:04:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 15:04:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
Message-ID: <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>

On Mon, 2 Jun 2025 14:57: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:
>> 
>>   Fix bug related to async stack walking
>
> src/hotspot/share/jfr/jfr.inline.hpp line 41:
> 
>> 39: inline void Jfr::check_and_process_sample_request(JavaThread* jt) {
>> 40:   JfrThreadLocal* tl = jt->jfr_thread_local();
>> 41:   bool has_cpu_time_sample_request = tl->has_cpu_time_jfr_requests();
> 
> Why this change?

So I don't read the ` tl->has_cpu_time_jfr_requests()` twice on the hot-path

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 349:
> 
>> 347:   const frame top_frame = thread->last_frame();
>> 348:   bool in_continuation = is_in_continuation(top_frame, thread);
>> 349:   for (u4 i = 0; i < queue.size(); i++) {
> 
> Realized this drainage is entirely wrong!
> 
> You are not using the sample requests in the queue to build individual stack traces for events; instead, you are using the same top frame (the last Java frame) for all of them.

Can I export compute_top_frame and use it here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121424752
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121413413

From jbechberger at openjdk.org  Mon Jun  2 15:04:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 15:04:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
Message-ID: <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>

On Mon, 2 Jun 2025 14:57:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 349:
>> 
>>> 347:   const frame top_frame = thread->last_frame();
>>> 348:   bool in_continuation = is_in_continuation(top_frame, thread);
>>> 349:   for (u4 i = 0; i < queue.size(); i++) {
>> 
>> Realized this drainage is entirely wrong!
>> 
>> You are not using the sample requests in the queue to build individual stack traces for events; instead, you are using the same top frame (the last Java frame) for all of them.
>
> Can I export compute_top_frame and use it here?

Or just create a `Jfr::drain_cpu_time_queue` method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121426469

From mgronlun at openjdk.org  Mon Jun  2 15:12:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:12:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>
Message-ID: <_CAWRT6nKdljf9SDRnD-SfdXP9L9S6Y9f6I1nGB-4q8=.eb524157-7c00-4f01-8d8a-9e9c60ef4dc7@github.com>

On Mon, 2 Jun 2025 15:01:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Can I export compute_top_frame and use it here?
>
> Or just create a `Jfr::drain_cpu_time_queue` method?

Try to move the entire:

void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
}

Into JfrThreadSampling.hpp / jfrThreadSampling.cpp - you can send your JfrCPUTimeThreadSampler events from there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121456081

From mgronlun at openjdk.org  Mon Jun  2 15:18:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:18:11 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
Message-ID: <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>

On Mon, 2 Jun 2025 15:01:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/jfr.inline.hpp line 41:
>> 
>>> 39: inline void Jfr::check_and_process_sample_request(JavaThread* jt) {
>>> 40:   JfrThreadLocal* tl = jt->jfr_thread_local();
>>> 41:   bool has_cpu_time_sample_request = tl->has_cpu_time_jfr_requests();
>> 
>> Why this change?
>
> So I don't read the ` tl->has_cpu_time_jfr_requests()` twice on the hot-path

Ok, for now. We should try to come up with a better split.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121466027

From mgronlun at openjdk.org  Mon Jun  2 15:18:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:18:12 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <_CAWRT6nKdljf9SDRnD-SfdXP9L9S6Y9f6I1nGB-4q8=.eb524157-7c00-4f01-8d8a-9e9c60ef4dc7@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>
 <_CAWRT6nKdljf9SDRnD-SfdXP9L9S6Y9f6I1nGB-4q8=.eb524157-7c00-4f01-8d8a-9e9c60ef4dc7@github.com>
Message-ID: <mRMihpPCAq3lvDOb829eLp10INBukJWfmkaz8ThDpys=.762d9537-ac30-4593-887a-789ca2271171@github.com>

On Mon, 2 Jun 2025 15:09:30 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Or just create a `Jfr::drain_cpu_time_queue` method?
>
> Try to move the entire:
> 
> void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
> }
> 
> Into JfrThreadSampling.hpp / jfrThreadSampling.cpp - you can send your JfrCPUTimeThreadSampler events from there.

Of course, rename the routine to something appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121469433

From mgronlun at openjdk.org  Mon Jun  2 15:22:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:22:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <k_yXvVRs4Ra9lD64Kkl4VNKm4puJ_ME5wW5QqkSgsI8=.644fe3a9-df4f-4e89-9dc4-60ed256a2a45@github.com>

On Mon, 2 Jun 2025 13:50:49 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 bug related to async stack walking

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:

> 248:       break;
> 249:     } else {
> 250:       biased = false;

Not correct. There is a top_frame = *current - >biased = true below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121482514

From liach at openjdk.org  Mon Jun  2 15:30:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 15:30:54 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization
In-Reply-To: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
Message-ID: <z78H6Cw8M6dDkVwKAMzVmtmxhjgzo7xrzR6b8RX8Dpw=.5b229769-733d-4911-8722-5b1c1341dc5c@github.com>

On Mon, 2 Jun 2025 11:19:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java line 49:

> 47:  */
> 48: public final class PlatformTracer {
> 49:     private static volatile boolean INITIALIZED;

Can we make this a static final field in a holder class, so we call `PlatformTracer::initialize` from that holder class's `<clinit>`, and after initialization, the check to `INITIALIZED` field can be constant-folded instead of being a volatile read?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25584#discussion_r2121506115

From shade at openjdk.org  Mon Jun  2 15:51:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 15:51:50 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization
In-Reply-To: <z78H6Cw8M6dDkVwKAMzVmtmxhjgzo7xrzR6b8RX8Dpw=.5b229769-733d-4911-8722-5b1c1341dc5c@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
 <z78H6Cw8M6dDkVwKAMzVmtmxhjgzo7xrzR6b8RX8Dpw=.5b229769-733d-4911-8722-5b1c1341dc5c@github.com>
Message-ID: <qUniJYLnZXZE3HqJY0fZrlCOiiSgrkVbjPYq06dl2Ew=.069d28fb-a629-483a-9aa4-e81303cdf683@github.com>

On Mon, 2 Jun 2025 15:27:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/PlatformTracer.java line 49:
> 
>> 47:  */
>> 48: public final class PlatformTracer {
>> 49:     private static volatile boolean INITIALIZED;
> 
> Can we make this a static final field in a holder class, so we call `PlatformTracer::initialize` from that holder class's `<clinit>`, and after initialization, the check to `INITIALIZED` field can be constant-folded instead of being a volatile read?

As @egahlin mentions, it might be unnecessary, as this code is supposed to run in single-thread mode, and we do not need `volatile` at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25584#discussion_r2121565935

From shade at openjdk.org  Mon Jun  2 17:28:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 17:28:32 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization [v2]
In-Reply-To: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
Message-ID: <Yx6oef8XSMKm_Uc6sQ_oMD-VGgB1x8lQfo5hrTQiotI=.b4d77560-ee4d-4870-a30b-9f7b62c90043@github.com>

> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Unsynchronized fix
 - Merge branch 'master' into JDK-8358318-jfr-platform-tracer-init
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25584/files
  - new: https://git.openjdk.org/jdk/pull/25584/files/b5635420..0d8c05a1

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

  Stats: 534 lines in 32 files changed: 309 ins; 146 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/25584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25584/head:pull/25584

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

From mgronlun at openjdk.org  Mon Jun  2 17:29:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 17:29:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <ymnpsQsW76ZANo1bwt3TVupaDCc1J7MmBfE2zHDOrhY=.c6ab6614-89b3-4b12-8bf8-db880007e751@github.com>

On Mon, 2 Jun 2025 13:50:49 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 bug related to async stack walking

src/hotspot/share/memory/resourceArea.hpp line 46:

> 44: // A ResourceArea is an Arena that supports safe usage of ResourceMark.
> 45: class ResourceArea: public Arena {
> 46: 

Changes in this file are unrelated, so revert this entire file.

src/hotspot/share/prims/forte.cpp line 575:

> 573: extern "C" {
> 574: JNIEXPORT
> 575: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) {

Unrelated changes, please revert file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121757461
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121757998

From shade at openjdk.org  Mon Jun  2 17:28:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 17:28:32 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization
In-Reply-To: <Iiz619VeZWMB-Op2R7qAbp8eWetwlDLCtqUY7_cBYOQ=.c3bc9db6-d50d-4ee7-b408-5a371884ee64@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
 <Iiz619VeZWMB-Op2R7qAbp8eWetwlDLCtqUY7_cBYOQ=.c3bc9db6-d50d-4ee7-b408-5a371884ee64@github.com>
Message-ID: <TFMljE6mUJe7NFUtpnARJNCic_CN_9NjIvL7eD8DRzI=.cd8d27de-4cad-4295-b5b2-7568430046e8@github.com>

On Mon, 2 Jun 2025 11:42:11 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> All event settings modifications happen with the "metadata" lock, so only one thread at a time can modify the state in MethodSetting. I think it's sufficient to remove volatile in that class. It's misleading.

See new commit. This drops `volatile`, looks generally cleaner, and avoids triggering analysis that complains about static field modifications from instance methods on top.

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

PR Comment: https://git.openjdk.org/jdk/pull/25584#issuecomment-2931689864

From egahlin at openjdk.org  Mon Jun  2 17:38:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 2 Jun 2025 17:38:53 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization [v2]
In-Reply-To: <Yx6oef8XSMKm_Uc6sQ_oMD-VGgB1x8lQfo5hrTQiotI=.b4d77560-ee4d-4870-a30b-9f7b62c90043@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
 <Yx6oef8XSMKm_Uc6sQ_oMD-VGgB1x8lQfo5hrTQiotI=.b4d77560-ee4d-4870-a30b-9f7b62c90043@github.com>
Message-ID: <_jYL97zo2sr8OY28pn0LuEhgVusxdJ1orObaHu_LQEI=.cfb84b12-e2e6-4651-bd97-61b4186a8615@github.com>

On Mon, 2 Jun 2025 17:28:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Unsynchronized fix
>  - Merge branch 'master' into JDK-8358318-jfr-platform-tracer-init
>  - Fix

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25584#pullrequestreview-2889374075

From egahlin at openjdk.org  Mon Jun  2 18:25:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 2 Jun 2025 18:25:00 GMT
Subject: Integrated: 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: <37s8zcu35k8EmAme38VWPY1B0Q4lt3Ca1GL_Wojpqeg=.37664c94-1b9c-44fb-b5d0-cf075fc9a897@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

This pull request has now been integrated.

Changeset: 1373ceb7
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1373ceb7f3040a03ae142cfaab0f74894fc6a0a3
Stats:     706 lines in 6 files changed: 698 ins; 3 del; 5 mod

8356698: JFR: @Contextual

Reviewed-by: mgronlun

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

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

From vyazici at openjdk.org  Mon Jun  2 18:39:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 18:39:33 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
Message-ID: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@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.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Provide fallback for `stdin.encoding`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25542/files
  - new: https://git.openjdk.org/jdk/pull/25542/files/d7751294..45bdc4fd

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 shade at openjdk.org  Mon Jun  2 18:47:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:47:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>

On Mon, 2 Jun 2025 13:50:49 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 bug related to async stack walking

Scanned this briefly, would do another pass tomorrow.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 117:

> 115: 
> 116: bool JfrCPUTimeTraceQueue::is_empty() const {
> 117:   return Atomic::load(&_head) == 0;

Not entirely clear what is the memory semantics for accessing `_head`. Does it need to be acq/rel? If so, this one should be `::load_acquire`?

src/hotspot/share/memory/resourceArea.hpp line 46:

> 44: // A ResourceArea is an Arena that supports safe usage of ResourceMark.
> 45: class ResourceArea: public Arena {
> 46: 

All the changes in this file are unnecessary, please revert.

src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java line 281:

> 279:      * @param autoadapt true if the rate should be adapted automatically
> 280:      */
> 281:     public static native void setCPUThrottle(double rate, boolean autoadapt);

Suggestion:

    public static native void setCPUThrottle(double rate, boolean autoAdapt);

test/jdk/jdk/jfr/event/profiling/TestSamplingLongPeriod.java line 42:

> 40: public class TestSamplingLongPeriod {
> 41: 
> 42:     static String sampleEvent = EventNames.ExecutionSample;

Does not look necessary to change?

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2888004951
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121900364
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121610476
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121587105
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121584954

From shade at openjdk.org  Mon Jun  2 18:47:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:47:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <dw0nEvtOhHk5pe5VLBy_RF29x_ACwQ_UTjAVZykGKmc=.41920e11-799a-40a2-a258-3e796c260196@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>
 <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@github.com>
 <dw0nEvtOhHk5pe5VLBy_RF29x_ACwQ_UTjAVZykGKmc=.41920e11-799a-40a2-a258-3e796c260196@github.com>
Message-ID: <c_YDStb7UsPO4JPDnKv9B33xAw4yKAQwqtuKgkeS3AQ=.c09f8335-46d3-498a-9b4e-7bb339bc5b19@github.com>

On Sun, 1 Jun 2025 07:19:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Thanks for catching this mistake. I'll fix it this afternoon.
>
> I fixed it by changing the JEP.

Hold on, shouldn't this really be "Lost"? @egahlin and @mgronlun need to chime in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120893338

From shade at openjdk.org  Mon Jun  2 18:47:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:47:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
Message-ID: <B42Y_m2MMHoovZ-ronA3urM0XBTMSHMrYxgVXTFOYCo=.df0e5588-d10f-44a7-b0c3-45eb3680ed92@github.com>

On Mon, 2 Jun 2025 11:32:27 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 two additional commits since the last revision:
> 
>  - Tiny fixes
>  - Minor changes

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 30:

> 28: #include "runtime/orderAccess.hpp"
> 29: #include "utilities/ticks.hpp"
> 30: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"

Include order?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 60:

> 58:   assert(raw_thread->is_Java_thread(), "invariant");
> 59:   JavaThread* jt;
> 60:   if ((jt = JavaThread::cast(raw_thread))->is_exiting()) {

I see no point to be extra-smart with inline assignments here:

Suggestion:

  JavaThread* jt = JavaThread::cast(raw_thread);
  if (jt->is_exiting()) {

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 115:

> 113:   JfrCPUTimeSampleRequest* new_data = JfrCHeapObj::new_array<JfrCPUTimeSampleRequest>(capacity);
> 114:   JfrCHeapObj::free(_data, _capacity * sizeof(JfrCPUTimeSampleRequest));
> 115:   _data = new_data;

A bit of peak memory consumption improvement: don't have two things live at once. Plus, give the native allocator a chance to reuse the same location.

Suggestion:

  JfrCHeapObj::free(_data, _capacity * sizeof(JfrCPUTimeSampleRequest));
  _data = JfrCHeapObj::new_array<JfrCPUTimeSampleRequest>(capacity);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120895107
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120897472
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120909443

From cjplummer at openjdk.org  Mon Jun  2 19:02:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:02:53 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <KmxfpCX7C01W4ZWfeB4VkJ9KUzSNDnioLJY4VO65Yf4=.8ef6039a-22ba-4db7-895a-066353f85236@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 111:

> 109: 
> 110:         Charset charset = Charset.forName(System.getProperty("stdin.encoding"), Charset.defaultCharset());
> 111:         BufferedReader in = new BufferedReader(new InputStreamReader(System.in, charset));

Why in some cases are you special casing the the default charset as you do here, but in other cases you are not? Also, the CharSet.forName() API you are using here is new in 18, which means backports will need to address that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25542#discussion_r2121939764

From vyazici at openjdk.org  Mon Jun  2 19:41:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:41:52 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <KmxfpCX7C01W4ZWfeB4VkJ9KUzSNDnioLJY4VO65Yf4=.8ef6039a-22ba-4db7-895a-066353f85236@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <KmxfpCX7C01W4ZWfeB4VkJ9KUzSNDnioLJY4VO65Yf4=.8ef6039a-22ba-4db7-895a-066353f85236@github.com>
Message-ID: <bVByfbVe5ra99AXi1923ZvXy0J8BVlO_121U7KlGF9k=.13e026fc-ed9f-4e05-9ffe-2e19bae3f746@github.com>

On Mon, 2 Jun 2025 19:00:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Why in some cases are you special casing the the default charset as you do here, but in other cases you are not?

@plummercj, as requested in the parent ticket (i.e., [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893)), I added a fallback, except for tests. AFAICT, if `stdin.encoding` is either missing or contains an invalid value in a test, we ideally should fail the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25542#discussion_r2122007106

From mgronlun at openjdk.org  Mon Jun  2 20:07:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 20:07:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <cv9bDy_Zg7iEzbSAR5aFiHolzaWP1SYd6UPzSNAPLiA=.b3dda4d6-e525-4b49-8570-a34873e7744f@github.com>

On Mon, 2 Jun 2025 13:50:49 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 bug related to async stack walking

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 49:

> 47: 
> 48: static bool is_excluded(JavaThread* thread) {
> 49:   return thread->is_hidden_from_external_view() || thread->jfr_thread_local()->is_excluded();

I think I misled you saying that JfrRecorder_thread would be excluded by the above expression. That was true - but not anymore.

Our exclusion test looks like:

static inline bool is_excluded(JavaThread* jt) {
  assert(jt != nullptr, "invariant");
  return jt->is_Compiler_thread() || jt->is_hidden_from_external_view() || jt->is_JfrRecorder_thread() || jt->jfr_thread_local()->is_excluded();
}

I like you could fold jt->is_Compiler_thread() into jt->is_hidden_from_external_view() - good!.

But can you please again list the condition jt->is_JfrRecorder_thread() ? Sorry, I forgot we had removed it from being considered excluded on the JfrThreadLocal level. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122045043

From dholmes at openjdk.org  Mon Jun  2 21:56:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 21:56:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>
Message-ID: <ermts7eqxGeuCidfgDMgA-gpV2OweDA0wsMIbOA8yiw=.26448a32-1433-47f0-b748-1c328aefb6c6@github.com>

On Mon, 2 Jun 2025 18:37:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug related to async stack walking
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 117:
> 
>> 115: 
>> 116: bool JfrCPUTimeTraceQueue::is_empty() const {
>> 117:   return Atomic::load(&_head) == 0;
> 
> Not entirely clear what is the memory semantics for accessing `_head`. Does it need to be acq/rel? If so, this one should be `::load_acquire`?

Many of the accesses to head do not appear to synchronize with anything and so do not need acquire semantics. But the overall concurrency properties of this code are very unclear to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122228261

From cjplummer at openjdk.org  Mon Jun  2 22:07:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 22:07:52 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <-rIQHptI3h_uZTew6KYZLXC--aq6_Sxoe5wg1Xe7xq8=.f41290f7-7c61-4849-80d6-e65cf47d8733@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

Changes look good. Can you clarify your testing?

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25542#pullrequestreview-2890065248

From dholmes at openjdk.org  Tue Jun  3 00:16:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 00:16:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <rtV4SDWYrn4P64uGvC5yAw_8qzeCUMeOwz7Ly7I9EZA=.32e3ceba-ff3d-42f1-aa0f-3e60606ad03f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>
 <rtV4SDWYrn4P64uGvC5yAw_8qzeCUMeOwz7Ly7I9EZA=.32e3ceba-ff3d-42f1-aa0f-3e60606ad03f@github.com>
Message-ID: <jF47KzRlEdyxYFBpo8PMrj9wbL43EWQoE6Kf3vZ95c8=.fcd9f508-0827-4666-83e3-595c3dc484e3@github.com>

On Mon, 2 Jun 2025 09:24:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 119:
>> 
>>> 117:   _data = new_data;
>>> 118:   _capacity = capacity;
>>> 119: }
>> 
>> I assume there is a lock protecting this so it happens atomically?
>
> This happens before the signal handler is attached to thread. So it does happen before any parallelism is introduced on thread creation.

I'm missing the big picture here unfortunately. This looks like it can get called repeatedly as needed to change capacity. Are you saying it only gets called once before we create the sampler thread? Is the concurrency model described somewhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122365626

From dholmes at openjdk.org  Tue Jun  3 00:28:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 00:28:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <ermts7eqxGeuCidfgDMgA-gpV2OweDA0wsMIbOA8yiw=.26448a32-1433-47f0-b748-1c328aefb6c6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>
 <ermts7eqxGeuCidfgDMgA-gpV2OweDA0wsMIbOA8yiw=.26448a32-1433-47f0-b748-1c328aefb6c6@github.com>
Message-ID: <_Q0iW6TuzM0P1qeE2XsMZbTx3lfCgW9QDEsf3-FlRYE=.b6707a06-3d91-4764-a8d8-7eaa76680584@github.com>

On Mon, 2 Jun 2025 21:53:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 117:
>> 
>>> 115: 
>>> 116: bool JfrCPUTimeTraceQueue::is_empty() const {
>>> 117:   return Atomic::load(&_head) == 0;
>> 
>> Not entirely clear what is the memory semantics for accessing `_head`. Does it need to be acq/rel? If so, this one should be `::load_acquire`?
>
> Many of the accesses to head do not appear to synchronize with anything and so do not need acquire semantics. But the overall concurrency properties of this code are very unclear to me.

To be clear, you only need acquire semantics here if after seeing the value 0 you need to access fields that were written before `_head` was set to 0. Similarly for most of the other access to `_head`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122374152

From jbechberger at openjdk.org  Tue Jun  3 06:58:03 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 06:58:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <GebM_7E8Zpil6ckH6wYx4izFkdoWT0IwW5_oKPBrYJ4=.46da4495-e7a4-4f85-9527-6ca0da9a2f09@github.com>

On Mon, 2 Jun 2025 13:50:49 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 bug related to async stack walking

Regarding https://github.com/openjdk/jdk/pull/25302#discussion_r2119984783


raw_thread == nullptr


This seems to happen rarely on (abrupt) shutdowns. I attached an hs_err file: [hs_err_pid1688961.log](https://github.com/user-attachments/files/20563594/hs_err_pid1688961.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2933774229

From jbechberger at openjdk.org  Tue Jun  3 07:05:47 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:05:47 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v30]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <QaYQnf_1OBfk55Ppt_C_WcWAJTN9fRh5xj7aHq3nlEs=.e99a7873-e243-4e86-a193-cda9f720842a@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:

 - Check for raw_thread == nullptr
 - Move async stackwalking to JFR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/09ca4fed..bef52132

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

  Stats: 89 lines in 3 files changed: 37 ins; 49 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  Tue Jun  3 07:12:46 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:12:46 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@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 three additional commits since the last revision:

 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Small fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/bef52132..c3dedefb

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

  Stats: 17 lines in 4 files changed: 2 ins; 5 del; 10 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  Tue Jun  3 07:17:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:17:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <cv9bDy_Zg7iEzbSAR5aFiHolzaWP1SYd6UPzSNAPLiA=.b3dda4d6-e525-4b49-8570-a34873e7744f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <cv9bDy_Zg7iEzbSAR5aFiHolzaWP1SYd6UPzSNAPLiA=.b3dda4d6-e525-4b49-8570-a34873e7744f@github.com>
Message-ID: <G1Iao_wSPalg0_uQglKFwWi6j4UWtH59ggkQZ7mZy3E=.33bdd35a-a685-44d0-9656-997985fc86f8@github.com>

On Mon, 2 Jun 2025 20:02:15 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 bug related to async stack walking
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 49:
> 
>> 47: 
>> 48: static bool is_excluded(JavaThread* thread) {
>> 49:   return thread->is_hidden_from_external_view() || thread->jfr_thread_local()->is_excluded();
> 
> I think I misled you saying that JfrRecorder_thread would be excluded by the above expression. That was true - but not anymore.
> 
> Our exclusion test looks like:
> 
> static inline bool is_excluded(JavaThread* jt) {
>   assert(jt != nullptr, "invariant");
>   return jt->is_Compiler_thread() || jt->is_hidden_from_external_view() || jt->is_JfrRecorder_thread() || jt->jfr_thread_local()->is_excluded();
> }
> 
> I like you could fold jt->is_Compiler_thread() into jt->is_hidden_from_external_view() - good!.
> 
> But can you please again list the condition jt->is_JfrRecorder_thread()? Sorry, I forgot we had removed it from being considered excluded on a per JfrThreadLocal level. Thanks.

No problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122934873

From dholmes at openjdk.org  Tue Jun  3 07:39:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 07:39:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
Message-ID: <aw1krGUp1fbgU8GLgIiJ2wQ3k_biKBazNCq9dNhZew0=.d44b11e9-5853-4337-8f0b-f0d55fe86809@github.com>

On Tue, 3 Jun 2025 07:12:46 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 three additional commits since the last revision:
> 
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Small fixes

> Regarding [#25302 (comment)](https://github.com/openjdk/jdk/pull/25302#discussion_r2119984783)
> 
> ```
> raw_thread == nullptr
> ```
> 
> This seems to happen rarely on (abrupt) shutdowns. I attached an hs_err file: [hs_err_pid1688961.log](https://github.com/user-attachments/files/20563594/hs_err_pid1688961.log)

That is interesting. The signal appears to be being handled on an unattached thread during shutdown, and there is no stack left to show any VM involvement. Possibly we need to block the signal as part of thread termination, before we clear the current thread. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2933916367

From jbechberger at openjdk.org  Tue Jun  3 07:44:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:44:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v32]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <iNwRQeUlur9y6sm3QRLH9_ooILlyzOdYbzxSlBf_DZM=.8cec5ec7-2efb-4990-aa1c-a6747f8842d3@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:

 - Remove includes and other lines
 - Fix is_excluded

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/c3dedefb..ab47f680

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=30-31

  Stats: 25 lines in 17 files changed: 4 ins; 5 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  Tue Jun  3 07:44:34 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:44:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
Message-ID: <PyJV7DdapZ82m3biASyj6vhrb74OMiG6FpFaPas_ZNU=.1c5f57ab-2147-4c04-9f9f-875ac7a8ede8@github.com>

On Tue, 3 Jun 2025 07:12:46 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 three additional commits since the last revision:
> 
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Small fixes

We already do:


void JfrCPUTimeThreadSampler::on_javathread_terminate(JavaThread* thread) {
  JfrThreadLocal* tl = thread->jfr_thread_local();
  assert(tl != nullptr, "invariant");
  timer_t* timer = tl->cpu_timer();
  if (timer == nullptr) {
    return; // no timer was created for this thread
  }
  timer_delete(*timer);

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2933945034

From shade at openjdk.org  Tue Jun  3 08:32:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:32:58 GMT
Subject: Integrated: 8358318: JFR: Tighten up PlatformTracer initialization
In-Reply-To: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
Message-ID: <AhLG7CW5C0FIL40tystRWCtXWIvB9RalKnBU1Jde_6o=.49ffd052-e5ff-4ec3-a9e3-6f092276c276@github.com>

On Mon, 2 Jun 2025 11:19:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

This pull request has now been integrated.

Changeset: 8674f491
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8674f49127d75d20c074fb8c4f0736bfe190f8b8
Stats:     18 lines in 2 files changed: 12 ins; 5 del; 1 mod

8358318: JFR: Tighten up PlatformTracer initialization

Reviewed-by: egahlin

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

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

From shade at openjdk.org  Tue Jun  3 08:32:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:32:57 GMT
Subject: RFR: 8358318: JFR: Tighten up PlatformTracer initialization [v2]
In-Reply-To: <Yx6oef8XSMKm_Uc6sQ_oMD-VGgB1x8lQfo5hrTQiotI=.b4d77560-ee4d-4870-a30b-9f7b62c90043@github.com>
References: <hI-2DhD5JqL87wfMkUp7W-YCmDQ66zoE-yCG5C-ucIw=.374dbadc-2f5f-4ca7-8f00-b267514d7f44@github.com>
 <Yx6oef8XSMKm_Uc6sQ_oMD-VGgB1x8lQfo5hrTQiotI=.b4d77560-ee4d-4870-a30b-9f7b62c90043@github.com>
Message-ID: <ac8VUVWIDuTtP4hvzCG_354Z255fCv5p48B16THphck=.baaa4759-54e2-4c7e-b5d2-f6afa923288a@github.com>

On Mon, 2 Jun 2025 17:28:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Started as SonarCloud complaint that MethodSetting.apply initializes a static field. But I think there is a larger problem here, which I completely missed during [JDK-8352738](https://bugs.openjdk.org/browse/JDK-8352738) review: the `PlatformTracer` initialization can technically run several times, AFAICS. This PR tightens up the initialization. It also allows us to call `ensureInitialized` from other places, if we ever find a need.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Unsynchronized fix
>  - Merge branch 'master' into JDK-8358318-jfr-platform-tracer-init
>  - Fix

Thanks for review, here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25584#issuecomment-2934117050

From jbechberger at openjdk.org  Tue Jun  3 08:42:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 08:42:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v33]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <PAEbbcgVvoCbXPc69QgUgGFfGLFr2KYnRNfEcRWBPPE=.a236f65f-92f6-4854-8b82-e8500d75409c@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 non Linux builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ab47f680..ef9f9cd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=31-32

  Stats: 4 lines in 1 file changed: 2 ins; 2 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  Tue Jun  3 09:26:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 09:26:05 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <-rIQHptI3h_uZTew6KYZLXC--aq6_Sxoe5wg1Xe7xq8=.f41290f7-7c61-4849-80d6-e65cf47d8733@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <-rIQHptI3h_uZTew6KYZLXC--aq6_Sxoe5wg1Xe7xq8=.f41290f7-7c61-4849-80d6-e65cf47d8733@github.com>
Message-ID: <qEkAQ_qddaxGTU2r3ZgGSbUXJ3DuSKFjGa7-gE-M-CI=.b2db3e01-dbb2-4e73-8982-c73e3eb1873e@github.com>

On Mon, 2 Jun 2025 22:04:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Can you clarify your testing?

@plummercj, green `tier1,2` results on 45bdc4fdaa1 are attached to the ticket. Would they suffice?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2934323998

From mgronlun at openjdk.org  Tue Jun  3 09:47:09 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 09:47:09 GMT
Subject: RFR: 8358429: JFR: minimize the time the Threads_lock is held for
 sampling
Message-ID: <Q5c8lt88lTjS7YPec5D8fEspUjB4-Nyrfelxx0jtk9o=.cd422b75-5609-4663-87ad-6608ccc13e1f@github.com>

Greetings,

Before [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), the JFR Sampler Thread held onto the Threads_lock during the entire sampling period when iterating threads.

This was for two purposes:

1. Having a non-Java thread sampler thread race through an ongoing safepoint, touching oops is generally not supported by most GCs.
2. Since the sampler thread is a non-Java thread, and a JavaThread to be sampled can be in thread state _thread_in_native, it means both threads are outside the safepoint protocol. JFR evolves its global epoch during a safepoint.

With [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), things have improved much. The sampling parts performed by the non-Java sampler thread do not touch any oops for threads sampled in state _thread_in_Java.
For sampling threads in native, the original issue persists (the sampler thread needs to capture the stack trace in the correct JFR epoch, and will also, in the case of virtual threads, need to touch oops).

However, we can significantly reduce the time the Threads_lock is held for sampling.

Testing: jdk_jfr, stress testing

Thanks
Markus

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

Commit messages:
 - whitespace
 - description
 - 8358429

Changes: https://git.openjdk.org/jdk/pull/25602/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25602&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358429
  Stats: 165 lines in 4 files changed: 102 ins; 19 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/25602.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25602/head:pull/25602

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

From erik.gahlin at oracle.com  Tue Jun  3 09:50:17 2025
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 3 Jun 2025 09:50:17 +0000
Subject: JFR: Scrubbing sensitive information from events
In-Reply-To: <CACX82zeW1sQRHAYZW52GLtWczKVAt=Q5_=arHHSnYRKz_QXOmg@mail.gmail.com>
References: <CACX82zeW1sQRHAYZW52GLtWczKVAt=Q5_=arHHSnYRKz_QXOmg@mail.gmail.com>
Message-ID: <DS7PR10MB5118CDB3DDFDA3044761C8B59D62A@DS7PR10MB5118.namprd10.prod.outlook.com>

We have discussed it, but we don't understand all the details. We are also unsure how to best expose it to the end user. Let's say there was a command line option -XX:FlightRecorder:scrub-file=<file>.

What would you fill that file with? I want examples that work on real data to understand how expressive the filters must be.

Thanks
Erik
________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Erwan Viollet <erwan.viollet at gmail.com>
Sent: Monday, June 2, 2025 3:30 PM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: JFR: Scrubbing sensitive information from events

Hello,

I am currently looking into how to remove sensitive information from JFR events. The main events that typically contain sensitive information: jdk.SystemProcess,  jdk.InitialSystemProperty, jdk.JVMInformation. Passwords from command lines can typically be found in these events.

Dropping these events altogether is not ideal, as we need them to make relevant performance recommendations to users (e.g. suggesting JVM or system setting adjustments).

Dropping them or scrubbing them on the backend side (after the fact) requires decompressing and re-writing these events, which is wasteful in terms of both compute and storage. The approach is not perfect, as we still end up intaking and temporarily storing sensitive information.

Ideally, we would like to be able to scrub or redact only the sensitive fields within these events (for example, using a simple regex or pattern-based rule), rather than dropping the whole event. We also want to avoid handling this only after the event has already been written to the JFR file, as that does not fully mitigate the risk of exposing sensitive data.

At present, it appears there is no public API or supported mechanism to intercept or scrub JFR events in-process, before they are persisted. What would you think of an API accepting custom scrubbing patterns so that sensitive data never leaves the JVM in an unredacted state?

Are there any plans or discussions in this area? I am fairly new to the JFR world, so it is likely that I missed previous discussions around this.

Thank you, Best regards,

Erwan Viollet,

Profiling team, Datadog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250603/999bf193/attachment.htm>

From shade at openjdk.org  Tue Jun  3 10:33:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 10:33:52 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: <SrW9_EJnP8nHIaogRecCHB9__OrJFRYbHK12u9f1HuA=.e125edd6-4577-4a47-b76d-e5c3cc8f8044@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`

I think @iwanowww had an opinion on this :)

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

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

From nbenalla at openjdk.org  Tue Jun  3 11:16:03 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:16:03 GMT
Subject: RFR: 8346886: Add since checker test to jdk.management.jfr
Message-ID: <BnO4tQIO36TrJDW_nawg5Wg5elHmQXHjKSTaKVGmZXA=.faabca52-1afe-429e-81d3-6d0de33693bd@github.com>

Please review this patch to add a new test to check `@since` tags in the `jdk.management.jfr` module.

TIA

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

Commit messages:
 - add new `@since` test

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

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

From jbechberger at openjdk.org  Tue Jun  3 11:32:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 11:32:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <aw1krGUp1fbgU8GLgIiJ2wQ3k_biKBazNCq9dNhZew0=.d44b11e9-5853-4337-8f0b-f0d55fe86809@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
 <aw1krGUp1fbgU8GLgIiJ2wQ3k_biKBazNCq9dNhZew0=.d44b11e9-5853-4337-8f0b-f0d55fe86809@github.com>
Message-ID: <iijJRrJgOxlvWSA3hrQTgE7SJgqnHfIwZ9FQGfhws3U=.e5d88557-1006-4c72-9986-c7f3b7722130@github.com>

On Tue, 3 Jun 2025 07:36:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>>    
>>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>>    
>>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>>  - Small fixes
>
>> Regarding [#25302 (comment)](https://github.com/openjdk/jdk/pull/25302#discussion_r2119984783)
>> 
>> ```
>> raw_thread == nullptr
>> ```
>> 
>> This seems to happen rarely on (abrupt) shutdowns. I attached an hs_err file: [hs_err_pid1688961.log](https://github.com/user-attachments/files/20563594/hs_err_pid1688961.log)
> 
> That is interesting. The signal appears to be being handled on an unattached thread during shutdown, and there is no stack left to show any VM involvement. Possibly we need to block the signal as part of thread termination, before we clear the current thread. ?

Regarding the acquire-release-semantics (cc @dholmes-ora): I currently use it, because it works and is fast enough. Using a weaker semantics is a good optimization, but I would abstain it for new due to time constraints.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2934793239

From jbechberger at openjdk.org  Tue Jun  3 11:42:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 11:42:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v34]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <NY5XG0lZkmWMi7UGr6WgzeiNzUJvRx5DYk8Ec8A3XdE=.e351aea6-faa4-41e7-8e08-55891766cefd@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:

 - Use store-release semantics
 - Log error when timer_create fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ef9f9cd1..93b5a189

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=32-33

  Stats: 10 lines in 3 files changed: 1 ins; 1 del; 8 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  Tue Jun  3 12:12:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:12:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@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:

 - Fix include order
 - Tiny refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/93b5a189..71611f1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=33-34

  Stats: 19 lines in 4 files changed: 8 ins; 10 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  Tue Jun  3 12:19:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 12:19:04 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: <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>

On Mon, 26 May 2025 15:42:57 GMT, Erik Gahlin <egahlin 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.
>
>> 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 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.

> Hold on, shouldn't this really be "Lost"? @egahlin and @mgronlun need to chime in here.

Lost might be better.

I wonder if `<Field type="Thread" name="eventThread" label="Thread" />` is needed,  instead of thread = true?

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2934959447

From jbechberger at openjdk.org  Tue Jun  3 12:19:05 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:19:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@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>
 <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>
Message-ID: <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@github.com>

On Tue, 3 Jun 2025 12:15:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I wonder if <Field type="Thread" name="eventThread" label="Thread" /> is needed, instead of thread = true?

We had these discussions before on the old PR and then decided to end up with eventThread (as the other events do to),

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2934963523

From mgronlun at openjdk.org  Tue Jun  3 12:19:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:19:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
Message-ID: <fkXDN7qy0lQ2si3il714rKAQ6HmUTyt1e8OZpDnRSZg=.d88ce69a-357f-4d3b-a29e-cd6dfeb7d80d@github.com>

On Tue, 3 Jun 2025 12:12:53 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 two additional commits since the last revision:
> 
>  - Fix include order
>  - Tiny refactoring

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 67:

> 65:   }
> 66: 
> 67:   if (is_excluded(jt)) {

I think move this before the jt->is_exiting() check - excluded is much much more common than exiting...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123633391

From mgronlun at openjdk.org  Tue Jun  3 12:25:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:25:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
Message-ID: <e87wWtBns9NxmIlA4-ycnt015LIpn52ob9VcL2UEhww=.c500f54a-1b71-43bc-b122-b036fa975f54@github.com>

On Tue, 3 Jun 2025 12:12:53 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 two additional commits since the last revision:
> 
>  - Fix include order
>  - Tiny refactoring

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 371:

> 369:   timer_t* cpu_timer() const;
> 370: 
> 371:   // The CPU time JFR lock has four different states:

Only three different states now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123651646

From jbechberger at openjdk.org  Tue Jun  3 12:29:48 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:29:48 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v36]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <gTBCzFTywdIwThuNzoXcpxf8tzTIJE4BxklK_uiil7k=.aa48a78e-973e-498f-9738-af13c0f4db33@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:

 - CPUTimeSampleLoss -> CPUTimeSamplesLost
 - Move is_excluded forward

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/71611f1e..a419daba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=34-35

  Stats: 13 lines in 7 files changed: 0 ins; 1 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  Tue Jun  3 12:35:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:35:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v37]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <WlHvbZE4QvzY_ZRproz5Jy6EV3G5JYviDtedkEZGsXE=.0917cf57-85b5-4c50-b59e-917bc073d9e1@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 mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/a419daba..44c37d17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=35-36

  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 mgronlun at openjdk.org  Tue Jun  3 12:35:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:35:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
Message-ID: <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>

On Tue, 3 Jun 2025 12:12:53 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 two additional commits since the last revision:
> 
>  - Fix include order
>  - Tiny refactoring

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 235:

> 233: 
> 234: void JfrCPUTimeThreadSampler::on_javathread_create(JavaThread* thread) {
> 235:   if (thread->is_Compiler_thread()) {

is_hidden_from_external_view() + is_JfrRecorderThread() instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123668189

From jbechberger at openjdk.org  Tue Jun  3 12:39:47 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:39:47 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@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:

  Restrict threads for which timers are created

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/44c37d17..83b55f58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=36-37

  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 mgronlun at openjdk.org  Tue Jun  3 12:39:49 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:39:49 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
 <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
Message-ID: <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>

On Tue, 3 Jun 2025 12:29:39 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix include order
>>  - Tiny refactoring
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 235:
> 
>> 233: 
>> 234: void JfrCPUTimeThreadSampler::on_javathread_create(JavaThread* thread) {
>> 235:   if (thread->is_Compiler_thread()) {
> 
> is_hidden_from_external_view() + is_JfrRecorderThread() instead?

tl->is_excluded() is volatile and can change during runtime, so it's better to add a timer unconditionally there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123669984

From jbechberger at openjdk.org  Tue Jun  3 12:39:49 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:39:49 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
 <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
 <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>
Message-ID: <mEryQDWQA3DXeD2cgsY-jDd_7thpuckPP5e7nzmjWOI=.42fa317f-8d37-49f4-aad7-25657372fcee@github.com>

On Tue, 3 Jun 2025 12:30:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 235:
>> 
>>> 233: 
>>> 234: void JfrCPUTimeThreadSampler::on_javathread_create(JavaThread* thread) {
>>> 235:   if (thread->is_Compiler_thread()) {
>> 
>> is_hidden_from_external_view() + is_JfrRecorderThread() instead?
>
> tl->is_excluded() is volatile and can change during runtime, so it's better to add a timer unconditionally there.

why not just `is_excluded`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123673323

From mgronlun at openjdk.org  Tue Jun  3 12:44:09 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:44:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
Message-ID: <23UojxlSZeRcCB38B1d2hDIcyXbgRnmbi8Vu3cfUmM4=.ba379d71-7bc7-4721-bda0-6d5f469a45f7@github.com>

On Tue, 3 Jun 2025 12:39:47 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:
> 
>   Restrict threads for which timers are created

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 63:

> 61:   assert(raw_thread->is_Java_thread(), "invariant");
> 62:   JavaThread* jt = JavaThread::cast(raw_thread);
> 63:   if (is_excluded(jt)) {

and now:

 if (is_excluded(jt) || jt->is_exiting()) {
   return nullptr;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123692657

From jbechberger at openjdk.org  Tue Jun  3 12:47:48 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:47:48 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v39]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <yP4vUHQv7wtT0hC3ojJQ7_r7l-itvez20Nwer9qvIWk=.6c4778f4-a825-4a2a-ad7c-86723ecda9cf@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 refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/83b55f58..2b8c6db4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=37-38

  Stats: 4 lines in 1 file changed: 0 ins; 3 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  Tue Jun  3 12:50:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 12:50:49 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@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

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

  Fix adjust boundary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/d0097506..7fa2db19

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

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 mgronlun at openjdk.org  Tue Jun  3 12:51:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:51:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
Message-ID: <WSVxq1bpLMdJWWO90qjN8icWwa2bXRqXO51yXz3L7d8=.42df9e65-a9a3-49b9-bf79-d395baf73505@github.com>

On Tue, 3 Jun 2025 12:39:47 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:
> 
>   Restrict threads for which timers are created

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 327:

> 325:     JfrThreadLocal* tl = jt->jfr_thread_local();
> 326:     if (tl->wants_async_processing_of_cpu_time_jfr_requests()) {
> 327:       if (!jt->has_last_Java_frame() || jt->thread_state() != _thread_in_native || !tl->try_acquire_cpu_time_jfr_dequeue_lock()) {

I recommend this order for higher probability:

1. jt->thread_state() != _thread_in_native
2. !tl->try_acquire_cpu_time_jfr_dequeue_lock()
3. !jt->has_last_Java_frame()

You need to restructure of course, to get the unlocking correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123711980

From jbechberger at openjdk.org  Tue Jun  3 13:00:06 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 13:00:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v40]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <XBx9ygN3h-Q2WFXj4N3fnSvyd2fYAscvxYV2ZTaoqSg=.4b59177b-f34e-44fd-97f7-36825bca89cd@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:

  Reorder condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/2b8c6db4..56ce2b05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=38-39

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 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  Tue Jun  3 13:00:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 13:00:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
Message-ID: <SQrM358KIiTM8NFrGofKFH5pffthpwFe0XE5opYW0Uo=.85b4e04e-1083-45ff-8310-caf337b024d5@github.com>

On Tue, 3 Jun 2025 12:39:47 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:
> 
>   Restrict threads for which timers are created

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 479:

> 477: 
> 478: // Entry point for a thread that has been sampled in native code and has a pending JFR CPU time request.
> 479: void JfrThreadSampling::process_cpu_time_request(JavaThread* jt, JfrThreadLocal* tl, Thread* current, bool lock) {

Can you move this up to be co-located with  "drain_enqueued_cpu_time_requests"? Thanks.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.hpp line 40:

> 38:  public:
> 39:   static void process_sample_request(JavaThread* jt, bool has_cpu_time_sample_request);
> 40:   static void process_cpu_time_request(JavaThread* jt, JfrThreadLocal* tl, Thread* current, bool lock);

Put this under private and add JfrCPUTimeThreadSampler as a friend (like above with JfrSamplerThread and "process_native_sample_requests"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123728400
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123726144

From jbechberger at openjdk.org  Tue Jun  3 13:33:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 13:33:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v41]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <dFc1zKdrVaiDvJRX3kyCltXFcamagWNpd5Sgx3sbogA=.0045581e-6b64-4595-b536-b3208a1fb2ca@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:

  Make process_cpu_time_request private and move up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/56ce2b05..7561d512

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=39-40

  Stats: 17 lines in 2 files changed: 9 ins; 8 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  Tue Jun  3 14:09:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 14:09:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@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:

  Rename autoadapt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/7561d512..ae55610c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=40-41

  Stats: 41 lines in 8 files changed: 0 ins; 0 del; 41 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  Tue Jun  3 14:10:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 14:10:59 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <8jbZNr-7dzvGRglSLxMcgr5WjmSrGRChJ8MQarUTkdo=.dc1c9dff-65da-4e75-a49c-9af112b26cc7@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

Great stuff.

We have now what amounts to a carbon-copy of the existing throttling implementation used in the JVM, mainly used by the jdk.ObjectAllocationSample event. (see hotspot/src/share/jfr/support/jfrAdaptiveSampler.cpp and hotspot/src/share/jfr/recorder/service/jfrEventThrottler.cpp).

Smart work to write the Java implementation as a method-to-method comparison, which made it easier to review.

Thanks
Markus

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2892579207

From egahlin at openjdk.org  Tue Jun  3 14:36:07 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 14:36:07 GMT
Subject: RFR: 8358448: JFR: Incorrect time unit for MethodTiming event
Message-ID: <ieR2KZOcdLXcA47Xbh3_Pn3-lR6whnLnVcFhWYKrXlQ=.906189a2-883b-4022-a1d7-74c5d46e91da@github.com>

Could I have a review of a PR that fixes a regression introduced with [JDK-8047756](https://bugs.openjdk.org/projects/JDK/issues/JDK-8047756)?

The default unit for `@Timespan` in Java is nanos, but it should be set to ticks. Prior to JDK-8047756, annotations were taken from native code, so ticks were used.

Testing: 
100 * test/jdk//jdk/jfr/event/tracing/TestMethodTimingEvent.java on Windows, Linux and MacOS 
test/jdk//jdk/jfr/*

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Tue Jun  3 14:49:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 14:49:51 GMT
Subject: RFR: 8358448: JFR: Incorrect time unit for MethodTiming event
In-Reply-To: <ieR2KZOcdLXcA47Xbh3_Pn3-lR6whnLnVcFhWYKrXlQ=.906189a2-883b-4022-a1d7-74c5d46e91da@github.com>
References: <ieR2KZOcdLXcA47Xbh3_Pn3-lR6whnLnVcFhWYKrXlQ=.906189a2-883b-4022-a1d7-74c5d46e91da@github.com>
Message-ID: <xnJ5W_Y547GjLX2_IW2oXS4aOVhu6zT4SQWK_Xu-rKE=.a34a69bd-d213-469d-bb0c-7ae942a236b3@github.com>

On Tue, 3 Jun 2025 14:26:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes a regression introduced with [JDK-8047756](https://bugs.openjdk.org/projects/JDK/issues/JDK-8047756)?
> 
> The default unit for `@Timespan` in Java is nanos, but it should be set to ticks. Prior to JDK-8047756, annotations were taken from native code, so ticks were used.
> 
> Testing: 
> 100 * test/jdk//jdk/jfr/event/tracing/TestMethodTimingEvent.java on Windows, Linux and MacOS 
> test/jdk//jdk/jfr/*
> 
> Thanks
> Erik

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25615#pullrequestreview-2892825125

From ayang at openjdk.org  Tue Jun  3 15:28:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 3 Jun 2025 15:28:50 GMT
Subject: RFR: 8358448: JFR: Incorrect time unit for MethodTiming event
In-Reply-To: <ieR2KZOcdLXcA47Xbh3_Pn3-lR6whnLnVcFhWYKrXlQ=.906189a2-883b-4022-a1d7-74c5d46e91da@github.com>
References: <ieR2KZOcdLXcA47Xbh3_Pn3-lR6whnLnVcFhWYKrXlQ=.906189a2-883b-4022-a1d7-74c5d46e91da@github.com>
Message-ID: <MpzHZlqRCCIhSXFdffo7k_5C8p5TmMbZZgfVbs3wmRc=.33607010-6b7c-4a21-a51e-9a5418d0e123@github.com>

On Tue, 3 Jun 2025 14:26:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes a regression introduced with [JDK-8047756](https://bugs.openjdk.org/projects/JDK/issues/JDK-8047756)?
> 
> The default unit for `@Timespan` in Java is nanos, but it should be set to ticks. Prior to JDK-8047756, annotations were taken from native code, so ticks were used.
> 
> Testing: 
> 100 * test/jdk//jdk/jfr/event/tracing/TestMethodTimingEvent.java on Windows, Linux and MacOS 
> test/jdk//jdk/jfr/*
> 
> Thanks
> Erik

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25615#pullrequestreview-2893052614

From egahlin at openjdk.org  Tue Jun  3 16:05:43 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 16:05:43 GMT
Subject: Integrated: 8358448: JFR: Incorrect time unit for MethodTiming event
In-Reply-To: <ieR2KZOcdLXcA47Xbh3_Pn3-lR6whnLnVcFhWYKrXlQ=.906189a2-883b-4022-a1d7-74c5d46e91da@github.com>
References: <ieR2KZOcdLXcA47Xbh3_Pn3-lR6whnLnVcFhWYKrXlQ=.906189a2-883b-4022-a1d7-74c5d46e91da@github.com>
Message-ID: <pJmEAqeyq6H1WaP0DdMgBsZDpul6N7tTl70MTFX0YL4=.260aba95-db11-4e53-a8a2-8a77634bf4b9@github.com>

On Tue, 3 Jun 2025 14:26:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes a regression introduced with [JDK-8047756](https://bugs.openjdk.org/projects/JDK/issues/JDK-8047756)?
> 
> The default unit for `@Timespan` in Java is nanos, but it should be set to ticks. Prior to JDK-8047756, annotations were taken from native code, so ticks were used.
> 
> Testing: 
> 100 * test/jdk//jdk/jfr/event/tracing/TestMethodTimingEvent.java on Windows, Linux and MacOS 
> test/jdk//jdk/jfr/*
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: d7def20a
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7def20afa045a0bb154655b02e56346f7f51347
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358448: JFR: Incorrect time unit for MethodTiming event

Reviewed-by: mgronlun, ayang

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

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

From mgronlun at openjdk.org  Tue Jun  3 16:25:07 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 16:25:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <mEryQDWQA3DXeD2cgsY-jDd_7thpuckPP5e7nzmjWOI=.42fa317f-8d37-49f4-aad7-25657372fcee@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
 <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
 <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>
 <mEryQDWQA3DXeD2cgsY-jDd_7thpuckPP5e7nzmjWOI=.42fa317f-8d37-49f4-aad7-25657372fcee@github.com>
Message-ID: <hLrPEyDdl4DzUt6J9zKLMBf9_1RWL-YC9PEwYk450dc=.a0ca4e15-5754-4276-955f-057fee563626@github.com>

On Tue, 3 Jun 2025 12:31:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> tl->is_excluded() is volatile and can change during runtime, so it's better to add a timer unconditionally there.
>
> why not just `is_excluded`?

because tl->is_excluded() can get included and excluded many times during runtime. Its not a static property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124366551

From cjplummer at openjdk.org  Tue Jun  3 18:11:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Jun 2025 18:11:23 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

> > Can you clarify your testing?
> 
> @plummercj, green `tier1,2` results on [45bdc4f](https://github.com/openjdk/jdk/commit/45bdc4fdaa17d0e9579154578cb9e3917e62c5c5) are attached to the ticket. Would they suffice?

That's not going to be sufficient. The nsk tests are not being run until tier5.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2936567479

From mgronlun at openjdk.org  Tue Jun  3 18:16:24 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 18:16:24 GMT
Subject: RFR: 8357671: JFR: Remove JfrTraceIdEpoch synchronizing
Message-ID: <4FuUPlh3piGBRKq_6BggDdyQviABYNk66rTV97rYaTs=.227185d8-81a8-49eb-a7e8-e70ce6cbf2b0@github.com>

Greetings,

The JfrTraceIdEpoch::is_synchronizing() method and the field _synchronizing are remnants from the old days when we attempted to force CompilerThreads running in native mode into the correct epoch, which ultimately failed due to races.

Removing all that old cruft. Also, reuse the existing epoch generation value for the string pool.

Testing: jdk_jfr

Thanks
Markus

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

Commit messages:
 - 8357671

Changes: https://git.openjdk.org/jdk/pull/25625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357671
  Stats: 52 lines in 7 files changed: 1 ins; 29 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25625/head:pull/25625

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

From dcubed at openjdk.org  Tue Jun  3 18:44:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
Message-ID: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>

A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

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

Commit messages:
 - 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java

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

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

From ayang at openjdk.org  Tue Jun  3 18:44:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
Message-ID: <xM9tjMvvRjUwvvavZxJOFbj30Dgivl7JsGHLI2nVwJM=.00da6a7d-b41c-4df4-b851-6e83ad2d46c0@github.com>

On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25626#pullrequestreview-2893678505

From bpb at openjdk.org  Tue Jun  3 18:44:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
Message-ID: <N71g2QDwsfhI8pU7JSvEL5J36GH8w6OHhmvzxO-RRW0=.05d7363b-6b35-4fba-851b-1f28d50b8cd1@github.com>

On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25626#pullrequestreview-2893679060

From dcubed at openjdk.org  Tue Jun  3 18:44:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <xM9tjMvvRjUwvvavZxJOFbj30Dgivl7JsGHLI2nVwJM=.00da6a7d-b41c-4df4-b851-6e83ad2d46c0@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
 <xM9tjMvvRjUwvvavZxJOFbj30Dgivl7JsGHLI2nVwJM=.00da6a7d-b41c-4df4-b851-6e83ad2d46c0@github.com>
Message-ID: <InzKQUgEHxnwc_o90oRW31ge7zHQcU5-mNVQlb_v23o=.7352fdce-5e15-4f5b-8a4c-a7fd28f7e824@github.com>

On Tue, 3 Jun 2025 18:39:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk and @bplb - Thanks for the lightning fast reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25626#issuecomment-2936702783

From dcubed at openjdk.org  Tue Jun  3 18:44:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
Message-ID: <PEBAzSLzd6k1MwauM-uJFOC7DIT6Y8T_6paBGR_gZuE=.dcdf91d9-a764-41f1-92a9-bde09b8215d2@github.com>

On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

This pull request has now been integrated.

Changeset: e984fa79
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e984fa7997dda922708edf556d1839b866e44e55
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java

Reviewed-by: ayang, bpb

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

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

From egahlin at openjdk.org  Tue Jun  3 20:41:15 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 20:41:15 GMT
Subject: RFR: 8358429: JFR: minimize the time the Threads_lock is held for
 sampling
In-Reply-To: <Q5c8lt88lTjS7YPec5D8fEspUjB4-Nyrfelxx0jtk9o=.cd422b75-5609-4663-87ad-6608ccc13e1f@github.com>
References: <Q5c8lt88lTjS7YPec5D8fEspUjB4-Nyrfelxx0jtk9o=.cd422b75-5609-4663-87ad-6608ccc13e1f@github.com>
Message-ID: <KJNyimAwDYc4Gxg9hwdLen8t0CF_JpziJmbiEx8YM0c=.cea9d83d-c4c4-4335-8916-b532c327a026@github.com>

On Mon, 2 Jun 2025 23:17:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Before [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), the JFR Sampler Thread held onto the Threads_lock during the entire sampling period when iterating threads.
> 
> This was for two purposes:
> 
> 1. Having a non-Java thread sampler thread race through an ongoing safepoint, touching oops is generally not supported by most GCs.
> 2. Since the sampler thread is a non-Java thread, and a JavaThread to be sampled can be in thread state _thread_in_native, it means both threads are outside the safepoint protocol. JFR evolves its global epoch during a safepoint.
> 
> With [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), things have improved much. The sampling parts performed by the non-Java sampler thread do not touch any oops for threads sampled in state _thread_in_Java.
> For sampling threads in native, the original issue persists (the sampler thread needs to capture the stack trace in the correct JFR epoch, and will also, in the case of virtual threads, need to touch oops).
> 
> However, we can significantly reduce the time the Threads_lock is held for sampling.
> 
> Testing: jdk_jfr, stress testing
> 
> Thanks
> Markus

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25602#pullrequestreview-2894053010

From mgronlun at openjdk.org  Tue Jun  3 20:41:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 20:41:34 GMT
Subject: RFR: 8357671: JFR: Remove JfrTraceIdEpoch synchronizing [v2]
In-Reply-To: <4FuUPlh3piGBRKq_6BggDdyQviABYNk66rTV97rYaTs=.227185d8-81a8-49eb-a7e8-e70ce6cbf2b0@github.com>
References: <4FuUPlh3piGBRKq_6BggDdyQviABYNk66rTV97rYaTs=.227185d8-81a8-49eb-a7e8-e70ce6cbf2b0@github.com>
Message-ID: <QxIrl1StvnYEEFtyFdl_Hg3yli1b_7sgtcM89zxxnkk=.e2e21d7b-2910-47b0-8c1c-84ad423a7d00@github.com>

> Greetings,
> 
> The JfrTraceIdEpoch::is_synchronizing() method and the field _synchronizing are remnants from the old days when we attempted to force CompilerThreads running in native mode into the correct epoch, which ultimately failed due to races.
> 
> Removing all that old cruft. Also, reuse the existing epoch generation value for the string pool.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  extended comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25625/files
  - new: https://git.openjdk.org/jdk/pull/25625/files/990275ad..f66b90ee

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

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

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

From egahlin at openjdk.org  Tue Jun  3 20:51:20 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 20:51:20 GMT
Subject: RFR: 8357671: JFR: Remove JfrTraceIdEpoch synchronizing [v2]
In-Reply-To: <QxIrl1StvnYEEFtyFdl_Hg3yli1b_7sgtcM89zxxnkk=.e2e21d7b-2910-47b0-8c1c-84ad423a7d00@github.com>
References: <4FuUPlh3piGBRKq_6BggDdyQviABYNk66rTV97rYaTs=.227185d8-81a8-49eb-a7e8-e70ce6cbf2b0@github.com>
 <QxIrl1StvnYEEFtyFdl_Hg3yli1b_7sgtcM89zxxnkk=.e2e21d7b-2910-47b0-8c1c-84ad423a7d00@github.com>
Message-ID: <QM_2Q7OBK-YGgtl_GN4ux88gAcIl1WHs1aJMJmpbpZ4=.24b06831-9b53-414f-a14f-4f95ade1a59e@github.com>

On Tue, 3 Jun 2025 20:41:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> The JfrTraceIdEpoch::is_synchronizing() method and the field _synchronizing are remnants from the old days when we attempted to force CompilerThreads running in native mode into the correct epoch, which ultimately failed due to races.
>> 
>> Removing all that old cruft. Also, reuse the existing epoch generation value for the string pool.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extended comment

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25625#pullrequestreview-2894076015

From mgronlun at openjdk.org  Tue Jun  3 21:00:36 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:00:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <wVrBhx6WXHPg7K03wGDCFlYf3GYhKd2uMz8r_lv_dL0=.bb3e8f70-996e-45a4-b049-f5391356dba4@github.com>

On Tue, 3 Jun 2025 14:09:29 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:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 31:

> 29: 
> 30: class JavaThread;
> 31: class NonJavaThread;

NonJavaThread fwd not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124913821

From mgronlun at openjdk.org  Tue Jun  3 21:11:32 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:11:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <aevO8AUuhhxjYpl2F7Se3lIBADa0oLHW8htoCP4_MA4=.e3cfcb3c-fc5a-4eed-a654-6fe80053396a@github.com>

On Tue, 3 Jun 2025 14:09:29 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:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 79:

> 77: 
> 78: bool JfrCPUTimeTraceQueue::enqueue(JfrCPUTimeSampleRequest& request) {
> 79:   assert(JavaThread::current()->jfr_thread_local()->is_cpu_time_jfr_enqueue_locked(), "invariant");

What is preventing another thread from enqueuing a request here? We only know it holds a thread-local lock? Let's make it explicit at this site that the current queue corresponds to the thread-local queue for the current thread.

+ assert(&JavaThread::current()->jfr_thread_local()->cpu_time_jfr_queue() == this, "invariant");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124934207

From mgronlun at openjdk.org  Tue Jun  3 21:18:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:18:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <rHqPQU-V8MLLm8oRdk04ek_TiBs4a6OWykEIUZkVQsU=.1b21a346-2a48-4c53-9720-3c2c46023c80@github.com>

On Tue, 3 Jun 2025 14:09:29 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:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 96:

> 94: }
> 95: 
> 96: volatile u4 _lost_samples_sum = 0;

static volatile

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124941941

From mgronlun at openjdk.org  Tue Jun  3 21:45:29 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:45:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <1RLKF0E-I7CjQRNUqb7k0mEIvoSCO010FUaKnmLVPSI=.4c6876fb-ac9c-47d2-8379-ccafdbdbaabe@github.com>

On Tue, 3 Jun 2025 14:09:29 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:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 520:

> 518:   // the sampling period might be too low for the current Linux configuration
> 519:   // so samples might be skipped and we have to compute the actual period
> 520:   int64_t period = get_sampling_period() * (info->si_overrun + 1);

Does this calculation have to be done on every signal, by every thread? It seems like something that could be precalculated when the period is set?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124980054

From mgronlun at openjdk.org  Tue Jun  3 22:01:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 22:01:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <hhQ2qjqC1JjLPwC9l7-rGLp8NuUsOvNLN6Iwjn86rPM=.3e5625fa-60b4-4404-b6ed-b1aae6055e67@github.com>

On Tue, 3 Jun 2025 14:09:29 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:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 360:

> 358:   tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 359:   if (lock) {
> 360:     tl->acquire_cpu_time_jfr_dequeue_lock();

This is your synchronization point on return from native code, which is effectively a spinlock. This can cause problems when a large number of threads are being processed by the "do_async_processing" request call.

We should fix this as a bug after integration (use a proper Monitor as a synchronization point).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124997140

From mgronlun at openjdk.org  Tue Jun  3 22:04:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 22:04:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <yl3LkvLqVPJ0Yf6dRuQW5b82F8H8efdsfRc_4_c3Uzw=.474a65a0-c982-4d81-9b19-7bd7f1f18c01@github.com>

On Tue, 3 Jun 2025 14:09:29 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:
> 
>   Rename autoadapt

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 143:

> 141:       JavaThread *const jt = JavaThread::cast(t);
> 142:       send_java_thread_start_event(jt);
> 143:       JfrCPUTimeThreadSampling::on_javathread_create(jt);

Move before send_java_thread...to have that captured by the timer?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125004892

From apangin at openjdk.org  Wed Jun  4 03:15:36 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 03:15:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>

On Tue, 3 Jun 2025 14:09:29 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:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 51:

> 49: static bool is_excluded(JavaThread* jt) {
> 50:   return jt->is_hidden_from_external_view() ||
> 51:          jt->jfr_thread_local()->is_excluded() ||

These restrictions cause a large blind spot in observability. There is no technical limitation for recording cpu samples for internal threads too, even without a Java stack trace. Consider removing this restriction, although not in this PR.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 135:

> 133:   while ((new_lost_samples = Atomic::cmpxchg(&_lost_samples, lost_samples, 0)) != lost_samples) {
> 134:     lost_samples = new_lost_samples;
> 135:   }

Why not `Atomic::xchg`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 161:

> 159:     return 0;
> 160:   }
> 161:   return os::active_processor_count() * 1000000000.0 / rate;

If sampling period is configured as an absolute number in milliseconds, this value must be passed as is.
Double conversion via `Runtime.availableProcessors()` / `active_processor_count()` is unobvious and error-prone. First, because of asymmetry: e.g. `Runtime.availableProcessors()` may be redefined by an agent so that its value is not aligned with `active_processor_count()`. Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 198:

> 196:   virtual void post_run();
> 197: public:
> 198:   virtual const char* name() const { return "JFR CPU Time Thread Sampler"; }

Thread name is too long and does not sound right. Logically, it is not "Thread Sampler", but rather "Sampler Thread", which also aligns with the existing "JFR Sampler Thread". But I'd simplify it to `JFR CPU Time Sampler` or maybe `JFR CPU Sampler Thread`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 202:

> 200:   void run();
> 201:   void on_javathread_create(JavaThread* thread);
> 202:   bool create_timer_for_thread(JavaThread* thread, timer_t &timerid);

Should it be `private`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 252:

> 250:   timer_delete(*timer);
> 251:   tl->unset_cpu_timer();
> 252:   tl->deallocate_cpu_time_jfr_queue();

Either this line is not needed or there is a possible resource leak: if `create_timer_for_thread` fails, queue is allocated but not deallocated.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:

> 279:     stop_timer();
> 280:     Atomic::store(&_stop_signals, true);
> 281:     while (Atomic::load_acquire(&_active_signal_handlers) > 0) {

There can be a race when `handle_timer_signal` has already passed `_stop_signals` check but has not yet incremented `_active_signal_handlers`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 308:

> 306: 
> 307:     if (Atomic::load_acquire(&_is_async_processing_of_cpu_time_jfr_requests_triggered)) {
> 308:       Atomic::release_store(&_is_async_processing_of_cpu_time_jfr_requests_triggered, false);

acquire/release seem to be used for no good reason. Also, this could be a single `cmpxchg`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 326:

> 324:       if (jt->thread_state() != _thread_in_native || !tl->try_acquire_cpu_time_jfr_dequeue_lock()) {
> 325:         tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 326:         continue; // thread doesn't have a last Java frame or queue is already being processed

This comment may sound confusing, since `has_last_Java_frame` is checked separately below.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:

> 470: 
> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
> 472:   assert(_instance != nullptr, "invariant");

There can be an arbitrary delay in async signal delivery.
It's unlikely, but not impossible for `_instance` to be deleted by the time signal handler is called. There should be a better way to synchronize with JFR shutdown.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 477:

> 475: 
> 476: 
> 477: void JfrCPUTimeThreadSampling::handle_timer_signal(siginfo_t* info, void* context) {

It may be a good idea to validate `info->si_code` in order to protect from things like `kill -SIGPROF` after profiling has stopped. For a similar reason, `_sampler->_stop_signals` should default to `true` whenever profiler is not running.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 509:

> 507:   JfrCPUTimeTraceQueue& queue = tl->cpu_time_jfr_queue();
> 508:   if (!check_state(jt)) {
> 509:       queue.increment_lost_samples();

nit: wrong indent

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 576:

> 574:   }
> 575:   if (timer_create(clock, &sev, &t) < 0) {
> 576:     log_error(jfr)("Failed to register the signal handler for thread sampling: %s", os::strerror(os::get_last_error()));

If an application has many threads and current RLIMIT_SIGPENDING is low, logs will be flooded with this error message.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 606:

> 604: void JfrCPUTimeThreadSampler::init_timers() {
> 605:   // install sig handler for sig
> 606:   PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal);

SIGPROF is also used by external profilers. Need to check if SIGPROF handler is already installed and warn user.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 58:

> 56:   volatile u4 _head;
> 57: 
> 58:   volatile s4 _lost_samples;

Why signed int? Can it be negative?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 128:

> 126:   static void send_lost_event(const JfrTicks& time, traceid tid, s4 lost_samples);
> 127: 
> 128:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread

typo: separate

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 558:

> 556: void JfrThreadLocal::set_cpu_timer(timer_t* timer) {
> 557:   if (_cpu_timer == nullptr) {
> 558:     _cpu_timer = JfrCHeapObj::new_array<timer_t>(1);

`timer_t` is a primitive type, at most one machine word. Why extra indirection and allocation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124528320
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124503100
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125157311
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125128723
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125130332
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125190998
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125203700
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125342289
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125249171
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125230422
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125241099
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125320255
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125411074
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125430231
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124507884
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125333563
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125183931

From dholmes at openjdk.org  Wed Jun  4 04:53:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jun 2025 04:53:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@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>
 <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>
 <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@github.com>
Message-ID: <CrLB3PxTonY2tagR-vsH1x3v45HK8ikUTEc0MC11mg8=.fe97c0cf-11b1-42ee-bcdc-113f0464d0ee@github.com>

On Tue, 3 Jun 2025 12:16:32 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>>> Hold on, shouldn't this really be "Lost"? @egahlin and @mgronlun need to chime in here.
>> 
>> Lost might be better.
>> 
>> I wonder if `<Field type="Thread" name="eventThread" label="Thread" />` is needed,  instead of thread = true?
>
>> I wonder if <Field type="Thread" name="eventThread" label="Thread" /> is needed, instead of thread = true?
> 
> We had these discussions before on the old PR and then decided to end up with eventThread (as the other events do to),

@parttimenerd  I would really like to see some kind of design description for this which explains what the threading model is, how the signals are used, and how all the pieces interact. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2938512151

From jbechberger at openjdk.org  Wed Jun  4 05:32:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 05:32:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
Message-ID: <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>

On Wed, 4 Jun 2025 00:13:07 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 161:
> 
>> 159:     return 0;
>> 160:   }
>> 161:   return os::active_processor_count() * 1000000000.0 / rate;
> 
> If sampling period is configured as an absolute number in milliseconds, this value must be passed as is.
> Double conversion via `Runtime.availableProcessors()` / `active_processor_count()` is unobvious and error-prone. First, because of asymmetry: e.g. `Runtime.availableProcessors()` may be redefined by an agent so that its value is not aligned with `active_processor_count()`. Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.

Is this something for a later PR?

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:
> 
>> 279:     stop_timer();
>> 280:     Atomic::store(&_stop_signals, true);
>> 281:     while (Atomic::load_acquire(&_active_signal_handlers) > 0) {
> 
> There can be a race when `handle_timer_signal` has already passed `_stop_signals` check but has not yet incremented `_active_signal_handlers`.

Amy idea on how to fix it?

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:
> 
>> 470: 
>> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
>> 472:   assert(_instance != nullptr, "invariant");
> 
> There can be an arbitrary delay in async signal delivery.
> It's unlikely, but not impossible for `_instance` to be deleted by the time signal handler is called. There should be a better way to synchronize with JFR shutdown.

Any ideas? Or is it something for a later PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125678084
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125680345
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125681876

From jbechberger at openjdk.org  Wed Jun  4 06:02:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:02:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <CrLB3PxTonY2tagR-vsH1x3v45HK8ikUTEc0MC11mg8=.fe97c0cf-11b1-42ee-bcdc-113f0464d0ee@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>
 <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>
 <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@github.com>
 <CrLB3PxTonY2tagR-vsH1x3v45HK8ikUTEc0MC11mg8=.fe97c0cf-11b1-42ee-bcdc-113f0464d0ee@github.com>
Message-ID: <81dLp_39MhU-TuDD3EDt7iTX8HyEDZfj6nvCPwE5Ol4=.7d564cda-b7ae-4623-9705-704770b2b118@github.com>

On Wed, 4 Jun 2025 04:50:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I wonder if <Field type="Thread" name="eventThread" label="Thread" /> is needed, instead of thread = true?
>> 
>> We had these discussions before on the old PR and then decided to end up with eventThread (as the other events do to),
>
> @parttimenerd  I would really like to see some kind of design description for this which explains what the threading model is, how the signals are used, and how all the pieces interact. Thanks

@dholmes-ora I attempt a first version here:

The design consists of four main parts:
- setup code: This sets up the signal handlers for every new thread and deletes them afterwards
- the per-thread signal handlers: They check first that the current thread is valid, increment that they are currently active and check that they shouldn't stop (because the profiler is disabled). Now they acquire the thread-local enqueue lock for the current thread's request queue and push the sampling requests in (see https://openjdk.org/jeps/518 + the current period). It triggers/arms a safepoint. If the current thread is in native, they trigger (set a flag) the asynchronous stackwalking. This prevents long native periods of overflowing the request queue. Finally, the enqueue lock is released.
- the safepoint handler: In the safepoint handler, we check if the thread-local queue is not empty. If so, we acquire a dequeue lock and process all entries of the queue, thereby creating JFR events. We also untrigger the async-stack-walking request for the thread. We then release the lock.
- the sampler thread: Its task is to regularly update the timers if needed (configuration changes) and to walk the thread list to find any task that wants to be asynchronously stack-walked. For every of these threads, the dequeue lock is acquired (skipping if already set to enqueue) and the queue is processed as at the safepoint. Then the lock is released.

On shutdown: Whenever the sampler is shut down, we first set the `_stop_signals` flag to prevent new signal handlers from entering the request creation code (and thereby accessing data structures that we already deallocated), we disable the timers for all threads and then wait till no signal handler is engaged anymore.

It is important to note that there is only one thread-local lock used, but it has three states:
- enqueue
- dequeue
- unlocked

This prevents these phases from overlapping.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2938677600

From jbechberger at openjdk.org  Wed Jun  4 06:10:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:10:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <1RLKF0E-I7CjQRNUqb7k0mEIvoSCO010FUaKnmLVPSI=.4c6876fb-ac9c-47d2-8379-ccafdbdbaabe@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <1RLKF0E-I7CjQRNUqb7k0mEIvoSCO010FUaKnmLVPSI=.4c6876fb-ac9c-47d2-8379-ccafdbdbaabe@github.com>
Message-ID: <mC6pwnHod4ewPHh6ULKKK97AN5LsB6sfqlMFJj7oF6I=.25abb82a-653c-49b0-bccb-fd69c39a3a5d@github.com>

On Tue, 3 Jun 2025 21:42: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:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 520:
> 
>> 518:   // the sampling period might be too low for the current Linux configuration
>> 519:   // so samples might be skipped and we have to compute the actual period
>> 520:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
> 
> Does this calculation have to be done on every signal, by every thread? It seems like something that could be precalculated when the period is set?

This might change dynamically, so probably no. Only caching would work, but this is a small optimization for later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125725230

From jbechberger at openjdk.org  Wed Jun  4 06:34:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:34:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
Message-ID: <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>

On Wed, 4 Jun 2025 05:28:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:
>> 
>>> 279:     stop_timer();
>>> 280:     Atomic::store(&_stop_signals, true);
>>> 281:     while (Atomic::load_acquire(&_active_signal_handlers) > 0) {
>> 
>> There can be a race when `handle_timer_signal` has already passed `_stop_signals` check but has not yet incremented `_active_signal_handlers`.
>
> Amy idea on how to fix it?

I added another _static_stop_signals field which should prevent this.

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:
>> 
>>> 470: 
>>> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
>>> 472:   assert(_instance != nullptr, "invariant");
>> 
>> There can be an arbitrary delay in async signal delivery.
>> It's unlikely, but not impossible for `_instance` to be deleted by the time signal handler is called. There should be a better way to synchronize with JFR shutdown.
>
> Any ideas? Or is it something for a later PR?

I added another `_static_stop_signals` field which should prevent this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125756115
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125755428

From jbechberger at openjdk.org  Wed Jun  4 06:34:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:34:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
Message-ID: <PSQGMGCpH-7_AXOlrjZ1x-loj1PEfQXF1SqA4G4w8B8=.39e6dace-3fe2-43e5-bb70-80f10ba7f7f5@github.com>

On Wed, 4 Jun 2025 00:28:46 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 558:
> 
>> 556: void JfrThreadLocal::set_cpu_timer(timer_t* timer) {
>> 557:   if (_cpu_timer == nullptr) {
>> 558:     _cpu_timer = JfrCHeapObj::new_array<timer_t>(1);
> 
> `timer_t` is a primitive type, at most one machine word. Why extra indirection and allocation?

@mgronlun wanted this indirection to move it abstract from implementation details

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125758074

From jbechberger at openjdk.org  Wed Jun  4 07:00:51 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 07:00:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v43]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ae55610c..55c30aef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=41-42

  Stats: 87 lines in 6 files changed: 26 ins; 10 del; 51 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  Wed Jun  4 08:17:31 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 08:17:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>
Message-ID: <AUdBBwPJHu_G8QgU_RFIH_zuRMBJopJLPYQZCUkHp3U=.a12504ca-8417-4016-b2ce-c9950e27f2a1@github.com>

On Wed, 4 Jun 2025 06:29:59 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Any ideas? Or is it something for a later PR?
>
> I added another `_static_stop_signals` field which should prevent this.

The _instance is only ever deleted in case a JFR startup attempt fails as part of JfrRecorder::create(). The sampler must have a rate and become enrolled to serve clients (by installing timers). The rate is set post JfrRecorder::create() using the setting system, which implies that _instance != nullptr should be invariant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125976370

From jbechberger at openjdk.org  Wed Jun  4 08:21:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 08:21:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <AUdBBwPJHu_G8QgU_RFIH_zuRMBJopJLPYQZCUkHp3U=.a12504ca-8417-4016-b2ce-c9950e27f2a1@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>
 <AUdBBwPJHu_G8QgU_RFIH_zuRMBJopJLPYQZCUkHp3U=.a12504ca-8417-4016-b2ce-c9950e27f2a1@github.com>
Message-ID: <CkrqpqeNd5SCH7AoPHP57IV8Qaa-NFvXmgTHR4CXfIs=.4072dafb-eb41-43c1-b649-5fef4f46b3c2@github.com>

On Wed, 4 Jun 2025 08:14:11 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I added another `_static_stop_signals` field which should prevent this.
>
> The _instance is only ever deleted in case a JFR startup attempt fails as part of JfrRecorder::create(). The sampler must have a rate and become enrolled to serve clients (by installing timers). The rate is set post JfrRecorder::create() using the setting system, which implies that _instance != nullptr should be invariant.

Yes, you're right. I'll update the code and combine `_active_signal_handlers` and `_stop_signals` in one, so that a CAS loop prevents `_active_signal_handlers` from being incremented when `_stop_signals` is true. This should solve the other data race.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125985412

From mgronlun at openjdk.org  Wed Jun  4 08:22:21 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 08:22:21 GMT
Subject: Integrated: 8357671: JFR: Remove JfrTraceIdEpoch synchronizing
In-Reply-To: <4FuUPlh3piGBRKq_6BggDdyQviABYNk66rTV97rYaTs=.227185d8-81a8-49eb-a7e8-e70ce6cbf2b0@github.com>
References: <4FuUPlh3piGBRKq_6BggDdyQviABYNk66rTV97rYaTs=.227185d8-81a8-49eb-a7e8-e70ce6cbf2b0@github.com>
Message-ID: <icxXXy8sTL0-S4cYIuXHISVo63eJKozTFU4G9BWrXto=.339acac2-0102-4128-b052-8e5c782d19e8@github.com>

On Tue, 3 Jun 2025 18:09:22 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> The JfrTraceIdEpoch::is_synchronizing() method and the field _synchronizing are remnants from the old days when we attempted to force CompilerThreads running in native mode into the correct epoch, which ultimately failed due to races.
> 
> Removing all that old cruft. Also, reuse the existing epoch generation value for the string pool.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 955bfcd5
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/955bfcd5502b3555c2c91db876be8e7535f2289a
Stats:     52 lines in 7 files changed: 1 ins; 29 del; 22 mod

8357671: JFR: Remove JfrTraceIdEpoch synchronizing

Reviewed-by: egahlin

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

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

From mgronlun at openjdk.org  Wed Jun  4 08:23:26 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 08:23:26 GMT
Subject: Integrated: 8358429: JFR: minimize the time the Threads_lock is held
 for sampling
In-Reply-To: <Q5c8lt88lTjS7YPec5D8fEspUjB4-Nyrfelxx0jtk9o=.cd422b75-5609-4663-87ad-6608ccc13e1f@github.com>
References: <Q5c8lt88lTjS7YPec5D8fEspUjB4-Nyrfelxx0jtk9o=.cd422b75-5609-4663-87ad-6608ccc13e1f@github.com>
Message-ID: <98Xo5Tyi3O-uyYygRuySHcU-FBx4w1Bmu8ciZvKxkh4=.a1c1838e-0e23-4240-81a7-4fdea7822228@github.com>

On Mon, 2 Jun 2025 23:17:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Before [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), the JFR Sampler Thread held onto the Threads_lock during the entire sampling period when iterating threads.
> 
> This was for two purposes:
> 
> 1. Having a non-Java thread sampler thread race through an ongoing safepoint, touching oops is generally not supported by most GCs.
> 2. Since the sampler thread is a non-Java thread, and a JavaThread to be sampled can be in thread state _thread_in_native, it means both threads are outside the safepoint protocol. JFR evolves its global epoch during a safepoint.
> 
> With [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251), things have improved much. The sampling parts performed by the non-Java sampler thread do not touch any oops for threads sampled in state _thread_in_Java.
> For sampling threads in native, the original issue persists (the sampler thread needs to capture the stack trace in the correct JFR epoch, and will also, in the case of virtual threads, need to touch oops).
> 
> However, we can significantly reduce the time the Threads_lock is held for sampling.
> 
> Testing: jdk_jfr, stress testing
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: b6d60280
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6d60280e789436c7f9e3cd1447c8f77b77e77b4
Stats:     165 lines in 4 files changed: 102 ins; 19 del; 44 mod

8358429: JFR: minimize the time the Threads_lock is held for sampling

Reviewed-by: egahlin

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

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

From mgronlun at openjdk.org  Wed Jun  4 08:43:37 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 08:43:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
Message-ID: <jkO0SbSmolLqmXPMAojUSak8QgB5xQYqttBaGZAgs0w=.9ba426c9-f5c6-44ea-9db3-0397f1daa0aa@github.com>

On Wed, 4 Jun 2025 03:07:52 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 606:
> 
>> 604: void JfrCPUTimeThreadSampler::init_timers() {
>> 605:   // install sig handler for sig
>> 606:   PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal);
> 
> SIGPROF is also used by external profilers. Need to check if SIGPROF handler is already installed and warn user.

This is *very* important to have a robust failure mechanism when existing handlers are already installed. Why? JFR can be turned on dynamically from the outside, at any time, during runtime. A lot of agents could have installed their handlers by then.

Please describe how you intend to handle the case where someone starts JFR late during runtime and the signal handler cannot be installed.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 128:
> 
>> 126:   static void send_lost_event(const JfrTicks& time, traceid tid, s4 lost_samples);
>> 127: 
>> 128:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread
> 
> typo: separate

And again, its not "sampling" that is triggered. It is async processing of the queue holding existing samples.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126029865
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126025355

From jbechberger at openjdk.org  Wed Jun  4 11:13:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:13:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v44]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <35LXUV5UP0dcnU2ImfP7ny2SyPmJBTYhRT6JbADqWA4=.22d4360e-639c-4e65-86a3-62aad45a2606@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:

 - Add error message on signal handler install failure
 - Fix signal handler synchronization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/55c30aef..4a258e96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=42-43

  Stats: 71 lines in 2 files changed: 44 ins; 19 del; 8 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 Jun  4 11:13:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:13:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <jkO0SbSmolLqmXPMAojUSak8QgB5xQYqttBaGZAgs0w=.9ba426c9-f5c6-44ea-9db3-0397f1daa0aa@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <jkO0SbSmolLqmXPMAojUSak8QgB5xQYqttBaGZAgs0w=.9ba426c9-f5c6-44ea-9db3-0397f1daa0aa@github.com>
Message-ID: <YynPzC8e9wMwYPtS-3OJ6z7Mp9UYJXfbsqB6qyYG3qc=.c8c6c5e0-6b9b-440d-b74e-78c24a2a3cb8@github.com>

On Wed, 4 Jun 2025 08:40:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 606:
>> 
>>> 604: void JfrCPUTimeThreadSampler::init_timers() {
>>> 605:   // install sig handler for sig
>>> 606:   PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal);
>> 
>> SIGPROF is also used by external profilers. Need to check if SIGPROF handler is already installed and warn user.
>
> This is *very* important to have a robust failure mechanism when existing handlers are already installed. Why? JFR can be turned on dynamically from the outside, at any time, during runtime. A lot of agents could have installed their handlers by then.
> 
> Please describe how you intend to handle the case where someone starts JFR late during runtime and the signal handler cannot be installed.

I added a log_error to tell the user

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 128:
>> 
>>> 126:   static void send_lost_event(const JfrTicks& time, traceid tid, s4 lost_samples);
>>> 127: 
>>> 128:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread
>> 
>> typo: separate
>
> And again, its not "sampling" that is triggered. It is async processing of the queue holding existing samples.

I removed the comment, as the method name itself is pretty self-explanatory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126330036
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126332382

From jbechberger at openjdk.org  Wed Jun  4 11:18:52 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:18:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@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 127 commits:

 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Add error message on signal handler install failure
 - Fix signal handler synchronization
 - Improve
 - Rename autoadapt
 - Make process_cpu_time_request private and move up
 - Reorder condition
 - Tiny refactoring
 - Restrict threads for which timers are created
 - Fix tiny mistake
 - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=44
  Stats: 2308 lines in 39 files changed: 2164 ins; 128 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 Jun  4 11:28:51 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:28:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@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 error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/4fd4b673..8fe07614

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=44-45

  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 apangin at openjdk.org  Wed Jun  4 11:28:51 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 11:28:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
Message-ID: <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>

On Wed, 4 Jun 2025 05:26:42 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 161:
>> 
>>> 159:     return 0;
>>> 160:   }
>>> 161:   return os::active_processor_count() * 1000000000.0 / rate;
>> 
>> If sampling period is configured as an absolute number in milliseconds, this value must be passed as is.
>> Double conversion via `Runtime.availableProcessors()` / `active_processor_count()` is unobvious and error-prone. First, because of asymmetry: e.g. `Runtime.availableProcessors()` may be redefined by an agent so that its value is not aligned with `active_processor_count()`. Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.
>
> Is this something for a later PR?

I'm OK with fixing this separately.

>> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 558:
>> 
>>> 556: void JfrThreadLocal::set_cpu_timer(timer_t* timer) {
>>> 557:   if (_cpu_timer == nullptr) {
>>> 558:     _cpu_timer = JfrCHeapObj::new_array<timer_t>(1);
>> 
>> `timer_t` is a primitive type, at most one machine word. Why extra indirection and allocation?
>
> @mgronlun wanted this indirection to move it abstract from implementation details

I don't see how it is an abstraction when the pointer still has concrete `timer_t` type.
All POSIX timer functions accept `timer_t` rather than `timer_t*`.
This is not a big issue, though, just a minor inefficiency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126360330
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126304082

From apangin at openjdk.org  Wed Jun  4 11:28:52 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 11:28:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v43]
In-Reply-To: <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@github.com>
Message-ID: <uYwvyjIRqoj8BqdtAmAA5MbkuKNKG6Z-ywnsoKN3YF8=.d36d8579-e1d7-45c3-8991-d3bbb5c7a303@github.com>

On Wed, 4 Jun 2025 07:00:51 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:
> 
>   Improve

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 238:

> 236:   tl->cpu_time_jfr_queue().resize_for_period(_current_sampling_period_ns / 1000000);
> 237:   timer_t timerid;
> 238:   if (create_timer_for_thread(thread, timerid)) {

Timer creation failure is not an impossible situation, we should somehow let user know that not all threads are being profiled but without flooding in logs. One warning per profiling session may be a good compromise.
You can verify failure condition by setting low `ulimit -i`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 492:

> 490:   assert(_sampler != nullptr, "invariant");
> 491:   if (info->si_signo != SIGPROF) {
> 492:     // not the signal we are interested in

No, I meant checking `si_code`. `si_signo` will always be the right one.
And this check should come first, before any assertions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126338737
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126316533

From apangin at openjdk.org  Wed Jun  4 11:28:54 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 11:28:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
Message-ID: <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>

On Wed, 4 Jun 2025 11:18:52 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 with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
> 
>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>  - Add error message on signal handler install failure
>  - Fix signal handler synchronization
>  - Improve
>  - Rename autoadapt
>  - Make process_cpu_time_request private and move up
>  - Reorder condition
>  - Tiny refactoring
>  - Restrict threads for which timers are created
>  - Fix tiny mistake
>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 611:

> 609:   // increment the count of active signal handlers
> 610:   u4 old_value = Atomic::fetch_then_add(&_active_signal_handlers, (u4)1, memory_order_acq_rel);
> 611:   if ((old_value & STOP_SIGNAL_BIT) != 0) {

Combining stop signal with a counter is nice, you can then use `Atomic::cmpxchg` to avoid incrementing counter when the stop bit is set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126354062

From mgronlun at openjdk.org  Wed Jun  4 11:28:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 11:28:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
Message-ID: <r6xxXYeirwBZWWCyzM9fRE6OI-2b1wRK406TY4J5AYM=.4f71451f-8790-4025-87f1-2e879015734f@github.com>

On Wed, 4 Jun 2025 11:18:52 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 with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
> 
>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>  - Add error message on signal handler install failure
>  - Fix signal handler synchronization
>  - Improve
>  - Rename autoadapt
>  - Make process_cpu_time_request private and move up
>  - Reorder condition
>  - Tiny refactoring
>  - Restrict threads for which timers are created
>  - Fix tiny mistake
>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 647:

> 645:   // install sig handler for sig
> 646:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
> 647:     log_error(jfr)("Failed to install signal handler for CPU thread sampling, possibly because another profiler is active: %s", os::strerror(os::get_last_error()));

That we are using a signal handler to provide the user with CPU time information is an implementation detail. Its good to provide an error message, but I think it should reflect back on something the user is expecting.

Perhaps add a line that says something along the lines of "CPUTimeSample events will not be recorded."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126357345

From jbechberger at openjdk.org  Wed Jun  4 11:28:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:28:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <r6xxXYeirwBZWWCyzM9fRE6OI-2b1wRK406TY4J5AYM=.4f71451f-8790-4025-87f1-2e879015734f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
 <r6xxXYeirwBZWWCyzM9fRE6OI-2b1wRK406TY4J5AYM=.4f71451f-8790-4025-87f1-2e879015734f@github.com>
Message-ID: <1vlVzhpxsamhKyaKX4ixcG-JZj4Qxgc0Au3mEnjs_So=.91d8a5a1-7b1b-46c6-991c-a5c61c77e39e@github.com>

On Wed, 4 Jun 2025 11:23:57 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
>> 
>>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>>  - Add error message on signal handler install failure
>>  - Fix signal handler synchronization
>>  - Improve
>>  - Rename autoadapt
>>  - Make process_cpu_time_request private and move up
>>  - Reorder condition
>>  - Tiny refactoring
>>  - Restrict threads for which timers are created
>>  - Fix tiny mistake
>>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 647:
> 
>> 645:   // install sig handler for sig
>> 646:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
>> 647:     log_error(jfr)("Failed to install signal handler for CPU thread sampling, possibly because another profiler is active: %s", os::strerror(os::get_last_error()));
> 
> That we are using a signal handler to provide the user with CPU time information is an implementation detail. Its good to provide an error message, but I think it should reflect back on something the user is expecting.
> 
> Perhaps add a line that says something along the lines of "CPUTimeSample events will not be recorded."

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126360801

From egahlin at openjdk.org  Wed Jun  4 11:34:24 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 11:34:24 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

@AlanBateman Do you have time for a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939669198

From jbechberger at openjdk.org  Wed Jun  4 11:37:34 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:37:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v43]
In-Reply-To: <uYwvyjIRqoj8BqdtAmAA5MbkuKNKG6Z-ywnsoKN3YF8=.d36d8579-e1d7-45c3-8991-d3bbb5c7a303@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@github.com>
 <uYwvyjIRqoj8BqdtAmAA5MbkuKNKG6Z-ywnsoKN3YF8=.d36d8579-e1d7-45c3-8991-d3bbb5c7a303@github.com>
Message-ID: <3tt6-HjldmHpRIKHFqWHaLcC7FRZLwiCZl__j7Ht7Gw=.a14d3aa8-4780-49e2-b9ec-d24a828a1948@github.com>

On Wed, 4 Jun 2025 11:13:30 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 238:
> 
>> 236:   tl->cpu_time_jfr_queue().resize_for_period(_current_sampling_period_ns / 1000000);
>> 237:   timer_t timerid;
>> 238:   if (create_timer_for_thread(thread, timerid)) {
> 
> Timer creation failure is not an impossible situation, we should somehow let user know that not all threads are being profiled but without flooding in logs. One warning per profiling session may be a good compromise.
> You can verify failure condition by setting low `ulimit -i`.

I added a "Failed to create timer for a thread" warning

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126373721

From jbechberger at openjdk.org  Wed Jun  4 11:37:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:37:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
 <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>
Message-ID: <URHFhmpIcFdnX3d29D57R_JJ76hBo7gAm9zXGOfLxZs=.4aed11f9-2afa-417c-b67c-60fb2806a0bb@github.com>

On Wed, 4 Jun 2025 11:21:57 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
>> 
>>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>>  - Add error message on signal handler install failure
>>  - Fix signal handler synchronization
>>  - Improve
>>  - Rename autoadapt
>>  - Make process_cpu_time_request private and move up
>>  - Reorder condition
>>  - Tiny refactoring
>>  - Restrict threads for which timers are created
>>  - Fix tiny mistake
>>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 611:
> 
>> 609:   // increment the count of active signal handlers
>> 610:   u4 old_value = Atomic::fetch_then_add(&_active_signal_handlers, (u4)1, memory_order_acq_rel);
>> 611:   if ((old_value & STOP_SIGNAL_BIT) != 0) {
> 
> Combining stop signal with a counter is nice, you can then use `Atomic::cmpxchg` to avoid incrementing counter when the stop bit is set.

I don't see how `Atomic::cmpxchg` would make the code easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126375482

From dtabata at openjdk.org  Wed Jun  4 11:43:31 2025
From: dtabata at openjdk.org (Daishi Tabata)
Date: Wed, 4 Jun 2025 11:43:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
Message-ID: <SBMAGcag8zgg4wJ5-mKhtJJT9GKydtBebIg8D_CJmqI=.f5178cd8-1ba9-4c01-b220-12f90840eb22@github.com>

On Wed, 4 Jun 2025 11:28:51 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:
> 
>   Improve error message

https://github.com/openjdk/jdk/pull/25302/commits/a419dabab213e78a2ff7f3c62cd4af72a0fdabed
Since the implementation has changed from Loss to Lost, the JEP document needs to be changed back to the original, Lost.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2939698219

From jbechberger at openjdk.org  Wed Jun  4 11:43:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:43:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <URHFhmpIcFdnX3d29D57R_JJ76hBo7gAm9zXGOfLxZs=.4aed11f9-2afa-417c-b67c-60fb2806a0bb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
 <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>
 <URHFhmpIcFdnX3d29D57R_JJ76hBo7gAm9zXGOfLxZs=.4aed11f9-2afa-417c-b67c-60fb2806a0bb@github.com>
Message-ID: <6e2kCVaBWwL4UY_zXxuwRDYQKksbEo_uaRH7P8gBDJU=.f52500af-d413-4b2e-bc19-32d2248aa48e@github.com>

On Wed, 4 Jun 2025 11:34:44 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 611:
>> 
>>> 609:   // increment the count of active signal handlers
>>> 610:   u4 old_value = Atomic::fetch_then_add(&_active_signal_handlers, (u4)1, memory_order_acq_rel);
>>> 611:   if ((old_value & STOP_SIGNAL_BIT) != 0) {
>> 
>> Combining stop signal with a counter is nice, you can then use `Atomic::cmpxchg` to avoid incrementing counter when the stop bit is set.
>
> I don't see how `Atomic::cmpxchg` would make the code easier.

With my current code, I avoid having a loop, and in the fast path, I only have one atomic instruction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126383576

From jbechberger at openjdk.org  Wed Jun  4 11:49:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:49:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
Message-ID: <kNwYb_xwjLiKCL5w0DxTdCkfwonsejfo3vaggLM1os4=.2eab93e1-efb6-4a23-b446-2fa95572582c@github.com>

On Wed, 4 Jun 2025 11:28:51 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:
> 
>   Improve error message

> [a419dab](https://github.com/openjdk/jdk/commit/a419dabab213e78a2ff7f3c62cd4af72a0fdabed)
> Since the implementation has changed from Loss to Lost, the JEP document needs to be changed back to the original, Lost.

Good catch, I updated the JEP.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2939723399

From jbechberger at openjdk.org  Wed Jun  4 12:05:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:05:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v47]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <7XHQamQvo__d4VCHVNQQqwNEmPLoKh8wtpES1a3ZRDg=.2bc3d95c-c00d-4487-90e2-2341a8da9173@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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8fe07614..fe53990d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=45-46

  Stats: 11 lines in 1 file changed: 8 ins; 1 del; 2 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  Wed Jun  4 12:05:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 12:05:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
Message-ID: <RtuCzD-Jwn5fKo8_9p06yAMQaH8IAA2T3rcanP3DAIA=.6fdd2062-b006-4cd9-b713-ea3143961f93@github.com>

On Wed, 4 Jun 2025 11:28:51 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:
> 
>   Improve error message

I am approving this PR for the following reasons:

1. We have reached a state that is "good enough" - I no longer see any fundamental design issues that can not be handled by follow-up bug fixes.
2. There are still many vague aspects included with this PR, as many has already pointed out, mostly related to the memory model and thread interactions - all those can, and should, be clarified, explained and exacted post-integration.
3. The feature as a whole is experimental and turned off by default.
4. Today is the penultimate day before JDK 25 cutoff. To give the feature a fair chance for making JDK25, it needs approval now.

Thanks a lot Johannes and all involved for your hard work getting this feature ready.

Many thanks
Markus

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896467191

From jbechberger at openjdk.org  Wed Jun  4 12:10:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:10:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@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 timer creation warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/fe53990d..8d545e74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=46-47

  Stats: 4 lines in 1 file changed: 0 ins; 1 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 alanb at openjdk.org  Wed Jun  4 12:10:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 12:10:20 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
Message-ID: <us23R2nkGfg4Fisd7aTuf2-qDgnmaTn7sbqe0wuvphc=.ee7dcfdb-ae16-4f97-bae6-0328079a09ed@github.com>

On Wed, 4 Jun 2025 11:31:21 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> @AlanBateman Do you have time for a review?

Yes, looking at the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939787559

From jbechberger at openjdk.org  Wed Jun  4 12:23:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:23:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v49]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <4aLbfK7e6pncU0QwXORueBxt8WEOz5KYO1pKnpjFOC0=.cf78fb29-a30f-4084-bee7-76c1e6e81f31@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 build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8d545e74..fbaf1da6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=47-48

  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 apangin at openjdk.org  Wed Jun  4 12:38:21 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 12:38:21 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
Message-ID: <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>

On Wed, 4 Jun 2025 12:10:17 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 timer creation warning

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 491:

> 489: 
> 490: void JfrCPUTimeThreadSampling::handle_timer_signal(siginfo_t* info, void* context) {
> 491:   if (info->si_code != SIGPROF) {

The correct check is
`if (info->si_code != SI_TIMER)`

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 652:

> 650: bool JfrCPUSamplerThread::init_timers() {
> 651:   // install sig handler for sig
> 652:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {

Comparing return value to `(void*)-1` would be cleaner.
But the main problem is that it only checks for `sigaction` failure (which normally never happens), however, we should also check if there was a custom signal handler set _before_ installing our own handler, i.e. old handler is not SIG_IGN or SIG_DFL or `handle_timer_signal`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126447823
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126488937

From jbechberger at openjdk.org  Wed Jun  4 12:47:36 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:47:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
 <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
Message-ID: <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>

On Wed, 4 Jun 2025 12:33:45 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix timer creation warning
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 652:
> 
>> 650: bool JfrCPUSamplerThread::init_timers() {
>> 651:   // install sig handler for sig
>> 652:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
> 
> Comparing return value to `(void*)-1` would be cleaner.
> But the main problem is that it only checks for `sigaction` failure (which normally never happens), however, we should also check if there was a custom signal handler set _before_ installing our own handler, i.e. old handler is not SIG_IGN or SIG_DFL or `handle_timer_signal`.

Using `sigaction(SIG, NULL, &sa)` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126510947

From jbechberger at openjdk.org  Wed Jun  4 12:56:22 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:56:22 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@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 build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/fbaf1da6..e4558a6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=48-49

  Stats: 3 lines in 1 file changed: 0 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 jbechberger at openjdk.org  Wed Jun  4 13:07:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 13:07:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
 <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
 <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>
Message-ID: <-JmnqMbD8vGy_dVeVUv59WrjuCavWV3F3w9HMTxhAQM=.2c079574-0729-4c70-af86-946a3204f7b6@github.com>

On Wed, 4 Jun 2025 12:44:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 652:
>> 
>>> 650: bool JfrCPUSamplerThread::init_timers() {
>>> 651:   // install sig handler for sig
>>> 652:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
>> 
>> Comparing return value to `(void*)-1` would be cleaner.
>> But the main problem is that it only checks for `sigaction` failure (which normally never happens), however, we should also check if there was a custom signal handler set _before_ installing our own handler, i.e. old handler is not SIG_IGN or SIG_DFL or `handle_timer_signal`.
>
> Using `sigaction(SIG, NULL, &sa)` ?

I'm currently implementing the check against SIG_IGN and SIG_DFL, as `handle_timer_signal` should never occur.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126551278

From egahlin at openjdk.org  Wed Jun  4 13:19:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 13:19:36 GMT
Subject: RFR: 8358590: JFR: Include min and max in MethodTiming event
Message-ID: <DU3oC0CKpsQqGBEFsi4CHICb3HQwumcEzWeJnwHsj3g=.74776cd3-8c05-4f79-8a3c-336c3c9d49db@github.com>

Could I have review of this PR that adds minimum and maximum to the MethodTimingEvent.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25637/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358590
  Stats: 49 lines in 6 files changed: 42 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25637/head:pull/25637

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

From egahlin at openjdk.org  Wed Jun  4 13:19:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 13:19:49 GMT
Subject: RFR: 8358536: jdk/jfr/api/consumer/TestRecordingFileWrite.java times
 out
Message-ID: <3mPIkzXdn_aYsY5Xw0Ovqj-NQZqthFB4EKt7Oter6kg=.9c21d13e-1aac-4356-8b09-bf1dcb5e73a1@github.com>

Could I have a review of the PR that fixes a regression caused by [JDK-8356698](https://bugs.openjdk.org/browse/JDK-8356698)?

The problem is that PrettyWriter is also used by RecordedObject::toString, and by allocating the priority queue when PrettyWriter is instantiated, the memory pressure increases enormously. The fix is to allocate them lazily. 

Testing: 10 * jdk/jdk/jfr/ on Linux, MacOS and Windows.

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Wed Jun  4 13:19:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 13:19:50 GMT
Subject: RFR: 8358536: jdk/jfr/api/consumer/TestRecordingFileWrite.java
 times out
In-Reply-To: <3mPIkzXdn_aYsY5Xw0Ovqj-NQZqthFB4EKt7Oter6kg=.9c21d13e-1aac-4356-8b09-bf1dcb5e73a1@github.com>
References: <3mPIkzXdn_aYsY5Xw0Ovqj-NQZqthFB4EKt7Oter6kg=.9c21d13e-1aac-4356-8b09-bf1dcb5e73a1@github.com>
Message-ID: <WY-pbOoMALvQInEUyA8tpmvEcyTwY-eiNTrDW6GOjM8=.3d251fc0-99a4-41b2-b6d1-dbe0af19cc21@github.com>

On Wed, 4 Jun 2025 04:15:12 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the PR that fixes a regression caused by [JDK-8356698](https://bugs.openjdk.org/browse/JDK-8356698)?
> 
> The problem is that PrettyWriter is also used by RecordedObject::toString, and by allocating the priority queue when PrettyWriter is instantiated, the memory pressure increases enormously. The fix is to allocate them lazily. 
> 
> Testing: 10 * jdk/jdk/jfr/ on Linux, MacOS and Windows.
> 
> Thanks
> Erik

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25633#pullrequestreview-2896381131

From egahlin at openjdk.org  Wed Jun  4 13:41:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 13:41:55 GMT
Subject: Integrated: 8358536: jdk/jfr/api/consumer/TestRecordingFileWrite.java
 times out
In-Reply-To: <3mPIkzXdn_aYsY5Xw0Ovqj-NQZqthFB4EKt7Oter6kg=.9c21d13e-1aac-4356-8b09-bf1dcb5e73a1@github.com>
References: <3mPIkzXdn_aYsY5Xw0Ovqj-NQZqthFB4EKt7Oter6kg=.9c21d13e-1aac-4356-8b09-bf1dcb5e73a1@github.com>
Message-ID: <bNm-cwPh_PPUtQX-eNJriNrUZuPLZpfA3Jk1xxYNYqk=.549c8670-cd0f-40ec-a976-723b7196c896@github.com>

On Wed, 4 Jun 2025 04:15:12 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the PR that fixes a regression caused by [JDK-8356698](https://bugs.openjdk.org/browse/JDK-8356698)?
> 
> The problem is that PrettyWriter is also used by RecordedObject::toString, and by allocating the priority queue when PrettyWriter is instantiated, the memory pressure increases enormously. The fix is to allocate them lazily. 
> 
> Testing: 10 * jdk/jdk/jfr/ on Linux, MacOS and Windows.
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: a653ff48
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a653ff48933bfd72c7c3d004ccc5bd0d9c1162cb
Stats:     10 lines in 2 files changed: 6 ins; 4 del; 0 mod

8358536: jdk/jfr/api/consumer/TestRecordingFileWrite.java times out

Reviewed-by: mgronlun

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

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

From mdoerr at openjdk.org  Wed Jun  4 14:01:16 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Jun 2025 14:01:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
Message-ID: <YKYZ-XyOaQP9gG1Mr4xbFzNC2cE1fvHbsuNyQDR21n4=.c396c57b-6575-44ed-891d-ae16e5cea22c@github.com>

On Wed, 4 Jun 2025 12:56:22 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 build

I've looked over it and couldn't spot any critical issue. I think it's good enough for an experimental feature if we do further cleanups and improvements later.
What I'd like to see as a follow-up is a review of the usage of `Atomic` functions. I've never seen so many of them in such a density.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896853345

From mgronlun at openjdk.org  Wed Jun  4 14:04:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 14:04:50 GMT
Subject: RFR: 8358590: JFR: Include min and max in MethodTiming event
In-Reply-To: <DU3oC0CKpsQqGBEFsi4CHICb3HQwumcEzWeJnwHsj3g=.74776cd3-8c05-4f79-8a3c-336c3c9d49db@github.com>
References: <DU3oC0CKpsQqGBEFsi4CHICb3HQwumcEzWeJnwHsj3g=.74776cd3-8c05-4f79-8a3c-336c3c9d49db@github.com>
Message-ID: <EiKZLGpFf99k79XcwbrkVSX3an6S5-VojjbgaQZcffM=.c2b3d5c2-a589-4af1-a480-e7d2221e9a21@github.com>

On Wed, 4 Jun 2025 11:36:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of this PR that adds minimum and maximum to the MethodTimingEvent.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25637#pullrequestreview-2896869984

From pchilanomate at openjdk.org  Wed Jun  4 14:15:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:15:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
Message-ID: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>

On Wed, 4 Jun 2025 12:56:22 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 build

I took a look at this. I only found one issue that needs fixing before integration and then a few comments. Thanks.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 59:

> 57:   Thread* raw_thread = Thread::current_or_null_safe();
> 58:   if (raw_thread == nullptr) {
> 59:     // probably while shutting down

Do you remember which test fail because of this? It would be interesting to know, since I don?t see how it could be null here.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 330:

> 328: void JfrCPUSamplerThread::stackwalk_threads_in_native() {
> 329:   ResourceMark rm;
> 330:   MutexLocker tlock(Threads_lock);

What exactly are we guarding against by holding the `Threads_lock`? Seems `ThreadsListHandle` should be enough.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 430:

> 428: void JfrCPUTimeThreadSampling::create_sampler(double rate, bool auto_adapt) {
> 429:   assert(_sampler == nullptr, "invariant");
> 430:   _sampler = new JfrCPUSamplerThread(rate, auto_adapt);

If we start a recording on an already running process we have a race here where a new thread can create and set its timer before we call init_timers() where the signal handler is installed. In that case the program will terminate with message ?Profiling timer expired" (default action for SIGPROF). It can be easily reproduced by adding a delay here and starting a recording on a simple test that just creates new threads. We need to add some extra check in create_timer_for_thread() or install the signal handler earlier.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 584:

> 582:   sev.sigev_notify = SIGEV_THREAD_ID;
> 583:   sev.sigev_signo = SIG;
> 584:   sev.sigev_value.sival_ptr = &t;

Why setting the address of `t` which is a local variable here?

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896813404
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126661443
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126670024
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126651264
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126666505

From jbechberger at openjdk.org  Wed Jun  4 14:15:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:15:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <-JmnqMbD8vGy_dVeVUv59WrjuCavWV3F3w9HMTxhAQM=.2c079574-0729-4c70-af86-946a3204f7b6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
 <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
 <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>
 <-JmnqMbD8vGy_dVeVUv59WrjuCavWV3F3w9HMTxhAQM=.2c079574-0729-4c70-af86-946a3204f7b6@github.com>
Message-ID: <b-puA8U0ATu7kbUIIgsqrbbUavd5klDl2b-GAsh8vUA=.98fe85f1-01e2-479b-b61b-c265990bffee@github.com>

On Wed, 4 Jun 2025 13:04:28 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Using `sigaction(SIG, NULL, &sa)` ?
>
> I'm currently implementing the check against SIG_IGN and SIG_DFL, as `handle_timer_signal` should never occur.

I implemented what you want. This prevents confusion of users.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126701277

From jbechberger at openjdk.org  Wed Jun  4 14:15:48 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:15:48 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v51]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <L5JSoB8VKtSPrybxRzQinXlzK96mA1Ak3f58KuYKM_g=.ea4aa9b2-d556-4728-be11-efdf0f4d2a74@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:

  Check if signal handler is already installed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/e4558a6e..762da321

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=49-50

  Stats: 14 lines in 3 files changed: 12 ins; 0 del; 2 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 pchilanomate at openjdk.org  Wed Jun  4 14:15:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:15:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>
Message-ID: <Vdk2TBsN_nRj3_l2VB4SyTY_TJh1Bvy7zqwfsILH354=.2f927c67-40d8-4fa8-bb18-70bb5320d332@github.com>

On Mon, 2 Jun 2025 15:13:54 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> So I don't read the ` tl->has_cpu_time_jfr_requests()` twice on the hot-path
>
> Ok, for now. We should try to come up with a better split.

If there are sample requests then we are already in the slow path so loading again `has_cpu_time_jfr_requests()` later won't change anything. My suggestion would be to avoid passing this boolean around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126692802

From jbechberger at openjdk.org  Wed Jun  4 14:21:07 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:21:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
Message-ID: <EDtZkOHaeA3hIKutgg4O1o1mmiG1VhEiG0pBb-LCZy8=.72b00371-19f1-4cf4-ad83-45d96dd20b1e@github.com>

On Wed, 4 Jun 2025 13:51:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 59:
> 
>> 57:   Thread* raw_thread = Thread::current_or_null_safe();
>> 58:   if (raw_thread == nullptr) {
>> 59:     // probably while shutting down
> 
> Do you remember which test fail because of this? It would be interesting to know, since I don?t see how it could be null here.

I just ran the renaissance benchmark with https://github.com/parttimenerd/basic-profiler-tests for a few hours.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126728665

From jbechberger at openjdk.org  Wed Jun  4 14:27:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:27:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
Message-ID: <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>

On Wed, 4 Jun 2025 13:55:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 330:
> 
>> 328: void JfrCPUSamplerThread::stackwalk_threads_in_native() {
>> 329:   ResourceMark rm;
>> 330:   MutexLocker tlock(Threads_lock);
> 
> What exactly are we guarding against by holding the `Threads_lock`? Seems `ThreadsListHandle` should be enough.

You're right.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 584:
> 
>> 582:   sev.sigev_notify = SIGEV_THREAD_ID;
>> 583:   sev.sigev_signo = SIG;
>> 584:   sev.sigev_value.sival_ptr = &t;
> 
> Why setting the address of `t` which is a local variable here?

Because this is how the API works. You store the location where the timer should be stored.

See https://www.man7.org/linux/man-pages/man2/timer_create.2.html for more information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126741491
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126735519

From jbechberger at openjdk.org  Wed Jun  4 14:31:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:31:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <Vdk2TBsN_nRj3_l2VB4SyTY_TJh1Bvy7zqwfsILH354=.2f927c67-40d8-4fa8-bb18-70bb5320d332@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>
 <Vdk2TBsN_nRj3_l2VB4SyTY_TJh1Bvy7zqwfsILH354=.2f927c67-40d8-4fa8-bb18-70bb5320d332@github.com>
Message-ID: <8K2UKh2c90_9WYibMs0LoKZr5GNFAGZkINV11POsvac=.8150ba38-e33e-4780-bb08-2783640b6a3a@github.com>

On Wed, 4 Jun 2025 14:04:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Ok, for now. We should try to come up with a better split.
>
> If there are sample requests then we are already in the slow path so loading again `has_cpu_time_jfr_requests()` later won't change anything. My suggestion would be to avoid passing this boolean around.

I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126751794

From alanb at openjdk.org  Wed Jun  4 14:35:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 14:35:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

src/java.base/share/classes/java/net/Socket.java line 970:

> 968:             long end = SocketReadEvent.timestamp();
> 969:             long duration = end - start;
> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {

The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.

Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:

> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
> 76:      *
> 77:      * @return the throttle value, default {@code "off"} not {@code null}

I think it would be clear to drop "not null" from the return description.

src/jdk.jfr/share/conf/jfr/default.jfc line 762:

> 760:       <setting name="enabled">true</setting>
> 761:       <setting name="stackTrace">true</setting>
> 762:       <setting name="threshold">20 ms</setting>

I agree FileForce isn't a good candidate to throttle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126765474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126722810
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126719134

From jbechberger at openjdk.org  Wed Jun  4 14:45:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:45:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
Message-ID: <ZFbJAFMki4I2l3iekCNiLgPpQZkROMF2j6GIKjCWkQM=.d285a9cc-5279-4ebb-93f2-3605f4e72c66@github.com>

On Wed, 4 Jun 2025 13:47:01 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 430:
> 
>> 428: void JfrCPUTimeThreadSampling::create_sampler(double rate, bool auto_adapt) {
>> 429:   assert(_sampler == nullptr, "invariant");
>> 430:   _sampler = new JfrCPUSamplerThread(rate, auto_adapt);
> 
> If we start a recording on an already running process we have a race here where a new thread can create and set its timer before we call init_timers() where the signal handler is installed. In that case the program will terminate with message ?Profiling timer expired" (default action for SIGPROF). It can be easily reproduced by adding a delay here and starting a recording on a simple test that just creates new threads. We need to add some extra check in create_timer_for_thread() or install the signal handler earlier.

I created a `has_timer` flag that is checked by `create_timer_for_thread()` before creating timers and set by `init_timers`. Is this what you envisioned?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126783367

From pchilanomate at openjdk.org  Wed Jun  4 14:45:21 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:45:21 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
Message-ID: <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>

On Wed, 4 Jun 2025 14:21:31 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 584:
>> 
>>> 582:   sev.sigev_notify = SIGEV_THREAD_ID;
>>> 583:   sev.sigev_signo = SIG;
>>> 584:   sev.sigev_value.sival_ptr = &t;
>> 
>> Why setting the address of `t` which is a local variable here?
>
> Because this is how the API works. You store the location where the timer should be stored.
> 
> See https://www.man7.org/linux/man-pages/man2/timer_create.2.html for more information.

Sorry where does it say that? I think you are looking at the example in that page which makes use of sival_ptr in the signal handler. In that example reading from that timer address in the handler is valid but for us we would be accessing invalid memory. Plus we are not really reading it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126787035

From jbechberger at openjdk.org  Wed Jun  4 14:49:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:49:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
Message-ID: <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>

On Wed, 4 Jun 2025 14:41:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Because this is how the API works. You store the location where the timer should be stored.
>> 
>> See https://www.man7.org/linux/man-pages/man2/timer_create.2.html for more information.
>
> Sorry where does it say that? I think you are looking at the example in that page which makes use of sival_ptr in the signal handler. In that example reading from that timer address in the handler is valid but for us we would be accessing invalid memory. Plus we are not really reading it.

Why would we be accessing invalid memory?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126798263

From jbechberger at openjdk.org  Wed Jun  4 14:59:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v52]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <skECGGRF1Q7nVu1BKWauGA5qz0pkpCKsVYGBuIx3FXg=.d370e0f8-6c3a-47ae-82ef-469121ff62f0@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:

  Small changes
  
  Suggested by @pchilano

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/762da321..20b8db28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=50-51

  Stats: 21 lines in 4 files changed: 6 ins; 4 del; 11 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 Jun  4 14:59:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
Message-ID: <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>

On Wed, 4 Jun 2025 14:46:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Sorry where does it say that? I think you are looking at the example in that page which makes use of sival_ptr in the signal handler. In that example reading from that timer address in the handler is valid but for us we would be accessing invalid memory. Plus we are not really reading it.
>
> Why would we be accessing invalid memory?

Which differences to the example code are you seeing?


 sev.sigev_notify = SIGEV_SIGNAL;
           sev.sigev_signo = SIG;
           sev.sigev_value.sival_ptr = &timerid;
           if (timer_create(CLOCKID, &sev, &timerid) == -1)
               errExit("timer_create");

           printf("timer ID is %#jx\n", (uintmax_t) timerid);

           /* Start the timer. */

           freq_nanosecs = atoll(argv[2]);
           its.it_value.tv_sec = freq_nanosecs / 1000000000;
           its.it_value.tv_nsec = freq_nanosecs % 1000000000;
           its.it_interval.tv_sec = its.it_value.tv_sec;
           its.it_interval.tv_nsec = its.it_value.tv_nsec;



Is similar to:


 ((int*)&sev.sigev_notify)[1] = thread->osthread()->thread_id();
  clockid_t clock;
  int err = pthread_getcpuclockid(thread->osthread()->pthread_id(), &clock);
  if (err != 0) {
    log_error(jfr)("Failed to get clock for thread sampling: %s", os::strerror(err));
    return false;
  }
  if (timer_create(clock, &sev, &t) < 0) {
    return false;
  }
  int64_t period = get_sampling_period();
  if (period != 0) {
    set_timer_time(t, period);
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126810984

From pchilanomate at openjdk.org  Wed Jun  4 14:59:33 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
Message-ID: <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>

On Wed, 4 Jun 2025 14:52:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Why would we be accessing invalid memory?
>
> Which differences to the example code are you seeing?
> 
> 
>  sev.sigev_notify = SIGEV_SIGNAL;
>            sev.sigev_signo = SIG;
>            sev.sigev_value.sival_ptr = &timerid;
>            if (timer_create(CLOCKID, &sev, &timerid) == -1)
>                errExit("timer_create");
> 
>            printf("timer ID is %#jx\n", (uintmax_t) timerid);
> 
>            /* Start the timer. */
> 
>            freq_nanosecs = atoll(argv[2]);
>            its.it_value.tv_sec = freq_nanosecs / 1000000000;
>            its.it_value.tv_nsec = freq_nanosecs % 1000000000;
>            its.it_interval.tv_sec = its.it_value.tv_sec;
>            its.it_interval.tv_nsec = its.it_value.tv_nsec;
> 
> 
> 
> Is similar to:
> 
> 
>  ((int*)&sev.sigev_notify)[1] = thread->osthread()->thread_id();
>   clockid_t clock;
>   int err = pthread_getcpuclockid(thread->osthread()->pthread_id(), &clock);
>   if (err != 0) {
>     log_error(jfr)("Failed to get clock for thread sampling: %s", os::strerror(err));
>     return false;
>   }
>   if (timer_create(clock, &sev, &t) < 0) {
>     return false;
>   }
>   int64_t period = get_sampling_period();
>   if (period != 0) {
>     set_timer_time(t, period);
>   }

The `sigev_value` member is used to pass data that you can read in the signal handler. The address of `t` won't be valid anymore once you return from this function. In that example the address of `timerid ` is still valid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126817165

From jbechberger at openjdk.org  Wed Jun  4 14:59:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
Message-ID: <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>

On Wed, 4 Jun 2025 14:54:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Which differences to the example code are you seeing?
>> 
>> 
>>  sev.sigev_notify = SIGEV_SIGNAL;
>>            sev.sigev_signo = SIG;
>>            sev.sigev_value.sival_ptr = &timerid;
>>            if (timer_create(CLOCKID, &sev, &timerid) == -1)
>>                errExit("timer_create");
>> 
>>            printf("timer ID is %#jx\n", (uintmax_t) timerid);
>> 
>>            /* Start the timer. */
>> 
>>            freq_nanosecs = atoll(argv[2]);
>>            its.it_value.tv_sec = freq_nanosecs / 1000000000;
>>            its.it_value.tv_nsec = freq_nanosecs % 1000000000;
>>            its.it_interval.tv_sec = its.it_value.tv_sec;
>>            its.it_interval.tv_nsec = its.it_value.tv_nsec;
>> 
>> 
>> 
>> Is similar to:
>> 
>> 
>>  ((int*)&sev.sigev_notify)[1] = thread->osthread()->thread_id();
>>   clockid_t clock;
>>   int err = pthread_getcpuclockid(thread->osthread()->pthread_id(), &clock);
>>   if (err != 0) {
>>     log_error(jfr)("Failed to get clock for thread sampling: %s", os::strerror(err));
>>     return false;
>>   }
>>   if (timer_create(clock, &sev, &t) < 0) {
>>     return false;
>>   }
>>   int64_t period = get_sampling_period();
>>   if (period != 0) {
>>     set_timer_time(t, period);
>>   }
>
> The `sigev_value` member is used to pass data that you can read in the signal handler. The address of `t` won't be valid anymore once you return from this function. In that example the address of `timerid ` is still valid.

Why is this a problem? We don't leak `&t` outside of `create_timer_for_thread`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126820560

From jbechberger at openjdk.org  Wed Jun  4 15:06:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:06:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v53]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <40QHcJ9vY8NkXNVIhF-84WqMoSTRwxGsQfENcTJNEHI=.d1753def-3f74-4646-a574-952612dddaec@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 create_timer_for_thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/20b8db28..45f915b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=51-52

  Stats: 5 lines in 1 file changed: 0 ins; 2 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  Wed Jun  4 15:06:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:06:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
Message-ID: <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>

On Wed, 4 Jun 2025 14:56:10 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> The `sigev_value` member is used to pass data that you can read in the signal handler. The address of `t` won't be valid anymore once you return from this function. In that example the address of `timerid ` is still valid.
>
> Why is this a problem? We don't leak `&t` outside of `create_timer_for_thread`.

But I can start using the passed-in parameter `timerid` directly, which should make the code less confusing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126829360

From jbechberger at openjdk.org  Wed Jun  4 15:19:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:19:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
 <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
Message-ID: <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYrV9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>

On Wed, 4 Jun 2025 15:00:07 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Why is this a problem? We don't leak `&t` outside of `create_timer_for_thread`.
>
> But I can start using the passed-in parameter `timerid` directly, which should make the code less confusing.

I pushed the modifications.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126863235

From jbechberger at openjdk.org  Wed Jun  4 15:32:25 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:32:25 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v54]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <8m6_JMIlbofV7pazQz-ZmfzLDOmVt-bXpmOMtQQFhpg=.121c7602-81c0-4a8a-81ea-dc753bd4ca87@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 create_timer_for_thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/45f915b4..8f237898

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=52-53

  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 apangin at openjdk.org  Wed Jun  4 15:32:26 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYrV9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
 <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
 <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYr
 V9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>
Message-ID: <BePzKNIhTPBfpooLDVE1u8PUUdPhWgoohU-3g0eD0Ow=.2ad957e1-054b-4b66-ab4a-cc5bcad2d754@github.com>

On Wed, 4 Jun 2025 15:16:16 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> But I can start using the passed-in parameter `timerid` directly, which should make the code less confusing.
>
> I pushed the modifications.

Simply set `sival_ptr` to `NULL`, the value is never used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126880196

From jbechberger at openjdk.org  Wed Jun  4 15:32:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <BePzKNIhTPBfpooLDVE1u8PUUdPhWgoohU-3g0eD0Ow=.2ad957e1-054b-4b66-ab4a-cc5bcad2d754@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
 <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
 <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYr
 V9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>
 <BePzKNIhTPBfpooLDVE1u8PUUdPhWgoohU-3g0eD0Ow=.2ad957e1-054b-4b66-ab4a-cc5bcad2d754@github.com>
Message-ID: <YlgBcy7lN1pd5zNAF-RwFOvEo9Kmbc-6dhhN2w199mM=.bddce2c1-85da-42e0-851d-32f8f756151c@github.com>

On Wed, 4 Jun 2025 15:23:55 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> I pushed the modifications.
>
> Simply set `sival_ptr` to `NULL`, the value is never used.

You're right, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126886264

From shade at openjdk.org  Wed Jun  4 15:32:26 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
Message-ID: <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>

On Wed, 4 Jun 2025 12:56:22 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 build

Some more cosmetics/nits.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 264:

> 262:   }
> 263:   timer_delete(*timer);
> 264:   tl->unset_cpu_timer();

Should this deletion be right in `unset_cpu_timer`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 729:

> 727: #else
> 728: 
> 729: static bool _showed_warning = false;

`_displayed_warning`? Actually, I think you can move this straight into `warn()` body.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:

> 248:     }
> 249: 
> 250: 

Unnecessary?

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 582:

> 580: }
> 581: 
> 582: bool JfrThreadLocal::acquire_cpu_time_jfr_enqueue_lock() {

This sounds like `try_acquire_cpu_time_jfr_enqueue_lock`, emphasis on `try_`. It does not actually guarantee to lock.

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 586:

> 584: }
> 585: 
> 586: bool JfrThreadLocal::try_acquire_cpu_time_jfr_dequeue_lock() {

...and this one is not `try_`, but the actual "blocking" acquire.

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896958686
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126882197
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126868308
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126736956
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126831195
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126844713

From jbechberger at openjdk.org  Wed Jun  4 15:32:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
Message-ID: <Da68pFmCN9F7Vx-OduGkqSrEZKlday2JavfUUVGf6Fs=.312bd07b-e421-4bb5-a1d2-5490df2c5f74@github.com>

On Wed, 4 Jun 2025 14:22:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:
> 
>> 248:     }
>> 249: 
>> 250: 
> 
> Unnecessary?

Yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126890693

From jbechberger at openjdk.org  Wed Jun  4 15:40:06 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:40:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
Message-ID: <DlRlcXVrIpxbq-tDJaGWxAcy6kzmx7a_8WmRDSqKp8o=.ae9f0ba0-2ecc-45ef-b146-0550219d178f@github.com>

On Wed, 4 Jun 2025 15:07:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 586:
> 
>> 584: }
>> 585: 
>> 586: bool JfrThreadLocal::try_acquire_cpu_time_jfr_dequeue_lock() {
> 
> ...and this one is not `try_`, but the actual "blocking" acquire.

But it fails if the lock state is already on `DEQUEUE`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126907622

From jbechberger at openjdk.org  Wed Jun  4 15:48:31 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:48:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v55]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8f237898..3a486817

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=53-54

  Stats: 11 lines in 4 files changed: 2 ins; 4 del; 5 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 Jun  4 15:59:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 15:59:03 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <wJSneY7Iw7SjTULCVaLikMyjKH7L9q5sn4ZuAQcx8lA=.15ec6ced-d662-474b-99a1-b7937c7ceb68@github.com>

On Wed, 4 Jun 2025 14:16:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:
> 
>> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
>> 76:      *
>> 77:      * @return the throttle value, default {@code "off"} not {@code null}
> 
> I think it would be clearer to drop "not null" from the return description.

We have "not null" with Threshold, but not with "Period". I filed a bug to make it consistent for all JFR annotations and I can bring Throttle into the same CSR. 

https://bugs.openjdk.org/browse/JDK-8358602

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126946237

From egahlin at openjdk.org  Wed Jun  4 16:06:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 16:06:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>

On Wed, 4 Jun 2025 14:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/java.base/share/classes/java/net/Socket.java line 970:
> 
>> 968:             long end = SocketReadEvent.timestamp();
>> 969:             long duration = end - start;
>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
> 
> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
> 
> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.

We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126960704

From mgronlun at openjdk.org  Wed Jun  4 17:09:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 17:09:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
Message-ID: <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>

On Wed, 4 Jun 2025 14:24:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 330:
>> 
>>> 328: void JfrCPUSamplerThread::stackwalk_threads_in_native() {
>>> 329:   ResourceMark rm;
>>> 330:   MutexLocker tlock(Threads_lock);
>> 
>> What exactly are we guarding against by holding the `Threads_lock`? Seems `ThreadsListHandle` should be enough.
>
> You're right.

The Threads_lock is required to prevent JFR from sampling through an ongoing safepoint, touching oops, which is not supported by most GCs as well as JFR evolving its global epoch (happens during safepoint) while both threads are outside the safepoint protocol. Can be optimized (later), see for example: https://github.com/openjdk/jdk/pull/25602

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127062451

From jbechberger at openjdk.org  Wed Jun  4 17:22:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:22:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@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:

  Readd lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/3a486817..53d3ed4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=54-55

  Stats: 1 line in 1 file changed: 1 ins; 0 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 Jun  4 17:22:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:22:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>
Message-ID: <-YJusSw4Vn4Dx_is7mRjOT6clvj3Uh5F5tcLsPIwUAk=.fda1546c-22b0-4a57-900e-2e752841b617@github.com>

On Wed, 4 Jun 2025 17:04:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> You're right.
>
> The Threads_lock is required to prevent JFR from sampling through an ongoing safepoint, touching oops, which is not supported by most GCs as well as JFR evolving its global epoch (happens during safepoint) while both threads are outside the safepoint protocol. Can be optimized (later), see for example: https://github.com/openjdk/jdk/pull/25602

I readded the lock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127082776

From shade at openjdk.org  Wed Jun  4 17:27:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 17:27:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v55]
In-Reply-To: <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@github.com>
Message-ID: <o56EXvgyVDG1x31cDH9l6agnFwGc0xh_fXlJAXyy6UA=.17cf60fc-fe7d-4907-b5c4-1bd52cdec9ae@github.com>

On Wed, 4 Jun 2025 15:48:31 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:
> 
>   Improve

I admit I am leaning pretty hard on JFR folks expertise here.

I agree this code passes the bar for experimental feature: it does not seem to affect non-JFR paths, does not seem to interact with JFR in obviously incorrect manner, and in itself looks more or less sensible.

Please file the follow-ups to figure out the memory ordering story in `JfrCPUTimeTraceQueue`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 640:

> 638: 
> 639:   VM_CPUTimeSamplerThreadInitializer(JfrCPUSamplerThread* sampler) : _sampler(sampler) {
> 640:   }

Suggestion:

 private:
  JfrCPUSamplerThread* const _sampler;
  
 public:
  VM_CPUTimeSamplerThreadInitializer(JfrCPUSamplerThread* sampler) : _sampler(sampler) {}

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 671:

> 669: 
> 670:   VM_CPUTimeSamplerThreadTerminator(JfrCPUSamplerThread* sampler) : _sampler(sampler) {
> 671:   }

Suggestion:

 private:
  JfrCPUSamplerThread* const _sampler;

 public:
  VM_CPUTimeSamplerThreadTerminator(JfrCPUSamplerThread* sampler) : _sampler(sampler) {}

src/hotspot/share/runtime/vmOperation.hpp line 119:

> 117:   template(RendezvousGCThreads)                   \
> 118:   template(CPUTimeSamplerThreadInitializer)       \
> 119:   template(CPUTimeSamplerThreadTerminator)        \

I think these better be prefixed with `JFR`. E.g.: `JFRInitializeCPUTimeSampler` / `JFRTerminateCPUTimeSampler`?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2897511962
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127078325
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127079549
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127090498

From jbechberger at openjdk.org  Wed Jun  4 17:49:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:49:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v57]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <I3MalT4D4ZSk6QLBeCSgCFfX6q2I47VeQejwnmrCsOc=.43b62b63-9f2b-44d7-92d6-64d6a67c753a@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 three additional commits since the last revision:

 - Renaming of VM ops
 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/53d3ed4a..f3ef7908

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=56
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=55-56

  Stats: 16 lines in 2 files changed: 0 ins; 2 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 jbechberger at openjdk.org  Wed Jun  4 17:49:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:49:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v55]
In-Reply-To: <o56EXvgyVDG1x31cDH9l6agnFwGc0xh_fXlJAXyy6UA=.17cf60fc-fe7d-4907-b5c4-1bd52cdec9ae@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@github.com>
 <o56EXvgyVDG1x31cDH9l6agnFwGc0xh_fXlJAXyy6UA=.17cf60fc-fe7d-4907-b5c4-1bd52cdec9ae@github.com>
Message-ID: <mUXSwVZZCVWg3zz7bVBzpP8MoT0KpnvZPwP3zP36dk4=.c682f285-6365-4477-92ab-080727639b74@github.com>

On Wed, 4 Jun 2025 17:24:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Please file the follow-ups to figure out the memory ordering story in `JfrCPUTimeTraceQueue`.

I created a preliminary issue at https://bugs.openjdk.org/browse/JDK-8358616

> src/hotspot/share/runtime/vmOperation.hpp line 119:
> 
>> 117:   template(RendezvousGCThreads)                   \
>> 118:   template(CPUTimeSamplerThreadInitializer)       \
>> 119:   template(CPUTimeSamplerThreadTerminator)        \
> 
> I think these better be prefixed with `JFR`. E.g.: `JFRInitializeCPUTimeSampler` / `JFRTerminateCPUTimeSampler`?

Good point

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2940863550
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127113247

From mgronlun at openjdk.org  Wed Jun  4 17:49:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 17:49:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
Message-ID: <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>

On Wed, 4 Jun 2025 17:22:37 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:
> 
>   Readd lock

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 300:

> 298:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
> 299:     log_trace(jfr)("Disenrolling CPU thread sampler");
> 300:     if (Atomic::fetch_then_and(&_signal_handler_installed, false)) {

fetch_then_and with false? Must be simpler way to express this? Like Atomic::load(&_signal_handler_installed)?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 608:

> 606: void JfrCPUSamplerThread::stop_signal_handlers() {
> 607:   // set the stop signal bit
> 608:   Atomic::or_then_fetch(&_active_signal_handlers, STOP_SIGNAL_BIT, memory_order_acq_rel);

Whatever was fetched is gone with the wind...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127117357
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127119596

From jbechberger at openjdk.org  Wed Jun  4 17:49:28 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:49:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
 <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
Message-ID: <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>

On Wed, 4 Jun 2025 17:39: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:
>> 
>>   Readd lock
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 300:
> 
>> 298:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
>> 299:     log_trace(jfr)("Disenrolling CPU thread sampler");
>> 300:     if (Atomic::fetch_then_and(&_signal_handler_installed, false)) {
> 
> fetch_then_and with false? Must be simpler way to express this? Like Atomic::load(&_signal_handler_installed)?

I also want to set it. Wanted to do a simple ::xchg, but this doesn't exist for booleans.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 608:
> 
>> 606: void JfrCPUSamplerThread::stop_signal_handlers() {
>> 607:   // set the stop signal bit
>> 608:   Atomic::or_then_fetch(&_active_signal_handlers, STOP_SIGNAL_BIT, memory_order_acq_rel);
> 
> Whatever was fetched is gone with the wind...

I didn't find an Atomic::or method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127120548
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127122509

From mgronlun at openjdk.org  Wed Jun  4 17:49:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 17:49:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
 <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
 <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>
Message-ID: <-1_gEsqoLf4kh7TUZbIXh0n4PwcU7_IuaFMedlvMaAM=.27f3a6c4-79f6-4535-912a-9d2e69587a41@github.com>

On Wed, 4 Jun 2025 17:41:46 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 300:
>> 
>>> 298:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
>>> 299:     log_trace(jfr)("Disenrolling CPU thread sampler");
>>> 300:     if (Atomic::fetch_then_and(&_signal_handler_installed, false)) {
>> 
>> fetch_then_and with false? Must be simpler way to express this? Like Atomic::load(&_signal_handler_installed)?
>
> I also want to set it. Wanted to do a simple ::xchg, but this doesn't exist for booleans.

1 & 0 -> 0, are you setting _signal_handler_installed to false? Why?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127125344

From jbechberger at openjdk.org  Wed Jun  4 17:54:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:54:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@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 disenroll

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/f3ef7908..db093a28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=57
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=56-57

  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  Wed Jun  4 17:54:51 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:54:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <-1_gEsqoLf4kh7TUZbIXh0n4PwcU7_IuaFMedlvMaAM=.27f3a6c4-79f6-4535-912a-9d2e69587a41@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
 <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
 <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>
 <-1_gEsqoLf4kh7TUZbIXh0n4PwcU7_IuaFMedlvMaAM=.27f3a6c4-79f6-4535-912a-9d2e69587a41@github.com>
Message-ID: <w13b4jXcmAL9nInnd6wcg8fJUqvH3iYaUPsTvf5wUbU=.7f7c04ac-8848-4438-8189-4a47ee9ab5de@github.com>

On Wed, 4 Jun 2025 17:44:45 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I also want to set it. Wanted to do a simple ::xchg, but this doesn't exist for booleans.
>
> 1 & 0 -> 0, are you setting _signal_handler_installed to false? Why?

You're right, it's not required. I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127135816

From mgronlun at openjdk.org  Wed Jun  4 18:41:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 18:41:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>
Message-ID: <S-OniZT7w7UyZ3mDujAP36jVd2kQ9_xooLYBQtQFNwM=.5489df05-b52d-48a9-be34-b765ddbaadf1@github.com>

On Wed, 4 Jun 2025 11:25:44 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Is this something for a later PR?
>
> I'm OK with fixing this separately.

Please ensure that you file a follow-up issue on this matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127213771

From ecki at zusammenkunft.net  Wed Jun  4 18:50:47 2025
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed,  4 Jun 2025 20:50:47 +0200 (CEST)
Subject: Hidden startup exception, JFR Crashs with javaagents 
Message-ID: <20250604185047.301126660D4@dd33810.kasserver.com>

Hello,

While playing round with JavaAgents which emit JFR Events I could trigger a
class circularity problem (Most likely my (or Copilot) fault, tips welcome).


However, this report is about the fact that the actual exception is not
printed and the actual error Message is very ugly:

> java -XX:StartFlightRecording=filename=out.jfr,settings=single.jfc
> -javaagent:.\target\agent-x-0.1.0.jar=TestApp:test .\TestApp.java OpenJDK
> 64-Bit Server VM warning: Sharing is only supported for boot loader
> classes because bootstrap classpath has been appended
> [0.064s][error][jfr,startup] java/lang/WeakPairMap$Pair$Weak Error
> occurred during initialization of VM Failure when starting JFR
> on_create_vm_3


find the details here:

https://github.com/ecki/jfr-agent-x


(also when looking at Xlog:exceptions=error it feels like its handele
multiple times)

Gru?
Bernd


From jbechberger at openjdk.org  Wed Jun  4 18:57:07 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 18:57:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <S-OniZT7w7UyZ3mDujAP36jVd2kQ9_xooLYBQtQFNwM=.5489df05-b52d-48a9-be34-b765ddbaadf1@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>
 <S-OniZT7w7UyZ3mDujAP36jVd2kQ9_xooLYBQtQFNwM=.5489df05-b52d-48a9-be34-b765ddbaadf1@github.com>
Message-ID: <0PjEBxgqHesjNBoyKSYCW6wGcS2GEqujEz79IeWl_LA=.04c24d78-dfb4-4917-bc50-59420548b854@github.com>

On Wed, 4 Jun 2025 18:38:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I'm OK with fixing this separately.
>
> Please ensure that you file a follow-up issue on this matter.

Here it is https://bugs.openjdk.org/browse/JDK-8358619

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127234787

From pchilanomate at openjdk.org  Wed Jun  4 18:57:08 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 18:57:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <-YJusSw4Vn4Dx_is7mRjOT6clvj3Uh5F5tcLsPIwUAk=.fda1546c-22b0-4a57-900e-2e752841b617@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>
 <-YJusSw4Vn4Dx_is7mRjOT6clvj3Uh5F5tcLsPIwUAk=.fda1546c-22b0-4a57-900e-2e752841b617@github.com>
Message-ID: <EB5u-oWj4DrVtamqPQiPVGUu8bondWxeuIhek1Q15wc=.c0b57a00-9cd4-42cd-a922-2b43e4bc407f@github.com>

On Wed, 4 Jun 2025 17:17:31 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> The Threads_lock is required to prevent JFR from sampling through an ongoing safepoint, touching oops, which is not supported by most GCs as well as JFR evolving its global epoch (happens during safepoint) while both threads are outside the safepoint protocol. Can be optimized (later), see for example: https://github.com/openjdk/jdk/pull/25602
>
> I readded the lock.

Thanks, a comment about that would be nice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127239230

From pchilanomate at openjdk.org  Wed Jun  4 18:57:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 18:57:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <ZFbJAFMki4I2l3iekCNiLgPpQZkROMF2j6GIKjCWkQM=.d285a9cc-5279-4ebb-93f2-3605f4e72c66@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <ZFbJAFMki4I2l3iekCNiLgPpQZkROMF2j6GIKjCWkQM=.d285a9cc-5279-4ebb-93f2-3605f4e72c66@github.com>
Message-ID: <OVP5JNgJGVXTubPORLoniMjdVkGNxHKKCFfMo_eMEpk=.35e63358-66b8-4028-92c8-3e842bba153a@github.com>

On Wed, 4 Jun 2025 14:39:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 430:
>> 
>>> 428: void JfrCPUTimeThreadSampling::create_sampler(double rate, bool auto_adapt) {
>>> 429:   assert(_sampler == nullptr, "invariant");
>>> 430:   _sampler = new JfrCPUSamplerThread(rate, auto_adapt);
>> 
>> If we start a recording on an already running process we have a race here where a new thread can create and set its timer before we call init_timers() where the signal handler is installed. In that case the program will terminate with message ?Profiling timer expired" (default action for SIGPROF). It can be easily reproduced by adding a delay here and starting a recording on a simple test that just creates new threads. We need to add some extra check in create_timer_for_thread() or install the signal handler earlier.
>
> I created a `has_timer` flag that is checked by `create_timer_for_thread()` before creating timers and set by `init_timers`. Is this what you envisioned?

Thanks, I verified that fixes the issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127238263

From mgronlun at openjdk.org  Wed Jun  4 19:08:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:08:40 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
Message-ID: <y8H18hv3tKC_bm6VRpkDKYBnJdi92B3oCLUVwFrcbdc=.2fd88708-43b5-48f2-a04c-57d01cc16ff5@github.com>

On Wed, 4 Jun 2025 17:54:50 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:
> 
>   Improve disenroll

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 396:

> 394: }
> 395: 
> 396: class SampleMonitor : public StackObj {

This is a merge error. SampleMonitor is no longer used and can be deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127252688

From jbechberger at openjdk.org  Wed Jun  4 19:08:40 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:08:40 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v59]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <egSpnuKJNQ-nq2-cEbrQlM3NJpVLONueZDFD_ndCSMw=.1960dabc-743f-4a3d-9bbb-f4f7e4d3a630@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:

 - Fixed merge error
 - Add comment regarding Threads_lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/db093a28..b9def278

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=58
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=57-58

  Stats: 19 lines in 2 files changed: 1 ins; 18 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 apangin at openjdk.org  Wed Jun  4 19:15:09 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 19:15:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
Message-ID: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>

On Wed, 4 Jun 2025 17:54:50 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:
> 
>   Improve disenroll

src/hotspot/os/posix/signals_posix.cpp line 1511:

> 1509:   struct sigaction oact;
> 1510:   if (sigaction(sig, (struct sigaction*)nullptr, &oact) == -1) {
> 1511:     return nullptr; // signal not installed

A comment is misleading: sigaction does not fail if a handler for the signal is not installed (i.e. the handler is SIG_IGN).

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 656:

> 654:   if ((prev_handler != SIG_DFL && prev_handler != SIG_IGN && prev_handler != (void*)::handle_timer_signal) ||
> 655:       PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == (void*)-1) {
> 656:     log_error(jfr)("CPUTimeSample events will not be recorded: %p", prev_handler);

A message with some random hex address may look cryptic.
Maybe make it a bit more user-friendly? E.g.

Conflicting SIGPROF handler found: %p. CPUTimeSample events will not be recorded

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

> 331:     }
> 332:   }
> 333:   request._sample_ticks = JfrTicks::now();

For accurate correlation with other events, timestamp of a sample should be taken as early as possible, preferably in the beginning of `JfrCPUSamplerThread::handle_timer_signal`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127222795
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127266822
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127236706

From mgronlun at openjdk.org  Wed Jun  4 19:15:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:15:10 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v59]
In-Reply-To: <egSpnuKJNQ-nq2-cEbrQlM3NJpVLONueZDFD_ndCSMw=.1960dabc-743f-4a3d-9bbb-f4f7e4d3a630@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <egSpnuKJNQ-nq2-cEbrQlM3NJpVLONueZDFD_ndCSMw=.1960dabc-743f-4a3d-9bbb-f4f7e4d3a630@github.com>
Message-ID: <B8Fz0rIS4eUEiJxALgM_AJz_c2Sm5nZBgYi3aGS5m4o=.ba7af8fe-92da-4543-a284-6af834a0a6f4@github.com>

On Wed, 4 Jun 2025 19:08:40 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 two additional commits since the last revision:
> 
>  - Fixed merge error
>  - Add comment regarding Threads_lock

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 633:

> 631: 
> 632: void JfrCPUSamplerThread::allow_signal_handlers() {
> 633:   Atomic::release_store(&_active_signal_handlers, (u4)0);

"allow_signal_handlers" is not the best name for this routine - it suggests that by setting _active_signal_handlers = 0, something is enabled - like an inverted Semaphore. But "signal handlers" are allowed for all W of this value, so the 0 has no bearing on enablement.

Just call it "initialize_active_signal_handler_counter" or whatever.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127267710

From mgronlun at openjdk.org  Wed Jun  4 19:18:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:18:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
Message-ID: <3MKLMJ4-eLHkm1qroOSGU2Kvi1pIYkyeZ9unRVbhHAk=.afeb3c4a-4501-4f70-82b6-f293948bc229@github.com>

On Wed, 4 Jun 2025 19:11:16 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve disenroll
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 656:
> 
>> 654:   if ((prev_handler != SIG_DFL && prev_handler != SIG_IGN && prev_handler != (void*)::handle_timer_signal) ||
>> 655:       PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == (void*)-1) {
>> 656:     log_error(jfr)("CPUTimeSample events will not be recorded: %p", prev_handler);
> 
> A message with some random hex address may look cryptic.
> Maybe make it a bit more user-friendly? E.g.
> 
> Conflicting SIGPROF handler found: %p. CPUTimeSample events will not be recorded

Thanks Andrei.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127272864

From jbechberger at openjdk.org  Wed Jun  4 19:24:11 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:24:11 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
Message-ID: <R4LGgPNj7oq6UXVhPoiIbyUYGN-77QA1AyBCaykrYhM=.d6714403-5a79-4f2a-91f5-5fd90967d62e@github.com>

On Wed, 4 Jun 2025 18:44:23 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve disenroll
>
> src/hotspot/os/posix/signals_posix.cpp line 1511:
> 
>> 1509:   struct sigaction oact;
>> 1510:   if (sigaction(sig, (struct sigaction*)nullptr, &oact) == -1) {
>> 1511:     return nullptr; // signal not installed
> 
> A comment is misleading: sigaction does not fail if a handler for the signal is not installed (i.e. the handler is SIG_IGN).

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127281710

From jbechberger at openjdk.org  Wed Jun  4 19:33:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:33:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <3MKLMJ4-eLHkm1qroOSGU2Kvi1pIYkyeZ9unRVbhHAk=.afeb3c4a-4501-4f70-82b6-f293948bc229@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
 <3MKLMJ4-eLHkm1qroOSGU2Kvi1pIYkyeZ9unRVbhHAk=.afeb3c4a-4501-4f70-82b6-f293948bc229@github.com>
Message-ID: <c2Tsu1u-evboeTjBHN5mCXW5EWnVUl0s_qJZ7QwPIng=.e26a627f-f769-4833-9e8c-80ce7b0dc147@github.com>

On Wed, 4 Jun 2025 19:15:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 656:
>> 
>>> 654:   if ((prev_handler != SIG_DFL && prev_handler != SIG_IGN && prev_handler != (void*)::handle_timer_signal) ||
>>> 655:       PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == (void*)-1) {
>>> 656:     log_error(jfr)("CPUTimeSample events will not be recorded: %p", prev_handler);
>> 
>> A message with some random hex address may look cryptic.
>> Maybe make it a bit more user-friendly? E.g.
>> 
>> Conflicting SIGPROF handler found: %p. CPUTimeSample events will not be recorded
>
> Thanks Andrei.

Fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127292777

From jbechberger at openjdk.org  Wed Jun  4 19:33:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:33:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
Message-ID: <Zq60I1hpF1JrzH_J2gFnYmg4tdBkIzTHipM-rQ2Ei7A=.3385b1be-d455-4f67-8793-57e79ce0b0e7@github.com>

On Wed, 4 Jun 2025 18:53:35 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve disenroll
>
> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 333:
> 
>> 331:     }
>> 332:   }
>> 333:   request._sample_ticks = JfrTicks::now();
> 
> For accurate correlation with other events, timestamp of a sample should be taken as early as possible, preferably in the beginning of `JfrCPUSamplerThread::handle_timer_signal`

I moved it up:


void JfrCPUSamplerThread::handle_timer_signal(siginfo_t* info, void* context) {
  JfrTicks now = JfrTicks::now();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127294191

From jbechberger at openjdk.org  Wed Jun  4 19:38:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:38:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v60]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/b9def278..ab2ac459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=59
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=58-59

  Stats: 22 lines in 4 files changed: 5 ins; 1 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 mgronlun at openjdk.org  Wed Jun  4 19:38:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:38:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <hhQ2qjqC1JjLPwC9l7-rGLp8NuUsOvNLN6Iwjn86rPM=.3e5625fa-60b4-4404-b6ed-b1aae6055e67@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <hhQ2qjqC1JjLPwC9l7-rGLp8NuUsOvNLN6Iwjn86rPM=.3e5625fa-60b4-4404-b6ed-b1aae6055e67@github.com>
Message-ID: <0T2FCxivdxhNus6A9_fGcXDNFDLachuVRGgJbixpU_0=.d51a569d-6f68-4dfa-a0cb-ca71c85f9286@github.com>

On Tue, 3 Jun 2025 21:56: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:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 360:
> 
>> 358:   tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
>> 359:   if (lock) {
>> 360:     tl->acquire_cpu_time_jfr_dequeue_lock();
> 
> This is your synchronization point on return from native code, which is effectively a spinlock. This can cause problems when a large number of threads are being processed by the "do_async_processing" request call.
> 
> We should fix this as a bug after integration (use a proper Monitor as a synchronization point).

Filed: https://bugs.openjdk.org/browse/JDK-8358621

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127300632

From mgronlun at openjdk.org  Wed Jun  4 19:50:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:50:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v60]
In-Reply-To: <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@github.com>
Message-ID: <399lO47PUBfDUPjh-Ve1NztHstmkEF24xiJVQe3FRZI=.693af08b-3df9-4ec5-a589-a1c269bb7837@github.com>

On Wed, 4 Jun 2025 19:38:57 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:
> 
>   Improve

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 634:

> 632: 
> 633: void JfrCPUSamplerThread::allow_signal_handlers() {
> 634:   Atomic::release_store(&_initialize_active_signal_handler_counter, (u4)0);

I think we might be getting a bit tired. I meant the function name, not the variable name, which now looks completely bonkers :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127323120

From jbechberger at openjdk.org  Wed Jun  4 19:55:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:55:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@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:

  Renaming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ab2ac459..b1689bdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=60
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=59-60

  Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 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 Jun  4 19:55:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:55:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v60]
In-Reply-To: <399lO47PUBfDUPjh-Ve1NztHstmkEF24xiJVQe3FRZI=.693af08b-3df9-4ec5-a589-a1c269bb7837@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@github.com>
 <399lO47PUBfDUPjh-Ve1NztHstmkEF24xiJVQe3FRZI=.693af08b-3df9-4ec5-a589-a1c269bb7837@github.com>
Message-ID: <v0-iUypGdp4t_wV1Sl8642l4k1qqLCGX3SBjUmynJfY=.edb3b622-947b-46e6-832b-5599e7c5e8ac@github.com>

On Wed, 4 Jun 2025 19:47:17 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:
>> 
>>   Improve
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 634:
> 
>> 632: 
>> 633: void JfrCPUSamplerThread::allow_signal_handlers() {
>> 634:   Atomic::release_store(&_initialize_active_signal_handler_counter, (u4)0);
> 
> I think we might be getting a bit tired. I meant the function name, not the variable name, which now looks completely bonkers :-)

Well, I just misunderstood you :D

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127329186

From mdoerr at openjdk.org  Wed Jun  4 20:48:07 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Jun 2025 20:48:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <8jQ9fsDS_OZA6WYBEy5Rf9WPfZaZJQB1zWB53iHt5i8=.6ebbb1cc-0c6f-4699-88cc-f93e8d9b5a82@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898056841

From apangin at openjdk.org  Wed Jun  4 21:22:07 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 21:22:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <XCwuyt6sbF1TRpAlRnYbhyfhFcklUQNhHs5kRPpbVSA=.f20da6e8-ab56-474b-8bc5-0f3fa0e3b190@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

Marked as reviewed by apangin (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898137302

From mgronlun at openjdk.org  Wed Jun  4 21:47:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 21:47:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <-H5MPWW5BYrLTBLZIGu8PRcWUw9LxZoLpapnZaDy5ts=.295d136b-d764-4a73-b334-4fb51295a580@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

I am waiting for the basic CI pre-tests to come back green before I approve for integration.

No sweat, the cutoff is in CST :) and branching usually happens later in the day.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941623120

From mgronlun at openjdk.org  Wed Jun  4 22:02:19 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <qrpqeC2JySjI92oILasDkHzE74ERl5EsyOlTJydehoo=.35d0b5b7-6301-4010-8253-e40bef2d54a2@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

Ship it!

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898222436

From pchilanomate at openjdk.org  Wed Jun  4 22:02:19 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <WgIJMhy2pI48a5mUKABBZ4IYe4gi_-tR-z9mdbuVtyU=.1083df29-6522-47c0-82c6-6a1c5b1fce46@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898222664

From jbechberger at openjdk.org  Wed Jun  4 22:02:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <wW9xJ2Att2cQVPqn6-2MAegC7XZQOBFaLkf68a-InzM=.adf7bf15-01fb-40c0-86ec-4dae315a8318@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

I know, but I want to get over it today(ish).

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941671138

From mgronlun at openjdk.org  Wed Jun  4 22:02:19 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <wW9xJ2Att2cQVPqn6-2MAegC7XZQOBFaLkf68a-InzM=.adf7bf15-01fb-40c0-86ec-4dae315a8318@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
 <wW9xJ2Att2cQVPqn6-2MAegC7XZQOBFaLkf68a-InzM=.adf7bf15-01fb-40c0-86ec-4dae315a8318@github.com>
Message-ID: <TLbiEpISmb02-dK-zpLS3aC5Ev0xf13_jbwLDpOfXJg=.895bb82e-8604-4b30-8d57-fd888df7cd41@github.com>

On Wed, 4 Jun 2025 21:56:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> I know, but I want to get over it today(ish).

Go for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941686873

From mgronlun at openjdk.org  Wed Jun  4 22:13:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:13:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <fWKHOsBA-9c_hob8Z4CGogYpHKDV3sNqVAZbbKM3mgk=.96f37338-270f-4e6c-b52d-5d1c34cf3e94@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
 <fWKHOsBA-9c_hob8Z4CGogYpHKDV3sNqVAZbbKM3mgk=.96f37338-270f-4e6c-b52d-5d1c34cf3e94@github.com>
Message-ID: <m7lgHs2_834A1QBgXeED4Ukmuk26Xc2mD_6EVEl7XVY=.73e37dd4-6dbf-4abb-99d5-00db64cf18a0@github.com>

On Wed, 4 Jun 2025 22:06:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> So I'm just waiting for Skara?

You can issue the integrate command.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941709310

From mgronlun at openjdk.org  Wed Jun  4 22:13:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:13:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <FeE4FA6dSkjoI3Vfgcga7fgCYoSrMwNvxeEbAQK0CfM=.aa19f73a-db08-4a11-94c9-ba741933a5e3@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

Well done - now take some well-deserved rest. I'll monitor the first stages of integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941716415

From jbechberger at openjdk.org  Wed Jun  4 22:13:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 22:13:17 GMT
Subject: Integrated: 8342818: Implement JEP 509: JFR CPU-Time Profiling
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <mnW0AmpnqC8dY3sh7GWbniO42ze334iCntCMS1GbLkc=.bc5dea65-d9ff-4ad3-b268-439a337f5d5f@github.com>

On Mon, 19 May 2025 13:02:20 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

This pull request has now been integrated.

Changeset: 5b27e9c2
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b27e9c2df8b386b38b0553d941469cd8aa65c28
Stats:     2306 lines in 41 files changed: 2166 ins; 128 del; 12 mod

8342818: Implement JEP 509: JFR CPU-Time Profiling

Reviewed-by: mgronlun, mdoerr, pchilanomate, apangin, shade

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

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

From jbechberger at openjdk.org  Wed Jun  4 22:13:14 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 22:13:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <fWKHOsBA-9c_hob8Z4CGogYpHKDV3sNqVAZbbKM3mgk=.96f37338-270f-4e6c-b52d-5d1c34cf3e94@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

So I'm just waiting for Skara?

Thanks, good night.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941707891
PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941716783

From mgronlun at openjdk.org  Wed Jun  4 22:47:15 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:47:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <oDXY2fuWGwTGWO_zRI5zIK4LlxlOxZbk5RNn6UwyND0=.c1a29d46-bd0f-4ead-a3db-78ecdaf32ffc@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

Hope you have not got to sleep yet:

jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941820906

From dholmes at openjdk.org  Wed Jun  4 23:57:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jun 2025 23:57:56 GMT
Subject: RFR: 8358628: [BACKOUT] 8342818: Implement JEP 509: JFR CPU-Time
 Profiling
In-Reply-To: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
References: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
Message-ID: <62oqwYVSGqRO_SeQhJ7Ylhgo9Y_M6fbTDVLYSkb8cK4=.95eba6bd-99ae-41ad-86e3-51cfcf16b0cd@github.com>

On Wed, 4 Jun 2025 23:38:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This reverts commit 5b27e9c2df8b386b38b0553d941469cd8aa65c28.
> 
> There are too many strange issues appearing, memory allocation corruptions, and also some strange activation of the feature that is yet not understood.
> 
> We should back it out as to not block other integrations while we troubleshoot.
> 
> Thanks
> Markus

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25649#pullrequestreview-2898378246

From mgronlun at openjdk.org  Wed Jun  4 23:57:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 23:57:56 GMT
Subject: Integrated: 8358628: [BACKOUT] 8342818: Implement JEP 509: JFR
 CPU-Time Profiling
In-Reply-To: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
References: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
Message-ID: <aX9zWDpcxvKsKLTQLBZkTNyAr6VB8OwAbl99tm1LQDw=.f6f2b207-dc21-4057-9876-d8ceed5b2485@github.com>

On Wed, 4 Jun 2025 23:38:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This reverts commit 5b27e9c2df8b386b38b0553d941469cd8aa65c28.
> 
> There are too many strange issues appearing, memory allocation corruptions, and also some strange activation of the feature that is yet not understood.
> 
> We should back it out as to not block other integrations while we troubleshoot.
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 9186cc73
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9186cc7310c0cca2fca776031280f08d84e43b74
Stats:     2306 lines in 41 files changed: 128 ins; 2166 del; 12 mod

8358628: [BACKOUT] 8342818: Implement JEP 509: JFR CPU-Time Profiling

Reviewed-by: pchilanomate, dholmes

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

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

From smarks at openjdk.org  Thu Jun  5 00:24:55 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 5 Jun 2025 00:24:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
Message-ID: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>

On Wed, 4 Jun 2025 16:04:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 970:
>> 
>>> 968:             long end = SocketReadEvent.timestamp();
>>> 969:             long duration = end - start;
>>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
>> 
>> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
>> 
>> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.
>
> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
> 
> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
> 
> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.

I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.

To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)

But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2127716516

From dholmes at openjdk.org  Thu Jun  5 01:12:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 01:12:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <q8sSGxGGdHFo58B9HfLmqNdguipXeMdKO2pGs60jYxk=.e236d467-195f-4537-9498-1e0b8733a35e@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 88:

> 86:       return false;
> 87:     }
> 88:   } while (Atomic::cmpxchg(&_head, elementIndex, elementIndex + 1) != elementIndex);

Why do we need atomic operations if we hold the enqueue lock. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127755502

From jbechberger at openjdk.org  Thu Jun  5 05:05:22 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 5 Jun 2025 05:05:22 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <q8sSGxGGdHFo58B9HfLmqNdguipXeMdKO2pGs60jYxk=.e236d467-195f-4537-9498-1e0b8733a35e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
 <q8sSGxGGdHFo58B9HfLmqNdguipXeMdKO2pGs60jYxk=.e236d467-195f-4537-9498-1e0b8733a35e@github.com>
Message-ID: <MnqN0CjSc_S7gfhNxvkf-y7aodI4RXsLBRjmgFhNj3I=.57da8ad9-5b90-462d-88dd-376d69260417@github.com>

On Thu, 5 Jun 2025 01:09:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renaming
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 88:
> 
>> 86:       return false;
>> 87:     }
>> 88:   } while (Atomic::cmpxchg(&_head, elementIndex, elementIndex + 1) != elementIndex);
> 
> Why do we need atomic operations if we hold the enqueue lock. ??

Valid Point, I was probably over cautious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127957148

From jbechberger at openjdk.org  Thu Jun  5 05:13:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 5 Jun 2025 05:13:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <nJIkdkY3xwM4SvuI0dxIYGYXhkR1WdYa30V5rlJWqro=.b24ebfa3-77b6-43b7-b8a6-9c3ecafbb521@github.com>

On Wed, 4 Jun 2025 19:55:55 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:
> 
>   Renaming

I'm on it, darn.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2942770368

From vyazici at openjdk.org  Thu Jun  5 05:51:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 05:51:55 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>
Message-ID: <vbkzLujju3ftu2UcPbudkR20YRTnLlgtTtRzsasVEpU=.6828f0da-7002-4ac2-ac89-ff728884ea42@github.com>

On Tue, 3 Jun 2025 18:08:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> That's not going to be sufficient. The nsk tests are not being run until tier5.

@plummercj, I've attached the `tier3,4,5` run report to the ticket, would you mind reviewing them, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2942851679

From egahlin at openjdk.org  Thu Jun  5 08:10:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:10:42 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v4]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <72MCuwD8Jd9igYMm5C4yZyxh-8xLnnKePImAaep3p2U=.49745a1b-7f46-4a07-a150-4c243683068f@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7fa2db19..59278ca8

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

  Stats: 26802 lines in 553 files changed: 20626 ins; 2170 del; 4006 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 egahlin at openjdk.org  Thu Jun  5 08:13:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:13:21 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v5]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <8opPh4lTfGQBzlleDOuxmi3QyhF3M9M7U7MpIoFWUCE=.a14d1385-e759-4fa5-8733-5ebb162d20a7@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/59278ca8..535d458a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=03-04

  Stats: 2776 lines in 58 files changed: 477 ins; 2217 del; 82 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 egahlin at openjdk.org  Thu Jun  5 08:40:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:40:44 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/535d458a..8259ff41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=04-05

  Stats: 2319 lines in 41 files changed: 2179 ins; 128 del; 12 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 aturbanov at openjdk.org  Thu Jun  5 09:02:57 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 09:02:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
Message-ID: <bPhyUNuWlTSgWzVu0XGymtuPwYZa2VqhcLPb7siVcmU=.60458892-b041-4fa8-8237-094f995e50c6@github.com>

On Thu, 5 Jun 2025 08:40:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Fix adjust boundary
>  - Some reviewer feedback
>  - Consistent annotation
>  - Fix typos
>  - Fix whitespace
>  - Initial

src/java.base/share/classes/java/io/RandomAccessFile.java line 594:

> 592:         } finally {
> 593:             long end = FileWriteEvent.timestamp();
> 594:             long duration =  end - start;

Suggestion:

            long duration = end - start;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 65:

> 63: public final class EventInstrumentation {
> 64:     public static final long MASK_THROTTLE              = 1 << 62;
> 65:     public static final long MASK_THROTTLE_CHECK        = 1 << 63;

Let's align
Suggestion:

    public static final long MASK_THROTTLE               = 1 << 62;
    public static final long MASK_THROTTLE_CHECK         = 1 << 63;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 593:

> 591:         if (throttled) {
> 592:             codeBuilder.aload(0);
> 593:             getfield(codeBuilder, eventClassDesc,  ImplicitFields.FIELD_DURATION);

Suggestion:

            getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);

test/jdk/jdk/jfr/api/recording/settings/TestSettingsAvailability.java line 93:

> 91:         testSetting(EventNames.JVMInformation, "enabled", "period");
> 92:         testSetting(EventNames.FileRead, "enabled", "threshold", "stackTrace", "throttle");
> 93:         testSetting(EventNames.FileWrite, "enabled", "threshold","stackTrace", "throttle");

Suggestion:

        testSetting(EventNames.FileWrite, "enabled", "threshold", "stackTrace", "throttle");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322876
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128321445
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128323708

From egahlin at openjdk.org  Thu Jun  5 09:26:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:26:13 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Use offer method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8259ff41..7f26f172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=05-06

  Stats: 570 lines in 10 files changed: 455 ins; 88 del; 27 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 alanb at openjdk.org  Thu Jun  5 09:28:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:28:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
Message-ID: <g4wakHQv7Fsl1YNLYTUXAPUC7WwQb7CM3wV9FrJMNYs=.b91f4a96-a4ec-4bd2-9ddc-67409d4097b4@github.com>

On Thu, 5 Jun 2025 09:26:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use offer method

t.txt line 1:

> 1: diff --git a/src/java.base/share/classes/java/io/FileInputStream.java b/src/java.base/share/classes/java/io/FileInputStream.java

t.txt added by mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128388583

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:

 - Remove the mistakenly added file.
 - Fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7f26f172..8beb194a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=06-07

  Stats: 414 lines in 3 files changed: 0 ins; 410 del; 4 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 alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <APXhHhCmSmtSgE7-D_oiy7_DFNdzKqfEdkOmQUkXVMc=.e66a486a-0074-4756-a5d5-903fc4a4cbd0@github.com>

On Thu, 5 Jun 2025 09:37:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/java/io/FileInputStream.java line 219:

> 217:             }
> 218:         } finally {
> 219:             FileReadEvent.offer(start, path, bytesRead);

Thanks for this update, this looks much better. It think would be better again if `start = FileReadEvent.timestamp()` is moved to before the try.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 328:

> 326:         } finally {
> 327:             long end = FileReadEvent.timestamp();
> 328:             FileReadEvent.offer(start, path, bytesRead);

I don't think "end" is needed now.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 382:

> 380:             FileWriteEvent.offer(start, path, bytes);
> 381:         }
> 382:         return bytes;

The method returns the number of bytes written and traceImplRead uses bytesRead for the number of bytes read. So I think better to leave it as bytesWritten.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128400058
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128401565
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128406420

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
Message-ID: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>

On Thu, 5 Jun 2025 00:21:45 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
>> 
>> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
>> 
>> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.
>
> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
> 
> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
> 
> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128398824

From alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
 <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
Message-ID: <Zwcb_hQVZmXxEiB91eADdb60FeRk8-8g5VfbolZa1FA=.3d4e5d5b-6653-4adc-9c9d-06e06b7d2977@github.com>

On Thu, 5 Jun 2025 09:31:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
>> 
>> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
>> 
>> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.
>
> I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

Thank you for this update, it looks much better now. I chatted briefly with Stuart yesterday and mostly agreed there would need to be some follow-up cleanup of the use-sites. Doing in now is good as it addresses our grumblings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128410969

From alanb at openjdk.org  Thu Jun  5 09:48:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:48:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <QzDSW4zb1mvKE02K7Lqu-i0ORDvEpXM5AXglPU0MkrM=.8cb32924-10cf-4734-8bef-ca5820d47ac2@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1252:

> 1250:         } finally {
> 1251:             long bytes = bytesWritten > 0 ? bytesWritten : 0;
> 1252:             FileWriteEvent.offer(start, path, bytes);

The number of bytes written is >=0, it can't be < 0, so I'm not sure why the existing code checks bytesWritten > 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128429546

From alanb at openjdk.org  Thu Jun  5 09:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:54:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/jdk.jfr/share/conf/jfr/default.jfc line 845:

> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
> 844:       <setting name="stackTrace">true</setting>
> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>

What was used to proposed 100/s as the default and 300/s in profile.jfc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128442250

From egahlin at openjdk.org  Thu Jun  5 10:10:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:10:41 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8beb194a..45adc081

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=07-08

  Stats: 35 lines in 4 files changed: 0 ins; 16 del; 19 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 alanb at openjdk.org  Thu Jun  5 10:37:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 10:37:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

src/java.base/share/classes/java/lang/Throwable.java line 124:

> 122:      * exceptions should be traced by JFR.
> 123:      */
> 124:     static boolean jfrTracing;

Are you sure this is okay?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128525269

From egahlin at openjdk.org  Thu Jun  5 10:51:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:51:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
 <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
Message-ID: <-LaEF0pmA3xzw9HcVJlYD91h2ek-nUAfB3BQ1NG--Is=.381146ec-7a22-4fc1-aa2c-032726bc134b@github.com>

On Thu, 5 Jun 2025 09:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the mistakenly added file.
>>  - Fix whitespace
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 845:
> 
>> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
>> 844:       <setting name="stackTrace">true</setting>
>> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>
> 
> What was used to propose 100/s as the default and 300/s in profile.jfc?  Just curious if there was a benchmark or test to see the overhead.

It's hard to benchmark since it depends on the application, but we have used 150 events / second for the Object Allocation Sample event without complaints. If you divide one second by 20 ms, the previous threshold, you end up with at most 50 events / second per thread. That said, I think few applications actually have socket read/write around 20-25 ms, so I don't think we should draw too many conclusions from that.

Another way of thinking about it is that the cost of walking maximum 64 stack frames is roughly 5000 ns, so we end up with 100 * 5000 = 500 000 ns or 0.05% of CPU usage. There is also the cost of sampling, and that's why I put in the 1 ms threshold, which puts an upper bound of 1000 sampling attempts per thread.

For profile, I used the same value as Object Allocation Sample.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128549389

From alanb at openjdk.org  Thu Jun  5 11:07:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 11:07:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <iDfQv5IiGJsRClkYco3XrTBrU1XbMUPxSXQ9YlwfA88=.5656cc2f-d519-4eab-951a-5c36babd57c0@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

The usages are much cleaner in the update so I think this all good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899855765

From egahlin at openjdk.org  Thu Jun  5 11:10:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:10:54 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
 <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
Message-ID: <dk_r3oQg_7Ir8nrdVEVm3K3iJ8JX5GM6Bx9iC8k7jXc=.35d39c84-62a2-474a-9c3d-8496474dddee@github.com>

On Thu, 5 Jun 2025 10:35:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code
>
> src/java.base/share/classes/java/lang/Throwable.java line 124:
> 
>> 122:      * exceptions should be traced by JFR.
>> 123:      */
>> 124:     static boolean jfrTracing;
> 
> Are you sure this is okay?

When JFR starts the JVM is brought to safepoint so the whole heap becomes visible. We have used it for socket events without any issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128580995

From egahlin at openjdk.org  Thu Jun  5 11:20:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:20:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <FjjoB-kxB5mI8i2jb_jxw9kkTbwzudcRZnmXQmdWdms=.4446bbc6-7c65-4200-8fd8-9660b7dc30cb@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Thanks for the reviews, the offer methods turned out nicely.

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

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2943787262

From mgronlun at openjdk.org  Thu Jun  5 11:35:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 5 Jun 2025 11:35:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <gn5HwfhUBgCGFVHOTLTYdpOyCN1GJ2_cJtAmKGIsiBI=.7a0fd2dd-0584-4b56-a15b-29dcf16c7b7d@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899934064

From egahlin at openjdk.org  Thu Jun  5 11:39:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:39:01 GMT
Subject: Integrated: 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: <AhEyXqirLtAgGs8Pkoa2uv6V1EyWqdENXIwyjcE_lxY=.957d323b-e3cd-413f-934d-e183bf6b43e5@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 events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: eb770a06
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb770a060ad86d69b38df7d11622e9e25a528e1d
Stats:     1346 lines in 37 files changed: 1056 ins; 174 del; 116 mod

8351594: JFR: Rate-limited sampling of Java events

Reviewed-by: mgronlun, alanb

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

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

From egahlin at openjdk.org  Thu Jun  5 11:45:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:45:00 GMT
Subject: Integrated: 8358590: JFR: Include min and max in MethodTiming event
In-Reply-To: <DU3oC0CKpsQqGBEFsi4CHICb3HQwumcEzWeJnwHsj3g=.74776cd3-8c05-4f79-8a3c-336c3c9d49db@github.com>
References: <DU3oC0CKpsQqGBEFsi4CHICb3HQwumcEzWeJnwHsj3g=.74776cd3-8c05-4f79-8a3c-336c3c9d49db@github.com>
Message-ID: <uom9vfVOsWsq4s_TgFcs4rjWgkj-jKfQ47F0_iK2fb4=.e5e55681-5d1d-4f97-9cb3-8cd46fb5766d@github.com>

On Wed, 4 Jun 2025 11:36:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of this PR that adds minimum and maximum to the MethodTimingEvent.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 6cdfd36a
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cdfd36ac80ad889ddbcfc702115b750a32d9645
Stats:     49 lines in 6 files changed: 42 ins; 0 del; 7 mod

8358590: JFR: Include min and max in MethodTiming event

Reviewed-by: mgronlun

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

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

From cjplummer at openjdk.org  Thu Jun  5 15:16:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Jun 2025 15:16:54 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <vbkzLujju3ftu2UcPbudkR20YRTnLlgtTtRzsasVEpU=.6828f0da-7002-4ac2-ac89-ff728884ea42@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>
 <vbkzLujju3ftu2UcPbudkR20YRTnLlgtTtRzsasVEpU=.6828f0da-7002-4ac2-ac89-ff728884ea42@github.com>
Message-ID: <RyB3WpHjKcAKlg9gtxQr6lMp75rwhVazXVMKbroecRs=.29c16890-221e-47d8-ae3b-d9f7e25ceaec@github.com>

On Thu, 5 Jun 2025 05:49:18 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> > That's not going to be sufficient. The nsk tests are not being run until tier5.
> 
> @plummercj, I've attached the `tier3,4,5` run report to the ticket, would you mind reviewing them, please?

Looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2944947156

From sspitsyn at openjdk.org  Thu Jun  5 17:05:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 5 Jun 2025 17:05:51 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <LOvVAvQXHKLk4bqBxNG4whAXfKzevmb7g_Iv2URNZT0=.ac11e579-5cfa-450c-88d9-b58436e6d41f@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

Looks okay to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25542#pullrequestreview-2901163257

From vyazici at openjdk.org  Fri Jun  6 06:55:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 06:55:58 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

@AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948280027

From vyazici at openjdk.org  Fri Jun  6 06:55:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 06:55:59 GMT
Subject: Integrated: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot]
In-Reply-To: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
Message-ID: <eSlbp4RGgck5nhLN1TpcUtwZBoWC97tksBSqpXyMcBI=.0d552948-b036-4dd0-8fa0-73e35c3e8169@github.com>

On Fri, 30 May 2025 10:50:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: bb2611ad
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb2611ad43a2feaebc2246fdbac2179a40115d67
Stats:     13 lines in 4 files changed: 4 ins; 0 del; 9 mod

8357993: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [hotspot]

Reviewed-by: cjplummer, sspitsyn

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

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

From alanb at openjdk.org  Fri Jun  6 07:25:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jun 2025 07:25:04 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
Message-ID: <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>

On Fri, 6 Jun 2025 06:52:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated.

Okay, but I'm still puzzled as to why the tests were changed as they don't ready from the console.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948340133

From vyazici at openjdk.org  Fri Jun  6 08:09:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 08:09:00 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
 <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
Message-ID: <PFawmtB_T8jyHMFUmQ7RrDnZwTcg493qwQkt2bZVISQ=.7e6fab7d-598e-4cd6-a708-a057bbf3e67a@github.com>

On Fri, 6 Jun 2025 07:21:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay, but I'm still puzzled as to why the tests were changed as they don't ready from the console.

@AlanBateman, I only skipped the practice of passing `stdin.encoding` to `InputStreamReader`/`Scanner` ctors whenever it is obvious that the `System.in` referred there is not the console. Do you imply I was mistaken while assessing `BindServer` and `attach010Agent00`? If so, which ones, and [to learn what I missed] why? I can create a follow-up ticket+PR to amend them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948435515

From alanb at openjdk.org  Fri Jun  6 08:44:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jun 2025 08:44:56 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
 <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
Message-ID: <MeUY0lF1UvMsAVvCp7gKWxmnogJbG3rl3uykiPpTyR0=.5bd36cbb-daf7-4512-859d-50adc33a4c53@github.com>

On Fri, 6 Jun 2025 07:21:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated. ?
>
>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated.
> 
> Okay, but I'm still puzzled as to why the tests were changed as they don't ready from the console.

> @AlanBateman, I only skipped the practice of passing `stdin.encoding` to `InputStreamReader`/`Scanner` ctors whenever it is obvious that the `System.in` referred there is not the console. Do you imply I was mistaken while assessing `BindServer` and `attach010Agent00`? If so, which ones, and [to learn what I missed] why? I can create a follow-up ticket+PR to amend them.

Tests are automated and very rare to have tests read from an interactive console. A small number of test uses "expect" for testing interactive input. There might be tests that have stdin redirected from a file or something else.

For multi VM tests (very common in the test suite) then you typically see the parent process using Process/ProcessBuilder and starting a child VM with its standard streams connected to the parent, meaning reading from System.in will read from a pipe connected to the parent. Some tests do inherit but I doubt we have any tests that inherit and also read from an interactive console.

So my point is that we probably don't need to jump on all tests that use System.in. The tests that do read from System.in probably need closer examination to see if they are reading from a pipe or something else.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948526535

From vyazici at openjdk.org  Fri Jun  6 11:48:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:48:54 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <MeUY0lF1UvMsAVvCp7gKWxmnogJbG3rl3uykiPpTyR0=.5bd36cbb-daf7-4512-859d-50adc33a4c53@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
 <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
 <MeUY0lF1UvMsAVvCp7gKWxmnogJbG3rl3uykiPpTyR0=.5bd36cbb-daf7-4512-859d-50adc33a4c53@github.com>
Message-ID: <kSazC1jCUEQekQsZ9BqVIRqve39JATAtmDEi5vmz6Yc=.6dbf3b21-a921-434d-b4fc-336afce483af@github.com>

On Fri, 6 Jun 2025 08:42:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For multi VM tests (very common in the test suite) then you typically see the parent process using Process/ProcessBuilder and starting a child VM with its standard streams connected to the parent, meaning reading from System.in will read from a pipe connected to the parent. Some tests do inherit but I doubt we have any tests that inherit and also read from an interactive console.
> 
> So my point is that we probably don't need to jump on all tests that use System.in.

_I think_ ? I see your point, and I agree with it. I've dropped several of my earlier changes from the abandoned parent #25368 ? this applies to all subsequent tickets: #25544 (core), #25541 (tools), and this one. When the subject code is called in a `Process`, or the stream is obtained from a `URL` or a `ClassLoader`, ..., when it is _"obvious"_ that the stream doesn't refer to the console, I've skipped the `stdin.encoding` refactoring. That said, _"obvious"_ is very subjective and I might have misjudged certain usages.

> The tests that do read from System.in probably need closer examination to see if they are reading from a pipe or something else.

In all `stdin.encoding` PRs ? #25544 (core), #25541 (tools), and this one ? I've examined usages before introducing the changes. I did my best, but I cannot claim it was exhaustive. That said, if it requires a significant effort to deduce that the console is not involved in a `System.in` usage, I'd prefer to include the `stdin.encoding` best-practice. There is a considerable likelihood that a later change could inadvertently violate that subtle assumption.

@AlanBateman, if you think a particular change needs closer examination or needs to be reverted, please say so. I'd be more than happy to carry out that task.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948996963

From cjplummer at openjdk.org  Fri Jun  6 19:28:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 6 Jun 2025 19:28:55 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

BindServer.java is not used. It can be removed.

The changes in attach010Agent00.java are unnecessary because System.in has been set to read from a file:

35     private static final String inStreamFileName = "AttachOnDemand.attach010.in";
60         FileInputStream newInputStream = new FileInputStream(inStreamFileName);
61         System.setIn(newInputStream);

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2950447745

From vyazici at openjdk.org  Sun Jun  8 21:12:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Sun, 8 Jun 2025 21:12:59 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
Message-ID: <aqslvw1rOZF6ZNxjjm_XCrn7xhOYhc-ia-z957pV9B8=.9c9eb7c8-f491-4052-8a94-c5287a06b330@github.com>

On Fri, 6 Jun 2025 19:26:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Provide fallback for `stdin.encoding`
>
> BindServer.java is not used. It can be removed.
> 
> The changes in attach010Agent00.java are unnecessary because System.in has been set to read from a file:
> 
> 35     private static final String inStreamFileName = "AttachOnDemand.attach010.in";
> 60         FileInputStream newInputStream = new FileInputStream(inStreamFileName);
> 61         System.setIn(newInputStream);

@plummercj, shall I create a ticket+PR to

1. remove `BindServer.java`, and
2. revert changes to `attach010Agent00.java`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2954277726

From cjplummer at openjdk.org  Mon Jun  9 15:48:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Jun 2025 15:48:08 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
Message-ID: <oGvae3hPJsYSkm5JkdIKqxmac3hoe-V-QA1JEjZ95-g=.b48821db-4e45-4b99-aa16-d0aba006e2b6@github.com>

On Fri, 6 Jun 2025 19:26:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Provide fallback for `stdin.encoding`
>
> BindServer.java is not used. It can be removed.
> 
> The changes in attach010Agent00.java are unnecessary because System.in has been set to read from a file:
> 
> 35     private static final String inStreamFileName = "AttachOnDemand.attach010.in";
> 60         FileInputStream newInputStream = new FileInputStream(inStreamFileName);
> 61         System.setIn(newInputStream);

> @plummercj, shall I create a ticket+PR to
> 
>     1. remove `BindServer.java`, and
> 
>     2. revert changes to `attach010Agent00.java`?

Yes. It might be better to make them 2 PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2956182139

From egahlin at openjdk.org  Tue Jun 10 13:16:07 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 10 Jun 2025 13:16:07 GMT
Subject: RFR: 8358602: JFR: Annotations in jdk.jfr package should not use
 "not null" in specification
Message-ID: <lILMkjao_vjbgJ9d8CLvcBSpzsZyurXyUTiorzoE_JA=.06e66d28-2792-4b20-9727-738d6305fb01@github.com>

Could I have review of PR that fixes the specification / documentation for annotations in the jdk.jfr package.

Testing: tier1 + jdk/jdk/jfr

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25723&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358602
  Stats: 15 lines in 8 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/25723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25723/head:pull/25723

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

From mgronlun at openjdk.org  Tue Jun 10 17:01:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 10 Jun 2025 17:01:28 GMT
Subject: RFR: 8358602: JFR: Annotations in jdk.jfr package should not use
 "not null" in specification
In-Reply-To: <lILMkjao_vjbgJ9d8CLvcBSpzsZyurXyUTiorzoE_JA=.06e66d28-2792-4b20-9727-738d6305fb01@github.com>
References: <lILMkjao_vjbgJ9d8CLvcBSpzsZyurXyUTiorzoE_JA=.06e66d28-2792-4b20-9727-738d6305fb01@github.com>
Message-ID: <Er-ZOMYI52_IK7-4mLiQ0do8VNiLdD8v7Bs_j6htjNQ=.72791c0d-5cb7-40ff-8053-fe5d0fc75f84@github.com>

On Tue, 10 Jun 2025 12:48:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that fixes the specification / documentation for annotations in the jdk.jfr package.
> 
> Testing: tier1 + jdk/jdk/jfr

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25723#pullrequestreview-2914382380

From vyazici at openjdk.org  Tue Jun 10 20:34:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 10 Jun 2025 20:34:35 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <2q9j9ODae3SFNCHdS9fpasGuXrm3wWGXip_Fk1NNvIk=.ba677f20-2660-4d93-91e7-6debc0ad4cfd@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

I've created

- [8359167](https://bugs.openjdk.org/browse/JDK-8359167): Remove unused test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
- [8359168](https://bugs.openjdk.org/browse/JDK-8359168): Revert stdin.encoding usage in test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java

Used `hotspot` and `test` as `Component/s` and `Subcomponent`, respectively ? hope that is okay. Feel free to update the tickets as you see fit. I will try to pick them up sometime this week.

@plummercj, @AlanBateman, thank you for your assistance and patience. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2960509836

From mdoerr at openjdk.org  Wed Jun 11 10:18:10 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Jun 2025 10:18:10 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
In-Reply-To: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
Message-ID: <whsFAmzN7SjWLrvN-M5UyY7a_8f_3OPTXE43rLffAWs=.5003472e-e4a6-48e2-b0ea-895e1e00f009@github.com>

On Wed, 11 Jun 2025 10:10:25 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.

Thanks! 25% should hopefully avoid intermittent failures.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25745#pullrequestreview-2916508242

From jbechberger at openjdk.org  Wed Jun 11 10:18:10 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 11 Jun 2025 10:18:10 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
In-Reply-To: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
Message-ID: <dnI0fss2Dqa_AtmoSI12wvIBLoYtddewC-ZxAViZaYc=.ae0f9c76-1713-4866-a603-b490dd41fa1a@github.com>

On Wed, 11 Jun 2025 10:10:25 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.

Although one could say that I should not have symmetric bounds, I expect to get fewer samples; if I get significantly more, then I probably have a bug. Maybe I should therefore use `0.75 < rate < 1.1`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25745#issuecomment-2962079022

From jbechberger at openjdk.org  Wed Jun 11 10:18:10 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 11 Jun 2025 10:18:10 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
Message-ID: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>

I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.

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

Commit messages:
 - 8359135: New test TestCPUTimeSampleThrottling fails intermittently

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

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

From jbechberger at openjdk.org  Wed Jun 11 11:11:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 11 Jun 2025 11:11:50 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
Message-ID: <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>

> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Remove debug code
 - Make upper-bound narrower

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25745/files
  - new: https://git.openjdk.org/jdk/pull/25745/files/7f9fda63..57a3f447

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

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

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

From mdoerr at openjdk.org  Wed Jun 11 11:44:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Jun 2025 11:44:29 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
Message-ID: <9qL89mmtHWhset08ZwM2zaEJmx5I5nTlj7eqcFSs4-E=.ecf9180b-88eb-41c1-9098-76d2a87086f1@github.com>

On Wed, 11 Jun 2025 11:11:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove debug code
>  - Make upper-bound narrower

Looks good and trivial.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25745#pullrequestreview-2916793102

From egahlin at openjdk.org  Wed Jun 11 14:13:29 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 11 Jun 2025 14:13:29 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
Message-ID: <XkdrbHpyKzDIiyADfCuGd-8_fnaprfdL6UTB0PcfLJg=.cb42f125-660f-4238-8c74-81dd59442c9b@github.com>

On Wed, 11 Jun 2025 11:11:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove debug code
>  - Make upper-bound narrower

My experience with tests that make a recording and check some time-related bounds is that they fail sooner or later. The hardware is slow, a GC happens etc. 

Maybe you could use an event stream and let it run until you hit, let's say, 50-150 samples / second?

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

PR Comment: https://git.openjdk.org/jdk/pull/25745#issuecomment-2962997568

From jbechberger at openjdk.org  Wed Jun 11 14:59:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 11 Jun 2025 14:59:29 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
Message-ID: <Z7QXrswhbdlaT8GeQPoooCZIUecDEWIPEITQR1-7ESY=.249e0d62-7bb9-4b2c-9b37-da4add4cfaa4@github.com>

On Wed, 11 Jun 2025 11:11:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove debug code
>  - Make upper-bound narrower

But I still want to see when we have large deviations, which might indicate a bug. The 75 boundary is low enough that it we should not run into the issues you described.

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

PR Comment: https://git.openjdk.org/jdk/pull/25745#issuecomment-2963167764

From egahlin at openjdk.org  Wed Jun 11 15:05:28 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 11 Jun 2025 15:05:28 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <Z7QXrswhbdlaT8GeQPoooCZIUecDEWIPEITQR1-7ESY=.249e0d62-7bb9-4b2c-9b37-da4add4cfaa4@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
 <Z7QXrswhbdlaT8GeQPoooCZIUecDEWIPEITQR1-7ESY=.249e0d62-7bb9-4b2c-9b37-da4add4cfaa4@github.com>
Message-ID: <c7VgFFKZmnCsNKDHzLQoGdOzhUcz91pEwvhwN3rOVi8=.b12c16d2-0288-4145-909f-8f3cceeb6ef8@github.com>

On Wed, 11 Jun 2025 14:57:11 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> But I still want to see when we have large deviations, which might indicate a bug. The 75 boundary is low enough that it we should not run into the issues you described.

Ok, but I think you will be back with a new test failure soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25745#issuecomment-2963185727

From jbechberger at openjdk.org  Wed Jun 11 15:10:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 11 Jun 2025 15:10:32 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
Message-ID: <GcJ2xUgsEogLgqKn-QONgS1Xkt0AAQ5GitQm0QkceR8=.d93d2ab3-76ce-4844-b9c4-444a4995dda1@github.com>

On Wed, 11 Jun 2025 11:11:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove debug code
>  - Make upper-bound narrower

This test already only takes CPU-time into account (so this prevents issues with system load), and even if the thread is in the wrong state (like in VM or in GC), events are recorded (with `failed=true`). So I disagree with you.

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

PR Comment: https://git.openjdk.org/jdk/pull/25745#issuecomment-2963205790

From egahlin at openjdk.org  Wed Jun 11 15:17:28 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 11 Jun 2025 15:17:28 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <GcJ2xUgsEogLgqKn-QONgS1Xkt0AAQ5GitQm0QkceR8=.d93d2ab3-76ce-4844-b9c4-444a4995dda1@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
 <GcJ2xUgsEogLgqKn-QONgS1Xkt0AAQ5GitQm0QkceR8=.d93d2ab3-76ce-4844-b9c4-444a4995dda1@github.com>
Message-ID: <KJ91ShMAUNxH_-A_svlnb0bcB3Ug1G_cLM4xZytIcCA=.17dd0816-427e-47a9-8efb-cb1c37b38446@github.com>

On Wed, 11 Jun 2025 15:08:16 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This test already only takes CPU-time into account (so this prevents issues with system load), and even if the thread is in the wrong state (like in VM or in GC), events are recorded (with `failed=true`). So I disagree with you.

That's fine. Check it in.

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

PR Comment: https://git.openjdk.org/jdk/pull/25745#issuecomment-2963224594

From jbechberger at openjdk.org  Wed Jun 11 15:21:28 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 11 Jun 2025 15:21:28 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v2]
In-Reply-To: <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <mmjZlLYPnrZ54wydpKvBvFxMvFA74Rm0whEKRDHb0dc=.6105e82d-27f5-4fb7-891d-d647e264796f@github.com>
Message-ID: <_iRyjRiL7d5a_yW52HQ4RhxuOG8-L3qMF-DLKBj9hLY=.4e1da6e1-5f66-41db-9b2a-db1e21f4de02@github.com>

On Wed, 11 Jun 2025 11:11:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove debug code
>  - Make upper-bound narrower

Good, but I feel I should document this somewhere in a comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/25745#issuecomment-2963241791

From jbechberger at openjdk.org  Wed Jun 11 15:28:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 11 Jun 2025 15:28:08 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v3]
In-Reply-To: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
Message-ID: <D7vdDtUOXHXeLGlY6kzEH5R2Mflgc_GFyYagIJTN6gc=.0346a106-e8e1-48f6-a4d5-851e30014b5d@github.com>

> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25745/files
  - new: https://git.openjdk.org/jdk/pull/25745/files/57a3f447..5ce6cf35

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

  Stats: 15 lines in 1 file changed: 8 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25745/head:pull/25745

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

From egahlin at openjdk.org  Wed Jun 11 16:34:40 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 11 Jun 2025 16:34:40 GMT
Subject: RFR: 8359242: JFR: Missing help text for method trace and timing
Message-ID: <HcOoPbadxLEpydbOPll2C0pb7lTB5heRYuiEBrIAsJQ=.66972a51-ab69-4472-80d7-c10a05e72f6b@github.com>

Could I have a review of a PR that adds missing help texts for method trace and method timing? Without, it's hard for user to understand how the feature can be used in JMC or with "jfr configure --interactive"

Testing:  test/jdk/jdk/jfr  + tier1

Thanks
Erik

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

Commit messages:
 - Improve
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25759/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25759&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359242
  Stats: 54 lines in 8 files changed: 36 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25759/head:pull/25759

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

From mdoerr at openjdk.org  Wed Jun 11 16:44:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Jun 2025 16:44:29 GMT
Subject: RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently [v3]
In-Reply-To: <D7vdDtUOXHXeLGlY6kzEH5R2Mflgc_GFyYagIJTN6gc=.0346a106-e8e1-48f6-a4d5-851e30014b5d@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
 <D7vdDtUOXHXeLGlY6kzEH5R2Mflgc_GFyYagIJTN6gc=.0346a106-e8e1-48f6-a4d5-851e30014b5d@github.com>
Message-ID: <RF2ca_8OTaQuIYQFFDzGtMRKyKr6uVpSQaWuF0HnkYw=.719d9c35-1e3f-468e-9d5b-802dec291c51@github.com>

On Wed, 11 Jun 2025 15:28:08 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Still good.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25745#pullrequestreview-2917974820

From egahlin at openjdk.org  Wed Jun 11 20:52:09 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 11 Jun 2025 20:52:09 GMT
Subject: RFR: 8359242: JFR: Missing help text for method trace and timing
 [v2]
In-Reply-To: <HcOoPbadxLEpydbOPll2C0pb7lTB5heRYuiEBrIAsJQ=.66972a51-ab69-4472-80d7-c10a05e72f6b@github.com>
References: <HcOoPbadxLEpydbOPll2C0pb7lTB5heRYuiEBrIAsJQ=.66972a51-ab69-4472-80d7-c10a05e72f6b@github.com>
Message-ID: <OjgLfY5QGfeZfh8DMisZbkYhtuYGoKLu3iBi8kN2H-I=.2fd81aca-b61c-4cd2-a0c3-913b8a6bc27c@github.com>

> Could I have a review of a PR that adds missing help text for method trace and method timing? Without it, it's hard for users to understand how the feature can be used in JMC or with `jfr configure --interactive`.
> 
> Testing:  test/jdk/jdk/jfr  + tier1
> 
> Thanks
> Erik

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

  Restore accidentally changed file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25759/files
  - new: https://git.openjdk.org/jdk/pull/25759/files/6ed4825e..a23b5489

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

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

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

From jbechberger at openjdk.org  Thu Jun 12 08:57:40 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 12 Jun 2025 08:57:40 GMT
Subject: Integrated: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
In-Reply-To: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
References: <04iTDD9yJI60x75w9Ir6cTPD-19qhaUHkblkakXLEt0=.ad9e8ea5-717a-4b6c-9450-2218ccee2421@github.com>
Message-ID: <uhkf2DA3ugOlvi2t7wRx3jvpJ6TWCHmUFuZF94Mf4qQ=.95b7b81e-b023-4d36-b3cb-4b72d8c741ec@github.com>

On Wed, 11 Jun 2025 10:10:25 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> I increased the tolerated rate deviation to make the test less flaky on systems like PowerPC. The deviation comes from the thread not being in the Java and native states on some platforms compared to others.

This pull request has now been integrated.

Changeset: 3f0fef2c
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f0fef2c9c323cb7b6e9191b17eac4296ff22dac
Stats:     16 lines in 1 file changed: 8 ins; 2 del; 6 mod

8359135: New test TestCPUTimeSampleThrottling fails intermittently

Reviewed-by: mdoerr

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

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

From mgronlun at openjdk.org  Thu Jun 12 09:06:36 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 12 Jun 2025 09:06:36 GMT
Subject: RFR: 8359242: JFR: Missing help text for method trace and timing
 [v2]
In-Reply-To: <OjgLfY5QGfeZfh8DMisZbkYhtuYGoKLu3iBi8kN2H-I=.2fd81aca-b61c-4cd2-a0c3-913b8a6bc27c@github.com>
References: <HcOoPbadxLEpydbOPll2C0pb7lTB5heRYuiEBrIAsJQ=.66972a51-ab69-4472-80d7-c10a05e72f6b@github.com>
 <OjgLfY5QGfeZfh8DMisZbkYhtuYGoKLu3iBi8kN2H-I=.2fd81aca-b61c-4cd2-a0c3-913b8a6bc27c@github.com>
Message-ID: <hNhgw84RhG2npr7LhM-A9cbHVgsBjVKbUblAF9UDZbU=.cca91a7b-140f-45b3-a539-04fe5e8cca7f@github.com>

On Wed, 11 Jun 2025 20:52:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that adds missing help text for method trace and method timing? Without it, it's hard for users to understand how the feature can be used in JMC or with `jfr configure --interactive`.
>> 
>> Testing:  test/jdk/jdk/jfr  + tier1
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore accidentally changed file

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25759#pullrequestreview-2920171358

From jbechberger at openjdk.org  Thu Jun 12 09:36:48 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 12 Jun 2025 09:36:48 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler
Message-ID: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>

Fixes the recomputation issue by passing either the rate or the period directly to the sampler (instead of just the rate value with the period value converted into a rate). This prevents issues when the number of cores changes during the JFR recording.

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

Commit messages:
 - 8358619: Fix interval recomputation in CPU Time Profiler

Changes: https://git.openjdk.org/jdk/pull/25775/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25775&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358619
  Stats: 327 lines in 11 files changed: 180 ins; 78 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/25775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25775/head:pull/25775

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

From jbechberger at openjdk.org  Thu Jun 12 09:48:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 12 Jun 2025 09:48:02 GMT
Subject: [jdk25] RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
Message-ID: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>

Tested in SAP's testing queue.

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

Commit messages:
 - Backport 3f0fef2c9c323cb7b6e9191b17eac4296ff22dac

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

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

From mdoerr at openjdk.org  Thu Jun 12 09:48:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 12 Jun 2025 09:48:02 GMT
Subject: [jdk25] RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
In-Reply-To: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
References: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
Message-ID: <PUywyzfK8Ng-XFmAVZMR8WEpfS6DXG9JSrwV_2VgvaM=.a82b85f4-f215-42f7-a105-10aaa780a68a@github.com>

On Thu, 12 Jun 2025 09:40:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Tested in SAP's testing queue.

Simple P3 test fix. Applies cleanly.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25776#pullrequestreview-2920330900

From erwan.viollet at gmail.com  Thu Jun 12 15:07:12 2025
From: erwan.viollet at gmail.com (Erwan Viollet)
Date: Thu, 12 Jun 2025 17:07:12 +0200
Subject: JFR: Scrubbing sensitive information from events
In-Reply-To: <DS7PR10MB5118CDB3DDFDA3044761C8B59D62A@DS7PR10MB5118.namprd10.prod.outlook.com>
References: <CACX82zeW1sQRHAYZW52GLtWczKVAt=Q5_=arHHSnYRKz_QXOmg@mail.gmail.com>
 <DS7PR10MB5118CDB3DDFDA3044761C8B59D62A@DS7PR10MB5118.namprd10.prod.outlook.com>
Message-ID: <CACX82zchxZU-kf1d57_qxSGhmVVWbspipQMiKE5g7ghOUXH9GA@mail.gmail.com>

Hello,

Here is an example of the types of events we are concerned about:

Recording
?
??? Event (e.g. jdk.InitialSystemProperty)
?     ??? eventType: "jdk.InitialSystemProperty"
?     ??? startTime
?     ??? duration
?     ??? fields:
?     ?     ??? key: "javax.net.ssl.keyStorePassword"
?     ?     ??? value: "*supersecret*"
?     ?     ??? ...
?     ??? ...
?
??? Event (e.g. jdk.JVMInformation)
?     ??? eventType: "jdk.JVMInformation"
?     ??? jvmArguments: [ "-Xmx4G", "-Djavax.net.ssl.keyStorePassword=
*supersecret*", ... ]
?     ??? ...
?
??? ...

The rules are slightly challenging as they need to account for key/value
pairs, arrays and simple fields (like commandLine field).
Here <https://gist.github.com/r1viollet/812ed70c6410c4f62640fd792570d36c>
is a scrub file example. I'm happy to consider ways to simplify this
proposal. Storing JFR files would also be helpful to consider test cases.
Regards,

Erwan


Le mar. 3 juin 2025 ? 11:50, Erik Gahlin <erik.gahlin at oracle.com> a ?crit :

> We have discussed it, but we don't understand all the details. We are also
> unsure how to best expose it to the end user. Let's say there was a command
> line option -XX:FlightRecorder:scrub-file=<file>.
>
> What would you fill that file with? I want examples that work on real data
> to understand how expressive the filters must be.
>
> Thanks
> Erik
> ------------------------------
> *From:* hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of
> Erwan Viollet <erwan.viollet at gmail.com>
> *Sent:* Monday, June 2, 2025 3:30 PM
> *To:* hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
> *Subject:* JFR: Scrubbing sensitive information from events
>
> Hello,
>
> I am currently looking into how to remove sensitive information from JFR
> events. The main events that typically contain sensitive information:
> jdk.SystemProcess,  jdk.InitialSystemProperty, jdk.JVMInformation.
> Passwords from command lines can typically be found in these events.
>
> Dropping these events altogether is not ideal, as we need them to make
> relevant performance recommendations to users (e.g. suggesting JVM or
> system setting adjustments).
>
> Dropping them or scrubbing them on the backend side (after the fact)
> requires decompressing and re-writing these events, which is wasteful in
> terms of both compute and storage. The approach is not perfect, as we still
> end up intaking and temporarily storing sensitive information.
>
> Ideally, we would like to be able to scrub or redact only the sensitive
> fields within these events (for example, using a simple regex or
> pattern-based rule), rather than dropping the whole event. We also want to
> avoid handling this only after the event has already been written to the
> JFR file, as that does not fully mitigate the risk of exposing sensitive
> data.
>
> At present, it appears there is no public API or supported mechanism to
> intercept or scrub JFR events in-process, before they are persisted. What
> would you think of an API accepting custom scrubbing patterns so that
> sensitive data never leaves the JVM in an unredacted state?
>
> Are there any plans or discussions in this area? I am fairly new to the
> JFR world, so it is likely that I missed previous discussions around this.
>
> Thank you, Best regards,
>
> Erwan Viollet,
>
> Profiling team, Datadog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250612/4296c5b7/attachment.htm>

From erik.gahlin at oracle.com  Thu Jun 12 17:24:29 2025
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 12 Jun 2025 17:24:29 +0000
Subject: [External] : Re: JFR: Scrubbing sensitive information from events
In-Reply-To: <CACX82zchxZU-kf1d57_qxSGhmVVWbspipQMiKE5g7ghOUXH9GA@mail.gmail.com>
References: <CACX82zeW1sQRHAYZW52GLtWczKVAt=Q5_=arHHSnYRKz_QXOmg@mail.gmail.com>
 <DS7PR10MB5118CDB3DDFDA3044761C8B59D62A@DS7PR10MB5118.namprd10.prod.outlook.com>
 <CACX82zchxZU-kf1d57_qxSGhmVVWbspipQMiKE5g7ghOUXH9GA@mail.gmail.com>
Message-ID: <DS7PR10MB511850094C5F8B1EDE853EC89D74A@DS7PR10MB5118.namprd10.prod.outlook.com>

Thanks for the file.

I worry that processing the file in the JVM or creating an intuitive Java API for post-processing it will be hard. The context/event determines what needs to be redacted. If scrubbing is only necessary for these four events, hardcoding the sensitive tokens and logic into the JVM might be a viable approach.

Users would specify:

 $ java -XX:FlightRecorderOptions:scrub-sensitive=true

or it might be enabled by default and users would need to opt-out.

Anyway, if enabled, a jfrScrub.cpp class would do the job. Something like this:

    EventInitialEnvironmentVariable event(UNTIMED);
    event.set_starttime(time_stamp);
    event.set_endtime(time_stamp);
    event.set_key(key);
    if (JfrScrub::is_sensitive_key(key)) {
      event.set_value("[REDACTED]");
    } else {
      event.set_value(value);
    }
    event.commit();

    EventInitialSystemProperty event(UNTIMED);
    event.set_key(p->key());
    if (JfrScrub::is_sensitive_key(p->key()) {
       event.set_value("[REDACTED]");
    } else {
       event.set_value(p->value());
    }
    event.set_starttime(time_stamp);
    event.set_endtime(time_stamp);
    event.commit();

    EventSystemProcess event(UNTIMED);
    event.set_pid(pid_buf);
    event.set_commandLine(JfrScrub::command_line(info));
    event.set_starttime(start_time);
    event.set_endtime(end_time);
    event.commit();

    EventJVMInformation event;
    event.set_jvmName(VM_Version::vm_name());
    event.set_jvmVersion(VM_Version::internal_vm_info_string());
    event.set_javaArguments(JfrScrub::command_line(Arguments::java_command()));
    event.set_jvmArguments(Arguments::jvm_args());
    event.set_jvmFlags(Arguments::jvm_flags());
    event.set_jvmStartTime(Management::vm_init_done_time());
    event.set_pid(os::current_process_id());
    event.commit();

It's a bit ugly and not as flexible, but perhaps that's something we need to tolerate. Or will it be useless because new passwords/keys will be added all the time, or because they will match false positives, and more advanced logic is needed? Perhaps it will give users the false(?) impression that they don't need to worry about sensitive data?

Thanks
Erik
________________________________
From: Erwan Viollet <erwan.viollet at gmail.com>
Sent: Thursday, June 12, 2025 5:07 PM
To: Erik Gahlin <erik.gahlin at oracle.com>
Cc: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: [External] : Re: JFR: Scrubbing sensitive information from events

Hello,

Here is an example of the types of events we are concerned about:

Recording
?
??? Event (e.g. jdk.InitialSystemProperty)
?     ??? eventType: "jdk.InitialSystemProperty"
?     ??? startTime
?     ??? duration
?     ??? fields:
?     ?     ??? key: "javax.net.ssl.keyStorePassword"
?     ?     ??? value: "supersecret"
?     ?     ??? ...
?     ??? ...
?
??? Event (e.g. jdk.JVMInformation)
?     ??? eventType: "jdk.JVMInformation"
?     ??? jvmArguments: [ "-Xmx4G", "-Djavax.net.ssl.keyStorePassword=supersecret", ... ]
?     ??? ...
?
??? ...

The rules are slightly challenging as they need to account for key/value pairs, arrays and simple fields (like commandLine field).
Here<https://urldefense.com/v3/__https://gist.github.com/r1viollet/812ed70c6410c4f62640fd792570d36c__;!!ACWV5N9M2RV99hQ!LrFg9xF9Jy2l4LW6sj6mxVPhLXr30tA_2lzstCSiBbi4SxLyh8t2wDJGc4E1b7ePKrrsivDhkoZtMsHWCKsBeBLJ$> is a scrub file example. I'm happy to consider ways to simplify this proposal. Storing JFR files would also be helpful to consider test cases.
Regards,

Erwan


Le mar. 3 juin 2025 ? 11:50, Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>> a ?crit :
We have discussed it, but we don't understand all the details. We are also unsure how to best expose it to the end user. Let's say there was a command line option -XX:FlightRecorder:scrub-file=<file>.

What would you fill that file with? I want examples that work on real data to understand how expressive the filters must be.

Thanks
Erik
________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org<mailto:hotspot-jfr-dev-retn at openjdk.org>> on behalf of Erwan Viollet <erwan.viollet at gmail.com<mailto:erwan.viollet at gmail.com>>
Sent: Monday, June 2, 2025 3:30 PM
To: hotspot-jfr-dev at openjdk.org<mailto:hotspot-jfr-dev at openjdk.org> <hotspot-jfr-dev at openjdk.org<mailto:hotspot-jfr-dev at openjdk.org>>
Subject: JFR: Scrubbing sensitive information from events

Hello,

I am currently looking into how to remove sensitive information from JFR events. The main events that typically contain sensitive information: jdk.SystemProcess,  jdk.InitialSystemProperty, jdk.JVMInformation. Passwords from command lines can typically be found in these events.

Dropping these events altogether is not ideal, as we need them to make relevant performance recommendations to users (e.g. suggesting JVM or system setting adjustments).

Dropping them or scrubbing them on the backend side (after the fact) requires decompressing and re-writing these events, which is wasteful in terms of both compute and storage. The approach is not perfect, as we still end up intaking and temporarily storing sensitive information.

Ideally, we would like to be able to scrub or redact only the sensitive fields within these events (for example, using a simple regex or pattern-based rule), rather than dropping the whole event. We also want to avoid handling this only after the event has already been written to the JFR file, as that does not fully mitigate the risk of exposing sensitive data.

At present, it appears there is no public API or supported mechanism to intercept or scrub JFR events in-process, before they are persisted. What would you think of an API accepting custom scrubbing patterns so that sensitive data never leaves the JVM in an unredacted state?

Are there any plans or discussions in this area? I am fairly new to the JFR world, so it is likely that I missed previous discussions around this.

Thank you, Best regards,

Erwan Viollet,

Profiling team, Datadog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250612/fb79b20d/attachment-0001.htm>

From egahlin at openjdk.org  Fri Jun 13 10:50:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 13 Jun 2025 10:50:42 GMT
Subject: Integrated: 8358602: JFR: Annotations in jdk.jfr package should not
 use "not null" in specification
In-Reply-To: <lILMkjao_vjbgJ9d8CLvcBSpzsZyurXyUTiorzoE_JA=.06e66d28-2792-4b20-9727-738d6305fb01@github.com>
References: <lILMkjao_vjbgJ9d8CLvcBSpzsZyurXyUTiorzoE_JA=.06e66d28-2792-4b20-9727-738d6305fb01@github.com>
Message-ID: <iGv1esfnGLMq4U_EoX3BJN3hjeOke6Kn0zU_jGI8S4c=.eb573721-6c31-43b7-9c0d-8bfcca134c80@github.com>

On Tue, 10 Jun 2025 12:48:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that fixes the specification / documentation for annotations in the jdk.jfr package.
> 
> Testing: tier1 + jdk/jdk/jfr

This pull request has now been integrated.

Changeset: 25b22c9b
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25b22c9b553ffab82eb44df23f6b4942724aedaf
Stats:     15 lines in 8 files changed: 0 ins; 0 del; 15 mod

8358602: JFR: Annotations in jdk.jfr package should not use "not null" in specification

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Fri Jun 13 11:25:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 13 Jun 2025 11:25:46 GMT
Subject: RFR: 8359248: JFR: Help text
 for-XX:StartFlightRecording:report-on-exit should explain option can be
 repeated
Message-ID: <r7u_lxK6artjxrAA0gX7rKG4So_30YBmQENs6oQA59A=.ab4626c9-824b-41ed-b9d2-ea7b66e79945@github.com>

Could I have review of a PR that updates the help text for report-on-exit so it clarifies that the option can be repeated.

Testing: jdk/jdk/jfr + tier1

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Fri Jun 13 12:22:36 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 13 Jun 2025 12:22:36 GMT
Subject: RFR: 8359248: JFR: Help text
 for-XX:StartFlightRecording:report-on-exit should explain option can be
 repeated
In-Reply-To: <r7u_lxK6artjxrAA0gX7rKG4So_30YBmQENs6oQA59A=.ab4626c9-824b-41ed-b9d2-ea7b66e79945@github.com>
References: <r7u_lxK6artjxrAA0gX7rKG4So_30YBmQENs6oQA59A=.ab4626c9-824b-41ed-b9d2-ea7b66e79945@github.com>
Message-ID: <6wcFWvoHZAajzudIOgGQi2FQI4IakGfcNGNqb0Rt7bU=.c931b87b-af65-4668-a6dc-057a295fe784@github.com>

On Fri, 13 Jun 2025 11:01:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a PR that updates the help text for report-on-exit so it clarifies that the option can be repeated.
> 
> Testing: jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25797#pullrequestreview-2924614601

From erwan.viollet at gmail.com  Fri Jun 13 12:51:22 2025
From: erwan.viollet at gmail.com (Erwan Viollet)
Date: Fri, 13 Jun 2025 14:51:22 +0200
Subject: [External] : Re: JFR: Scrubbing sensitive information from events
In-Reply-To: <DS7PR10MB511850094C5F8B1EDE853EC89D74A@DS7PR10MB5118.namprd10.prod.outlook.com>
References: <CACX82zeW1sQRHAYZW52GLtWczKVAt=Q5_=arHHSnYRKz_QXOmg@mail.gmail.com>
 <DS7PR10MB5118CDB3DDFDA3044761C8B59D62A@DS7PR10MB5118.namprd10.prod.outlook.com>
 <CACX82zchxZU-kf1d57_qxSGhmVVWbspipQMiKE5g7ghOUXH9GA@mail.gmail.com>
 <DS7PR10MB511850094C5F8B1EDE853EC89D74A@DS7PR10MB5118.namprd10.prod.outlook.com>
Message-ID: <CACX82zcEEqKM+wWb86JPVEE=ufuxvTkUiXGO4dS6cxTAcNXaDg@mail.gmail.com>

I like the simple and pragmatic approach. Especially if we can have this as
default.
Writing custom scrubbing logic for these specific events is much more
straightforward than building a generic scrubbing framework.

To address the risk of missing sensitive patterns that are specific to user
environments, I'd suggest adding a customization option:
# Allow users to extend or override default patterns
-XX:FlightRecorderOptions:scrub-sensitive-patterns="password,secret,key,token,credential,auth,pwd,passwd,api[_-]?key,custompattern"

We had to do the same for the Datadog Agent process scrubbing
<https://docs.datadoghq.com/infrastructure/process/?tab=linuxwindows#process-arguments-scrubbing>,
where users can specify `custom_sensitive_words` to handle their specific
use cases.

The remaining questions:
1. Scope limitations: Are there any known use cases that would be impacted
by limiting scrubbing to these four event types? We believe this covers the
vast majority of sensitive data exposure, but want to ensure we're not
missing critical scenarios.

2. Default pattern selection:
We should align on what a reasonable default would look like. We can use
our JFR Data to do this.

Regards,

Erwan

Le jeu. 12 juin 2025 ? 19:24, Erik Gahlin <erik.gahlin at oracle.com> a ?crit :

> Thanks for the file.
>
> I worry that processing the file in the JVM or creating an intuitive Java
> API for post-processing it will be hard. The context/event determines what
> needs to be redacted. If scrubbing is only necessary for these four events,
> hardcoding the sensitive tokens and logic into the JVM might be a viable
> approach.
>
> Users would specify:
>
>  $ java -XX:FlightRecorderOptions:scrub-sensitive=true
>
> or it might be enabled by default and users would need to opt-out.
>
> Anyway, if enabled, a jfrScrub.cpp class would do the job. Something like
> this:
>
>     EventInitialEnvironmentVariable event(UNTIMED);
>     event.set_starttime(time_stamp);
>     event.set_endtime(time_stamp);
>     event.set_key(key);
>     if (JfrScrub::is_sensitive_key(key)) {
>       event.set_value("[REDACTED]");
>     } else {
>       event.set_value(value);
>     }
>     event.commit();
>
>     EventInitialSystemProperty event(UNTIMED);
>     event.set_key(p->key());
>     if (JfrScrub::is_sensitive_key(p->key()) {
>        event.set_value("[REDACTED]");
>     } else {
>        event.set_value(p->value());
>     }
>     event.set_starttime(time_stamp);
>     event.set_endtime(time_stamp);
>     event.commit();
>
>     EventSystemProcess event(UNTIMED);
>     event.set_pid(pid_buf);
>     event.set_commandLine(JfrScrub::command_line(info));
>     event.set_starttime(start_time);
>     event.set_endtime(end_time);
>     event.commit();
>
>     EventJVMInformation event;
>     event.set_jvmName(VM_Version::vm_name());
>     event.set_jvmVersion(VM_Version::internal_vm_info_string());
>
> event.set_javaArguments(JfrScrub::command_line(Arguments::java_command()));
>     event.set_jvmArguments(Arguments::jvm_args());
>     event.set_jvmFlags(Arguments::jvm_flags());
>     event.set_jvmStartTime(Management::vm_init_done_time());
>     event.set_pid(os::current_process_id());
>     event.commit();
>
> It's a bit ugly and not as flexible, but perhaps that's something we need
> to tolerate. Or will it be useless because new passwords/keys will be added
> all the time, or because they will match false positives, and more advanced
> logic is needed? Perhaps it will give users the false(?) impression that
> they don't need to worry about sensitive data?
>
> Thanks
> Erik
> ------------------------------
> *From:* Erwan Viollet <erwan.viollet at gmail.com>
> *Sent:* Thursday, June 12, 2025 5:07 PM
> *To:* Erik Gahlin <erik.gahlin at oracle.com>
> *Cc:* hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
> *Subject:* [External] : Re: JFR: Scrubbing sensitive information from
> events
>
> Hello,
>
> Here is an example of the types of events we are concerned about:
>
> Recording
> ?
> ??? Event (e.g. jdk.InitialSystemProperty)
> ?     ??? eventType: "jdk.InitialSystemProperty"
> ?     ??? startTime
> ?     ??? duration
> ?     ??? fields:
> ?     ?     ??? key: "javax.net.ssl.keyStorePassword"
> ?     ?     ??? value: "*supersecret*"
> ?     ?     ??? ...
> ?     ??? ...
> ?
> ??? Event (e.g. jdk.JVMInformation)
> ?     ??? eventType: "jdk.JVMInformation"
> ?     ??? jvmArguments: [ "-Xmx4G", "-Djavax.net.ssl.keyStorePassword=
> *supersecret*", ... ]
> ?     ??? ...
> ?
> ??? ...
>
> The rules are slightly challenging as they need to account for key/value
> pairs, arrays and simple fields (like commandLine field).
> Here
> <https://urldefense.com/v3/__https://gist.github.com/r1viollet/812ed70c6410c4f62640fd792570d36c__;!!ACWV5N9M2RV99hQ!LrFg9xF9Jy2l4LW6sj6mxVPhLXr30tA_2lzstCSiBbi4SxLyh8t2wDJGc4E1b7ePKrrsivDhkoZtMsHWCKsBeBLJ$>
> is a scrub file example. I'm happy to consider ways to simplify this
> proposal. Storing JFR files would also be helpful to consider test cases.
> Regards,
>
> Erwan
>
>
> Le mar. 3 juin 2025 ? 11:50, Erik Gahlin <erik.gahlin at oracle.com> a
> ?crit :
>
> We have discussed it, but we don't understand all the details. We are also
> unsure how to best expose it to the end user. Let's say there was a command
> line option -XX:FlightRecorder:scrub-file=<file>.
>
> What would you fill that file with? I want examples that work on real data
> to understand how expressive the filters must be.
>
> Thanks
> Erik
> ------------------------------
> *From:* hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of
> Erwan Viollet <erwan.viollet at gmail.com>
> *Sent:* Monday, June 2, 2025 3:30 PM
> *To:* hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
> *Subject:* JFR: Scrubbing sensitive information from events
>
> Hello,
>
> I am currently looking into how to remove sensitive information from JFR
> events. The main events that typically contain sensitive information:
> jdk.SystemProcess,  jdk.InitialSystemProperty, jdk.JVMInformation.
> Passwords from command lines can typically be found in these events.
>
> Dropping these events altogether is not ideal, as we need them to make
> relevant performance recommendations to users (e.g. suggesting JVM or
> system setting adjustments).
>
> Dropping them or scrubbing them on the backend side (after the fact)
> requires decompressing and re-writing these events, which is wasteful in
> terms of both compute and storage. The approach is not perfect, as we still
> end up intaking and temporarily storing sensitive information.
>
> Ideally, we would like to be able to scrub or redact only the sensitive
> fields within these events (for example, using a simple regex or
> pattern-based rule), rather than dropping the whole event. We also want to
> avoid handling this only after the event has already been written to the
> JFR file, as that does not fully mitigate the risk of exposing sensitive
> data.
>
> At present, it appears there is no public API or supported mechanism to
> intercept or scrub JFR events in-process, before they are persisted. What
> would you think of an API accepting custom scrubbing patterns so that
> sensitive data never leaves the JVM in an unredacted state?
>
> Are there any plans or discussions in this area? I am fairly new to the
> JFR world, so it is likely that I missed previous discussions around this.
>
> Thank you, Best regards,
>
> Erwan Viollet,
>
> Profiling team, Datadog
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250613/e67af53c/attachment-0001.htm>

From egahlin at openjdk.org  Sun Jun 15 16:37:24 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 15 Jun 2025 16:37:24 GMT
Subject: RFR: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording
Message-ID: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>

Could I have review of PR that excludes problematic String-related methods when tracing java.lang.String.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25814/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25814&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359593
  Stats: 100 lines in 2 files changed: 88 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25814/head:pull/25814

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

From egahlin at openjdk.org  Sun Jun 15 18:41:18 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 15 Jun 2025 18:41:18 GMT
Subject: RFR: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording [v2]
In-Reply-To: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
References: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
Message-ID: <9J11ddd9n87zzDpcKPEQIw00ne7a8SAPnz0Uv5S1ejw=.18f60b3b-7b48-4021-9d15-28fc1497c27e@github.com>

> Could I have review of PR that excludes problematic String-related methods when tracing java.lang.String.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Add missing copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25814/files
  - new: https://git.openjdk.org/jdk/pull/25814/files/7f00bba7..90ad9325

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

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

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

From duke at openjdk.org  Sun Jun 15 21:58:28 2025
From: duke at openjdk.org (ExE Boss)
Date: Sun, 15 Jun 2025 21:58:28 GMT
Subject: RFR: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording [v2]
In-Reply-To: <9J11ddd9n87zzDpcKPEQIw00ne7a8SAPnz0Uv5S1ejw=.18f60b3b-7b48-4021-9d15-28fc1497c27e@github.com>
References: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
 <9J11ddd9n87zzDpcKPEQIw00ne7a8SAPnz0Uv5S1ejw=.18f60b3b-7b48-4021-9d15-28fc1497c27e@github.com>
Message-ID: <DH0OYbZqyh-0jHlxF7uO1Z8fXkuBcd196i_xWvSkSbY=.4966bebc-edc2-4969-ba42-8b0fa85f22ec@github.com>

On Sun, 15 Jun 2025 18:41:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of PR that excludes problematic String-related methods when tracing java.lang.String.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing copyright header

src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/ExcludeList.java line 38:

> 36:         "jdk/internal/misc/Unsafe",
> 37:         "java/lang/StringLatin1",
> 38:         "java/lang/StringUTF16"

**Java** array?initialiser?expressions can?have trailing?commas:
Suggestion:

        "java/lang/StringUTF16",

(wish?the?same applied?to?method parameters)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25814#discussion_r2148837431

From egahlin at openjdk.org  Mon Jun 16 09:10:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Jun 2025 09:10:51 GMT
Subject: RFR: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording [v3]
In-Reply-To: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
References: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
Message-ID: <4VCHQlrVuo_c1onovruLFy1xnPnPD4N-8lhZcS8YjfE=.2ce5cd57-163c-40ab-a078-f04a906b27a9@github.com>

> Could I have review of PR that excludes problematic String-related methods when tracing java.lang.String.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Add comma

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25814/files
  - new: https://git.openjdk.org/jdk/pull/25814/files/90ad9325..9669ed4a

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

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

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

From egahlin at openjdk.org  Mon Jun 16 09:12:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Jun 2025 09:12:36 GMT
Subject: Integrated: 8359248: JFR: Help text
 for-XX:StartFlightRecording:report-on-exit should explain option can be
 repeated
In-Reply-To: <r7u_lxK6artjxrAA0gX7rKG4So_30YBmQENs6oQA59A=.ab4626c9-824b-41ed-b9d2-ea7b66e79945@github.com>
References: <r7u_lxK6artjxrAA0gX7rKG4So_30YBmQENs6oQA59A=.ab4626c9-824b-41ed-b9d2-ea7b66e79945@github.com>
Message-ID: <mD6vk-Jvniq0KbuQ5R-9XNzdhUx3QN3kVhTAp3ytK-I=.19b4a442-a353-40f2-bb1c-846afa65a7bc@github.com>

On Fri, 13 Jun 2025 11:01:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a PR that updates the help text for report-on-exit so it clarifies that the option can be repeated.
> 
> Testing: jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: fedd0a0e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fedd0a0ee3aea9f73cfce34172a764e63c1ba46b
Stats:     9 lines in 2 files changed: 3 ins; 0 del; 6 mod

8359248: JFR: Help text for-XX:StartFlightRecording:report-on-exit should explain option can be repeated

Reviewed-by: mgronlun

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

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

From syan at openjdk.org  Mon Jun 16 11:36:31 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 16 Jun 2025 11:36:31 GMT
Subject: RFR: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording [v3]
In-Reply-To: <4VCHQlrVuo_c1onovruLFy1xnPnPD4N-8lhZcS8YjfE=.2ce5cd57-163c-40ab-a078-f04a906b27a9@github.com>
References: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
 <4VCHQlrVuo_c1onovruLFy1xnPnPD4N-8lhZcS8YjfE=.2ce5cd57-163c-40ab-a078-f04a906b27a9@github.com>
Message-ID: <NWcFrRzHEoHZhILwjTIVaNZQ-70Ww_tMqVJgDae85KY=.64a4ee25-68fa-4428-8a82-ae646536c9a2@github.com>

On Mon, 16 Jun 2025 09:10:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of PR that excludes problematic String-related methods when tracing java.lang.String.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comma

test/jdk/jdk/jfr/event/tracing/TestTracedString.java line 39:

> 37:  * @requires vm.hasJFR
> 38:  * @library /test/lib
> 39:  * @run main/othervm jdk.jfr.event.tracing.TestTracedString

The `/othervm` could be removed or not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25814#discussion_r2149723823

From egahlin at openjdk.org  Mon Jun 16 11:43:28 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Jun 2025 11:43:28 GMT
Subject: RFR: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording [v3]
In-Reply-To: <NWcFrRzHEoHZhILwjTIVaNZQ-70Ww_tMqVJgDae85KY=.64a4ee25-68fa-4428-8a82-ae646536c9a2@github.com>
References: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
 <4VCHQlrVuo_c1onovruLFy1xnPnPD4N-8lhZcS8YjfE=.2ce5cd57-163c-40ab-a078-f04a906b27a9@github.com>
 <NWcFrRzHEoHZhILwjTIVaNZQ-70Ww_tMqVJgDae85KY=.64a4ee25-68fa-4428-8a82-ae646536c9a2@github.com>
Message-ID: <8dQcan3JAVHmh6qZSauSbP3RXEubm9Awp9sAj-dyHKw=.81dac1c8-9f77-40d4-b278-69d154636399@github.com>

On Mon, 16 Jun 2025 11:34:07 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comma
>
> test/jdk/jdk/jfr/event/tracing/TestTracedString.java line 39:
> 
>> 37:  * @requires vm.hasJFR
>> 38:  * @library /test/lib
>> 39:  * @run main/othervm jdk.jfr.event.tracing.TestTracedString
> 
> The `/othervm` could be removed or not?

It's by design. We don't want other tests to modify the state of the JVM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25814#discussion_r2149734149

From mbaesken at openjdk.org  Mon Jun 16 13:27:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Jun 2025 13:27:33 GMT
Subject: [jdk25] RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
In-Reply-To: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
References: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
Message-ID: <83PzVS_hd8BJX1Q1-k0h2uvkvTLdacvnGQJ7Dz5NOi8=.5cd425f5-811b-495d-9860-fdbddfdcf3ee@github.com>

On Thu, 12 Jun 2025 09:40:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Tested in SAP's testing queue.

We got also this error from the test  
java.lang.RuntimeException: Expected between 0 and 3 events, got 0: expected true, was false
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:545)
	at jdk.jfr.event.profiling.TestCPUTimeSampleThrottling.testThrottleSettings(TestCPUTimeSampleThrottling.java:58)
	at jdk.jfr.event.profiling.TestCPUTimeSampleThrottling.main(TestCPUTimeSampleThrottling.java:47)
	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:1474)

Should we fix this as well in this PR ?  Or is a separate one planned ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25776#issuecomment-2976653684

From mdoerr at openjdk.org  Mon Jun 16 13:56:27 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Jun 2025 13:56:27 GMT
Subject: [jdk25] RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
In-Reply-To: <83PzVS_hd8BJX1Q1-k0h2uvkvTLdacvnGQJ7Dz5NOi8=.5cd425f5-811b-495d-9860-fdbddfdcf3ee@github.com>
References: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
 <83PzVS_hd8BJX1Q1-k0h2uvkvTLdacvnGQJ7Dz5NOi8=.5cd425f5-811b-495d-9860-fdbddfdcf3ee@github.com>
Message-ID: <XttIJPLfRkwS1Us6wbzCNVEx9hPg_4GDe7VrByJIfxY=.97b59d5c-d737-4c7d-9aa0-534b73e52c68@github.com>

On Mon, 16 Jun 2025 13:25:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We got also this error from the test java.lang.RuntimeException: Expected between 0 and 3 events, got 0: expected true, was false at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertTrue(Asserts.java:545) at jdk.jfr.event.profiling.TestCPUTimeSampleThrottling.testThrottleSettings(TestCPUTimeSampleThrottling.java:58) at jdk.jfr.event.profiling.TestCPUTimeSampleThrottling.main(TestCPUTimeSampleThrottling.java:47) 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:1474)
> 
> Should we fix this as well in this PR ? Or is a separate one planned ?

This is the clean JDK25 backport. We'll need a new issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25776#issuecomment-2976757345

From mbaesken at openjdk.org  Mon Jun 16 14:07:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Jun 2025 14:07:29 GMT
Subject: [jdk25] RFR: 8359135: New test TestCPUTimeSampleThrottling fails
 intermittently
In-Reply-To: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
References: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
Message-ID: <IyiYynqX3zYNyzviIDDLDyCH-0TKrb_ijeHZRDvgpAA=.dec696ef-531a-4843-9bba-bd086315ed45@github.com>

On Thu, 12 Jun 2025 09:40:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Tested in SAP's testing queue.

I created the new issue JDK-8359690 .

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

PR Comment: https://git.openjdk.org/jdk/pull/25776#issuecomment-2976797163

From mgronlun at openjdk.org  Mon Jun 16 14:46:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 16 Jun 2025 14:46:28 GMT
Subject: RFR: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording [v3]
In-Reply-To: <4VCHQlrVuo_c1onovruLFy1xnPnPD4N-8lhZcS8YjfE=.2ce5cd57-163c-40ab-a078-f04a906b27a9@github.com>
References: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
 <4VCHQlrVuo_c1onovruLFy1xnPnPD4N-8lhZcS8YjfE=.2ce5cd57-163c-40ab-a078-f04a906b27a9@github.com>
Message-ID: <sWzfVhSaD43mWtmJD2px0jnZziMLSBEz-EhuNSkjEik=.ee28c6a9-77d2-4670-bf9d-8f53765f8add@github.com>

On Mon, 16 Jun 2025 09:10:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of PR that excludes problematic String-related methods when tracing java.lang.String.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comma

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25814#pullrequestreview-2932438185

From egahlin at openjdk.org  Mon Jun 16 16:13:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Jun 2025 16:13:36 GMT
Subject: Integrated: 8359593: JFR: Instrumentation of java.lang.String corrupts
 recording
In-Reply-To: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
References: <p-qBCQpoWSKwkpsrqDO4jgDdRlVqtUhgLZ4Wq8_qjjU=.27b22cf0-c0a8-4a15-b531-73202da1ed4c@github.com>
Message-ID: <jm3ZSS71tviqP5-PpHsDfZJWpEaYH-gINL6mTPe-aGA=.638727c3-ba6f-4cfe-8b6a-6a4c9f3c1c42@github.com>

On Sun, 15 Jun 2025 16:25:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that excludes problematic String-related methods when tracing java.lang.String.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 2f2acb2e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f2acb2e3f292517456f5b328a35182863188653
Stats:     122 lines in 2 files changed: 110 ins; 5 del; 7 mod

8359593: JFR: Instrumentation of java.lang.String corrupts recording

Reviewed-by: mgronlun

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

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

From jbechberger at openjdk.org  Mon Jun 16 16:23:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 16 Jun 2025 16:23:33 GMT
Subject: [jdk25] Integrated: 8359135: New test TestCPUTimeSampleThrottling
 fails intermittently
In-Reply-To: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
References: <MCLyHiRDZAclWYDRsz5CFOQ_D0nnMiFoDbXAVJkIL60=.bb1c8a6f-b72d-4b69-9371-7efe3c71f135@github.com>
Message-ID: <55rlWdyLxbmN9YVmSreYsaTWwu5YPBlp-sQGobsAwJ0=.8d7885ed-4cb0-46c9-b779-af5307d0a851@github.com>

On Thu, 12 Jun 2025 09:40:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Tested in SAP's testing queue.

This pull request has now been integrated.

Changeset: b6cacfcb
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6cacfcbc80fd6574b1040a3ec56639a1db47e46
Stats:     16 lines in 1 file changed: 8 ins; 2 del; 6 mod

8359135: New test TestCPUTimeSampleThrottling fails intermittently

Reviewed-by: mdoerr
Backport-of: 3f0fef2c9c323cb7b6e9191b17eac4296ff22dac

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

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

From egahlin at openjdk.org  Mon Jun 16 16:55:32 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Jun 2025 16:55:32 GMT
Subject: Integrated: 8359242: JFR: Missing help text for method trace and
 timing
In-Reply-To: <HcOoPbadxLEpydbOPll2C0pb7lTB5heRYuiEBrIAsJQ=.66972a51-ab69-4472-80d7-c10a05e72f6b@github.com>
References: <HcOoPbadxLEpydbOPll2C0pb7lTB5heRYuiEBrIAsJQ=.66972a51-ab69-4472-80d7-c10a05e72f6b@github.com>
Message-ID: <C4LEQPfNPTG31ChwxiNTq54hVVVhtQ0Pr3VwZHZxwAk=.ec868572-7ef3-4b3e-8e01-20bb08aa8308@github.com>

On Wed, 11 Jun 2025 15:12:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that adds missing help text for method trace and method timing? Without it, it's hard for users to understand how the feature can be used in JMC or with `jfr configure --interactive`.
> 
> Testing:  test/jdk/jdk/jfr  + tier1
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: e57a214e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e57a214e2a1059109dd028369d518298cfa5d5b4
Stats:     50 lines in 7 files changed: 35 ins; 4 del; 11 mod

8359242: JFR: Missing help text for method trace and timing

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Tue Jun 17 12:27:32 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 17 Jun 2025 12:27:32 GMT
Subject: RFR: 8346886: Add since checker test to jdk.management.jfr
In-Reply-To: <BnO4tQIO36TrJDW_nawg5Wg5elHmQXHjKSTaKVGmZXA=.faabca52-1afe-429e-81d3-6d0de33693bd@github.com>
References: <BnO4tQIO36TrJDW_nawg5Wg5elHmQXHjKSTaKVGmZXA=.faabca52-1afe-429e-81d3-6d0de33693bd@github.com>
Message-ID: <V6GERNG4cGwoheBnuOPDOGB7LXbLbNxcDN_eWEhW5G4=.dbe7b605-35b9-4ed8-97f4-dca4b6caf0b7@github.com>

On Tue, 3 Jun 2025 10:08:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to add a new test to check `@since` tags in the `jdk.management.jfr` module.
> 
> TIA

Looks reasonable.

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

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25612#pullrequestreview-2935443583

From naoto at openjdk.org  Tue Jun 17 20:37:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jun 2025 20:37:04 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
Message-ID: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>

Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

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

Commit messages:
 - Several more locations
 - initial commit

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

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

From vyazici at openjdk.org  Wed Jun 18 07:10:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 18 Jun 2025 07:10:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

I've verified that all relevant occurrences of `std{in,err,out}.encoding` are covered, except the ones `src/java.base/share/classes/java/lang/System.java`, which, I presume, is left out intentionally.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2937989243

From alanb at openjdk.org  Wed Jun 18 07:55:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:55:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.base/share/classes/module-info.java line 287:

> 285:         jdk.jpackage,
> 286:         jdk.jshell,
> 287:         jdk.net;

At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 111:

> 109: 
> 110: 
> 111:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jhsdb tool, just wondering why it needs to be changed.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 802:

> 800:         }
> 801:         try {
> 802:             Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the example jdb debugger, I assume okay to let it read the stdin.encoding property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153907749
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153910478
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153913162

From alanb at openjdk.org  Wed Jun 18 07:59:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:59:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <HS_moiW1ZXnwCePhJrtlJTtiwO37FEHMKxldVBPgDcw=.d649f3bf-3ce2-44d9-bc5c-9ed5f74b333d@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.scripting/share/classes/javax/script/SimpleScriptContext.java line 100:

> 98: 
> 99:     private static InputStreamReader stdinReader() {
> 100:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jrunscript command line tool. I suppose it's possible it could run a script that changes stdin.encoding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153921907

From jbachorik at openjdk.org  Wed Jun 18 11:50:29 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Wed, 18 Jun 2025 11:50:29 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler
In-Reply-To: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
Message-ID: <FyJHPbS2pqTPjeKp1yiIWVGOpRCljjfGoc9dMzhzY3E=.e675b788-80ce-4e4e-8fe4-7c8dfa9555a4@github.com>

On Thu, 12 Jun 2025 09:27:30 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the recomputation issue by passing either the rate or the period directly to the sampler (instead of just the rate value with the period value converted into a rate). This prevents issues when the number of cores changes during the JFR recording.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 171:

> 169:   double _rate;
> 170:   u8 _period_nanos;
> 171:   bool _is_rate;

Can this be turned into `union`? 
Only one of `_rate`  or `_period_nanos` will ever be set at a time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2154393526

From jbechberger at openjdk.org  Wed Jun 18 11:50:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 18 Jun 2025 11:50:30 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler
In-Reply-To: <FyJHPbS2pqTPjeKp1yiIWVGOpRCljjfGoc9dMzhzY3E=.e675b788-80ce-4e4e-8fe4-7c8dfa9555a4@github.com>
References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
 <FyJHPbS2pqTPjeKp1yiIWVGOpRCljjfGoc9dMzhzY3E=.e675b788-80ce-4e4e-8fe4-7c8dfa9555a4@github.com>
Message-ID: <uPfbHpXfR_SUUEvuTcl_Y0sN36diSvM7Kqwzmjd0D_o=.ef2a8274-bc33-41ac-85fe-dc4744526343@github.com>

On Wed, 18 Jun 2025 11:45:48 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Fixes the recomputation issue by passing either the rate or the period directly to the sampler (instead of just the rate value with the period value converted into a rate). This prevents issues when the number of cores changes during the JFR recording.
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 171:
> 
>> 169:   double _rate;
>> 170:   u8 _period_nanos;
>> 171:   bool _is_rate;
> 
> Can this be turned into `union`? 
> Only one of `_rate`  or `_period_nanos` will ever be set at a time.

good idea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2154397271

From jbachorik at openjdk.org  Wed Jun 18 11:54:28 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Wed, 18 Jun 2025 11:54:28 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler
In-Reply-To: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
Message-ID: <qBBm2UIiHWDWWdKbbE5IwydyVfyzRir5Lp-MwZG2K0E=.7ef4c690-5049-4d6c-b61d-a4f55fc707da@github.com>

On Thu, 12 Jun 2025 09:27:30 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the recomputation issue by passing either the rate or the period directly to the sampler (instead of just the rate value with the period value converted into a rate). This prevents issues when the number of cores changes during the JFR recording.

src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRateOrPeriod.java line 37:

> 35:     public static final TimespanRateOrPeriod OFF = new TimespanRateOrPeriod(0, 0, false);
> 36: 
> 37:     public static TimespanRateOrPeriod of(String text) {

Please add the doc about the allowed format for the `text` input

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2154403402

From egahlin at openjdk.org  Wed Jun 18 12:23:08 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 18 Jun 2025 12:23:08 GMT
Subject: RFR: 8359895: JFR: method-timing view doesn't work
Message-ID: <SabJIWXjFmHsz-M8ljks2gyFzIkztrAawKY_gg0r1c0=.4d12518c-692c-4ce1-b135-e24301331e07@github.com>

Could I have review of PR that fixes the method timing view.

Testing: jdk/jdk/jfr 

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Wed Jun 18 12:23:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 18 Jun 2025 12:23:08 GMT
Subject: RFR: 8359895: JFR: method-timing view doesn't work
In-Reply-To: <SabJIWXjFmHsz-M8ljks2gyFzIkztrAawKY_gg0r1c0=.4d12518c-692c-4ce1-b135-e24301331e07@github.com>
References: <SabJIWXjFmHsz-M8ljks2gyFzIkztrAawKY_gg0r1c0=.4d12518c-692c-4ce1-b135-e24301331e07@github.com>
Message-ID: <nUpPMItb4nn4SkL_RuAGOamO67zQV6KSi72CdvVYJPg=.e92b1242-f751-4996-a333-b674a0b1b747@github.com>

On Wed, 18 Jun 2025 12:11:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that fixes the method timing view.
> 
> Testing: jdk/jdk/jfr 
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25869#pullrequestreview-2938977502

From egahlin at openjdk.org  Wed Jun 18 14:46:33 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 18 Jun 2025 14:46:33 GMT
Subject: Integrated: 8359895: JFR: method-timing view doesn't work
In-Reply-To: <SabJIWXjFmHsz-M8ljks2gyFzIkztrAawKY_gg0r1c0=.4d12518c-692c-4ce1-b135-e24301331e07@github.com>
References: <SabJIWXjFmHsz-M8ljks2gyFzIkztrAawKY_gg0r1c0=.4d12518c-692c-4ce1-b135-e24301331e07@github.com>
Message-ID: <6fzzSsc1Uer_tVyG8Ayv8FSv_-s9_qvPF5HXlpaiC_s=.26febdaf-f475-47d2-b905-38220ba5f334@github.com>

On Wed, 18 Jun 2025 12:11:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that fixes the method timing view.
> 
> Testing: jdk/jdk/jfr 
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 984d7f9c
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/984d7f9cdfb0d75ea906ce32df0b6c447f4d5954
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8359895: JFR: method-timing view doesn't work

Reviewed-by: mgronlun

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

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

From rriggs at openjdk.org  Wed Jun 18 15:08:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <LbRBF6gknL_SsjFh_wALuLuFGTOFzDNYTUikL7MbvA8=.f0b9e433-da69-4280-9a3d-9150dfaa1b80@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Static properties should not be used outside of java.base.
The "for internal use only" should have said "java.base internal use only"
Adding a comment to that effect would be a good idea.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2939624079

From rriggs at openjdk.org  Wed Jun 18 15:08:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:30 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
Message-ID: <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>

On Wed, 18 Jun 2025 07:50:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> src/java.base/share/classes/module-info.java line 287:
> 
>> 285:         jdk.jpackage,
>> 286:         jdk.jshell,
>> 287:         jdk.net;
> 
> At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

The original intent of StaticProperties was to limit it to the base module.
Other modules are free to read the property themselves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2154852609

From egahlin at openjdk.org  Wed Jun 18 20:50:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 18 Jun 2025 20:50:04 GMT
Subject: [jdk25] RFR: 8359248: JFR: Help text
 for-XX:StartFlightRecording:report-on-exit should explain option can be
 repeated
Message-ID: <MqFyNtQm-idzfi83EpWQp_asTySH8620luJR4-0TqNo=.1693f1d8-1e26-45cb-9129-12ae8420d9ea@github.com>

8359248: JFR: Help text for-XX:StartFlightRecording:report-on-exit should explain option can be repeated

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

Commit messages:
 - Backport fedd0a0ee3aea9f73cfce34172a764e63c1ba46b

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

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

From egahlin at openjdk.org  Wed Jun 18 21:39:09 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 18 Jun 2025 21:39:09 GMT
Subject: [jdk25] RFR: 8359593: JFR: Instrumentation of java.lang.String
 corrupts recording
Message-ID: <WJ1pn6pQFOO4BLidROo05LsBAKGjqXAG2_bXampylgI=.bbfbbd3c-b759-49df-8957-f6fc5a99628f@github.com>

8359593: JFR: Instrumentation of java.lang.String corrupts recording

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

Commit messages:
 - Backport 2f2acb2e3f292517456f5b328a35182863188653

Changes: https://git.openjdk.org/jdk/pull/25886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359593
  Stats: 122 lines in 2 files changed: 110 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25886/head:pull/25886

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

From mgronlun at openjdk.org  Thu Jun 19 09:54:35 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 19 Jun 2025 09:54:35 GMT
Subject: [jdk25] RFR: 8359593: JFR: Instrumentation of java.lang.String
 corrupts recording
In-Reply-To: <WJ1pn6pQFOO4BLidROo05LsBAKGjqXAG2_bXampylgI=.bbfbbd3c-b759-49df-8957-f6fc5a99628f@github.com>
References: <WJ1pn6pQFOO4BLidROo05LsBAKGjqXAG2_bXampylgI=.bbfbbd3c-b759-49df-8957-f6fc5a99628f@github.com>
Message-ID: <tN3mUBMqrr_8hec2yHo11L5FaKn54zAoalmdFTpjBE4=.da1009ef-d23e-43c7-9ca1-525404d9372e@github.com>

On Wed, 18 Jun 2025 21:17:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8359593: JFR: Instrumentation of java.lang.String corrupts recording

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25886#pullrequestreview-2942338168

From mgronlun at openjdk.org  Thu Jun 19 09:54:49 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 19 Jun 2025 09:54:49 GMT
Subject: [jdk25] RFR: 8359248: JFR: Help text
 for-XX:StartFlightRecording:report-on-exit should explain option can be
 repeated
In-Reply-To: <MqFyNtQm-idzfi83EpWQp_asTySH8620luJR4-0TqNo=.1693f1d8-1e26-45cb-9129-12ae8420d9ea@github.com>
References: <MqFyNtQm-idzfi83EpWQp_asTySH8620luJR4-0TqNo=.1693f1d8-1e26-45cb-9129-12ae8420d9ea@github.com>
Message-ID: <hC-Pu7J6ZSBbcK8EDPw2bm9IqGoKT0WPCmVzdmmlch8=.41dc85e4-38ad-4001-aaec-1cdbf868ac96@github.com>

On Wed, 18 Jun 2025 20:27:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8359248: JFR: Help text for-XX:StartFlightRecording:report-on-exit should explain option can be repeated

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25885#pullrequestreview-2942337584

From egahlin at openjdk.org  Thu Jun 19 12:59:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 19 Jun 2025 12:59:51 GMT
Subject: [jdk25] Integrated: 8359248: JFR: Help text
 for-XX:StartFlightRecording:report-on-exit should explain option can be
 repeated
In-Reply-To: <MqFyNtQm-idzfi83EpWQp_asTySH8620luJR4-0TqNo=.1693f1d8-1e26-45cb-9129-12ae8420d9ea@github.com>
References: <MqFyNtQm-idzfi83EpWQp_asTySH8620luJR4-0TqNo=.1693f1d8-1e26-45cb-9129-12ae8420d9ea@github.com>
Message-ID: <XQKVWn9NHlBxvh016yD0RDe5a31BGi8ZukK_511_i_s=.bfc7b269-f9ad-4dda-b085-7ac8e3ed3818@github.com>

On Wed, 18 Jun 2025 20:27:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8359248: JFR: Help text for-XX:StartFlightRecording:report-on-exit should explain option can be repeated

This pull request has now been integrated.

Changeset: b79ca5f0
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b79ca5f03b5c827212f854d39a26a6f6b7579589
Stats:     9 lines in 2 files changed: 3 ins; 0 del; 6 mod

8359248: JFR: Help text for-XX:StartFlightRecording:report-on-exit should explain option can be repeated

Reviewed-by: mgronlun
Backport-of: fedd0a0ee3aea9f73cfce34172a764e63c1ba46b

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

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

From egahlin at openjdk.org  Thu Jun 19 14:26:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 19 Jun 2025 14:26:51 GMT
Subject: [jdk25] Integrated: 8359593: JFR: Instrumentation of java.lang.String
 corrupts recording
In-Reply-To: <WJ1pn6pQFOO4BLidROo05LsBAKGjqXAG2_bXampylgI=.bbfbbd3c-b759-49df-8957-f6fc5a99628f@github.com>
References: <WJ1pn6pQFOO4BLidROo05LsBAKGjqXAG2_bXampylgI=.bbfbbd3c-b759-49df-8957-f6fc5a99628f@github.com>
Message-ID: <DAtUn3KvNNOScXnqY_qvRdvLrPp6g9tE2hTdrhRdPc4=.18641085-bc55-411c-ad6d-a2ab8c07dfcc@github.com>

On Wed, 18 Jun 2025 21:17:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8359593: JFR: Instrumentation of java.lang.String corrupts recording

This pull request has now been integrated.

Changeset: c832f001
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c832f001e47c0eb64948e90291991e678f6b2619
Stats:     122 lines in 2 files changed: 110 ins; 5 del; 7 mod

8359593: JFR: Instrumentation of java.lang.String corrupts recording

Reviewed-by: mgronlun
Backport-of: 2f2acb2e3f292517456f5b328a35182863188653

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

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

From egahlin at openjdk.org  Thu Jun 19 15:04:08 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 19 Jun 2025 15:04:08 GMT
Subject: [jdk25] RFR: 8359242: JFR: Missing help text for method trace and
 timing
Message-ID: <46Bx5apRRtfaMPLPUC4GYrx-ptArCi63I1AHfYZnCgw=.ec42f056-9570-4171-97f3-57108afa8694@github.com>

8359242: JFR: Missing help text for method trace and timing

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

Commit messages:
 - Backport e57a214e2a1059109dd028369d518298cfa5d5b4

Changes: https://git.openjdk.org/jdk/pull/25899/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25899&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359242
  Stats: 50 lines in 7 files changed: 35 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25899/head:pull/25899

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

From egahlin at openjdk.org  Thu Jun 19 15:19:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 19 Jun 2025 15:19:45 GMT
Subject: [jdk25] RFR: 8359895: JFR: method-timing view doesn't work
Message-ID: <-wCIbDMiqJuDZvXgZlMnhPYPNiONxYW9P0TvtYOAuMM=.6b53c34e-65fc-4a67-935d-70ae2473c2dd@github.com>

8359895: JFR: method-timing view doesn't work

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

Commit messages:
 - Backport 984d7f9cdfb0d75ea906ce32df0b6c447f4d5954

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

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

From egahlin at openjdk.org  Thu Jun 19 15:39:06 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 19 Jun 2025 15:39:06 GMT
Subject: RFR: 8360039: JFR: Improve parser logging of constants
Message-ID: <7KEf12IUWBnN6BHHiKTT0mh7e0sPhHqzu8PPH4CUmgA=.c1d47d86-d046-4b16-a778-6dcb216d7016@github.com>

Could I have a review of the PR that improves logging in the JFR parser for arrays?

Testing: test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Thu Jun 19 16:44:26 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 19 Jun 2025 16:44:26 GMT
Subject: [jdk25] RFR: 8359895: JFR: method-timing view doesn't work
In-Reply-To: <-wCIbDMiqJuDZvXgZlMnhPYPNiONxYW9P0TvtYOAuMM=.6b53c34e-65fc-4a67-935d-70ae2473c2dd@github.com>
References: <-wCIbDMiqJuDZvXgZlMnhPYPNiONxYW9P0TvtYOAuMM=.6b53c34e-65fc-4a67-935d-70ae2473c2dd@github.com>
Message-ID: <tFJo6UfRaTzYvKD5Y5LGyjS5eXT_QSwiqivIbOnXxLA=.59c19514-6fbc-4a8d-8c6a-4c6bc253e31d@github.com>

On Thu, 19 Jun 2025 15:02:32 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8359895: JFR: method-timing view doesn't work

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25901#pullrequestreview-2943630260

From mgronlun at openjdk.org  Thu Jun 19 16:45:33 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 19 Jun 2025 16:45:33 GMT
Subject: [jdk25] RFR: 8359242: JFR: Missing help text for method trace and
 timing
In-Reply-To: <46Bx5apRRtfaMPLPUC4GYrx-ptArCi63I1AHfYZnCgw=.ec42f056-9570-4171-97f3-57108afa8694@github.com>
References: <46Bx5apRRtfaMPLPUC4GYrx-ptArCi63I1AHfYZnCgw=.ec42f056-9570-4171-97f3-57108afa8694@github.com>
Message-ID: <Jo7QkXyThjV0MlG38Z5aMs_B9pBKDq11PUDiSIhAVJ4=.d5e61ee3-84ab-47a8-b66e-a0ac967025ce@github.com>

On Thu, 19 Jun 2025 14:38:12 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8359242: JFR: Missing help text for method trace and timing

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25899#pullrequestreview-2943631380