From nbenalla at openjdk.org  Mon Dec  2 23:19:53 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Dec 2024 23:19:53 GMT
Subject: RFR: 8343780: Add since checker tests to the Tools area modules
 and add missing @since to  jdk.jfr [v5]
In-Reply-To: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>
References: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>
Message-ID: <PysC_4wqtH9o58NR8TdwdQSRU_hK3w85e8Vq4EkvDQE=.0fdff94d-87c5-4f99-acc1-61012df3b9d7@github.com>

> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442.
> 
> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers.
> 
> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK.
> 
> Notes: 
> - I have also added an `@since` tag that was missing.
> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test)
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Revert "add a missing \@since tag to RecordingStream.onMetadata"
  
  This reverts commit 091fb28320e2cd3471bfb5640202dbf4f04afbbe.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21982/files
  - new: https://git.openjdk.org/jdk/pull/21982/files/091fb283..7858f99b

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

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

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

From nbenalla at openjdk.org  Mon Dec  2 23:19:53 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Dec 2024 23:19:53 GMT
Subject: RFR: 8343780: Add since checker tests to the Tools area modules
 and add missing @since to  jdk.jfr [v4]
In-Reply-To: <WY4h7c3raDfs9kLswdWtasyhQk18UXcrH0QruGZZ7-E=.617d79be-c49b-4b9f-82db-a29aab02ba7c@github.com>
References: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>
 <WY4h7c3raDfs9kLswdWtasyhQk18UXcrH0QruGZZ7-E=.617d79be-c49b-4b9f-82db-a29aab02ba7c@github.com>
Message-ID: <_nxGOeqRO_xd0mKBoGEpf1pPvRYUBBG61V5pG3CzGe8=.3ea101a0-f684-4adf-9c8c-63df69954412@github.com>

On Fri, 29 Nov 2024 18:53:52 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442.
>> 
>> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers.
>> 
>> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK.
>> 
>> Notes: 
>> - I have also added an `@since` tag that was missing.
>> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test)
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a missing \@since tag to RecordingStream.onMetadata

Reverting the change to `RecordingStream`, as [JDK-8345339](https://bugs.openjdk.org/browse/JDK-8345339) will filed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21982#issuecomment-2513176418

From tprinzing at openjdk.org  Tue Dec  3 00:40:24 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 3 Dec 2024 00:40:24 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  split socket connect failure out to its own event.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/13f81570..f7b3be00

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

  Stats: 327 lines in 16 files changed: 240 ins; 21 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From liach at openjdk.org  Tue Dec  3 02:08:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 02:08:33 GMT
Subject: RFR: 8345343: Hide java.lang.classfile.components package to
 implementation
Message-ID: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>

Draft for preliminary review. Writing CSR right now.

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

Commit messages:
 - 8345344: Hide java.lang.classfile.components package to implementation

Changes: https://git.openjdk.org/jdk/pull/22503/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345343
  Stats: 170 lines in 33 files changed: 12 ins; 116 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/22503.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22503/head:pull/22503

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

From asotona at openjdk.org  Tue Dec  3 06:25:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Dec 2024 06:25:38 GMT
Subject: RFR: 8345343: Hide java.lang.classfile.components package to
 implementation
In-Reply-To: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
References: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
Message-ID: <iMUprwalXM8x_8wCXgQbT6DIwquWTyND62WG8kQyRa0=.ccf26fd1-dbc4-49ac-b646-09707ed9fe94@github.com>

On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized.
> 
> To compensate in such a short time to the stabilization of JDK 24, we propose to temporarily move this package to jdk.internal instead. This allows us to better consider the role of this package and its members.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.

I don't see a clear reason for this drastic last-minute change.

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

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22503#pullrequestreview-2474687952

From alanb at openjdk.org  Tue Dec  3 08:12:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 08:12:43 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
Message-ID: <5c8gIt8-z91QNINjYzUv5lpgo_0opzxoyFnW3GGMI6w=.d57ac699-6478-4f28-be6b-6fef9f5295e3@github.com>

On Tue, 3 Dec 2024 00:40:24 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   split socket connect failure out to its own event.

Would it be possible to sync up the branch from master as it hasn't been sync'ed up since Oct.

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2513817462

From nbenalla at openjdk.org  Tue Dec  3 09:08:47 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Dec 2024 09:08:47 GMT
Subject: Integrated: 8343780: Add since checker tests to the Tools area modules
 and add missing @since to  jdk.jfr
In-Reply-To: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>
References: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>
Message-ID: <zxmqKALybxUo7Y3TwpsV42e5Zym5vHjRaf63jRkXKu0=.e64a373e-1f09-454e-b134-87c02416b61d@github.com>

On Fri, 8 Nov 2024 15:19:34 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442.
> 
> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers.
> 
> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK.
> 
> Notes: 
> - I have also added an `@since` tag that was missing.
> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test)
> 
> TIA

This pull request has now been integrated.

Changeset: c330b90b
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c330b90b9f43f80c322153585fa78704358f0224
Stats:     16 lines in 6 files changed: 1 ins; 0 del; 15 mod

8343780: Add since checker tests to the Tools area modules and add missing @since to  jdk.jfr

Reviewed-by: cstein, egahlin

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

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

From asotona at openjdk.org  Tue Dec  3 10:30:41 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Dec 2024 10:30:41 GMT
Subject: RFR: 8345343: Hide java.lang.classfile.components package to
 implementation
In-Reply-To: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
References: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
Message-ID: <VTRSg7ptyvXF83Sm-YUXkqYOto-u-lgTfcxXzuGYd2c=.82e6a0e3-3db4-40a3-a2a8-502e251b2507@github.com>

On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized.
> 
> To compensate in such a short time to the stabilization of JDK 24, we propose to temporarily move this package to jdk.internal instead. This allows us to better consider the role of this package and its members.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.

`java.lang.classfile.components.ClassPrinter` received significant positive feedback in the recent years, it became an essential debugging and logging tool.
`java.lang.classfile.components.ClassRemapper` has been designed based on user requests, it received positive feedback in the recent years and it is an essential component for class instrumentation.
`java.lang.classfile.components.CodeLocalsShifter` and `java.lang.classfile.components.CodeRelabeler` are essential components for class instrumentation and other advanced transformations, they have been designed based on the feedback from JFR class instrumentation conversion from ASM to Class-File API.
`java.lang.classfile.components.CodeStackTracker` has been designed as standalone component (out of the core Class-File API) for performance reasons. It has been strongly requested by users and it has been applied in a prototype of javac using Class-File API to generate classes.

There is no real justification for this change and I suggest to close it.

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

PR Comment: https://git.openjdk.org/jdk/pull/22503#issuecomment-2514149797

From alanb at openjdk.org  Tue Dec  3 12:36:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 12:36:41 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
Message-ID: <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>

On Mon, 25 Nov 2024 13:23:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Having a view for connect failures that doesn't require exceptions=all could be useful. Does this mean two events, one an instant event for the failures, the other a duration event for the connections that are slow to establish?
>
> A connection failure introduces a latency in the application, so probably best to have such an event durational as well.

@egahlin The updated PR proposes two duration events: jdk.SocketConnect for when a connection is established, and jdk.SocketConnectFailed for when a connection cannot be established. Naming aside, it seems that would allow the jfr views that you listed above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867647214

