From egahlin at openjdk.org  Fri Aug  1 15:24:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 1 Aug 2025 15:24:55 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v6]
In-Reply-To: <LAYJyPzZD7a9nCIFpHG9MKFQx_3ZUwBhf3wVuwuuDxI=.4dad1c72-163d-46f9-8b2d-54ad3eb149b3@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
 <LAYJyPzZD7a9nCIFpHG9MKFQx_3ZUwBhf3wVuwuuDxI=.4dad1c72-163d-46f9-8b2d-54ad3eb149b3@github.com>
Message-ID: <vRoLoFEWnPQlAhs9dtULW1CPHagvlv8MPmpea2dPE80=.b0e4254a-4ca5-44cf-a995-8ee0a0690d3a@github.com>

On Thu, 31 Jul 2025 21:18:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

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

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26558#pullrequestreview-3079642780

From mgronlun at openjdk.org  Fri Aug  1 17:11:46 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 17:11:46 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v7]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <RL0HEABjKoSMipI1YabLFVn1AHkPX1Lp5GHPFhC8oW0=.b7042043-53b5-4e0d-b8ac-9376402cab99@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:

  handle no thread groups found

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

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

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Fri Aug  1 17:45:29 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 17:45:29 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v8]
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <llseRg_mbneeq4FuTVX2co5AWueZlv-kr1AO7wiI0og=.7edff125-24cd-44ce-9a6b-b3de11272d4a@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:

  do not attempt to serialize a null thread group

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26558/files
  - new: https://git.openjdk.org/jdk/pull/26558/files/d3ae953c..7738eda8

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Fri Aug  1 18:30:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 18:30: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: <T9rrbQmHT1-HwpDqq0VxquoLRZzCm5a7wkqzH-uhKtA=.b941be84-3bbc-439a-aafc-e369b8dab002@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

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26575#pullrequestreview-3080180909

From mgronlun at openjdk.org  Fri Aug  1 18:32:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 18:32:55 GMT
Subject: RFR: 8364461: JFR: Default constructor may not be first in setting
 control
In-Reply-To: <2SjUPyQaD3JzmnNE5snHZoDH0d0nhq7_cVbK0f5Ro6Y=.fb77b298-b5a2-47ba-b7b9-6ad4b956fee9@github.com>
References: <2SjUPyQaD3JzmnNE5snHZoDH0d0nhq7_cVbK0f5Ro6Y=.fb77b298-b5a2-47ba-b7b9-6ad4b956fee9@github.com>
Message-ID: <42_rFeoLa1PTr6qcazu5YPraizfG_T3TdUEdMPZf3XQ=.44419860-b986-4c18-82cd-4ee24ee09f81@github.com>

On Thu, 31 Jul 2025 19:24:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 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

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26582#pullrequestreview-3080184915

From mgronlun at openjdk.org  Fri Aug  1 18:32:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 18:32:56 GMT
Subject: RFR: 8364257: JFR: User-defined events and settings with a
 one-letter name cannot be configured
In-Reply-To: <VWi3VMollVoZ0BKH1nhlX9j--bd0ud13tkhgSmfzbXU=.c749052d-8dee-44c6-9d0d-eb6d777d58ad@github.com>
References: <VWi3VMollVoZ0BKH1nhlX9j--bd0ud13tkhgSmfzbXU=.c749052d-8dee-44c6-9d0d-eb6d777d58ad@github.com>
Message-ID: <xBCxFUufiCI_kox8V5vQdPZdVOG2uLVzxVGSsEPDFDY=.07a53e47-1be3-464d-a294-a80f2bbeb97f@github.com>

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

> 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

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26531#pullrequestreview-3080185955

From mgronlun at openjdk.org  Fri Aug  1 18:34:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 1 Aug 2025 18:34:55 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: <KdKB0BGauZqkVXHFJMqj-Q0Cf2NPLfazotdV-6GlCKw=.d9502b1a-81ad-4092-a958-a5c1abede625@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

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26540#pullrequestreview-3080189116

From egahlin at openjdk.org  Sat Aug  2 07:40:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 2 Aug 2025 07:40:59 GMT
Subject: RFR: 8364258: ThreadGroup constant pool serialization is not
 normalized [v8]
In-Reply-To: <llseRg_mbneeq4FuTVX2co5AWueZlv-kr1AO7wiI0og=.7edff125-24cd-44ce-9a6b-b3de11272d4a@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
 <llseRg_mbneeq4FuTVX2co5AWueZlv-kr1AO7wiI0og=.7edff125-24cd-44ce-9a6b-b3de11272d4a@github.com>
Message-ID: <12hEAV63qGAxWivowB48g9zieX19awQr9X0V3EUASR8=.3643cce7-d6fb-4e4a-80a5-d7c52fb40968@github.com>

On Fri, 1 Aug 2025 17:45:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> 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:
> 
>   do not attempt to serialize a null thread group

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26558#pullrequestreview-3080950856

From egahlin at openjdk.org  Mon Aug  4 08:54:07 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 08:54:07 GMT
Subject: Integrated: 8364257: JFR: User-defined events and settings with a
 one-letter name cannot be configured
In-Reply-To: <VWi3VMollVoZ0BKH1nhlX9j--bd0ud13tkhgSmfzbXU=.c749052d-8dee-44c6-9d0d-eb6d777d58ad@github.com>
References: <VWi3VMollVoZ0BKH1nhlX9j--bd0ud13tkhgSmfzbXU=.c749052d-8dee-44c6-9d0d-eb6d777d58ad@github.com>
Message-ID: <ksqBk0EU9uc0I12l8hjSwZyy7ALJRIwhIhkSmCL7FyE=.934df411-c6d3-474c-8768-ecd081e30618@github.com>

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

> 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

This pull request has now been integrated.

Changeset: ea7e9438
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea7e943874288e1cbea10a6bd82d6c7f2a1c9ae0
Stats:     10 lines in 2 files changed: 4 ins; 0 del; 6 mod

8364257: JFR: User-defined events and settings with a one-letter name cannot be configured

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Mon Aug  4 09:15:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 09:15:03 GMT
Subject: Integrated: 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: <4G6lrGfZ0jRNoJuzvfQvzA1kFHL9GKgRK8nSkg8tVbA=.a0c25800-3172-40e8-9bd8-b2980aae3096@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

This pull request has now been integrated.

Changeset: cf5a2553
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf5a25538e09e449ff621562df6529abaa9b3685
Stats:     176 lines in 2 files changed: 160 ins; 6 del; 10 mod

8364427: JFR: Possible resource leak in Recording::getStream

Reviewed-by: mgronlun

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

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

From mgronlun at openjdk.org  Mon Aug  4 09:47:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 4 Aug 2025 09:47:10 GMT
Subject: Integrated: 8364258: ThreadGroup constant pool serialization is not
 normalized
In-Reply-To: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
References: <gIJUvly5QIjQCZ8y483ZxIVRY292EivXkw5pXY_y8lY=.f600e5f0-677e-4c54-9bb0-8cc98598ab61@github.com>
Message-ID: <euFWC6ke4itOLmIdimnZMaSKA75dlaQL64PdplcIebs=.b91f630e-eafc-4883-a81c-8e5baf7d3587@github.com>

On Wed, 30 Jul 2025 16:08:59 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: 3bc44979
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bc449797eb59f9770d2a06d260b23b6efd5ff0f
Stats:     938 lines in 12 files changed: 431 ins; 482 del; 25 mod

8364258: ThreadGroup constant pool serialization is not normalized

Reviewed-by: egahlin

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

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

From egahlin at openjdk.org  Mon Aug  4 10:28:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 10:28:03 GMT
Subject: Integrated: 8364461: JFR: Default constructor may not be first in
 setting control
In-Reply-To: <2SjUPyQaD3JzmnNE5snHZoDH0d0nhq7_cVbK0f5Ro6Y=.fb77b298-b5a2-47ba-b7b9-6ad4b956fee9@github.com>
References: <2SjUPyQaD3JzmnNE5snHZoDH0d0nhq7_cVbK0f5Ro6Y=.fb77b298-b5a2-47ba-b7b9-6ad4b956fee9@github.com>
Message-ID: <O_utk8yrQyuQKfHZrplpDUGemfuRQt7EjNFP-ZXdL2k=.1eed9953-b592-42ef-a969-73e9e6fbb9e7@github.com>

On Thu, 31 Jul 2025 19:24:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: b96b9c3d
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b96b9c3d5b2ffaeaa365b2f0d33674a980c96547
Stats:     28 lines in 2 files changed: 20 ins; 7 del; 1 mod

8364461: JFR: Default constructor may not be first in setting control

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Mon Aug  4 10:44:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 10:44:03 GMT
Subject: Integrated: 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: <qJmyAUwlQIAbtIquia7B2bmanS5m-SSQOWwGbTPBimY=.dff832f3-c1b4-4d42-a1ee-0343409e931f@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

This pull request has now been integrated.

Changeset: da0d9598
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da0d9598d049b17c04da95b61214b093c97fb60e
Stats:     151 lines in 3 files changed: 143 ins; 0 del; 8 mod

8364190: JFR: RemoteRecordingStream withers don't work

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Mon Aug  4 10:57:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 10:57:00 GMT
Subject: Integrated: 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: <OIqgo5ggYzuzEtohsBVSXNR0cW_ld_QXr2XJ5jNYBT0=.0be938b1-b568-4ec4-9ebc-293396574d10@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

This pull request has now been integrated.

Changeset: 68a4396d
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68a4396dbc1f7bc02fea91934fc71366ad879637
Stats:     57 lines in 3 files changed: 6 ins; 30 del; 21 mod

8364316: JFR: Incorrect validation of mirror fields

Reviewed-by: shade, mgronlun

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

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

From egahlin at openjdk.org  Mon Aug  4 12:26:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 12:26:53 GMT
Subject: [jdk25] RFR: 8364258: ThreadGroup constant pool serialization is
 not normalized
In-Reply-To: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
References: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
Message-ID: <ZKYzjYYBmZeTywgBlVuQswA3MTVpUk7inJoO0oTrxrI=.ac94355d-5bcb-4a9b-a176-682640506e18@github.com>

On Mon, 4 Aug 2025 09:52:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8364258: ThreadGroup constant pool serialization is not normalized

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26618#pullrequestreview-3083961842

From mgronlun at openjdk.org  Mon Aug  4 14:55:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 4 Aug 2025 14:55:03 GMT
Subject: [jdk25] Integrated: 8364258: ThreadGroup constant pool serialization
 is not normalized
In-Reply-To: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
References: <DvqtMLpkKmkZfiok2e6ygYAFV33h2bw26MizV2vCsH4=.1dde3ebd-1e66-4307-9d9d-8d5412a50151@github.com>
Message-ID: <rWM5w7qhnyVq874s2A9IoW-4_p-BkS1Brqt7SW_I9Rw=.da6666fc-76cf-4362-b743-690f9649e2a4@github.com>

On Mon, 4 Aug 2025 09:52:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8364258: ThreadGroup constant pool serialization is not normalized

This pull request has now been integrated.

Changeset: 1e2bf070
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e2bf070f0cb9e852839347d1f5711c583091d85
Stats:     938 lines in 12 files changed: 431 ins; 482 del; 25 mod

8364258: ThreadGroup constant pool serialization is not normalized

Reviewed-by: egahlin
Backport-of: 3bc449797eb59f9770d2a06d260b23b6efd5ff0f

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

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

From egahlin at openjdk.org  Mon Aug  4 22:31:26 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 4 Aug 2025 22:31:26 GMT
Subject: RFR: 8364667: JFR: Throttle doesn't work with dynamic events
Message-ID: <dWDjJhYsrl8s225uFNubp0bZF_VuYWup6qYpENmmx_Q=.0298b457-21da-46e3-9039-4d95750f68f2@github.com>

Could I have a review of a PR that fixes a bug with dynamic events and the new `@Throttle` annotation?

If a class is in the boot class loader (isJDK), it only checks for a static commit method and does not check if the `@Throttle` annotation exists (which it does  for dynamic events).

I added a test, and I also noticed that there is no check to see if there are zero events when shouldCommit is false, so I added that as well.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Move test in file
 - Initial

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

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

From thomas.stuefe at gmail.com  Tue Aug  5 08:14:18 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 5 Aug 2025 10:14:18 +0200
Subject: How to add platform-specific metrics?
Message-ID: <CAA-vtUyGY=YV+7mfqDpKZDwZacK_f=TETCe3JhD7ztRV5dxK2g@mail.gmail.com>

Hi,

short JFR question:

Is there an accepted way to add OS/Arch/Runtime-specific metrics, exclude
them where they don't make sense (both in JFR and JMC), and name them
clearly as what they are? One example of many: "glibc memory retention".

>From what I see, everything I add would have to be forced through some
platform-agnostic lens? As in, find some umbrella name for it over all
configurations (OSes/libc variants/Architectures), even if the metric makes
no sense on other configurations.

Thanks,

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250805/01d55d4d/attachment.htm>

From mgronlun at openjdk.org  Tue Aug  5 11:58:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 5 Aug 2025 11:58:03 GMT
Subject: RFR: 8364667: JFR: Throttle doesn't work with dynamic events
In-Reply-To: <dWDjJhYsrl8s225uFNubp0bZF_VuYWup6qYpENmmx_Q=.0298b457-21da-46e3-9039-4d95750f68f2@github.com>
References: <dWDjJhYsrl8s225uFNubp0bZF_VuYWup6qYpENmmx_Q=.0298b457-21da-46e3-9039-4d95750f68f2@github.com>
Message-ID: <MODcyYJu3W0wDyPri6N14R3OZKd_TU4ppWbpmAu0Fsk=.070cde05-412b-4ded-8604-b7520e2421f6@github.com>

On Mon, 4 Aug 2025 22:20:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes a bug with dynamic events and the new `@Throttle` annotation?
> 
> If a class is in the boot class loader (isJDK), it only checks for a static commit method and does not check if the `@Throttle` annotation exists (which it does  for dynamic events).
> 
> I added a test, and I also noticed that there is no check to see if there are zero events when shouldCommit is false, so I added that as well.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26632#pullrequestreview-3087965161

From thomas.stuefe at gmail.com  Tue Aug  5 14:27:58 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 5 Aug 2025 16:27:58 +0200
Subject: How to add platform-specific metrics?
In-Reply-To: <CAA-vtUyGY=YV+7mfqDpKZDwZacK_f=TETCe3JhD7ztRV5dxK2g@mail.gmail.com>
References: <CAA-vtUyGY=YV+7mfqDpKZDwZacK_f=TETCe3JhD7ztRV5dxK2g@mail.gmail.com>
Message-ID: <CAA-vtUwfAyguL6TH7yhz19h9bkcbC_355Bjdh1prZg3L0g8xdA@mail.gmail.com>

Follow-up question:

Is there some process to deprecate/reshape Events?

For example, let's say I want to introduce Process vsize and swap as
metrics. The most reasonable way would be to group these metrics with RSS
and RSSPeak into one event. There is no need for separate Events for these
values (it is unlikely that someone ever needs different collection
intervals, for example), and these are retrieved in a single operation
anyway, so retrieving them all in one go is faster than doing it separately
for every metric, and it also prevents polluting the Event space with tons
of events.

But there are problems: the event name for RSS is "ResidentSetSize". That
is probably not a good name for a combined event, which I would name
something like "ProcessMemory", with metrics like "rssUsage",
"rssPeakUsage", "vsize", "swap", or similar. But this would change the
existing ResidentSetSize event. This Event is the base for the RSS chart
printed in JMC, so I guess JMC would have to be adapted - but if it is, it
won't be able to read old jfr files anymore? So I wonder, how is backward
compatibility handled in JFR? Is there a process? Or are we stuck with old
decisions forever?

Thanks!

Kind Regards, Thomas


On Tue, Aug 5, 2025 at 10:14?AM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi,
>
> short JFR question:
>
> Is there an accepted way to add OS/Arch/Runtime-specific metrics, exclude
> them where they don't make sense (both in JFR and JMC), and name them
> clearly as what they are? One example of many: "glibc memory retention".
>
> From what I see, everything I add would have to be forced through some
> platform-agnostic lens? As in, find some umbrella name for it over all
> configurations (OSes/libc variants/Architectures), even if the metric makes
> no sense on other configurations.
>
> Thanks,
>
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250805/d9fae589/attachment.htm>

From egahlin at openjdk.org  Tue Aug  5 14:36:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 5 Aug 2025 14:36:10 GMT
Subject: Integrated: 8364667: JFR: Throttle doesn't work with dynamic events
In-Reply-To: <dWDjJhYsrl8s225uFNubp0bZF_VuYWup6qYpENmmx_Q=.0298b457-21da-46e3-9039-4d95750f68f2@github.com>
References: <dWDjJhYsrl8s225uFNubp0bZF_VuYWup6qYpENmmx_Q=.0298b457-21da-46e3-9039-4d95750f68f2@github.com>
Message-ID: <sdJkqJ8HxuZoau5hktyOdnp_nHJXjJFYU_CEzhuvXY0=.0c944216-4d7f-4ef4-990d-0749ca32568b@github.com>

On Mon, 4 Aug 2025 22:20:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes a bug with dynamic events and the new `@Throttle` annotation?
> 
> If a class is in the boot class loader (isJDK), it only checks for a static commit method and does not check if the `@Throttle` annotation exists (which it does  for dynamic events).
> 
> I added a test, and I also noticed that there is no check to see if there are zero events when shouldCommit is false, so I added that as well.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 8a571ee7
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a571ee7f2d9a46ff485fd9f3658c552e2d20817
Stats:     52 lines in 3 files changed: 46 ins; 4 del; 2 mod

8364667: JFR: Throttle doesn't work with dynamic events

Reviewed-by: mgronlun

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

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

From mbaesken at openjdk.org  Thu Aug  7 07:51:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Aug 2025 07:51:13 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: <vSNfcdzkvFqYO-fdy28DUaLkLFJfO-7Oc6R3ubqNatU=.bbb8054a-1152-4967-b09c-868373718e56@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.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26506#pullrequestreview-3095860607

From mbaesken at openjdk.org  Thu Aug  7 07:51:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Aug 2025 07:51:14 GMT
Subject: RFR: 8359690: New test TestCPUTimeSampleThrottling still fails
 intermittently
In-Reply-To: <1F_Q_LJmoxqwhtKy0XgOoIpH59WdOzQTleGcU_0xYwI=.b519f39c-3c73-4464-9026-0cd7e6893b32@github.com>
References: <Nwsdm_u3PFMLhimdtQxnEGW90ny9D-Aleyvkyrihwz8=.c0c2f304-896e-4bf6-8978-d5f06f20f0cb@github.com>
 <1F_Q_LJmoxqwhtKy0XgOoIpH59WdOzQTleGcU_0xYwI=.b519f39c-3c73-4464-9026-0cd7e6893b32@github.com>
Message-ID: <JdXXuptP0Cn_w-HzwAgOsG6EC3eDz8N6Z8oVf1yQiKI=.b60ef184-a003-4d09-9d49-ba0b990cf9ab@github.com>

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

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

No issues seen any more in the internal tests (at least where the patch was used) .

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

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

From jbechberger at openjdk.org  Thu Aug  7 07:55:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 7 Aug 2025 07:55:18 GMT
Subject: Integrated: 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: <pLMv53RF0xywzc_gKbGmi558Y37NHbljBKmBA4Z2F9E=.aba69c2b-d551-412c-9eb0-730b5ef457b7@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.

This pull request has now been integrated.

Changeset: 487cc3c5
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/487cc3c5be769d15d61cb950137d52ba0eb982b5
Stats:     15 lines in 1 file changed: 3 ins; 7 del; 5 mod

8359690: New test TestCPUTimeSampleThrottling still fails intermittently

Reviewed-by: mbaesken

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

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

From dcherepanov at openjdk.org  Fri Aug  8 10:44:53 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Fri, 8 Aug 2025 10:44:53 GMT
Subject: RFR: 8365044: Missing copyright header in Contextual.java
Message-ID: <i5uJ90TAR3jb9u1PVaSVgKNrxNh7ijdhHTu8B3p9NNA=.b0630ddf-3ce7-434a-9b4f-d490d584c98d@github.com>

Adding missing copyright header to Contextual.java

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

Commit messages:
 - 8365044: Missing copyright header in Contextual.java

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

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

From egahlin at openjdk.org  Sat Aug  9 19:01:12 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 9 Aug 2025 19:01:12 GMT
Subject: RFR: 8365044: Missing copyright header in Contextual.java
In-Reply-To: <i5uJ90TAR3jb9u1PVaSVgKNrxNh7ijdhHTu8B3p9NNA=.b0630ddf-3ce7-434a-9b4f-d490d584c98d@github.com>
References: <i5uJ90TAR3jb9u1PVaSVgKNrxNh7ijdhHTu8B3p9NNA=.b0630ddf-3ce7-434a-9b4f-d490d584c98d@github.com>
Message-ID: <MA6_oFlPBQPe-J6Bfwfbpwfb3vs9S87huaIN6quPKB8=.17427e28-fa69-4432-8831-63243bd4e34d@github.com>

On Fri, 8 Aug 2025 10:38:41 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Adding missing copyright header to Contextual.java

Thanks for fixing.

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

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26693#pullrequestreview-3103211822

From dcherepanov at openjdk.org  Mon Aug 11 08:22:21 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 11 Aug 2025 08:22:21 GMT
Subject: RFR: 8365044: Missing copyright header in Contextual.java
In-Reply-To: <i5uJ90TAR3jb9u1PVaSVgKNrxNh7ijdhHTu8B3p9NNA=.b0630ddf-3ce7-434a-9b4f-d490d584c98d@github.com>
References: <i5uJ90TAR3jb9u1PVaSVgKNrxNh7ijdhHTu8B3p9NNA=.b0630ddf-3ce7-434a-9b4f-d490d584c98d@github.com>
Message-ID: <xZ7bP36KlUYILj6dGfUbJAwmTLMI0LA_wJWG81Jt3ss=.ee27cba8-c416-4cec-9ace-b224eaca03e7@github.com>

On Fri, 8 Aug 2025 10:38:41 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Adding missing copyright header to Contextual.java

Thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26693#issuecomment-3173712332

