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: References: Message-ID: > 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: References: Message-ID: <_nxGOeqRO_xd0mKBoGEpf1pPvRYUBBG61V5pG3CzGe8=.3ea101a0-f684-4adf-9c8c-63df69954412@github.com> On Fri, 29 Nov 2024 18:53:52 GMT, Nizar Benalla 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: > 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: 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: References: Message-ID: On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@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 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: References: Message-ID: On Fri, 8 Nov 2024 15:19:34 GMT, Nizar Benalla 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 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: References: Message-ID: On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang 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> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com> Message-ID: On Mon, 25 Nov 2024 13:23:23 GMT, Erik Gahlin 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: > 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Tue, 3 Dec 2024 00:40:24 GMT, Tim Prinzing 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: true > 745: true > 746: 20 ms 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> <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 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Tue, 3 Dec 2024 15:40:02 GMT, Tim Prinzing 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: References: Message-ID: On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang 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: References: Message-ID: On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Tue, 3 Dec 2024 15:12:10 GMT, Daniel Fuchs 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: true >> 745: true >> 746: 20 ms > > 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com> Message-ID: On Tue, 3 Dec 2024 12:34:20 GMT, Alan Bateman 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: References: Message-ID: On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com> Message-ID: On Tue, 3 Dec 2024 23:42:34 GMT, Erik Gahlin 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: 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: References: Message-ID: On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang 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: 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: References: Message-ID: On Mon, 2 Dec 2024 21:02:20 GMT, Erik Gahlin 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 ` 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: References: Message-ID: On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik 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: References: Message-ID: On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang 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: References: Message-ID: On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang 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: References: Message-ID: On Wed, 4 Dec 2024 14:23:07 GMT, Chen Liang 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 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: 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: References: Message-ID: <_olCpUYV10NbNUGJ8mK987-znsCpIxNOUlV1fqWM5c8=.fc33500a-3342-4608-b873-b2416ae18678@github.com> On Wed, 4 Dec 2024 15:27:23 GMT, Erik Gahlin 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: References: Message-ID: > 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: References: Message-ID: On Thu, 5 Dec 2024 13:09:52 GMT, Erik Gahlin 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: References: Message-ID: On Thu, 5 Dec 2024 13:09:52 GMT, Erik Gahlin 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: References: Message-ID: On Wed, 4 Dec 2024 15:27:23 GMT, Erik Gahlin 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 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: References: Message-ID: On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik 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 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: > 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: 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: 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com> Message-ID: On Wed, 4 Dec 2024 12:26:20 GMT, Alan Bateman 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: <9Ra2WGQHgeLba87NCCurerM96SaLNYZrCH_cM5ERI0w=.d966c2d0-5314-43de-b01c-bc4f7bf48c30@github.com> On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing 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: 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: References: Message-ID: <5WRHzMDj9EllnujizF6bofiVwUXkWXbP-MH8bxnH4Jc=.94ef97de-ec4c-4190-ad06-b7882d2c5c0b@github.com> On Fri, 13 Dec 2024 00:51:35 GMT, Leonid Mesnik 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: References: Message-ID: <-WLfdOgxo_9xEbZN9jVN0kcuX_BvEI8YpEFgYpXIl9s=.6fc54e49-7ae4-4a07-a89a-da5142041efa@github.com> On Fri, 13 Dec 2024 00:51:35 GMT, Leonid Mesnik 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 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Thu, 12 Dec 2024 09:48:45 GMT, Daniel Fuchs 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: 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 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: References: Message-ID: > 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: References: Message-ID: On Wed, 18 Dec 2024 17:06:02 GMT, Magnus Ihse Bursie 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: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com> Message-ID: On Thu, 12 Dec 2024 03:58:29 GMT, Erik Gahlin 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: References: Message-ID: On Wed, 13 Nov 2024 12:11:18 GMT, Markus Gr?nlund 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: References: Message-ID: On Sun, 29 Dec 2024 00:53:58 GMT, Eli Schwartz 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