From tprinzing at openjdk.org  Tue Dec  3 15:40:02 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 3 Dec 2024 15:40:02 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v7]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <lCMAOlIQ_nflVjOpkMwLRmXTWS3QGBPN5YlVefIe-dQ=.e08c1bba-a76f-48c2-bba5-207ad65b9229@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into JDK-8310996
   
   # Conflicts:
   #	src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java
 - split socket connect failure out to its own event.
 - Added more tests for socket connect events.
   
   - SocketAdapter connect
   - SocketAdapter connect with exception
   - Socket connect with exception
   - SocketChannel connect with exception
   - SocketChannel non-blocking connect
   - SocketChannel non-blocking connect with exception
 - suggested changes
 - improved exception names and handling
 - Added support for connection failure and non-blocking connections.
   
   If an exception is thrown while attempting a connection, the message
   from the exception is stored in the event.  The start time of the
   initial connect call is stored and used when a finishConnect call is
   successful or an exception is thrown.
 - fix default settings
 - fix merge
 - Merge branch 'master' into JDK-8310996
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
 - added tests and support for sockets.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/dfa5620f...a379609e

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

Changes: https://git.openjdk.org/jdk/pull/21528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=06
  Stats: 738 lines in 16 files changed: 686 ins; 7 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From dfuchs at openjdk.org  Tue Dec  3 16:33:48 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Dec 2024 16:33:48 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
Message-ID: <d-1Z_pA5-i6YC2h366K3NW-FdJOB_ClRWdP4RkqpBgo=.033e93d2-fbc9-4028-b159-49fb071f98ea@github.com>

On Tue, 3 Dec 2024 00:40:24 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   split socket connect failure out to its own event.

src/java.base/share/classes/jdk/internal/event/SocketConnectFailedEvent.java line 145:

> 143:         if (shouldCommit(duration)) {
> 144:             commit(start, duration, host, address.getHostAddress(), port, connectEx.getMessage());
> 145:         }

Would it be better to pass `connectEx.toString()` here to capture the type of the exception and avoid the awkward case where the message could be the empty string or null? Same in the other offer() method above...

src/jdk.jfr/share/classes/jdk/jfr/events/SocketConnectFailedEvent.java line 52:

> 50:     @Label("Connect Exception Message")
> 51:     public String connectExceptionMessage;
> 52: }

There seem to be a missing newline at the end of this file

src/jdk.jfr/share/conf/jfr/default.jfc line 746:

> 744:       <setting name="enabled">true</setting>
> 745:       <setting name="stackTrace">true</setting>
> 746:       <setting name="threshold" control="socket-threshold">20 ms</setting>

Does this event needs a threshold?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867888476
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867909881
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867912497

From dfuchs at openjdk.org  Tue Dec  3 16:33:58 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Dec 2024 16:33:58 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
Message-ID: <1lHHT0dJUnuCp8V_J__oATyi7XKeVI5ikrlAAv-kgNo=.e300e896-7a46-4de9-94d9-2496452bcef8@github.com>

On Sat, 23 Nov 2024 08:36:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added more tests for socket connect events.
>>   
>>   - SocketAdapter connect
>>   - SocketAdapter connect with exception
>>   - Socket connect with exception
>>   - SocketChannel connect with exception
>>   - SocketChannel non-blocking connect
>>   - SocketChannel non-blocking connect with exception
>
> test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 157:
> 
>> 155:                         while (! sc.finishConnect()) {
>> 156:                             Thread.sleep(1);
>> 157:                         }
> 
> The connect method returns true if the connection is established, you should only need to poll finishConnect if the connection is not established immediately. Using a sleep is okay here (although 1ms is very low) and I'm guessing you've done this to avoid using a Selector.

It should be OK to sleep for longer if you don't want to use a selector.

> test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 216:
> 
>> 214:                 } catch (IOException ioe) {
>> 215:                     // we expect this
>> 216:                     connectException = ioe;
> 
> I think you'll need to adjust the try-catch to only set connectException if the connect or finishConnect methods fails. If the open or configureBlocking fails then connectException should not be set, instead the test should fail.

In addition there's no guarantee that connect will fail - so the test should guard for the case where connect might succeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867981816
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868041972

From dfuchs at openjdk.org  Tue Dec  3 16:33:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Dec 2024 16:33:55 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v7]
In-Reply-To: <lCMAOlIQ_nflVjOpkMwLRmXTWS3QGBPN5YlVefIe-dQ=.e08c1bba-a76f-48c2-bba5-207ad65b9229@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <lCMAOlIQ_nflVjOpkMwLRmXTWS3QGBPN5YlVefIe-dQ=.e08c1bba-a76f-48c2-bba5-207ad65b9229@github.com>
Message-ID: <RgCo5IhbI4VhTMCs0FKeovP_z6weI_jKDd8oSSGxfEY=.f56976af-4c80-4672-b1cc-586411a67c7a@github.com>

On Tue, 3 Dec 2024 15:40:02 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into JDK-8310996
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java
>  - split socket connect failure out to its own event.
>  - Added more tests for socket connect events.
>    
>    - SocketAdapter connect
>    - SocketAdapter connect with exception
>    - Socket connect with exception
>    - SocketChannel connect with exception
>    - SocketChannel non-blocking connect
>    - SocketChannel non-blocking connect with exception
>  - suggested changes
>  - improved exception names and handling
>  - Added support for connection failure and non-blocking connections.
>    
>    If an exception is thrown while attempting a connection, the message
>    from the exception is stored in the event.  The start time of the
>    initial connect call is stored and used when a finishConnect call is
>    successful or an exception is thrown.
>  - fix default settings
>  - fix merge
>  - Merge branch 'master' into JDK-8310996
>    
>    # Conflicts:
>    #	src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java
>    #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
>  - added tests and support for sockets.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/dfa5620f...a379609e

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 149:

> 147:                 } catch (IOException ioe) {
> 148:                     // we expect this
> 149:                     connectException = ioe;

Though unlikely the connect() call could succeed if another (test) process managed to rebind and listen to the port that our server socket just freed. 
An alternative could be to try to connect to a TCP port reserved by IANA, such as ports 225-241 for instance. Hopefully there should be nothing listening at these ports.

Another possibility would be to restart the whole thing untill connect actually fails.

You could try to find a refusing port that will generate an exception using something similar to https://github.com/openjdk/jdk/blob/3eaa7615cd7dc67eb78fb0a8f89d4e6662a0db37/test/jdk/java/nio/channels/SocketChannel/OpenLeak.java#L65
Note that I had some trouble with that on windows (attempting to connect to port 47 was using up the whole connect timeout on windows) so you might need to experiment a bit with different reserved ports if you want to go down this route.
 
In anycase, the case where connect() unexpectedly succeed should be handled, for instance by throwing a `jtreg.SkippedException`, or by simply printing a warning and returning, or by retrying with another port until an exception is obtained.

test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 185:

> 183:                     // we expect this
> 184:                     connectException = ioe;
> 185:                 }

Same remark as previouly: it's not guaranteed that connect() will not succeed.
Also I notice that we're using main/othervm here - and this method is not last one called in main() - so we might not want to throw SkippedException here. Possibly printing a warning and returning would be a better option. Or try with another port...

test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 146:

> 144:                     // we expect this
> 145:                     connectException = ioe;
> 146:                 }

Same remark as for the other test: exception is not a guaranteed outcome.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867974742
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867983998
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868044001

From liach at openjdk.org  Tue Dec  3 16:41:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 16:41:45 GMT
Subject: RFR: 8345343: Hide java.lang.classfile.components package to
 implementation
In-Reply-To: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
References: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
Message-ID: <Lk_rbcb45v1C486sQumPb542998JRGslc8alhVnLw2o=.c6f2b9db-b836-4411-8e74-250e155b1c7d@github.com>

On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized.
> 
> To compensate in such a short time to the stabilization of JDK 24, we propose to temporarily move this package to jdk.internal instead. This allows us to better consider the role of this package and its members.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.

After offline discussion, we decide to stick to continued preview status to facilitate adoption. #22501

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

PR Comment: https://git.openjdk.org/jdk/pull/22503#issuecomment-2515058684

From liach at openjdk.org  Tue Dec  3 16:41:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 16:41:45 GMT
Subject: Withdrawn: 8345343: Hide java.lang.classfile.components package to
 implementation