From dcherepanov at openjdk.org  Mon Aug 11 08:22:22 2025
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 11 Aug 2025 08:22:22 GMT
Subject: Integrated: 8365044: Missing copyright header in Contextual.java
In-Reply-To: <i5uJ90TAR3jb9u1PVaSVgKNrxNh7ijdhHTu8B3p9NNA=.b0630ddf-3ce7-434a-9b4f-d490d584c98d@github.com>
References: <i5uJ90TAR3jb9u1PVaSVgKNrxNh7ijdhHTu8B3p9NNA=.b0630ddf-3ce7-434a-9b4f-d490d584c98d@github.com>
Message-ID: <lKxyJsmjFvpbLuuolvGYesz2SrOTKnuZ8ZbvGoxlw7g=.694b94f8-2006-408e-923b-b4cdd97fc234@github.com>

On Fri, 8 Aug 2025 10:38:41 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Adding missing copyright header to Contextual.java

This pull request has now been integrated.

Changeset: 10762d40
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10762d408bba9ce0945100847a8674e7eb7fa75e
Stats:     25 lines in 1 file changed: 25 ins; 0 del; 0 mod

8365044: Missing copyright header in Contextual.java

Reviewed-by: egahlin

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

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

From egahlin at openjdk.org  Mon Aug 11 18:46:22 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 11 Aug 2025 18:46:22 GMT
Subject: RFR: 8364993: JFR: Disable jdk.ModuleExport in default.jfc
Message-ID: <49abVTdv2L9xuM8rZmEtX5FC7YXUqzFWF-cntaIAfzQ=.9ba41da0-9150-45e9-814e-ba5626b526a2@github.com>

Could I have a review of a change that disables the ModuleExport event in default.jfc? It can use a significant amount of space in some applications, and the event is not that useful. See the bug for details.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From egahlin at openjdk.org  Mon Aug 11 18:47:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 11 Aug 2025 18:47:01 GMT
Subject: RFR: 8364756: JFR: Improve slow tests
Message-ID: <DwxnJAGlo1wsu_g1sApfipTU85V-oBi_LNUzmvurHG8=.3c3181df-f768-4bfa-8a14-7b87b5da159d@github.com>

Could I have a review of a PR that improves the speed of some of the JFR tests?

Thanks
Erik

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

Commit messages:
 - Revert test change as it did not yield improvement
 - Initial

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

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

From mgronlun at openjdk.org  Mon Aug 11 19:36:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 11 Aug 2025 19:36:11 GMT
Subject: RFR: 8364756: JFR: Improve slow tests
In-Reply-To: <DwxnJAGlo1wsu_g1sApfipTU85V-oBi_LNUzmvurHG8=.3c3181df-f768-4bfa-8a14-7b87b5da159d@github.com>
References: <DwxnJAGlo1wsu_g1sApfipTU85V-oBi_LNUzmvurHG8=.3c3181df-f768-4bfa-8a14-7b87b5da159d@github.com>
Message-ID: <5f5ErZmkmLCqUM5aYL3M_asoL-7Tui9JqOxttzCWBbQ=.8448d579-5654-4a5c-9079-0280a50c8a6d@github.com>

On Tue, 5 Aug 2025 15:20:36 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that improves the speed of some of the JFR tests?
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26644#pullrequestreview-3107490457

From mgronlun at openjdk.org  Mon Aug 11 19:38:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 11 Aug 2025 19:38:11 GMT
Subject: RFR: 8364993: JFR: Disable jdk.ModuleExport in default.jfc
In-Reply-To: <49abVTdv2L9xuM8rZmEtX5FC7YXUqzFWF-cntaIAfzQ=.9ba41da0-9150-45e9-814e-ba5626b526a2@github.com>
References: <49abVTdv2L9xuM8rZmEtX5FC7YXUqzFWF-cntaIAfzQ=.9ba41da0-9150-45e9-814e-ba5626b526a2@github.com>
Message-ID: <saSJmO_NEQtTSN2ZYR2cdM7LUinL7GZ-8ywjpztIM7k=.531b8054-084e-48e3-905e-4f79b571c373@github.com>

On Mon, 11 Aug 2025 14:55:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that disables the ModuleExport event in default.jfc? It can use a significant amount of space in some applications, and the event is not that useful. See the bug for details.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26728#pullrequestreview-3107503495

From mgronlun at openjdk.org  Mon Aug 11 20:58:49 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 11 Aug 2025 20:58:49 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary Klass*
 storage to reduce typeset processing
Message-ID: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>

Greetings,

This change set is a performance improvement to speed up JFR typeset processing.

It accomplishes this by using a set instead of a list as the intermediary Klass* storage.

Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 

Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).

Testing: jdk_jfr, stress tests

Thanks
Markus

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

Commit messages:
 - adjustment
 - 8365199

Changes: https://git.openjdk.org/jdk/pull/26733/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26733&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365199
  Stats: 358 lines in 11 files changed: 176 ins; 86 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/26733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26733/head:pull/26733

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

From mgronlun at openjdk.org  Mon Aug 11 21:41:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 11 Aug 2025 21:41:27 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing [v2]
In-Reply-To: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
Message-ID: <AMrUo8gX5pG7g2VOAY8rLPIgC8pWhlLWPMKSBxOfPlY=.b405f818-79ed-403b-bf90-0d0c1ab6f157@github.com>

> Greetings,
> 
> This change set is a performance improvement to speed up JFR typeset processing.
> 
> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
> 
> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
> 
> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
> 
> Testing: jdk_jfr, stress tests
> 
> Thanks
> Markus

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

  improved typedef usage and static assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26733/files
  - new: https://git.openjdk.org/jdk/pull/26733/files/dbc9ecd2..02d6f526

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

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

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

From egahlin at openjdk.org  Tue Aug 12 13:46:18 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 12 Aug 2025 13:46:18 GMT
Subject: Integrated: 8364993: JFR: Disable jdk.ModuleExport in default.jfc
In-Reply-To: <49abVTdv2L9xuM8rZmEtX5FC7YXUqzFWF-cntaIAfzQ=.9ba41da0-9150-45e9-814e-ba5626b526a2@github.com>
References: <49abVTdv2L9xuM8rZmEtX5FC7YXUqzFWF-cntaIAfzQ=.9ba41da0-9150-45e9-814e-ba5626b526a2@github.com>
Message-ID: <TSEaShcaOHY9HmbNP7j8ugMejZgol-789DtPLFZW8S4=.e63947c2-7858-4a75-b468-b01449972c92@github.com>

On Mon, 11 Aug 2025 14:55:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that disables the ModuleExport event in default.jfc? It can use a significant amount of space in some applications, and the event is not that useful. See the bug for details.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: a382996b
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a382996bb496d50b4eb5a6be9f61e5c2f8aaae2d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8364993: JFR: Disable jdk.ModuleExport in default.jfc

Reviewed-by: mgronlun

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

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

From mgronlun at openjdk.org  Tue Aug 12 14:10:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 12 Aug 2025 14:10:28 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing [v3]
In-Reply-To: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
Message-ID: <eijn4fttBoCACIR6BdLPkRmks0GN4U58PE4dl41jTXM=.b2b07bcf-1d24-481c-b276-ec586ef169a6@github.com>

> Greetings,
> 
> This change set is a performance improvement to speed up JFR typeset processing.
> 
> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
> 
> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
> 
> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
> 
> Testing: jdk_jfr, stress tests
> 
> Thanks
> Markus

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

  increase possible maxsize and extend probe sequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26733/files
  - new: https://git.openjdk.org/jdk/pull/26733/files/02d6f526..c9ed816f

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

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

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

From mgronlun at openjdk.org  Tue Aug 12 14:14:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 12 Aug 2025 14:14:54 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing [v4]
In-Reply-To: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
Message-ID: <IrGwzrqMLkwW9zQVRPFI8BoN0bpTqVIQwEdeMxWaVGs=.734a4db0-1422-4bfd-bcba-aa44e8c24991@github.com>

> Greetings,
> 
> This change set is a performance improvement to speed up JFR typeset processing.
> 
> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
> 
> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
> 
> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
> 
> Testing: jdk_jfr, stress tests
> 
> Thanks
> Markus

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

  const

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26733/files
  - new: https://git.openjdk.org/jdk/pull/26733/files/c9ed816f..c1707f85

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

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

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

From egahlin at openjdk.org  Tue Aug 12 17:48:16 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 12 Aug 2025 17:48:16 GMT
Subject: Integrated: 8364756: JFR: Improve slow tests
In-Reply-To: <DwxnJAGlo1wsu_g1sApfipTU85V-oBi_LNUzmvurHG8=.3c3181df-f768-4bfa-8a14-7b87b5da159d@github.com>
References: <DwxnJAGlo1wsu_g1sApfipTU85V-oBi_LNUzmvurHG8=.3c3181df-f768-4bfa-8a14-7b87b5da159d@github.com>
Message-ID: <iQAA7Piiunx_cWOPDXcyVAfT0A0NjhPdN5Ij4Uiqkcs=.f1db02aa-e416-4d34-813b-6e96b038bfe8@github.com>

On Tue, 5 Aug 2025 15:20:36 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that improves the speed of some of the JFR tests?
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 87d73401
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87d734012e3130501bfd37b23cee7f5e0a3a476f
Stats:     28 lines in 7 files changed: 8 ins; 8 del; 12 mod

8364756: JFR: Improve slow tests

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Tue Aug 12 17:49:19 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 12 Aug 2025 17:49:19 GMT
Subject: RFR: 8364556: JFR:  Disable SymbolTableStatistics and
 StringTableStatistics in default.jfc
Message-ID: <XKbdwj9mCusJMhI40VfkoQwn_h5dP7DYHmJoMbGBsNw=.5bedfd7d-4761-4280-8042-674a1071c414@github.com>

Could I have a review of PR that disabled two events in the default configuration due to the runtime impact.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Tue Aug 12 18:57:25 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 12 Aug 2025 18:57:25 GMT
Subject: RFR: 8364556: JFR:  Disable SymbolTableStatistics and
 StringTableStatistics in default.jfc
In-Reply-To: <XKbdwj9mCusJMhI40VfkoQwn_h5dP7DYHmJoMbGBsNw=.5bedfd7d-4761-4280-8042-674a1071c414@github.com>
References: <XKbdwj9mCusJMhI40VfkoQwn_h5dP7DYHmJoMbGBsNw=.5bedfd7d-4761-4280-8042-674a1071c414@github.com>
Message-ID: <Sn0cTbwPzBlJCMfulzDJhgaI_MKrYn9HhJKrC7Busw0=.2af85200-4d57-45b4-b7f1-06163b72544d@github.com>

On Mon, 4 Aug 2025 13:08:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that disabled two events in the default configuration due to the runtime impact.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26620#pullrequestreview-3112311587

From mgronlun at openjdk.org  Wed Aug 13 14:31:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 13 Aug 2025 14:31:01 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing [v5]
In-Reply-To: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
Message-ID: <XcD4ASLO8aAT2ouy0vF1tOrIYgc4defftUT0N2dsK54=.03a81ec2-94d2-47df-8e14-dec3a5e055ab@github.com>

> Greetings,
> 
> This change set is a performance improvement to speed up JFR typeset processing.
> 
> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
> 
> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
> 
> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
> 
> Testing: jdk_jfr, stress tests
> 
> Thanks
> Markus

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

  less than or equal to max_initial_size

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26733/files
  - new: https://git.openjdk.org/jdk/pull/26733/files/c1707f85..9b9db9f2

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

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

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

From jpai at openjdk.org  Thu Aug 14 10:42:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 10:42:26 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
Message-ID: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>

Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.

These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.

tier1, tier2 and tier3 testing of this change completed without any related failures.

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

Commit messages:
 - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

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

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

From egahlin at openjdk.org  Thu Aug 14 10:46:17 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 14 Aug 2025 10:46:17 GMT
Subject: Integrated: 8364556: JFR:  Disable SymbolTableStatistics and
 StringTableStatistics in default.jfc
In-Reply-To: <XKbdwj9mCusJMhI40VfkoQwn_h5dP7DYHmJoMbGBsNw=.5bedfd7d-4761-4280-8042-674a1071c414@github.com>
References: <XKbdwj9mCusJMhI40VfkoQwn_h5dP7DYHmJoMbGBsNw=.5bedfd7d-4761-4280-8042-674a1071c414@github.com>
Message-ID: <CK3f-AEzXfJHM3gyOWOc8p9Ym0Q0D6akEDd_KSzAqso=.e6371553-f12e-4041-b086-74a0a79e1829@github.com>

On Mon, 4 Aug 2025 13:08:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that disabled two events in the default configuration due to the runtime impact.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

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

8364556: JFR:  Disable SymbolTableStatistics and StringTableStatistics in default.jfc

Reviewed-by: mgronlun

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

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

From duke at openjdk.org  Thu Aug 14 12:04:14 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 14 Aug 2025 12:04:14 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <RwfKP5KO_jRS4HxRMRu_pfbiNJahmrRc9q8qMybEaiU=.8319ef07-772d-4817-8e5f-b88fd887afa1@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

See?also <https://github.com/openjdk/jdk/pull/26765> ([JDK?8365416])

[JDK?8365416]: https://bugs.openjdk.org/browse/JDK-8365416 "[JDK?8365416] java.desktop no?longer?needs preview?feature?access"

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

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3188202824

From jpai at openjdk.org  Thu Aug 14 12:23:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 12:23:12 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <R-Hw3-g5SjEVgWmyAGyXJ2HrKh9MyDgcfuMvU9erYsk=.65b03c56-5e97-4de4-a3fc-639ffb8195e5@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

> See also #26765 ([JDK?8365416](https://bugs.openjdk.org/browse/JDK-8365416))

Right, that's what prompted me to start looking into this. The java.desktop change for which that other PR is open can go ahead independently.

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

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3188258941

From mgronlun at openjdk.org  Thu Aug 14 14:30:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 14 Aug 2025 14:30:01 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing [v6]
In-Reply-To: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
Message-ID: <YePRXRDdfM_aGuKoIw54errm8CyNbPoRbXunyPakrRY=.ae4a9b41-2307-49bd-b564-496971b3c299@github.com>

> Greetings,
> 
> This change set is a performance improvement to speed up JFR typeset processing.
> 
> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
> 
> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
> 
> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
> 
> Testing: jdk_jfr, stress tests
> 
> Thanks
> Markus

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

 - merge error
 - Merge branch '8365199' of github.com:mgronlun/jdk into 8365199
 - use load factor instead of probe sequence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26733/files
  - new: https://git.openjdk.org/jdk/pull/26733/files/9b9db9f2..07d9d1ab

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

  Stats: 89 lines in 5 files changed: 32 ins; 23 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/26733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26733/head:pull/26733

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

From mgronlun at openjdk.org  Thu Aug 14 14:34:57 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 14 Aug 2025 14:34:57 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing [v7]
In-Reply-To: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
Message-ID: <7c7XSbWWI8W5rZnvAQiKrPNV2cE8--KIMrTu4uAThn8=.228b1811-4f32-426f-b690-690bc660b52e@github.com>

> Greetings,
> 
> This change set is a performance improvement to speed up JFR typeset processing.
> 
> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
> 
> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
> 
> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
> 
> Testing: jdk_jfr, stress tests
> 
> Thanks
> Markus

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

 - Merge branch 'master' of https://git.openjdk.org/jdk into 8365199
 - merge error
 - Merge branch '8365199' of github.com:mgronlun/jdk into 8365199
 - less than or equal to max_initial_size
 - use load factor instead of probe sequence
 - const
 - increase possible maxsize and extend probe sequence
 - improved typedef usage and static assert
 - adjustment
 - 8365199

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

Changes: https://git.openjdk.org/jdk/pull/26733/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26733&range=06
  Stats: 350 lines in 11 files changed: 175 ins; 74 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/26733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26733/head:pull/26733

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

From egahlin at openjdk.org  Thu Aug 14 14:51:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 14 Aug 2025 14:51:13 GMT
Subject: RFR: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing [v7]
In-Reply-To: <7c7XSbWWI8W5rZnvAQiKrPNV2cE8--KIMrTu4uAThn8=.228b1811-4f32-426f-b690-690bc660b52e@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
 <7c7XSbWWI8W5rZnvAQiKrPNV2cE8--KIMrTu4uAThn8=.228b1811-4f32-426f-b690-690bc660b52e@github.com>
Message-ID: <zezUW-KtPRjTjfUnqzJ4kc0v6vVZ6ap3HLgaLORLFCo=.76d62dc1-f5e3-474b-a2fc-586c09d90144@github.com>

On Thu, 14 Aug 2025 14:34:57 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This change set is a performance improvement to speed up JFR typeset processing.
>> 
>> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
>> 
>> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
>> 
>> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
>> 
>> Testing: jdk_jfr, stress tests
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into 8365199
>  - merge error
>  - Merge branch '8365199' of github.com:mgronlun/jdk into 8365199
>  - less than or equal to max_initial_size
>  - use load factor instead of probe sequence
>  - const
>  - increase possible maxsize and extend probe sequence
>  - improved typedef usage and static assert
>  - adjustment
>  - 8365199

Looks good.

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

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26733#pullrequestreview-3120901943

From liach at openjdk.org  Fri Aug 15 04:29:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Aug 2025 04:29:15 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <kmngnozEmlS3-dfo_xmzpW84PLGX-yrXavmBAGO_7Ys=.4600fb69-1c42-4132-9cce-1077fbdc7ae4@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

Looks right to me. However since your changed lines is directly by the java.desktop changed line, there's a conflict and you must resolve it.

In addition, `PreviewFeature.Feature` enum has a few obsolete entries - they should be kept until the preview feature is not in the minimum boot JDK. Now the boot JDK is min 24, and a few of the features are already permanent in 24.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26776#pullrequestreview-3122788756
PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3190566237

From mgronlun at openjdk.org  Fri Aug 15 09:36:15 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 15 Aug 2025 09:36:15 GMT
Subject: Integrated: 8365199: Use a set instead of a list as the intermediary
 Klass* storage to reduce typeset processing
In-Reply-To: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
References: <iJSHvVy6Bie26U9VgQByDOQrGZbJ5mvOsJGEVeIl7N4=.2ac41822-e5ad-456b-bb0f-38831e46edb0@github.com>
Message-ID: <UWIWQkACQYdViZzJIrP_cLiNONvC3v6trVyrZ7-QkcU=.44f6eee1-10da-4d22-8a7c-b6220f380a7c@github.com>

On Mon, 11 Aug 2025 20:51:22 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This change set is a performance improvement to speed up JFR typeset processing.
> 
> It accomplishes this by using a set instead of a list as the intermediary Klass* storage.
> 
> Further, the existing JfrSet implementation (currently backed by a linked-list ResizeableResourceHashTable) is optimized to use instead a slimmed open-addressing implementation, premised on the invariant that our sets are key sets. 
> 
> Running the test program attached to the JIRA issue results in a 100% performance improvement in total running time (by reducing the work set of Klass: es being processed by the JFR Recorder Thread).
> 
> Testing: jdk_jfr, stress tests
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 5856dc34
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5856dc34c82de9f840be1dc28a9917224971491f
Stats:     350 lines in 11 files changed: 175 ins; 74 del; 101 mod

8365199: Use a set instead of a list as the intermediary Klass* storage to reduce typeset processing

Reviewed-by: egahlin

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

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

From duke at openjdk.org  Fri Aug 15 13:37:52 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 15 Aug 2025 13:37:52 GMT
Subject: RFR: 8365610: Sort share/jfr includes
Message-ID: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>

This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.

Passes tier1.

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

Commit messages:
 - reorder

Changes: https://git.openjdk.org/jdk/pull/26800/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26800&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365610
  Stats: 173 lines in 56 files changed: 82 ins; 89 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26800.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26800/head:pull/26800

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

From duke at openjdk.org  Fri Aug 15 13:37:52 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 15 Aug 2025 13:37:52 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <d4RYBJvvXp9nGgw05JoMN41n_8d0PDmlvShcvqjDx9M=.be58949e-f5a2-4844-9114-5f2e6a48d352@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Passes tier1.

src/hotspot/share/jfr/periodic/jfrOSInterface.cpp line 35:

> 33: #include "utilities/ostream.hpp"
> 34: 
> 35: #include <stdlib.h> // for environment variables

I couldn't find any usage for this include, let me know if it should stay. It's been here for a long time: https://github.com/openjdk/jdk/commit/a060be188df894ed5c26fc12fc9e902f9af32bd3

src/hotspot/share/jfr/support/jfrDeprecationManager.cpp line 52:

> 50: #include "runtime/thread.inline.hpp"
> 51: 
> 52: // for strstr

Let me know if the comment should stay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26800#discussion_r2278998210
PR Review Comment: https://git.openjdk.org/jdk/pull/26800#discussion_r2278998848

From stuefe at openjdk.org  Sat Aug 16 04:23:56 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 16 Aug 2025 04:23:56 GMT
Subject: RFR: 8365611: Throttle any JFR event
Message-ID: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>

This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.

The patch does not yet enable throttling for any other event. I can do that, if we agree that this is okay. But I'd like to avoid arguments, so for now the patch does not add the ability to throttle to any event; it just makes it trivially easy to do that if needed.

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

Commit messages:
 - Update jfrEventThrottler.cpp
 - wip
 - fixes
 - start

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

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

From egahlin at openjdk.org  Sun Aug 17 19:16:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 17 Aug 2025 19:16:53 GMT
Subject: RFR: 8365636: JFR: Minor cleanup
Message-ID: <9mu1ONkHASHyy8qEo4G7oaIvM0R-n717TOsQMGAh6vg=.62dceb2c-826a-4798-81a3-81adb05e544d@github.com>

Could I have review of Pr That cleans up various stuff (unnecessary imports, typos etc).

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/26811/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26811&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365636
  Stats: 88 lines in 33 files changed: 1 ins; 16 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/26811.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26811/head:pull/26811

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

From egahlin at openjdk.org  Sun Aug 17 19:17:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 17 Aug 2025 19:17:53 GMT
Subject: RFR: 8365614: JFR: Improve PrettyWriter::printValue
Message-ID: <JLZQnil5Pk8mxdt56AQ_Bccqf2CTtJ_zx5vOfrpUCIs=.49157f71-aa06-4fc5-8d0d-7696f98faa3b@github.com>

