From egahlin at openjdk.org  Tue Jul  1 08:00:40 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 1 Jul 2025 08:00:40 GMT
Subject: [jdk25] RFR: 8360287: JFR: PlatformTracer class should be loaded
 lazily
In-Reply-To: <gVWJZraxp_hfcSvKwSJ-JRHzIIAIvLaQTRfI4wMLdME=.bd68822c-9de8-4511-9a32-7b585ebb5720@github.com>
References: <EldsjeySTcU1PxFd3dfRb9DSzOCebf-Gxs8V7E6TwOg=.77577930-c9a9-4130-a2ed-4999ab868860@github.com>
 <gVWJZraxp_hfcSvKwSJ-JRHzIIAIvLaQTRfI4wMLdME=.bd68822c-9de8-4511-9a32-7b585ebb5720@github.com>
Message-ID: <7ZEZWQFZX09QtIWpSkWTXjDUWejKSKFgyD8VNenf5_0=.cfca9a39-2276-44f8-8799-fe94316d0031@github.com>

On Mon, 30 Jun 2025 19:45:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> 8360287: JFR: PlatformTracer class should be loaded lazily
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/MethodSetting.java line 45:
> 
>> 43: public final class MethodSetting extends FilterSetting {
>> 44:     private final Modification modification;
>> 45:     private volatile static boolean initialized;
> 
> Let's use blessed modifiers order
> Suggestion:
> 
>     private static volatile boolean initialized;

I'd prefer to keep this backport as is. If you believe the change is necessary, please file a separate bug and backport it. In general, it's helpful to suggest small changes early on to avoid re-reviews and unclean backports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26040#discussion_r2176730411

From egahlin at openjdk.org  Tue Jul  1 08:12:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 1 Jul 2025 08:12:54 GMT
Subject: RFR: 8358750: JFR: EventInstrumentation MASK_THROTTLE* constants
 should be computed in longs [v2]
In-Reply-To: <NgfEE6RgyadzXbGWlcJ-SrfG9wUo8UDWrOS5bqdbVxs=.620a63ed-da53-420a-812b-50591bafed42@github.com>
References: <NgfEE6RgyadzXbGWlcJ-SrfG9wUo8UDWrOS5bqdbVxs=.620a63ed-da53-420a-812b-50591bafed42@github.com>
Message-ID: <KOh6WhCemFETW8ONBu1ao6gwczlfVYflkO8XxIBTUJo=.da1841da-b220-47db-b2c5-00296013f340@github.com>

> Could I have a review of a fix to the throttling mechanism added in JDK 25? Long values should be shifted instead of integer values when creating the masks.
> 
> During debugging, I found several issues, and I also strengthened the test.
> 
> - The start time of the event needs to be stored if the event is being throttled. The reason is that the timestamp is reused later to determine if the event should be throttled or not. This happens with events that lack an end time.
> 
> - The duration value that is written to the buffer must remove the mask if it is throttled. This is handled by`getDuration(blockCodeBuilder)`.
> 
> - I added a clarifying comment that when duration is compared to 0, it also prevents a new duration from being calculated if the event has been throttled (for an instant event).
> 
> The test now checks that the duration is not negative, that the start time is not before the test starts, and that the duration is not unreasonably large. The reason I multiply the recording duration by two is to give the test some slack in case we run into clock issues where the time taken for the event doesn't match the recording. Purpose of the check is to make sure we don't end up with the mask being added to the duration.
> 
> Testing:  
> test/jdk/jdk/jfr + tier1
> 
> I validated manually that the throttle rate works using a small test program I have (which can't be checked in due to stability issues).

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

  Remove whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26028/files
  - new: https://git.openjdk.org/jdk/pull/26028/files/214c9397..9d397d90

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

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

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

From apangin at openjdk.org  Tue Jul  1 19:49:39 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Tue, 1 Jul 2025 19:49:39 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: <lz551oJhsVzqIK2es-6-h2nfXPmCjDtGwxU0g3jCH5c=.11265fdc-19ca-44a2-86ba-9f10e61f3a91@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/PlatformEventType.java line 205:

> 203:     public void setCPUThrottle(TimespanRateOrPeriod rate) {
> 204:         if (isCPUTimeMethodSampling) {
> 205:             System.out.println("Setting CPU throttle for " + getName() + " to " + rate);

Please remove debug printout here and in other places.

src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRateOrPeriod.java line 59:

> 57:     }
> 58: 
> 59:     public static TimespanRateOrPeriod max(TimespanRateOrPeriod a, TimespanRateOrPeriod b) {

`max` is not the best name for it, since it can be `min` for period or `max` for rate.
The idea of the method is to select a value with the highest resolution, right? Let's reflect this in the name and/or code comment.

src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRateOrPeriod.java line 67:

> 65:         }
> 66:         if (a.isRate) {
> 67:             double bRate = Runtime.getRuntime().availableProcessors() / b.periodNanos() * 1_000_000_000.0;

Integer division will round it to zero. Correct expression would be
`Runtime.getRuntime().availableProcessors() * (1_000_000_000.0 / b.periodNanos())`

src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRateOrPeriod.java line 70:

> 68:             return new TimespanRateOrPeriod(Math.max(a.rate(), bRate), 0, true);
> 69:         }
> 70:         return max(b, a); // swap to use the same logic

Please don't use recursion for trivial cases.

src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRateOrPeriod.java line 95:

> 93:         }
> 94:         // fallback to days if no smaller unit is found
> 95:         return String.format("%d/%s", (long)(rate / TimespanUnit.DAYS.nanos * 1_000_000_000.0), TimespanUnit.DAYS.text);

Do we really need this complication? Where is this `toString()` used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2178359999
PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2178405607
PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2178374195
PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2178375571
PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2178399206

From egahlin at openjdk.org  Tue Jul  1 22:10:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 1 Jul 2025 22:10:41 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: <m4PsgnYRSWfmp2eAbL0zLIsCXNNihhkwjJRRlm7ml2A=.1429d5ec-2c71-47c5-8942-7ef2b2220ff7@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.

Why was the class renamed to TimespanRateOrPeriod?

I believe the name TimespanRate was chosen to indicate that it could represent both a timespan (e.g., 20 ms) and a rate (e.g., 1000/s). If you think period is more appropriate than timespan, how about RatePeriod?

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

PR Comment: https://git.openjdk.org/jdk/pull/25775#issuecomment-3025671727

From mgronlun at openjdk.org  Thu Jul  3 12:37:43 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 3 Jul 2025 12:37:43 GMT
Subject: RFR: 8358750: JFR: EventInstrumentation MASK_THROTTLE* constants
 should be computed in longs [v2]
In-Reply-To: <KOh6WhCemFETW8ONBu1ao6gwczlfVYflkO8XxIBTUJo=.da1841da-b220-47db-b2c5-00296013f340@github.com>
References: <NgfEE6RgyadzXbGWlcJ-SrfG9wUo8UDWrOS5bqdbVxs=.620a63ed-da53-420a-812b-50591bafed42@github.com>
 <KOh6WhCemFETW8ONBu1ao6gwczlfVYflkO8XxIBTUJo=.da1841da-b220-47db-b2c5-00296013f340@github.com>
Message-ID: <4YCJQTxWP6RQo1H-tGajmLUouQaWM1OGOzwMIQj5GUc=.bd6579b3-5c25-489d-af6e-bb54f47bc3f4@github.com>

On Tue, 1 Jul 2025 08:12:54 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a fix to the throttling mechanism added in JDK 25? Long values should be shifted instead of integer values when creating the masks.
>> 
>> During debugging, I found several issues, and I also strengthened the test.
>> 
>> - The start time of the event needs to be stored if the event is being throttled. The reason is that the timestamp is reused later to determine if the event should be throttled or not. This happens with events that lack an end time.
>> 
>> - The duration value that is written to the buffer must remove the mask if it is throttled. This is handled by`getDuration(blockCodeBuilder)`.
>> 
>> - I added a clarifying comment that when duration is compared to 0, it also prevents a new duration from being calculated if the event has been throttled (for an instant event).
>> 
>> The test now checks that the duration is not negative, that the start time is not before the test starts, and that the duration is not unreasonably large. The reason I multiply the recording duration by two is to give the test some slack in case we run into clock issues where the time taken for the event doesn't match the recording. Purpose of the check is to make sure we don't end up with the mask being added to the duration.
>> 
>> Testing:  
>> test/jdk/jdk/jfr + tier1
>> 
>> I validated manually that the throttle rate works using a small test program I have (which can't be checked in due to stability issues).
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26028#pullrequestreview-2982995446

From mgronlun at openjdk.org  Thu Jul  3 12:40:39 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 3 Jul 2025 12:40:39 GMT
Subject: [jdk25] RFR: 8360287: JFR: PlatformTracer class should be loaded
 lazily
In-Reply-To: <EldsjeySTcU1PxFd3dfRb9DSzOCebf-Gxs8V7E6TwOg=.77577930-c9a9-4130-a2ed-4999ab868860@github.com>
References: <EldsjeySTcU1PxFd3dfRb9DSzOCebf-Gxs8V7E6TwOg=.77577930-c9a9-4130-a2ed-4999ab868860@github.com>
Message-ID: <1M5_9sHHd8SNfuxtO8JWmB8Z9jpttGH_o74Md1ql3Rw=.02b09e00-6886-419d-a403-08faa12104f1@github.com>

On Mon, 30 Jun 2025 09:30:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8360287: JFR: PlatformTracer class should be loaded lazily

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26040#pullrequestreview-2983003952

From egahlin at openjdk.org  Thu Jul  3 18:37:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 3 Jul 2025 18:37:46 GMT
Subject: [jdk25] Integrated: 8360287: JFR: PlatformTracer class should be
 loaded lazily
In-Reply-To: <EldsjeySTcU1PxFd3dfRb9DSzOCebf-Gxs8V7E6TwOg=.77577930-c9a9-4130-a2ed-4999ab868860@github.com>
References: <EldsjeySTcU1PxFd3dfRb9DSzOCebf-Gxs8V7E6TwOg=.77577930-c9a9-4130-a2ed-4999ab868860@github.com>
Message-ID: <0EXLpOD70EMbBGAmtkJQPodB4hbx8xjXCXJOujk_97M=.6006f041-e1d3-404f-a7a8-b7ccf29d4c73@github.com>

On Mon, 30 Jun 2025 09:30:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8360287: JFR: PlatformTracer class should be loaded lazily

This pull request has now been integrated.

Changeset: e3bd9c6e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3bd9c6e1c78aac4de5907a3cb3358ec5862373b
Stats:     75 lines in 4 files changed: 62 ins; 11 del; 2 mod

8360287: JFR: PlatformTracer class should be loaded lazily

Reviewed-by: mgronlun
Backport-of: 8ea544c33fc502208577249fb83544f8d876bc17

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

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

From egahlin at openjdk.org  Thu Jul  3 20:04:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 3 Jul 2025 20:04:44 GMT
Subject: Integrated: 8358750: JFR: EventInstrumentation MASK_THROTTLE*
 constants should be computed in longs
In-Reply-To: <NgfEE6RgyadzXbGWlcJ-SrfG9wUo8UDWrOS5bqdbVxs=.620a63ed-da53-420a-812b-50591bafed42@github.com>
References: <NgfEE6RgyadzXbGWlcJ-SrfG9wUo8UDWrOS5bqdbVxs=.620a63ed-da53-420a-812b-50591bafed42@github.com>
Message-ID: <_5_o3I54LmmcRzk9wJU-IO0QKFCZFq7GIpIKJdh7bxI=.552b8524-ff24-4612-b1d0-92bb2a2baf57@github.com>

On Fri, 27 Jun 2025 20:49:37 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a fix to the throttling mechanism added in JDK 25? Long values should be shifted instead of integer values when creating the masks.
> 
> During debugging, I found several issues, and I also strengthened the test.
> 
> - The start time of the event needs to be stored if the event is being throttled. The reason is that the timestamp is reused later to determine if the event should be throttled or not. This happens with events that lack an end time.
> 
> - The duration value that is written to the buffer must remove the mask if it is throttled. This is handled by`getDuration(blockCodeBuilder)`.
> 
> - I added a clarifying comment that when duration is compared to 0, it also prevents a new duration from being calculated if the event has been throttled (for an instant event).
> 
> The test now checks that the duration is not negative, that the start time is not before the test starts, and that the duration is not unreasonably large. The reason I multiply the recording duration by two is to give the test some slack in case we run into clock issues where the time taken for the event doesn't match the recording. Purpose of the check is to make sure we don't end up with the mask being added to the duration.
> 
> Testing:  
> test/jdk/jdk/jfr + tier1
> 
> I validated manually that the throttle rate works using a small test program I have (which can't be checked in due to stability issues).

This pull request has now been integrated.

Changeset: 77e69e02
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77e69e02ebd280636859dd698423db6ac3bc7f5c
Stats:     78 lines in 2 files changed: 48 ins; 22 del; 8 mod

8358750: JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Fri Jul  4 09:32:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 4 Jul 2025 09:32:13 GMT
Subject: [jdk25] RFR: 8358750: JFR: EventInstrumentation MASK_THROTTLE*
 constants should be computed in longs
Message-ID: <lJSpSuX4Bk6GV4xSKfHd4xvxSPKa4jhUjnmkWW912EY=.c5202816-701f-4494-9817-8d67bae12032@github.com>

8358750: JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs

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

Commit messages:
 - Backport 77e69e02ebd280636859dd698423db6ac3bc7f5c

Changes: https://git.openjdk.org/jdk/pull/26126/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358750
  Stats: 78 lines in 2 files changed: 48 ins; 22 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26126/head:pull/26126

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

From mgronlun at openjdk.org  Fri Jul  4 09:37:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 4 Jul 2025 09:37:40 GMT
Subject: [jdk25] RFR: 8358750: JFR: EventInstrumentation MASK_THROTTLE*
 constants should be computed in longs
In-Reply-To: <lJSpSuX4Bk6GV4xSKfHd4xvxSPKa4jhUjnmkWW912EY=.c5202816-701f-4494-9817-8d67bae12032@github.com>
References: <lJSpSuX4Bk6GV4xSKfHd4xvxSPKa4jhUjnmkWW912EY=.c5202816-701f-4494-9817-8d67bae12032@github.com>
Message-ID: <MtfbHH-S9ddb5DxtAstt7s5QFFBaueIaTqLDL-ZZDR0=.b9dddd99-7de8-4e2d-85d8-3057901c7785@github.com>

On Fri, 4 Jul 2025 06:22:00 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8358750: JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26126#pullrequestreview-2986315059

From egahlin at openjdk.org  Fri Jul  4 10:56:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 4 Jul 2025 10:56:21 GMT
Subject: RFR: 8361338: JFR: Min and max time in MethodTime event is confusing
Message-ID: <FN94v48RBoF3QMJEjAMHXq8wNPGFN6AuX1L03_c9cm0=.59678daa-3a21-4882-a0fc-b7257ffb35d7@github.com>

Could I have a review of change that make the method timing event less confusing.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From egahlin at openjdk.org  Fri Jul  4 11:35:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 4 Jul 2025 11:35:54 GMT
Subject: RFR: 8361338: JFR: Min and max time in MethodTime event is
 confusing [v2]
In-Reply-To: <FN94v48RBoF3QMJEjAMHXq8wNPGFN6AuX1L03_c9cm0=.59678daa-3a21-4882-a0fc-b7257ffb35d7@github.com>
References: <FN94v48RBoF3QMJEjAMHXq8wNPGFN6AuX1L03_c9cm0=.59678daa-3a21-4882-a0fc-b7257ffb35d7@github.com>
Message-ID: <y0VfMGAz1JnIeoV6cfBxC04OxrcuMueuMcSI9vGsi7c=.4fc40a48-d165-4c4a-81f8-5e728674b162@github.com>

> Could I have a review of change that make the method timing event less confusing.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Fix bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26112/files
  - new: https://git.openjdk.org/jdk/pull/26112/files/4473ae98..c37f94e6

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

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

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

From egahlin at openjdk.org  Fri Jul  4 15:10:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 4 Jul 2025 15:10:46 GMT
Subject: [jdk25] Integrated: 8358750: JFR: EventInstrumentation MASK_THROTTLE*
 constants should be computed in longs
In-Reply-To: <lJSpSuX4Bk6GV4xSKfHd4xvxSPKa4jhUjnmkWW912EY=.c5202816-701f-4494-9817-8d67bae12032@github.com>
References: <lJSpSuX4Bk6GV4xSKfHd4xvxSPKa4jhUjnmkWW912EY=.c5202816-701f-4494-9817-8d67bae12032@github.com>
Message-ID: <ZtLBTJkH-JAogTWM985gq4LpovQHHO3fNX7h8KJoG6o=.e756179e-3ce7-4561-84f6-d2f7ec5f38c1@github.com>

On Fri, 4 Jul 2025 06:22:00 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8358750: JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs

This pull request has now been integrated.

Changeset: 8707167e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8707167ef3bb7015d87599387fbbcf17ddf0f291
Stats:     78 lines in 2 files changed: 48 ins; 22 del; 8 mod

8358750: JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs

Reviewed-by: mgronlun
Backport-of: 77e69e02ebd280636859dd698423db6ac3bc7f5c

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

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

From mgronlun at openjdk.org  Fri Jul  4 16:56:39 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 4 Jul 2025 16:56:39 GMT
Subject: RFR: 8361338: JFR: Min and max time in MethodTime event is
 confusing [v2]
In-Reply-To: <y0VfMGAz1JnIeoV6cfBxC04OxrcuMueuMcSI9vGsi7c=.4fc40a48-d165-4c4a-81f8-5e728674b162@github.com>
References: <FN94v48RBoF3QMJEjAMHXq8wNPGFN6AuX1L03_c9cm0=.59678daa-3a21-4882-a0fc-b7257ffb35d7@github.com>
 <y0VfMGAz1JnIeoV6cfBxC04OxrcuMueuMcSI9vGsi7c=.4fc40a48-d165-4c4a-81f8-5e728674b162@github.com>
Message-ID: <g5IotjGHjPjsXig5GuU3SCGiHdQJOXb4f2GMKcz42lk=.b7e1a6d3-3912-4ffb-8ee3-689af25290ec@github.com>

On Fri, 4 Jul 2025 11:35:54 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of change that make the method timing event less confusing.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26112#pullrequestreview-2987873710

From egahlin at openjdk.org  Fri Jul  4 18:56:19 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 4 Jul 2025 18:56:19 GMT
Subject: RFR: 8361175: JFR: Document differences between method sample events
Message-ID: <c1KKU8nJmTE77J5XMx6Gkt0W3WQ-zpureqdmKee72Zs=.0b17f28a-cfe1-434a-bd84-d02d1ef79246@github.com>

Could I have a review that clarifies how the method sample events work?

- Added descriptions to NativeMethodSample, ExecutionSample and CPUTimeSample to clarify what they sample and what they don't sample.
- Removed the word "Method" from the labels of the CPUTimeSample and "ExecutionSample events for consistency and to avoid overly verbose event labels.
- Added the word "setting" so that the description of CPUTimeSample reads "throttle setting" instead of just "throttle".
- Changed the label for the CPUTimeSamplesLost event to "CPU Time Samples Lost", making it easier to associate with "CPU Time Sample" event. 
- Removed the percentage column from the "native-methods" view, as normalization doesn't make sense when mixing executing and waiting samples.


Testing: tets/jdk/jdk/jfr + tier1

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/26132/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361175
  Stats: 11 lines in 2 files changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26132/head:pull/26132

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

From egahlin at openjdk.org  Sun Jul  6 15:24:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 6 Jul 2025 15:24:49 GMT
Subject: Integrated: 8361338: JFR: Min and max time in MethodTime event is
 confusing
In-Reply-To: <FN94v48RBoF3QMJEjAMHXq8wNPGFN6AuX1L03_c9cm0=.59678daa-3a21-4882-a0fc-b7257ffb35d7@github.com>
References: <FN94v48RBoF3QMJEjAMHXq8wNPGFN6AuX1L03_c9cm0=.59678daa-3a21-4882-a0fc-b7257ffb35d7@github.com>
Message-ID: <ywF3XryqjBBp-lAYA6GCHivs8R-YoU_DccYAxW_uu2U=.e9c02100-6fe8-4388-8604-f729b03f5f7e@github.com>

On Thu, 3 Jul 2025 08:17:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of change that make the method timing event less confusing.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: f3e0588d
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3e0588d0b825a68a4ad61ddf806877f46da69dc
Stats:     30 lines in 4 files changed: 23 ins; 4 del; 3 mod

8361338: JFR: Min and max time in MethodTime event is confusing

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Sun Jul  6 19:27:22 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 6 Jul 2025 19:27:22 GMT
Subject: [jdk25] RFR: 8361338: JFR: Min and max time in MethodTime event is
 confusing
Message-ID: <G7vdPIIhSJjNO-DHORXq72UI_MnpXln3UI8ntOqQRos=.fb81dd7c-debe-4e92-8568-f0c9bd61d106@github.com>

8361338: JFR: Min and max time in MethodTime event is confusing

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

Commit messages:
 - Backport f3e0588d0b825a68a4ad61ddf806877f46da69dc

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

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

From shade at openjdk.org  Mon Jul  7 08:14:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Jul 2025 08:14:38 GMT
Subject: [jdk25] RFR: 8361338: JFR: Min and max time in MethodTime event is
 confusing
In-Reply-To: <G7vdPIIhSJjNO-DHORXq72UI_MnpXln3UI8ntOqQRos=.fb81dd7c-debe-4e92-8568-f0c9bd61d106@github.com>
References: <G7vdPIIhSJjNO-DHORXq72UI_MnpXln3UI8ntOqQRos=.fb81dd7c-debe-4e92-8568-f0c9bd61d106@github.com>
Message-ID: <I6rdTtOd3CZqS5ijmmWzx9vS4HOsPAn05l3iYQm4_Tk=.7ebfcd11-7bcb-4948-a5a0-36f59f5e6950@github.com>

On Sun, 6 Jul 2025 19:17:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361338: JFR: Min and max time in MethodTime event is confusing

Marked as reviewed by shade (Reviewer).

src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/TimedClass.java line 76:

> 74:                     if (max == Long.MIN_VALUE) {
> 75:                         max = average;
> 76:                     }

For the future: I think `Math.min/max` below subsume these checks for `Long.MAX/MIN_VALUE`.

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

PR Review: https://git.openjdk.org/jdk/pull/26145#pullrequestreview-2992688756
PR Review Comment: https://git.openjdk.org/jdk/pull/26145#discussion_r2189318564

From egahlin at openjdk.org  Mon Jul  7 10:31:57 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 7 Jul 2025 10:31:57 GMT
Subject: RFR: 8361175: JFR: Document differences between method sample
 events [v2]
In-Reply-To: <c1KKU8nJmTE77J5XMx6Gkt0W3WQ-zpureqdmKee72Zs=.0b17f28a-cfe1-434a-bd84-d02d1ef79246@github.com>
References: <c1KKU8nJmTE77J5XMx6Gkt0W3WQ-zpureqdmKee72Zs=.0b17f28a-cfe1-434a-bd84-d02d1ef79246@github.com>
Message-ID: <LzLr7ng9Oaby7oNcvmejT5GYwOgcJw2ulCGnYRzoG8Q=.8abd9e84-aed8-4425-bd01-704d18c15b7f@github.com>

> Could I have a review that clarifies how the method sample events work?
> 
> - Added descriptions to NativeMethodSample, ExecutionSample and CPUTimeSample to clarify what they sample and what they don't sample.
> - Removed the word "Method" from the labels of the CPUTimeSample and "ExecutionSample events for consistency and to avoid overly verbose event labels.
> - Added the word "setting" so that the description of CPUTimeSample reads "throttle setting" instead of just "throttle".
> - Changed the label for the CPUTimeSamplesLost event to "CPU Time Samples Lost", making it easier to associate with "CPU Time Sample" event. 
> - Removed the percentage column from the "native-methods" view, as normalization doesn't make sense when mixing executing and waiting samples.
> 
> 
> Testing: tets/jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26132/files
  - new: https://git.openjdk.org/jdk/pull/26132/files/256c268f..80ead0b6

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

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

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

From mgronlun at openjdk.org  Mon Jul  7 12:35:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 7 Jul 2025 12:35:38 GMT
Subject: RFR: 8361175: JFR: Document differences between method sample
 events [v2]
In-Reply-To: <LzLr7ng9Oaby7oNcvmejT5GYwOgcJw2ulCGnYRzoG8Q=.8abd9e84-aed8-4425-bd01-704d18c15b7f@github.com>
References: <c1KKU8nJmTE77J5XMx6Gkt0W3WQ-zpureqdmKee72Zs=.0b17f28a-cfe1-434a-bd84-d02d1ef79246@github.com>
 <LzLr7ng9Oaby7oNcvmejT5GYwOgcJw2ulCGnYRzoG8Q=.8abd9e84-aed8-4425-bd01-704d18c15b7f@github.com>
Message-ID: <s82iOevm1O9ljnHCkuXtDWEdyCWAG_N0SITYcSuyxcs=.5711680c-b6ed-4998-882e-5f9084140d7f@github.com>

On Mon, 7 Jul 2025 10:31:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review that clarifies how the method sample events work?
>> 
>> - Added descriptions to NativeMethodSample, ExecutionSample and CPUTimeSample to clarify what they sample and what they don't sample.
>> - Removed the word "Method" from the labels of the CPUTimeSample and ExecutionSample events for consistency and to avoid overly verbose event labels.
>> - Added the word "setting" so that the description of CPUTimeSample reads "throttle setting" instead of just "throttle".
>> - Changed the label for the CPUTimeSamplesLost event to "CPU Time Samples Lost", making it easier to associate with "CPU Time Sample" event. 
>> - Removed the percentage column from the "native-methods" view, as normalization doesn't make sense when mixing executing and waiting samples.
>> 
>> 
>> Testing: tets/jdk/jdk/jfr + tier1
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26132#pullrequestreview-2993638311

From egahlin at openjdk.org  Tue Jul  8 14:06:48 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 8 Jul 2025 14:06:48 GMT
Subject: [jdk25] Integrated: 8361338: JFR: Min and max time in MethodTime event
 is confusing
In-Reply-To: <G7vdPIIhSJjNO-DHORXq72UI_MnpXln3UI8ntOqQRos=.fb81dd7c-debe-4e92-8568-f0c9bd61d106@github.com>
References: <G7vdPIIhSJjNO-DHORXq72UI_MnpXln3UI8ntOqQRos=.fb81dd7c-debe-4e92-8568-f0c9bd61d106@github.com>
Message-ID: <DauvS-x7sttHHQFC6TDc1uhsF4gAcINrsmQHWJcioNA=.f59e6d09-d1b5-4b9e-8fde-7b9b71087699@github.com>

On Sun, 6 Jul 2025 19:17:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361338: JFR: Min and max time in MethodTime event is confusing

This pull request has now been integrated.

Changeset: b3b55953
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3b5595362a64a134f4df6a7e655e87b4844b800
Stats:     30 lines in 4 files changed: 23 ins; 4 del; 3 mod

8361338: JFR: Min and max time in MethodTime event is confusing

Reviewed-by: shade
Backport-of: f3e0588d0b825a68a4ad61ddf806877f46da69dc

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

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

From egahlin at openjdk.org  Tue Jul  8 14:07:48 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 8 Jul 2025 14:07:48 GMT
Subject: Integrated: 8361175: JFR: Document differences between method sample
 events
In-Reply-To: <c1KKU8nJmTE77J5XMx6Gkt0W3WQ-zpureqdmKee72Zs=.0b17f28a-cfe1-434a-bd84-d02d1ef79246@github.com>
References: <c1KKU8nJmTE77J5XMx6Gkt0W3WQ-zpureqdmKee72Zs=.0b17f28a-cfe1-434a-bd84-d02d1ef79246@github.com>
Message-ID: <-skp_oM-aomfwHSUd4W8gLoTdN7xoBF5VRBnsSDlb1k=.4b697eed-9cfa-4f1a-85ca-dc3b302f83b7@github.com>

On Fri, 4 Jul 2025 11:57:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review that clarifies how the method sample events work?
> 
> - Added descriptions to NativeMethodSample, ExecutionSample and CPUTimeSample to clarify what they sample and what they don't sample.
> - Removed the word "Method" from the labels of the CPUTimeSample and ExecutionSample events for consistency and to avoid overly verbose event labels.
> - Added the word "setting" so that the description of CPUTimeSample reads "throttle setting" instead of just "throttle".
> - Changed the label for the CPUTimeSamplesLost event to "CPU Time Samples Lost", making it easier to associate with "CPU Time Sample" event. 
> - Removed the percentage column from the "native-methods" view, as normalization doesn't make sense when mixing executing and waiting samples.
> 
> 
> Testing: tets/jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 63e08d4a
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63e08d4af7145b94048d565f4f80dae221090c19
Stats:     12 lines in 2 files changed: 2 ins; 0 del; 10 mod

8361175: JFR: Document differences between method sample events

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Tue Jul  8 21:21:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 8 Jul 2025 21:21:52 GMT
Subject: [jdk25] RFR: 8361175: JFR: Document differences between method sample
 events
Message-ID: <wXP7yRvjQHyq8zbzP_E-hNYBbHqv2z9LWpqtjD0r8So=.8caa508f-eb79-4da2-878c-bece5467ea90@github.com>

8361175: JFR: Document differences between method sample events

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

Commit messages:
 - Backport 63e08d4af7145b94048d565f4f80dae221090c19

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

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

From egahlin at openjdk.org  Wed Jul  9 08:27:26 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 9 Jul 2025 08:27:26 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for each
 character
Message-ID: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>

Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.

Testing: tier1 + jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Remove mistakenly added file
 - Initial

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

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

From alanb at openjdk.org  Wed Jul  9 09:04:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Jul 2025 09:04:38 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character
In-Reply-To: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
Message-ID: <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>

On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Testing: tier1 + jdk/jdk/jfr

The tests for this area are in tier2 (not tier1).

I think we'll need to see if a test can be added as it's way too easy to refactor this code and re-introduce the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3051782421
PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3051784996

From mgronlun at openjdk.org  Wed Jul  9 11:36:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 9 Jul 2025 11:36:38 GMT
Subject: [jdk25] RFR: 8361175: JFR: Document differences between method
 sample events
In-Reply-To: <wXP7yRvjQHyq8zbzP_E-hNYBbHqv2z9LWpqtjD0r8So=.8caa508f-eb79-4da2-878c-bece5467ea90@github.com>
References: <wXP7yRvjQHyq8zbzP_E-hNYBbHqv2z9LWpqtjD0r8So=.8caa508f-eb79-4da2-878c-bece5467ea90@github.com>
Message-ID: <ErFaNtq6IGB_MNGzvCCC9vxDmB6yHmOW7Rp-BmbaG3c=.3b8642ea-1bf1-4c25-b207-bbf99d86a052@github.com>

On Tue, 8 Jul 2025 20:54:04 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361175: JFR: Document differences between method sample events

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26202#pullrequestreview-3001175983

From egahlin at openjdk.org  Wed Jul  9 13:43:38 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 9 Jul 2025 13:43:38 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character
In-Reply-To: <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
Message-ID: <nhBqTyzEsfSsaLBIQKN8zLaBuTuYbv_NT7AHbAioAuY=.2642023c-7185-4838-a468-ab886635ec03@github.com>

On Wed, 9 Jul 2025 09:01:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we'll need to see if a test can be added as it's way too easy to refactor this code and re-introduce the issue.

I'm planning a follow-up PR that will check the top frame. Here's the draft:
https://github.com/openjdk/jdk/pull/26211

That test will count the number of events also, so it can detect if the code is refactored.

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

PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3052718528

From egahlin at openjdk.org  Wed Jul  9 15:35:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 9 Jul 2025 15:35:44 GMT
Subject: [jdk25] Integrated: 8361175: JFR: Document differences between method
 sample events
In-Reply-To: <wXP7yRvjQHyq8zbzP_E-hNYBbHqv2z9LWpqtjD0r8So=.8caa508f-eb79-4da2-878c-bece5467ea90@github.com>
References: <wXP7yRvjQHyq8zbzP_E-hNYBbHqv2z9LWpqtjD0r8So=.8caa508f-eb79-4da2-878c-bece5467ea90@github.com>
Message-ID: <W3VTcR7hSzgUE8U3siKF0VXnSqxMHMgtuXNS2F5sLHU=.5d1c899f-2f25-47ba-a376-1913b4edbc7f@github.com>

On Tue, 8 Jul 2025 20:54:04 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361175: JFR: Document differences between method sample events

This pull request has now been integrated.

Changeset: 1de89437
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1de8943731862e6fb307caf9ebb84cfcb45b71e2
Stats:     12 lines in 2 files changed: 2 ins; 0 del; 10 mod

8361175: JFR: Document differences between method sample events

Reviewed-by: mgronlun
Backport-of: 63e08d4af7145b94048d565f4f80dae221090c19

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

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

From egahlin at openjdk.org  Wed Jul  9 17:16:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 9 Jul 2025 17:16:37 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character
In-Reply-To: <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
Message-ID: <JNqPDNF2OHnOrtRHYqLXgS2pwGbTVQS6Nwh21-euqXM=.47dd77f5-0ab0-409e-8b39-ad9a877462ce@github.com>

On Wed, 9 Jul 2025 09:01:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Testing: tier1 + jdk/jdk/jfr
> 
> The tests for this area are in tier2 (not tier1).

I ran tier2. It was fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3053405518

From jbechberger at openjdk.org  Thu Jul 10 09:55:41 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 10 Jul 2025 09:55:41 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler
In-Reply-To: <lz551oJhsVzqIK2es-6-h2nfXPmCjDtGwxU0g3jCH5c=.11265fdc-19ca-44a2-86ba-9f10e61f3a91@github.com>
References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
 <lz551oJhsVzqIK2es-6-h2nfXPmCjDtGwxU0g3jCH5c=.11265fdc-19ca-44a2-86ba-9f10e61f3a91@github.com>
Message-ID: <98EJurjD0PVvZ-MtEisfTdnYvkmHKlfbILM6iZWJ2uY=.4df53f1e-8159-419f-a5a0-c11c05a65d42@github.com>

On Tue, 1 Jul 2025 19:41:43 GMT, Andrei Pangin <apangin 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 95:
> 
>> 93:         }
>> 94:         // fallback to days if no smaller unit is found
>> 95:         return String.format("%d/%s", (long)(rate / TimespanUnit.DAYS.nanos * 1_000_000_000.0), TimespanUnit.DAYS.text);
> 
> Do we really need this complication? Where is this `toString()` used?

In the CPUThrottleSetting:


    @Override
    public String combine(Set<String> values) {
        TimespanRateOrPeriod max = null;
        for (String value : values) {
            TimespanRateOrPeriod rate = TimespanRateOrPeriod.of(value);
            if (rate != null) {
                if (max == null) {
                    max = rate;
                } else {
                    max = TimespanRateOrPeriod.max(max, rate);
                }
            }
        }
        // "off" is not supported
        return Objects.requireNonNullElse(max.toString(), DEFAULT_VALUE);
    }


When combining different settings. We have to return a string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2197180848

From jbechberger at openjdk.org  Thu Jul 10 09:59:40 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 10 Jul 2025 09:59:40 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler
In-Reply-To: <lz551oJhsVzqIK2es-6-h2nfXPmCjDtGwxU0g3jCH5c=.11265fdc-19ca-44a2-86ba-9f10e61f3a91@github.com>
References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
 <lz551oJhsVzqIK2es-6-h2nfXPmCjDtGwxU0g3jCH5c=.11265fdc-19ca-44a2-86ba-9f10e61f3a91@github.com>
Message-ID: <Z8IG19Hqf8t3jp7F3fnnUwmHG2h8arVH9mwH8t-qbss=.ec141370-7340-408b-9df3-99fae5143882@github.com>

On Tue, 1 Jul 2025 19:45:41 GMT, Andrei Pangin <apangin 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 59:
> 
>> 57:     }
>> 58: 
>> 59:     public static TimespanRateOrPeriod max(TimespanRateOrPeriod a, TimespanRateOrPeriod b) {
> 
> `max` is not the best name for it, since it can be `min` for period or `max` for rate.
> The idea of the method is to select a value with the highest resolution, right? Let's reflect this in the name and/or code comment.

I renamed it "selectHigherResolution"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25775#discussion_r2197191717

From jbechberger at openjdk.org  Thu Jul 10 10:03:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 10 Jul 2025 10:03:39 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: <FdmrAiof5T9oVH22pfX5fvI9zC2zEF7McuEq87q1DLI=.ac606964-71db-4446-be16-d481d05e68ac@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.

I totally forgot the old reasoning on the name. I dropped the renaming of the class.

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

PR Comment: https://git.openjdk.org/jdk/pull/25775#issuecomment-3056693663

From jbechberger at openjdk.org  Thu Jul 10 10:14:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 10 Jul 2025 10:14:58 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler [v2]
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: <4_3IBumZMW94fghrkf-n81rk_eIGwyzUhqMilCet7Hs=.efa80840-2e10-4e0e-b7ae-1fa71f8a6c49@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.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix smaller issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25775/files
  - new: https://git.openjdk.org/jdk/pull/25775/files/116f8326..781e3dd3

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

  Stats: 124 lines in 4 files changed: 2 ins; 108 del; 14 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 Jul 10 10:18:36 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 10 Jul 2025 10:18:36 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler [v3]
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: <yusoJkRnWj9QR5ZWAnsKZvP7jMHKIA-5PA0Ly9wL-dI=.cd523514-6e54-4f2b-94ee-835d16dff83b@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.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Commit missing file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25775/files
  - new: https://git.openjdk.org/jdk/pull/25775/files/781e3dd3..ba40ca8f

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

  Stats: 115 lines in 1 file changed: 115 ins; 0 del; 0 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