In-Reply-To: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
References: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
Message-ID: <X0MMee8f8cSow0R7jQ1ePI1S6MQ1of70n04IMawe_0w=.dd4d35b8-4491-432a-9ece-89cc80eff479@github.com>

On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized.
> 
> To compensate in such a short time to the stabilization of JDK 24, we propose to temporarily move this package to jdk.internal instead. This allows us to better consider the role of this package and its members.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Tue Dec  3 17:11:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 17:11:49 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <d-1Z_pA5-i6YC2h366K3NW-FdJOB_ClRWdP4RkqpBgo=.033e93d2-fbc9-4028-b159-49fb071f98ea@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
 <d-1Z_pA5-i6YC2h366K3NW-FdJOB_ClRWdP4RkqpBgo=.033e93d2-fbc9-4028-b159-49fb071f98ea@github.com>
Message-ID: <vgFbtAhltSSnmc33pLZH3I9ErEyapbr1GZ4Pi1tHk_4=.b7be426a-3322-410d-b537-19609e0ee908@github.com>

On Tue, 3 Dec 2024 15:12:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   split socket connect failure out to its own event.
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 746:
> 
>> 744:       <setting name="enabled">true</setting>
>> 745:       <setting name="stackTrace">true</setting>
>> 746:       <setting name="threshold" control="socket-threshold">20 ms</setting>
> 
> Does this event needs a threshold?

I think it needs to be a duration event, otherwise it's possible to a floor events when connections fail immediately. With the current proposal then it is at least configurable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868102788

From egahlin at openjdk.org  Tue Dec  3 23:45:39 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Dec 2024 23:45:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
Message-ID: <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>

On Tue, 3 Dec 2024 12:34:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A connection failure introduces a latency in the application, so probably best to have such an event durational as well.
>
> @egahlin The updated PR proposes two duration events: jdk.SocketConnect for when a connection is established, and jdk.SocketConnectFailed for when a connection cannot be established. Naming aside, it seems that would allow the jfr views that you listed above.

We could have two views with only one event. The query for the view could filter for exceptionMessage != null or a failure property. The advantage of having two events is that the failure event could have a threshold of 0 ms.

We are planning to add a throttling mechanism for exception events, perhaps per call site. The same mechanism could be used for a failed event. If you receive 500 events per second for a call site, there is little value in having additional events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868506166

From liach at openjdk.org  Tue Dec  3 23:55:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 23:55:40 GMT
Subject: RFR: 8345343: Hide java.lang.classfile.components package to
 implementation
In-Reply-To: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
References: <oHBOYwGv_w-vWZO1gkjaOfB-oq2Oy1zzKQNYA_hvSVQ=.bd167232-e705-4b1b-8841-911acda92b42@github.com>
Message-ID: <uZGpvo6KtDQGnWAkoAFnOpcOnBpaA-Xv44XAeBGtK3E=.bc05c72c-7565-41e3-a7d8-114639ec808f@github.com>

On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized. In the previous rounds of reviews by other engineers, most of the review efforts were devoted to other core modeling and API classes, and components was largely omitted; a few questions were asked, but no solution were proposed and the questions were forgotten.
> 
> To compensate in such a short time to the stabilization of JDK 24, we propose to temporarily move this package to jdk.internal instead. This allows us to better consider the role of this package and its members. We considered to continue previewing this package or making it an incubator module, but this is currently not possible as JEP 484 does not provide for any preview API or incubator module - to add such provisions, the JEP must be re-drafted and go through the draft to target process, and now is too late for that.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.
> 
> Testing: tier 1-3.

After further studies, due to JEP process restrictions, hiding is the only choice at this point. Reopening.

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

PR Comment: https://git.openjdk.org/jdk/pull/22503#issuecomment-2515822844

From alanb at openjdk.org  Wed Dec  4 12:28:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Dec 2024 12:28:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
 <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
Message-ID: <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>

On Tue, 3 Dec 2024 23:42:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> @egahlin The updated PR proposes two duration events: jdk.SocketConnect for when a connection is established, and jdk.SocketConnectFailed for when a connection cannot be established. Naming aside, it seems that would allow the jfr views that you listed above.
>
> We could have two views with only one event. The query for the view could filter for exceptionMessage != null or a failure property. The advantage of having two events is that the failure event could have a threshold of 0 ms.
> 
> We are planning to add a throttling mechanism for exception events, perhaps per call site. The same mechanism could be used for a failed event. If you receive 500 events per second for a call site, there is little value in having additional events.

We need to help Tim on the question of whether there is one or two events. 

An application that makes outbound network connections may run slowly for several reasons. A duration event may help to diagnose this, irrespective of whether the connection is established successfully or it fails, so one event is okay. Separately, another big source of latency is the name service / DNS lookup which happens before getting to the Socket connect. Maybe further work could add events to InetAddress for this.

When hunting misbehaving behavior then focusing on the cases where a connection cannot be established may be more interesting. So it's possible someone might want to run with threshold=0 to see all failed events. If there is throttling support, and since we control call site for both the successful and failed cases, could we live with one event?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1869400913

From liach at openjdk.org  Wed Dec  4 14:31:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Dec 2024 14:31:19 GMT
Subject: RFR: 8345486: Reevaluate the classes in java.lang.classfile.components
 package
Message-ID: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>

Over the years there have been significant rounds of cleanup to try and keep the classfile API as focussed and true to its underlying functional core as possible. One of the side-effects of such cleanups was to move higher-level functionalities from the root classfile API package `java.lang.classfile` to a separate package -- `java.lang.classfile.util`, then renamed to the current `java.lang.classfile.components`.

As is natural, most of the review cycles over the last few years have been spent on making sure that the functional core of the classfile API was fit for purpose, and good enough to tackle existing use cases, both within and without the JDK. A consequence of that is that the `java.lang.classfile.components` received, in comparison, relatively little reviewing attention. When we had a chance to look at this again [1], it quickly became clear that, while the functionalities provided by the classes in this package are generally useful, they have evolved in a rather ad-hoc fashion. Some functionalities, like `ClassPrinter`, are probably closer to belong to the core API than the `components` package suggests. Other functionalities (e.g. `CodeStackTracker`), seem more peripheral and, while useful, have received little to no feedback.

For these reasons, and in order to deliver the best classfile API we can, we would like to buy us some time to reevaluate the classes in this package. Unfortunately, given the little time left available to make changes in Java 24, the only realistic option left available to us is to temporarily move the `java.lang.classfile.components` to an internal package (`jdk.internal.classfile.components`). While this is unfortunate, we still believe it would be a better course of action than to ship the `components` package in its current state.

[1] - https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html

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

Commit messages:
 - 8345486: Reevaluate the classes in java.lang.classfile.components package

Changes: https://git.openjdk.org/jdk/pull/22544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345486
  Stats: 170 lines in 33 files changed: 12 ins; 116 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/22544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22544/head:pull/22544

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

From mcimadamore at openjdk.org  Wed Dec  4 14:31:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 14:31:19 GMT
Subject: RFR: 8345486: Reevaluate the classes in
 java.lang.classfile.components package
In-Reply-To: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
References: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
Message-ID: <Qppu5CYpSPuW1tNWffKgY_ratEqT9fzzbJVmgY5xpdc=.058a086b-502a-4d37-9c2e-2d81e783179a@github.com>