Could I have a review of a PR  that simplifies the PrettyWriter::printValue method so it uses switch expression. It also changes so null is never passed to the method, making the code more robust.

Testing: jdk/jdk/jfr  + manual comparison of output before and after so it hasn't changed

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

Commit messages:
 - Remove wrongly added file
 - Initial

Changes: https://git.openjdk.org/jdk/pull/26810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365614
  Stats: 154 lines in 2 files changed: 23 ins; 66 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/26810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26810/head:pull/26810

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

From egahlin at openjdk.org  Sun Aug 17 19:19:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 17 Aug 2025 19:19:55 GMT
Subject: RFR: 8365638: JFR: Add --exact for debugging out-of-order events
Message-ID: <u6nBVONJONXbZyr5CNMaP46nzcNsumsdusbc49xgcbc=.5219f3a8-fd82-42fd-b30e-106e413474ed@github.com>

Could I have review of PR that add --exact so the failure of a test can be debugged more easily. 

Testing: test/jdk/jdk/jfr/tool/TestPrintContextual.java

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From egahlin at openjdk.org  Sun Aug 17 19:20:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 17 Aug 2025 19:20:01 GMT
Subject: RFR: 8365550: JFR: The active-settings view should not use LAST_BATCH
Message-ID: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>

Could I have a review of the change that updates the active-settings query to use LAST instead of LAST_BATCH?

The problem with using LAST_BATCH is that it doesn?t work with older recordings where the jdk.ActiveSetting event was not emitted as a batch, or with later recordings where a single setting is changed programmatically.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From jpai at openjdk.org  Mon Aug 18 04:49:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 04:49:28 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - merge latest from master branch
 - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

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

Changes: https://git.openjdk.org/jdk/pull/26776/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26776&range=01
  Stats: 27 lines in 7 files changed: 0 ins; 22 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26776/head:pull/26776

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

From alanb at openjdk.org  Mon Aug 18 06:04:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Aug 2025 06:04:14 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
Message-ID: <H_tMMP8u5UzbkC9lwzvo4NTkFdDGg0x_baZZ07tg5Ig=.12c19630-073e-46aa-bf94-cb26b566f87a@github.com>

On Mon, 18 Aug 2025 04:49:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
>> 
>> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
>> 
>> tier1, tier2 and tier3 testing of this change completed without any related failures.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge latest from master branch
>  - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26776#pullrequestreview-3126883742

From jpai at openjdk.org  Mon Aug 18 06:48:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 06:48:19 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
Message-ID: <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>

On Mon, 18 Aug 2025 04:49:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
>> 
>> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
>> 
>> tier1, tier2 and tier3 testing of this change completed without any related failures.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge latest from master branch
>  - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Thank you Alan and Chen for the reviews.

tier1, tier2 and tier3 testing with this change completed without any related issues.

> In addition, `PreviewFeature.Feature` enum has a few obsolete entries ... Now the boot JDK is min 24, and a few of the features are already permanent in 24.

I'll file a separate issue to clean those up.

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

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3195338107

From egahlin at openjdk.org  Mon Aug 18 07:00:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 18 Aug 2025 07:00:01 GMT
Subject: RFR: 8365636: JFR: Minor cleanup [v2]
In-Reply-To: <9mu1ONkHASHyy8qEo4G7oaIvM0R-n717TOsQMGAh6vg=.62dceb2c-826a-4798-81a3-81adb05e544d@github.com>
References: <9mu1ONkHASHyy8qEo4G7oaIvM0R-n717TOsQMGAh6vg=.62dceb2c-826a-4798-81a3-81adb05e544d@github.com>
Message-ID: <CwZBoWpO9ESJp3XxxPuA84UPxMNCQ2lM8kgf33byzkM=.34a673f0-8482-4d20-b0ec-3137619d5326@github.com>

> Could I have review of Pr That cleans up various stuff (unnecessary imports, typos etc).
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Compare with class instead incorrect/reversed isAssignableFrom

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26811/files
  - new: https://git.openjdk.org/jdk/pull/26811/files/c90ef842..9a0c6edc

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

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

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

From shade at openjdk.org  Mon Aug 18 08:52:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 08:52:13 GMT
Subject: RFR: 8365638: JFR: Add --exact for debugging out-of-order events
In-Reply-To: <u6nBVONJONXbZyr5CNMaP46nzcNsumsdusbc49xgcbc=.5219f3a8-fd82-42fd-b30e-106e413474ed@github.com>
References: <u6nBVONJONXbZyr5CNMaP46nzcNsumsdusbc49xgcbc=.5219f3a8-fd82-42fd-b30e-106e413474ed@github.com>
Message-ID: <1oc-4VowRcY5m9_c9Octw4Vex8rceVIEWcQifb69Vi8=.1d317799-830a-4b1d-ac45-759335d975c8@github.com>

On Sun, 17 Aug 2025 18:34:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that add --exact so the failure of a test can be debugged more easily. 
> 
> Testing: test/jdk/jdk/jfr/tool/TestPrintContextual.java
> 
> Thanks
> Erik

Looks good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26812#pullrequestreview-3127406574

From mgronlun at openjdk.org  Mon Aug 18 09:48:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 09:48:14 GMT
Subject: RFR: 8365611: Throttle any JFR event
In-Reply-To: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
Message-ID: <BR6dLB41EgUU9esXPX9x_kSiWoMH475iO4smJ6QeKJo=.5722653c-d50a-41e6-a0b3-6aeff4c23826@github.com>

On Fri, 15 Aug 2025 14:58:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
> 
> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
> 
> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.

What motivates this change?

It does not make any sense to "throttle all events." Also, "all events" at this location only constitute JVM events, not Java events.

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3195941664

From mgronlun at openjdk.org  Mon Aug 18 09:59:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 09:59:13 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <oehNmOCVoZNUmN3WidZurTyX6n_m1jdtM-oYcEguVGY=.0e17fdeb-3f88-4f6e-a9ad-adfe8ef84c2b@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

This creates a dependency on a test that is not normally run when we develop JFR.

What tier is the test located?

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3195982055

From stuefe at openjdk.org  Mon Aug 18 10:00:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 18 Aug 2025 10:00:11 GMT
Subject: RFR: 8365611: Throttle any JFR event
In-Reply-To: <BR6dLB41EgUU9esXPX9x_kSiWoMH475iO4smJ6QeKJo=.5722653c-d50a-41e6-a0b3-6aeff4c23826@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <BR6dLB41EgUU9esXPX9x_kSiWoMH475iO4smJ6QeKJo=.5722653c-d50a-41e6-a0b3-6aeff4c23826@github.com>
Message-ID: <0a3Rvcto678pkGJpzyvDSEwqBrfYh9_-Jt8u6Zpv3xM=.2b495455-a660-4779-9c0d-aa52f94e1683@github.com>

On Mon, 18 Aug 2025 09:45:20 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> What motivates this change?
> 
> It does not make any sense to "throttle all events." Also, "all events" at this location only constitute JVM events, not Java events.

I'd like to introduce an event to count allocations via Unsafe.allocateMemory ([1]). We get many customers with unexplainably high RSS footprint, and often it turns out that the culprit is an external library allocating memory via Unsafe.allocateMemory. One example would be Netty. 

What folks currently do is to use techniques like valgrind, replacing the C-Heap with jemalloc or using asyncprofiler. It would be very nice if we could do this with JFR itself; it is certainly capable.

But these calls can be relatively fine-grained. Often not, but sometimes they are. If they are, it makes sense to make this new event "throttleable" and throttle it by default to a sensible level.

Apart from all of that, is this not something that is cleaner and just makes sense? You's avoid some ugly and more costly switch case constructs that are executed on every event, don't you?

[1] https://github.com/openjdk/jdk/compare/master...tstuefe:jdk:refs/heads/JFR-Unsafe.allocateMemory

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3195983563

From duke at openjdk.org  Mon Aug 18 10:07:16 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 18 Aug 2025 10:07:16 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <oehNmOCVoZNUmN3WidZurTyX6n_m1jdtM-oYcEguVGY=.0e17fdeb-3f88-4f6e-a9ad-adfe8ef84c2b@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <oehNmOCVoZNUmN3WidZurTyX6n_m1jdtM-oYcEguVGY=.0e17fdeb-3f88-4f6e-a9ad-adfe8ef84c2b@github.com>
Message-ID: <fAwxnmPMXs6cdVZfLJVdMYSToE5rb5f9o3Q-UnjqwaQ=.88aad5f0-235f-4893-b921-934eacbd9b7a@github.com>

On Mon, 18 Aug 2025 09:56:32 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This creates a dependency on a test that is not normally run when we develop JFR.
> 
> What tier is the test located?

`TestIncludesAreSorted.java` is in [`tier1`](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/TEST.groups#L142).

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3196013395

From mgronlun at openjdk.org  Mon Aug 18 10:18:09 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 10:18:09 GMT
Subject: RFR: 8365611: Throttle any JFR event
In-Reply-To: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
Message-ID: <C6GBO0mOEO5XEMPENP_J_3F2zQYtYaQMBKArBmRRZww=.21f546a4-c262-4286-859b-c6f4e0d029f5@github.com>

On Fri, 15 Aug 2025 14:58:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
> 
> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
> 
> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.

I'm just trying to understand what is "underneath" this change. Throttling all events is not a target since it does not make sense.

Making it easy to plug in a new throttler for a new event would make more sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3196052544

From egahlin at openjdk.org  Mon Aug 18 10:40:17 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 18 Aug 2025 10:40:17 GMT
Subject: Integrated: 8365638: JFR: Add --exact for debugging out-of-order
 events
In-Reply-To: <u6nBVONJONXbZyr5CNMaP46nzcNsumsdusbc49xgcbc=.5219f3a8-fd82-42fd-b30e-106e413474ed@github.com>
References: <u6nBVONJONXbZyr5CNMaP46nzcNsumsdusbc49xgcbc=.5219f3a8-fd82-42fd-b30e-106e413474ed@github.com>
Message-ID: <J78VnLSBn48lQWIIUgZ9iR9FCezj0Y0venbS84onO8I=.c1c0a026-c25c-4282-a7ca-7b4c6db10884@github.com>

On Sun, 17 Aug 2025 18:34:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of PR that add --exact so the failure of a test can be debugged more easily. 
> 
> Testing: test/jdk/jdk/jfr/tool/TestPrintContextual.java
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: a42ba1ff
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a42ba1ff1a6c7c856323a8e2c54457fc3ddb3659
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8365638: JFR: Add --exact for debugging out-of-order events

Reviewed-by: shade

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

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

From mgronlun at openjdk.org  Mon Aug 18 10:41:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 10:41:11 GMT
Subject: RFR: 8365611: Throttle any JFR event
In-Reply-To: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
Message-ID: <EpoY2c-4ojoaplOIs2G6tEqfnl1goVdRotShmwWkiKc=.e55d1c99-4c7c-4204-903e-3c4dce6a2982@github.com>

On Fri, 15 Aug 2025 14:58:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
> 
> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
> 
> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.

Changes requested by mgronlun (Reviewer).

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 101:

> 99: }
> 100: 
> 101: // There is currently only two throttler instances, one for the jdk.ObjectAllocationSample event

Now we can remove this comment.

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 117:

