From duke at openjdk.org Fri Aug 2 00:39:56 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Fri, 2 Aug 2024 00:39:56 GMT Subject: RFR: 8236: Add support for Jolokia discovery [v3] In-Reply-To: References: Message-ID: > Jolokia comes with a discovery mechanism. It is helpful to make use of this to automatically populate the JVM browser, alongside local JVM and other discovery mechanisms. > > https://jolokia.org/reference/html/manual/jolokia_protocol.html#discovery Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-8236: Deleted blank lines ------------- Changes: - all: https://git.openjdk.org/jmc/pull/570/files - new: https://git.openjdk.org/jmc/pull/570/files/2445326d..db5128c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=570&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=570&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/570.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/570/head:pull/570 PR: https://git.openjdk.org/jmc/pull/570 From vpurnam at openjdk.org Fri Aug 2 08:40:36 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Fri, 2 Aug 2024 08:40:36 GMT Subject: RFR: 8114: Verify fixed uitests in ControlRecordingsTest on jdk 17 In-Reply-To: References: Message-ID: <_kMZqMqTM6zzNaKtSu9d2Bmx0NKHkBXXFSz8qmkHlqI=.cddc784b-7f82-4d87-8db1-ca00431ee7ec@github.com> On Tue, 30 Jul 2024 16:03:16 GMT, Alex Macdonald wrote: > JMC-8114 (https://bugs.openjdk.org/browse/JMC-8114) is a follow-up to JMC-8175 (https://bugs.openjdk.org/browse/JMC-8175). > > There were a handful of uitests in ControlRecordingsTest that were failing, and were ignored until this backport was released in 17.0.12: https://bugs.openjdk.org/browse/JDK-8328159. > > They're passing again now, so the tests can be un-ignored and run again. > > Having said that, I'm running into different flightrecorder uitest failures now, but can address that in a different issue. Marked as reviewed by vpurnam (Committer). ------------- PR Review: https://git.openjdk.org/jmc/pull/575#pullrequestreview-2215023091 From aptmac at openjdk.org Fri Aug 2 13:25:37 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 2 Aug 2024 13:25:37 GMT Subject: RFR: 8236: Add support for Jolokia discovery [v3] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 00:39:56 GMT, Martin Skarsaune wrote: >> Jolokia comes with a discovery mechanism. It is helpful to make use of this to automatically populate the JVM browser, alongside local JVM and other discovery mechanisms. >> >> https://jolokia.org/reference/html/manual/jolokia_protocol.html#discovery > > Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: > > JMC-8236: Deleted blank lines Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/570#pullrequestreview-2215579973 From duke at openjdk.org Sat Aug 3 13:01:35 2024 From: duke at openjdk.org (duke) Date: Sat, 3 Aug 2024 13:01:35 GMT Subject: RFR: 8236: Add support for Jolokia discovery [v3] In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 00:39:56 GMT, Martin Skarsaune wrote: >> Jolokia comes with a discovery mechanism. It is helpful to make use of this to automatically populate the JVM browser, alongside local JVM and other discovery mechanisms. >> >> https://jolokia.org/reference/html/manual/jolokia_protocol.html#discovery > > Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: > > JMC-8236: Deleted blank lines @skarsaune Your change (at version db5128c1f156763a4704227448ea6fff095d103a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jmc/pull/570#issuecomment-2266704982 From duke at openjdk.org Sat Aug 3 17:49:37 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sat, 3 Aug 2024 17:49:37 GMT Subject: Integrated: 8236: Add support for Jolokia discovery In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 20:43:04 GMT, Martin Skarsaune wrote: > Jolokia comes with a discovery mechanism. It is helpful to make use of this to automatically populate the JVM browser, alongside local JVM and other discovery mechanisms. > > https://jolokia.org/reference/html/manual/jolokia_protocol.html#discovery This pull request has now been integrated. Changeset: 8a04432f Author: Martin Skarsaune Committer: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/8a04432f1678a2a9119becd509100417b27b56eb Stats: 1070 lines in 21 files changed: 1045 ins; 7 del; 18 mod 8236: Add support for Jolokia discovery Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/570 From vpurnam at openjdk.org Wed Aug 7 05:13:37 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Wed, 7 Aug 2024 05:13:37 GMT Subject: Integrated: 8245: Improve XML processing In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 04:47:16 GMT, Virag Purnam wrote: > Improve XML processing. > Static code analyzer tool flags some issues in below classes for XML processing. > > - ListVersions.java > - Preset.java > - StateToolkit.java > - TestRulesWithJfr.java > - XmlToolkit.java > - Transform.java > > I have fixed all the issues by adding some attributes and features to **DocumentBuilderFactory**, **SAXParserFactory** and **TransformerFactory**. This pull request has now been integrated. Changeset: 5016cc19 Author: Virag Purnam URL: https://git.openjdk.org/jmc/commit/5016cc1919616f559cec95a20dc3ae2edb721dc3 Stats: 22 lines in 6 files changed: 16 ins; 0 del; 6 mod 8245: Improve XML processing Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/574 From bdutheil at openjdk.org Fri Aug 9 12:50:37 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 9 Aug 2024 12:50:37 GMT Subject: RFR: 8244: Turn off scientific notation in JMC for attributes with long data type In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 19:24:56 GMT, Suchita Chaturvedi wrote: > This PR resolves the issue of scientific notation display for attributes with long datatype. This was the common pain-point of several customers and we were getting repeated requests of fixing this issue as they were not able to analyze the data due to this format of display. Since there is very less difference between the values of each row, after converting it to scientific notation all values look-alike and its difficult for customers to analyze the data. We have consulted the JFR team and there was a suggestion of skipping long attributes for this format display as they have followed in JFR-tools also. Same approach I have followed in JMC too. Please provide your valuable feedbacks. > > Attaching few screenshots for better reference: > > Before: > image > > After: > image > > Before: > image > > After: > image > > Before: > image > > After: > image This PR looks good to me for the immediate problem, but I wonder if other predefined "attributes" could benefit from that approach. core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java line 813: > 811: return countNumber == null ? null : UnitLookup.NUMBER_UNITY.quantity(countNumber); > 812: } > 813: }; **question:** For readability I wonder of these attributes might be converted to lambda, e.g. : Suggestion: return accessor == null ? null : i -> { Number countNumber = accessor.getMember(i); return countNumber == null ? null : UnitLookup.NUMBER_UNITY.quantity(countNumber); }; core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java line 817: > 815: }); > 816: > 817: public static final IAttribute CLASSLOADER_UNLOADED_COUNT = attr("unloadedClassCount", //$NON-NLS-1$ **question:** Could this be useful to have that for similar attributes like `unloadedClassCount`. ------------- Marked as reviewed by bdutheil (Committer). PR Review: https://git.openjdk.org/jmc/pull/572#pullrequestreview-2230080132 PR Review Comment: https://git.openjdk.org/jmc/pull/572#discussion_r1711398125 PR Review Comment: https://git.openjdk.org/jmc/pull/572#discussion_r1711383737 From schaturvedi at openjdk.org Tue Aug 13 09:03:59 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Tue, 13 Aug 2024 09:03:59 GMT Subject: RFR: 8244: Turn off scientific notation in JMC for attributes with long data type In-Reply-To: References: Message-ID: <81XjduDqE__98HOvYVSKtuaTor3TUAVZ1_93P7OQJBo=.281df2dc-c943-48cf-bbac-813208da9aea@github.com> On Fri, 9 Aug 2024 12:34:44 GMT, Brice Dutheil wrote: >> This PR resolves the issue of scientific notation display for attributes with long datatype. This was the common pain-point of several customers and we were getting repeated requests of fixing this issue as they were not able to analyze the data due to this format of display. Since there is very less difference between the values of each row, after converting it to scientific notation all values look-alike and its difficult for customers to analyze the data. We have consulted the JFR team and there was a suggestion of skipping long attributes for this format display as they have followed in JFR-tools also. Same approach I have followed in JMC too. Please provide your valuable feedbacks. >> >> Attaching few screenshots for better reference: >> >> Before: >> image >> >> After: >> image >> >> Before: >> image >> >> After: >> image >> >> Before: >> image >> >> After: >> image > > core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java line 817: > >> 815: }); >> 816: >> 817: public static final IAttribute CLASSLOADER_UNLOADED_COUNT = attr("unloadedClassCount", //$NON-NLS-1$ > > **question:** Could this be useful to have that for similar attributes like `unloadedClassCount`. yes it resolves issue for all such attributes. Here is the example of a JFR where unloadedClassCount data is present. Before the change: image After the change: image ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/572#discussion_r1714933564 From jbachorik at openjdk.org Tue Aug 20 01:38:55 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 20 Aug 2024 01:38:55 GMT Subject: Integrated: 7992: Add API to easily write annotated Java JFR events In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 10:05:32 GMT, Jaroslav Bachorik wrote: > This PR extends the JFR Writer API with the ability to use the custom JFR event types (eg. classes extending `jdk.jfr.Event`) and register new writer type for them and also directly accept the instances of those types to write them in the recording. This pull request has now been integrated. Changeset: 4c9d9e47 Author: Jaroslav Bachorik Committer: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/4c9d9e47bcf13d6c12ddfcdeddb2e90dbe3b691b Stats: 642 lines in 4 files changed: 635 ins; 0 del; 7 mod 7992: Add API to easily write annotated Java JFR events Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/457 From hirt at openjdk.org Tue Aug 20 01:57:56 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 20 Aug 2024 01:57:56 GMT Subject: RFR: 8244: Turn off scientific notation in JMC for attributes with long data type In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 19:24:56 GMT, Suchita Chaturvedi wrote: > This PR resolves the issue of scientific notation display for attributes with long datatype. This was the common pain-point of several customers and we were getting repeated requests of fixing this issue as they were not able to analyze the data due to this format of display. Since there is very less difference between the values of each row, after converting it to scientific notation all values look-alike and its difficult for customers to analyze the data. We have consulted the JFR team and there was a suggestion of skipping long attributes for this format display as they have followed in JFR-tools also. Same approach I have followed in JMC too. Please provide your valuable feedbacks. > > Attaching few screenshots for better reference: > > Before: > image > > After: > image > > Before: > image > > After: > image > > Before: > image > > After: > image core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java line 796: > 794: Messages.getString(Messages.ATTR_SHUTDOWN_REASON), Messages.getString(Messages.ATTR_SHUTDOWN_REASON_DESC), > 795: PLAIN_TEXT); > 796: public static final IAttribute CLASSLOADER_LOADED_COUNT_NUMBER = attr("loadedClassCount", //$NON-NLS-1$ Note that this is changing the generic type for publicly defined constants, and that we would be breaking people depending on them. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/572#discussion_r1722589881 From hirt at openjdk.org Tue Aug 20 01:59:59 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 20 Aug 2024 01:59:59 GMT Subject: RFR: 8219: Missing coverage in application reports [v4] In-Reply-To: <5AlSPiHHedQxTobNQNhzkL-JcdnR98JtkihgQFM0maw=.86af4ff4-c8be-4945-91be-021d069fb5d7@github.com> References: <5AlSPiHHedQxTobNQNhzkL-JcdnR98JtkihgQFM0maw=.86af4ff4-c8be-4945-91be-021d069fb5d7@github.com> Message-ID: <6lbk3qPbTAaUR4tSrM6i4qFQAtpjoJOtL62PArKG46M=.a7298920-b9c6-427d-b57a-98386e846d0a@github.com> On Tue, 2 Jul 2024 14:32:37 GMT, Alex Macdonald wrote: >> This PR fixes (&cleans up) the coverage reports under jmc/application. >> >> The argLine was being set in a handful of the application test packages without the surefireArgLine that's required to have jacoco run coverage. >> >> Additionally I've removed a bunch of the feature packages from the report (as there isn't anything to scan), and included missing packages that have been added in the last few years. There were also a handful of versions that needed to be updated as well. >> >> The Jacoco version in core was bumped to 8.0.10, but the application version stayed at 8.0.7, this has been updated. > > Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Add tycho.testArgLine.local to Jolokia test argLine > - Merge remote-tracking branch 'upstream/master' into 8219 > - update license header > - adjust the argline for tycho-maven-plugin > - 8219: Missing coverage in application reports Branch has conflicts. ------------- PR Comment: https://git.openjdk.org/jmc/pull/562#issuecomment-2297819510 From aptmac at openjdk.org Tue Aug 20 16:44:04 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 20 Aug 2024 16:44:04 GMT Subject: RFR: 8219: Missing coverage in application reports [v5] In-Reply-To: References: Message-ID: > This PR fixes (&cleans up) the coverage reports under jmc/application. > > The argLine was being set in a handful of the application test packages without the surefireArgLine that's required to have jacoco run coverage. > > Additionally I've removed a bunch of the feature packages from the report (as there isn't anything to scan), and included missing packages that have been added in the last few years. There were also a handful of versions that needed to be updated as well. > > The Jacoco version in core was bumped to 8.0.10, but the application version stayed at 8.0.7, this has been updated. Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Add tycho.testArgLine.local to Jolokia test argLine - adjust the argline for tycho-maven-plugin - 8219: Missing coverage in application reports ------------- Changes: https://git.openjdk.org/jmc/pull/562/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=562&range=04 Stats: 117 lines in 7 files changed: 10 ins; 88 del; 19 mod Patch: https://git.openjdk.org/jmc/pull/562.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/562/head:pull/562 PR: https://git.openjdk.org/jmc/pull/562 From schaturvedi at openjdk.org Tue Aug 20 18:31:11 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Tue, 20 Aug 2024 18:31:11 GMT Subject: RFR: 8244: Turn off scientific notation in JMC for attributes with long data type In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 01:55:33 GMT, Marcus Hirt wrote: >> This PR resolves the issue of scientific notation display for attributes with long datatype. This was the common pain-point of several customers and we were getting repeated requests of fixing this issue as they were not able to analyze the data due to this format of display. Since there is very less difference between the values of each row, after converting it to scientific notation all values look-alike and its difficult for customers to analyze the data. We have consulted the JFR team and there was a suggestion of skipping long attributes for this format display as they have followed in JFR-tools also. Same approach I have followed in JMC too. Please provide your valuable feedbacks. >> >> Attaching few screenshots for better reference: >> >> Before: >> image >> >> After: >> image >> >> Before: >> image >> >> After: >> image >> >> Before: >> image >> >> After: >> image > > core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java line 796: > >> 794: Messages.getString(Messages.ATTR_SHUTDOWN_REASON), Messages.getString(Messages.ATTR_SHUTDOWN_REASON_DESC), >> 795: PLAIN_TEXT); >> 796: public static final IAttribute CLASSLOADER_LOADED_COUNT_NUMBER = attr("loadedClassCount", //$NON-NLS-1$ > > Note that this is changing the generic type for publicly defined constants, and that we would be breaking people depending on them. Thanks for the review @thegreystone . I understand this concern, thats why I have retained the attribute with same datatype i.e. IQuantity on line number 800. So basically the internal value is number but I have written a custom accessor to retain the uniformity of IQuantity data type. So that it doesn;t break anything. Please let me know if I am missing something here. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/572#discussion_r1723765131 From hirt at openjdk.org Wed Aug 21 22:32:36 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 21 Aug 2024 22:32:36 GMT Subject: RFR: 8238: Update to Eclipse 2024-06 Message-ID: This one got a bit interesting. ------------- Commit messages: - Updating to the correct spifly version in the 2024-03 target - Getting the right maven version - Updating action versions - Using both the JDK 17 toolchain (for core) and JDK 21 (for the app) - Updating to 21, and updating the platform definition with the additional jolokia dependencies - Updating HDR histogram - Merge branch 'openjdk:master' into 8238-update-2024-06 - Merge pull request #3 from viragpurnam/8238-Working - 8238 JDK 21 - 8238 JDK 21 - ... and 5 more: https://git.openjdk.org/jmc/compare/4c9d9e47...2b468857 Changes: https://git.openjdk.org/jmc/pull/578/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=578&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8238 Stats: 345 lines in 9 files changed: 299 ins; 21 del; 25 mod Patch: https://git.openjdk.org/jmc/pull/578.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/578/head:pull/578 PR: https://git.openjdk.org/jmc/pull/578 From hirt at openjdk.org Fri Aug 23 21:12:10 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 23 Aug 2024 21:12:10 GMT Subject: RFR: 8114: Verify fixed uitests in ControlRecordingsTest on jdk 17 In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 16:03:16 GMT, Alex Macdonald wrote: > JMC-8114 (https://bugs.openjdk.org/browse/JMC-8114) is a follow-up to JMC-8175 (https://bugs.openjdk.org/browse/JMC-8175). > > There were a handful of uitests in ControlRecordingsTest that were failing, and were ignored until this backport was released in 17.0.12: https://bugs.openjdk.org/browse/JDK-8328159. > > They're passing again now, so the tests can be un-ignored and run again. > > Having said that, I'm running into different flightrecorder uitest failures now, but can address that in a different issue. Marked as reviewed by hirt (Lead). ------------- PR Review: https://git.openjdk.org/jmc/pull/575#pullrequestreview-2258108709 From hirt at openjdk.org Fri Aug 23 21:14:09 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 23 Aug 2024 21:14:09 GMT Subject: RFR: 8244: Turn off scientific notation in JMC for attributes with long data type In-Reply-To: References: Message-ID: <6YnHP8UpKoTBwkUs4BdxXJQ4MZFya1VVXqSuNyL2SGI=.c44e035c-c18a-4b95-9605-a4c51d3289d9@github.com> On Sun, 28 Jul 2024 19:24:56 GMT, Suchita Chaturvedi wrote: > This PR resolves the issue of scientific notation display for attributes with long datatype. This was the common pain-point of several customers and we were getting repeated requests of fixing this issue as they were not able to analyze the data due to this format of display. Since there is very less difference between the values of each row, after converting it to scientific notation all values look-alike and its difficult for customers to analyze the data. We have consulted the JFR team and there was a suggestion of skipping long attributes for this format display as they have followed in JFR-tools also. Same approach I have followed in JMC too. Please provide your valuable feedbacks. > > Attaching few screenshots for better reference: > > Before: > image > > After: > image > > Before: > image > > After: > image > > Before: > image > > After: > image Marked as reviewed by hirt (Lead). ------------- PR Review: https://git.openjdk.org/jmc/pull/572#pullrequestreview-2258110981 From schaturvedi at openjdk.org Sat Aug 24 10:36:08 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 24 Aug 2024 10:36:08 GMT Subject: Integrated: 8244: Turn off scientific notation in JMC for attributes with long data type In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 19:24:56 GMT, Suchita Chaturvedi wrote: > This PR resolves the issue of scientific notation display for attributes with long datatype. This was the common pain-point of several customers and we were getting repeated requests of fixing this issue as they were not able to analyze the data due to this format of display. Since there is very less difference between the values of each row, after converting it to scientific notation all values look-alike and its difficult for customers to analyze the data. We have consulted the JFR team and there was a suggestion of skipping long attributes for this format display as they have followed in JFR-tools also. Same approach I have followed in JMC too. Please provide your valuable feedbacks. > > Attaching few screenshots for better reference: > > Before: > image > > After: > image > > Before: > image > > After: > image > > Before: > image > > After: > image This pull request has now been integrated. Changeset: ab0f9a6c Author: Suchita Chaturvedi URL: https://git.openjdk.org/jmc/commit/ab0f9a6c35254b390866de5b4c44712d052099e4 Stats: 68 lines in 3 files changed: 60 ins; 0 del; 8 mod 8244: Turn off scientific notation in JMC for attributes with long data type Reviewed-by: bdutheil, hirt ------------- PR: https://git.openjdk.org/jmc/pull/572 From vpurnam at openjdk.org Sat Aug 24 11:34:07 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Sat, 24 Aug 2024 11:34:07 GMT Subject: RFR: 8238: Update to Eclipse 2024-06 In-Reply-To: References: Message-ID: <3oRFE1ExxUQHvw6BDPLcLCxOvqDVeDOLkpd64CZMdes=.8f2851dc-7aef-47d9-bdae-44c9d449d865@github.com> On Wed, 21 Aug 2024 22:28:06 GMT, Marcus Hirt wrote: > This one got a bit interesting. LGTM ------------- Marked as reviewed by vpurnam (Committer). PR Review: https://git.openjdk.org/jmc/pull/578#pullrequestreview-2258677203 From schaturvedi at openjdk.org Mon Aug 26 10:24:39 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Mon, 26 Aug 2024 10:24:39 GMT Subject: RFR: 8248: [Accessibility] Low Contrast in High Contrast mode on Stacktrace View Message-ID: This PR is to fix the accessibility issue for High Contrast mode. Stracktrace View was not readable at all in dark mode. Before the fix: image After the fix: image ------------- Commit messages: - 8248: [Accessibility] Low Contrast in High Contrast mode on Stacktrace View Changes: https://git.openjdk.org/jmc/pull/580/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=580&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8248 Stats: 51 lines in 3 files changed: 42 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jmc/pull/580.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/580/head:pull/580 PR: https://git.openjdk.org/jmc/pull/580 From aptmac at openjdk.org Mon Aug 26 17:38:11 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 26 Aug 2024 17:38:11 GMT Subject: Integrated: 8114: Verify fixed uitests in ControlRecordingsTest on jdk 17 In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 16:03:16 GMT, Alex Macdonald wrote: > JMC-8114 (https://bugs.openjdk.org/browse/JMC-8114) is a follow-up to JMC-8175 (https://bugs.openjdk.org/browse/JMC-8175). > > There were a handful of uitests in ControlRecordingsTest that were failing, and were ignored until this backport was released in 17.0.12: https://bugs.openjdk.org/browse/JDK-8328159. > > They're passing again now, so the tests can be un-ignored and run again. > > Having said that, I'm running into different flightrecorder uitest failures now, but can address that in a different issue. This pull request has now been integrated. Changeset: 719b7142 Author: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/719b71422e06d6d290642c97e48dbef22b437449 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8114: Verify fixed uitests in ControlRecordingsTest on jdk 17 Reviewed-by: vpurnam, hirt ------------- PR: https://git.openjdk.org/jmc/pull/575 From bdutheil at openjdk.org Wed Aug 28 14:08:29 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 28 Aug 2024 14:08:29 GMT Subject: RFR: 8248: [Accessibility] Low Contrast in High Contrast mode on Stacktrace View In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 10:20:20 GMT, Suchita Chaturvedi wrote: > This PR is to fix the accessibility issue for High Contrast mode. Stracktrace View was not readable at all in dark mode. > > Before the fix: > image > > After the fix: > image application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java line 212: > 210: > 211: private static final String HELP_CONTEXT_ID = FlightRecorderUI.PLUGIN_ID + ".StacktraceView"; //$NON-NLS-1$ > 212: private static final Boolean IS_DARK_MODE = ThemeUtils.isDarkMode(); **question:** I would avoid the static final there, I think the themes can be dynamic, i.e. change without restarting ? If that's not the case maybe it can be in the future. See the the comment on `ThemeUtils` to see a different approach. application/org.openjdk.jmc.ui.common/src/main/java/org/openjdk/jmc/ui/common/util/ThemeUtils.java line 8: > 6: import org.eclipse.ui.PlatformUI; > 7: > 8: public class ThemeUtils { **suggestion:** I believe the themes can change at runtime. `isDarkMode` will compute this value always. But to avoid the computation on each call, you could store a variable here and update this value each time the theme changes. Something like: public class ThemeUtils { private static boolean isCurrentThemeDark = isDarkMode(); static { PlatformUI.getWorkbench().getThemeManager().addPropertyChangeListener(() -> isCurrentThemeDark = isDarkMode()) } public static boolean isDarkThemeTheme() { return isCurrentThemeDark; } } This way the value is updated anytime the theme changes. I'm not quite sure when to register the listener, I put it in static block as an example, but maybe this is not recommended in the Eclipse RCP programing idioms. Note I kept the original name of `isDarkMode`, but feel free to rename to anything meaningful in your implementation. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/580#discussion_r1734708852 PR Review Comment: https://git.openjdk.org/jmc/pull/580#discussion_r1734751653 From hirt at openjdk.org Wed Aug 28 17:23:27 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 28 Aug 2024 17:23:27 GMT Subject: RFR: 8238: Update to Eclipse 2024-06 In-Reply-To: References: Message-ID: <37pn_mqhLtRPhjbzjce7HCjCLx3eniK6WI8rIKBX1SM=.ebc7173d-bc55-473d-acea-434785b53f6c@github.com> On Wed, 21 Aug 2024 22:28:06 GMT, Marcus Hirt wrote: > This one got a bit interesting. @aptmac pointed out that there are a lot of warnings related to the localisation. We should test to see if the localization works, e.g. try to run with Japanese locale. ------------- PR Comment: https://git.openjdk.org/jmc/pull/578#issuecomment-2315889520 From aptmac at openjdk.org Thu Aug 29 16:50:26 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 29 Aug 2024 16:50:26 GMT Subject: RFR: 8238: Update to Eclipse 2024-06 In-Reply-To: <37pn_mqhLtRPhjbzjce7HCjCLx3eniK6WI8rIKBX1SM=.ebc7173d-bc55-473d-acea-434785b53f6c@github.com> References: <37pn_mqhLtRPhjbzjce7HCjCLx3eniK6WI8rIKBX1SM=.ebc7173d-bc55-473d-acea-434785b53f6c@github.com> Message-ID: <0Ys8xbpvBXueep6nKt1b7ngSHPSw7DIvf17JdBLmSag=.8803d7af-e1dd-431a-a9da-8118d4c04b87@github.com> On Wed, 28 Aug 2024 17:20:47 GMT, Marcus Hirt wrote: > @aptmac pointed out that there are a lot of warnings related to the localisation. We should test to see if the localization works, e.g. try to run with Japanese locale. It seems to be okay, I wonder what all the warnings are complaining about then. ![Screenshot from 2024-08-29 12-47-03](https://github.com/user-attachments/assets/342fbc34-9a61-4c96-957a-963afc4da814) ------------- PR Comment: https://git.openjdk.org/jmc/pull/578#issuecomment-2318349886 From duke at openjdk.org Fri Aug 30 19:19:53 2024 From: duke at openjdk.org (Carter Kozak) Date: Fri, 30 Aug 2024 19:19:53 GMT Subject: RFR: 8249: Add support for the new allocation profiler in rules Message-ID: <8KiZNsF0w78cDxPtWi0lubrws9yWEaTHmXKpV4PC5rc=.49391215-860c-4da1-83c6-5f3bbc2e9da8@github.com> ## Allocation Rules may use ObjectAllocationSample The allocation profiling rules (`AllocationByClassRule`, `AllocationByThreadRule`, `AutoBoxingRule`) were developed prior to the introduction of the newer and less invasive ObjectAllocationSample event. I've updated these rules to prefer the more precise events, but when those are unavailable, use the new ObjectAllocationSample events instead. This proved a bit tricky because the rules are scored based on number of events sampled, where the new events may not be emitted for every tlab based on a rate limit, so we must take into account the sample weight and estimate the number of samples as best we can. The `IRule#getRequiredEvents` API doesn't provide a way to declare _either_ dependencies, so I opted to remove the dependencies in favor of a similar check in the `getResult` implementation. ## JfrGenerator Utility The idea is to provide java sources with code that violates rules. We compile and execute the input sources while capturing a JFR, and execute rules against the results to verify they work as expected. I like having the input sources available in the test rather than only a JFR recording, because it's not clear whether most JDKs will still create the given recording, or with what configuration. However, the trade-off is that we're only testing against the JVM used to run tests, which represents a subset of all supported versions. This type of test must also compile and execute small Java programs, which is more expensive than executing against an existing recording, and may be more likely to flake if we're not careful. Anyhow, I thought I would share the idea before moving forward, as always, feedback is appreciated :-) ------------- Commit messages: - revert changes to JdkAttributes.TOTAL_ALLOCATION_SIZE - style - tests opt out of ObjectAllocationSample throttling - reset baseline - coverage for autoboxing - style - scale by min weight - docs and style - Attempt to use allocaiton sample events in allocation rules - spotless - ... and 1 more: https://git.openjdk.org/jmc/compare/719b7142...9f2e7c02 Changes: https://git.openjdk.org/jmc/pull/579/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=579&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8249 Stats: 449 lines in 6 files changed: 418 ins; 15 del; 16 mod Patch: https://git.openjdk.org/jmc/pull/579.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/579/head:pull/579 PR: https://git.openjdk.org/jmc/pull/579 From duke at openjdk.org Fri Aug 30 19:19:53 2024 From: duke at openjdk.org (Carter Kozak) Date: Fri, 30 Aug 2024 19:19:53 GMT Subject: RFR: 8249: Add support for the new allocation profiler in rules In-Reply-To: <8KiZNsF0w78cDxPtWi0lubrws9yWEaTHmXKpV4PC5rc=.49391215-860c-4da1-83c6-5f3bbc2e9da8@github.com> References: <8KiZNsF0w78cDxPtWi0lubrws9yWEaTHmXKpV4PC5rc=.49391215-860c-4da1-83c6-5f3bbc2e9da8@github.com> Message-ID: On Thu, 22 Aug 2024 20:50:58 GMT, Carter Kozak wrote: > ## Allocation Rules may use ObjectAllocationSample > > The allocation profiling rules (`AllocationByClassRule`, `AllocationByThreadRule`, `AutoBoxingRule`) were developed prior to the introduction of the newer and less invasive ObjectAllocationSample event. I've updated these rules to prefer the more precise events, but when those are unavailable, use the new ObjectAllocationSample events instead. This proved a bit tricky because the rules are scored based on number of events sampled, where the new events may not be emitted for every tlab based on a rate limit, so we must take into account the sample weight and estimate the number of samples as best we can. > > The `IRule#getRequiredEvents` API doesn't provide a way to declare _either_ dependencies, so I opted to remove the dependencies in favor of a similar check in the `getResult` implementation. > > ## JfrGenerator Utility > > The idea is to provide java sources with code that violates rules. We compile and execute the input sources while capturing a JFR, and execute rules against the results to verify they work as expected. > > I like having the input sources available in the test rather than only a JFR recording, because it's not clear whether most JDKs will still create the given recording, or with what configuration. However, the trade-off is that we're only testing against the JVM used to run tests, which represents a subset of all supported versions. > This type of test must also compile and execute small Java programs, which is more expensive than executing against an existing recording, and may be more likely to flake if we're not careful. > > Anyhow, I thought I would share the idea before moving forward, as always, feedback is appreciated :-) core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java line 583: > 581: return JdkAttributes.ALLOCATION_SIZE.getAccessor(type); > 582: } else if (type.getIdentifier().equals(JdkTypeIDs.OBJ_ALLOC_SAMPLE)) { > 583: return JdkAttributes.SAMPLE_WEIGHT.getAccessor(type); I'm going to revert this piece and branch on whether we expect ObjectAllocationSample events -- I initially audited uses within `core`, however I missed some places in the UI that would likely have slightly different behavior. I suspect it would be generally helpful to include sample weight in this attribute, but if we make that change, I'd prefer to do it in isolation from this enhancement. core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/main/java/org/openjdk/jmc/flightrecorder/test/rules/jdk/TestRulesWithJfr.java line 270: > 268: StreamResult console = new StreamResult(os); > 269: transformer.transform(source, console); > 270: } catch (TransformerException e) { I added this test to the `TestRulesWithJfr.java` class to reuse `generateReport` without a large diff -- if we move forward with this approach, it may make sense to share the rule report utility functionality ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/579#discussion_r1739294264 PR Review Comment: https://git.openjdk.org/jmc/pull/579#discussion_r1727799033