On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Over the years there have been significant rounds of cleanup to try and keep the classfile API as focussed and true to its underlying functional core as possible. One of the side-effects of such cleanups was to move higher-level functionalities from the root classfile API package `java.lang.classfile` to a separate package -- `java.lang.classfile.util`, then renamed to the current `java.lang.classfile.components`.
> 
> As is natural, most of the review cycles over the last few years have been spent on making sure that the functional core of the classfile API was fit for purpose, and good enough to tackle existing use cases, both within and without the JDK. A consequence of that is that the `java.lang.classfile.components` received, in comparison, relatively little reviewing attention. When we had a chance to look at this again [1], it quickly became clear that, while the functionalities provided by the classes in this package are generally useful, they have evolved in a rather ad-hoc fashion. Some functionalities, like `ClassPrinter`, are probably closer to belong to the core API than the `components` package suggests. Other functionalities (e.g. `CodeStackTracker`), seem more peripheral and, while useful, have received little to no feedback.
> 
> For these reasons, and in order to deliver the best classfile API we can, we would like to buy us some time to reevaluate the classes in this package. Unfortunately, given the little time left available to make changes in Java 24, the only realistic option left available to us is to temporarily move the `java.lang.classfile.components` to an internal package (`jdk.internal.classfile.components`). While this is unfortunate, we still believe it would be a better course of action than to ship the `components` package in its current state.
> 
> [1] - https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html

Changes look good.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22544#pullrequestreview-2478861128

From egahlin at openjdk.org  Wed Dec  4 14:36:49 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Dec 2024 14:36:49 GMT
Subject: RFR: 8345337: JFR: jfr view should display all direct subfields for an
 event type
Message-ID: <pviCwb_kxKdR7TBphJ_IioiZiwzt7siee1la-cPUi44=.b3879217-2372-434f-9f4b-38579876133c@github.com>

Could I have a review of a PR that fixes an issue when displaying subfields with 'jfr view'

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Remove accidentally added file
 - Initial

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

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

From redestad at openjdk.org  Wed Dec  4 14:36:49 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 4 Dec 2024 14:36:49 GMT
Subject: RFR: 8345337: JFR: jfr view should display all direct subfields
 for an event type
In-Reply-To: <pviCwb_kxKdR7TBphJ_IioiZiwzt7siee1la-cPUi44=.b3879217-2372-434f-9f4b-38579876133c@github.com>
References: <pviCwb_kxKdR7TBphJ_IioiZiwzt7siee1la-cPUi44=.b3879217-2372-434f-9f4b-38579876133c@github.com>
Message-ID: <msglV9S4p-J--16molR_OuVvvF-LnSm0fMhM7bJZD-E=.d3da01de-ad15-4a1f-b5e9-96c646d45e34@github.com>

On Mon, 2 Dec 2024 21:02:20 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes an issue when displaying subfields with 'jfr view'
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Thanks. This makes `jfr view jdk.ModuleExport <recording>` more complete, which was missing most of the useful columns:


Time     Exported Package : Name                    Exported Package : Exported Target Module : Name    Target Module : Version Target Module : Location     Target Module : Class Loader
-------- ------------------------------------------ --------------------------- ----------------------- ----------------------- ---------------------------- ------------------------------------------
13:46:10 javax/xml/crypto                                                  true N/A                     N/A                     N/A                          N/A
13:46:10 com/sun/net/httpserver/spi                                        true N/A                     N/A                     N/A                          N/A
13:46:10 com/sun/jndi/url/dns                                              true java.naming             24-internal             jrt:/java.naming             N/A
13:46:10 javax/security/auth/kerberos                                      true N/A                     N/A                     N/A                          N/A
13:46:10 org/w3c/dom/html                                                  true N/A                     N/A                     N/A                          N/A
...

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

PR Comment: https://git.openjdk.org/jdk/pull/22498#issuecomment-2514482560

From egahlin at openjdk.org  Wed Dec  4 14:46:43 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Dec 2024 14:46:43 GMT
Subject: RFR: 8340969: jdk/jfr/startupargs/TestStartDuration.java should be
 marked as flagless
In-Reply-To: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
References: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
Message-ID: <RXTf00_Pw_5kLW0BKmLpzNyPGXlN-Ai-J-aUHThkchI=.2abe93ee-bf9f-40b5-8e66-4298dbd8dc05@github.com>

On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test jdk/jfr/startupargs/TestStartDuration.java
> checks duration, the time might be too small for stress options like Xcomp.
> So it makes sense to mark it as flaglesss.

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21237#pullrequestreview-2478912826

From asotona at openjdk.org  Wed Dec  4 16:17:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Dec 2024 16:17:39 GMT
Subject: RFR: 8345486: Reevaluate the classes in
 java.lang.classfile.components package
In-Reply-To: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
References: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
Message-ID: <KPjGMM8iJjOA_-KsNzbI_5muYdA_TZ0-kEIlGSxDlsI=.040ec845-4b64-4e43-81d7-06ca4950517d@github.com>

On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Over the years there have been significant rounds of cleanup to try and keep the classfile API as focussed and true to its underlying functional core as possible. One of the side-effects of such cleanups was to move higher-level functionalities from the root classfile API package `java.lang.classfile` to a separate package -- `java.lang.classfile.util`, then renamed to the current `java.lang.classfile.components`.
> 
> As is natural, most of the review cycles over the last few years have been spent on making sure that the functional core of the classfile API was fit for purpose, and good enough to tackle existing use cases, both within and without the JDK. A consequence of that is that the `java.lang.classfile.components` received, in comparison, relatively little reviewing attention. When we had a chance to look at this again [1], it quickly became clear that, while the functionalities provided by the classes in this package are generally useful, they have evolved in a rather ad-hoc fashion. Some functionalities, like `ClassPrinter`, are probably closer to belong to the core API than the `components` package suggests. Other functionalities (e.g. `CodeStackTracker`), seem more peripheral and, while useful, have received little to no feedback.
> 
> For these reasons, and in order to deliver the best classfile API we can, we would like to buy us some time to reevaluate the classes in this package. Unfortunately, given the little time left available to make changes in Java 24, the only realistic option left available to us is to temporarily move the `java.lang.classfile.components` to an internal package (`jdk.internal.classfile.components`). While this is unfortunate, we still believe it would be a better course of action than to ship the `components` package in its current state.
> 
> [1] - https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22544#pullrequestreview-2479242574

From liach at openjdk.org  Wed Dec  4 17:33:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Dec 2024 17:33:51 GMT
Subject: RFR: 8345486: Reevaluate the classes in
 java.lang.classfile.components package
In-Reply-To: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
References: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
Message-ID: <qNb6aZ3switDRMzxfZ75dzfR_uWuGIImpjvemlWfIsM=.8e7af97b-6de9-4c73-855a-0c4c4f8694da@github.com>

On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Over the years there have been significant rounds of cleanup to try and keep the classfile API as focussed and true to its underlying functional core as possible. One of the side-effects of such cleanups was to move higher-level functionalities from the root classfile API package `java.lang.classfile` to a separate package -- `java.lang.classfile.util`, then renamed to the current `java.lang.classfile.components`.
> 
> As is natural, most of the review cycles over the last few years have been spent on making sure that the functional core of the classfile API was fit for purpose, and good enough to tackle existing use cases, both within and without the JDK. A consequence of that is that the `java.lang.classfile.components` received, in comparison, relatively little reviewing attention. When we had a chance to look at this again [1], it quickly became clear that, while the functionalities provided by the classes in this package are generally useful, they have evolved in a rather ad-hoc fashion. Some functionalities, like `ClassPrinter`, are probably closer to belong to the core API than the `components` package suggests. Other functionalities (e.g. `CodeStackTracker`), seem more peripheral and, while useful, have received little to no feedback.
> 
> For these reasons, and in order to deliver the best classfile API we can, we would like to buy us some time to reevaluate the classes in this package. Unfortunately, given the little time left available to make changes in Java 24, the only realistic option left available to us is to temporarily move the `java.lang.classfile.components` to an internal package (`jdk.internal.classfile.components`). While this is unfortunate, we still believe it would be a better course of action than to ship the `components` package in its current state.
> 
> [1] - https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html

Tier 1-5 test results look good.  Integrating early to help prepare for the 24 stabilization branch-off.

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

PR Comment: https://git.openjdk.org/jdk/pull/22544#issuecomment-2518096015