> 115: 
> 116: JfrEventThrottler* JfrEventThrottler::create_throttler(JfrEventId id) {
> 117:   JfrEventThrottler* p = new JfrEventThrottler(id);

JfrEventThrottler is a JfrAdaptiveSampler that utilizes the JfrCHeapObj allocator, which can return nullptr during JFR initialization.

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.hpp line 53:

> 51: 
> 52:  public:
> 53:   static JfrEventThrottler* create_throttler(JfrEventId event_id);

Please make this private and add ThrottlerLookupTable as a friend.

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

PR Review: https://git.openjdk.org/jdk/pull/26801#pullrequestreview-3127803372
PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2282002313
PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2282014257
PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2281999373

From mgronlun at openjdk.org  Mon Aug 18 10:46:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 10:46:11 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <O2_Cl-3aAkgpwc3Hv51FD-TzGgz4N1MCJ7gTKgawtiQ=.dfdf83a8-5862-4bf6-9ccf-5260aa1ebd60@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

A blanket HotSpot change that does not add much value, but instead creates an unnecessary dependency that will make development of JFR more problematic.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3196133193

From shade at openjdk.org  Mon Aug 18 11:35:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 11:35:12 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <O2_Cl-3aAkgpwc3Hv51FD-TzGgz4N1MCJ7gTKgawtiQ=.dfdf83a8-5862-4bf6-9ccf-5260aa1ebd60@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <O2_Cl-3aAkgpwc3Hv51FD-TzGgz4N1MCJ7gTKgawtiQ=.dfdf83a8-5862-4bf6-9ccf-5260aa1ebd60@github.com>
Message-ID: <uPYT-gAjgHAmdqfErL0fxKAF0SKoB7SJs-PlD1aCYuc=.2fe06592-d950-4871-875b-3d691c19689e@github.com>

On Mon, 18 Aug 2025 10:43:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> A blanket HotSpot change that does not add much value, but instead creates an unnecessary dependency that will make development of JFR more problematic.

It is not "blanket", is it? The includes get sorted component by component, and many components in Hotspot have already been processed, with a long view of entire Hotspot being covered. Overall, while I agree maintaining the include order hygiene would require additional work, that is true for _any_ hygiene work. It does not mean we refrain from it. What we do is to make sure the detection is as prompt and the fixes are as easy as practically possible.

Also, there is already a "dependency" on source tests. For example, if you write `NULL` anywhere in JFR code, this test would fail: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/sources/TestNoNULL.java. You'll get a failure with any `tier1` testing, including GHA checks. The include order test is not that different.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3196274329

From shade at openjdk.org  Mon Aug 18 11:43:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 11:43:12 GMT
Subject: RFR: 8365550: JFR: The active-settings view should not use
 LAST_BATCH
In-Reply-To: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
References: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
Message-ID: <OWaRtw14fG9Y_R_eBYKvYTK2wEOr17FVoNDmauAt9T0=.fb2e5bb1-b5d9-48bf-a650-13aaf6e4f584@github.com>

On Sun, 17 Aug 2025 19:08:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that updates the active-settings query to use LAST instead of LAST_BATCH?
> 
> The problem with using LAST_BATCH is that it doesn?t work with older recordings where the jdk.ActiveSetting event was not emitted as a batch, or with later recordings where a single setting is changed programmatically.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This makes sense, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26813#pullrequestreview-3128025057

From mgronlun at openjdk.org  Mon Aug 18 11:47:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 11:47:12 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <Bwv55MwGS2Yktt_mYx_EV2ihHspldsPmnybSp_WzlBc=.1a4a037f-4e10-4bad-a270-885c085fbab8@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

That is a blanket change, yes - it means all of HotSpot being covered.

In my opinion, it adds little value and instead creates more work for us that develop JFR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3196311191

From shade at openjdk.org  Mon Aug 18 11:51:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 11:51:13 GMT
Subject: RFR: 8365636: JFR: Minor cleanup [v2]
In-Reply-To: <CwZBoWpO9ESJp3XxxPuA84UPxMNCQ2lM8kgf33byzkM=.34a673f0-8482-4d20-b0ec-3137619d5326@github.com>
References: <9mu1ONkHASHyy8qEo4G7oaIvM0R-n717TOsQMGAh6vg=.62dceb2c-826a-4798-81a3-81adb05e544d@github.com>
 <CwZBoWpO9ESJp3XxxPuA84UPxMNCQ2lM8kgf33byzkM=.34a673f0-8482-4d20-b0ec-3137619d5326@github.com>
Message-ID: <Kbzt_8av1CGrXs0ZIP3RM0svidT-YQJNBvYUQ6DAw2Y=.38b206fb-ed44-4eae-982d-193182946b24@github.com>

On Mon, 18 Aug 2025 07:00:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of Pr That cleans up various stuff (unnecessary imports, typos etc).
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compare with class instead incorrect/reversed isAssignableFrom

Looks fine to me, I just have one question:

src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java line 186:

> 184:         }
> 185:         T object = getValue(name);
> 186:         if (object == null || object.getClass() == clazz) {

Comprehension check: looks like do not need to check hierarchy at all, since we only ever call `getTyped` with `final` classes, correct?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26811#pullrequestreview-3128046871
PR Review Comment: https://git.openjdk.org/jdk/pull/26811#discussion_r2282171802

From mgronlun at openjdk.org  Mon Aug 18 11:53:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 11:53:12 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <Bwv55MwGS2Yktt_mYx_EV2ihHspldsPmnybSp_WzlBc=.1a4a037f-4e10-4bad-a270-885c085fbab8@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <Bwv55MwGS2Yktt_mYx_EV2ihHspldsPmnybSp_WzlBc=.1a4a037f-4e10-4bad-a270-885c085fbab8@github.com>
Message-ID: <A1OnGhvxHIYml1mCRzGLS-4E2FKyU3p3Rd9TY7u-FcQ=.11f460cf-dab1-46bd-87ff-9f75a9c329c1@github.com>

On Mon, 18 Aug 2025 11:44:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> That is a blanket change, yes - it means all of HotSpot being covered.
> 
> In my opinion, it adds little value and instead creates more work for us that develop JFR.

But if  "someone" has said this is good to do for all of HotSpot (who?) we can accommodate to the general will.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3196327634

From shade at openjdk.org  Mon Aug 18 12:06:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 12:06:12 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <Bwv55MwGS2Yktt_mYx_EV2ihHspldsPmnybSp_WzlBc=.1a4a037f-4e10-4bad-a270-885c085fbab8@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <Bwv55MwGS2Yktt_mYx_EV2ihHspldsPmnybSp_WzlBc=.1a4a037f-4e10-4bad-a270-885c085fbab8@github.com>
Message-ID: <Ly5z_aY0o4eRTOxxjZNvRQWbsdgAbD03qbuAB8hqh4A=.a8b5c5f3-3261-4ed8-8081-05b8e3fa206d@github.com>

On Mon, 18 Aug 2025 11:44:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> In my opinion, it adds little value and instead creates more work for us that develop JFR.

Noted, but I think this overestimates the amount of work. If the test would fail in `tier1` (which the required pre-integration testing, runs even in GHA), in 99% of cases you either sort the includes by hand, or run the tool in the way that test failure itself would guide you through: https://github.com/openjdk/jdk/blob/c1198bba0e8cbdaa47c821263d122d0ba4dd6759/test/hotspot/jtreg/sources/TestIncludesAreSorted.java#L91-L93

> But if "someone" has said this is good to do for all of HotSpot (who?) we can accommodate to the general will.

Take a look at [Hotspot Style Guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files): "Keep the include lines within a section alphabetically sorted by their lowercase value. If an include must be out of order for correctness, suffix with it a comment such as // do not reorder. Source code processing tools can also use this hint."

Both the original [JDK-8352645](https://bugs.openjdk.org/browse/JDK-8352645), and the related tasks from it maintain the same consensus: sort the includes, make sure the test would keep them sorted.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3196365263

From stuefe at openjdk.org  Mon Aug 18 13:33:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 18 Aug 2025 13:33:11 GMT
Subject: RFR: 8365611: Throttle any JFR event
In-Reply-To: <EpoY2c-4ojoaplOIs2G6tEqfnl1goVdRotShmwWkiKc=.e55d1c99-4c7c-4204-903e-3c4dce6a2982@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <EpoY2c-4ojoaplOIs2G6tEqfnl1goVdRotShmwWkiKc=.e55d1c99-4c7c-4204-903e-3c4dce6a2982@github.com>
Message-ID: <bOxt4hvc9xPO1JOpzMu62lRTA2WIMjfcU8T_petcMCo=.3b855d08-49ce-4637-ba90-b28fe7ff42b6@github.com>

On Mon, 18 Aug 2025 10:37:10 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
>> 
>> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
>> 
>> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 117:
> 
>> 115: 
>> 116: JfrEventThrottler* JfrEventThrottler::create_throttler(JfrEventId id) {
>> 117:   JfrEventThrottler* p = new JfrEventThrottler(id);
> 
> JfrEventThrottler is a JfrAdaptiveSampler that utilizes the JfrCHeapObj allocator, which can return nullptr during JFR initialization.

Are you sure? 

..

Ah, I see it now. You end up calling the nothrow variant of `CHeapObjBase::operator new`. And treat malloc OOMs during initialization as non-fatal, runtime malloc OOMs as fatal.

May I ask why you bother? Is the memory footprint of JFR really so high as to make this distinction worthwhile? (As in "if JVM does not come up with JFR, the footprint without JFR will be so much lower that it is worth trying"?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2282403845

From mgronlun at openjdk.org  Mon Aug 18 13:40:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 13:40:13 GMT
Subject: RFR: 8365550: JFR: The active-settings view should not use
 LAST_BATCH
In-Reply-To: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
References: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
Message-ID: <LiT4CwDPXC8TAhxF1GKC8ZtWGwUVqrV_j6CUaQ2LFOA=.7f1515f1-e8f3-4167-91ad-e85fda4f5789@github.com>

On Sun, 17 Aug 2025 19:08:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that updates the active-settings query to use LAST instead of LAST_BATCH?
> 
> The problem with using LAST_BATCH is that it doesn?t work with older recordings where the jdk.ActiveSetting event was not emitted as a batch, or with later recordings where a single setting is changed programmatically.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26813#pullrequestreview-3128406055

From stuefe at openjdk.org  Mon Aug 18 13:41:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 18 Aug 2025 13:41:51 GMT
Subject: RFR: 8365611: Throttle any JFR event [v2]
In-Reply-To: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
Message-ID: <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>

> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
> 
> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
> 
> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Markus Feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26801/files
  - new: https://git.openjdk.org/jdk/pull/26801/files/34c340fb..3cb74305

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

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

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

From mgronlun at openjdk.org  Mon Aug 18 13:42:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 13:42:13 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <v2dtJuBA9Yu8AYPv-2u__c_8ZKYxcf24rq4EGMavqcA=.983874f8-1d5e-403b-9031-94ef915f4ac5@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

That the test is integrated with GHA is the good part.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3196955412

From jpai at openjdk.org  Mon Aug 18 13:43:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 13:43:23 GMT
Subject: Integrated: 8365533: Remove outdated jdk.internal.javac package export
 to several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <rGcu60RTmmtT0IhftuIgwKa33UyYiopBA9D4Oal7op0=.b4692860-d62b-426b-a248-63030d11fa6f@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

This pull request has now been integrated.

Changeset: 81c6ed38
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81c6ed38828940d51c872c354c29dc13ed62a5ac
Stats:     27 lines in 7 files changed: 0 ins; 22 del; 5 mod

8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Reviewed-by: alanb, liach

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

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

From mgronlun at openjdk.org  Mon Aug 18 13:45:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 13:45:12 GMT
Subject: RFR: 8365611: Throttle any JFR event [v2]
In-Reply-To: <bOxt4hvc9xPO1JOpzMu62lRTA2WIMjfcU8T_petcMCo=.3b855d08-49ce-4637-ba90-b28fe7ff42b6@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <EpoY2c-4ojoaplOIs2G6tEqfnl1goVdRotShmwWkiKc=.e55d1c99-4c7c-4204-903e-3c4dce6a2982@github.com>
 <bOxt4hvc9xPO1JOpzMu62lRTA2WIMjfcU8T_petcMCo=.3b855d08-49ce-4637-ba90-b28fe7ff42b6@github.com>
Message-ID: <dOJJ7CKa-vk1zOB7pauPcySS2dUhK28weCYD_77NtEs=.2b1b7457-e212-49db-a957-5d94ef4c63a9@github.com>

On Mon, 18 Aug 2025 13:30:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 117:
>> 
>>> 115: 
>>> 116: JfrEventThrottler* JfrEventThrottler::create_throttler(JfrEventId id) {
>>> 117:   JfrEventThrottler* p = new JfrEventThrottler(id);
>> 
>> JfrEventThrottler is a JfrAdaptiveSampler that utilizes the JfrCHeapObj allocator, which can return nullptr during JFR initialization.
>
> Are you sure? 
> 
> ..
> 
> Ah, I see it now. You end up calling the nothrow variant of `CHeapObjBase::operator new`. And treat malloc OOMs during initialization as non-fatal, runtime malloc OOMs as fatal.
> 
> May I ask why you bother? Is the memory footprint of JFR really so high as to make this distinction worthwhile? (As in "if JVM does not come up with JFR, the footprint without JFR will be so much lower that it is worth trying"?)

Because JFR can be started dynamically during runtime, from the outside.

We don't want someone killing the JVM by starting JFR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2282441434

From jpai at openjdk.org  Mon Aug 18 14:23:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 14:23:16 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
 <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>
Message-ID: <GyH3rTfRAPhV2t0UQNd3v5tucgnj1GlhkNTLz30emJ4=.075a85a3-06ad-40ef-8cfc-94be7c608801@github.com>

On Mon, 18 Aug 2025 06:45:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > In addition, `PreviewFeature.Feature` enum has a few obsolete entries ... Now the boot JDK is min 24, and a few of the features are already permanent in 24.
> 
> I'll file a separate issue to clean those up.

I've now filed https://bugs.openjdk.org/browse/JDK-8365699 to track this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3197140201

From mgronlun at openjdk.org  Mon Aug 18 14:58:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 14:58:12 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <qKDQEWwxWKUgeR20GzTS5An4frvTr4YiaeS1RxdiABo=.7e3eb96c-774e-4f7f-ad84-8e8cb21dbb0b@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26800#pullrequestreview-3128733760

From mgronlun at openjdk.org  Mon Aug 18 15:05:16 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 18 Aug 2025 15:05:16 GMT
Subject: RFR: 8365611: Throttle any JFR event [v2]
In-Reply-To: <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
Message-ID: <uzptLK9eAFPIR1SQgTNq1FrS_JzHL1z6ixnPNez2rQ8=.cd8b1f87-30fe-4ae2-b9d6-ff1bd68d9a8b@github.com>

On Mon, 18 Aug 2025 13:41:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
>> 
>> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
>> 
>> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Markus Feedback

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26801#pullrequestreview-3128764724

From duke at openjdk.org  Mon Aug 18 15:20:13 2025
From: duke at openjdk.org (duke)
Date: Mon, 18 Aug 2025 15:20:13 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <NRqXNbUFTq2cH_X_ELdPeQB_Es_hoHl_mE8QsmRp_Ys=.6dc5a79d-4858-416f-aee2-87723c10f33a@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

@fandreuz 
Your change (at version 3bfcf13525c3eb1c1ff5a5e1e37fdc8de7323995) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3197353485

From egahlin at openjdk.org  Mon Aug 18 15:42:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 18 Aug 2025 15:42:13 GMT
Subject: RFR: 8365550: JFR: The active-settings view should not use
 LAST_BATCH
In-Reply-To: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
References: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
Message-ID: <gZCdR4jhBaRJBT0mNJPtjkTjqCYW5OO5bAryaNI4YQs=.6844afac-d455-46cc-917c-ce45f9ec2c0d@github.com>

On Sun, 17 Aug 2025 19:08:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that updates the active-settings query to use LAST instead of LAST_BATCH?
> 
> The problem with using LAST_BATCH is that it doesn?t work with older recordings where the jdk.ActiveSetting event was not emitted as a batch, or with later recordings where a single setting is changed programmatically.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26813#issuecomment-3197445781

From egahlin at openjdk.org  Mon Aug 18 15:46:15 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 18 Aug 2025 15:46:15 GMT
Subject: Integrated: 8365550: JFR: The active-settings view should not use
 LAST_BATCH
In-Reply-To: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
References: <zZbg5CqOoWH1DR5qjcI2pVJO1xEBQXF5BC2FnnZwjoA=.42d56a49-e89e-4306-b256-577e02b1ca13@github.com>
Message-ID: <kgfF45by8S9V58js3Gz4_XUrrgtealyGmcg0CkbOBgI=.c2b2c6aa-b8ec-40f4-bb16-c3ddbfef0088@github.com>

On Sun, 17 Aug 2025 19:08:58 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that updates the active-settings query to use LAST instead of LAST_BATCH?
> 
> The problem with using LAST_BATCH is that it doesn?t work with older recordings where the jdk.ActiveSetting event was not emitted as a batch, or with later recordings where a single setting is changed programmatically.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

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

8365550: JFR: The active-settings view should not use LAST_BATCH

Reviewed-by: shade, mgronlun

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

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

From shade at openjdk.org  Mon Aug 18 15:49:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Aug 2025 15:49:14 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <4LAyQOzRNUaavo8sKS2fr-ojornnGkgCzhmaqJOAE_s=.d6443b31-668e-4991-9ec0-03268f88b5df@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

For Hotspot changes, you need to wait 24 hours, so people around the globe could take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3197465672

From duke at openjdk.org  Mon Aug 18 15:56:13 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 18 Aug 2025 15:56:13 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <4LAyQOzRNUaavo8sKS2fr-ojornnGkgCzhmaqJOAE_s=.d6443b31-668e-4991-9ec0-03268f88b5df@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <4LAyQOzRNUaavo8sKS2fr-ojornnGkgCzhmaqJOAE_s=.d6443b31-668e-4991-9ec0-03268f88b5df@github.com>
Message-ID: <WJCLS8VWSN3hzOh1wQ80yOVigwCOtyyzavh-pf0rvGY=.ee63e8c1-b21d-4c82-af3a-eba711ec7008@github.com>

On Mon, 18 Aug 2025 15:46:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For Hotspot changes, you need to wait 24 hours, so people around the globe could take a look.

Sure, so is it 24 hours after getting approval? I thought it's 24 hours after opening the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3197491190

From egahlin at openjdk.org  Mon Aug 18 19:08:02 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 18 Aug 2025 19:08:02 GMT
Subject: RFR: 8365636: JFR: Minor cleanup [v2]
In-Reply-To: <Kbzt_8av1CGrXs0ZIP3RM0svidT-YQJNBvYUQ6DAw2Y=.38b206fb-ed44-4eae-982d-193182946b24@github.com>
References: <9mu1ONkHASHyy8qEo4G7oaIvM0R-n717TOsQMGAh6vg=.62dceb2c-826a-4798-81a3-81adb05e544d@github.com>
 <CwZBoWpO9ESJp3XxxPuA84UPxMNCQ2lM8kgf33byzkM=.34a673f0-8482-4d20-b0ec-3137619d5326@github.com>
 <Kbzt_8av1CGrXs0ZIP3RM0svidT-YQJNBvYUQ6DAw2Y=.38b206fb-ed44-4eae-982d-193182946b24@github.com>
Message-ID: <YEpUjM-7WCtxVx846EDNnZk_qv5aU6ZOhtJyEIoFVpU=.8534ca23-81aa-4e3c-a725-525cf1ef74f9@github.com>

On Mon, 18 Aug 2025 11:48:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Compare with class instead incorrect/reversed isAssignableFrom
>
> src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java line 186:
> 
>> 184:         }
>> 185:         T object = getValue(name);
>> 186:         if (object == null || object.getClass() == clazz) {
> 
> Comprehension check: looks like do not need to check hierarchy at all, since we only ever call `getTyped` with `final` classes, correct?

We only use the method with known leaf classes, e.g. Long and RecordedThread, which all happen to be final, but hypothetically they would not need to be. The class should match the type that the parser has instantiated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26811#discussion_r2283210921

From stuefe at openjdk.org  Tue Aug 19 05:02:36 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 19 Aug 2025 05:02:36 GMT
Subject: RFR: 8365611: Throttle any JFR event [v2]
In-Reply-To: <uzptLK9eAFPIR1SQgTNq1FrS_JzHL1z6ixnPNez2rQ8=.cd8b1f87-30fe-4ae2-b9d6-ff1bd68d9a8b@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
 <uzptLK9eAFPIR1SQgTNq1FrS_JzHL1z6ixnPNez2rQ8=.cd8b1f87-30fe-4ae2-b9d6-ff1bd68d9a8b@github.com>
Message-ID: <JWAEfZU889h_KTBUX0fV1p60cth3je88tzO-0hPg6Cw=.48d2a7fe-58ad-4603-8739-80fa4a039f4c@github.com>

On Mon, 18 Aug 2025 15:02:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Looks good.

Thank you, @mgronlun

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3199209692

From egahlin at openjdk.org  Tue Aug 19 06:29:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Aug 2025 06:29:36 GMT
Subject: RFR: 8365611: Throttle any JFR event [v2]
In-Reply-To: <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
Message-ID: <__DJ7zVbtW9xBpbAVnjqKBfiyce5pX3lQCWT6Ma5T7I=.802e961b-c009-4ffc-8b0a-b13d1d5180fc@github.com>

On Mon, 18 Aug 2025 13:41:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
>> 
>> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
>> 
>> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Markus Feedback

Could we change the title of the issue? "Throttle any JFR event" is not really what the PR does.

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3199386101

From stuefe at openjdk.org  Tue Aug 19 06:37:36 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 19 Aug 2025 06:37:36 GMT
Subject: RFR: 8365611: Throttle any JFR event [v2]
In-Reply-To: <__DJ7zVbtW9xBpbAVnjqKBfiyce5pX3lQCWT6Ma5T7I=.802e961b-c009-4ffc-8b0a-b13d1d5180fc@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
 <__DJ7zVbtW9xBpbAVnjqKBfiyce5pX3lQCWT6Ma5T7I=.802e961b-c009-4ffc-8b0a-b13d1d5180fc@github.com>
Message-ID: <Gu9bTl6R_xVqBMMnnL1AiXxOxVUR6MIqAoBPgjzhZYU=.2fb1b89e-3b80-426f-aae3-eb34cb6f0f10@github.com>

On Tue, 19 Aug 2025 06:27:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could we change the title of the issue? "Throttle any JFR event" is not really what the PR does. How about "Use lookup table for JfrEventThrottler"?

Yes I thought so too. Will do.

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3199413006

From egahlin at openjdk.org  Tue Aug 19 06:45:39 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Aug 2025 06:45:39 GMT
Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
Message-ID: <RiNISYo5_WuB-RmcBLU0fIixnotyWCTihF2Q5nk7_Jo=.20ce6de5-f25b-4c60-b5f1-b3a898a335d4@github.com>

On Wed, 13 Aug 2025 09:42:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This provides the following new metrics:
> - `ProcessSize` event (new, periodic) 
>   - vsize (for analyzing address-space fragmentation issues)
>   - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat)
>   - peak RSS 
>   - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing)
>   - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size)
> - `LibcStatistics` (new, periodic)
>   - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading)
>   - retained malloc size (super-important for the same reason)
>   - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`)
> - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims)
>    - RSS before and RSS after
>    - RSS recovered by this trim
>    - whether it was an automatic or manual trim
>    - duration
> - `JavaThreadStatistic`
>   - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.)
>   - nonJava thread counter (new field) (needed to interprete the os thread counter)
> 
> Notes:
> - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it.
> 
> - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue.
> 
> I provided implementations, as far as possible, to Linux, MacOS and Windows.
> 
> Testing:
> - ran the new tests manually and as part of GHAs

What is the problem with adding RSS metrics to the existing ResidentSetSize event?

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3199438538

From stuefe at openjdk.org  Tue Aug 19 07:01:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 19 Aug 2025 07:01:40 GMT
Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <RiNISYo5_WuB-RmcBLU0fIixnotyWCTihF2Q5nk7_Jo=.20ce6de5-f25b-4c60-b5f1-b3a898a335d4@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
 <RiNISYo5_WuB-RmcBLU0fIixnotyWCTihF2Q5nk7_Jo=.20ce6de5-f25b-4c60-b5f1-b3a898a335d4@github.com>
Message-ID: <cmWFUKDnTozlqMCYqQbElk93BYWrhbr71PPONLFaXV0=.66103679-6413-48dd-a08e-91f2eea61c21@github.com>

On Tue, 19 Aug 2025 06:43:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> What is the problem with adding RSS metrics to the existing ResidentSetSize event?

You mean adding the vsize, swap etc fields to ResidentSetSize?

I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?) 

I also thought about splitting them up and add one event per value, following the "ResidentSetSize" pattern. So, one event for  "VirtualSize", one for "Swap" etc. Apart from not liking the fine granularity, having these fields grouped in one event has multiple advantages. Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance).

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3199479458

From shade at openjdk.org  Tue Aug 19 10:13:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Aug 2025 10:13:41 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <WJCLS8VWSN3hzOh1wQ80yOVigwCOtyyzavh-pf0rvGY=.ee63e8c1-b21d-4c82-af3a-eba711ec7008@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <4LAyQOzRNUaavo8sKS2fr-ojornnGkgCzhmaqJOAE_s=.d6443b31-668e-4991-9ec0-03268f88b5df@github.com>
 <WJCLS8VWSN3hzOh1wQ80yOVigwCOtyyzavh-pf0rvGY=.ee63e8c1-b21d-4c82-af3a-eba711ec7008@github.com>
Message-ID: <z6HV5fTy5N_WXWDQISonMIuRLRqe764XJQFaZcRZrfQ=.5e36414f-c19d-4c5d-b118-910442f43193@github.com>

On Mon, 18 Aug 2025 15:53:50 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> > For Hotspot changes, you need to wait 24 hours, so people around the globe could take a look.
> 
> Sure, so is it 24 hours after getting approval? I thought it's 24 hours after opening the PR.

Ah no, you're right: https://openjdk.org/guide/#life-of-a-pr -- 24 hours is the bare minimum. It gets a bit murky around holidays/weekends, as people take time off or checkout on Friday earlier. But this looks fine.

You also need a Review from one area expert (for JFR, Markus definitely qualifies), and another Review from any other reviewer. I'll do it shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3200112542

From shade at openjdk.org  Tue Aug 19 10:30:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Aug 2025 10:30:49 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <8zVTQIeCpGMKTLXckQvoHyhtCulVA-H1uzB5xSljT3w=.6ea182fe-edaf-42d3-a56c-bb76a16b69dd@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

Looks fine, but I think we should refrain from deleting the includes here.

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

PR Review: https://git.openjdk.org/jdk/pull/26800#pullrequestreview-3131682406

From shade at openjdk.org  Tue Aug 19 10:30:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Aug 2025 10:30:52 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <d4RYBJvvXp9nGgw05JoMN41n_8d0PDmlvShcvqjDx9M=.be58949e-f5a2-4844-9114-5f2e6a48d352@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <d4RYBJvvXp9nGgw05JoMN41n_8d0PDmlvShcvqjDx9M=.be58949e-f5a2-4844-9114-5f2e6a48d352@github.com>
Message-ID: <3RwSwd93WGbyHLsMyrRegNwyyG_Z8TyRKVb4LeQWKZ4=.c0e8b7dc-dca4-48ea-9ddf-4b00f102e148@github.com>

On Fri, 15 Aug 2025 13:32:11 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
>> 
>> Testing:
>> - [x] tier1
>> - [x] tier2
>
> src/hotspot/share/jfr/periodic/jfrOSInterface.cpp line 35:
> 
>> 33: #include "utilities/ostream.hpp"
>> 34: 
>> 35: #include <stdlib.h> // for environment variables
> 
> I couldn't find any usage for this include, let me know if it should stay. It's been here for a long time: https://github.com/openjdk/jdk/commit/a060be188df894ed5c26fc12fc9e902f9af32bd3

I suspect it has to do with `generate_environment_variables_events()` here:
https://github.com/openjdk/jdk/pull/26800/files#diff-2d77a162387fd8e8a57c631e91543fa87889a7ef867725ecbfa37804b678fdabR83

Which does not have any implementation. I cannot find any code history about this as well; looks like it was unimplemented from day 1:


% git log -p --follow src/hotspot/ | grep generate_environment_variables_events      
+  void generate_environment_variables_events();


So maybe keep this one intact, and submit another quick RFE to clean up both the header inclusion and the dead method declarations? It would also match the synopsis for current PR ("sort") better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26800#discussion_r2284818979

From duke at openjdk.org  Tue Aug 19 10:53:25 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 19 Aug 2025 10:53:25 GMT
Subject: RFR: 8365610: Sort share/jfr includes [v2]
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <ij4JgZwhG9OOCnIDbuq_sp4MephKo-hWp0HP9ZifDCE=.10aa1b76-63cb-4544-91d2-2f98a500b79f@github.com>

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

Francesco Andreuzzi 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:

 - revert
 - Merge branch 'master' into JDK-8365610
 - reorder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26800/files
  - new: https://git.openjdk.org/jdk/pull/26800/files/3bfcf135..f734135f

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

  Stats: 5591 lines in 165 files changed: 4356 ins; 612 del; 623 mod
  Patch: https://git.openjdk.org/jdk/pull/26800.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26800/head:pull/26800

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

From duke at openjdk.org  Tue Aug 19 10:53:25 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 19 Aug 2025 10:53:25 GMT
Subject: RFR: 8365610: Sort share/jfr includes [v2]
In-Reply-To: <3RwSwd93WGbyHLsMyrRegNwyyG_Z8TyRKVb4LeQWKZ4=.c0e8b7dc-dca4-48ea-9ddf-4b00f102e148@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <d4RYBJvvXp9nGgw05JoMN41n_8d0PDmlvShcvqjDx9M=.be58949e-f5a2-4844-9114-5f2e6a48d352@github.com>
 <3RwSwd93WGbyHLsMyrRegNwyyG_Z8TyRKVb4LeQWKZ4=.c0e8b7dc-dca4-48ea-9ddf-4b00f102e148@github.com>
Message-ID: <6UHdI2ZFRFPb4H5155iarl1OoP3HTCaKA4pkZJJk5lc=.5d98b15f-232c-4501-b834-ad8d1f275f7f@github.com>

On Tue, 19 Aug 2025 10:25:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/jfrOSInterface.cpp line 35:
>> 
>>> 33: #include "utilities/ostream.hpp"
>>> 34: 
>>> 35: #include <stdlib.h> // for environment variables
>> 
>> I couldn't find any usage for this include, let me know if it should stay. It's been here for a long time: https://github.com/openjdk/jdk/commit/a060be188df894ed5c26fc12fc9e902f9af32bd3
>
> I suspect it has to do with `generate_environment_variables_events()` here:
> https://github.com/openjdk/jdk/pull/26800/files#diff-2d77a162387fd8e8a57c631e91543fa87889a7ef867725ecbfa37804b678fdabR83
> 
> Which does not have any implementation. I cannot find any code history about this as well; looks like it was unimplemented from day 1:
> 
> 
> % git log -p --follow src/hotspot/ | grep generate_environment_variables_events      
> +  void generate_environment_variables_events();
> 
> 
> So maybe keep this one intact, and submit another quick RFE to clean up both the header inclusion and the dead method declarations? It would also match the synopsis for current PR ("sort") better.

Sure: f734135f2ecc399ef2aa2a2d150ebba454e5776d

https://bugs.openjdk.org/browse/JDK-8365782

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26800#discussion_r2284870134

From mgronlun at openjdk.org  Tue Aug 19 11:58:43 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 19 Aug 2025 11:58:43 GMT
Subject: RFR: 8365614: JFR: Improve PrettyWriter::printValue
In-Reply-To: <JLZQnil5Pk8mxdt56AQ_Bccqf2CTtJ_zx5vOfrpUCIs=.49157f71-aa06-4fc5-8d0d-7696f98faa3b@github.com>
References: <JLZQnil5Pk8mxdt56AQ_Bccqf2CTtJ_zx5vOfrpUCIs=.49157f71-aa06-4fc5-8d0d-7696f98faa3b@github.com>
Message-ID: <rxEIu3idlDXHkDYbPjfm53XhzRkJSfuCXaMwQGnFFOs=.90a0d90e-4545-43f8-9b79-e5b73f6c989c@github.com>

On Sun, 17 Aug 2025 11:30:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR  that simplifies the PrettyWriter::printValue method so it uses switch expression. It also changes so null is never passed to the method, making the code more robust.
> 
> Testing: jdk/jdk/jfr  + manual comparison of output before and after so it hasn't changed

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26810#pullrequestreview-3131991254

From egahlin at openjdk.org  Tue Aug 19 14:48:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Aug 2025 14:48:56 GMT
Subject: Integrated: 8365636: JFR: Minor cleanup
In-Reply-To: <9mu1ONkHASHyy8qEo4G7oaIvM0R-n717TOsQMGAh6vg=.62dceb2c-826a-4798-81a3-81adb05e544d@github.com>
References: <9mu1ONkHASHyy8qEo4G7oaIvM0R-n717TOsQMGAh6vg=.62dceb2c-826a-4798-81a3-81adb05e544d@github.com>
Message-ID: <BLxcnEEaYgyPZgmdBYlfzuKiox1bbdo_p1MqUck4BG0=.ebc5f64a-899b-4b16-a813-513e161eb978@github.com>

On Sun, 17 Aug 2025 17:40:36 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of Pr That cleans up various stuff (unnecessary imports, typos etc).
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 0b2d0817
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b2d0817f14895102600744670e4a6d4764b0259
Stats:     89 lines in 34 files changed: 1 ins; 16 del; 72 mod

8365636: JFR: Minor cleanup

Reviewed-by: shade

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

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

From shade at openjdk.org  Tue Aug 19 15:11:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Aug 2025 15:11:45 GMT
Subject: RFR: 8365610: Sort share/jfr includes [v2]
In-Reply-To: <ij4JgZwhG9OOCnIDbuq_sp4MephKo-hWp0HP9ZifDCE=.10aa1b76-63cb-4544-91d2-2f98a500b79f@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <ij4JgZwhG9OOCnIDbuq_sp4MephKo-hWp0HP9ZifDCE=.10aa1b76-63cb-4544-91d2-2f98a500b79f@github.com>
Message-ID: <P4M9xcevY34FiAvTY0nl6PwYAyMCtbiNm3BeCNqf_SI=.6c5efc12-60a1-4dca-b27f-dde9ef515448@github.com>

On Tue, 19 Aug 2025 10:53:25 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
>> 
>> Testing:
>> - [x] tier1
>> - [x] tier2
>
> Francesco Andreuzzi 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:
> 
>  - revert
>  - Merge branch 'master' into JDK-8365610
>  - reorder

Looks fine, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26800#pullrequestreview-3132770097

From duke at openjdk.org  Tue Aug 19 15:19:39 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Tue, 19 Aug 2025 15:19:39 GMT
Subject: RFR: 8365610: Sort share/jfr includes
In-Reply-To: <z6HV5fTy5N_WXWDQISonMIuRLRqe764XJQFaZcRZrfQ=.5e36414f-c19d-4c5d-b118-910442f43193@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <4LAyQOzRNUaavo8sKS2fr-ojornnGkgCzhmaqJOAE_s=.d6443b31-668e-4991-9ec0-03268f88b5df@github.com>
 <WJCLS8VWSN3hzOh1wQ80yOVigwCOtyyzavh-pf0rvGY=.ee63e8c1-b21d-4c82-af3a-eba711ec7008@github.com>
 <z6HV5fTy5N_WXWDQISonMIuRLRqe764XJQFaZcRZrfQ=.5e36414f-c19d-4c5d-b118-910442f43193@github.com>
Message-ID: <oQ38bf25BeU0LDh-qwuzKRwreLgJjfgC2b4my3uX6Tc=.c24f241d-84b7-4eee-92ac-f0ba18547bc4@github.com>

On Tue, 19 Aug 2025 10:10:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> For Hotspot changes, you need to wait 24 hours, so people around the globe could take a look.
>> 
>> Sure, so is it 24 hours after getting approval? I thought it's 24 hours after opening the PR.
>
>> > For Hotspot changes, you need to wait 24 hours, so people around the globe could take a look.
>> 
>> Sure, so is it 24 hours after getting approval? I thought it's 24 hours after opening the PR.
> 
> Ah no, you're right: https://openjdk.org/guide/#life-of-a-pr -- 24 hours is the bare minimum. It gets a bit murky around holidays/weekends, as people take time off or checkout on Friday earlier. But this looks fine.
> 
> You also need a Review from one area expert (for JFR, Markus definitely qualifies), and another Review from any other reviewer. I'll do it shortly.

Thanks for your reviews @shipilev and @mgronlun !

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3201175425

From duke at openjdk.org  Tue Aug 19 15:19:41 2025
From: duke at openjdk.org (duke)
Date: Tue, 19 Aug 2025 15:19:41 GMT
Subject: RFR: 8365610: Sort share/jfr includes [v2]
In-Reply-To: <ij4JgZwhG9OOCnIDbuq_sp4MephKo-hWp0HP9ZifDCE=.10aa1b76-63cb-4544-91d2-2f98a500b79f@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
 <ij4JgZwhG9OOCnIDbuq_sp4MephKo-hWp0HP9ZifDCE=.10aa1b76-63cb-4544-91d2-2f98a500b79f@github.com>
Message-ID: <iNAvm6eWtiE_WtOAABJh9B_-gEtodt1G6gA37_yJWRY=.9ef607ea-7535-445a-bc0b-5dd88ba2e361@github.com>

On Tue, 19 Aug 2025 10:53:25 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
>> 
>> Testing:
>> - [x] tier1
>> - [x] tier2
>
> Francesco Andreuzzi 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:
> 
>  - revert
>  - Merge branch 'master' into JDK-8365610
>  - reorder

@fandreuz 
Your change (at version f734135f2ecc399ef2aa2a2d150ebba454e5776d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26800#issuecomment-3201182213

From egahlin at openjdk.org  Tue Aug 19 16:10:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Aug 2025 16:10:45 GMT
Subject: Integrated: 8365614: JFR: Improve PrettyWriter::printValue
In-Reply-To: <JLZQnil5Pk8mxdt56AQ_Bccqf2CTtJ_zx5vOfrpUCIs=.49157f71-aa06-4fc5-8d0d-7696f98faa3b@github.com>
References: <JLZQnil5Pk8mxdt56AQ_Bccqf2CTtJ_zx5vOfrpUCIs=.49157f71-aa06-4fc5-8d0d-7696f98faa3b@github.com>
Message-ID: <WTDIAwm_nuBbiqSvjgkZikVWuuyv-pwy1CiKkerWHyI=.bf723a88-36c2-4b04-8a3e-565e7d026aad@github.com>

On Sun, 17 Aug 2025 11:30:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR  that simplifies the PrettyWriter::printValue method so it uses switch expression. It also changes so null is never passed to the method, making the code more robust.
> 
> Testing: jdk/jdk/jfr  + manual comparison of output before and after so it hasn't changed

This pull request has now been integrated.

Changeset: 024292ac
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/024292ac4dde7e49816d82d5f8a30a3e11f44d18
Stats:     154 lines in 2 files changed: 23 ins; 66 del; 65 mod

8365614: JFR: Improve PrettyWriter::printValue

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Tue Aug 19 19:02:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 19 Aug 2025 19:02:36 GMT
Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <cmWFUKDnTozlqMCYqQbElk93BYWrhbr71PPONLFaXV0=.66103679-6413-48dd-a08e-91f2eea61c21@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
 <RiNISYo5_WuB-RmcBLU0fIixnotyWCTihF2Q5nk7_Jo=.20ce6de5-f25b-4c60-b5f1-b3a898a335d4@github.com>
 <cmWFUKDnTozlqMCYqQbElk93BYWrhbr71PPONLFaXV0=.66103679-6413-48dd-a08e-91f2eea61c21@github.com>
Message-ID: <YYtu5mqNoLQxNVt0i5NnDDxcbT0kF6xEBLqGmAxdwug=.5a986262-a3eb-4cc8-ac97-ac8405880176@github.com>

On Tue, 19 Aug 2025 06:58:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> You mean adding the vsize, swap etc fields to ResidentSetSize?
> 
> I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?)

I was thinking something like this:


<Event name="ResidentSetSize" category="Java Virtual Machine, Memory" ... >
  <Field type="ulong" contentType="bytes" name="size" .../>
  <Field type="ulong" contentType="bytes" name="peak" ..  />
  <Field type="ulong" contentType="bytes" name="anonymous"   />
  <Field type="ulong" contentType="bytes" name="file" />
  <Field type="ulong" contentType="bytes" name="sharedMemory"  />
</Event>


When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. 

>  Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. 

Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal.

These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future.

> It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance).

We should not sacrifice the design unless the overhead is significant.

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3201882624

From stuefe at openjdk.org  Wed Aug 20 05:24:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 20 Aug 2025 05:24:38 GMT
Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <YYtu5mqNoLQxNVt0i5NnDDxcbT0kF6xEBLqGmAxdwug=.5a986262-a3eb-4cc8-ac97-ac8405880176@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
 <RiNISYo5_WuB-RmcBLU0fIixnotyWCTihF2Q5nk7_Jo=.20ce6de5-f25b-4c60-b5f1-b3a898a335d4@github.com>
 <cmWFUKDnTozlqMCYqQbElk93BYWrhbr71PPONLFaXV0=.66103679-6413-48dd-a08e-91f2eea61c21@github.com>
 <YYtu5mqNoLQxNVt0i5NnDDxcbT0kF6xEBLqGmAxdwug=.5a986262-a3eb-4cc8-ac97-ac8405880176@github.com>
Message-ID: <FWcxyeLcziSTI84GXACo8UDovehDhqS6x-Y7XaUjc8s=.f0ec1b30-cec1-418e-9b61-f8e10fa14d36@github.com>

On Tue, 19 Aug 2025 18:59:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > You mean adding the vsize, swap etc fields to ResidentSetSize?
> > I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?)
> 
> I was thinking something like this:
> 
> ```
> <Event name="ResidentSetSize" category="Java Virtual Machine, Memory" ... >
>   <Field type="ulong" contentType="bytes" name="size" .../>
>   <Field type="ulong" contentType="bytes" name="peak" ..  />
>   <Field type="ulong" contentType="bytes" name="anonymous"   />
>   <Field type="ulong" contentType="bytes" name="file" />
>   <Field type="ulong" contentType="bytes" name="sharedMemory"  />
> </Event>
> ```

Hmm, yes, that would be one alternative.

> 
> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it.
> 
> > Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values.
> 
> Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal.
> 
> These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future.

I spent a lot of the time allotted to this PR deliberating on how exactly to shape the events. I didn't want just to jam them in. And I agree. I dislike it how tight the coupling is between the data model and the renderer in the case of JMC. It leads to many UI inconsistencies and gives the wrong motivation.

Unfortunately, we live in a world where JMC is the only serious and freely available tool, and where JFR protocol is not open, so I fear this is likely to stay that way.

In the case of this PR, an argument can be made for grouping OS-side process-related metrics together into one event. Doing it the way I did is not absurd; this is how these metrics are often presented: vsize+rss+swap, complementing each other and giving a holistic view of the OS side of process memory consumption?especially rss+swap. You need swap to be able to explain rss.

I also agonized about the platform-specific aspects of this. This is rather Linux-centric. But again, reality: Linux is by far the most important platform.

On Windows, for example, we can ask for the size of the commit charge. That is a nice complementary information. On Linux, we also have a commit charge (as in, how much of the process memory was committed by the OS, underlaid with swap according to the kernel overcommit rules). That would be useful to know, since it can explain native OOMs when the OS runs out of swap. But I don't see a way to obtain that information on Linux. Since I only have the number on Windows, I left it out. And I realize this is a bit arbitrary, since I included values I only get for Linux.

Shaping events the right way is hard, and I am thankful for any direction from your side.

> 
> > It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance).
> 
> We should not sacrifice the design unless the overhead is significant.

Hm, sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3204233221

From dholmes at openjdk.org  Wed Aug 20 12:28:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:28:38 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

Some alignment nits where you have added additional condition clauses.

Some of these are difficult to evaluate in isolation and will need review from the specific component areas.

src/hotspot/share/adlc/output_h.cpp line 1952:

> 1950:     }*/
> 1951:     else if( instr->is_ideal_copy() &&
> 1952:     (instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr) &&

Suggestion:

            (instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr) &&

src/hotspot/share/c1/c1_LinearScan.cpp line 4422:

> 4420: 
> 4421:   if ((cur != nullptr) &&
> 4422:   (cur->from() < split_pos)) {

Suggestion:

      (cur->from() < split_pos)) {

src/hotspot/share/nmt/mallocSiteTable.cpp line 172:

> 170:        index < pos_idx && head != nullptr;
> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
> 172:       (MallocSiteHashtableEntry*)head->next()) {}

This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1319:

> 1317:     log_if_needed("  ** not supported: arity=%d op=%s vlen=%d etype=%s atype=%s ismask=no",
> 1318:                     is_scatter, is_scatter ? "scatter" : "gather",
> 1319:                     num_elem, type2name(elem_bt), type2name(arr_type->elem()->array_element_basic_type()));

There is  a bug here but I'm not sure it is what you think it is.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26798#pullrequestreview-3136325292
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287976814
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287984002
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287993050
PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2287996530

From dholmes at openjdk.org  Wed Aug 20 12:32:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:32:42 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

I've added some additional mailing lists to ensure better coverage here.

Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206112684

From adinn at openjdk.org  Wed Aug 20 14:22:37 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 20 Aug 2025 14:22:37 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <mm_qPZgVNqoihxb53bJCzsnvmNg15xdfOr6tj3FcVvA=.cf3562a5-a2bf-4c6f-8250-fa07f2939143@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

I'm not clear that the original issue is necessarily a bug that needs fixing with a skip to the next else if case.

The justification for adding `instr->_matrule != nullptr && instr->_matrule->_rChild != nullptr` to the if branch test is that earlier code allows for the possibility that `instr->_matrule` might be null. However, that check is performed in an unconditional context for any value of `instr` whereas this specific else branch limits the circumstance to the case where `instr->is_ideal_copy()` is found to be true.

So, the prior test offers no guarantee that in this restricted case a null pointer should or should not be possible. The original design may assume that a successful test for `instr->is_ideal_copy()` ought to guarantee that both `instr->_matrule` and `instr->_matrule->_rChild` are non-null. That cannot be determined by the evidence offered. It can only be determined by looking at how instr is constructed.

So, rather than just skip to the next case we might need to handle this with an assert and fix whatever code is producing an ideal copy with null fields.

Given the level of analysis offered for this case I am suspicious as to whether the other cases tacked onto this issue ought to be accepted at face value without some justification as to why a null check and skip to the next case is correct.

I'm also wondering how and why all these cases and associated amendments were arrived at? Is this perhaps based on output from a code analysis tool (perhaps even a genAI tool). If so then I think 1) we ought to be told and 2) we ought to treat its recommendations with a very healthy dose of skepticism.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3206613521

From duke at openjdk.org  Wed Aug 20 16:54:40 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 20 Aug 2025 16:54:40 GMT
Subject: RFR: 8365611: Use lookup table for JfrEventThrottler [v2]
In-Reply-To: <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
Message-ID: <Qhzfi16yf8iZB_px98gb9v32ECO9LcP7Kae9NjE76A8=.e0a855c2-e248-4d8c-b139-a0d27fc0db18@github.com>

On Mon, 18 Aug 2025 13:41:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
>> 
>> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
>> 
>> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Markus Feedback

I think that the reasoning behind this change makes sense (to avoid the risk of high overhead for a Unsafe.allocateMemory event). I agree there is also immediate benefit in generalizing the throttler code rather than hardcoding for specific event types.

I've left a couple minor comments below:

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 103:

> 101: JfrEventThrottler* JfrEventThrottler::for_event(JfrEventId event_id) {
> 102:   JfrEventThrottler* const throttler = _throttler_table.at(event_id);
> 103:   assert(throttler != nullptr, "Event type %d has an unconfigured throttler", (int)event_id);

The call to configure throttlers originates from up in the Java level JFR code.  Would it be possible to attempt sampling when a throttler is created, but not yet configured? 

If this is possible, then it was possible before this PR too (not introduced here).

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 109:

> 107: void JfrEventThrottler::configure(JfrEventId event_id, int64_t sample_size, int64_t period_ms) {
> 108:   JfrEventThrottler* const throttler = _throttler_table.at(event_id);
> 109:   assert(throttler != nullptr, "Event type %d has an unconfigured throttler", (int)event_id);

Small nitpick: it's actually just checking that the throttler exists. We configure it on the next line.
If it doesn't make sense to make this distinction, feel free to ignore this.

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

Marked as reviewed by roberttoyonaga at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/26801#pullrequestreview-3137462451
PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2288759661
PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2288747936

From duke at openjdk.org  Wed Aug 20 17:24:45 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Wed, 20 Aug 2025 17:24:45 GMT
Subject: Integrated: 8365610: Sort share/jfr includes
In-Reply-To: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
References: <cvmhyrGqTrJqOOJKgB7T5DhIpHx-d9P1ZVEgl-9rb5o=.d8f68823-71c7-4fd1-9967-a57a43056c90@github.com>
Message-ID: <31mvWaEYnLUFv4czPcKW6vZKOzyJIEtEoWyFVcznVsE=.4b4c9da2-e537-44c0-ab94-635ed857be6e@github.com>

On Fri, 15 Aug 2025 13:30:33 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> This PR sorts the includes in hotspot/share/jfr using SortIncludes.java. I'm also adding the directory to TestIncludesAreSorted.
> 
> Testing:
> - [x] tier1
> - [x] tier2

This pull request has now been integrated.

Changeset: ecab52c0
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecab52c09b078201ebeb8d45c0982b0481e15dc3
Stats:     171 lines in 55 files changed: 82 ins; 87 del; 2 mod

8365610: Sort share/jfr includes

Reviewed-by: shade, mgronlun

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

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

From duke at openjdk.org  Wed Aug 20 20:00:37 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 20 Aug 2025 20:00:37 GMT
Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <FWcxyeLcziSTI84GXACo8UDovehDhqS6x-Y7XaUjc8s=.f0ec1b30-cec1-418e-9b61-f8e10fa14d36@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
 <RiNISYo5_WuB-RmcBLU0fIixnotyWCTihF2Q5nk7_Jo=.20ce6de5-f25b-4c60-b5f1-b3a898a335d4@github.com>
 <cmWFUKDnTozlqMCYqQbElk93BYWrhbr71PPONLFaXV0=.66103679-6413-48dd-a08e-91f2eea61c21@github.com>
 <YYtu5mqNoLQxNVt0i5NnDDxcbT0kF6xEBLqGmAxdwug=.5a986262-a3eb-4cc8-ac97-ac8405880176@github.com>
 <FWcxyeLcziSTI84GXACo8UDovehDhqS6x-Y7XaUjc8s=.f0ec1b30-cec1-418e-9b61-f8e10fa14d36@github.com>
Message-ID: <Qs7Q_Fvkz_LHENAVISVRQiDSRJl6sBCwfMnWbnAx_AU=.5562bf09-665d-4335-b246-4d974647e8b2@github.com>

On Wed, 20 Aug 2025 05:22:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> You mean adding the vsize, swap etc fields to ResidentSetSize?
>>> 
>>> I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?)
>> 
>> I was thinking something like this:
>> 
>> 
>> <Event name="ResidentSetSize" category="Java Virtual Machine, Memory" ... >
>>   <Field type="ulong" contentType="bytes" name="size" .../>
>>   <Field type="ulong" contentType="bytes" name="peak" ..  />
>>   <Field type="ulong" contentType="bytes" name="anonymous"   />
>>   <Field type="ulong" contentType="bytes" name="file" />
>>   <Field type="ulong" contentType="bytes" name="sharedMemory"  />
>> </Event>
>> 
>> 
>> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it. 
>> 
>>>  Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values. 
>> 
>> Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal.
>> 
>> These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future.
>> 
>>> It is also cheaper to obtain (just one parsing operation for /proc/meminfo, for instance).
>> 
>> We should not sacrifice the design unless the overhead is significant.
>
>> > You mean adding the vsize, swap etc fields to ResidentSetSize?
>> > I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?)
>> 
>> I was thinking something like this:
>> 
>> ```
>> <Event name="ResidentSetSize" category="Java Virtual Machine, Memory" ... >
>>   <Field type="ulong" contentType="bytes" name="size" .../>
>>   <Field type="ulong" contentType="bytes" name="peak" ..  />
>>   <Field type="ulong" contentType="bytes" name="anonymous"   />
>>   <Field type="ulong" contentType="bytes" name="file" />
>>   <Field type="ulong" contentType="bytes" name="sharedMemory"  />
>> </Event>
>> ```
> 
> Hmm, yes, that would be one alternative.
> 
>> 
>> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it.
>> 
>> > Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values.
>> 
>> Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal.
>> 
>> These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future.
> 
> I spent a lot of the time allotted to this PR deliberating on how exactly to shape the events. I didn't want just to jam them in. And I agree. I dislike it how tight the coupling is between the data model and the renderer in the case of JMC. It leads to many UI inconsistencies and gives the wrong motivation.
> 
> Unfortunately, we live in a world where JMC is the only serious and freely available tool, and where JFR protocol is not open, so I fear this is likely to stay that way.
> 
> In the case of this PR, an argument can be made for grouping OS-side process-related metrics together into one event. Doing it the way I did is not absurd; this is how these metrics are often presented: vsize+rss+swap, complementing each other and giving a holistic view of the OS side of process memory consumption?especially rss+swap. You need swap to be able to explain rss.
> 
> I also agonized about the platform-specific aspects of this. This is rather Linux-centric. But again, reality: Linux is by far the most important platform.
> 
> On Windows, for exa...

@tstuefe 
I think that putting those metrics (vsize, swap, rss, etc) under a new `ProcessSize` event (while not touching `jdk.ResidentSetSize`) makes sense. 
- This allows JMC to continue as normal
- And also keeps the relevant metrics together so they can be easily interpreted in relation to each other.
- @egahlin , is there a procedure for deprecating event types? Or are events permanent once introduced? If you decide to go this route, maybe it would be possible to mark the `jdk.ResidentSetSize` event for deprecation at some point in the future to allow JMC time to eventually switch over to using the new event for its charts? 


> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? 

 I think this new swap data is process-specific so is not already covered by `jdk.SwapSpace`, which shows the max amount available and how much is currently free to the OS.  
I think it could be reasonable to leave the process' swap data in `ProcessSize` rather than the `jdk.SwapSpace` which contains data for the whole OS. The connecting thread is that this info is a "process" metric being grouped with other memory metrics for this specific process. 

Another option, in order to avoid duplication, could be to leave the RSS metrics in the `jdk.ResidentSetSize` event, not put them in the `ProcessSize` event, and correlate them by giving them the same timestamp as (Erik mentions above). 
Something similar was  also done with the `NativeMemoryUsagePeak` and `NativeMemoryUsageTotalPeak` events (which are GraalVM specific) to avoid having to modify `NativeMemoryUsage` and `NativeMemoryUsageTotal`. Admittedly, this is not as clean or convenient. 

Either way, I agree that putting all the metrics in `ProcessSize` in their own individual events is not the best way.

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3207897026

From egahlin at openjdk.org  Wed Aug 20 20:52:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 20 Aug 2025 20:52:04 GMT
Subject: RFR: 8365815: JFR: Update metadata.xml with 'jfr query' examples
Message-ID: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>

Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?

It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.

Testing: test/jdk/jdk/jfr + tier1

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From egahlin at openjdk.org  Thu Aug 21 05:21:23 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 21 Aug 2025 05:21:23 GMT
Subject: RFR: 8365815: JFR: Update metadata.xml with 'jfr query' examples
 [v2]
In-Reply-To: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
References: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
Message-ID: <NiSFcXWDjjaCrcmx-N9tZB56w62SdxDRL1QZ1-tD-6o=.3b779395-2677-4e24-8c11-93f92eab2c69@github.com>

> Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?
> 
> It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.
> 
> Testing: test/jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

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

  Add view output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26869/files
  - new: https://git.openjdk.org/jdk/pull/26869/files/604b86de..9d54c0e5

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

  Stats: 17 lines in 1 file changed: 13 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26869.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26869/head:pull/26869

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

From asemenov at openjdk.org  Thu Aug 21 09:01:12 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 09:01:12 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/c1/c1_LinearScan.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/adlc/output_h.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26798/files
  - new: https://git.openjdk.org/jdk/pull/26798/files/80777ced..dd21148b

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

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

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

From asemenov at openjdk.org  Thu Aug 21 09:11:53 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 09:11:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
Message-ID: <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>

On Wed, 20 Aug 2025 12:20:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/adlc/output_h.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/nmt/mallocSiteTable.cpp line 172:
> 
>> 170:        index < pos_idx && head != nullptr;
>> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
>> 172:       (MallocSiteHashtableEntry*)head->next()) {}
> 
> This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.

A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290418847

From cito at openjdk.org  Thu Aug 21 09:27:43 2025
From: cito at openjdk.org (Chihiro Ito)
Date: Thu, 21 Aug 2025 09:27:43 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
Message-ID: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>

Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 

Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.

Tests updated to validate lifecycle consistency: 
Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.

Test: jdk/jdk/jfr

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

Commit messages:
 - 8365066: RecordingStream and RemoteRecordingStream do not terminate when the associated Recording is stopped or closed externally

Changes: https://git.openjdk.org/jdk/pull/26710/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26710&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365066
  Stats: 648 lines in 7 files changed: 584 ins; 30 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/26710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26710/head:pull/26710

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

From cito at openjdk.org  Thu Aug 21 09:27:43 2025
From: cito at openjdk.org (Chihiro Ito)
Date: Thu, 21 Aug 2025 09:27:43 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
 <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
Message-ID: <0lFoRfCUlAVk-7LwYZ3Ps67pBUnLlHm0fIPpTd_XNko=.d69fa0b4-f72f-4345-8365-10d658f29958@github.com>

On Sat, 9 Aug 2025 04:50:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 
>> 
>> Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.
>> 
>> Tests updated to validate lifecycle consistency: 
>> Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.
>> 
>> Test: jdk/jdk/jfr
>
> Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.
> 
> For a RemoteRecordingStream there is a JMX notification that can be listened on.

@egahlin That sounds like a good idea. I?ll give it a try.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3179096227

From egahlin at openjdk.org  Thu Aug 21 09:27:43 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 21 Aug 2025 09:27:43 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
Message-ID: <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>

On Sat, 9 Aug 2025 01:33:29 GMT, Chihiro Ito <cito at openjdk.org> wrote:

> Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 
> 
> Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.
> 
> Tests updated to validate lifecycle consistency: 
> Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.
> 
> Test: jdk/jdk/jfr

Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.

For a RemoteRecordingStream there is a JMX notification that can be listened on.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3170208274

From aturbanov at openjdk.org  Thu Aug 21 09:27:50 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 21 Aug 2025 09:27:50 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
Message-ID: <DAhKmBzOSQOvyJcfos-syzpxCTZOlcfv-oNpbCfHGRo=.d9cb5cd9-c46c-4880-bdda-dd08af4f3033@github.com>

On Sat, 9 Aug 2025 01:33:29 GMT, Chihiro Ito <cito at openjdk.org> wrote:

> Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 
> 
> Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.
> 
> Tests updated to validate lifecycle consistency: 
> Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.
> 
> Test: jdk/jdk/jfr

src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java line 171:

> 169:                     }
> 170: 
> 171:                     if(!barrier.used()) {

Suggestion:

                    if (!barrier.used()) {

src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java line 195:

> 193:                 }
> 194: 
> 195:                 if(!barrier.used()) {

Suggestion:

                if (!barrier.used()) {

src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java line 200:

> 198:                         logStreamEnd("Event source is closed externally");
> 199:                         return;
> 200:                     }else if(state == RecordingState.STOPPED) {

Suggestion:

                    } else if (state == RecordingState.STOPPED) {

src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/LocalRecordingEventSource.java line 57:

> 55: 
> 56:     @Override
> 57:     public RecordingState getState()  {

Suggestion:

    public RecordingState getState() {

src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java line 470:

> 468:         stream.close();
> 469:         try {
> 470:             if(eventSource.getState() != RecordingState.CLOSED) {

Suggestion:

            if (eventSource.getState() != RecordingState.CLOSED) {

src/jdk.management.jfr/share/classes/jdk/management/jfr/internal/RemoteRecordingEventSource.java line 48:

> 46:     public long getStopTime() {
> 47:         Optional<RecordingInfo> recordingInfo = mbean.getRecordings().stream().filter(r -> r.getId() == recordingId).findFirst();
> 48:         if(recordingInfo.isEmpty()){

Suggestion:

        if (recordingInfo.isEmpty()){

src/jdk.management.jfr/share/classes/jdk/management/jfr/internal/RemoteRecordingEventSource.java line 55:

> 53: 
> 54:     @Override
> 55:     public RecordingState getState()  {

Suggestion:

    public RecordingState getState() {

src/jdk.management.jfr/share/classes/jdk/management/jfr/internal/RemoteRecordingEventSource.java line 57:

> 55:     public RecordingState getState()  {
> 56:         Optional<RecordingInfo> recordingInfo = mbean.getRecordings().stream().filter(r -> r.getId() == recordingId).findFirst();
> 57:         if(recordingInfo.isEmpty()){

Suggestion:

        if (recordingInfo.isEmpty()){

src/jdk.management.jfr/share/classes/jdk/management/jfr/internal/RemoteRecordingEventSource.java line 58:

> 56:         Optional<RecordingInfo> recordingInfo = mbean.getRecordings().stream().filter(r -> r.getId() == recordingId).findFirst();
> 57:         if(recordingInfo.isEmpty()){
> 58:             return  RecordingState.CLOSED;

Suggestion:

            return RecordingState.CLOSED;

test/jdk/jdk/jfr/api/consumer/recordingstream/TestClosedRecording.java line 47:

> 45:         @Override
> 46:         public void recordingStateChanged(Recording recording) {
> 47:             if(recording.getState() == RecordingState.RUNNING){

Suggestion:

            if (recording.getState() == RecordingState.RUNNING){

test/jdk/jdk/jfr/api/consumer/recordingstream/TestStoppedRecording.java line 44:

> 42: public class TestStoppedRecording {
> 43: 
> 44:     private static class SendEventListener implements  FlightRecorderListener{

Suggestion:

    private static class SendEventListener implements FlightRecorderListener {

test/jdk/jdk/jfr/api/consumer/recordingstream/TestStoppedRecording.java line 47:

> 45:         @Override
> 46:         public void recordingStateChanged(Recording recording) {
> 47:             if(recording.getState() == RecordingState.RUNNING){

Suggestion:

            if (recording.getState() == RecordingState.RUNNING){

test/jdk/jdk/jfr/jmx/streaming/TestClosedRecording.java line 49:

> 47:         @Override
> 48:         public void recordingStateChanged(Recording recording) {
> 49:             if(recording.getState() == RecordingState.RUNNING){

Suggestion:

            if (recording.getState() == RecordingState.RUNNING){

test/jdk/jdk/jfr/jmx/streaming/TestStoppedRecording.java line 49:

> 47:         @Override
> 48:         public void recordingStateChanged(Recording recording) {
> 49:             if(recording.getState() == RecordingState.RUNNING){

Suggestion:

            if (recording.getState() == RecordingState.RUNNING){

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2268786865
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2268787115
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269049532
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2268786126
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2268785446
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269052713
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269053453
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269053705
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269053990
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2268784511
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269051861
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269050262
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2268784953
PR Review Comment: https://git.openjdk.org/jdk/pull/26710#discussion_r2269050747

From mgronlun at openjdk.org  Thu Aug 21 09:57:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 21 Aug 2025 09:57:54 GMT
Subject: RFR: 8365611: Use lookup table for JfrEventThrottler [v2]
In-Reply-To: <Qhzfi16yf8iZB_px98gb9v32ECO9LcP7Kae9NjE76A8=.e0a855c2-e248-4d8c-b139-a0d27fc0db18@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <B7JGzUt1NOnpD4ub8Z-EFXLcS6pynKq-CPT2gom3XCw=.ebe0e3d1-d75a-4fe2-9c2e-a48280894d9b@github.com>
 <Qhzfi16yf8iZB_px98gb9v32ECO9LcP7Kae9NjE76A8=.e0a855c2-e248-4d8c-b139-a0d27fc0db18@github.com>
Message-ID: <C_o0maQpB40BKRGWC_qNGhAG-GbcCP0wFJ0tSE46rI8=.a843a6c7-3f09-4cb4-8a3c-6bda53140724@github.com>

On Wed, 20 Aug 2025 16:47:44 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Markus Feedback
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 103:
> 
>> 101: JfrEventThrottler* JfrEventThrottler::for_event(JfrEventId event_id) {
>> 102:   JfrEventThrottler* const throttler = _throttler_table.at(event_id);
>> 103:   assert(throttler != nullptr, "Event type %d has an unconfigured throttler", (int)event_id);
> 
> The call to configure throttlers originates from up in the Java level JFR code.  Would it be possible to attempt sampling when a throttler is created, but not yet configured? 
> 
> If this is possible, then it was possible before this PR too (not introduced here).

The settings system prevents this situation, because configure -> !enabled

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2290535281

From adinn at openjdk.org  Thu Aug 21 10:01:59 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 10:01:59 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
Message-ID: <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>

On Thu, 21 Aug 2025 09:08:58 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/hotspot/share/nmt/mallocSiteTable.cpp line 172:
>> 
>>> 170:        index < pos_idx && head != nullptr;
>>> 171:        index++, head = ((MallocSiteHashtableEntry*)head->next() == nullptr) ? head :
>>> 172:       (MallocSiteHashtableEntry*)head->next()) {}
>> 
>> This doesn't look right to me. We check `head != nullptr` in the loop condition so we cannot reach the assignment if it is null.
>
> A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error

Hmm, is it possible?

Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290543955

From adinn at openjdk.org  Thu Aug 21 10:17:56 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 10:17:56 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
Message-ID: <t1IN7M1W44RGuPkysGDxmmdmADmc6lFc0R11i4dKrcI=.de45ee4c-9a8d-436a-80e2-2d6224bf3ad0@github.com>

On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
>> 
>> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/adlc/output_h.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

n.b. Before accepting any of the changes in this PR I'd really like to know whether they have arisen from reports of an actual null pointer dereference or they are simply derived from some theoretical analysis. In the latter case then I think we would need a better explanation of why an error can happen than we have seen so far. Given that requirement I also think each of the changes should be submitted in its own PR with its own justification. We should not modify control flow logic on the nod.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209906082

From asemenov at openjdk.org  Thu Aug 21 10:34:03 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 10:34:03 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <O_bhdRkPTNNPMh-njv0iY0vTStYNWjOclqPxxfX4elg=.8a79282a-c985-442b-a105-f178852e60d5@github.com>
Message-ID: <sFP5T-Udewsb3RPw1JazXkAEFMWbtqADYzq-2VTyaAE=.e757c87b-1eb3-4bc0-8a0d-a76ff6a3a9ad@github.com>

On Wed, 20 Aug 2025 12:29:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I've added some additional mailing lists to ensure better coverage here.
> 
> Also I think you need to update the JBS (and PR) title to reflect the broader scope of the changes.

Please provide an example of an updated title?

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3209975632

From asemenov at openjdk.org  Thu Aug 21 10:34:04 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 10:34:04 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
Message-ID: <MQRWuZVpXil3heDuvAQ5rXpMeTvYPUr0dUfO_Vv35oo=.688e7cea-48e5-425a-ab7c-4e6a6e8f202a@github.com>

On Wed, 20 Aug 2025 12:22:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/adlc/output_h.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1319:
> 
>> 1317:     log_if_needed("  ** not supported: arity=%d op=%s vlen=%d etype=%s atype=%s ismask=no",
>> 1318:                     is_scatter, is_scatter ? "scatter" : "gather",
>> 1319:                     num_elem, type2name(elem_bt), type2name(arr_type->elem()->array_element_basic_type()));
> 
> There is  a bug here but I'm not sure it is what you think it is.

```addr_type->isa_aryptr();``` might return nullptr, while in ```elem_consistent_with_arr(elem_bt, arr_type, false)```, arr_type is only checked with an assert.
Moreover, the presence of a check in the original version indicates that arr_type can be null, and there is no protection against this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290615638

From asemenov at openjdk.org  Thu Aug 21 11:11:56 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 11:11:56 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
Message-ID: <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>

On Thu, 21 Aug 2025 09:59:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> A situation is possible where head becomes nullptr when head->next() returns nullptr on the last iteration. Then, after the loop finishes, assert(head != nullptr) will trigger (only in debug mode), and return head->data() will cause a program error
>
> Hmm, is it possible?
> 
> Perhaps you could explain how pos_idx is being used in this loop to guard against that happening and why that does not make this safe?

```head->next()``` returns a pointer to _next without any checks.

In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread.

>From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr.

But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290701959

From adinn at openjdk.org  Thu Aug 21 12:11:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 12:11:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
Message-ID: <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>

On Thu, 21 Aug 2025 11:09:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Moreover, pos_idx is also not being checked

I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.

The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.

n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2290852355

From asemenov at openjdk.org  Thu Aug 21 13:21:02 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 21 Aug 2025 13:21:02 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
Message-ID: <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>

On Thu, 21 Aug 2025 12:09:38 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> ```head->next()``` returns a pointer to _next without any checks.
>> 
>> In turn, the _next pointer is marked as volatile, which means it can be modified at any moment, for example, in another thread.
>> 
>> From this, I conclude that a check in this location is desirable. Moreover, pos_idx is also not being checked. It is quite possible that ```head->next()``` could turn out to be nullptr.
>> 
>> But I don?t mind. If you are sure that there can?t be a nullptr in this place, I will withdraw this patch.
>
>> Moreover, pos_idx is also not being checked
> 
> I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.
> 
> The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.
> 
> n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.

pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size.

I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer and confirmed by a specialist from another organization. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?.

As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form.

I certainly do not claim to understand this code as well as you or any other member of the hotspot team.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291041769

From adinn at openjdk.org  Thu Aug 21 14:34:53 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 21 Aug 2025 14:34:53 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
 <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
Message-ID: <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>

On Thu, 21 Aug 2025 13:18:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>>> Moreover, pos_idx is also not being checked
>> 
>> I don't know what you mean by this comment. `pos_idx` is being checked in the loop test before the call to `head->next()` in that same test.
>> 
>> The important question you need to address is why and what that check guarantees. I say you need to address it because you are the one claiming that there is a possible nullptr dereference  here without any evidence that it has occurred in practice. If that is based on a correct analysis of the code then you need to explain how we can arrive at a situtation where we hit a null pointer that takes into account the logic of the loop test. So far you have not done so.
>> 
>> n.b. I am not claiming there is no possibility of a nullptr dereference here (although I can form my own opinion). I'm asking you to tell me why I should take your claim that it is possible seriously. Your answers so far are not convincing me that you have understood how this code works.
>
> pos_idx receives its value when calling a certain function pos_idx_from_marker(marker), and there is no check before the loop to ensure that it is within the bounds of the _table size.
> 
> I mentioned above that I am not insisting on this particular patch. This issue was detected by a static analyzer. After that, based on my limited knowledge, I considered it confirmed? If you have any refutation, please share your thoughts. In that case, I will revert this patch and mark the trigger as ?NO FIX REQUIRED?.
> 
> As far as I have checked, there are no checks anywhere in the calls to this function to compare the marker with the table or any other entities in any form.
> 
> I certainly do not claim to understand this code as well as you or any other member of the hotspot team.

Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me abut a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant.

I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers.

Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful.

Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2291265263

From cito at openjdk.org  Thu Aug 21 14:38:02 2025
From: cito at openjdk.org (Chihiro Ito)
Date: Thu, 21 Aug 2025 14:38:02 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
 <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
Message-ID: <4amEiivX29FlYE6fbjvWrIVBq2HAmzhmUGHaCmZ3w_E=.9f676802-6ead-41ae-8aff-756de1c1b8c1@github.com>

On Sat, 9 Aug 2025 04:50:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 
>> 
>> Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.
>> 
>> Tests updated to validate lifecycle consistency: 
>> Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.
>> 
>> Test: jdk/jdk/jfr
>
> Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.
> 
> For a RemoteRecordingStream there is a JMX notification that can be listened on.

@egahlin 
Could you please review this please?
I added a listener-based mechanism that propagates external stop/close to the stream.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3210871547

From egahlin at openjdk.org  Thu Aug 21 18:15:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 21 Aug 2025 18:15:51 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
 <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
Message-ID: <KuKZ7Rw-VcygY0EtN405T4sRVFc0_y71pHsvUHL7cjs=.563e6af5-240d-4b7d-8c2d-d0a8f1e82021@github.com>

On Sat, 9 Aug 2025 04:50:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 
>> 
>> Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.
>> 
>> Tests updated to validate lifecycle consistency: 
>> Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.
>> 
>> Test: jdk/jdk/jfr
>
> Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.
> 
> For a RemoteRecordingStream there is a JMX notification that can be listened on.

> @egahlin Could you please review this please? I added a listener-based mechanism that propagates external stop/close to the stream.

This will take me some time to go through. I'm a little bit worried about the locking, but I need to investigate, before I can comment further.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3211615677

From egahlin at openjdk.org  Fri Aug 22 06:09:30 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 22 Aug 2025 06:09:30 GMT
Subject: RFR: 8365815: JFR: Update metadata.xml with 'jfr query' examples
 [v3]
In-Reply-To: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
References: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
Message-ID: <6fDHpUNTm6j5OuFgsDiRpMh3LAYOAUgeayyTA1Eb1h0=.11887e3c-726f-4a74-a985-3e2060a469df@github.com>

> Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?
> 
> It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.
> 
> Testing: test/jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

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

  Add s

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26869/files
  - new: https://git.openjdk.org/jdk/pull/26869/files/9d54c0e5..d6c88bb0

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

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

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

From mgronlun at openjdk.org  Fri Aug 22 11:33:07 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 22 Aug 2025 11:33:07 GMT
Subject: RFR: 8362573: Incorrect weight of the first ObjectAllocationSample JFR
 event (regression)
Message-ID: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>

Greetings,

Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled.

The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads.

This time also includes a regression test.

Testing: jdk_jfr

Thanks
Markus

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

Commit messages:
 - 8362573

Changes: https://git.openjdk.org/jdk/pull/26900/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26900&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362573
  Stats: 194 lines in 7 files changed: 133 ins; 30 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/26900.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26900/head:pull/26900

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

From dlong at openjdk.org  Fri Aug 22 12:01:59 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 22 Aug 2025 12:01:59 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <clP7ORnQOS8o0QhYs7DyuOLjQ-bPKch1dK1hDqPzzaI=.9b61fd70-4622-4344-aea6-8661fb57427c@github.com>
Message-ID: <MEJsxrF4K-t_cRGvOO3KpBBiUcF4MtHCxigyJD64WeU=.c5cf9542-204b-4e5f-b57d-61f900062352@github.com>

On Thu, 21 Aug 2025 09:01:12 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
>> 
>> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.
>
> Artem Semenov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/c1/c1_LinearScan.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/adlc/output_h.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Most of these mitigations to guard against a possible null pointer dereference are inside `if` expressions, which means if there was a null pointer, then we will now end up in the `else` clause, changing the behavior of the code to something that was perhaps unintended, and we still don't know what caused the null pointer.  So this is just silently masking potential problems, and in my experience is usually not the correct fix.  Most of the time the correct fix is to tell the static analyzer that it is a false positive and move on.  Sometimes it is appropriate to add an assert or guarantee, and yes sometimes it is appropriate to do something different if there is a null, for example if it is a result of an allocation that can fail.

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

PR Comment: https://git.openjdk.org/jdk/pull/26798#issuecomment-3212300703

From asemenov at openjdk.org  Fri Aug 22 12:02:00 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 22 Aug 2025 12:02:00 GMT
Subject: RFR: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses() [v2]
In-Reply-To: <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
 <m-aR302_Qm6Np3fyTAaw5RB2q6t1vMW4vEolOaVueKo=.ff55cc84-9167-473a-af27-95becf011732@github.com>
 <ftJY3jOzJsWM_Aq9WpMjcrn3uR4e9cs_dS9ibkfu3c4=.6b8bbd93-e8e1-4000-8d24-42d40ddd5c11@github.com>
 <nfX_mlIzSSw6BnbOsToJC4QUI4u8SIO2WPOgbmcKV4o=.c6711b09-3989-4762-92a9-cde741c8b303@github.com>
 <TMAYmQLsLMVYslI-dilLANogdWfQqCRdPML64fs1Rz8=.4a247460-76c9-46a3-92bd-df5ece4679ba@github.com>
 <IPp6nZpu3m9vy6YmAi7OpffEWN5h8p81ss21dkBsPGU=.3edab52c-89d6-45f4-9daa-c35f48dc3bb0@github.com>
 <iA2tvBsBkeEoKQntaeQZpteiyfMJCSdhhGKzNO-CeHc=.f5fb60fb-37e6-4b2e-9146-0be0fe220b9d@github.com>
 <KS-ahFFjB-Ehnk_gU_5pM3mfuhHOvOYySiL5Q1wZeVc=.a8bef526-8f2b-495d-b2b7-efa88f1ed6d6@github.com>
Message-ID: <os0FO1i7DzfjdqmpWxKOPGa-6rHOdkNEA-fus5a9w8o=.dc80696d-3672-42a4-a205-977008c212bd@github.com>

On Thu, 21 Aug 2025 14:32:43 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Well, this leads right to the root of the problem I have with this report. As you say, pos_idx does indeed come out of a marker object. It took me about a minute to identify that this marker object is created in the function that sits right above the one your code assistant flagged as problematic -- even though I am not at all familiar with this code. It looks clear to me that, given the right call sequence for calls that create a marker and then consume it here, the check on pos_idx will ensure that we don't drop off the end of the list with a null pointer. So, it looks very liek this code has been designed so that the presence of a marker with a suitable pos_idx is intended to ensure this loop terminates before that happens. I am sure someone in this project knows whether that is the case but it is not you or your coding assistant.
> 
> I'm not suggesting that that calling sequence is actually right and that the check for pos_idx will definitely avoid dropping off the end. Indeed, I would welcome a bug report that proved it to be wrong. However, what is clear that both you and your coding assistant have failed to appreciate how some relatively obvious parts of this design actually operate. That renders your (or your tool's) analysis a shallow and unhelpful distraction; using it as an excuse to raise a purported 'issue' in the absence of any evidence of an actual issue is very much a waste of time for this project's reviewers.
> 
> Your error is compounded by the fact that you (or more likely your coding assistant) are suggesting changes which, because they are not founded in a correct understanding of the design, could potentially lead to worse outcomes than the speculative nullptr dereference they are intended to remedy -- as I explained when discussing your change to the control flow logic in the ALDC code. So, not only is this report unhelpful it is potentially harmful.
> 
> Ultimately the takeaway here is that the OpenJDK bug system is not here to report, review and add patches to remedy issues that you or your code assistant tool invents on the basis of misinformed assumptions. It is here to report, review and add patches to remedy issues that can be shown to actually affect the correct operation of the JVM and JDK,either by a reproducible test or by well-reasoned argument. So, please do not continue to spam the project with bug reports like this simply because a potentially bogus patch will improve your experience with what is clearly a decidedly fallible tool.

I?m sorry to have taken up your time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26798#discussion_r2293532235

From asemenov at openjdk.org  Fri Aug 22 12:02:01 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 22 Aug 2025 12:02:01 GMT
Subject: Withdrawn: 8365604: Null pointer dereference in
 src/hotspot/share/adlc/output_h.cpp ArchDesc::declareClasses()
In-Reply-To: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
References: <3lBcWmU_crhlwmnXaBl3ljOS87FTJ4VDZUC_kwlFC0A=.45fbea2f-4b39-4e15-a4a3-31b74c483748@github.com>
Message-ID: <kErw3f-D3SB4Yxj9Hi8GBrfshYhi7njMTMkZ-t9knPo=.43be4c0d-98c8-4912-82c5-807a38636cde@github.com>

On Fri, 15 Aug 2025 11:58:48 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function ArchDesc::declareClasses() located in the file src/hotspot/share/adlc/output_h.cpp with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer instr->_matrule is dereferenced in line 1952 without checking for nullptr, although earlier in line 1858 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

This pull request has been closed without being integrated.

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

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

From cito at openjdk.org  Sun Aug 24 04:13:57 2025
From: cito at openjdk.org (Chihiro Ito)
Date: Sun, 24 Aug 2025 04:13:57 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <KuKZ7Rw-VcygY0EtN405T4sRVFc0_y71pHsvUHL7cjs=.563e6af5-240d-4b7d-8c2d-d0a8f1e82021@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
 <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
 <KuKZ7Rw-VcygY0EtN405T4sRVFc0_y71pHsvUHL7cjs=.563e6af5-240d-4b7d-8c2d-d0a8f1e82021@github.com>
Message-ID: <KI9R25X6oRysMPLA99X-4xmAHKfq89GByS7fqLSiDrE=.117d4687-89fe-43ed-a44d-1ee3def6c5b5@github.com>

On Thu, 21 Aug 2025 18:12:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.
>> 
>> For a RemoteRecordingStream there is a JMX notification that can be listened on.
>
>> @egahlin Could you please review this please? I added a listener-based mechanism that propagates external stop/close to the stream.
> 
> This will take me some time to go through. I'm a little bit worried about the locking, but I need to investigate, before I can comment further.

@egahlin 

I apologize.
I forgot to fix some code I had been using to test the locking behavior and mistakenly committed it.
I?ll correct this and push the changes soon.

I do have one question: is there a general preference between using synchronized and ReentrantLock?
Personally, I lean toward ReentrantLock, since it can be safely used with virtual threads and may be easier to backport if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3217745957

From egahlin at openjdk.org  Sun Aug 24 07:48:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 24 Aug 2025 07:48:51 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <KuKZ7Rw-VcygY0EtN405T4sRVFc0_y71pHsvUHL7cjs=.563e6af5-240d-4b7d-8c2d-d0a8f1e82021@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
 <V_bY9xDhmiD4B2IinHgUPsxQXkcGneS4DsOGohvEafc=.fe6e3a2f-3477-42b7-8c25-47868638d8d5@github.com>
 <KuKZ7Rw-VcygY0EtN405T4sRVFc0_y71pHsvUHL7cjs=.563e6af5-240d-4b7d-8c2d-d0a8f1e82021@github.com>
Message-ID: <itHF_s72hhOrjdhaGrSEHduj7_HeCIhAWiaKdIMNU48=.687a3768-5336-472d-b9ce-d3ea2914db29@github.com>

On Thu, 21 Aug 2025 18:12:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Did you look into adding a FlightRecorderListener and implementing recordingStateChanged to check if the RecordingState is CLOSED and then call close() on the stream? Or perhaps it would be better to set a flag and let the thread running the stream close itself after the next flush is complete.
>> 
>> For a RemoteRecordingStream there is a JMX notification that can be listened on.
>
>> @egahlin Could you please review this please? I added a listener-based mechanism that propagates external stop/close to the stream.
> 
> This will take me some time to go through. I'm a little bit worried about the locking, but I need to investigate, before I can comment further.

> @egahlin
> 
> I apologize. I forgot to fix some code I had been using to test the locking behavior and mistakenly committed it. I?ll correct this and push the changes soon.
> 
> I do have one question: is there a general preference between using synchronized and ReentrantLock? Personally, I lean toward ReentrantLock, since it can be safely used with virtual threads and may be easier to backport if needed.

The preference is to not use locks at all when callbacks (listeners) are being invoked as it could potentially lead to dead locks. Best would be if a flag can be set so the stream stops or closes itself at the next flush, but again, I haven't had time to look at it, so it might not be feasible.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3217916307

From jbechberger at openjdk.org  Mon Aug 25 12:46:04 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 25 Aug 2025 12:46:04 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
Message-ID: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>

Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

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

Commit messages:
 - Improve queue size computation

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

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

From mgronlun at openjdk.org  Mon Aug 25 13:03:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 25 Aug 2025 13:03:56 GMT
Subject: RFR: 8365815: JFR: Update metadata.xml with 'jfr query' examples
 [v3]
In-Reply-To: <6fDHpUNTm6j5OuFgsDiRpMh3LAYOAUgeayyTA1Eb1h0=.11887e3c-726f-4a74-a985-3e2060a469df@github.com>
References: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
 <6fDHpUNTm6j5OuFgsDiRpMh3LAYOAUgeayyTA1Eb1h0=.11887e3c-726f-4a74-a985-3e2060a469df@github.com>
Message-ID: <jFqElW9s9GF07nFR_Q3VEfmaBLCYRFNNQ6cL6xDe964=.2bc539bc-d2a7-4fa5-9dbb-39be6cece48c@github.com>

On Fri, 22 Aug 2025 06:09:30 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?
>> 
>> It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.
>> 
>> Testing: test/jdk/jdk/jfr + tier1
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add s

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26869#pullrequestreview-3151361907

From krk at openjdk.org  Mon Aug 25 13:34:53 2025
From: krk at openjdk.org (Kerem Kat)
Date: Mon, 25 Aug 2025 13:34:53 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <Czt2ssXjx14W1CnCc8L0mDhXk0UaajVj8lqX2RGN2go=.48c8595d-b4b1-4b3f-9cf4-593aaa9afdc7@github.com>

On Mon, 25 Aug 2025 12:41:11 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

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

> 183:     }
> 184:     if (factor > 1) {
> 185:       u4 new_capacity = _capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor;

I noticed the check uses `_capacity` but the assignment uses `capacity`. Should both be using `capacity`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2298120010

From duke at openjdk.org  Mon Aug 25 13:45:59 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 25 Aug 2025 13:45:59 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <H_0yhkyqZi1XfwjKU87L6sNRSpqqG-F5mdgJ8ONQQTI=.eb7e9645-ad2c-4d16-9bd4-ff786e6899fb@github.com>

On Mon, 25 Aug 2025 12:41:11 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

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

> 184:     if (factor > 1) {
> 185:       u4 new_capacity = _capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor;
> 186:       set_capacity(new_capacity);

Is it a problem if another thread changes `_capacity` since when you read it at L171, and the update is overwritten?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2298149533

From jbechberger at openjdk.org  Mon Aug 25 14:11:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 25 Aug 2025 14:11:57 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
In-Reply-To: <Czt2ssXjx14W1CnCc8L0mDhXk0UaajVj8lqX2RGN2go=.48c8595d-b4b1-4b3f-9cf4-593aaa9afdc7@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <Czt2ssXjx14W1CnCc8L0mDhXk0UaajVj8lqX2RGN2go=.48c8595d-b4b1-4b3f-9cf4-593aaa9afdc7@github.com>
Message-ID: <UayGFFAYKxQxUvw1t2yFMJtXWOoK1c50No37xLvWD_c=.6e8c10ff-e920-4143-9220-776ef1069e19@github.com>

On Mon, 25 Aug 2025 13:31:47 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 185:
> 
>> 183:     }
>> 184:     if (factor > 1) {
>> 185:       u4 new_capacity = _capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor;
> 
> I noticed the check uses `_capacity` but the assignment uses `capacity`. Should both be using `capacity`?

good catch :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2298221961

From duke at openjdk.org  Mon Aug 25 14:25:57 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Mon, 25 Aug 2025 14:25:57 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
In-Reply-To: <2okkrBbQ49yYFXUdsRaAOlMhkD3a_xXwynJ8F3Zp4jM=.f2c87a99-edf6-4914-b122-46a1e764c47c@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <H_0yhkyqZi1XfwjKU87L6sNRSpqqG-F5mdgJ8ONQQTI=.eb7e9645-ad2c-4d16-9bd4-ff786e6899fb@github.com>
 <2okkrBbQ49yYFXUdsRaAOlMhkD3a_xXwynJ8F3Zp4jM=.f2c87a99-edf6-4914-b122-46a1e764c47c@github.com>
Message-ID: <t6UAV5Ld4GPYW4C892hBmk382fmuWAbi-eVUm1MALKI=.206ad47a-d63e-4db4-90eb-5451efc25209@github.com>

On Mon, 25 Aug 2025 14:21:30 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 186:
>> 
>>> 184:     if (factor > 1) {
>>> 185:       u4 new_capacity = _capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor;
>>> 186:       set_capacity(new_capacity);
>> 
>> Is it a problem if another thread changes `_capacity` since when you read it at L171, and the update is overwritten?
>
> No other thread can change it. The queue capacity is only changed when
> - a thread is created (so queue drainage is possible in parallel
> - when the queue is drained and there is sample loss (but this happens only with a dequeue lock)
> - a thread is terminated: I added synchronisation to prevent concurrency

Thanks for the clarification

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2298259049

From jbechberger at openjdk.org  Mon Aug 25 14:25:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 25 Aug 2025 14:25:57 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
In-Reply-To: <H_0yhkyqZi1XfwjKU87L6sNRSpqqG-F5mdgJ8ONQQTI=.eb7e9645-ad2c-4d16-9bd4-ff786e6899fb@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <H_0yhkyqZi1XfwjKU87L6sNRSpqqG-F5mdgJ8ONQQTI=.eb7e9645-ad2c-4d16-9bd4-ff786e6899fb@github.com>
Message-ID: <2okkrBbQ49yYFXUdsRaAOlMhkD3a_xXwynJ8F3Zp4jM=.f2c87a99-edf6-4914-b122-46a1e764c47c@github.com>

On Mon, 25 Aug 2025 13:42:50 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 186:
> 
>> 184:     if (factor > 1) {
>> 185:       u4 new_capacity = _capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor;
>> 186:       set_capacity(new_capacity);
> 
> Is it a problem if another thread changes `_capacity` since when you read it at L171, and the update is overwritten?

No other thread can change it. The queue capacity is only changed when
- a thread is created (so queue drainage is possible in parallel
- when the queue is drained and there is sample loss (but this happens only with a dequeue lock)
- a thread is terminated: I added synchronisation to prevent concurrency

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2298253432

From jbechberger at openjdk.org  Mon Aug 25 14:29:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 25 Aug 2025 14:29:08 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v2]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <sMS_NiR-sAXCfMMh3uuXsNWHB0pGTWUEk3t4CcAYey0=.205069f3-e0e7-4e0f-bb6d-0d65abe9dc41@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

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

  Add queue locking on thread termination

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/1c7b5b82..97669fe5

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

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

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

From jbechberger at openjdk.org  Mon Aug 25 14:29:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 25 Aug 2025 14:29:08 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v2]
In-Reply-To: <t6UAV5Ld4GPYW4C892hBmk382fmuWAbi-eVUm1MALKI=.206ad47a-d63e-4db4-90eb-5451efc25209@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <H_0yhkyqZi1XfwjKU87L6sNRSpqqG-F5mdgJ8ONQQTI=.eb7e9645-ad2c-4d16-9bd4-ff786e6899fb@github.com>
 <2okkrBbQ49yYFXUdsRaAOlMhkD3a_xXwynJ8F3Zp4jM=.f2c87a99-edf6-4914-b122-46a1e764c47c@github.com>
 <t6UAV5Ld4GPYW4C892hBmk382fmuWAbi-eVUm1MALKI=.206ad47a-d63e-4db4-90eb-5451efc25209@github.com>
Message-ID: <VrS3VEY1Kg1smcKLQ7-katRegMhKzI19LMt2cqDu5aM=.cfd1ebad-1441-4bc2-b618-3e6eff48b24c@github.com>

On Mon, 25 Aug 2025 14:23:44 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> No other thread can change it. The queue capacity is only changed when
>> - a thread is created (so queue drainage is possible in parallel
>> - when the queue is drained and there is sample loss (but this happens only with a dequeue lock)
>> - a thread is terminated: I added synchronisation to prevent concurrency
>
> Thanks for the clarification

I pushed the fix to include the proper locking, thank you for catching the issue

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2298268592

From egahlin at openjdk.org  Mon Aug 25 15:15:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 25 Aug 2025 15:15:00 GMT
Subject: Integrated: 8365815: JFR: Update metadata.xml with 'jfr query'
 examples
In-Reply-To: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
References: <ow5JcdjDYpLD2Vghm0Gxv-fHv-CFXNqb4OBuKFqz-yg=.5ff055be-190f-4f39-a439-6a1933e5b95c@github.com>
Message-ID: <N7jpTrV-gBuGmfWLqp9w27u_3-cyYEsQ65PJTGZIvVM=.cee57a82-1981-4b65-8d61-b2dd84de9670@github.com>

On Wed, 20 Aug 2025 20:39:55 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that adds a couple of 'jfr query' examples to metadata.xml?
> 
> It turns out that the EventDuration event doesn't work because it has no fields. The fix is to remove the class-specific commit() method and constructor for events without fields.
> 
> Testing: test/jdk/jdk/jfr + tier1
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: d24449f6
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d24449f696c86bca53cca8a77cc3c4eb58a73ced
Stats:     29 lines in 2 files changed: 25 ins; 0 del; 4 mod

8365815: JFR: Update metadata.xml with 'jfr query' examples

Reviewed-by: mgronlun

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

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

From erik.gahlin at oracle.com  Mon Aug 25 21:22:01 2025
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 25 Aug 2025 21:22:01 +0000
Subject: [External] : Re: JFR: Scrubbing sensitive information from events
In-Reply-To: <CACX82zcEEqKM+wWb86JPVEE=ufuxvTkUiXGO4dS6cxTAcNXaDg@mail.gmail.com>
References: <CACX82zeW1sQRHAYZW52GLtWczKVAt=Q5_=arHHSnYRKz_QXOmg@mail.gmail.com>
 <DS7PR10MB5118CDB3DDFDA3044761C8B59D62A@DS7PR10MB5118.namprd10.prod.outlook.com>
 <CACX82zchxZU-kf1d57_qxSGhmVVWbspipQMiKE5g7ghOUXH9GA@mail.gmail.com>
 <DS7PR10MB511850094C5F8B1EDE853EC89D74A@DS7PR10MB5118.namprd10.prod.outlook.com>
 <CACX82zcEEqKM+wWb86JPVEE=ufuxvTkUiXGO4dS6cxTAcNXaDg@mail.gmail.com>
Message-ID: <DS7PR10MB51186465E54A544A4A938CC09D7AA@DS7PR10MB5118.namprd10.prod.outlook.com>

Sorry for the late reply.

AFAIK we don't have a native implementation for regular expression, and writing one is error-prone. Glob patterns are easier and will probably work for most use cases. We could try caching the redaction, so we don't need to repeat the same operation every time the event is emitted.

I added this feature to our roadmap, and I will do some prototyping near term. It would be great if you later could provide a default set of patterns.

Erik
________________________________
From: Erwan Viollet <erwan.viollet at gmail.com>
Sent: Friday, June 13, 2025 2:51 PM
To: Erik Gahlin <erik.gahlin at oracle.com>
Cc: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: Re: [External] : Re: JFR: Scrubbing sensitive information from events

I like the simple and pragmatic approach. Especially if we can have this as default.
Writing custom scrubbing logic for these specific events is much more straightforward than building a generic scrubbing framework.

To address the risk of missing sensitive patterns that are specific to user environments, I'd suggest adding a customization option:
# Allow users to extend or override default patterns
-XX:FlightRecorderOptions:scrub-sensitive-patterns="password,secret,key,token,credential,auth,pwd,passwd,api[_-]?key,custompattern"

We had to do the same for the Datadog Agent process scrubbing<https://urldefense.com/v3/__https://docs.datadoghq.com/infrastructure/process/?tab=linuxwindows*process-arguments-scrubbing__;Iw!!ACWV5N9M2RV99hQ!OFTohOpwXKtDtD5o-I4TIjEgUBq8-6eVPpOtXWWNH5CBUGQ2V3IGoC9Nc51-9L5N7gi6MJ-LB4tt44FXOxTjiBHE$>, where users can specify `custom_sensitive_words` to handle their specific use cases.

The remaining questions:
1. Scope limitations: Are there any known use cases that would be impacted by limiting scrubbing to these four event types? We believe this covers the vast majority of sensitive data exposure, but want to ensure we're not missing critical scenarios.

2. Default pattern selection:
We should align on what a reasonable default would look like. We can use our JFR Data to do this.

Regards,

Erwan

Le jeu. 12 juin 2025 ? 19:24, Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>> a ?crit :
Thanks for the file.

I worry that processing the file in the JVM or creating an intuitive Java API for post-processing it will be hard. The context/event determines what needs to be redacted. If scrubbing is only necessary for these four events, hardcoding the sensitive tokens and logic into the JVM might be a viable approach.

Users would specify:

 $ java -XX:FlightRecorderOptions:scrub-sensitive=true

or it might be enabled by default and users would need to opt-out.

Anyway, if enabled, a jfrScrub.cpp class would do the job. Something like this:

    EventInitialEnvironmentVariable event(UNTIMED);
    event.set_starttime(time_stamp);
    event.set_endtime(time_stamp);
    event.set_key(key);
    if (JfrScrub::is_sensitive_key(key)) {
      event.set_value("[REDACTED]");
    } else {
      event.set_value(value);
    }
    event.commit();

    EventInitialSystemProperty event(UNTIMED);
    event.set_key(p->key());
    if (JfrScrub::is_sensitive_key(p->key()) {
       event.set_value("[REDACTED]");
    } else {
       event.set_value(p->value());
    }
    event.set_starttime(time_stamp);
    event.set_endtime(time_stamp);
    event.commit();

    EventSystemProcess event(UNTIMED);
    event.set_pid(pid_buf);
    event.set_commandLine(JfrScrub::command_line(info));
    event.set_starttime(start_time);
    event.set_endtime(end_time);
    event.commit();

    EventJVMInformation event;
    event.set_jvmName(VM_Version::vm_name());
    event.set_jvmVersion(VM_Version::internal_vm_info_string());
    event.set_javaArguments(JfrScrub::command_line(Arguments::java_command()));
    event.set_jvmArguments(Arguments::jvm_args());
    event.set_jvmFlags(Arguments::jvm_flags());
    event.set_jvmStartTime(Management::vm_init_done_time());
    event.set_pid(os::current_process_id());
    event.commit();

It's a bit ugly and not as flexible, but perhaps that's something we need to tolerate. Or will it be useless because new passwords/keys will be added all the time, or because they will match false positives, and more advanced logic is needed? Perhaps it will give users the false(?) impression that they don't need to worry about sensitive data?

Thanks
Erik
________________________________
From: Erwan Viollet <erwan.viollet at gmail.com<mailto:erwan.viollet at gmail.com>>
Sent: Thursday, June 12, 2025 5:07 PM
To: Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>>
Cc: hotspot-jfr-dev at openjdk.org<mailto:hotspot-jfr-dev at openjdk.org> <hotspot-jfr-dev at openjdk.org<mailto:hotspot-jfr-dev at openjdk.org>>
Subject: [External] : Re: JFR: Scrubbing sensitive information from events

Hello,

Here is an example of the types of events we are concerned about:

Recording
?
??? Event (e.g. jdk.InitialSystemProperty)
?     ??? eventType: "jdk.InitialSystemProperty"
?     ??? startTime
?     ??? duration
?     ??? fields:
?     ?     ??? key: "javax.net.ssl.keyStorePassword"
?     ?     ??? value: "supersecret"
?     ?     ??? ...
?     ??? ...
?
??? Event (e.g. jdk.JVMInformation)
?     ??? eventType: "jdk.JVMInformation"
?     ??? jvmArguments: [ "-Xmx4G", "-Djavax.net.ssl.keyStorePassword=supersecret", ... ]
?     ??? ...
?
??? ...

The rules are slightly challenging as they need to account for key/value pairs, arrays and simple fields (like commandLine field).
Here<https://urldefense.com/v3/__https://gist.github.com/r1viollet/812ed70c6410c4f62640fd792570d36c__;!!ACWV5N9M2RV99hQ!LrFg9xF9Jy2l4LW6sj6mxVPhLXr30tA_2lzstCSiBbi4SxLyh8t2wDJGc4E1b7ePKrrsivDhkoZtMsHWCKsBeBLJ$> is a scrub file example. I'm happy to consider ways to simplify this proposal. Storing JFR files would also be helpful to consider test cases.
Regards,

Erwan


Le mar. 3 juin 2025 ? 11:50, Erik Gahlin <erik.gahlin at oracle.com<mailto:erik.gahlin at oracle.com>> a ?crit :
We have discussed it, but we don't understand all the details. We are also unsure how to best expose it to the end user. Let's say there was a command line option -XX:FlightRecorder:scrub-file=<file>.

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

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

Hello,

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

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

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

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

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

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

Thank you, Best regards,

Erwan Viollet,

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

From stuefe at openjdk.org  Tue Aug 26 08:02:37 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 26 Aug 2025 08:02:37 GMT
Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <Qs7Q_Fvkz_LHENAVISVRQiDSRJl6sBCwfMnWbnAx_AU=.5562bf09-665d-4335-b246-4d974647e8b2@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
 <RiNISYo5_WuB-RmcBLU0fIixnotyWCTihF2Q5nk7_Jo=.20ce6de5-f25b-4c60-b5f1-b3a898a335d4@github.com>
 <cmWFUKDnTozlqMCYqQbElk93BYWrhbr71PPONLFaXV0=.66103679-6413-48dd-a08e-91f2eea61c21@github.com>
 <YYtu5mqNoLQxNVt0i5NnDDxcbT0kF6xEBLqGmAxdwug=.5a986262-a3eb-4cc8-ac97-ac8405880176@github.com>
 <FWcxyeLcziSTI84GXACo8UDovehDhqS6x-Y7XaUjc8s=.f0ec1b30-cec1-418e-9b61-f8e10fa14d36@github.com>
 <Qs7Q_Fvkz_LHENAVISVRQiDSRJl6sBCwfMnWbnAx_AU=.5562bf09-665d-4335-b246-4d974647e8b2@github.com>
Message-ID: <_a7bvHYlUDn0S6REAHUWOlEOq4lAiPGQLzHKrzyeogI=.91af02e1-4bfb-41d9-a646-a8d6da2fc6f2@github.com>

On Wed, 20 Aug 2025 19:57:56 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>>> > You mean adding the vsize, swap etc fields to ResidentSetSize?
>>> > I thought about that, but then it would be weirdly misnamed. RSS has a very specific meaning. So we would have ResidentSetSize.vsize, ResidentSetSize.swap, ResidentSetSize.rss (?)
>>> 
>>> I was thinking something like this:
>>> 
>>> ```
>>> <Event name="ResidentSetSize" category="Java Virtual Machine, Memory" ... >
>>>   <Field type="ulong" contentType="bytes" name="size" .../>
>>>   <Field type="ulong" contentType="bytes" name="peak" ..  />
>>>   <Field type="ulong" contentType="bytes" name="anonymous"   />
>>>   <Field type="ulong" contentType="bytes" name="file" />
>>>   <Field type="ulong" contentType="bytes" name="sharedMemory"  />
>>> </Event>
>>> ```
>> 
>> Hmm, yes, that would be one alternative.
>> 
>>> 
>>> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? Regarding other metrics, perhaps they should go into other events, or perhaps new events should be created. I haven't had time to look into it.
>>> 
>>> > Mainly, I can build myself graphs in JMC for all these fields in one graph and correlate all the values.
>>> 
>>> Periodic events can be emitted with the same timestamp. That way they can be grouped together. This is what we do with NativeMemoryUsage and NativeMemoryTotal.
>>> 
>>> These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future.
>> 
>> I spent a lot of the time allotted to this PR deliberating on how exactly to shape the events. I didn't want just to jam them in. And I agree. I dislike it how tight the coupling is between the data model and the renderer in the case of JMC. It leads to many UI inconsistencies and gives the wrong motivation.
>> 
>> Unfortunately, we live in a world where JMC is the only serious and freely available tool, and where JFR protocol is not open, so I fear this is likely to stay that way.
>> 
>> In the case of this PR, an argument can be made for grouping OS-side process-related metrics together into one event. Doing it the way I did is not absurd; this is how these metrics are often presented: vsize+rss+swap, complementing each other and giving a holistic view of the OS side of process memory consumption?especially rss+swap. You need swap to be able to explain rss.
>> 
>> I also agonized about the platform-specific aspects of this. This is rather Linux-centric. But again, reality: Linux is by far the m...
>
> @tstuefe 
> I think that putting those metrics (vsize, swap, rss, etc) under a new `ProcessSize` event (while not changing `jdk.ResidentSetSize`) makes sense. This allows JMC to continue as normal,  and it also keeps the relevant metrics together so they can be easily interpreted in relation to each other.
>>These events will likely be around for a long time. We shouldn't design them just to match the workflow of one tool as it currently works. New functionality can be added in the future.
>     
> @egahlin , is there a procedure for deprecating event types? Or are events permanent once introduced? If you decide to go the above route (leaving all the metrics in `ProcessSize`), maybe it would be possible to mark the `jdk.ResidentSetSize` event for deprecation to allow JMC time to eventually switch over to using the new event for its charts? 
> 
>> When it comes to non-rss metrics, there is a Swap event, but not sure it is appropriate? 
> 
>  I think this new swap data is process-specific so is not already covered by `jdk.SwapSpace`, which shows the max amount available and how much is currently free to the OS.  
> I think it could be reasonable to leave the process' swap data in `ProcessSize` rather than the `jdk.SwapSpace` which contains data for the whole OS. The connecting thread is that this info is a "process" metric being grouped with other memory metrics for this specific process. 
> 
> Another option, in order to avoid duplication, could be to leave the RSS metrics in the `jdk.ResidentSetSize` event, not put them in the `ProcessSize` event, and correlate them by giving them the same timestamp (as Erik mentions above). 
> Something similar was  also done with the `NativeMemoryUsagePeak` and `NativeMemoryUsageTotalPeak` events (which are GraalVM specific) to avoid having to modify `NativeMemoryUsage` and `NativeMemoryUsageTotal`. Admittedly, this is probably not as clean or convenient. 
> 
> Either way, I agree that putting all the metrics in `ProcessSize` in their own individual events is not the best way.

Thank you, @roberttoyonaga ! Let's see what @egahlin writes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3223056141

From egahlin at openjdk.org  Tue Aug 26 13:05:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 26 Aug 2025 13:05:42 GMT
Subject: RFR: 8365306: Provide OS Process Size and Libc statistic metrics
 to JFR
In-Reply-To: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
References: <r4zqfECC3D8jZuWpPIDcE6PRmCkiKTQqXmpaQX-lG6k=.d57bc06c-92e8-4a01-827c-0013fbb9bed0@github.com>
Message-ID: <x2eY7XVoFCrS5wRIDMgqxinePOP075JngRYNAuqRK6Y=.cf778762-62b0-4e09-aa67-1a9e4c0da60a@github.com>

On Wed, 13 Aug 2025 09:42:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This provides the following new metrics:
> - `ProcessSize` event (new, periodic) 
>   - vsize (for analyzing address-space fragmentation issues)
>   - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat)
>   - peak RSS 
>   - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing)
>   - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size)
> - `LibcStatistics` (new, periodic)
>   - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading)
>   - retained malloc size (super-important for the same reason)
>   - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`)
> - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims)
>    - RSS before and RSS after
>    - RSS recovered by this trim
>    - whether it was an automatic or manual trim
>    - duration
> - `JavaThreadStatistic`
>   - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.)
>   - nonJava thread counter (new field) (needed to interprete the os thread counter)
> 
> Notes:
> - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it.
> 
> - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue.
> 
> I provided implementations, as far as possible, to Linux, MacOS and Windows.
> 
> Testing:
> - ran the new tests manually and as part of GHAs

