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

From egahlin at openjdk.org  Fri Jul 11 09:34:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Jul 2025 09:34:04 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
Message-ID: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>

Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).

Testing: tier1, tier2 + jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Cleanup and socket adapters
 - Use switch expression
 - Revert accidental move
 - Fix whitespace
 - Initial

Changes: https://git.openjdk.org/jdk/pull/26211/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26211&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361639
  Stats: 375 lines in 6 files changed: 358 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26211.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26211/head:pull/26211

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

From alanb at openjdk.org  Fri Jul 11 09:34:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Jul 2025 09:34:04 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <MV4RYfuS8-dFDAe7y7a-M9B3Dr8fHq4clqMDWWcMg60=.66456e63-9fc8-494c-8641-5e2ade4975bd@github.com>

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

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 74:

> 72:         testFileRead();
> 73:         testSocketStreams();
> 74:         testSocketChannels();

The other case is the socket adaptor, as in SocketChannel::socket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2195672061

From mgronlun at openjdk.org  Fri Jul 11 09:34:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 11 Jul 2025 09:34:13 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: <fDox2b1axouS3fkLXeu7bq2LFj0V4z6IgyqvsoBlCMY=.cc684f5b-69fc-4d55-9310-d206732d39c7@github.com>

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

> 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 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3009487213

From egahlin at openjdk.org  Fri Jul 11 09:34:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Jul 2025 09:34:04 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <MV4RYfuS8-dFDAe7y7a-M9B3Dr8fHq4clqMDWWcMg60=.66456e63-9fc8-494c-8641-5e2ade4975bd@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <MV4RYfuS8-dFDAe7y7a-M9B3Dr8fHq4clqMDWWcMg60=.66456e63-9fc8-494c-8641-5e2ade4975bd@github.com>
Message-ID: <_pYZlNrH5axGeFZQrBzLb69rU55YsqlrMW5abLBJ-zU=.2e64c02e-eeab-4cd2-8caf-9d32b55ada89@github.com>

On Wed, 9 Jul 2025 17:59:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
>> 
>> Testing: tier1, tier2 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 74:
> 
>> 72:         testFileRead();
>> 73:         testSocketStreams();
>> 74:         testSocketChannels();
> 
> The other case is the socket adaptor, as in SocketChannel::socket.

I added support for adapters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2200197667

From egahlin at openjdk.org  Sun Jul 13 22:00:28 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 13 Jul 2025 22:00:28 GMT
Subject: RFR: 8362097: JFR: Active Settings view broken
Message-ID: <pbu6U1rg7z0X_GG06betxrNHW4wxnPkG8NwK11WAKJo=.525e003a-c1c4-44dd-935d-81075055b1e5@github.com>

Could I have review of a PR that fixes the active-settings view.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Mon Jul 14 07:42:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 14 Jul 2025 07:42:38 GMT
Subject: RFR: 8362097: JFR: Active Settings view broken
In-Reply-To: <pbu6U1rg7z0X_GG06betxrNHW4wxnPkG8NwK11WAKJo=.525e003a-c1c4-44dd-935d-81075055b1e5@github.com>
References: <pbu6U1rg7z0X_GG06betxrNHW4wxnPkG8NwK11WAKJo=.525e003a-c1c4-44dd-935d-81075055b1e5@github.com>
Message-ID: <W3NyorwF1M5541wpjz1fZI4n5p1nGqko4rKv-TUOvrI=.8aceabb0-b503-47f6-b08c-49ab78cb6899@github.com>

On Sun, 13 Jul 2025 21:52:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes the active-settings view.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26280#pullrequestreview-3015103229

From jbachorik at openjdk.org  Mon Jul 14 12:50:40 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Mon, 14 Jul 2025 12:50:40 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler [v3]
In-Reply-To: <yusoJkRnWj9QR5ZWAnsKZvP7jMHKIA-5PA0Ly9wL-dI=.cd523514-6e54-4f2b-94ee-835d16dff83b@github.com>
References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
 <yusoJkRnWj9QR5ZWAnsKZvP7jMHKIA-5PA0Ly9wL-dI=.cd523514-6e54-4f2b-94ee-835d16dff83b@github.com>
Message-ID: <gc-ew_XZOKZ67CXoTsQjTSreMI7m61T3nd-gcShqYAg=.d265c19a-eb2f-41cf-9b88-e430aed6ffcb@github.com>

On Thu, 10 Jul 2025 10:18:36 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.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Commit missing file

Marked as reviewed by jbachorik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25775#pullrequestreview-3016245614

From mgronlun at openjdk.org  Mon Jul 14 17:13:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 14 Jul 2025 17:13:40 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <VKhafG65tsvM-yVACtNDZQ8qtlzcXCaoMu3THp629YM=.b13560e8-8fff-4f75-bf9a-63fc04bbe7b7@github.com>

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

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26211#pullrequestreview-3017130373

From egahlin at openjdk.org  Tue Jul 15 04:44:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 04:44:37 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: <IZ_JQ401cUHXNC3iciH3To6fC6djlkNJg0jiq0nPraE=.2f0a6828-b754-4b84-9ce1-6c0a89a878ce@github.com>

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

> 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 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

It would be good if I could get a review from someone in core-libs before integrating. Thanks.

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

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

From egahlin at openjdk.org  Tue Jul 15 05:17:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 05:17:42 GMT
Subject: Integrated: 8362097: JFR: Active Settings view broken
In-Reply-To: <pbu6U1rg7z0X_GG06betxrNHW4wxnPkG8NwK11WAKJo=.525e003a-c1c4-44dd-935d-81075055b1e5@github.com>
References: <pbu6U1rg7z0X_GG06betxrNHW4wxnPkG8NwK11WAKJo=.525e003a-c1c4-44dd-935d-81075055b1e5@github.com>
Message-ID: <LUV3SFxPWAKnQ1vEQKcdsR0r4k3ipnsIzmYaRZB4sSg=.70b5d131-f4bd-41d9-9fea-22ac1cea158f@github.com>

On Sun, 13 Jul 2025 21:52:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes the active-settings view.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 25e509b0
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25e509b0db4f35b3b8fbfeb7ec84cc0e0fed89d1
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8362097: JFR: Active Settings view broken

Reviewed-by: mgronlun

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

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

From mgronlun at openjdk.org  Tue Jul 15 09:31:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 15 Jul 2025 09:31:40 GMT
Subject: RFR: 8358619: Fix interval recomputation in CPU Time Profiler [v3]
In-Reply-To: <yusoJkRnWj9QR5ZWAnsKZvP7jMHKIA-5PA0Ly9wL-dI=.cd523514-6e54-4f2b-94ee-835d16dff83b@github.com>
References: <3WRVvy_UqE4zZX60ZmDPb23PnJN2_pinfrcKVD-uQR8=.253cb8cd-8c39-49e5-b7f1-9e9f16bd76ea@github.com>
 <yusoJkRnWj9QR5ZWAnsKZvP7jMHKIA-5PA0Ly9wL-dI=.cd523514-6e54-4f2b-94ee-835d16dff83b@github.com>
Message-ID: <UR-vTP_OubLn3D6bB-V9u3UCs_M7GC3iSEVOaRZL48A=.493c1410-c4e2-4175-a14e-6b07c662b163@github.com>

On Thu, 10 Jul 2025 10:18:36 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.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Commit missing file

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25775#pullrequestreview-3019521278

From kiriyama.takuya at fujitsu.com  Tue Jul 15 09:35:30 2025
From: kiriyama.takuya at fujitsu.com (Takuya Kiriyama (Fujitsu))
Date: Tue, 15 Jul 2025 09:35:30 +0000
Subject: Question about the priority in Old Object Sample event
Message-ID: <TYCPR01MB8834B5229C67E513E0F6F406E757A@TYCPR01MB8834.jpnprd01.prod.outlook.com>

Hi,

I'm investigating Old Object Sample event in JFR that is useful
for memory leak analysis, but I'm finding some implementation
puzzling. I'd be grateful for any insights from those with more
experience.

Old Object Sample tracks a fixed number of objects on the heap
for as long as they are live. Marcus' article [1] was very useful
for understanding this event.
However, I have doubts about the priority of the samples stored
in the priority queue. As mentioned in the article, the priority
called "span" is determined by the memory size, giving more
weight to samples that are causing more serious leaks.

The code that implements span [2]:

```
  _total_allocated += allocated;
  const size_t span = _total_allocated - _priority_queue->total();
```

Here, "_total_allocated" is the total memory size allocated so far,
and "_priority_queue->total()" is the total size of the priority queue.
Since "_total_allocated" increases monotonically, the span of samples
allocated later tends to increase as time passes

For memory leak analysis, it is very important to pick which objects
out of a large number of objects. I didn't understand why objects
generated later tend to take precedence.

Any advice would be greatly appreciated.

Regards,
Takuya

From jbechberger at openjdk.org  Tue Jul 15 11:00:47 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 11:00:47 GMT
Subject: Integrated: 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: <r-6CLjmMiYe3HMbLjRwtyGYRA8XW8cSwkAN70cclvAQ=.7df4eb4f-17a2-4195-a686-c78b55675738@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.

This pull request has now been integrated.

Changeset: c70258ca
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c70258ca1cd074392b5bf844bf6f7b80601f45cc
Stats:     208 lines in 10 files changed: 122 ins; 11 del; 75 mod

8358619: Fix interval recomputation in CPU Time Profiler

Reviewed-by: jbachorik, mgronlun

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

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

From jbechberger at openjdk.org  Tue Jul 15 11:27:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 11:27:13 GMT
Subject: [jdk25] RFR: 8358619: Fix interval recomputation in CPU Time Profiler
Message-ID: <ChlMt-6g4x4IZAkkvg3yq9h4Z7gvUxjkkUM62Fui-GA=.da3ea39c-b8dc-404c-9ac1-11eafccb4455@github.com>

Fixes the interval recomputation in JEP 509, tested in the SAP CI.

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

Commit messages:
 - Backport c70258ca1cd074392b5bf844bf6f7b80601f45cc

Changes: https://git.openjdk.org/jdk/pull/26313/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26313&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358619
  Stats: 208 lines in 10 files changed: 122 ins; 11 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/26313.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26313/head:pull/26313

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

From jbechberger at openjdk.org  Tue Jul 15 11:41:49 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 11:41:49 GMT
Subject: RFR: 8358621: Avoid using a spinlock as the synchronization point
 returning from native in CPU Time Profiler
Message-ID: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>

Simple optimization to avoid busy waiting in safepoint handlers.

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

Commit messages:
 - Improve busy waiting

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

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

From shade at openjdk.org  Tue Jul 15 11:49:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 11:49:38 GMT
Subject: RFR: 8358621: Avoid using a spinlock as the synchronization point
 returning from native in CPU Time Profiler
In-Reply-To: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
Message-ID: <cxH_noFKh47I27a0xSr-7Rht47AArUNVnWci1ZlvWQg=.c4f6fd3f-4168-4d69-9b9e-8964dc1525c3@github.com>

On Tue, 15 Jul 2025 11:36:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Simple optimization to avoid busy waiting in safepoint handlers.

There is an utility for this, look in `utilities/spinYield.hpp`. Would be something like:


SpinYield sy;
while (...) {
  sy.wait();
}


Also, well, this does not _avoid_ the spinlock, it only makes it less aggressive.

I read the original improvement suggested using the actual / blocking `Mutex`/`Monitor`.

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

PR Review: https://git.openjdk.org/jdk/pull/26314#pullrequestreview-3019955256

From jbechberger at openjdk.org  Tue Jul 15 11:55:41 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 11:55:41 GMT
Subject: RFR: 8358621: Avoid using a spinlock as the synchronization point
 returning from native in CPU Time Profiler
In-Reply-To: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
Message-ID: <GxdnBvh_tfItg_uBt1JoxlvaxpKvvzQFY_NJ3iHye4o=.72bf16f4-7c12-412b-bf6e-3fb4e45361c3@github.com>

On Tue, 15 Jul 2025 11:36:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Simple optimization to avoid busy waiting in safepoint handlers.

Mutex / Monitor cannot be used as the lock is also used in signal handlers. I'll update to use SpinYield.

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

PR Comment: https://git.openjdk.org/jdk/pull/26314#issuecomment-3073308502

From jbechberger at openjdk.org  Tue Jul 15 12:12:22 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 12:12:22 GMT
Subject: RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler [v2]
In-Reply-To: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
Message-ID: <Paec7Pofd1UnlXVoYhPTJMCz5ZGM6PsD9kgqK4Aepa8=.c9025c65-401d-4aad-8b39-2a1a052dd9b5@github.com>

> Simple optimization to reduce busy waiting in safepoint handlers.

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

  Use SpinYield

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26314/files
  - new: https://git.openjdk.org/jdk/pull/26314/files/7fe92854..ad67f51c

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

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

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

From shade at openjdk.org  Tue Jul 15 12:12:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 12:12:22 GMT
Subject: RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler [v2]
In-Reply-To: <Paec7Pofd1UnlXVoYhPTJMCz5ZGM6PsD9kgqK4Aepa8=.c9025c65-401d-4aad-8b39-2a1a052dd9b5@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
 <Paec7Pofd1UnlXVoYhPTJMCz5ZGM6PsD9kgqK4Aepa8=.c9025c65-401d-4aad-8b39-2a1a052dd9b5@github.com>
Message-ID: <3B1XNEYq0REGssuIjBXFMfLQ7vxz56ZBuTggyxSUk28=.7fb8a48c-d502-449c-968e-a0e1ec171f1a@github.com>

On Tue, 15 Jul 2025 12:09:07 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Simple optimization to reduce busy waiting in safepoint handlers.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SpinYield

Looks OK to me, as long as JFR folks are happy with this solution.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26314#pullrequestreview-3019998648

From shade at openjdk.org  Tue Jul 15 12:12:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 12:12:22 GMT
Subject: RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler
In-Reply-To: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
Message-ID: <sfk9F2mp8tw1nNx7CJDzL1HgN2Px5prcPSfRASRWT_M=.cd0d236f-d5bd-4620-9228-711c47829236@github.com>

On Tue, 15 Jul 2025 11:36:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Simple optimization to reduce busy waiting in safepoint handlers.

Also this: "I propose we just rename the issue to something more related to the change. Also, maybe set Fix Version: 26, and then backport, to avoid complicating things unnecessarily."

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

PR Comment: https://git.openjdk.org/jdk/pull/26314#issuecomment-3073345273

From jbechberger at openjdk.org  Tue Jul 15 12:12:22 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 12:12:22 GMT
Subject: RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler
In-Reply-To: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
Message-ID: <SB_Tf3mMIHdQaFiAbtvC97xIotPcakXcNZKvyVa9zt4=.fb2b478b-6de4-4f9f-b6c0-9578cb66c8c3@github.com>

On Tue, 15 Jul 2025 11:36:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Simple optimization to reduce busy waiting in safepoint handlers.

Thanks. As a background: This lock should almost never be locked (confirmed with renaissance benchmark), when the safepoint handler comes in. So it is more a defence against a rare outlier.

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

