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: References: Message-ID: <7ZEZWQFZX09QtIWpSkWTXjDUWejKSKFgyD8VNenf5_0=.cfca9a39-2276-44f8-8799-fe94316d0031@github.com> On Mon, 30 Jun 2025 19:45:32 GMT, Andrey Turbanov 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: References: Message-ID: > 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: On Thu, 12 Jun 2025 09:27:30 GMT, Johannes Bechberger 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: On Thu, 12 Jun 2025 09:27:30 GMT, Johannes Bechberger 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: References: Message-ID: <4YCJQTxWP6RQo1H-tGajmLUouQaWM1OGOzwMIQj5GUc=.bd6579b3-5c25-489d-af6e-bb54f47bc3f4@github.com> On Tue, 1 Jul 2025 08:12:54 GMT, Erik Gahlin 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: References: Message-ID: <1M5_9sHHd8SNfuxtO8JWmB8Z9jpttGH_o74Md1ql3Rw=.02b09e00-6886-419d-a403-08faa12104f1@github.com> On Mon, 30 Jun 2025 09:30:09 GMT, Erik Gahlin 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: References: Message-ID: <0EXLpOD70EMbBGAmtkJQPodB4hbx8xjXCXJOujk_97M=.6006f041-e1d3-404f-a7a8-b7ccf29d4c73@github.com> On Mon, 30 Jun 2025 09:30:09 GMT, Erik Gahlin wrote: > 8360287: JFR: PlatformTracer class should be loaded lazily This pull request has now been integrated. Changeset: e3bd9c6e Author: Erik Gahlin 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: References: Message-ID: <_5_o3I54LmmcRzk9wJU-IO0QKFCZFq7GIpIKJdh7bxI=.552b8524-ff24-4612-b1d0-92bb2a2baf57@github.com> On Fri, 27 Jun 2025 20:49:37 GMT, Erik Gahlin 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 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: 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: References: Message-ID: On Fri, 4 Jul 2025 06:22:00 GMT, Erik Gahlin 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: 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: References: Message-ID: > 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: References: Message-ID: On Fri, 4 Jul 2025 06:22:00 GMT, Erik Gahlin wrote: > 8358750: JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs This pull request has now been integrated. Changeset: 8707167e Author: Erik Gahlin 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: References: Message-ID: On Fri, 4 Jul 2025 11:35:54 GMT, Erik Gahlin 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: 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: References: Message-ID: On Thu, 3 Jul 2025 08:17:10 GMT, Erik Gahlin 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 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: 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: References: Message-ID: On Sun, 6 Jul 2025 19:17:42 GMT, Erik Gahlin 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: References: Message-ID: > 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: References: Message-ID: On Mon, 7 Jul 2025 10:31:57 GMT, Erik Gahlin 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: References: Message-ID: On Sun, 6 Jul 2025 19:17:42 GMT, Erik Gahlin wrote: > 8361338: JFR: Min and max time in MethodTime event is confusing This pull request has now been integrated. Changeset: b3b55953 Author: Erik Gahlin 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: References: Message-ID: <-skp_oM-aomfwHSUd4W8gLoTdN7xoBF5VRBnsSDlb1k=.4b697eed-9cfa-4f1a-85ca-dc3b302f83b7@github.com> On Fri, 4 Jul 2025 11:57:07 GMT, Erik Gahlin 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 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: 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: 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: References: Message-ID: On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin 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: References: Message-ID: On Tue, 8 Jul 2025 20:54:04 GMT, Erik Gahlin 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: References: Message-ID: On Wed, 9 Jul 2025 09:01:52 GMT, Alan Bateman 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: References: Message-ID: On Tue, 8 Jul 2025 20:54:04 GMT, Erik Gahlin wrote: > 8361175: JFR: Document differences between method sample events This pull request has now been integrated. Changeset: 1de89437 Author: Erik Gahlin 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: References: Message-ID: On Wed, 9 Jul 2025 09:01:00 GMT, Alan Bateman 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: References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com> Message-ID: <98EJurjD0PVvZ-MtEisfTdnYvkmHKlfbILM6iZWJ2uY=.4df53f1e-8159-419f-a5a0-c11c05a65d42@github.com> On Tue, 1 Jul 2025 19:41:43 GMT, Andrei Pangin 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 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: References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com> Message-ID: On Tue, 1 Jul 2025 19:45:41 GMT, Andrei Pangin 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: On Thu, 12 Jun 2025 09:27:30 GMT, Johannes Bechberger 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: > 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