From liach at openjdk.org  Wed Dec  4 17:33:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Dec 2024 17:33:53 GMT
Subject: Integrated: 8345486: Reevaluate the classes in
 java.lang.classfile.components package
In-Reply-To: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
References: <C5LkuRrkDQ_-j9C9i7-DW-6wGs0dVgDu3oO6ytUAr6A=.70578667-c669-444d-9b80-5241afab4e88@github.com>
Message-ID: <AN9DfpISontfJvVbp10IzKWITC79GGftlmxFQtvOaLM=.f22ab326-9dc7-4c77-a115-3e665045e7aa@github.com>

On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> Over the years there have been significant rounds of cleanup to try and keep the classfile API as focussed and true to its underlying functional core as possible. One of the side-effects of such cleanups was to move higher-level functionalities from the root classfile API package `java.lang.classfile` to a separate package -- `java.lang.classfile.util`, then renamed to the current `java.lang.classfile.components`.
> 
> As is natural, most of the review cycles over the last few years have been spent on making sure that the functional core of the classfile API was fit for purpose, and good enough to tackle existing use cases, both within and without the JDK. A consequence of that is that the `java.lang.classfile.components` received, in comparison, relatively little reviewing attention. When we had a chance to look at this again [1], it quickly became clear that, while the functionalities provided by the classes in this package are generally useful, they have evolved in a rather ad-hoc fashion. Some functionalities, like `ClassPrinter`, are probably closer to belong to the core API than the `components` package suggests. Other functionalities (e.g. `CodeStackTracker`), seem more peripheral and, while useful, have received little to no feedback.
> 
> For these reasons, and in order to deliver the best classfile API we can, we would like to buy us some time to reevaluate the classes in this package. Unfortunately, given the little time left available to make changes in Java 24, the only realistic option left available to us is to temporarily move the `java.lang.classfile.components` to an internal package (`jdk.internal.classfile.components`). While this is unfortunate, we still believe it would be a better course of action than to ship the `components` package in its current state.
> 
> [1] - https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html

This pull request has now been integrated.

Changeset: 79eb77b7
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79eb77b782bd0c3cecee6c66b86f6f3e17054498
Stats:     170 lines in 33 files changed: 12 ins; 116 del; 42 mod

8345486: Reevaluate the classes in java.lang.classfile.components package

Reviewed-by: mcimadamore, asotona

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

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

From egahlin at openjdk.org  Wed Dec  4 18:36:11 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Dec 2024 18:36:11 GMT
Subject: RFR: 8345339: JFR: Missing javadoc for RecordingStream::onMetadata
Message-ID: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>

Could I have a review of a change that adds missing javadoc for the RecordingStream::onMetadata.

Testing: tier1 + test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From nbenalla at openjdk.org  Wed Dec  4 21:24:39 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Dec 2024 21:24:39 GMT
Subject: RFR: 8345339: JFR: Missing javadoc for RecordingStream::onMetadata
In-Reply-To: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
References: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
Message-ID: <_olCpUYV10NbNUGJ8mK987-znsCpIxNOUlV1fqWM5c8=.fc33500a-3342-4608-b873-b2416ae18678@github.com>

On Wed, 4 Dec 2024 15:27:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that adds missing javadoc for the RecordingStream::onMetadata.
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by nbenalla (Committer).

Small change request, copyright in `src/jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files/Snippets.java` need to be `2024`

Looks good to me.