Events can be viewed as tables in a relational database. Duplicating information or designing tables based on the user interface is not a good idea. Correlating or grouping data from different events is not a new problem. The way we have solved it in the past is by using an explicit ID, similar to a foreign key (gcId, compilerId, safepointId etc), or by using the same timestamp (ActiveSetting, NativeMemory* etc.). In this case, I think a timestamp makes more sense. Tools can place the value on a timeline and have memory on the y-axis.

An alternative design is to do something similar to the NativeMemoryUsage event. That is, to split the data per type

    <Event name="ProcessMemoryUsage">
      <Field type="MemoryType" name="type" label="Type" />
      <Field type="ulong" contentType="bytes" name="amount" label="Amount"/>
    </Event>

and then emit what is supported on a specific platform and have all those event with the same timestamp.

I'm not sure which of the following memory types make sense to include, there is also a maintenance aspect, or if it the list is correct or complete, but the data would be normalized, even if it differs depending on the platform.

    Memory Type                 Linux    macOS   Windows Description
    -------------------------- ------ -------- --------- ----------------------------------------------------------'
    Resident Set Size             Yes      Yes         -  Resident memory currently in physical RAM
    Private Bytes                   -        -       Yes  Privately allocated memory
    Shared Memory                 Yes      Yes       Yes  Memory shared among processes
    Virtual Memory Size           Yes      Yes       Yes  Total reserved address space
    Commit Charge                   -        -       Yes  Promised/guaranteed memory for process
    Mapped File Memory            Yes      Yes       Yes  Memory mapped from files
    Page Table Size               Yes        -         -  Memory used for page tables
    Swap / Swapped                Yes      Yes       Yes  Memory swapped out to disk
    Wired Memory                    -      Yes         -  Locked memory that can't be paged out
    Compressed Memory               -      Yes         -  Memory compressed by the system
    Paged Pool                      -        -       Yes  Pool for pageable kernel allocations
    Non-paged Pool                  -        -       Yes  Pool for non-pageable kernel allocations
    Working Set                     -        -       Yes  Memory pages currently in RAM for the process
    Stack                         Yes      Yes       Yes  Memory used by call stacks
    Heap / Malloc                 Yes      Yes       Yes  Dynamically allocated memory (heap)
    Image                         Yes      Yes         -  Memory used for executables and loaded libraries

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