PR Comment: https://git.openjdk.org/jdk/pull/26314#issuecomment-3073349264

From jbachorik at openjdk.org  Tue Jul 15 12:40:40 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Tue, 15 Jul 2025 12:40:40 GMT
Subject: RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler [v2]
In-Reply-To: <Paec7Pofd1UnlXVoYhPTJMCz5ZGM6PsD9kgqK4Aepa8=.c9025c65-401d-4aad-8b39-2a1a052dd9b5@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
 <Paec7Pofd1UnlXVoYhPTJMCz5ZGM6PsD9kgqK4Aepa8=.c9025c65-401d-4aad-8b39-2a1a052dd9b5@github.com>
Message-ID: <9pumduUp1vDTN8fUSoWMZpi8HR-ZgMOw7I17sZpXGCc=.d09868c8-84d6-4007-8bbd-88e5a5fcb3ee@github.com>

On Tue, 15 Jul 2025 12:12:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Simple optimization to reduce busy waiting in safepoint handlers.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SpinYield

Marked as reviewed by jbachorik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26314#pullrequestreview-3020106053

From egahlin at openjdk.org  Tue Jul 15 12:48:43 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 12:48:43 GMT
Subject: RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler [v2]
In-Reply-To: <Paec7Pofd1UnlXVoYhPTJMCz5ZGM6PsD9kgqK4Aepa8=.c9025c65-401d-4aad-8b39-2a1a052dd9b5@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
 <Paec7Pofd1UnlXVoYhPTJMCz5ZGM6PsD9kgqK4Aepa8=.c9025c65-401d-4aad-8b39-2a1a052dd9b5@github.com>
Message-ID: <1RJd2nQy0vzajLAiREQ1UGJ1X6L3C0E2qPNqtrF1x6Q=.980fe7cd-1fff-42e4-9787-c63c6f91305e@github.com>

On Tue, 15 Jul 2025 12:12:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Simple optimization to reduce busy waiting in safepoint handlers.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SpinYield

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26314#pullrequestreview-3020130466

From alanb at openjdk.org  Tue Jul 15 13:40:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 13:40:40 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <PssjHDEO4S_0nt2Fp7ScTVnXy0d29UV_6nTUCMD9znk=.05236d63-32ab-46d5-acbc-64997ffa654f@github.com>

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

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/events/FileReadEvent.java line 44:

> 42:               "java.io.DataInputStream",
> 43:               "java.io.FileInputStream",
> 44:               "java.io.InputStream",

Do you have any stack traces handy that could be pasted into the JBS issue or the PR so that it's clear why InputStream and Data*Stream frames are filtered?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2207508203

From jbechberger at openjdk.org  Tue Jul 15 14:25:45 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 14:25:45 GMT
Subject: Integrated: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler
In-Reply-To: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
References: <_M4ZK2igZxj2yvcQt8hFIaHzVsA5rJ6JZHJvPUXNDGk=.f16841ea-19ab-443a-af6a-400c2aa4e9d9@github.com>
Message-ID: <QRnb6mPmlB-vagC5Ybtr39Wn_NnBN7LnqRADjJNTbas=.d3ac2602-6b89-4b7b-9d2a-4e5021297207@github.com>

On Tue, 15 Jul 2025 11:36:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Simple optimization to reduce busy waiting in safepoint handlers.

This pull request has now been integrated.

Changeset: d2082c58
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2082c58ff086eb37c6211a8d1b813cdfedc2259
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8358621: Reduce busy waiting in worse case at the synchronization point returning from native in CPU Time Profiler

Reviewed-by: shade, jbachorik, egahlin

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

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

From rriggs at openjdk.org  Tue Jul 15 14:30:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 14:30:42 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: <vf6Px4zJNJrwVk66vBHdarAXon9vCnhLyf2gyxe0_fA=.009ecf72-773a-4996-83f4-2c17626003e9@github.com>

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

> 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 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3020688621

From jbechberger at openjdk.org  Tue Jul 15 14:44:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 15 Jul 2025 14:44:19 GMT
Subject: [jdk25] RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler
Message-ID: <QmuS__mD18S3QbJP4m90AcAhxce58PMo8nStkA23MS0=.dbc24ad5-920d-41dc-b5ea-e0a0ab9d3e73@github.com>

Hi all,