[Without this javadoc](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8343780/api/jdk.jfr/jdk/jfr/consumer/RecordingStream.html#onMetadata(java.util.function.Consumer)), the example in the snippet and the text would use `EventStream` instead of `RecordingStream`.
I compiled the snippet and it is valid.

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

PR Review: https://git.openjdk.org/jdk/pull/22547#pullrequestreview-2479928093
Changes requested by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22547#pullrequestreview-2479932001
PR Comment: https://git.openjdk.org/jdk/pull/22547#issuecomment-2518582337

From egahlin at openjdk.org  Thu Dec  5 13:09:52 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Dec 2024 13:09:52 GMT
Subject: RFR: 8345339: JFR: Missing javadoc for RecordingStream::onMetadata
 [v2]
In-Reply-To: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
References: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
Message-ID: <fFaeFNBFbK6lb3ZQMXBvYX7iBAjcNDXs9uTDHyW1Avc=.05f6fa16-f4f8-4b4e-807f-e7aa8408e88d@github.com>

> Could I have a review of a change that adds missing javadoc for the RecordingStream::onMetadata.
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22547/files
  - new: https://git.openjdk.org/jdk/pull/22547/files/eb8f75d9..56dadb9b

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

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

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

From nbenalla at openjdk.org  Thu Dec  5 13:39:38 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Dec 2024 13:39:38 GMT
Subject: RFR: 8345339: JFR: Missing javadoc for RecordingStream::onMetadata
 [v2]
In-Reply-To: <fFaeFNBFbK6lb3ZQMXBvYX7iBAjcNDXs9uTDHyW1Avc=.05f6fa16-f4f8-4b4e-807f-e7aa8408e88d@github.com>
References: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
 <fFaeFNBFbK6lb3ZQMXBvYX7iBAjcNDXs9uTDHyW1Avc=.05f6fa16-f4f8-4b4e-807f-e7aa8408e88d@github.com>
Message-ID: <rUBV8n4pqV68VsFoRGaeLT1k8jiFYYLMYrcJ3bG4WyY=.57d24793-1675-41be-aefc-973a89fd5794@github.com>

On Thu, 5 Dec 2024 13:09:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a change that adds missing javadoc for the RecordingStream::onMetadata.
>> 
>> Testing: tier1 + test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by nbenalla (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22547#pullrequestreview-2481722742

From liach at openjdk.org  Thu Dec  5 14:31:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 14:31:38 GMT
Subject: RFR: 8345339: JFR: Missing javadoc for RecordingStream::onMetadata
 [v2]
In-Reply-To: <fFaeFNBFbK6lb3ZQMXBvYX7iBAjcNDXs9uTDHyW1Avc=.05f6fa16-f4f8-4b4e-807f-e7aa8408e88d@github.com>
References: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
 <fFaeFNBFbK6lb3ZQMXBvYX7iBAjcNDXs9uTDHyW1Avc=.05f6fa16-f4f8-4b4e-807f-e7aa8408e88d@github.com>
Message-ID: <Nc-tMEdJ5oEp5li7b3VcchAiKMIuXNC4qmg9HfzDieo=.831ca15c-2d02-4c85-86b7-5066ab7fcad6@github.com>

On Thu, 5 Dec 2024 13:09:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a change that adds missing javadoc for the RecordingStream::onMetadata.
>> 
>> Testing: tier1 + test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

There is indeed no specification change, besides the example code update which is irrelevant.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22547#pullrequestreview-2481874283

From egahlin at openjdk.org  Thu Dec  5 14:53:42 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Dec 2024 14:53:42 GMT
Subject: Integrated: 8345339: JFR: Missing javadoc for
 RecordingStream::onMetadata
In-Reply-To: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
References: <h-gig3yN00g-E3IcZFpHTtiVr9Nz2JMMW6bvG1dXCgw=.5e7f3db8-baa4-42ff-ab29-4ac1440ca313@github.com>
Message-ID: <jMcEjt5wXl_GEV_OZ3htrPiQIf_27zmjK3LTKcYa9WM=.4718b199-4b20-4223-86cb-ce4182154227@github.com>

On Wed, 4 Dec 2024 15:27:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that adds missing javadoc for the RecordingStream::onMetadata.
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 97b8a09b
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97b8a09bda92fab38b97acd49b6a5e4607b396e6
Stats:     43 lines in 2 files changed: 42 ins; 0 del; 1 mod

8345339: JFR: Missing javadoc for RecordingStream::onMetadata

Reviewed-by: nbenalla, liach

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

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

From lmesnik at openjdk.org  Fri Dec  6 18:44:48 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 6 Dec 2024 18:44:48 GMT
Subject: Integrated: 8340969: jdk/jfr/startupargs/TestStartDuration.java should
 be marked as flagless
In-Reply-To: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
References: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
Message-ID: <rpdIGnWlqfAJdv2_BrwQPt892gv7XHhjqfmEl_Mir_M=.af60a8ee-6baf-4673-b647-f220518e8177@github.com>

On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test jdk/jfr/startupargs/TestStartDuration.java
> checks duration, the time might be too small for stress options like Xcomp.
> So it makes sense to mark it as flaglesss.

This pull request has now been integrated.

Changeset: 470701f0
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/470701f0bb269834cc0e1cb40f7d34e92226454b
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless

Reviewed-by: syan, egahlin

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

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

From tprinzing at openjdk.org  Tue Dec 10 21:41:18 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 10 Dec 2024 21:41:18 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  requests fixes
  
  - Use IOException.toString() instead of getMessage() in case it's empty
  - Attempts to test connect exceptions may fail due to unexpected
    successful connect.  Tests quit with uncompleted status if the
    connect is successful and are retried a small number of times until
    the test can be performed properly.  If the retries are exceeded an
    exception is generated indicating the test can't be setup properly.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/a379609e..5e55ffc6

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

  Stats: 62 lines in 6 files changed: 43 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From egahlin at openjdk.org  Thu Dec 12 03:53:06 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 12 Dec 2024 03:53:06 GMT
Subject: RFR: 8346047: JFR: Incorrect percentile value in 'jfr view'
Message-ID: <c8y5w-zD9vd1QTxevbMb0l2i48Ih67kIZeaaK1uAUQc=.9ca235af-bd7f-4494-869e-25d177f01a4a@github.com>

Could I have a review of PR that fixes an issue with 'jfr view' when calculating the percentile.

It would be possible to create a separate variable for the truncated doubleIndex, but I think this is easier to read than introducing fourth index variable.

Testing: jdk/jdk/rf

Thanks
Erik

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

Commit messages:
 - Remove incorrectly added file
 - Initial

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

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

From egahlin at openjdk.org  Thu Dec 12 03:53:12 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 12 Dec 2024 03:53:12 GMT
Subject: RFR: 8346052: JFR: Incorrect average value in 'jfr view'
Message-ID: <beF0-KIfR1j6MRKMhOAc35ewpRHAFe1HyTQtutROBmw=.e34a181b-8849-4467-8f14-593cda70d0d4@github.com>

Could I have a review of PR that fixes an issue with 'jfr view' when calculating the average for a timespan.

Testing: jdk/jdk/rf

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From egahlin at openjdk.org  Thu Dec 12 04:01:37 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 12 Dec 2024 04:01:37 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
 <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
 <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz
 5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>
Message-ID: <xqj9Uffno4vZWpf6VLW9oNc3I4hPEVYBuwq0hRIvSgk=.f25d0ad9-64c5-43e2-8fdc-654ab25b20bc@github.com>

On Wed, 4 Dec 2024 12:26:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We could have two views with only one event. The query for the view could filter for exceptionMessage != null or a failure property. The advantage of having two events is that the failure event could have a threshold of 0 ms.
>> 
>> We are planning to add a throttling mechanism for exception events, perhaps per call site. The same mechanism could be used for a failed event. If you receive 500 events per second for a call site, there is little value in having additional events.
>
> We need to help Tim on the question of whether there is one or two events. 
> 
> An application that makes outbound network connections may run slowly for several reasons. A duration event may help to diagnose this, irrespective of whether the connection is established successfully or it fails, so one event is okay. Separately, another big source of latency is the name service / DNS lookup which happens before getting to the Socket connect. Maybe further work could add events to InetAddress for this.
> 
> When hunting misbehaving behavior then focusing on the cases where a connection cannot be established may be more interesting. So it's possible someone might want to run with threshold=0 to see all failed events. If there is throttling support, and since we control call site for both the successful and failed cases, could we live with one event?

I'm not sure if one or two events are most suitable. If possible, I would like to discuss it with Markus to get some more input. He will back in January.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1881347326

From dfuchs at openjdk.org  Thu Dec 12 09:51:46 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Dec 2024 09:51:46 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
Message-ID: <tkQNsDYyvNlxFm_7izZHDHa4PxBsUb4YIPqcEwlbJVw=.c6246c91-b32f-4b75-bb17-71c97ddcbde6@github.com>

On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requests fixes
>   
>   - Use IOException.toString() instead of getMessage() in case it's empty
>   - Attempts to test connect exceptions may fail due to unexpected
>     successful connect.  Tests quit with uncompleted status if the
>     connect is successful and are retried a small number of times until
>     the test can be performed properly.  If the retries are exceeded an
>     exception is generated indicating the test can't be setup properly.

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 154:

> 152:                     s.connect(addr);
> 153:                     // unexpected, abandon the test
> 154:                     return false;

The main issue with using the ephemeral port range is that you might manage to connect to a server opened by another test, and that might cause the other test to fail if it's not expecting connections to get closed.

If instead you use ports in the IANA reserved port range - at least you know that you won't connect to other tests running on the same machine.

Have you tried to connect to port 225 for instance, and increase the port number up to 241 in case you still manage to connect?

Ports 225-241 are reserved by IANA - so there should be nobody listening there. I had some trouble on windows 2016 with port 47, but hopefully ports 225-241 will not have the same issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1881736555

From dfuchs at openjdk.org  Thu Dec 12 10:04:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Dec 2024 10:04:41 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
Message-ID: <9Ra2WGQHgeLba87NCCurerM96SaLNYZrCH_cM5ERI0w=.d966c2d0-5314-43de-b01c-bc4f7bf48c30@github.com>

On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requests fixes
>   
>   - Use IOException.toString() instead of getMessage() in case it's empty
>   - Attempts to test connect exceptions may fail due to unexpected
>     successful connect.  Tests quit with uncompleted status if the
>     connect is successful and are retried a small number of times until
>     the test can be performed properly.  If the retries are exceeded an
>     exception is generated indicating the test can't be setup properly.

src/java.base/share/classes/jdk/internal/event/SocketConnectFailedEvent.java line 117:

> 115:         long duration = timestamp() - start;
> 116:         if (shouldCommit(duration)) {
> 117:             String msg = connectEx.toString();

Should the description for this field in the event be updated too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1881757052

From egahlin at openjdk.org  Thu Dec 12 13:37:05 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 12 Dec 2024 13:37:05 GMT
Subject: RFR: 8346099: JFR: Query for 'jfr view' can't handle wildcard with
 multiple event types
Message-ID: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com>

Could I have a review of PR that improves the query language for 'jfr view' so it can handle a wildcard with multiple event types, e.g. "SELECT * FROM E1, E2".

Every field has an index which corresponds to where it is located in resultFields array. Today, the same index can appear multiple times. See FieldBuilder::createWildcardField how this can happen when there are multiple event/filter types. The fix is to set the index after all fields have been added. 

Testing: jdk/jdk/jfr + manual check

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From lmesnik at openjdk.org  Fri Dec 13 00:56:56 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 13 Dec 2024 00:56:56 GMT
Subject: RFR: 8344453: Test jdk/jfr/event/oldobject/TestSanityDefault.java
 timed out
Message-ID: <lzwP7BdWfPaR_OKQA1gz9c33yq9m6YMzL7gLQVj8k5s=.9da7a111-3ee6-4d5d-aa57-27d0c9ddb35c@github.com>

The test Test jdk/jfr/event/oldobject/TestSanityDefault.java timed out with non G1 GC.

It is no regression, just was not executed in this configuration.

It might be not reliably trigger event for non G1 GC/ with VM flags and should not be executed this.

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

Commit messages:
 - 8344453: Test jdk/jfr/event/oldobject/TestSanityDefault.java timed

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

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

From egahlin at openjdk.org  Sat Dec 14 13:35:35 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 14 Dec 2024 13:35:35 GMT
Subject: RFR: 8344453: Test jdk/jfr/event/oldobject/TestSanityDefault.java
 timed out
In-Reply-To: <lzwP7BdWfPaR_OKQA1gz9c33yq9m6YMzL7gLQVj8k5s=.9da7a111-3ee6-4d5d-aa57-27d0c9ddb35c@github.com>
References: <lzwP7BdWfPaR_OKQA1gz9c33yq9m6YMzL7gLQVj8k5s=.9da7a111-3ee6-4d5d-aa57-27d0c9ddb35c@github.com>
Message-ID: <5WRHzMDj9EllnujizF6bofiVwUXkWXbP-MH8bxnH4Jc=.94ef97de-ec4c-4190-ad06-b7882d2c5c0b@github.com>

On Fri, 13 Dec 2024 00:51:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test Test jdk/jfr/event/oldobject/TestSanityDefault.java timed out with non G1 GC.
> 
> It is no regression, just was not executed in this configuration.
> 
> It might be not reliably trigger event for non G1 GC/ with VM flags and should not be executed this.

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22726#pullrequestreview-2503873476

From lmesnik at openjdk.org  Sat Dec 14 19:10:45 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 14 Dec 2024 19:10:45 GMT
Subject: Integrated: 8344453: Test
 jdk/jfr/event/oldobject/TestSanityDefault.java timed out
In-Reply-To: <lzwP7BdWfPaR_OKQA1gz9c33yq9m6YMzL7gLQVj8k5s=.9da7a111-3ee6-4d5d-aa57-27d0c9ddb35c@github.com>
References: <lzwP7BdWfPaR_OKQA1gz9c33yq9m6YMzL7gLQVj8k5s=.9da7a111-3ee6-4d5d-aa57-27d0c9ddb35c@github.com>
Message-ID: <-WLfdOgxo_9xEbZN9jVN0kcuX_BvEI8YpEFgYpXIl9s=.6fc54e49-7ae4-4a07-a89a-da5142041efa@github.com>

On Fri, 13 Dec 2024 00:51:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test Test jdk/jfr/event/oldobject/TestSanityDefault.java timed out with non G1 GC.
> 
> It is no regression, just was not executed in this configuration.
> 
> It might be not reliably trigger event for non G1 GC/ with VM flags and should not be executed this.

This pull request has now been integrated.

Changeset: 6b022bb6
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b022bb64b2109c8cd40ebd3b8b3226cf894544d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8344453: Test jdk/jfr/event/oldobject/TestSanityDefault.java timed out

Reviewed-by: egahlin

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

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

From tprinzing at openjdk.org  Mon Dec 16 20:24:20 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 16 Dec 2024 20:24:20 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v9]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <754sEaQPoyPi9j7x1ltulFSIW1eS0PtzzfMYkFzHeaA=.5a037bc0-3867-4272-be89-3dc01da62ec3@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  Refactored connect exception tests to a single IOHelper method
  that takes a function argument that is excpected to produce the
  appropriate exception.  IANA reserved ports in the range 225 to
  241 are used to attempt to produce a connect exception.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/5e55ffc6..81cea489

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

  Stats: 206 lines in 4 files changed: 54 ins; 114 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From tprinzing at openjdk.org  Mon Dec 16 20:24:20 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 16 Dec 2024 20:24:20 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <tkQNsDYyvNlxFm_7izZHDHa4PxBsUb4YIPqcEwlbJVw=.c6246c91-b32f-4b75-bb17-71c97ddcbde6@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
 <tkQNsDYyvNlxFm_7izZHDHa4PxBsUb4YIPqcEwlbJVw=.c6246c91-b32f-4b75-bb17-71c97ddcbde6@github.com>
Message-ID: <NvNkIKEUiGbSTDZJ_pqoSbMj3CxZBRQPhkwpKW8ozak=.326c8842-5fd1-464a-b544-11798baa2b1b@github.com>

On Thu, 12 Dec 2024 09:48:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   requests fixes
>>   
>>   - Use IOException.toString() instead of getMessage() in case it's empty
>>   - Attempts to test connect exceptions may fail due to unexpected
>>     successful connect.  Tests quit with uncompleted status if the
>>     connect is successful and are retried a small number of times until
>>     the test can be performed properly.  If the retries are exceeded an
>>     exception is generated indicating the test can't be setup properly.
>
> test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 154:
> 
>> 152:                     s.connect(addr);
>> 153:                     // unexpected, abandon the test
>> 154:                     return false;
> 
> The main issue with using the ephemeral port range is that you might manage to connect to a server opened by another test, and that might cause the other test to fail if it's not expecting connections to get closed.
> 
> If instead you use ports in the IANA reserved port range - at least you know that you won't connect to other tests running on the same machine.
> 
> Have you tried to connect to port 225 for instance, and increase the port number up to 241 in case you still manage to connect?
> 
> Ports 225-241 are reserved by IANA - so there should be nobody listening there. I had some trouble on windows 2016 with port 47, but hopefully ports 225-241 will not have the same issue.

I've changed the exception tests to use the port range you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1887538817

From stevenschlansker at gmail.com  Tue Dec 17 19:08:07 2024
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Tue, 17 Dec 2024 11:08:07 -0800
Subject: Socket Read event always reads 5B on jdk 23.0.1+11
Message-ID: <CAHjY6CUwthaBi3Ay_M5+C1yOPMLHd+cvdQ70j1LxJPw0GXE=Jg@mail.gmail.com>

Hi hotspot-jfr-dev,

I am trying to track down a problem with long db queries - Java
reports 10s, but the database server says the query only took 100ms.

In the flight recording, I look up the Socket Read events and indeed
find my suspiciously long read event. However, the event reports that
only 5B are read, which is hard to believe. In fact, *every* socket
read event reports exactly 5B read. This seems impossible - the server
builds a 45MB response body, and all the data comes from the database.

Should I expect that the socket read event reliably reports Bytes
Read? I don't believe this socket stream uses asynchronous IO, which
doesn't seem to be recorded at all (bummer!)
I tried to read the Socket$SocketInputStream Java code but the
instrumentation seems to happen due to much deeper magic.

We run openjdk 23.0.1+11 on rockylinux 9.5

Example event log, subset:
Start Time    Duration    End Time    Event Thread    Remote Address
 Bytes Read    End of Stream    Remote Host    Remote Port    Timeout
Value    Event Type Id
1734454183069711840 epochns    24210111038 ticks
3815799226963477504 epochticks    company-server-56    10.28.224.20
5 B    false    wsdb    5432    0 ms    jdk.SocketRead
1734454183748414110 epochns    20222774822 ticks
3815799224469286400 epochticks    company-server-39    10.28.224.20
5 B    false    wsdb    5432    0 ms    jdk.SocketRead
1734454590578194253 epochns    4759793838 ticks    3815800104031821312
epochticks    company-server-59    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454441187707733 epochns    4751996960 ticks    3815799775364954112
epochticks    company-server-42    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454425227497984 epochns    4120098692 ticks    3815799739620594688
epochticks    company-server-39    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454241790648566 epochns    1079527886 ticks    3815799333018955264
epochticks    company-server-55    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454590289810962 epochns    884150534 ticks    3815800099521735168
epochticks    company-server-47    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454649681226560 epochns    757929740 ticks    3815800230056628736
epochticks    company-server-47    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead


An example stack trace for one of the events:
void jdk.internal.event.SocketReadEvent.emit(long, long, long,
SocketAddress, long)
int java.net.Socket$SocketInputStream.read(byte[], int, int)
int sun.security.ssl.SSLSocketInputRecord.read(InputStream, byte[], int, int)
int sun.security.ssl.SSLSocketInputRecord.readHeader()
int sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket()
ByteBuffer sun.security.ssl.SSLSocketImpl.readApplicationRecord(ByteBuffer)
int sun.security.ssl.SSLSocketImpl$AppInputStream.read(byte[], int, int)
boolean org.postgresql.core.VisibleBufferedInputStream.readMore(int, boolean)
boolean org.postgresql.core.VisibleBufferedInputStream.ensureBytes(int, boolean)
boolean org.postgresql.core.VisibleBufferedInputStream.ensureBytes(int)
int org.postgresql.core.VisibleBufferedInputStream.read()
int org.postgresql.core.PGStream.receiveChar()
void org.postgresql.core.v3.QueryExecutorImpl.processResults(ResultHandler,
int, boolean)
void org.postgresql.core.v3.QueryExecutorImpl.execute(Query,
ParameterList, ResultHandler, int, int, int, boolean)
void org.postgresql.jdbc.PgStatement.executeInternal(CachedQuery,
ParameterList, int)
void org.postgresql.jdbc.PgStatement.execute(CachedQuery, ParameterList, int)
boolean org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(int)
boolean org.postgresql.jdbc.PgPreparedStatement.execute()
boolean com.zaxxer.hikari.pool.ProxyPreparedStatement.execute()
boolean com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute()

Thank you for any insight - happy to provide more information if possible.

From dfuchs at openjdk.org  Wed Dec 18 14:52:39 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 18 Dec 2024 14:52:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v9]
In-Reply-To: <754sEaQPoyPi9j7x1ltulFSIW1eS0PtzzfMYkFzHeaA=.5a037bc0-3867-4272-be89-3dc01da62ec3@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <754sEaQPoyPi9j7x1ltulFSIW1eS0PtzzfMYkFzHeaA=.5a037bc0-3867-4272-be89-3dc01da62ec3@github.com>
Message-ID: <3zb5xfTBTaX0fz635YTOpgpQZk0Iaco5A5m7vZWOoSU=.ac44adff-136f-4198-9692-2577949469a7@github.com>

On Mon, 16 Dec 2024 20:24:20 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactored connect exception tests to a single IOHelper method
>   that takes a function argument that is excpected to produce the
>   appropriate exception.  IANA reserved ports in the range 225 to
>   241 are used to attempt to produce a connect exception.

The test updates LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2551514817

From ihse at openjdk.org  Wed Dec 18 17:06:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 18 Dec 2024 17:06:02 GMT
Subject: RFR: 8344191: Build code should not have classpath exception [v2]
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into remove-build-classpath-exception
 - Update build tools, data and IDE support
 - Update makefiles, autoconf, shell scripts, properties files and configuration files

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

Changes: https://git.openjdk.org/jdk/pull/22104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=01
  Stats: 1994 lines in 555 files changed: 0 ins; 1120 del; 874 mod
  Patch: https://git.openjdk.org/jdk/pull/22104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104

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

From asemenyuk at openjdk.org  Wed Dec 18 18:58:40 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 18 Dec 2024 18:58:40 GMT
Subject: RFR: 8344191: Build code should not have classpath exception [v2]
In-Reply-To: <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
 <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>
Message-ID: <Jzc-zFSvSRq41LPZQUXveoZoJSEMv30oszPC8Qm23mw=.f0743a79-082c-42b7-ac9d-e31515838f5f@github.com>

On Wed, 18 Dec 2024 17:06:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
>> 
>> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
>> 
>> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
>> 
>> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into remove-build-classpath-exception
>  - Update build tools, data and IDE support
>  - Update makefiles, autoconf, shell scripts, properties files and configuration files

jpackage changes look good. $0.02

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22104#pullrequestreview-2512625117

From egahlin at openjdk.org  Thu Dec 19 19:19:38 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 19 Dec 2024 19:19:38 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <xqj9Uffno4vZWpf6VLW9oNc3I4hPEVYBuwq0hRIvSgk=.f25d0ad9-64c5-43e2-8fdc-654ab25b20bc@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
 <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
 <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz
 5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>
 <xqj9Uffno4vZWpf6VLW9oNc3I4hPEVYBuwq0hRIvSgk=.f25d0ad9-64c5-43e2-8fdc-654ab25b20bc@github.com>
Message-ID: <CVS-QWIDcmKgGRfcZKSAo2tsqbmsjAubV_1D4nxkemg=.4c1cebba-2473-4462-b503-a1b98d275c9c@github.com>

On Thu, 12 Dec 2024 03:58:29 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> We need to help Tim on the question of whether there is one or two events. 
>> 
>> An application that makes outbound network connections may run slowly for several reasons. A duration event may help to diagnose this, irrespective of whether the connection is established successfully or it fails, so one event is okay. Separately, another big source of latency is the name service / DNS lookup which happens before getting to the Socket connect. Maybe further work could add events to InetAddress for this.
>> 
>> When hunting misbehaving behavior then focusing on the cases where a connection cannot be established may be more interesting. So it's possible someone might want to run with threshold=0 to see all failed events. If there is throttling support, and since we control call site for both the successful and failed cases, could we live with one event?
>
> I'm not sure if one or two events are most suitable. If possible, I would like to discuss it with Markus to get some more input. He will back in January.

Regarding, one or two events. I'm fine with integrating as-is and then revisit before FC, if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1893019773

From duke at openjdk.org  Sun Dec 29 09:37:48 2024
From: duke at openjdk.org (Eli Schwartz)
Date: Sun, 29 Dec 2024 09:37:48 GMT
Subject: RFR: 8344080: Return type mismatch for jfr_unregister_stack_filter
In-Reply-To: <fZIUnoDG04qQw_i5bsKrB3UJmTAi7ODwxixrwQz4uOg=.59fcfb9d-b8d3-43f3-a928-6c796f88ef92@github.com>
References: <fZIUnoDG04qQw_i5bsKrB3UJmTAi7ODwxixrwQz4uOg=.59fcfb9d-b8d3-43f3-a928-6c796f88ef92@github.com>
Message-ID: <PiYvYTxDaeWvNEDsabUXB-hGE3319t-pQrGz4t9Iez0=.c18f43a7-cce3-4918-987c-a8cd06f27a13@github.com>

On Wed, 13 Nov 2024 12:11:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Tiny adjustment to function declaration.
> 
> Test: jdk_jfr
> 
> Thanks
> Markus

The associated JIRA ticket should probably be cross-linked with https://bugs.openjdk.org/browse/JDK-8340215

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

PR Comment: https://git.openjdk.org/jdk/pull/22068#issuecomment-2564572459

From mgronlun at openjdk.org  Tue Dec 31 13:55:43 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 31 Dec 2024 13:55:43 GMT
Subject: RFR: 8344080: Return type mismatch for jfr_unregister_stack_filter
In-Reply-To: <PiYvYTxDaeWvNEDsabUXB-hGE3319t-pQrGz4t9Iez0=.c18f43a7-cce3-4918-987c-a8cd06f27a13@github.com>
References: <fZIUnoDG04qQw_i5bsKrB3UJmTAi7ODwxixrwQz4uOg=.59fcfb9d-b8d3-43f3-a928-6c796f88ef92@github.com>
 <PiYvYTxDaeWvNEDsabUXB-hGE3319t-pQrGz4t9Iez0=.c18f43a7-cce3-4918-987c-a8cd06f27a13@github.com>
Message-ID: <Fw58XNko-bX-N89q_ahvw_LCLLxWFe3FMOJTZixaPLU=.dd9dc260-f111-436b-9090-3527ef68fdcc@github.com>

On Sun, 29 Dec 2024 00:53:58 GMT, Eli Schwartz <duke at openjdk.org> wrote:

> The associated JIRA ticket should probably be cross-linked with https://bugs.openjdk.org/browse/JDK-8340215

Linked.

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

PR Comment: https://git.openjdk.org/jdk/pull/22068#issuecomment-2566471850