PR Comment: https://git.openjdk.org/jdk/pull/26756#issuecomment-3224085095

From stuefe at openjdk.org  Tue Aug 26 22:03:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 26 Aug 2025 22:03:48 GMT
Subject: RFR: 8365611: Use lookup table for JfrEventThrottler
In-Reply-To: <C6GBO0mOEO5XEMPENP_J_3F2zQYtYaQMBKArBmRRZww=.21f546a4-c262-4286-859b-c6f4e0d029f5@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
 <C6GBO0mOEO5XEMPENP_J_3F2zQYtYaQMBKArBmRRZww=.21f546a4-c262-4286-859b-c6f4e0d029f5@github.com>
Message-ID: <xdmB8__kbXZhgMlRgzpNUtOPaWd7ef2njC1Tffc9FyE=.4668847d-ab49-4714-b894-11e8f72ce91d@github.com>

On Mon, 18 Aug 2025 10:15:50 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
>> 
>> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
>> 
>> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.
>
> I'm just trying to understand what is "underneath" this change. Throttling all events is not a target since it does not make sense.
> 
> Making it easier to plug in a new throttler for a new JVM event would make more sense.

Thanks @mgronlun @egahlin and @roberttoyonaga !

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

PR Comment: https://git.openjdk.org/jdk/pull/26801#issuecomment-3222794482