This pull request contains a backport of commit [d2082c58](https://github.com/openjdk/jdk/commit/d2082c58ff086eb37c6211a8d1b813cdfedc2259) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Johannes Bechberger on 15 Jul 2025 and was reviewed by Aleksey Shipilev, Jaroslav Bachorik and Erik Gahlin.

Thanks!

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

Commit messages:
 - Backport d2082c58ff086eb37c6211a8d1b813cdfedc2259

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

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

From alanb at openjdk.org  Tue Jul 15 16:12:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 16:12:40 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: <B4c9PF2e1qev7TnGG6I0GfYcSS2u-PBimTbnPtOwEo8=.47b1f4ca-68a5-4128-b08a-b382d1340692@github.com>

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

> 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 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

src/java.base/share/classes/java/io/RandomAccessFile.java line 1039:

> 1037:     }
> 1038: 
> 1039:     private String traceImplReadLine() throws IOException {

I think it would be cleaner to have the FileReadEvent usage in readLine. That would reduce this to readLine + implReadLine, no traceImplReadLine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26210#discussion_r2207938638

From egahlin at openjdk.org  Tue Jul 15 17:09:23 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 17:09:23 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
Message-ID: <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@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 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Remove traceImplReadLine

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26210/files
  - new: https://git.openjdk.org/jdk/pull/26210/files/027093ed..37b10a17

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

  Stats: 21 lines in 1 file changed: 8 ins; 12 del; 1 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 egahlin at openjdk.org  Tue Jul 15 17:45:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 17:45:42 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <PssjHDEO4S_0nt2Fp7ScTVnXy0d29UV_6nTUCMD9znk=.05236d63-32ab-46d5-acbc-64997ffa654f@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <PssjHDEO4S_0nt2Fp7ScTVnXy0d29UV_6nTUCMD9znk=.05236d63-32ab-46d5-acbc-64997ffa654f@github.com>
Message-ID: <hL-E9pYQLno41aDU1wj1ndSGNM3-A6-47XDEz9-op34=.c548f6ce-c37b-492e-8ab8-ccd6f55bd3e9@github.com>

On Tue, 15 Jul 2025 13:38:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
>> 
>> Testing: tier1, tier2 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/events/FileReadEvent.java line 44:
> 
>> 42:               "java.io.DataInputStream",
>> 43:               "java.io.FileInputStream",
>> 44:               "java.io.InputStream",
> 
> Do you have any stack traces handy that could be pasted into the JBS issue or the PR so that it's clear why InputStream and Data*Stream frames are filtered?

It's DataInputStream::readUTF(DataInput in), used by RandomAccessFile::readUTF(), and InputStream::readNBytes(byte[], int, int), which is not overridden by FileInputStream. (FileRead)

DataOutputStream::writeUTF(DataOutput) used by RandomAccessFile::writeUTF (FileWrite)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2208184872

From egahlin at openjdk.org  Tue Jul 15 17:48:39 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 17:48:39 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <B4c9PF2e1qev7TnGG6I0GfYcSS2u-PBimTbnPtOwEo8=.47b1f4ca-68a5-4128-b08a-b382d1340692@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <B4c9PF2e1qev7TnGG6I0GfYcSS2u-PBimTbnPtOwEo8=.47b1f4ca-68a5-4128-b08a-b382d1340692@github.com>
Message-ID: <_nyotsEtXqR_QscsRsAUKa4Apk6zEgKQy8xpkvoPpKg=.ea911c7d-b6c9-4a6c-9ac4-e327a91a7412@github.com>

On Tue, 15 Jul 2025 16:09:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove traceImplReadLine
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 1039:
> 
>> 1037:     }
>> 1038: 
>> 1039:     private String traceImplReadLine() throws IOException {
> 
> I think it would be cleaner to have the FileReadEvent usage in readLine. That would reduce this to readLine + implReadLine, no traceImplReadLine.

Refactored the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26210#discussion_r2208195842

From alanb at openjdk.org  Tue Jul 15 18:04:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 18:04:46 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
Message-ID: <ctSg4w8ax-XJltYQvmzghoY5ZYkgyOZgkuRaRWDPKJo=.5b2d1f60-b609-4962-95c2-a4e01140a22e@github.com>

On Tue, 15 Jul 2025 17:09:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> 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 + tier2 +  jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove traceImplReadLine

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3021653358

From rriggs at openjdk.org  Tue Jul 15 18:56:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 18:56:42 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
Message-ID: <u9H4VLcYH6iG7tL6LIbnpNsnMvVsn9o01xIUJfsAQlU=.df285b11-60d4-452c-b167-d179d20af10b@github.com>

On Tue, 15 Jul 2025 17:09:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> 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 + tier2 +  jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove traceImplReadLine

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3021883229

From egahlin at openjdk.org  Tue Jul 15 19:09:17 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 19:09:17 GMT
Subject: [jdk25] RFR: 8362097: JFR: Active Settings view broken
Message-ID: <hecGwku1SKLhUP1IUXYyF11Uzl0c4WoRSjVswXgGA1E=.e17eb031-82a8-45a2-b6d3-84ff4f8c1907@github.com>

8362097: JFR: Active Settings view broken

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

Commit messages:
 - Backport 25e509b0db4f35b3b8fbfeb7ec84cc0e0fed89d1

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

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

From mgronlun at openjdk.org  Tue Jul 15 20:12:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 15 Jul 2025 20:12:40 GMT
Subject: [jdk25] RFR: 8362097: JFR: Active Settings view broken
In-Reply-To: <hecGwku1SKLhUP1IUXYyF11Uzl0c4WoRSjVswXgGA1E=.e17eb031-82a8-45a2-b6d3-84ff4f8c1907@github.com>
References: <hecGwku1SKLhUP1IUXYyF11Uzl0c4WoRSjVswXgGA1E=.e17eb031-82a8-45a2-b6d3-84ff4f8c1907@github.com>
Message-ID: <SqhlQAXjgNgUySKguBOao8FcnF7LHwtq8DRyqidTw2c=.227c3d56-2607-4381-b945-68b9a3478ad2@github.com>

On Tue, 15 Jul 2025 18:58:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8362097: JFR: Active Settings view broken

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26329#pullrequestreview-3022136756

From egahlin at openjdk.org  Tue Jul 15 20:35:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 20:35:45 GMT
Subject: Integrated: 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: <gnX4s9rhD01m4-BYhQKzBIy26ePjOdM1D-0ZoRSK67c=.48fe9e58-60a5-4618-be89-85ad8e71e796@github.com>

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

> 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 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 9bef2d16
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bef2d1610647dec18f9e81cbac3dddbbf99dd6d
Stats:     17 lines in 1 file changed: 15 ins; 0 del; 2 mod

8361640: JFR: RandomAccessFile::readLine emits events for each character

Reviewed-by: rriggs, alanb, mgronlun

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

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

From egahlin at openjdk.org  Wed Jul 16 06:58:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 16 Jul 2025 06:58:49 GMT
Subject: [jdk25] Integrated: 8362097: JFR: Active Settings view broken
In-Reply-To: <hecGwku1SKLhUP1IUXYyF11Uzl0c4WoRSjVswXgGA1E=.e17eb031-82a8-45a2-b6d3-84ff4f8c1907@github.com>
References: <hecGwku1SKLhUP1IUXYyF11Uzl0c4WoRSjVswXgGA1E=.e17eb031-82a8-45a2-b6d3-84ff4f8c1907@github.com>
Message-ID: <0x_-mVJApthf4Q76LxdszuIIWZJJqYti5oJXRdsL4tk=.07eb2c5d-a9a2-4e6d-9341-1160883d3dea@github.com>

On Tue, 15 Jul 2025 18:58:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8362097: JFR: Active Settings view broken

This pull request has now been integrated.

Changeset: 07bb0e3e
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07bb0e3e2f183db38d0e68f6a28a0275d1473739
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8362097: JFR: Active Settings view broken

Reviewed-by: mgronlun
Backport-of: 25e509b0db4f35b3b8fbfeb7ec84cc0e0fed89d1

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

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

From shade at openjdk.org  Wed Jul 16 07:26:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Jul 2025 07:26:41 GMT
Subject: [jdk25] RFR: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler
In-Reply-To: <QmuS__mD18S3QbJP4m90AcAhxce58PMo8nStkA23MS0=.dbc24ad5-920d-41dc-b5ea-e0a0ab9d3e73@github.com>
References: <QmuS__mD18S3QbJP4m90AcAhxce58PMo8nStkA23MS0=.dbc24ad5-920d-41dc-b5ea-e0a0ab9d3e73@github.com>
Message-ID: <4IQpC0QQf30qAczPEwd6LVwM__cWAfuj60H049EpSd8=.2b078921-2b08-4a51-9d24-9d34f808e467@github.com>

On Tue, 15 Jul 2025 14:38:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d2082c58](https://github.com/openjdk/jdk/commit/d2082c58ff086eb37c6211a8d1b813cdfedc2259) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Johannes Bechberger on 15 Jul 2025 and was reviewed by Aleksey Shipilev, Jaroslav Bachorik and Erik Gahlin.
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26320#pullrequestreview-3023534560

From jbechberger at openjdk.org  Wed Jul 16 07:34:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 16 Jul 2025 07:34:44 GMT
Subject: [jdk25] Integrated: 8358621: Reduce busy waiting in worse case at the
 synchronization point returning from native in CPU Time Profiler
In-Reply-To: <QmuS__mD18S3QbJP4m90AcAhxce58PMo8nStkA23MS0=.dbc24ad5-920d-41dc-b5ea-e0a0ab9d3e73@github.com>
References: <QmuS__mD18S3QbJP4m90AcAhxce58PMo8nStkA23MS0=.dbc24ad5-920d-41dc-b5ea-e0a0ab9d3e73@github.com>
Message-ID: <Kzg98kbQCg_FeHB45Z9wT1S-M6zvyEmjzCJ0veBjzNI=.4d414878-e306-4798-87d1-1d88905e278f@github.com>

On Tue, 15 Jul 2025 14:38:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d2082c58](https://github.com/openjdk/jdk/commit/d2082c58ff086eb37c6211a8d1b813cdfedc2259) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Johannes Bechberger on 15 Jul 2025 and was reviewed by Aleksey Shipilev, Jaroslav Bachorik and Erik Gahlin.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 533211af
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/533211af73d2df79fb041055a7a5de1b92bf5e3d
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8358621: Reduce busy waiting in worse case at the synchronization point returning from native in CPU Time Profiler

Reviewed-by: shade
Backport-of: d2082c58ff086eb37c6211a8d1b813cdfedc2259

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

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

From jbachorik at openjdk.org  Wed Jul 16 10:10:40 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Wed, 16 Jul 2025 10:10:40 GMT
Subject: [jdk25] RFR: 8358619: Fix interval recomputation in CPU Time
 Profiler
In-Reply-To: <ChlMt-6g4x4IZAkkvg3yq9h4Z7gvUxjkkUM62Fui-GA=.da3ea39c-b8dc-404c-9ac1-11eafccb4455@github.com>
References: <ChlMt-6g4x4IZAkkvg3yq9h4Z7gvUxjkkUM62Fui-GA=.da3ea39c-b8dc-404c-9ac1-11eafccb4455@github.com>
Message-ID: <B4gKSWT-_Rm0uyYkGFoc3qmAy_hWDfsJZUBtsuM9Bpk=.c8d392ec-92e7-4a9d-995f-634620d68949@github.com>

On Tue, 15 Jul 2025 11:22:36 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the interval recomputation in JEP 509, tested in the SAP CI.

Marked as reviewed by jbachorik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26313#pullrequestreview-3024109543

From jbechberger at openjdk.org  Wed Jul 16 10:16:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 16 Jul 2025 10:16:44 GMT
Subject: [jdk25] Integrated: 8358619: Fix interval recomputation in CPU Time
 Profiler
In-Reply-To: <ChlMt-6g4x4IZAkkvg3yq9h4Z7gvUxjkkUM62Fui-GA=.da3ea39c-b8dc-404c-9ac1-11eafccb4455@github.com>
References: <ChlMt-6g4x4IZAkkvg3yq9h4Z7gvUxjkkUM62Fui-GA=.da3ea39c-b8dc-404c-9ac1-11eafccb4455@github.com>
Message-ID: <z9j6Xse1On5zOXqTqPIPztnXGx5lxGWzW0OxisZpFOU=.ae1cfb33-f731-4b33-9c47-9e473b535544@github.com>

On Tue, 15 Jul 2025 11:22:36 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the interval recomputation in JEP 509, tested in the SAP CI.

This pull request has now been integrated.

Changeset: a626c1d9
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a626c1d92c4f73a06705efb68584bd10b61ce544
Stats:     208 lines in 10 files changed: 122 ins; 11 del; 75 mod

8358619: Fix interval recomputation in CPU Time Profiler

Reviewed-by: jbachorik
Backport-of: c70258ca1cd074392b5bf844bf6f7b80601f45cc

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

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

From aturbanov at openjdk.org  Wed Jul 16 14:45:48 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Jul 2025 14:45:48 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <J1pdn5vHMo3xXv_4_FAjWdRl-tv16Dp5b28nDKRWEyU=.34f38fa5-3665-4794-a8e5-2713dbe0db16@github.com>

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

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 227:

> 225:             sc.read(buffers[0]); // 1
> 226:             sc.read(buffers); // 2
> 227:             try (InputStream is = sc.socket().getInputStream();) {

Suggestion:

            try (InputStream is = sc.socket().getInputStream()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2210640867

From alanb at openjdk.org  Wed Jul 16 16:53:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 16:53:40 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <nOZt5eJe5yAZAsJx-vQi1N1DMpcLYieFc-IlQn3fXJY=.687e25c4-20a9-4cef-a360-e15703ddbf99@github.com>

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

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 88:

> 86:     }
> 87: 
> 88:     private static void testFileRead() throws Exception {

In addition to java.io, there will be FileRead/FileWrite events recorded for the stream/channels created with Files.newXXX methods.

test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 200:

> 198:             fc.read(buffers[0]); // 19
> 199:             if (fc.read(buffers) < 1) { // 20
> 200:                 throw new Exception("Expected som bytes to be read");

som -> some

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2210963422
PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2210961074

From egahlin at openjdk.org  Thu Jul 17 10:24:34 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 10:24:34 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events [v2]
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <sA9lAAJUKvrqB6NBjJIumVn6gK2coCQ2Vl6j1EJXeEg=.87dbae14-2625-44ba-8470-1b4b6f833ba9@github.com>

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Add support for Files.newXXX + typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26211/files
  - new: https://git.openjdk.org/jdk/pull/26211/files/eded9cdc..4b60c7a9

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

  Stats: 69 lines in 3 files changed: 43 ins; 4 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/26211.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26211/head:pull/26211

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

From mgronlun at openjdk.org  Thu Jul 17 10:30:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 17 Jul 2025 10:30:51 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events [v2]
In-Reply-To: <sA9lAAJUKvrqB6NBjJIumVn6gK2coCQ2Vl6j1EJXeEg=.87dbae14-2625-44ba-8470-1b4b6f833ba9@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <sA9lAAJUKvrqB6NBjJIumVn6gK2coCQ2Vl6j1EJXeEg=.87dbae14-2625-44ba-8470-1b4b6f833ba9@github.com>
Message-ID: <HLg-4zPcobtTQT2XJTHwwNnulnf8Cd60Yi92T82nP1g=.748d576f-32a8-4e4a-9dfb-1ec2b0bb63b5@github.com>

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

>> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
>> 
>> Testing: tier1, tier2 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for Files.newXXX + typos

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26211#pullrequestreview-3028927441

From egahlin at openjdk.org  Thu Jul 17 10:37:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 10:37:52 GMT
Subject: RFR: 8361639: JFR: Incorrect top frame for I/O events [v2]
In-Reply-To: <nOZt5eJe5yAZAsJx-vQi1N1DMpcLYieFc-IlQn3fXJY=.687e25c4-20a9-4cef-a360-e15703ddbf99@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
 <nOZt5eJe5yAZAsJx-vQi1N1DMpcLYieFc-IlQn3fXJY=.687e25c4-20a9-4cef-a360-e15703ddbf99@github.com>
Message-ID: <qm0hfjUjsPXGvYMcKaBmyAOVGA7YPUHAjs5ZYtuvtWw=.6814203c-d2d7-438a-bf99-9479003e413f@github.com>

On Wed, 16 Jul 2025 16:51:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for Files.newXXX + typos
>
> test/jdk/jdk/jfr/event/io/TestIOTopFrame.java line 88:
> 
>> 86:     }
>> 87: 
>> 88:     private static void testFileRead() throws Exception {
> 
> In addition to java.io, there will be FileRead/FileWrite events recorded for the stream/channels created with Files.newXXX methods.

I added support for Files.newByteChannel, Files.newInputStream and Files.newOutputStream.

I did try to implement it for Files.newBufferedWriter and Files.newBufferedReader, but I didn't want to filter out BufferedReader and BufferedWriter, since they might be used in application stack frames, so I did not include them in the test.

Given that RDP2 begins today, I think this is the best that can be done for JDK 25. We can revisit other top frames later, perhaps with some other mechanism. I filed an issue for this: https://bugs.openjdk.org/browse/JDK-8362491

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26211#discussion_r2212982580

From egahlin at openjdk.org  Thu Jul 17 11:23:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 11:23:55 GMT
Subject: Integrated: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
References: <wpZTK7TpbD3_DNA89g5GY6Is7ZewhxZkPA0OeRU1TWI=.22c7e688-d6b2-4573-a268-459b0de7dd6a@github.com>
Message-ID: <yyZSoeo1R8vRJmfLDYG3HExWpVxUvYerKg_2beFWmXQ=.d037255b-137e-4e8f-92e2-8fb05f7879aa@github.com>

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

> Could I have a review of the change that ensures that the top frame for I/O events is not an internal JDK method, such as FileReadEvent::offer? This change is dependent on [JDK-8361640](https://bugs.openjdk.org/browse/JDK-8361640).
> 
> Testing: tier1, tier2 + jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 1a6cbe42
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a6cbe421facab0de1c7162f2762258664338814
Stats:     414 lines in 6 files changed: 397 ins; 12 del; 5 mod

8361639: JFR: Incorrect top frame for I/O events

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Thu Jul 17 11:59:19 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 11:59:19 GMT
Subject: [jdk25] RFR: 8361639: JFR: Incorrect top frame for I/O events
Message-ID: <dehCKZz13Hj8IJHN74-HxQoYJHzLOhFLZFJQStGx8q8=.b6c2adf3-ec10-49b5-ac09-35f1572f98a2@github.com>

8361639: JFR: Incorrect top frame for I/O events

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

Commit messages:
 - Backport 1a6cbe421facab0de1c7162f2762258664338814

Changes: https://git.openjdk.org/jdk/pull/26367/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361639
  Stats: 414 lines in 6 files changed: 397 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26367/head:pull/26367

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

From mgronlun at openjdk.org  Thu Jul 17 12:11:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 17 Jul 2025 12:11:48 GMT
Subject: [jdk25] RFR: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <dehCKZz13Hj8IJHN74-HxQoYJHzLOhFLZFJQStGx8q8=.b6c2adf3-ec10-49b5-ac09-35f1572f98a2@github.com>
References: <dehCKZz13Hj8IJHN74-HxQoYJHzLOhFLZFJQStGx8q8=.b6c2adf3-ec10-49b5-ac09-35f1572f98a2@github.com>
Message-ID: <4o3RVkSOi6A-4ltGzS1zFVdu0IdGwhAvUJnab5QisiU=.c122c4a9-15c3-4c51-8bd4-54cb495ca8a4@github.com>

On Thu, 17 Jul 2025 11:47:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361639: JFR: Incorrect top frame for I/O events

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26367#pullrequestreview-3029247327

From egahlin at openjdk.org  Thu Jul 17 12:22:58 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Jul 2025 12:22:58 GMT
Subject: [jdk25] Integrated: 8361639: JFR: Incorrect top frame for I/O events
In-Reply-To: <dehCKZz13Hj8IJHN74-HxQoYJHzLOhFLZFJQStGx8q8=.b6c2adf3-ec10-49b5-ac09-35f1572f98a2@github.com>
References: <dehCKZz13Hj8IJHN74-HxQoYJHzLOhFLZFJQStGx8q8=.b6c2adf3-ec10-49b5-ac09-35f1572f98a2@github.com>
Message-ID: <GmEhTD0Qx_m6OhktbwL8rsAq98fkN65-5FUNgQJZFGM=.8ba5a031-b811-4868-8563-32c49abd656e@github.com>

On Thu, 17 Jul 2025 11:47:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361639: JFR: Incorrect top frame for I/O events

This pull request has now been integrated.

Changeset: 331adac3
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/331adac38e65b87f4ac381f42cf3c7873eb89191
Stats:     414 lines in 6 files changed: 397 ins; 12 del; 5 mod

8361639: JFR: Incorrect top frame for I/O events

Reviewed-by: mgronlun
Backport-of: 1a6cbe421facab0de1c7162f2762258664338814

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

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

From egahlin at openjdk.org  Fri Jul 18 02:14:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 18 Jul 2025 02:14:41 GMT
Subject: RFR: 8362556: New test jdk/jfr/event/io/TestIOTopFrame.java is failing
 on all platforms
Message-ID: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>

Could I have a review of a PR that adjusts the number of frames to skip for the FileRead event? The problem was that an intermediary frame was removed during review in a dependent PR, but the offset was not updated.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Fri Jul 18 11:19:46 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 18 Jul 2025 11:19:46 GMT
Subject: RFR: 8362556: New test jdk/jfr/event/io/TestIOTopFrame.java is
 failing on all platforms
In-Reply-To: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
References: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
Message-ID: <uQqcXFbtU4mv800Y06BUrn-MmHsk3Qsq90uQifWKOro=.75efc978-49d1-447b-8c5d-500b8ff661da@github.com>

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

> Could I have a review of a PR that adjusts the number of frames to skip for the FileRead event? The problem was that an intermediary frame was removed during review in a dependent PR, but the offset was not updated.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26378#pullrequestreview-3033179046

From egahlin at openjdk.org  Fri Jul 18 13:24:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 18 Jul 2025 13:24:10 GMT
Subject: RFR: 8362556: New test jdk/jfr/event/io/TestIOTopFrame.java is
 failing on all platforms [v2]
In-Reply-To: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
References: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
Message-ID: <99604m0EK1CCwBZrkbp-94p8WMVfaWevr2Mpq4kKgFI=.e3389267-1db7-40d3-b9ea-fc450ddb46ea@github.com>

> Could I have a review of a PR that adjusts the number of frames to skip for the FileRead event? The problem was that an intermediary frame was removed during review in a dependent PR, but the offset was not updated.
> 
> Testing: 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 three additional commits since the last revision:

 - Remove from problem list
 - Merge remote-tracking branch 'upstream/master' into test-raf-top-frame
 - Initial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26378/files
  - new: https://git.openjdk.org/jdk/pull/26378/files/556570bf..755ccb10

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

  Stats: 204 lines in 14 files changed: 103 ins; 49 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/26378.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26378/head:pull/26378

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

From mgronlun at openjdk.org  Fri Jul 18 14:54:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 18 Jul 2025 14:54:48 GMT
Subject: RFR: 8362556: New test jdk/jfr/event/io/TestIOTopFrame.java is
 failing on all platforms [v2]
In-Reply-To: <99604m0EK1CCwBZrkbp-94p8WMVfaWevr2Mpq4kKgFI=.e3389267-1db7-40d3-b9ea-fc450ddb46ea@github.com>
References: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
 <99604m0EK1CCwBZrkbp-94p8WMVfaWevr2Mpq4kKgFI=.e3389267-1db7-40d3-b9ea-fc450ddb46ea@github.com>
Message-ID: <GB_PUe-zGWfcpoHa56faWkpVVvpoqytSgPqWW7CnsCo=.f3f9ec28-6133-41cf-8764-cb48e4115152@github.com>

On Fri, 18 Jul 2025 13:24:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that adjusts the number of frames to skip for the FileRead event? The problem was that an intermediary frame was removed during review in a dependent PR, but the offset was not updated.
>> 
>> Testing: 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 three additional commits since the last revision:
> 
>  - Remove from problem list
>  - Merge remote-tracking branch 'upstream/master' into test-raf-top-frame
>  - Initial

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26378#pullrequestreview-3033871464

From shade at openjdk.org  Fri Jul 18 15:27:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Jul 2025 15:27:48 GMT
Subject: RFR: 8362556: New test jdk/jfr/event/io/TestIOTopFrame.java is
 failing on all platforms [v2]
In-Reply-To: <99604m0EK1CCwBZrkbp-94p8WMVfaWevr2Mpq4kKgFI=.e3389267-1db7-40d3-b9ea-fc450ddb46ea@github.com>
References: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
 <99604m0EK1CCwBZrkbp-94p8WMVfaWevr2Mpq4kKgFI=.e3389267-1db7-40d3-b9ea-fc450ddb46ea@github.com>
Message-ID: <osipkzadHHC-qN85qsQ7GSXace_0sGN0vVPz2oTDYSk=.7b80b44f-af61-4dce-b58c-29cdda5492de@github.com>

On Fri, 18 Jul 2025 13:24:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that adjusts the number of frames to skip for the FileRead event? The problem was that an intermediary frame was removed during review in a dependent PR, but the offset was not updated.
>> 
>> Testing: 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 three additional commits since the last revision:
> 
>  - Remove from problem list
>  - Merge remote-tracking branch 'upstream/master' into test-raf-top-frame
>  - Initial

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26378#pullrequestreview-3033965164

From egahlin at openjdk.org  Sat Jul 19 15:12:57 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 19 Jul 2025 15:12:57 GMT
Subject: Integrated: 8362556: New test jdk/jfr/event/io/TestIOTopFrame.java is
 failing on all platforms
In-Reply-To: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
References: <yfPWcm_D59VHjTUMsNTztQBihJGq1psmyVEuWzg6_jk=.c217791d-8598-4bfd-bd76-c92f9db2d5f4@github.com>
Message-ID: <HCBxS7vU7A2pr9grSvseoGwFEJ7HHg61DEdk5ZLYu5g=.fd825a0a-0e86-48bd-b3cc-c47e19405aed@github.com>

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

> Could I have a review of a PR that adjusts the number of frames to skip for the FileRead event? The problem was that an intermediary frame was removed during review in a dependent PR, but the offset was not updated.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 441dbde2
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/441dbde2c3c915ffd916e39a5b4a91df5620d7f3
Stats:     4 lines in 2 files changed: 1 ins; 2 del; 1 mod

8362556: New test jdk/jfr/event/io/TestIOTopFrame.java is failing on all platforms

Reviewed-by: mgronlun, shade

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

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

From egahlin at openjdk.org  Sun Jul 20 13:54:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 20 Jul 2025 13:54:49 GMT
Subject: RFR: 8362836: JFR: Broken pipe in jdk/jfr/event/io/TestIOTopFrame.java
Message-ID: <Gl_eIyYQMay2GUXWc3Xe4djBl8ISwoYXjwo18VKrmmk=.e59abffb-837f-4272-a1e2-0d5babc4c1ac@github.com>

Could I have a review of a test fix?

The problem is that the socket may be closed before all content has been written.

Testing: 1000 * jdk/jfr/event/io/TestIOTopFrame.java

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Mon Jul 21 10:19:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 21 Jul 2025 10:19:00 GMT
Subject: RFR: 8362836: JFR: Broken pipe in
 jdk/jfr/event/io/TestIOTopFrame.java
In-Reply-To: <Gl_eIyYQMay2GUXWc3Xe4djBl8ISwoYXjwo18VKrmmk=.e59abffb-837f-4272-a1e2-0d5babc4c1ac@github.com>
References: <Gl_eIyYQMay2GUXWc3Xe4djBl8ISwoYXjwo18VKrmmk=.e59abffb-837f-4272-a1e2-0d5babc4c1ac@github.com>
Message-ID: <bClqyNTphwFate9KNkVMOObWAKfAzWH99rTBVmcYWGM=.ba6219a3-0302-42a8-a087-597af978fa87@github.com>

On Sun, 20 Jul 2025 13:48:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a test fix?
> 
> The problem is that the socket may be closed before all content has been written.
> 
> Testing: 1000 * jdk/jfr/event/io/TestIOTopFrame.java
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26405#pullrequestreview-3037416242

From egahlin at openjdk.org  Mon Jul 21 10:38:47 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 21 Jul 2025 10:38:47 GMT
Subject: Integrated: 8362836: JFR: Broken pipe in
 jdk/jfr/event/io/TestIOTopFrame.java
In-Reply-To: <Gl_eIyYQMay2GUXWc3Xe4djBl8ISwoYXjwo18VKrmmk=.e59abffb-837f-4272-a1e2-0d5babc4c1ac@github.com>
References: <Gl_eIyYQMay2GUXWc3Xe4djBl8ISwoYXjwo18VKrmmk=.e59abffb-837f-4272-a1e2-0d5babc4c1ac@github.com>
Message-ID: <Yi1g9FJ4w8b5o-ccy9oy6ecopmeGCpoygx5m199Q0RA=.2c8535c0-de6e-467e-8e0b-8e85349ca43a@github.com>

On Sun, 20 Jul 2025 13:48:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a test fix?
> 
> The problem is that the socket may be closed before all content has been written.
> 
> Testing: 1000 * jdk/jfr/event/io/TestIOTopFrame.java
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 1b94a346
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b94a3466e7bb3815c0caeeeebff6018b6440455
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8362836: JFR: Broken pipe in jdk/jfr/event/io/TestIOTopFrame.java

Reviewed-by: mgronlun

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

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

From milan.mimica at gmail.com  Wed Jul 23 07:41:01 2025
From: milan.mimica at gmail.com (Milan Mimica)
Date: Wed, 23 Jul 2025 09:41:01 +0200
Subject: Question about JEP 509 and thread state
Message-ID: <CAC+6wjrV3Qnj2rQhyWZjs9g=d080iDET=QWbk0fKPdwpJiVWtQ@mail.gmail.com>

Hello

I have always assumed that JFR thread sampler will ignore threads that are
blocked on socket read, but the description on https://openjdk.org/jeps/509
states that this is exactly the problem that the JEP 509 aims to resolve.

So my question is specifically
about JfrSamplerThread::sample_java_thread/sample_native_thread. These
explicitly skip sampling unless the thread state is _thread_in_Java/
_thread_in_native. Which state is a thread in while blocked on socket read?
I assumed it was _thread_blocked.


-- 
Milan Mimica
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250723/234c9c72/attachment-0001.htm>

From erik.gahlin at oracle.com  Wed Jul 23 12:11:39 2025
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 23 Jul 2025 12:11:39 +0000
Subject: Question about JEP 509 and thread state
In-Reply-To: <CAC+6wjrV3Qnj2rQhyWZjs9g=d080iDET=QWbk0fKPdwpJiVWtQ@mail.gmail.com>
References: <CAC+6wjrV3Qnj2rQhyWZjs9g=d080iDET=QWbk0fKPdwpJiVWtQ@mail.gmail.com>
Message-ID: <DS7PR10MB51180FF5AC87387D5963C7869D5FA@DS7PR10MB5118.namprd10.prod.outlook.com>

Hello,

The ExecutionSample event will only sample code that is running Java code. The NativeMethodSample event will sample both running and blocked code in native code. See the descriptions of the events:

https://github.com/openjdk/jdk/blob/e6ac956a7ac613b916c0dbfda7e57856c1b8a83c/src/hotspot/share/jfr/metadata/metadata.xml#L951

The JEP text is confusing, and we are working on an improved version.

Erik

________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Milan Mimica <milan.mimica at gmail.com>
Sent: Wednesday, July 23, 2025 9:41 AM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: Question about JEP 509 and thread state

Hello

I have always assumed that JFR thread sampler will ignore threads that are blocked on socket read, but the description on https://openjdk.org/jeps/509 states that this is exactly the problem that the JEP 509 aims to resolve.

So my question is specifically about JfrSamplerThread::sample_java_thread/sample_native_thread. These explicitly skip sampling unless the thread state is _thread_in_Java/ _thread_in_native. Which state is a thread in while blocked on socket read? I assumed it was _thread_blocked.


--
Milan Mimica

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250723/1e3cd9a8/attachment.htm>

From suenaga at oss.nttdata.com  Thu Jul 24 09:21:09 2025
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Thu, 24 Jul 2025 18:21:09 +0900
Subject: JFR emergency dump didn't happen at OOM
Message-ID: <3bc0c029-2b98-4641-954d-d8c3557513e9@oss.nttdata.com>

Hi all,

I reported and proposed the fix about 6 years ago (!), I faced the issue again that would be helpful if this is fixed.

6 years ago, we discussed about this issue in [1], then I hear JDK-8196050 might fix this issue, but it hasn't yet happened unfortunately...

JDK codebase has been made a lot of changes in 6 years, so I think we can fix simply than I proposed before.
All of changes is [2]. It is not so big change and it is good because no flags are added in .jfc files. What do you think? I will send PR if it is ok, but I want to hear your opinions before PR (because we discussed before).

For example, we can pass a flag for OOM rather than exception handler as following:

```
--- a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
+++ b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
@@ -556,22 +556,21 @@ class JavaThreadInVMAndNative : public StackObj {
    }
  };

-static void post_events(bool exception_handler, Thread* thread) {
-  if (exception_handler) {
+static void post_events(bool is_oom, Thread* thread) {
+  if (is_oom) {
+    LeakProfiler::emit_events(max_jlong, false, false);
+  } else {
      EventShutdown e;
      e.set_reason("VM Error");
      e.commit();
-  } else {
-    // OOM
-    LeakProfiler::emit_events(max_jlong, false, false);
    }
    EventDumpReason event;
-  event.set_reason(exception_handler ? "Crash" : "Out of Memory");
+  event.set_reason(is_oom ? "Out of Memory" : "Crash");
    event.set_recordingId(-1);
    event.commit();
  }
```

And also we can identify whether OOM or not (crash) via `id` in argument of `report_and_die`:
```
--- a/src/hotspot/share/utilities/vmError.cpp
+++ b/src/hotspot/share/utilities/vmError.cpp
@@ -1856,7 +1856,7 @@ void VMError::report_and_die(int id, const char* message, const char* detail_fmt
      log.set_fd(-1);
    }

-  JFR_ONLY(Jfr::on_vm_shutdown(true);)
+  JFR_ONLY(Jfr::on_vm_shutdown(static_cast<VMErrorType>(_id) == OOM_JAVA_HEAP_FATAL);)

```


Thanks,

Yasumasa


[1] https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html
[2] https://github.com/YaSuenag/jdk/commit/3f18fd74679387c385a8f79c8bea5b6b1f2815c0

From erik.gahlin at oracle.com  Thu Jul 24 17:45:51 2025
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 24 Jul 2025 17:45:51 +0000
Subject: JFR emergency dump didn't happen at OOM
In-Reply-To: <3bc0c029-2b98-4641-954d-d8c3557513e9@oss.nttdata.com>
References: <3bc0c029-2b98-4641-954d-d8c3557513e9@oss.nttdata.com>
Message-ID: <DS7PR10MB5118B9E982D8450B5A09E14A9D5EA@DS7PR10MB5118.namprd10.prod.outlook.com>

Hi Yasumasa,

This looks more reasonable, although most of it is a refactoring.

Could you turn it into a PR with a webrev so it's easier to review?

Thanks
Erik


________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Yasumasa Suenaga <suenaga at oss.nttdata.com>
Sent: Thursday, July 24, 2025 11:21 AM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: JFR emergency dump didn't happen at OOM

Hi all,

I reported and proposed the fix about 6 years ago (!), I faced the issue again that would be helpful if this is fixed.

6 years ago, we discussed about this issue in [1], then I hear JDK-8196050 might fix this issue, but it hasn't yet happened unfortunately...

JDK codebase has been made a lot of changes in 6 years, so I think we can fix simply than I proposed before.
All of changes is [2]. It is not so big change and it is good because no flags are added in .jfc files. What do you think? I will send PR if it is ok, but I want to hear your opinions before PR (because we discussed before).

For example, we can pass a flag for OOM rather than exception handler as following:

```
--- a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
+++ b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
@@ -556,22 +556,21 @@ class JavaThreadInVMAndNative : public StackObj {
    }
  };

-static void post_events(bool exception_handler, Thread* thread) {
-  if (exception_handler) {
+static void post_events(bool is_oom, Thread* thread) {
+  if (is_oom) {
+    LeakProfiler::emit_events(max_jlong, false, false);
+  } else {
      EventShutdown e;
      e.set_reason("VM Error");
      e.commit();
-  } else {
-    // OOM
-    LeakProfiler::emit_events(max_jlong, false, false);
    }
    EventDumpReason event;
-  event.set_reason(exception_handler ? "Crash" : "Out of Memory");
+  event.set_reason(is_oom ? "Out of Memory" : "Crash");
    event.set_recordingId(-1);
    event.commit();
  }
```

And also we can identify whether OOM or not (crash) via `id` in argument of `report_and_die`:
```
--- a/src/hotspot/share/utilities/vmError.cpp
+++ b/src/hotspot/share/utilities/vmError.cpp
@@ -1856,7 +1856,7 @@ void VMError::report_and_die(int id, const char* message, const char* detail_fmt
      log.set_fd(-1);
    }

-  JFR_ONLY(Jfr::on_vm_shutdown(true);)
+  JFR_ONLY(Jfr::on_vm_shutdown(static_cast<VMErrorType>(_id) == OOM_JAVA_HEAP_FATAL);)

```


Thanks,

Yasumasa


[1] https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html
[2] https://github.com/YaSuenag/jdk/commit/3f18fd74679387c385a8f79c8bea5b6b1f2815c0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250724/e1a03690/attachment-0001.htm>

From suenaga at oss.nttdata.com  Fri Jul 25 00:53:52 2025
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Fri, 25 Jul 2025 09:53:52 +0900
Subject: JFR emergency dump didn't happen at OOM
In-Reply-To: <DS7PR10MB5118B9E982D8450B5A09E14A9D5EA@DS7PR10MB5118.namprd10.prod.outlook.com>
References: <3bc0c029-2b98-4641-954d-d8c3557513e9@oss.nttdata.com>
 <DS7PR10MB5118B9E982D8450B5A09E14A9D5EA@DS7PR10MB5118.namprd10.prod.outlook.com>
Message-ID: <e46893bf-9571-44a1-9c80-86644a5a8256@oss.nttdata.com>

Hi Erik,

I filed this to JBS, and I've sent PR:
   https://github.com/openjdk/jdk/pull/26468

I hope this issue will be fixed soon :)


Thanks,

Yasumasa


On 2025/07/25 2:45, Erik Gahlin wrote:
> Hi Yasumasa,
> 
> This looks more reasonable, although most of it is a refactoring.
> 
> Could you turn it into a PR with a webrev so it's easier to review?
> 
> Thanks
> Erik
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Yasumasa Suenaga <suenaga at oss.nttdata.com>
> *Sent:* Thursday, July 24, 2025 11:21 AM
> *To:* hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
> *Subject:* JFR emergency dump didn't happen at OOM
> Hi all,
> 
> I reported and proposed the fix about 6 years ago (!), I faced the issue again that would be helpful if this is fixed.
> 
> 6 years ago, we discussed about this issue in [1], then I hear JDK-8196050 might fix this issue, but it hasn't yet happened unfortunately...
> 
> JDK codebase has been made a lot of changes in 6 years, so I think we can fix simply than I proposed before.
> All of changes is [2]. It is not so big change and it is good because no flags are added in .jfc files. What do you think? I will send PR if it is ok, but I want to hear your opinions before PR (because we discussed before).
> 
> For example, we can pass a flag for OOM rather than exception handler as following:
> 
> ```
> --- a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> +++ b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> @@ -556,22 +556,21 @@ class JavaThreadInVMAndNative : public StackObj {
>  ??? }
>  ? };
> 
> -static void post_events(bool exception_handler, Thread* thread) {
> -? if (exception_handler) {
> +static void post_events(bool is_oom, Thread* thread) {
> +? if (is_oom) {
> +??? LeakProfiler::emit_events(max_jlong, false, false);
> +? } else {
>  ????? EventShutdown e;
>  ????? e.set_reason("VM Error");
>  ????? e.commit();
> -? } else {
> -??? // OOM
> -??? LeakProfiler::emit_events(max_jlong, false, false);
>  ??? }
>  ??? EventDumpReason event;
> -? event.set_reason(exception_handler ? "Crash" : "Out of Memory");
> +? event.set_reason(is_oom ? "Out of Memory" : "Crash");
>  ??? event.set_recordingId(-1);
>  ??? event.commit();
>  ? }
> ```
> 
> And also we can identify whether OOM or not (crash) via `id` in argument of `report_and_die`:
> ```
> --- a/src/hotspot/share/utilities/vmError.cpp
> +++ b/src/hotspot/share/utilities/vmError.cpp
> @@ -1856,7 +1856,7 @@ void VMError::report_and_die(int id, const char* message, const char* detail_fmt
>  ????? log.set_fd(-1);
>  ??? }
> 
> -? JFR_ONLY(Jfr::on_vm_shutdown(true);)
> +? JFR_ONLY(Jfr::on_vm_shutdown(static_cast<VMErrorType>(_id) == OOM_JAVA_HEAP_FATAL);)
> 
> ```
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> [1] https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html>
> [2] https://github.com/YaSuenag/jdk/commit/3f18fd74679387c385a8f79c8bea5b6b1f2815c0 <https://github.com/YaSuenag/jdk/commit/3f18fd74679387c385a8f79c8bea5b6b1f2815c0>


From egahlin at openjdk.org  Fri Jul 25 07:52:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 25 Jul 2025 07:52:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>

On Fri, 25 Jul 2025 00:52:29 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

src/hotspot/share/runtime/java.cpp line 466:

> 464:   }
> 465: 
> 466:   JFR_ONLY(Jfr::on_vm_shutdown(true, halt);)

You set oom to true here, why?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230419356

From ysuenaga at openjdk.org  Fri Jul 25 08:07:57 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 25 Jul 2025 08:07:57 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
Message-ID: <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>

On Fri, 25 Jul 2025 07:50:32 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> src/hotspot/share/runtime/java.cpp line 466:
> 
>> 464:   }
>> 465: 
>> 466:   JFR_ONLY(Jfr::on_vm_shutdown(true, halt);)
> 
> You set oom to true here, why?

To keep current behavior.

Before this change, 1st argument of `on_vm_shutdown` is `exception_handler`. You can see it on this change. If `exception_handler` sets to `false`, emergency dump handles it as OOM:


static void post_events(bool exception_handler, Thread* thread) {
  if (exception_handler) {
    EventShutdown e;
    e.set_reason("VM Error");
    e.commit();
  } else {
    // OOM
    LeakProfiler::emit_events(max_jlong, false, false);
  }
  EventDumpReason event;
  event.set_reason(exception_handler ? "Crash" : "Out of Memory");
  event.set_recordingId(-1);
  event.commit();
}


I'm not sure this code would be called when OOM happens, but I think we need to keep this behavior in this change - this change focuses on working emergency dump with `CrashOnOutOfMemoryError`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230449677

From egahlin at openjdk.org  Fri Jul 25 08:24:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 25 Jul 2025 08:24:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
 <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
Message-ID: <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>

On Fri, 25 Jul 2025 08:05:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/share/runtime/java.cpp line 466:
>> 
>>> 464:   }
>>> 465: 
>>> 466:   JFR_ONLY(Jfr::on_vm_shutdown(true, halt);)
>> 
>> You set oom to true here, why?
>
> To keep current behavior.
> 
> Before this change, 1st argument of `on_vm_shutdown` is `exception_handler`. You can see it on this change. If `exception_handler` sets to `false`, emergency dump handles it as OOM:
> 
> 
> static void post_events(bool exception_handler, Thread* thread) {
>   if (exception_handler) {
>     EventShutdown e;
>     e.set_reason("VM Error");
>     e.commit();
>   } else {
>     // OOM
>     LeakProfiler::emit_events(max_jlong, false, false);
>   }
>   EventDumpReason event;
>   event.set_reason(exception_handler ? "Crash" : "Out of Memory");
>   event.set_recordingId(-1);
>   event.commit();
> }
> 
> 
> I'm not sure this code would be called when OOM happens, but I think we need to keep this behavior in this change - this change focuses on working emergency dump with `CrashOnOutOfMemoryError`.

Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?

I think the OldObjectSample event should only be emitted if an emergency dump occurs, preferably only on oom.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230486262

From ysuenaga at openjdk.org  Fri Jul 25 09:09:53 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 25 Jul 2025 09:09:53 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
 <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
 <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>
Message-ID: <PxlkCRSxLcHIwkL23xDQF89IbZNW4JZvvKCVga1I_VI=.d174e746-59da-4d88-b5ba-2a2b5c89cc98@github.com>

On Fri, 25 Jul 2025 08:21:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?

Ok, I will rename to `emit_old_object_samples`.

> I think the OldObjectSample event should only be emitted directly from native, if an emergency dump occurs , preferably only on oom. Normal exit should be handled from Java, where a user can configure the event settings.

Normally, JFR recording should already be stopped at this point because it is stopped by shutdown hook. So I guess this code (`Jfr::on_vm_shutdown` call at here) rarely works. However it might work if shutdown hook would not work for some reasons - OOM for example.

So should we keep this code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2230583197

From egahlin at openjdk.org  Fri Jul 25 13:59:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 25 Jul 2025 13:59:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <PxlkCRSxLcHIwkL23xDQF89IbZNW4JZvvKCVga1I_VI=.d174e746-59da-4d88-b5ba-2a2b5c89cc98@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <SkaNJ1FtRbwF418Rdvyg9imJ2ZReFruFL8-WNCfciCI=.b63c30b5-ab48-4bb0-9bbb-315bc0cfac5f@github.com>
 <DaMYJ3mg_J_1eWtqBtEYHzHacW6S4_M6zN8gRkZfEAo=.cced6c8e-5a0c-41f3-acb9-dec37112fe79@github.com>
 <DHbAmg5o9_d7pa6HWJfAajl7rHfptMYuiqf2Po1IrRU=.98e77c48-d134-49e0-8038-5568779cbcee@github.com>
 <PxlkCRSxLcHIwkL23xDQF89IbZNW4JZvvKCVga1I_VI=.d174e746-59da-4d88-b5ba-2a2b5c89cc98@github.com>
Message-ID: <Yv714ShPV1hJQbSRX0HcdTEXNr7lVFntrxWtBLTzAwQ=.073ef128-c46d-43c3-bd85-3e55b97701d1@github.com>

On Fri, 25 Jul 2025 09:07:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?
>> 
>> I think the OldObjectSample event should only be emitted directly from native, if an emergency dump occurs , preferably only on oom. Normal exit should be handled from Java, where a user can configure the event settings.
>
>> Could you call the parameter something more fitting? Perhaps emit_old_object_samples, if that is the new purpose of the flag?
> 
> Ok, I will rename to `emit_old_object_samples`.
> 
>> I think the OldObjectSample event should only be emitted directly from native, if an emergency dump occurs , preferably only on oom. Normal exit should be handled from Java, where a user can configure the event settings.
> 
> Normally, JFR recording should already be stopped at this point because it is stopped by shutdown hook. So I guess this code (`Jfr::on_vm_shutdown` call at here) rarely works. However it might work if shutdown hook would not work for some reasons - OOM for example.
> 
> So should we keep this code?

I think you can keep it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2231156266

From mgronlun at openjdk.org  Fri Jul 25 14:16:44 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 25 Jul 2025 14:16:44 GMT
Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v2]
In-Reply-To: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
References: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
Message-ID: <KSkpEJeLx0mkodCRXo-9OIaQ7ya7QNa81uselmDELxo=.f1643455-c08f-49fb-92d4-d9eaafae1d29@github.com>

