From liach at openjdk.org Fri Jan 3 16:35:39 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Jan 2025 16:35:39 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona wrote: > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam Looks good; waiting for a JFR reviewer. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2529380039 From alanb at openjdk.org Fri Jan 3 17:18:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Jan 2025 17:18:34 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages In-Reply-To: References: Message-ID: <0dGBK1WiJqZwu6ornKPZRv6GG4ZN_Qi_9ueqw0OBICM=.08113b29-4905-43f7-991e-d8b2378f11cf@github.com> On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona wrote: > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam Good cleanup, these qualified exports should probably have been removed in JDK 22 when the instrumentation moved to the class file API. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2529437512 From asotona at openjdk.org Mon Jan 6 08:45:48 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 08:45:48 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: References: Message-ID: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22912/files - new: https://git.openjdk.org/jdk/pull/22912/files/06ec27bf..f8fe6546 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22912&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22912&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22912/head:pull/22912 PR: https://git.openjdk.org/jdk/pull/22912 From alanb at openjdk.org Mon Jan 6 08:48:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Jan 2025 08:48:38 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> References: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> Message-ID: On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona wrote: >> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2531645108 From qxing at openjdk.org Mon Jan 6 09:50:43 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Mon, 6 Jan 2025 09:50:43 GMT Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp` Message-ID: The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far. This patch removes the extra parenthesis. ------------- Commit messages: - Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp`. Changes: https://git.openjdk.org/jdk/pull/22925/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22925&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347042 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22925/head:pull/22925 PR: https://git.openjdk.org/jdk/pull/22925 From liach at openjdk.org Mon Jan 6 14:10:46 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 14:10:46 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> References: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> Message-ID: On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona wrote: >> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2532210782 From asotona at openjdk.org Mon Jan 6 14:10:47 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:10:47 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> References: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> Message-ID: On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona wrote: >> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22912#issuecomment-2573185292 From asotona at openjdk.org Mon Jan 6 14:10:47 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:10:47 GMT Subject: Integrated: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona wrote: > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: e0695e0e Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/e0695e0ef0dd1bfacbaac32edda055ba852a2421 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages Reviewed-by: liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22912 From mgronlun at openjdk.org Tue Jan 7 11:10:35 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 7 Jan 2025 11:10:35 GMT Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp` In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing wrote: > The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far. > > This patch removes the extra parenthesis. Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22925#pullrequestreview-2534047872 From mgronlun at openjdk.org Tue Jan 7 16:23:35 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 7 Jan 2025 16:23:35 GMT Subject: RFR: 8346099: JFR: Query for 'jfr view' can't handle wildcard with multiple event types In-Reply-To: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com> References: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com> Message-ID: On Thu, 12 Dec 2024 13:24:51 GMT, Erik Gahlin wrote: > 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 Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22711#pullrequestreview-2534838623 From mgronlun at openjdk.org Tue Jan 7 16:23:40 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 7 Jan 2025 16:23:40 GMT Subject: RFR: 8345337: JFR: jfr view should display all direct subfields for an event type In-Reply-To: References: Message-ID: <69ySkh1CPfHZRzC63yjaUhrj_qfckd4lprJF4Hvpc8o=.a7cd6e22-155b-46ae-babd-86ed1a04c8ac@github.com> 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 Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22498#pullrequestreview-2534836008 From mgronlun at openjdk.org Tue Jan 7 16:24:56 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 7 Jan 2025 16:24:56 GMT Subject: RFR: 8346047: JFR: Incorrect percentile value in 'jfr view' In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 03:41:26 GMT, Erik Gahlin wrote: > 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 a fourth index variable. > > Testing: jdk/jdk/rf > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22700#pullrequestreview-2534843231 From mgronlun at openjdk.org Tue Jan 7 16:24:48 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 7 Jan 2025 16:24:48 GMT Subject: RFR: 8346052: JFR: Incorrect average value in 'jfr view' In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 03:38:25 GMT, Erik Gahlin wrote: > 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 Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22699#pullrequestreview-2534841197 From egahlin at openjdk.org Wed Jan 8 12:47:50 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Jan 2025 12:47:50 GMT Subject: Integrated: 8345337: JFR: jfr view should display all direct subfields for an event type In-Reply-To: References: Message-ID: <0bWjuStOo74SM0DDdsx6U_k33WZJAGllD0QoM8Wu7N0=.04be0621-7be3-4b0c-a830-e8d3f0f883d3@github.com> 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 This pull request has now been integrated. Changeset: 672c413c Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/672c413c61d9b155020a0fd4bd1c2bc0661a60fb Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8345337: JFR: jfr view should display all direct subfields for an event type Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/22498 From egahlin at openjdk.org Wed Jan 8 14:42:40 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Jan 2025 14:42:40 GMT Subject: Integrated: 8346052: JFR: Incorrect average value in 'jfr view' In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 03:38:25 GMT, Erik Gahlin wrote: > 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 This pull request has now been integrated. Changeset: 92ad8a1d Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/92ad8a1d96c749d1f9c15e5b96244cd72a6e71be Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8346052: JFR: Incorrect average value in 'jfr view' Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/22699 From alanb at openjdk.org Wed Jan 8 14:45:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 14:45:38 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime In-Reply-To: References: Message-ID: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com> On Wed, 8 Jan 2025 14:24:25 GMT, Severin Gehwolf wrote: > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [ ] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? test/jdk/tools/launcher/SourceMode.java line 29: > 27: * @summary Test source mode > 28: * @modules jdk.compiler jdk.jlink > 29: * @run main/othervm SourceMode This looks fine, might need to add `@comment` to something brief to say why the test are othervm. Also I assume you'll bump the copyright header on the tests before ingtegrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22969#discussion_r1907293028 From sgehwolf at openjdk.org Wed Jan 8 14:56:55 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 14:56:55 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: References: Message-ID: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [ ] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Copyright and @comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22969/files - new: https://git.openjdk.org/jdk/pull/22969/files/afc33798..6eceb0de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=00-01 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22969/head:pull/22969 PR: https://git.openjdk.org/jdk/pull/22969 From sgehwolf at openjdk.org Wed Jan 8 14:56:56 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 14:56:56 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com> References: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com> Message-ID: On Wed, 8 Jan 2025 14:42:45 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright and @comment > > test/jdk/tools/launcher/SourceMode.java line 29: > >> 27: * @summary Test source mode >> 28: * @modules jdk.compiler jdk.jlink >> 29: * @run main/othervm SourceMode > > This looks fine, might need to add `@comment` to something brief to say why the test are othervm. Also I assume you'll bump the copyright header on the tests before ingtegrating. Thanks. `@comment` added and copyright header updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22969#discussion_r1907309808 From alanb at openjdk.org Wed Jan 8 15:17:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 15:17:47 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [ ] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and @comment Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2537439865 From egahlin at openjdk.org Wed Jan 8 15:55:55 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Jan 2025 15:55:55 GMT Subject: Integrated: 8346047: JFR: Incorrect percentile value in 'jfr view' In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 03:41:26 GMT, Erik Gahlin wrote: > 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 a fourth index variable. > > Testing: jdk/jdk/rf > > Thanks > Erik This pull request has now been integrated. Changeset: 55bcf4c0 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/55bcf4c054c95af2a073818cd8c392de02b3ee01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8346047: JFR: Incorrect percentile value in 'jfr view' Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/22700 From egahlin at openjdk.org Wed Jan 8 16:07:32 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Jan 2025 16:07:32 GMT Subject: Integrated: 8346099: JFR: Query for 'jfr view' can't handle wildcard with multiple event types In-Reply-To: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com> References: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com> Message-ID: On Thu, 12 Dec 2024 13:24:51 GMT, Erik Gahlin wrote: > 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 This pull request has now been integrated. Changeset: 3fe08186 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/3fe08186b1d6dbc17d4f14d8288ce3c7c6651004 Stats: 10 lines in 2 files changed: 8 ins; 2 del; 0 mod 8346099: JFR: Query for 'jfr view' can't handle wildcard with multiple event types Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/22711 From fyang at openjdk.org Thu Jan 9 00:50:41 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 9 Jan 2025 00:50:41 GMT Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp` In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing wrote: > The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far. > > This patch removes the extra parenthesis. LGTM. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22925#pullrequestreview-2538566352 From qxing at openjdk.org Thu Jan 9 01:06:54 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Thu, 9 Jan 2025 01:06:54 GMT Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp` In-Reply-To: References: Message-ID: <0P1Ci3tn2o85Ca_giEJbHBg9rQjhtVv05dGFqNEPsIg=.0e3fae0a-39d2-4e8e-a22e-b0c4d0d3a3c0@github.com> On Tue, 7 Jan 2025 11:08:16 GMT, Markus Gr?nlund wrote: >> The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far. >> >> This patch removes the extra parenthesis. > > Looks good. @mgronlun @RealFYang Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22925#issuecomment-2578987696 From duke at openjdk.org Thu Jan 9 01:06:54 2025 From: duke at openjdk.org (duke) Date: Thu, 9 Jan 2025 01:06:54 GMT Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp` In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing wrote: > The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far. > > This patch removes the extra parenthesis. @MaxXSoft Your change (at version f25196d706e00e09e734dd560ad0fc0920e6e373) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22925#issuecomment-2578988037 From qxing at openjdk.org Thu Jan 9 02:27:41 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Thu, 9 Jan 2025 02:27:41 GMT Subject: Integrated: 8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp` In-Reply-To: References: Message-ID: <_5YVueTh9_6CLv5VEtQUJzrm1GdLFj3CJIMArr49O9g=.7a7b9a6c-531c-4935-afd2-3296c89d1ad7@github.com> On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing wrote: > The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far. > > This patch removes the extra parenthesis. This pull request has now been integrated. Changeset: 1ade96b8 Author: Qizheng Xing Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/1ade96b808e66cf1623c38e23772eaf9fc991db9 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp` Reviewed-by: mgronlun, fyang ------------- PR: https://git.openjdk.org/jdk/pull/22925 From dholmes at openjdk.org Thu Jan 9 03:41:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 03:41:36 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [ ] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and @comment Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise? ------------- PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2538683215 From alanb at openjdk.org Thu Jan 9 08:29:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 08:29:36 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Thu, 9 Jan 2025 03:38:48 GMT, David Holmes wrote: > Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise? jtreg patches java.base to add JTRegModuleHelper so not compatible that uses that using jlink "in-process" (with ToolProvider). Maybe the `@comment` could be expanded a bit to say this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2579429178 From sgehwolf at openjdk.org Thu Jan 9 10:18:35 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 10:18:35 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [x] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Expand comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22969/files - new: https://git.openjdk.org/jdk/pull/22969/files/6eceb0de..77dc9376 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=01-02 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22969/head:pull/22969 PR: https://git.openjdk.org/jdk/pull/22969 From sgehwolf at openjdk.org Thu Jan 9 10:18:37 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 10:18:37 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and @comment I've updated the `@comment` to explain this better. Is it clearer now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2579692209 From shade at openjdk.org Thu Jan 9 10:20:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 9 Jan 2025 10:20:38 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Expand comment Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2539455608 From egahlin at openjdk.org Thu Jan 9 13:18:00 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 9 Jan 2025 13:18:00 GMT Subject: RFR: 8347287: JFR: Remove use of Security Manager Message-ID: Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. Testing: tier1 + test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Update copyright - Update specification in seperate issue - Remove mistakenly added directory - Fix copyright year - Remove whitespace - Remove whitespace - Update copyright to 2025 - Initial Changes: https://git.openjdk.org/jdk/pull/22787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22787&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347287 Stats: 1986 lines in 86 files changed: 197 ins; 1380 del; 409 mod Patch: https://git.openjdk.org/jdk/pull/22787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22787/head:pull/22787 PR: https://git.openjdk.org/jdk/pull/22787 From mgronlun at openjdk.org Thu Jan 9 13:18:00 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 9 Jan 2025 13:18:00 GMT Subject: RFR: 8347287: JFR: Remove use of Security Manager In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 09:25:17 GMT, Erik Gahlin wrote: > Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. > > Testing: tier1 + test/jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22787#pullrequestreview-2539866422 From sgehwolf at openjdk.org Thu Jan 9 13:54:40 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 13:54:40 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Thu, 9 Jan 2025 03:38:48 GMT, David Holmes wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright and @comment > > Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise? @dholmes-ora Is the latest patch any better? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2580239188 From egahlin at openjdk.org Thu Jan 9 15:02:47 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 9 Jan 2025 15:02:47 GMT Subject: [jdk24] RFR: 8345337: JFR: jfr view should display all direct subfields for an event type Message-ID: 8345337: JFR: jfr view should display all direct subfields for an event type ------------- Commit messages: - Backport 672c413c61d9b155020a0fd4bd1c2bc0661a60fb Changes: https://git.openjdk.org/jdk/pull/23009/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23009&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/23009.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23009/head:pull/23009 PR: https://git.openjdk.org/jdk/pull/23009 From mgronlun at openjdk.org Thu Jan 9 15:02:47 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 9 Jan 2025 15:02:47 GMT Subject: [jdk24] RFR: 8345337: JFR: jfr view should display all direct subfields for an event type In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 14:52:47 GMT, Erik Gahlin wrote: > 8345337: JFR: jfr view should display all direct subfields for an event type Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23009#pullrequestreview-2540156159 From erik.gahlin at oracle.com Thu Jan 9 18:23:25 2025 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 9 Jan 2025 18:23:25 +0000 Subject: Socket Read event always reads 5B on jdk 23.0.1+11 In-Reply-To: References: Message-ID: Hi Steven, There were changes to the Socket Read event in JDK 22 and JDK 23. I have looked at the implementation again, but it seems fine. Can you reproduce on JDK 21? Only events that take more than 20 ms are written, which might explain why some events are missing? You can enable all Socket Read events with the following command: $ java -XX:StartFlightRecording:jdk.SocketRead#threshold=0ms,filename=rec.jfr ... This might provide you with greater insight. Without a standalone reproducer, it's hard to say much more. Our tests of the Socket Read event work, but they do not test the duration because it's hard to do in a quick and reliable way. https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/jfr/event/io Thanks Erik ________________________________ From: hotspot-jfr-dev on behalf of Steven Schlansker Sent: Tuesday, December 17, 2024 8:08 PM To: hotspot-jfr-dev at openjdk.org Subject: Socket Read event always reads 5B on jdk 23.0.1+11 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at openjdk.org Fri Jan 10 10:09:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 10:09:51 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Expand comment This is a test-only fix and fairly trivial. I'll integrate now. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2582265348 From sgehwolf at openjdk.org Fri Jan 10 10:09:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 10:09:51 GMT Subject: Integrated: 8347124: Clean tests with --enable-linkable-runtime In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 14:24:25 GMT, Severin Gehwolf wrote: > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [x] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? This pull request has now been integrated. Changeset: 1f457977 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/1f457977f062e4ed219c6fa0fe26cb42acaf4bf2 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod 8347124: Clean tests with --enable-linkable-runtime Reviewed-by: shade, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22969 From aturbanov at openjdk.org Fri Jan 10 10:44:39 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 10 Jan 2025 10:44:39 GMT Subject: RFR: 8347287: JFR: Remove use of Security Manager In-Reply-To: References: Message-ID: <8KnWIHZTp36bAPwl9jX31tvkhK6_7D2o0XAku5Zj23w=.76c01f87-bf17-4374-9a2c-58c0f29a90e2@github.com> On Tue, 17 Dec 2024 09:25:17 GMT, Erik Gahlin wrote: > Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. > > Testing: tier1 + test/jdk/jdk/jfr > > Thanks > Erik src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java line 114: > 112: + MAXIMUM_FILE_SIZE + " characters can't be read."); > 113: } > 114: try (InputStream r = Files.newInputStream(knownPath);) { Suggestion: try (InputStream r = Files.newInputStream(knownPath)) { src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java line 198: > 196: Path file = path.resolveSibling(name + extension); > 197: if (Files.exists(file) && !Files.isDirectory(file)) { > 198: try (Reader r = Files.newBufferedReader(file);) { Suggestion: try (Reader r = Files.newBufferedReader(file)) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22787#discussion_r1910190020 PR Review Comment: https://git.openjdk.org/jdk/pull/22787#discussion_r1910190392 From egahlin at openjdk.org Fri Jan 10 13:46:52 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 10 Jan 2025 13:46:52 GMT Subject: RFR: 8347287: JFR: Remove use of Security Manager [v2] In-Reply-To: References: Message-ID: > Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. > > Testing: tier1 + test/jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22787/files - new: https://git.openjdk.org/jdk/pull/22787/files/d3cae681..edcbb62f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22787&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22787&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22787/head:pull/22787 PR: https://git.openjdk.org/jdk/pull/22787 From mgronlun at openjdk.org Fri Jan 10 13:46:52 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 10 Jan 2025 13:46:52 GMT Subject: RFR: 8347287: JFR: Remove use of Security Manager [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:43:10 GMT, Erik Gahlin wrote: >> Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. >> >> Testing: tier1 + test/jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Nit Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22787#pullrequestreview-2542469818 From egahlin at openjdk.org Fri Jan 10 13:49:49 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 10 Jan 2025 13:49:49 GMT Subject: Integrated: 8347287: JFR: Remove use of Security Manager In-Reply-To: References: Message-ID: <2ca-VF4ZRxnyHz-uiIuvsFdnOSjOggowahHxuaxfO3A=.87091826-fcc2-40d2-ac83-516fbaa78586@github.com> On Tue, 17 Dec 2024 09:25:17 GMT, Erik Gahlin wrote: > Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. > > Testing: tier1 + test/jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: ec7393e9 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/ec7393e9190c1b93ca08e1107f734c869f400b89 Stats: 1986 lines in 86 files changed: 197 ins; 1380 del; 409 mod 8347287: JFR: Remove use of Security Manager Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/22787 From egahlin at openjdk.org Fri Jan 10 13:54:45 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 10 Jan 2025 13:54:45 GMT Subject: [jdk24] Integrated: 8345337: JFR: jfr view should display all direct subfields for an event type In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 14:52:47 GMT, Erik Gahlin wrote: > 8345337: JFR: jfr view should display all direct subfields for an event type This pull request has now been integrated. Changeset: c61fbfd6 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/c61fbfd6ea0e2b91a0321b6b6cd382f710d0deef Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8345337: JFR: jfr view should display all direct subfields for an event type Reviewed-by: mgronlun Backport-of: 672c413c61d9b155020a0fd4bd1c2bc0661a60fb ------------- PR: https://git.openjdk.org/jdk/pull/23009 From egahlin at openjdk.org Fri Jan 10 14:00:23 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 10 Jan 2025 14:00:23 GMT Subject: RFR: 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification Message-ID: Could I have a review that updates the specification for FlightRecorder::addListener to reflect that the Security Manager is now disabled. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/23006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343510 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23006/head:pull/23006 PR: https://git.openjdk.org/jdk/pull/23006 From mgronlun at openjdk.org Fri Jan 10 14:00:23 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 10 Jan 2025 14:00:23 GMT Subject: RFR: 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 13:45:13 GMT, Erik Gahlin wrote: > Could I have a review that updates the specification for FlightRecorder::addListener to reflect that the Security Manager is now disabled. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23006#pullrequestreview-2542496694 From egahlin at openjdk.org Fri Jan 10 16:01:55 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 10 Jan 2025 16:01:55 GMT Subject: Integrated: 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 13:45:13 GMT, Erik Gahlin wrote: > Could I have a review that updates the specification for FlightRecorder::addListener to reflect that the Security Manager is now disabled. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 1bf2f5c8 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/1bf2f5c8a92b30eabb530737158f57c63a81fef6 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/23006 From egahlin at openjdk.org Fri Jan 10 16:35:10 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 10 Jan 2025 16:35:10 GMT Subject: [jdk24] RFR: 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification Message-ID: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com> 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification ------------- Commit messages: - Backport 1bf2f5c8a92b30eabb530737158f57c63a81fef6 Changes: https://git.openjdk.org/jdk/pull/23041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343510 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23041/head:pull/23041 PR: https://git.openjdk.org/jdk/pull/23041 From mgronlun at openjdk.org Fri Jan 10 16:35:10 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 10 Jan 2025 16:35:10 GMT Subject: [jdk24] RFR: 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification In-Reply-To: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com> References: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com> Message-ID: On Fri, 10 Jan 2025 16:16:09 GMT, Erik Gahlin wrote: > 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23041#pullrequestreview-2542909847 From dholmes at openjdk.org Mon Jan 13 06:04:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Jan 2025 06:04:42 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: <90L-N_yB8R9WfOVhMC7FM0StbeiRMz9DMa93apWR7R0=.33263ced-4a96-42a7-a89f-0a4ecdd7daa9@github.com> On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Expand comment Sorry for the tardy response - the updated comment looks good. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2586229113 From sgehwolf at openjdk.org Mon Jan 13 15:44:55 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 13 Jan 2025 15:44:55 GMT Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac Message-ID: Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped. I've done that by adding those two required modules in the `@modules` tag. Testing: - [ ] GHA - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes. Thoughts? ------------- Commit messages: - 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac Changes: https://git.openjdk.org/jdk/pull/23079/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23079&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347496 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23079.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23079/head:pull/23079 PR: https://git.openjdk.org/jdk/pull/23079 From egahlin at openjdk.org Mon Jan 13 20:57:40 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 13 Jan 2025 20:57:40 GMT Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac In-Reply-To: References: Message-ID: <7wNRc26-WfbpQoUi_hMa9NXdnN51s8LTvfWOqN6OiSs=.3091bbf5-130e-4ee7-b9dd-3eb181d4fff0@github.com> On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf wrote: > Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped. > > I've done that by adding those two required modules in the `@modules` tag. > > Testing: > - [ ] GHA > - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes. > > Thoughts? Marked as reviewed by egahlin (Reviewer). > > Thoughts? > Seems reasonable, as long as the created images don't have other modules it should be fines. ------------- PR Review: https://git.openjdk.org/jdk/pull/23079#pullrequestreview-2547868599 PR Comment: https://git.openjdk.org/jdk/pull/23079#issuecomment-2588178645 From dholmes at openjdk.org Tue Jan 14 02:54:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Jan 2025 02:54:37 GMT Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf wrote: > Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped. > > I've done that by adding those two required modules in the `@modules` tag. > > Testing: > - [ ] GHA > - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes. > > Thoughts? Looks good. Thanks for fixing! I agree this was likely always a problem but never observed when run in an agentVM. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23079#pullrequestreview-2548624479 From sgehwolf at openjdk.org Tue Jan 14 09:20:46 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 14 Jan 2025 09:20:46 GMT Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf wrote: > Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped. > > I've done that by adding those two required modules in the `@modules` tag. > > Testing: > - [x] GHA > - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes. > > Thoughts? Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23079#issuecomment-2589399240 From sgehwolf at openjdk.org Tue Jan 14 09:20:46 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 14 Jan 2025 09:20:46 GMT Subject: Integrated: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf wrote: > Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped. > > I've done that by adding those two required modules in the `@modules` tag. > > Testing: > - [x] GHA > - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes. > > Thoughts? This pull request has now been integrated. Changeset: 39676963 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/3967696386ecc706927f05dfae0841b3f23e319d Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac Reviewed-by: egahlin, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23079 From mgronlun at openjdk.org Tue Jan 14 14:40:11 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 14 Jan 2025 14:40:11 GMT Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently Message-ID: Greetings, This is a hypothetical fix for JDK-8345493, because the issue seems impossible to reproduce, even with instrumentation and extra debug information. Debugging .mdmp state indicates that a message request thread is not woken up from waiting on a condition variable, even as the sent-in message has been processed. Both the message request thread and the consumer wait on the condition variable instead. This means the message request thread does not wake up to check that its message has been processed. There is a bit of designed asymmetry in that only a single message thread should be waiting for a message to be processed. The consumer, therefore, signals it using notify(). Let's say we have a broken invariant somewhere (not yet found) that allows two threads to post messages?notify() will only wake up a single thread from the associated condition variable. A safer, intermediate "fix" is to let the consumer issue a notify_all() to wake all potential waiters. We will continue to investigate the underlying cause but suggest this as an intermediate fix. Testing: jdk_jfr, stress testing. Thanks Markus ------------- Commit messages: - 8345493 Changes: https://git.openjdk.org/jdk/pull/23105/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23105&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345493 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23105.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23105/head:pull/23105 PR: https://git.openjdk.org/jdk/pull/23105 From egahlin at openjdk.org Tue Jan 14 16:12:56 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 14 Jan 2025 16:12:56 GMT Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently In-Reply-To: References: Message-ID: <1CCra7fGm0aLlpIS1-0S4V2nWMlnzrL3xH0X1OOdG20=.29ebee20-d72e-4d80-975f-6a498130a715@github.com> On Tue, 14 Jan 2025 14:35:07 GMT, Markus Gr?nlund wrote: > Greetings, > > This is a hypothetical fix for JDK-8345493, because the issue seems impossible to reproduce, even with instrumentation and extra debug information. > > Debugging .mdmp state indicates that a message request thread is not woken up from waiting on a condition variable, even as the sent-in message has been processed. Both the message request thread and the consumer wait on the condition variable instead. This means the message request thread does not wake up to check that its message has been processed. > > There is a bit of designed asymmetry in that only a single message thread should be waiting for a message to be processed. The consumer, therefore, signals it using notify(). > > Let's say we have a broken invariant somewhere (not yet found) that allows two threads to post messages?notify() will only wake up a single thread from the associated condition variable. > > A safer, intermediate "fix" is to let the consumer issue a notify_all() to wake all potential waiters. > > We will continue to investigate the underlying cause but suggest this as an intermediate fix. > > Testing: jdk_jfr, stress testing. > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23105#pullrequestreview-2550239729 From coleenp at openjdk.org Tue Jan 14 16:40:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Jan 2025 16:40:50 GMT Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory Message-ID: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory. Most were done with a script with no hand-editing. Tested just now with tier1-4 on x86 and aarch64. ------------- Commit messages: - Round 1 with the script. Changes: https://git.openjdk.org/jdk/pull/23109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347724 Stats: 28 lines in 9 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/23109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23109/head:pull/23109 PR: https://git.openjdk.org/jdk/pull/23109 From egahlin at openjdk.org Tue Jan 14 16:51:37 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 14 Jan 2025 16:51:37 GMT Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> Message-ID: On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore wrote: > Please review this change to replace SIZE_FORMAT with %zu in the jfr directory. Most were done with a script with no hand-editing. > > Tested just now with tier1-4 on x86 and aarch64. Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23109#pullrequestreview-2550409017 From coleenp at openjdk.org Tue Jan 14 16:56:41 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Jan 2025 16:56:41 GMT Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> Message-ID: On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore wrote: > Please review this change to replace SIZE_FORMAT with %zu in the jfr directory. Most were done with a script with no hand-editing. > > Tested just now with tier1-4 on x86 and aarch64. Thanks Erik. Trivial? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590543402 From egahlin at openjdk.org Tue Jan 14 16:56:41 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 14 Jan 2025 16:56:41 GMT Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory In-Reply-To: References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> Message-ID: On Tue, 14 Jan 2025 16:51:51 GMT, Coleen Phillimore wrote: > Thanks Erik. Trivial? Yes! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590556159 From coleenp at openjdk.org Tue Jan 14 17:03:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Jan 2025 17:03:46 GMT Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> Message-ID: On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore wrote: > Please review this change to replace SIZE_FORMAT with %zu in the jfr directory. Most were done with a script with no hand-editing. > > Tested just now with tier1-4 on x86 and aarch64. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590573131 From coleenp at openjdk.org Tue Jan 14 17:03:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Jan 2025 17:03:46 GMT Subject: Integrated: 8347724: Replace SIZE_FORMAT in jfr directory In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com> Message-ID: On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore wrote: > Please review this change to replace SIZE_FORMAT with %zu in the jfr directory. Most were done with a script with no hand-editing. > > Tested just now with tier1-4 on x86 and aarch64. This pull request has now been integrated. Changeset: a01e92cd Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/a01e92cdef1b7fb02035f9246a7c9fccfcf46057 Stats: 28 lines in 9 files changed: 0 ins; 0 del; 28 mod 8347724: Replace SIZE_FORMAT in jfr directory Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/23109 From egahlin at openjdk.org Tue Jan 14 22:34:45 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 14 Jan 2025 22:34:45 GMT Subject: [jdk24] Integrated: 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification In-Reply-To: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com> References: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com> Message-ID: On Fri, 10 Jan 2025 16:16:09 GMT, Erik Gahlin wrote: > 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification This pull request has now been integrated. Changeset: 1399f253 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/1399f253b03c0deef862eb1ef3ffb16eb0a56717 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification Reviewed-by: mgronlun Backport-of: 1bf2f5c8a92b30eabb530737158f57c63a81fef6 ------------- PR: https://git.openjdk.org/jdk/pull/23041 From mgronlun at openjdk.org Wed Jan 15 13:04:59 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 15 Jan 2025 13:04:59 GMT Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently [v2] In-Reply-To: References: Message-ID: > Greetings, > > This is the fix for JDK-8345493. > > Problem Summary: > 1. Threads calling JVM.begin_recording() and JVM.end_recording() only hold the PlatformRecorder lock (not the MetadataRepository lock) > 2. The periodic flush thread only holds the MetadataRepository lock, not the PlatformRecorder lock. > > Problem solution: > The periodic flush thread must acquire both the PlatformRecorder lock and the MetadataRepository lock (in that order). > > Testing: jdk_jfr, stress testing. > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: - revert notify_all() - FlushTask to acquire PlatformRecorder and MetadataRepository locks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23105/files - new: https://git.openjdk.org/jdk/pull/23105/files/742f391c..5c8e9f10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23105&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23105&range=00-01 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23105.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23105/head:pull/23105 PR: https://git.openjdk.org/jdk/pull/23105 From mbaesken at openjdk.org Wed Jan 15 14:09:09 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 14:09:09 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS Message-ID: The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : java.lang.AssertionError: Expected at least one event at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1447) The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. ------------- Commit messages: - JDK-8346875 Changes: https://git.openjdk.org/jdk/pull/23136/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23136&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346875 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23136.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23136/head:pull/23136 PR: https://git.openjdk.org/jdk/pull/23136 From egahlin at openjdk.org Wed Jan 15 14:43:38 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 15 Jan 2025 14:43:38 GMT Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently [v2] In-Reply-To: References: Message-ID: <0NUmybYTykAs_a6FJ3t41taSnIVd3ZQ9LiYhsqf88Q4=.0af32073-c978-4d0f-9451-11a299f52afc@github.com> On Wed, 15 Jan 2025 13:04:59 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This is the fix for JDK-8345493. >> >> Problem Summary: >> 1. Threads calling JVM.begin_recording() and JVM.end_recording() only hold the PlatformRecorder lock (not the MetadataRepository lock) >> 2. The periodic flush thread only holds the MetadataRepository lock, not the PlatformRecorder lock. >> >> Problem solution: >> The periodic flush thread must acquire both the PlatformRecorder lock and the MetadataRepository lock (in that order). >> >> Testing: jdk_jfr, stress testing. >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - revert notify_all() > - FlushTask to acquire PlatformRecorder and MetadataRepository locks Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23105#pullrequestreview-2552956424 From mgronlun at openjdk.org Wed Jan 15 16:21:43 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 15 Jan 2025 16:21:43 GMT Subject: Integrated: 8345493: JFR: JVM.flush hangs intermittently In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 14:35:07 GMT, Markus Gr?nlund wrote: > Greetings, > > This is the fix for JDK-8345493. > > Problem Summary: > 1. Threads calling JVM.begin_recording() and JVM.end_recording() only hold the PlatformRecorder lock (not the MetadataRepository lock) > 2. The periodic flush thread only holds the MetadataRepository lock, not the PlatformRecorder lock. > > Problem solution: > The periodic flush thread must acquire both the PlatformRecorder lock and the MetadataRepository lock (in that order). > > Testing: jdk_jfr, stress testing. > > Thanks > Markus This pull request has now been integrated. Changeset: 4257215a Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/4257215a9fa02f74ccd4fc62893d4b1a232a8754 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod 8345493: JFR: JVM.flush hangs intermittently Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/23105 From mgronlun at openjdk.org Wed Jan 15 16:26:47 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 15 Jan 2025 16:26:47 GMT Subject: [jdk24] RFR: 8345493: JFR: JVM.flush hangs intermittently Message-ID: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com> 8345493: JFR: JVM.flush hangs intermittently ------------- Commit messages: - Backport 4257215a9fa02f74ccd4fc62893d4b1a232a8754 Changes: https://git.openjdk.org/jdk/pull/23141/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345493 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23141/head:pull/23141 PR: https://git.openjdk.org/jdk/pull/23141 From egahlin at openjdk.org Wed Jan 15 16:33:42 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 15 Jan 2025 16:33:42 GMT Subject: [jdk24] RFR: 8345493: JFR: JVM.flush hangs intermittently In-Reply-To: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com> References: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com> Message-ID: On Wed, 15 Jan 2025 16:19:30 GMT, Markus Gr?nlund wrote: > 8345493: JFR: JVM.flush hangs intermittently Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23141#pullrequestreview-2553294239 From mgronlun at openjdk.org Wed Jan 15 16:45:41 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 15 Jan 2025 16:45:41 GMT Subject: [jdk24] Integrated: 8345493: JFR: JVM.flush hangs intermittently In-Reply-To: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com> References: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com> Message-ID: On Wed, 15 Jan 2025 16:19:30 GMT, Markus Gr?nlund wrote: > 8345493: JFR: JVM.flush hangs intermittently This pull request has now been integrated. Changeset: 1495f7ad Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/1495f7addbaab5ed6bfb582a63f8cc2f0c97a100 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod 8345493: JFR: JVM.flush hangs intermittently Reviewed-by: egahlin Backport-of: 4257215a9fa02f74ccd4fc62893d4b1a232a8754 ------------- PR: https://git.openjdk.org/jdk/pull/23141 From duke at openjdk.org Wed Jan 15 22:30:45 2025 From: duke at openjdk.org (duke) Date: Wed, 15 Jan 2025 22:30:45 GMT Subject: Withdrawn: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 12:22:36 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) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22104 From egahlin at openjdk.org Thu Jan 16 03:51:34 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 16 Jan 2025 03:51:34 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:02:55 GMT, Matthias Baesken wrote: > The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : > java.lang.AssertionError: Expected at least one event > at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1447) > > The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. Do you think it is this lines that prevent us from getting a sample. https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/hotspot/os/bsd/os_perf_bsd.cpp#L140 Maybe we should do some work instead of additional sleeping? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2594419548 From mbaesken at openjdk.org Thu Jan 16 08:11:35 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Jan 2025 08:11:35 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS In-Reply-To: References: Message-ID: <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com> On Wed, 15 Jan 2025 14:02:55 GMT, Matthias Baesken wrote: > The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : > java.lang.AssertionError: Expected at least one event > at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1447) > > The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. Not sure if it is this line. Should we maybe add some UL tracing; enable it for the test and see if we hit this ? > Maybe we should do some work instead of additional sleeping? Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2594780617 From egahlin at openjdk.org Thu Jan 16 10:48:35 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 16 Jan 2025 10:48:35 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS In-Reply-To: <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com> References: <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com> Message-ID: On Thu, 16 Jan 2025 08:09:19 GMT, Matthias Baesken wrote: > Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work . You could keep the 100 ms and do some CPU intensive work. If it still fails, then we'll know it's not CPU work related. If we change both at once, it's harder to analyze. If I remember correctly, we didn't have sleep at all initially (2012). Then we had a smaller sleep which was later increased to 100 ms. We should probably have tried to add CPU related work instead of increasing the sleep time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2595185436 From mgronlun at openjdk.org Thu Jan 16 13:59:06 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 16 Jan 2025 13:59:06 GMT Subject: RFR: 8347922: Remove runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt and TEST.groups Message-ID: Greetings, Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt and TEST.groups. Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC. Thanks Markus ------------- Commit messages: - 8347922 Changes: https://git.openjdk.org/jdk/pull/23158/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23158&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347922 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23158/head:pull/23158 PR: https://git.openjdk.org/jdk/pull/23158 From egahlin at openjdk.org Thu Jan 16 14:03:34 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 16 Jan 2025 14:03:34 GMT Subject: RFR: 8347922: Remove runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt and TEST.groups In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 13:53:49 GMT, Markus Gr?nlund wrote: > Greetings, > > Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt and TEST.groups. > > Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC. > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23158#pullrequestreview-2556242652 From mbaesken at openjdk.org Thu Jan 16 14:45:16 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Jan 2025 14:45:16 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS [v2] In-Reply-To: References: Message-ID: > The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : > java.lang.AssertionError: Expected at least one event > at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1447) > > The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust the program, burn some cycles instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23136/files - new: https://git.openjdk.org/jdk/pull/23136/files/ad334587..382a12f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23136&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23136&range=00-01 Stats: 22 lines in 1 file changed: 19 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23136.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23136/head:pull/23136 PR: https://git.openjdk.org/jdk/pull/23136 From mbaesken at openjdk.org Thu Jan 16 14:52:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Jan 2025 14:52:39 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 14:45:16 GMT, Matthias Baesken wrote: >> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : >> java.lang.AssertionError: Expected at least one event >> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust the program, burn some cycles instead Hi Erik, I added some code doing a few calculations. Let's see if this is good . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2595932390 From gziemski at openjdk.org Thu Jan 16 19:46:15 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 16 Jan 2025 19:46:15 GMT Subject: RFR: 8345500: Timeout in jdk.jfr.api.consumer.streaming.TestJVMCrash Message-ID: In this fix we add 1 second delay after we create a process. On macOS we seem to be creating a process so quickly, that other threads need time to see it. ------------- Commit messages: - allow process to be visible by other threads Changes: https://git.openjdk.org/jdk/pull/23163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345500 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23163/head:pull/23163 PR: https://git.openjdk.org/jdk/pull/23163 From egahlin at openjdk.org Thu Jan 16 19:59:38 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 16 Jan 2025 19:59:38 GMT Subject: RFR: 8345500: Timeout in jdk.jfr.api.consumer.streaming.TestJVMCrash In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 19:39:01 GMT, Gerard Ziemski wrote: > In this fix we add 1 second delay after we create a process. > > On macOS we seem to be creating a process so quickly, that other threads need time to see it. I don't think this is the correct way to fix the issue. Users may write code that doesn't wait 1 s and run into the same problem. Why shouldn't a client be able to poll? Also, it's only a matter of time before it happens again, either because the hardware is slow or because the processes are starved due to other processes running on the machine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23163#issuecomment-2596779153 From egahlin at openjdk.org Thu Jan 16 20:04:36 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 16 Jan 2025 20:04:36 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS [v2] In-Reply-To: References: Message-ID: <5IZ_0IqI0ypBeE7PNHqJawhmSyVfRxF_Wkdjav0GNZc=.5b69d890-0cdf-41ad-9636-5e5ba520ee95@github.com> On Thu, 16 Jan 2025 14:45:16 GMT, Matthias Baesken wrote: >> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : >> java.lang.AssertionError: Expected at least one event >> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust the program, burn some cycles instead I tried running the test 100 times on different operating systems and hardware. No failures. Let's try this. ------------- Marked as reviewed by egahlin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23136#pullrequestreview-2557185942 From gziemski at openjdk.org Thu Jan 16 23:01:35 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 16 Jan 2025 23:01:35 GMT Subject: RFR: 8345500: Timeout in jdk.jfr.api.consumer.streaming.TestJVMCrash In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 19:57:12 GMT, Erik Gahlin wrote: > I don't think this is the correct way to fix the issue. Users may write code that doesn't wait 1 s and run into the same problem. Why shouldn't a client be able to poll repeatedly? Also, it's only a matter of time before it happens again, either because the hardware is slow or because the processes are starved due to other things running on the machine. To be honest I'm not 100% happy with the fix, it was just the simplest one that I could think of. Let me look into it a bit more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23163#issuecomment-2597076705 From mbaesken at openjdk.org Fri Jan 17 08:01:48 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 17 Jan 2025 08:01:48 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 14:45:16 GMT, Matthias Baesken wrote: >> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : >> java.lang.AssertionError: Expected at least one event >> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust the program, burn some cycles instead Hi Erik, thanks for the review ! Let's see if this is better than the sleep (or maybe we need both, sleep and cycle burning) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2597639959 From mbaesken at openjdk.org Fri Jan 17 08:01:49 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 17 Jan 2025 08:01:49 GMT Subject: Integrated: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:02:55 GMT, Matthias Baesken wrote: > The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with : > java.lang.AssertionError: Expected at least one event > at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1447) > > The current sleep value seems to be a bit too slow for those machines. The issues occured (mostly) with fastdebug binaries. This pull request has now been integrated. Changeset: a3eef6c2 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a3eef6c2416eb0e02fbd154d84c98b12bcb66e97 Stats: 23 lines in 1 file changed: 19 ins; 1 del; 3 mod 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/23136 From mgronlun at openjdk.org Fri Jan 17 17:35:51 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 17 Jan 2025 17:35:51 GMT Subject: RFR: 8347922: Remove runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt and TEST.groups [v2] In-Reply-To: References: Message-ID: > Greetings, > > Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt and TEST.groups. > > Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC. > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: do not modify TEST.groups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23158/files - new: https://git.openjdk.org/jdk/pull/23158/files/dca3d53c..0c661b42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23158&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23158&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23158/head:pull/23158 PR: https://git.openjdk.org/jdk/pull/23158 From egahlin at openjdk.org Fri Jan 17 17:46:34 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 17 Jan 2025 17:46:34 GMT Subject: RFR: 8347922: Remove runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 17:35:51 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt. >> >> Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC. >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > do not modify TEST.groups Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23158#pullrequestreview-2559613287 From mgronlun at openjdk.org Mon Jan 20 08:56:43 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 20 Jan 2025 08:56:43 GMT Subject: Integrated: 8347922: Remove runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt In-Reply-To: References: Message-ID: <8WJ57ZFYu4zAXhQwRgo3NyPzLfo1bROYP1O_p61Mboo=.8fce7cab-9c20-4eda-884d-097eebead139@github.com> On Thu, 16 Jan 2025 13:53:49 GMT, Markus Gr?nlund wrote: > Greetings, > > Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt. > > Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC. > > Thanks > Markus This pull request has now been integrated. Changeset: 4b4b1e91 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/4b4b1e912a3193cc95c956acc770015f707449b1 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8347922: Remove runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/23158 From egahlin at openjdk.org Mon Jan 20 18:41:39 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 20 Jan 2025 18:41: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 Thu, 19 Dec 2024 19:16:55 GMT, Erik Gahlin wrote: >> 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 it before FC, if needed. I talked to Markus, and we think two events would provide the greatest flexibility for future settings and events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1922757394 From mbaesken at openjdk.org Thu Jan 23 09:11:08 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Jan 2025 09:11:08 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS In-Reply-To: References: <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com> Message-ID: On Thu, 16 Jan 2025 10:46:24 GMT, Erik Gahlin wrote: >> Not sure if it is this line. Should we maybe add some UL tracing; enable it for the test and see if we hit this ? >> >>> Maybe we should do some work instead of additional sleeping? >> >> Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work . > >> Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work . > > You could keep the 100 ms and do some CPU intensive work. If it still fails, then we'll know it's not CPU work related. If we change both at once, it's harder to analyze. > > If I remember correctly, we didn't have sleep at all initially (2012). Then we had a smaller sleep which was later increased to 100 ms. We should probably have tried to add CPU related work instead of increasing the sleep time. Hi Erik @egahlin , we unfortunately still sometimes see the error after this change ----------System.out:(1/41)---------- Found 183072 primes while burning cycles ----------System.err:(11/642)---------- java.lang.AssertionError: Expected at least one event at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:80) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1447) So burning cycles did not really help . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2609230974 From egahlin at openjdk.org Fri Jan 24 02:28:58 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 24 Jan 2025 02:28:58 GMT Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS In-Reply-To: References: <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com> Message-ID: On Thu, 16 Jan 2025 10:46:24 GMT, Erik Gahlin wrote: >> Not sure if it is this line. Should we maybe add some UL tracing; enable it for the test and see if we hit this ? >> >>> Maybe we should do some work instead of additional sleeping? >> >> Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work . > >> Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work . > > You could keep the 100 ms and do some CPU intensive work. If it still fails, then we'll know it's not CPU work related. If we change both at once, it's harder to analyze. > > If I remember correctly, we didn't have sleep at all initially (2012). Then we had a smaller sleep which was later increased to 100 ms. We should probably have tried to add CPU related work instead of increasing the sleep time. > Hi Erik @egahlin , we unfortunately still sometimes see the error after this change I've noticed the same thing when running them in parallel locally, i.e., $ jtreg-conc:32 -v:a -jdk ... test/jdk/jdk/jfr You could try adding logging (log_debug(jfr, system)("...")) and see if you can reproduce the issue. If it's not a product bug, you could try to use an event stream instead. public static void main(String... args) throws Exception { List events = new CopyOnWriteArrayList<>(); try (var rs = new RecordingStream()) { rs.setReuse(false); rs.enable("jdk.CPULoad").withPeriod(Duration.ofMillis(50)); rs.onEvent(e -> { events.add(e); rs.close(); }); rs.start(); verifyEvent(events.getFirst()); } } private static void verifyEvent(RecordedEvent e) throws Exception { ... }` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2611409245 From mgronlun at openjdk.org Fri Jan 24 10:40:48 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 24 Jan 2025 10:40:48 GMT Subject: RFR: 8318098: Update jfr tests to replace keyword jfr with vm.flagless In-Reply-To: References: Message-ID: <_uOSUMMSvGhGU6WkVdjg6iIi3SU9rhyi9qlLi3zYiPY=.fda4acbd-8774-4d38-b70e-56c0e639cb77@github.com> On Fri, 24 Jan 2025 01:08:31 GMT, Leonid Mesnik wrote: > A lot of jfr tests are very specific. Currently all of them are marked with jfr keyword and excluded when VM flags are set. > > It makes sense to mark them with @requires to be complaint with all other openjdk tests. > The next step is to review tests and remove vm.flagless from tests that should be executed with different VM flags. > > Bug https://bugs.openjdk.org/browse/JDK-8318097 is filed for this activity. Blanket review. Did not check all files. ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23285#pullrequestreview-2572300298 From lmesnik at openjdk.org Sat Jan 25 19:02:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 25 Jan 2025 19:02:53 GMT Subject: Integrated: 8318098: Update jfr tests to replace keyword jfr with vm.flagless In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 01:08:31 GMT, Leonid Mesnik wrote: > A lot of jfr tests are very specific. Currently all of them are marked with jfr keyword and excluded when VM flags are set. > > It makes sense to mark them with @requires to be complaint with all other openjdk tests. > The next step is to review tests and remove vm.flagless from tests that should be executed with different VM flags. > > Bug https://bugs.openjdk.org/browse/JDK-8318097 is filed for this activity. This pull request has now been integrated. Changeset: 99002e4f Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/99002e4f9d421d08d912187a1f01809d85820427 Stats: 1090 lines in 582 files changed: 2 ins; 0 del; 1088 mod 8318098: Update jfr tests to replace keyword jfr with vm.flagless Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/23285 From egahlin at openjdk.org Thu Jan 30 15:13:24 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 30 Jan 2025 15:13:24 GMT Subject: RFR: 8348430: Update jfr tests to allow execution with different vm flags Message-ID: Could I have review of a change that allows some tests to run with flags. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/23369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348430 Stats: 10 lines in 10 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23369/head:pull/23369 PR: https://git.openjdk.org/jdk/pull/23369 From mgronlun at openjdk.org Thu Jan 30 16:49:52 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 30 Jan 2025 16:49:52 GMT Subject: RFR: 8348430: Update jfr tests to allow execution with different vm flags In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 14:25:51 GMT, Erik Gahlin wrote: > Could I have review of a change that allows some tests to run with flags. > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23369#pullrequestreview-2584467279 From egahlin at openjdk.org Fri Jan 31 08:58:49 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 31 Jan 2025 08:58:49 GMT Subject: Integrated: 8348430: Update jfr tests to allow execution with different vm flags In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 14:25:51 GMT, Erik Gahlin wrote: > Could I have review of a change that allows some tests to run with flags. > > Thanks > Erik This pull request has now been integrated. Changeset: 8f7e6e2d Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/8f7e6e2dbc0a3ccf56242bf071e57bfd671de951 Stats: 10 lines in 10 files changed: 0 ins; 10 del; 0 mod 8348430: Update jfr tests to allow execution with different vm flags Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/23369