From stuefe at openjdk.org  Tue Aug 26 22:34:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 26 Aug 2025 22:34:01 GMT
Subject: Integrated: 8365611: Use lookup table for JfrEventThrottler
In-Reply-To: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
References: <JoGTsu1hororzlHAvQ_b2EO3BcDo0u_ir8uY-JvlO78=.35120f5e-ffb2-4a4d-b308-628a356a8579@github.com>
Message-ID: <n0p2UUHDDamS-chy4-cu-6rpvo-YT2J5fPp9nvtBHl4=.59ed8fe6-add5-4696-a3a0-bbb81bb3bd62@github.com>

On Fri, 15 Aug 2025 14:58:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
> 
> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
> 
> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.

This pull request has now been integrated.

Changeset: 82289f65
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82289f6559cc083ee306b3175fef3ae9f87d6b1c
Stats:     90 lines in 2 files changed: 45 ins; 25 del; 20 mod

8365611: Use lookup table for JfrEventThrottler

Reviewed-by: mgronlun

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

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

From shade at openjdk.org  Wed Aug 27 14:50:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Aug 2025 14:50:43 GMT
Subject: RFR: 8356968: JFR: Compilation event should be enabled for all
 compilations by default
In-Reply-To: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
References: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
Message-ID: <VMUIajIUNia1crd1E7F_kPc9Z7t3gq_lByAa9I33tR0=.1578f969-4a2a-4870-8a28-08c3a88c5716@github.com>

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

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