> Greetings,
> 
> The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method".
> 
> It involves three components:
> 
> 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll().
> 
> 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint.
> 
> 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method.
> 
> There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem.
> 
> Testing: jdk_jfr, stress testing
> 
> Thank you
> Markus

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

  Must support AllowRedefinitionToAddDeleteMethods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26458/files
  - new: https://git.openjdk.org/jdk/pull/26458/files/4b77421b..a4d6ecc3

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

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

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

From ysuenaga at openjdk.org  Sat Jul 26 02:16:49 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 26 Jul 2025 02:16:49 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Rename is_oom to emit_old_object_samples

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/c3198690..ee27149e

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

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

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

From ysuenaga at openjdk.org  Sat Jul 26 02:16:50 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 26 Jul 2025 02:16:50 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <YBrgmAkderhdpG0vjwreKvXUcoKjEcOCo4Y_PVEkNkE=.d5956950-71df-4588-b14f-e4d897f29b1b@github.com>

On Fri, 25 Jul 2025 00:52:29 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

I renamed a parameter `is_oom` to `emit_old_object_samples`.
@egahlin Could you review again?

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

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3120997144

From egahlin at openjdk.org  Sat Jul 26 16:56:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 26 Jul 2025 16:56:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
Message-ID: <plQyLGbgIzzw5_SCM_1YoVaQcjrA7pb6VTw6Xc3oAdc=.e16fb2b3-33f1-4bd5-9fc7-cd2b02ecdc0e@github.com>

On Sat, 26 Jul 2025 02:16:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename is_oom to emit_old_object_samples

src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp line 563:

> 561:     LeakProfiler::emit_events(max_jlong, false, false);
> 562:   } else {
> 563:     EventShutdown e;

Do you know why EventShutDown is not always emitted?

Is it emitted from somewhere else, so we would get two events if we always emitted it here?

I know it was this way before your change, but I?d like to understand why. We want to add another parameter or write a comment to explain the behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2233100695

From ysuenaga at openjdk.org  Sun Jul 27 02:10:01 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 27 Jul 2025 02:10:01 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <plQyLGbgIzzw5_SCM_1YoVaQcjrA7pb6VTw6Xc3oAdc=.e16fb2b3-33f1-4bd5-9fc7-cd2b02ecdc0e@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
 <plQyLGbgIzzw5_SCM_1YoVaQcjrA7pb6VTw6Xc3oAdc=.e16fb2b3-33f1-4bd5-9fc7-cd2b02ecdc0e@github.com>
Message-ID: <5S_xXktLLlxi8Sz3xD39ZjYokKzhN1rZDj36BDN8GdQ=.0d298ab0-4a32-4343-a722-bbb5168e57cc@github.com>

On Sat, 26 Jul 2025 16:54:33 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename is_oom to emit_old_object_samples
>
> src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp line 563:
> 
>> 561:     LeakProfiler::emit_events(max_jlong, false, false);
>> 562:   } else {
>> 563:     EventShutdown e;
> 
> Do you know why EventShutDown is not always emitted?
> 
> Is it emitted from somewhere else, so we would get two events if we always emitted it here?
> 
> I know it was this way before your change, but I?d like to understand why. We may want to add another parameter or write a comment to explain the behavior.

We have two call path to emit `EventShutdown`.

In case of the most of OOM which triggers VM shutdown (e.g. OOM happend on the last non-daemon thread), `Threads::destroy_vm()` should be called, and `Jfr::on_vm_shutdown()` would be called via `before_exit` @ java.cpp .

`Threads::destroy_vm()` @ src/hotspot/share/runtime/threads.cpp

  EventShutdown e;
  if (e.should_commit()) {
    e.set_reason("No remaining non-daemon Java threads");
    e.commit();
  }

  // Hang forever on exit if we are reporting an error.
  if (ShowMessageBoxOnError && VMError::is_error_reported()) {
    os::infinite_sleep();
  }
  os::wait_for_keypress_at_exit();

  // run Java level shutdown hooks
  thread->invoke_shutdown_hooks();

  before_exit(thread);


In case of `exception_handler` - `VMError::report_and_die()` in this case - `EventShutdown` would be emitted at `post_events()`, however `LeakProfiler::emit_events()` would not be called.

I think both `EventShutdown` and LeakProfiler should be emitted when the crash happens due to `-XX:+CrashOnOutOfMemoryError`. So I will add another parameter to enforce to emit `EventShutdown` in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2233594799

From ysuenaga at openjdk.org  Sun Jul 27 10:02:40 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 27 Jul 2025 10:02:40 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add emit_event_shutdown

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/ee27149e..6cf417d8

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

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

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

From ysuenaga at openjdk.org  Sun Jul 27 10:02:40 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 27 Jul 2025 10:02:40 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v2]
In-Reply-To: <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <wmmW5qbEW6fw6mGIk-toKUllkllxCCG4SUSIkZEe18k=.cecdd26b-5720-4cb0-8451-d18fd80f0b9c@github.com>
Message-ID: <ZwuazYZEwNkLRvYQZoYWScch6KtpGWMvTIqI2c-wR2Q=.db456071-3b01-45e6-9b2c-9b034681d649@github.com>

On Sat, 26 Jul 2025 02:16:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename is_oom to emit_old_object_samples

@egahlin 
I added new parameter `emit_event_shutdown` to emit `EventShutdown` in new commit. This change does not change current behavior, and it passed `jdk_jfr` test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3124275944

From stuefe at openjdk.org  Mon Jul 28 07:09:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Jul 2025 07:09:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
Message-ID: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>

On Sun, 27 Jul 2025 10:02:40 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add emit_event_shutdown

Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

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

PR Review: https://git.openjdk.org/jdk/pull/26468#pullrequestreview-3060786131

From egahlin at openjdk.org  Mon Jul 28 08:57:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 28 Jul 2025 08:57:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
Message-ID: <lrozX0_OMkpUOjJVYwqPDKY6GaBpzgwaPvNZYx03dXw=.e9de80fc-50f8-439c-900b-fd62d48b80db@github.com>

On Mon, 28 Jul 2025 07:06:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

It might be better to have a test in test/jdk/jdk/jfr/jvm/, where we have other crash tests.

It's probably best to create a separate test for this, as checking for OOM can be flaky, and it may need to be added to the ProblemList separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3126226149

From mgronlun at openjdk.org  Mon Jul 28 11:06:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 28 Jul 2025 11:06:10 GMT
Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v3]
In-Reply-To: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
References: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
Message-ID: <aW4BpGYmOXNoFdqqpmmD0mQA0pWX9w1LJegeoEBr-ko=.ef7848c1-f4de-45dc-a58c-a409dcd29716@github.com>

> Greetings,
> 
> The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method".
> 
> It involves three components:
> 
> 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll().
> 
> 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint.
> 
> 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method.
> 
> There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem.
> 
> Testing: jdk_jfr, stress testing
> 
> Thank you
> Markus

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

  improved predicate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26458/files
  - new: https://git.openjdk.org/jdk/pull/26458/files/a4d6ecc3..933a2261

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

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

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

From ysuenaga at openjdk.org  Mon Jul 28 12:02:47 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 28 Jul 2025 12:02:47 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/6cf417d8..5ecd4e43

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

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

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

From ysuenaga at openjdk.org  Mon Jul 28 12:07:55 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 28 Jul 2025 12:07:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
Message-ID: <1vsjp_sMv3syJEfZWC-yp0mGUwkPyaCfEuL7QKqO0Zw=.7ad75bf3-b257-4fb5-a700-f08bce99a3aa@github.com>

On Mon, 28 Jul 2025 07:06:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add emit_event_shutdown
>
> Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

@tstuefe @egahlin 