I still believe this is a right idea, BTW :)

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

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

From egahlin at openjdk.org  Wed Aug 27 16:02:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 27 Aug 2025 16:02:51 GMT
Subject: RFR: 8356968: JFR: Compilation event should be enabled for all
 compilations by default
In-Reply-To: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
References: <Pg2sX3PzurSWhB7CAUGL91N9P367COp3WvwdGnVpLx4=.cb42483a-3d0a-487b-ad52-feb5a49d7d1b@github.com>
Message-ID: <P9rI-qqW1hiTsQNnxvsJvOCh1sPoR96jQMrKMgFQUJg=.1e1e48e5-34e7-4bd4-8b66-69984cdc7958@github.com>

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

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

`jfr summary` doesn't show the full cost of an event. The jdk.CheckPoint event also constains information about methods, classes and class loaders that the jdk.Compilation events hold references to. If you want to see the full cost:

    $ java -Xcomp -XX:StartFlightRecording:jdk.Compilation#threshold=0ns,filename=recording.jfr
      -jar ./build/platform/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
    $ jfr scrub recording.jfr waste-free.jfr
    $ jfr scrub --exclude-events jdk.Compilation waste-free.jfr no-compilation.jfr
    $ ls -l waste-free.jfr no-compilation.jfr
    -rw-r--r--  1 -----  -----  2054496 Aug 27 17:29 waste-free.jfr
    -rw-r--r--  1 -----  -----   895963 Aug 27 17:32 no-compilation.jfr

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

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

From dholmes at openjdk.org  Thu Aug 28 06:52:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 06:52:41 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <upX9JgHw42jbEwfsFoVsnJwFtecUsC_EZVfrRZLlqbo=.37c0cf66-a924-4ebf-ae0d-b18b592a4ac5@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

I can't say I like the general changes to UL to accommodate this. I also don't really like what JFR is already doing. I'm trying to see what the motivation is here. It appears to be "give a verbose startup message but don't label it as a 'warning'".  But there is also no guarantee that `jfr+startup` is being logged to `stdout` so this could by-pass the user's control over logging output!

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

PR Review: https://git.openjdk.org/jdk/pull/26957#pullrequestreview-3163457152

From jbechberger at openjdk.org  Thu Aug 28 07:02:46 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 28 Aug 2025 07:02:46 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <tqclVA9tWr0X1nOHUxne-5gxWNqn2qi0T9NeIAGYgC4=.60ffdd28-7924-4eb2-ae55-f3ddc7840df0@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

The motivation is to better capture the user's intent. When the user doesn't set any warning level, then we keep the default behaviour, for backwards compatibility as in the original change, when the user sets the logging level, then we consider it.

You mentioned yourself in the original issue:


 I'm just not sure we have a way to query if the logging level has been explicitly set to a given value.


I just implemented this. I just implemented a way to properly check whether the user didn't specify a logging level, so the code doesn't have to assume that a `warning` logging level means the user didn't set anything.

This change tries to reduce confusion.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232196397

From dholmes at openjdk.org  Thu Aug 28 07:57:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 07:57:43 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <OyJ4ccSOqfH0xY39FRh5tSO6JVjT-RFCe0dVr3G30ww=.a06256fa-6b5e-43ff-9668-7f5e192c7bed@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

What was the original issue? I have forgotten about this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232364965

From jbechberger at openjdk.org  Thu Aug 28 08:24:41 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 28 Aug 2025 08:24:41 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <nmzMdCujz2lrDkT_owCBAlK-s_tpo2QEivFPL7fnZ5A=.3cf87678-ad16-47d5-9401-39987c0f90c9@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

The original issue was [JDK-8244190](https://bugs.openjdk.org/browse/JDK-8244190), this PR just fixes a short-coming of the implementation. The limitations is even mentioned in [one of the tests](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/startupargs/TestStartupMessage.java):


        startJfrJvm("-Xlog:jfr+startup=error")
             .shouldNotContain("[jfr,startup")
             .shouldNotContain("Started recording")
             .shouldNotContain("Use jcmd");

         // Known limitation.
         // Can't turn off log with -Xlog:jfr+startup=warning

         startJfrJvm()
             .shouldContain("[info][jfr,startup")
             .shouldContain("Started recording")
             .shouldContain("Use jcmd");


This PR updates the test too.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232456905

From dholmes at openjdk.org  Thu Aug 28 13:06:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Aug 2025 13:06:45 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <nmzMdCujz2lrDkT_owCBAlK-s_tpo2QEivFPL7fnZ5A=.3cf87678-ad16-47d5-9401-39987c0f90c9@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
 <nmzMdCujz2lrDkT_owCBAlK-s_tpo2QEivFPL7fnZ5A=.3cf87678-ad16-47d5-9401-39987c0f90c9@github.com>
Message-ID: <DWf13_qW6ZElDVuy_IE8e3F1t6wzH8idAQkAV3lvb2Q=.58c915cd-9d2f-424f-ae08-b1aff5684690@github.com>

On Thu, 28 Aug 2025 08:22:05 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> The original issue was [JDK-8244190](https://bugs.openjdk.org/browse/JDK-8244190), this PR just fixes a short-coming of the implementation. 

Okay in the original JBS issue I wrote:

> How about you mark the output for jfr+startup info logging and have StartFlightRecording enable that logging level if not explicitly disabled? That way the output is the same, no other output is affected and the user can still turn it off if needed. I'm just not sure we have a way to query if the logging level has been explicitly set to a given value. 

But what got implemented was not what I had in mind - nor, I think,  is the adjustment you propose here. What I intended was along the lines of:

log_info(jfr, startup)("The startup message");

and then in the logic that starts JFR something like:

if (!log_is_enabled_on_stdout(info, jfr startup)
  Log::Configuration( /* enable jfr+startup on stdout */)

Though checking if it is enabled on stdout may be the tricky part. This was recognised in the original PR:

> I have chosen to implement 5. It's not perfect, but perhaps sufficient for now? 

but you also have to allow for it being turned off explicitly by the user.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3233422789

From jbechberger at openjdk.org  Thu Aug 28 13:18:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 28 Aug 2025 13:18:44 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <KJqwnWdQWsrYiVjMx_phP9rDmnLhOezEQVtTHZO1XBE=.d331fca6-49fd-4ac5-a6e0-3bb83dcb6ec2@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

But isn't my PR closer to what the user expects? When you explicitly set the level to `warning`, no `info` level messages should be printed

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3233467744

From dholmes at openjdk.org  Fri Aug 29 01:58:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Aug 2025 01:58:46 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <G8xjjyKWSViKoKoobA--pfHMy9XkU7jjunQEoL1mWqM=.2f48ba9a-93ef-4a10-9105-3c18a1395e1c@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Functionally yes, but I'm just not sure about the mechanism. Need to think more about it. This reminds me of the flag complexity: FLAG_IS_DEFAULT, FLAG_IS_CMDLINE etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3235455737

From egahlin at openjdk.org  Sun Aug 31 23:05:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 31 Aug 2025 23:05:46 GMT
Subject: RFR: 8365066: RecordingStream and RemoteRecordingStream do not
 terminate when the associated Recording is stopped or closed externally
In-Reply-To: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
References: <ZYiV__ze3Xs5dCbR5CCDwzvEp3tOCHyE6d_8ISiUc4Q=.af4e9552-e2dd-4822-b412-7d378f9ab682@github.com>
Message-ID: <z2Yw-tllS4mGV1MxzbaZA5fYqblGoQwYT0ZfHirDr2g=.12579116-c993-489b-8cc8-dd40083f9420@github.com>

On Sat, 9 Aug 2025 01:33:29 GMT, Chihiro Ito <cito at openjdk.org> wrote:

> Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. 
> 
> Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams.
> 
> Tests updated to validate lifecycle consistency: 
> Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream.
> 
> Test: jdk/jdk/jfr

I've looked into the issue, and I'm not sure a RemoteRecordingStream should be closed if the underlying recording is.

- One use case for the RemoteRecordingStream is to replicate the repository on another host. When the monitored application exits (and closes the recording), the data should be available on another machine. If we close the stream, data will be lost (prematurely). I need to think about this some more.

- I don't think we need to do anything when the underlying recording is stopped for RemoteRecordingStream, since a stopped stream should wait until all events in the recording have been consumed. The DownloadThread will end when there is no more data to be read from FlightRecorderMXBean::readStream.

-  For a RecordingStream, I think Recording::stop/close can just delegate to RecordingStream::stop/close and we can get the exact same behavior as if the stream was stopped/closed.

I have implemented the above changes. You can look at it here https://github.com/openjdk/jdk/pull/27025

I noticed that the underlying Recording object may be exposed before the stream has been initialized, so I added synchronization. Now, any other thread trying to get a recording will have to wait for the RecordingStream initialization to complete.

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

PR Comment: https://git.openjdk.org/jdk/pull/26710#issuecomment-3240474514