Thanks for your review and advice!
I added testcase in `test/jdk/jdk/jfr/event/oldobject` because this change is not only crash handler. `before_exit()` calls if OOM happens without `CrashOnOutOfMemoryError`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3126917501

From jbechberger at openjdk.org  Mon Jul 28 13:55:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 28 Jul 2025 13:55:27 GMT
Subject: RFR: 8359690: New test TestCPUTimeSampleThrottling still fails
 intermittently
Message-ID: <Nwsdm_u3PFMLhimdtQxnEGW90ny9D-Aleyvkyrihwz8=.c0c2f304-896e-4bf6-8978-d5f06f20f0cb@github.com>

This change fixes the issue by making the test independent of the system load.

Tested both with high and low load.

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

Commit messages:
 - Make TestCPUTimeSampleThrottling machine load independent

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

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

From jbechberger at openjdk.org  Mon Jul 28 14:15:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 28 Jul 2025 14:15:56 GMT
Subject: RFR: 8359690: New test TestCPUTimeSampleThrottling still fails
 intermittently
In-Reply-To: <Nwsdm_u3PFMLhimdtQxnEGW90ny9D-Aleyvkyrihwz8=.c0c2f304-896e-4bf6-8978-d5f06f20f0cb@github.com>
References: <Nwsdm_u3PFMLhimdtQxnEGW90ny9D-Aleyvkyrihwz8=.c0c2f304-896e-4bf6-8978-d5f06f20f0cb@github.com>
Message-ID: <1F_Q_LJmoxqwhtKy0XgOoIpH59WdOzQTleGcU_0xYwI=.b519f39c-3c73-4464-9026-0cd7e6893b32@github.com>

On Mon, 28 Jul 2025 13:49:24 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This change fixes the issue by making the test independent of the system load.
> 
> Tested both with high and low load.

We're waiting for the test to be successful in our internal queue over a few days.

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

PR Comment: https://git.openjdk.org/jdk/pull/26506#issuecomment-3127433180

From mgronlun at openjdk.org  Mon Jul 28 14:49:32 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 28 Jul 2025 14:49:32 GMT
Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v4]
In-Reply-To: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
References: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
Message-ID: <54d5GvjbJF3AXWowzkFC4HF11OFyHl3Dw41LpKE7ng4=.87fab246-f64a-4d0f-a62e-4314298065a5@github.com>

> Greetings,
> 
> The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method".
> 
> It involves three components:
> 
> 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll().
> 
> 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint.
> 
> 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method.
> 
> There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem.
> 
> Testing: jdk_jfr, stress testing
> 
> Thank you
> Markus

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

  always use new_methods length

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26458/files
  - new: https://git.openjdk.org/jdk/pull/26458/files/933a2261..e68e9f3c

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

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

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

From mgronlun at openjdk.org  Mon Jul 28 14:53:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 28 Jul 2025 14:53:34 GMT
Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v5]
In-Reply-To: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
References: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
Message-ID: <yTBDD-g_X8nCvADFzl_Ep3c4D6_Vv90J_tQ7UgyIQmg=.eb9a2b10-2c30-4605-bf90-958a7bdf17e7@github.com>

> Greetings,
> 
> The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method".
> 
> It involves three components:
> 
> 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll().
> 
> 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint.
> 
> 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method.
> 
> There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem.
> 
> Testing: jdk_jfr, stress testing
> 
> Thank you
> Markus

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

  removed unused

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26458/files
  - new: https://git.openjdk.org/jdk/pull/26458/files/e68e9f3c..6504e1b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=03-04

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

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

From egahlin at openjdk.org  Mon Jul 28 15:06:57 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 28 Jul 2025 15:06:57 GMT
Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v5]
In-Reply-To: <yTBDD-g_X8nCvADFzl_Ep3c4D6_Vv90J_tQ7UgyIQmg=.eb9a2b10-2c30-4605-bf90-958a7bdf17e7@github.com>
References: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
 <yTBDD-g_X8nCvADFzl_Ep3c4D6_Vv90J_tQ7UgyIQmg=.eb9a2b10-2c30-4605-bf90-958a7bdf17e7@github.com>
Message-ID: <WVA_HcOGPf7axDzOWgeGfzqYTIRhT9VOGRjP1qlEhv8=.50c66231-e9c3-4fea-9b99-57797c9e28ef@github.com>

On Mon, 28 Jul 2025 14:53:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method".
>> 
>> It involves three components:
>> 
>> 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll().
>> 
>> 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint.
>> 
>> 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method.
>> 
>> There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem.
>> 
>> Testing: jdk_jfr, stress testing
>> 
>> Thank you
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26458#pullrequestreview-3063256275

From egahlin at openjdk.org  Mon Jul 28 16:54:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 28 Jul 2025 16:54:00 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
Message-ID: <57dGQ-9eyRIov26Zl2Sr7I_Y02LOfz4Q_t0yLg0JZs0=.9c716d30-419d-4e8a-908d-9034101a69f0@github.com>

On Mon, 28 Jul 2025 07:06:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add emit_event_shutdown
>
> Looks reasonable to me. But could you please add a simple regression test? Easiest would be to modify TestCrashOnOutOfMemoryError.java - add a second `@test ` section, start the test with a different parameter that signals that you run the testee with JFR enabled, and then test for existence of the JFR dump.

> @tstuefe @egahlin
> 
> Thanks for your review and advice! I added testcase in `test/jdk/jdk/jfr/event/oldobject` because this change is not only crash handler. `before_exit()` calls if OOM happens without `CrashOnOutOfMemoryError`.

Does it also happen with -XX:ExitOnOutOfMemoryError?

I'm not sure we want that. Most users, I think, want a quick exit if they have specified that option. They are not interested in having the Java heap swept to find memory leak candidates.

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

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3128128908

From ysuenaga at openjdk.org  Mon Jul 28 23:58:44 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 28 Jul 2025 23:58:44 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v3]
In-Reply-To: <57dGQ-9eyRIov26Zl2Sr7I_Y02LOfz4Q_t0yLg0JZs0=.9c716d30-419d-4e8a-908d-9034101a69f0@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <97jBLwsHF-xFprYjUBV98Fs-wQykqeNRImROOPv16Fs=.01c9a71e-2bcc-45de-b62b-df417746b50c@github.com>
 <6vm9cD9kEJte9HyPshXBzAeyEbXsqzhG5NYPkIVMwws=.515072b2-c9e2-4433-b718-c6c7943a99de@github.com>
 <57dGQ-9eyRIov26Zl2Sr7I_Y02LOfz4Q_t0yLg0JZs0=.9c716d30-419d-4e8a-908d-9034101a69f0@github.com>
Message-ID: <eZx0id3f9UllTaK9T4AcxbreJzUn-4QNudElMvKFegU=.ec0638fe-324d-4854-9cbf-112155a98e38@github.com>

On Mon, 28 Jul 2025 16:51:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Does it also happen with -XX:ExitOnOutOfMemoryError?

No.
This change affects `CrashOnOutOutOfMemoryError`, but this does not change `ExitOnOutOfMemoryError` behavior. VM would shutdown immediately without emergency dump if OOM happened when the user adds `ExitOnOutOfMemoryError`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3130151589

From stuefe at openjdk.org  Tue Jul 29 06:23:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Jul 2025 06:23:57 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
Message-ID: <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>

On Mon, 28 Jul 2025 12:02:47 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add testcase

Looks good to me, provided Erik is happy.

test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java line 70:

> 68:         var p = ProcessTools.createTestJavaProcessBuilder(args).start();
> 69:         p.waitFor();
> 70:         var output = new OutputAnalyzer(p);

I'm not a big fan of var, since it degrades the readability. I like to know which types I deal with when reading code.

Not sure what others think, though, or if there is a Java style guideline similar to our hotspot style guide.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26468#pullrequestreview-3065672936
PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2238651593

From mgronlun at openjdk.org  Tue Jul 29 09:58:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Jul 2025 09:58:01 GMT
Subject: Integrated: 8356587: Missing object ID X in pool jdk.types.Method
In-Reply-To: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
References: <ebxYpmgGOiM3YE39JMyC5bKREqlq7Fxj8w7vt9vjmJo=.e3d622a3-a72d-4cf1-a62a-60f644698d73@github.com>
Message-ID: <3wd4ZmTVQzjgPIwmzQcfo1OxMsJ7BHVEV99IKJdwBfI=.5438c472-f3d0-4152-bf90-c115d57a13f4@github.com>

On Thu, 24 Jul 2025 12:49:36 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method".
> 
> It involves three components:
> 
> 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll().
> 
> 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint.
> 
> 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method.
> 
> There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem.
> 
> Testing: jdk_jfr, stress testing
> 
> Thank you
> Markus

This pull request has now been integrated.

Changeset: a3499447
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a34994476e8f4783c9f5a83a9c3db63ad605b323
Stats:     303 lines in 24 files changed: 129 ins; 101 del; 73 mod

8356587: Missing object ID X in pool jdk.types.Method

Reviewed-by: egahlin

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

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

From mgronlun at openjdk.org  Tue Jul 29 10:04:29 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Jul 2025 10:04:29 GMT
Subject: [jdk25] RFR: 8356587: Missing object ID X in pool jdk.types.Method
Message-ID: <HmHolamYS0zyqbT58OEO67WecgRDv7z2ColDZQQyDGk=.bb0fc922-1c16-4de8-82e4-2b4ade9313b3@github.com>

8356587: Missing object ID X in pool jdk.types.Method

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

Commit messages:
 - Backport a34994476e8f4783c9f5a83a9c3db63ad605b323

Changes: https://git.openjdk.org/jdk/pull/26529/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26529&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356587
  Stats: 303 lines in 24 files changed: 129 ins; 101 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/26529.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26529/head:pull/26529

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

From egahlin at openjdk.org  Tue Jul 29 10:07:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 10:07:54 GMT
Subject: [jdk25] RFR: 8356587: Missing object ID X in pool jdk.types.Method
In-Reply-To: <HmHolamYS0zyqbT58OEO67WecgRDv7z2ColDZQQyDGk=.bb0fc922-1c16-4de8-82e4-2b4ade9313b3@github.com>
References: <HmHolamYS0zyqbT58OEO67WecgRDv7z2ColDZQQyDGk=.bb0fc922-1c16-4de8-82e4-2b4ade9313b3@github.com>
Message-ID: <PI0zxS2Ft-6_3kASB9a2J2rHp6cWSFf4pBygwbLZmig=.78b99f0a-3383-473c-9a9d-5419a381e969@github.com>

On Tue, 29 Jul 2025 09:56:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8356587: Missing object ID X in pool jdk.types.Method

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26529#pullrequestreview-3066684022

From egahlin at openjdk.org  Tue Jul 29 11:05:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 11:05:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
Message-ID: <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>

On Tue, 29 Jul 2025 06:20:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add testcase
>
> test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java line 70:
> 
>> 68:         var p = ProcessTools.createTestJavaProcessBuilder(args).start();
>> 69:         p.waitFor();
>> 70:         var output = new OutputAnalyzer(p);
> 
> I'm not a big fan of var, since it degrades the readability. I like to know which types I deal with when reading code.
> 
> Not sure what others think, though, or if there is a Java style guideline similar to our hotspot style guide.

I'm going to run some testing before approving. 

I don't have a strong opinion on var, but Stuart Marks wrote about when to use it a few years ago:
https://openjdk.org/projects/amber/guides/lvti-style-guide

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2239410134

From mgronlun at openjdk.org  Tue Jul 29 11:44:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Jul 2025 11:44:01 GMT
Subject: [jdk25] Integrated: 8356587: Missing object ID X in pool
 jdk.types.Method
In-Reply-To: <HmHolamYS0zyqbT58OEO67WecgRDv7z2ColDZQQyDGk=.bb0fc922-1c16-4de8-82e4-2b4ade9313b3@github.com>
References: <HmHolamYS0zyqbT58OEO67WecgRDv7z2ColDZQQyDGk=.bb0fc922-1c16-4de8-82e4-2b4ade9313b3@github.com>
Message-ID: <nYEqK0VKywkXvZ4sH2Nz7IAJrmhd_QsZ0Ai3POYRq2c=.bae91c7f-6705-462a-b89c-59515afb08b5@github.com>

On Tue, 29 Jul 2025 09:56:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8356587: Missing object ID X in pool jdk.types.Method

This pull request has now been integrated.

Changeset: 9fe2aa59
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fe2aa59ffde71879eeee5cfa10919468c253b34
Stats:     303 lines in 24 files changed: 129 ins; 101 del; 73 mod

8356587: Missing object ID X in pool jdk.types.Method

Reviewed-by: egahlin
Backport-of: a34994476e8f4783c9f5a83a9c3db63ad605b323

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

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

From egahlin at openjdk.org  Tue Jul 29 15:31:32 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 15:31:32 GMT
Subject: RFR: 8364257: JFR: User-defined events and settings with a one-letter
 name cannot be configured
Message-ID: <VWi3VMollVoZ0BKH1nhlX9j--bd0ud13tkhgSmfzbXU=.c749052d-8dee-44c6-9d0d-eb6d777d58ad@github.com>

Could I have a review of the PR that fixes a bug with short event or setting names? Instead of adding a new test, I modified an existing test so that it uses an event and setting name with one letter.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From egahlin at openjdk.org  Tue Jul 29 20:15:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 20:15:55 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
Message-ID: <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>

On Tue, 29 Jul 2025 11:02:59 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java line 70:
>> 
>>> 68:         var p = ProcessTools.createTestJavaProcessBuilder(args).start();
>>> 69:         p.waitFor();
>>> 70:         var output = new OutputAnalyzer(p);
>> 
>> I'm not a big fan of var, since it degrades the readability. I like to know which types I deal with when reading code.
>> 
>> Not sure what others think, though, or if there is a Java style guideline similar to our hotspot style guide.
>
> I'm going to run some testing before approving. 
> 
> I don't have a strong opinion on var, but Stuart Marks wrote about when to use it a few years ago:
> https://openjdk.org/projects/amber/guides/lvti-style-guide

I get the following failure when testing your change:

`----------System.err:(15/955)----------
java.lang.RuntimeException: assertGreaterThan: expected 0 > 0
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:386)
	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.test(TestEmergencyDumpAtOOM.java:104)
	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.main(TestEmergencyDumpAtOOM.java:109)
	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)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2240881106

From egahlin at openjdk.org  Tue Jul 29 20:35:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 20:35:54 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
Message-ID: <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>

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

>> I'm going to run some testing before approving. 
>> 
>> I don't have a strong opinion on var, but Stuart Marks wrote about when to use it a few years ago:
>> https://openjdk.org/projects/amber/guides/lvti-style-guide
>
> I get the following failure when testing your change:
> 
> `----------System.err:(15/955)----------
> java.lang.RuntimeException: assertGreaterThan: expected 0 > 0
> 	at jdk.test.lib.Asserts.fail(Asserts.java:715)
> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:386)
> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.test(TestEmergencyDumpAtOOM.java:104)
> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.main(TestEmergencyDumpAtOOM.java:109)
> 	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)` 
> 	
> 	
> It is hard to guarantee a memory-leak sample. Other tests for OldObjectSample run in a loop until they succeed.
> 
> In the test, you use path-to-gc-roots=true. Is that really needed?

Using an EventStream might simplify the filtering, e.g.

        AtomicLong oldObjects = new AtomicLong();
        AtomicReference<String> reason = new AtomicReference<>();
        try (EventStream stream = EventStream.openFile(...)) {
            stream.onEvent("jdk.Shutdown", e -> reason.set(e.getString("reason")));
            stream.onEvent("jdk.OldObjectSample", e -> oldObjects.incrementAndGet());
            stream.start();
        }
        if (shouldCrash) {
            // validation
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2240950420

From egahlin at openjdk.org  Tue Jul 29 21:06:20 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 21:06:20 GMT
Subject: RFR: 8364190: JFR: RemoteRecordingStream withers don't work
Message-ID: <1YtQvtGf1jFNo9abBo1P0zdyctI1EeSN15WazrXX0EM=.0863ddfc-9384-472a-b996-40b1021bc71a@github.com>

Could I please have a review of a PR that fixes the RemoteRecordingStream::with-methods?

Testing: test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/26540/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364190
  Stats: 151 lines in 3 files changed: 143 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26540/head:pull/26540

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

From egahlin at openjdk.org  Tue Jul 29 21:06:38 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Jul 2025 21:06:38 GMT
Subject: RFR: 8364316: JFR: Incorrect validation of mirror fields
Message-ID: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>

Could I please have a review of a PR that fixes a bug in the mirror field validation?

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From ysuenaga at openjdk.org  Wed Jul 30 05:16:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 05:16:42 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v5]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <TpROAmt5YuMtjVkKwByrfvVcZn309l6pQd-jlZ1bbBc=.2e5a5922-5e2f-4bd5-8eb2-45e62326a0cb@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update TestEmergencyDumpAtOOM.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/5ecd4e43..a20d56a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=03-04

  Stats: 58 lines in 1 file changed: 22 ins; 11 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26468/head:pull/26468

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

From ysuenaga at openjdk.org  Wed Jul 30 05:16:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 05:16:42 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
 <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
Message-ID: <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>

On Tue, 29 Jul 2025 20:33:43 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I get the following failure when testing your change:
>> 
>> `----------System.err:(15/955)----------
>> java.lang.RuntimeException: assertGreaterThan: expected 0 > 0
>> 	at jdk.test.lib.Asserts.fail(Asserts.java:715)
>> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:403)
>> 	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:386)
>> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.test(TestEmergencyDumpAtOOM.java:104)
>> 	at jdk.jfr.event.oldobject.TestEmergencyDumpAtOOM.main(TestEmergencyDumpAtOOM.java:109)
>> 	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)` 
>> 	
>> 	
>> It is hard to guarantee a memory-leak sample. Other tests for OldObjectSample run in a loop until they succeed.
>> 
>> In the test, you use path-to-gc-roots=true. Is that really needed?
>
> Using an EventStream might simplify the filtering, e.g.
> 
>         AtomicLong oldObjects = new AtomicLong();
>         AtomicReference<String> reason = new AtomicReference<>();
>         try (EventStream stream = EventStream.openFile(...)) {
>             stream.onEvent("jdk.Shutdown", e -> reason.set(e.getString("reason")));
>             stream.onEvent("jdk.OldObjectSample", e -> oldObjects.incrementAndGet());
>             stream.start();
>         }
>         if (shouldCrash) {
>             // validation
>         }

I updated the test. I hope it works on your environment.

- Revise JVM option for the test process (`-Xmx` and `-XX:TLABSize` are copied from TestClassLoaderLeak.java)
- Use `EventStream` to check JFR events as Erik shown
- Repeat the test if `OldObjectSample` does not appear on the flight record
- Remove `var` from test code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2241548770

From egahlin at openjdk.org  Wed Jul 30 07:15:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 30 Jul 2025 07:15:56 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
 <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
 <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>
Message-ID: <wKg8UB2TeSHByzcuMqWI3DJFSOaTlgX0W2OPfFCKFX4=.1d4bdd85-bec9-47c8-8009-d93bb1b06130@github.com>

On Wed, 30 Jul 2025 05:13:42 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Using an EventStream might simplify the filtering, e.g.
>> 
>>         AtomicLong oldObjects = new AtomicLong();
>>         AtomicReference<String> reason = new AtomicReference<>();
>>         try (EventStream stream = EventStream.openFile(...)) {
>>             stream.onEvent("jdk.Shutdown", e -> reason.set(e.getString("reason")));
>>             stream.onEvent("jdk.OldObjectSample", e -> oldObjects.incrementAndGet());
>>             stream.start();
>>         }
>>         if (shouldCrash) {
>>             // validation
>>         }
>
> I updated the test. I hope it works on your environment.
> 
> - Revise JVM option for the test process (`-Xmx` and `-XX:TLABSize` are copied from TestClassLoaderLeak.java)
> - Use `EventStream` to check JFR events as Erik shown
> - Repeat the test if `OldObjectSample` does not appear on the flight record
> - Remove `var` from test code

I will try running it. I think readability can be improved if everything under shouldCrash is grouped together, e.g.


if (oldObjects.get() > 0L) {
    if (shouldCrash) {
        Asserts.assertEquals("VM Error", shutdownReason.get());
        Asserts.assertEquals("Out of Memory", dumpReason.get());
    } else {
        Asserts.assertEquals("No remaining non-daemon Java threads", shutdownReason.get());
    }
    return;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2241742584

From shade at openjdk.org  Wed Jul 30 08:30:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Jul 2025 08:30:53 GMT
Subject: RFR: 8364316: JFR: Incorrect validation of mirror fields
In-Reply-To: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>
References: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>
Message-ID: <h5Txph9TYd0Q_k25Q4iQLYyBXU0bH0e9AoVWfPq5tXc=.e8bd0d79-b2ea-4408-a6fd-a56e507aee74@github.com>

On Tue, 29 Jul 2025 20:50:33 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I please have a review of a PR that fixes a bug in the mirror field validation?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Looks reasonable. 

There might be another quirk in this code: fields of the same name can be hidden, so verification would miss that? See:


jshell> class C1 { int x;}
|  created class C1

jshell> class C2 extends C1 { int x;}
|  created class C2

jshell> Class cMirror = C2.class;
   ...> while (cMirror != Object.class) {
   ...>     System.out.println(cMirror.getDeclaredField("x").getName());
   ...>     cMirror = cMirror.getSuperclass();
   ...> }
cMirror ==> class C2
x
x

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26539#pullrequestreview-3070412524

From ysuenaga at openjdk.org  Wed Jul 30 08:37:37 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 08:37:37 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v6]
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Refactor TestEmergencyDumpAtOOM.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26468/files
  - new: https://git.openjdk.org/jdk/pull/26468/files/a20d56a7..544e7415

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26468&range=04-05

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

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

From ysuenaga at openjdk.org  Wed Jul 30 08:37:38 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 30 Jul 2025 08:37:38 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v4]
In-Reply-To: <wKg8UB2TeSHByzcuMqWI3DJFSOaTlgX0W2OPfFCKFX4=.1d4bdd85-bec9-47c8-8009-d93bb1b06130@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <gsJ7LeLZcSmUvSekRTfb0qFRFCZKHAOvgVfiDkBdsCA=.b0fb018b-ff4c-4863-942e-e38b3b62a945@github.com>
 <B4-LTyfKa6qbPs-waSkqrJtCCqvblsjpANgxNx7oMwk=.3cd78504-ce15-4590-92f5-b0fa9c81b360@github.com>
 <s2MYhhwdI63XkiHZIhEVOk1vy-p3ZCqj9_1S0tG38HU=.b8133175-35a0-4036-a5aa-a14f2111e9de@github.com>
 <69zRx_1ST1bBDwOOJ8v4lmqIirFvZxGr1wNBkAqi75g=.78605a3d-069b-4144-be59-5dfedfe3d18d@github.com>
 <6T1dCi7zMvzWEM5qf9sOwM0WxDjjteaZzVI-R4zmMzM=.f0bcb37c-df3c-4f2a-b2b8-b76c42772b99@github.com>
 <p2Wq587NybXNgR1BknNutoXlYClv0BEmTx184Mm8tyg=.6166050c-d947-4d97-b79b-64436cd67b0f@github.com>
 <wKg8UB2TeSHByzcuMqWI3DJFSOaTlgX0W2OPfFCKFX4=.1d4bdd85-bec9-47c8-8009-d93bb1b06130@github.com>
Message-ID: <o9cLr1LllrJGGgEQytVd5cQXriHScAwtWMRO8sNJpYY=.f06c7b4d-8771-4015-b2a2-0b5148f80720@github.com>

On Wed, 30 Jul 2025 07:13:38 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I updated the test. I hope it works on your environment.
>> 
>> - Revise JVM option for the test process (`-Xmx` and `-XX:TLABSize` are copied from TestClassLoaderLeak.java)
>> - Use `EventStream` to check JFR events as Erik shown
>> - Repeat the test if `OldObjectSample` does not appear on the flight record
>> - Remove `var` from test code
>
> I will try running it. I think readability can be improved if everything under shouldCrash is grouped together, e.g.
> 
> 
> if (oldObjects.get() > 0L) {
>     if (shouldCrash) {
>         Asserts.assertEquals("VM Error", shutdownReason);
>         Asserts.assertEquals("Out of Memory", dumpReason);
>     } else {
>         Asserts.assertEquals("No remaining non-daemon Java threads", shutdownReason);
>     }
>     return;
> }

@egahlin 
I updated testcase as you shown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26468#discussion_r2241927247

From mgronlun at openjdk.org  Wed Jul 30 17:09:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Jul 2025 17:09:17 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v2]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <v_WEdYeLYChULtHXf9t-aYyFsc_IUK-9B9DzIrPJ4wE=.a29a5f14-e736-43dc-8f34-7653ec29db53@github.com>

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  const Handle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/cec818ab..8c025caf

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

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

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

From dchuyko at openjdk.org  Wed Jul 30 19:21:53 2025
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 30 Jul 2025 19:21:53 GMT
Subject: RFR: 8364190: JFR: RemoteRecordingStream withers don't work
In-Reply-To: <1YtQvtGf1jFNo9abBo1P0zdyctI1EeSN15WazrXX0EM=.0863ddfc-9384-472a-b996-40b1021bc71a@github.com>
References: <1YtQvtGf1jFNo9abBo1P0zdyctI1EeSN15WazrXX0EM=.0863ddfc-9384-472a-b996-40b1021bc71a@github.com>
Message-ID: <dAxjTqA11DsRDr1F5BL87H5PNYAly9S_oLWAMubZ9Z0=.d072eecd-fe47-4c54-9859-77599ea5649d@github.com>

On Tue, 29 Jul 2025 20:59:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I please have a review of a PR that fixes the RemoteRecordingStream::with-methods?
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik, thanks for the quick fix. Not a reviewer, but looks good (just like expected) and fixes the cases we spotted.

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

PR Comment: https://git.openjdk.org/jdk/pull/26540#issuecomment-3137550201

From egahlin at openjdk.org  Wed Jul 30 22:00:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 30 Jul 2025 22:00:00 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v6]
In-Reply-To: <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
Message-ID: <Y68Yi8w_oLj1i2vrOF_uns1F_3MsucfNdXi98KrzNgI=.9b45a313-c2a8-44e4-b3f8-741c1b8339de@github.com>

On Wed, 30 Jul 2025 08:37:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor TestEmergencyDumpAtOOM.java

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26468#pullrequestreview-3073440975

From egahlin at openjdk.org  Thu Jul 31 08:49:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 31 Jul 2025 08:49:10 GMT
Subject: RFR: 8364316: JFR: Incorrect validation of mirror fields [v2]
In-Reply-To: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>
References: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>
Message-ID: <lEYgjby0ig0xAstsAU1SKHAQt0BxpZ6AGYfmzmUGiGk=.eae22b5e-26ef-4108-a316-46edd12185e5@github.com>

> Could I please have a review of a PR that fixes a bug in the mirror field validation?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Simplify field discovery

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26539/files
  - new: https://git.openjdk.org/jdk/pull/26539/files/75be1d4a..2947c54a

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

  Stats: 58 lines in 3 files changed: 5 ins; 33 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/26539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26539/head:pull/26539

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

From egahlin at openjdk.org  Thu Jul 31 08:53:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 31 Jul 2025 08:53:54 GMT
Subject: RFR: 8364316: JFR: Incorrect validation of mirror fields [v2]
In-Reply-To: <h5Txph9TYd0Q_k25Q4iQLYyBXU0bH0e9AoVWfPq5tXc=.e8bd0d79-b2ea-4408-a6fd-a56e507aee74@github.com>
References: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>
 <h5Txph9TYd0Q_k25Q4iQLYyBXU0bH0e9AoVWfPq5tXc=.e8bd0d79-b2ea-4408-a6fd-a56e507aee74@github.com>
Message-ID: <Q-ybDQZWZ11CG2zPmC9BjCYgt13NkT5USgbb1VXxgys=.2b14331d-1b37-4c14-bc54-7b69c12a2f03@github.com>

On Wed, 30 Jul 2025 08:28:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> 
> There might be another quirk in this code: fields of the same name can be hidden, so verification would miss that? 
> 

I don't think mirror events can be made to work with a class hierarchy (due to shadowing), and there is no need to, since their only purpose is to provide metadata for events defined in java.base (which cannot depend on the jdk.jfr module).

It's fine to have all the metadata directly in the mirror event class.

So, I simplified the traversal code and, at the same time, realized we should not duplicate the logic used to discover which event fields should be included. Now there is only one method, Utils.getEventFields(...), handling this.

The reason I could remove the synthetic check in verifyMirror is that its only purpose was to exclude the startTime and duration fields in the jdk.internal.Event class. The traversal stops before that class is reached, so it's not an issue.

I understand this may be more to review than you are willing to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/26539#issuecomment-3139086362

From shade at openjdk.org  Thu Jul 31 10:03:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 31 Jul 2025 10:03:54 GMT
Subject: RFR: 8364316: JFR: Incorrect validation of mirror fields [v2]
In-Reply-To: <lEYgjby0ig0xAstsAU1SKHAQt0BxpZ6AGYfmzmUGiGk=.eae22b5e-26ef-4108-a316-46edd12185e5@github.com>
References: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>
 <lEYgjby0ig0xAstsAU1SKHAQt0BxpZ6AGYfmzmUGiGk=.eae22b5e-26ef-4108-a316-46edd12185e5@github.com>
Message-ID: <oiUEvFIv1ZVYZS0rjcoow67BwOCi8rg_gWyBPp5PAAc=.174d5c55-9a92-4f3a-a2f5-fd7fe012b9bd@github.com>

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

>> Could I please have a review of a PR that fixes a bug in the mirror field validation?
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify field discovery

This looks reasonable as well, as long as it verifies what you want to verify :)

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26539#pullrequestreview-3074751702

From ysuenaga at openjdk.org  Thu Jul 31 12:15:04 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 31 Jul 2025 12:15:04 GMT
Subject: RFR: 8364090: Dump JFR recording on CrashOnOutOfMemoryError [v6]
In-Reply-To: <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
 <4rim7uurP5UaxZDO4dFZFtxwdSVwVTgnsRIiAd_R85M=.278377d3-ef1c-4419-aea9-fe14379afa4e@github.com>
Message-ID: <9dokJoeOWAcNlek3IhCDR9X74wo4o6Q_uKbPaCNAWqc=.6354d8af-ea6d-4670-9f69-30d61537b3b5@github.com>

On Wed, 30 Jul 2025 08:37:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
>> 
>> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
>> 
>> So I propose again to emit the events from LeakProfiler when OOM happened.
>> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
>> 
>> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor TestEmergencyDumpAtOOM.java

Thanks Erik and Thomas for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26468#issuecomment-3139710043

From ysuenaga at openjdk.org  Thu Jul 31 12:15:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 31 Jul 2025 12:15:06 GMT
Subject: Integrated: 8364090: Dump JFR recording on CrashOnOutOfMemoryError
In-Reply-To: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
References: <7EwD0uqgvXEex48MoWfiJCzESSBr_eE0WaCkmv1DLdA=.febcf597-b09d-4408-87b7-4b7b70a900b8@github.com>
Message-ID: <l3AbBZZnIhD8-lXLWMGaA1hT0duTsXhSwn-h-oFVAts=.4fc42111-82aa-4bc1-86b9-46533be0d147@github.com>

On Fri, 25 Jul 2025 00:52:29 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> JFR emergency dump would happen when OOM was thrown. However it would not contain most recent `OldObjectSample` events emitted by LeakProfiler.
> 
> I [reported this issue in past](https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html), and it seems to be difficult to fix soon, and also JDK codebase has been updated in several years. It brings us to fix this issue easier than past.
> 
> So I propose again to emit the events from LeakProfiler when OOM happened.
> This change passed `jdk_jfr` tests on Linux x64 (excepts TestHeapSummaryEventPSParOld.java reported in [JDK-8364082](https://bugs.openjdk.org/browse/JDK-8364082))
> 
> Related email thread: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2025-July/008007.html

This pull request has now been integrated.

Changeset: 8ed214f3
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ed214f3b1864ea0095d05497f782ce4131836d4
Stats:     138 lines in 7 files changed: 123 ins; 3 del; 12 mod

8364090: Dump JFR recording on CrashOnOutOfMemoryError

Reviewed-by: egahlin, stuefe

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

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

From egahlin at openjdk.org  Thu Jul 31 12:33:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 31 Jul 2025 12:33:42 GMT
Subject: RFR: 8364427: JFR: Possible resource leak in Recording::getStream
Message-ID: <BwpUP8ApWTCRYNVNSLv7CYD_dxMZ9s7qY9YJgb7DCvg=.024a4201-56b2-4f17-9afe-d1d6742f5464@github.com>

Could I have a review of the PR that fixes resource leaks when Recording::getStream is used?

Testing: tier1 + test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Fix whitespace
 - Initial

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

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

From duke at openjdk.org  Thu Jul 31 13:01:56 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 13:01:56 GMT
Subject: RFR: 8364427: JFR: Possible resource leak in Recording::getStream
In-Reply-To: <BwpUP8ApWTCRYNVNSLv7CYD_dxMZ9s7qY9YJgb7DCvg=.024a4201-56b2-4f17-9afe-d1d6742f5464@github.com>
References: <BwpUP8ApWTCRYNVNSLv7CYD_dxMZ9s7qY9YJgb7DCvg=.024a4201-56b2-4f17-9afe-d1d6742f5464@github.com>
Message-ID: <5zFVlBKmP7LB1H98OoPnR6edjK2BZrz6ntiWFdJnReU=.51106e8b-4a44-4af6-93d1-0f18bb90686a@github.com>

On Thu, 31 Jul 2025 12:17:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the PR that fixes resource leaks when Recording::getStream is used?
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/ChunkInputStream.java line 69:

> 67:         while (nextChunk()) {
> 68:             try {
> 69:                 stream = new BufferedInputStream(Files.newInputStream(currentChunk.getFile()));

Should we close `stream` if it's not null?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26575#discussion_r2245321075

From egahlin at openjdk.org  Thu Jul 31 13:08:57 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 31 Jul 2025 13:08:57 GMT
Subject: RFR: 8364427: JFR: Possible resource leak in Recording::getStream
In-Reply-To: <5zFVlBKmP7LB1H98OoPnR6edjK2BZrz6ntiWFdJnReU=.51106e8b-4a44-4af6-93d1-0f18bb90686a@github.com>
References: <BwpUP8ApWTCRYNVNSLv7CYD_dxMZ9s7qY9YJgb7DCvg=.024a4201-56b2-4f17-9afe-d1d6742f5464@github.com>
 <5zFVlBKmP7LB1H98OoPnR6edjK2BZrz6ntiWFdJnReU=.51106e8b-4a44-4af6-93d1-0f18bb90686a@github.com>
Message-ID: <acR9hLTdJFV5Qs6BBvRlYnPgnXrlncdb2tlSYm06G8o=.4fc86c72-c734-4086-bfa1-db246aa781fe@github.com>

On Thu, 31 Jul 2025 12:59:10 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Could I have a review of the PR that fixes resource leaks when Recording::getStream is used?
>> 
>> Testing: tier1 + test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/ChunkInputStream.java line 69:
> 
>> 67:         while (nextChunk()) {
>> 68:             try {
>> 69:                 stream = new BufferedInputStream(Files.newInputStream(currentChunk.getFile()));
> 
> Should we close `stream` if it's not null?

Could you elaborate? 

There is closeStream method that is called when there is no more data to be read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26575#discussion_r2245341547

From duke at openjdk.org  Thu Jul 31 13:16:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 13:16:54 GMT
Subject: RFR: 8364427: JFR: Possible resource leak in Recording::getStream
In-Reply-To: <acR9hLTdJFV5Qs6BBvRlYnPgnXrlncdb2tlSYm06G8o=.4fc86c72-c734-4086-bfa1-db246aa781fe@github.com>
References: <BwpUP8ApWTCRYNVNSLv7CYD_dxMZ9s7qY9YJgb7DCvg=.024a4201-56b2-4f17-9afe-d1d6742f5464@github.com>
 <5zFVlBKmP7LB1H98OoPnR6edjK2BZrz6ntiWFdJnReU=.51106e8b-4a44-4af6-93d1-0f18bb90686a@github.com>
 <acR9hLTdJFV5Qs6BBvRlYnPgnXrlncdb2tlSYm06G8o=.4fc86c72-c734-4086-bfa1-db246aa781fe@github.com>
Message-ID: <l3HeKwXCv3zJmfgOUzBOtAhw7Ae8uE_TcTBwHVKv4CQ=.6cce98dd-84e5-4050-b60f-ba6460575fbf@github.com>

On Thu, 31 Jul 2025 13:05:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/ChunkInputStream.java line 69:
>> 
>>> 67:         while (nextChunk()) {
>>> 68:             try {
>>> 69:                 stream = new BufferedInputStream(Files.newInputStream(currentChunk.getFile()));
>> 
>> Should we close `stream` if it's not null?
>
> Could you elaborate? 
> 
> There is closeStream method that is called when there is no more data to be read.

If `nextChunk` returns `true` e.g. 2 times in a row, the second iteration of the while loop at L67 will overwrite `stream` without closing the previous instance. I don't see if/where `closeStream` will be called within two iterations of the loop, maybe I'm missing something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26575#discussion_r2245367507

From egahlin at openjdk.org  Thu Jul 31 13:39:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 31 Jul 2025 13:39:53 GMT
Subject: RFR: 8364427: JFR: Possible resource leak in Recording::getStream
In-Reply-To: <l3HeKwXCv3zJmfgOUzBOtAhw7Ae8uE_TcTBwHVKv4CQ=.6cce98dd-84e5-4050-b60f-ba6460575fbf@github.com>
References: <BwpUP8ApWTCRYNVNSLv7CYD_dxMZ9s7qY9YJgb7DCvg=.024a4201-56b2-4f17-9afe-d1d6742f5464@github.com>
 <5zFVlBKmP7LB1H98OoPnR6edjK2BZrz6ntiWFdJnReU=.51106e8b-4a44-4af6-93d1-0f18bb90686a@github.com>
 <acR9hLTdJFV5Qs6BBvRlYnPgnXrlncdb2tlSYm06G8o=.4fc86c72-c734-4086-bfa1-db246aa781fe@github.com>
 <l3HeKwXCv3zJmfgOUzBOtAhw7Ae8uE_TcTBwHVKv4CQ=.6cce98dd-84e5-4050-b60f-ba6460575fbf@github.com>
Message-ID: <VcaTLaJqT77T6HNMKjOqX1IqBqSE9lWykoffSihHwa0=.4116f236-b9c9-4312-899b-bac2c72dee46@github.com>

On Thu, 31 Jul 2025 13:13:53 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Could you elaborate? 
>> 
>> There is the closeStream method that is called when there is no more data to be read.
>
> If `nextChunk` returns `true` e.g. 2 times in a row, the second iteration of the while loop at L67 will overwrite `stream` without closing the previous instance. I don't see if/where `closeStream` will be called within two iterations of the loop, maybe I'm missing something?

I think it's closed by the read methods or close(). Just to be sure, I inserted:


+    if (this.stream != null) {
+      throw new InternalError("Should not happen");
+   }
    stream = new BufferedInputStream(Files.newInputStream(currentChunk.getFile()));


and ran all the tests without failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26575#discussion_r2245424612

From duke at openjdk.org  Thu Jul 31 13:39:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 13:39:54 GMT
Subject: RFR: 8364427: JFR: Possible resource leak in Recording::getStream
In-Reply-To: <VcaTLaJqT77T6HNMKjOqX1IqBqSE9lWykoffSihHwa0=.4116f236-b9c9-4312-899b-bac2c72dee46@github.com>
References: <BwpUP8ApWTCRYNVNSLv7CYD_dxMZ9s7qY9YJgb7DCvg=.024a4201-56b2-4f17-9afe-d1d6742f5464@github.com>
 <5zFVlBKmP7LB1H98OoPnR6edjK2BZrz6ntiWFdJnReU=.51106e8b-4a44-4af6-93d1-0f18bb90686a@github.com>
 <acR9hLTdJFV5Qs6BBvRlYnPgnXrlncdb2tlSYm06G8o=.4fc86c72-c734-4086-bfa1-db246aa781fe@github.com>
 <l3HeKwXCv3zJmfgOUzBOtAhw7Ae8uE_TcTBwHVKv4CQ=.6cce98dd-84e5-4050-b60f-ba6460575fbf@github.com>
 <VcaTLaJqT77T6HNMKjOqX1IqBqSE9lWykoffSihHwa0=.4116f236-b9c9-4312-899b-bac2c72dee46@github.com>
Message-ID: <SaasPsLQJbmCH2lDtXdgoTGFiiGCgSYkxoPM13o8hTI=.a7ff1754-f656-4938-8d72-abcf26967f08@github.com>

On Thu, 31 Jul 2025 13:35:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> If `nextChunk` returns `true` e.g. 2 times in a row, the second iteration of the while loop at L67 will overwrite `stream` without closing the previous instance. I don't see if/where `closeStream` will be called within two iterations of the loop, maybe I'm missing something?
>
> I think it's closed by the read methods or close(). Just to be sure, I inserted:
> 
> 
> +    if (this.stream != null) {
> +      throw new InternalError("Should not happen");
> +   }
>     stream = new BufferedInputStream(Files.newInputStream(currentChunk.getFile()));
> 
> 
> and ran all the tests without failure.

Thanks for the clarification

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26575#discussion_r2245429005

From mgronlun at openjdk.org  Thu Jul 31 18:24:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 18:24:38 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v3]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <VMC36hkBX9-11dKJ_ocSs2N4bVecaJrcyL5qir9B2gU=.7e6e556f-d857-419d-bcd8-77c62985cea8@github.com>

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  remove unused setter because of intrusive list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/8c025caf..3434343a

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

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

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

From mgronlun at openjdk.org  Thu Jul 31 18:59:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 18:59:55 GMT
Subject: RFR: 8364316: JFR: Incorrect validation of mirror fields [v2]
In-Reply-To: <lEYgjby0ig0xAstsAU1SKHAQt0BxpZ6AGYfmzmUGiGk=.eae22b5e-26ef-4108-a316-46edd12185e5@github.com>
References: <2Q9ZF_yZPfqfYRsbDMs4gJggYIQPG7ui3ck7IhdaLKg=.b8f4b3f3-1bb8-4d15-9f1a-ccc13c12e39c@github.com>
 <lEYgjby0ig0xAstsAU1SKHAQt0BxpZ6AGYfmzmUGiGk=.eae22b5e-26ef-4108-a316-46edd12185e5@github.com>
Message-ID: <HWSiUs_3jii_6H9ZT6-BPnbEkJyBGa-5sansPl5g-GM=.0fbfc9c0-6571-4d17-928f-e363907b6469@github.com>

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

>> Could I please have a review of a PR that fixes a bug in the mirror field validation?
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify field discovery

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26539#pullrequestreview-3076576532

From egahlin at openjdk.org  Thu Jul 31 19:32:05 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 31 Jul 2025 19:32:05 GMT
Subject: RFR: 8364461: JFR: Default constructor may not be first in setting
 control
Message-ID: <2SjUPyQaD3JzmnNE5snHZoDH0d0nhq7_cVbK0f5Ro6Y=.fb77b298-b5a2-47ba-b7b9-6ad4b956fee9@github.com>

Could I have a review of a PR that fixes a bug occurring when a user-defined setting does not have the default constructor first?

Test: test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Thu Jul 31 20:37:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 20:37:17 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v4]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <zDcom3nY_baiySxF1Wox7ADEO38CECUWN7TeiUEu_N0=.88faa7d4-5395-4c6a-8764-e36e7aaf48a6@github.com>

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  extend is_serialized scheme to JavaThreads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/3434343a..e973f67b

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

  Stats: 38 lines in 3 files changed: 29 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26558.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26558/head:pull/26558

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

From mgronlun at openjdk.org  Thu Jul 31 20:49:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 20:49:40 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v5]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <1v_-nvJ23wTH984L50yKDaB3Onuna27PnpBAST4U1s8=.0dd882ce-bf65-46a7-87f2-8214f6799d9f@github.com>

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  adjustment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/e973f67b..0691e4c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=03-04

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

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

From mgronlun at openjdk.org  Thu Jul 31 21:18:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Jul 2025 21:18:14 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v6]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <LAYJyPzZD7a9nCIFpHG9MKFQx_3ZUwBhf3wVuwuuDxI=.4dad1c72-163d-46f9-8b2d-54ad3eb149b3@github.com>

> Greetings,
> 
> The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file.
> 
> It does this in two parts:
> 
> 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier.
> 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations.
> 
> Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  minimal window

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/0691e4c5..c73a8f91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=04-05

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

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