From schaturvedi at openjdk.org Wed Jul 5 05:07:06 2023 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 5 Jul 2023 05:07:06 GMT Subject: Withdrawn: 7248: JMC7/8 Automated Analysis taking very long time to produce results for Class Leak Rule. In-Reply-To: References: Message-ID: On Tue, 11 May 2021 22:35:08 GMT, Suchita Chaturvedi wrote: > This PR addresses the optimization of Class Leak Rule. > > Please refer the JBS for the sample JFR which was taking ~90 minutes to generate results for Class Leak Rule. After the optimization time is reduced to ~10-15 minutes. > > Please review the change and let me the know if there are any comments / suggestions. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jmc/pull/248 From aptmac at openjdk.org Wed Jul 5 20:14:01 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 5 Jul 2023 20:14:01 GMT Subject: RFR: 8098: Remove obsolete checkformatting step in GHA In-Reply-To: References: Message-ID: <5eDikmbgGQwhSVeBPO1zSk3Hjo748kojwatH90Lhduo=.fc7298db-047f-4001-984a-03ae0d79ede3@github.com> On Thu, 29 Jun 2023 16:16:52 GMT, Christoph Langer wrote: > spotless is integrated into the standard JMC build workflow now. So we can skip the separate checkformatting step in GHA. > > I also fixed indentation in updatecopyrightyear.sh. I think this should be okay. I was a bit back and forth on the removal of spotless checks for the uitests, but they aren't run in the GH CI and are very infrequently built upon anyways. In the event of new uitests the reviewers would have to run the tests locally anyways, so any spotless checks would be flagged then. ------------- PR Comment: https://git.openjdk.org/jmc/pull/504#issuecomment-1622429272 From aptmac at openjdk.org Wed Jul 5 20:19:03 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 5 Jul 2023 20:19:03 GMT Subject: RFR: 8098: Remove obsolete checkformatting step in GHA In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 16:16:52 GMT, Christoph Langer wrote: > spotless is integrated into the standard JMC build workflow now. So we can skip the separate checkformatting step in GHA. > > I also fixed indentation in updatecopyrightyear.sh. Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/504#pullrequestreview-1515293200 From clanger at openjdk.org Wed Jul 5 20:42:05 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 5 Jul 2023 20:42:05 GMT Subject: RFR: 8098: Remove obsolete checkformatting step in GHA In-Reply-To: <5eDikmbgGQwhSVeBPO1zSk3Hjo748kojwatH90Lhduo=.fc7298db-047f-4001-984a-03ae0d79ede3@github.com> References: <5eDikmbgGQwhSVeBPO1zSk3Hjo748kojwatH90Lhduo=.fc7298db-047f-4001-984a-03ae0d79ede3@github.com> Message-ID: On Wed, 5 Jul 2023 20:11:08 GMT, Alex Macdonald wrote: > I think this should be okay. I was a bit back and forth on the removal of spotless checks for the uitests, but they aren't run in the GH CI and are very infrequently built upon anyways. In the event of new uitests the reviewers would have to run the tests locally anyways, so any spotless checks would be flagged then. Ah, good point, I wasn't really aware. But anyway, those who run uitests will hit spotless then. And we should probably strive to include the uitests in GHA if possible. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jmc/pull/504#issuecomment-1622467217 From clanger at openjdk.org Thu Jul 6 06:09:00 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 6 Jul 2023 06:09:00 GMT Subject: Integrated: 8098: Remove obsolete checkformatting step in GHA In-Reply-To: References: Message-ID: On Thu, 29 Jun 2023 16:16:52 GMT, Christoph Langer wrote: > spotless is integrated into the standard JMC build workflow now. So we can skip the separate checkformatting step in GHA. > > I also fixed indentation in updatecopyrightyear.sh. This pull request has now been integrated. Changeset: 9f430af5 Author: Christoph Langer URL: https://git.openjdk.org/jmc/commit/9f430af53249b817b69b77ca5c78cb5f266b4453 Stats: 45 lines in 4 files changed: 0 ins; 27 del; 18 mod 8098: Remove obsolete checkformatting step in GHA Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/504 From aptmac at openjdk.org Fri Jul 14 01:30:24 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 14 Jul 2023 01:30:24 GMT Subject: RFR: 7441: JVM System information tables do not scroll horizontally Message-ID: This PR addresses JMC-7441 [[0]](https://bugs.openjdk.org/browse/JMC-7441), in which the tables on the System tab in the JVM Browser don't scroll horizontally. While looking into this I noticed it affects many more tables, potentially most notable would be the automated analysis report ui, but that should be taken care of in a separate ticket. The problem is that the column sizes aren't being set appropriately to the contents of the table. This affects the tables initialized with `SWT.VIRTUAL`, because these are lazy loaded and are not always fully filled out when it's time for the table to paint. I was playing around with an idea of adding a listener on the `SWT.Paint` event and having the columns re-sized in an attempt to keep these as virtual tables, but the initial re-paint was jarring visually. Also it might not make sense for (some of) these tables to be virtual; they don't contain a large amount of information and/or aren't mutable. For the sake of the JVM Browser System tab tables, I just made these tables non-virtual and added a column packing function to the ColumnManager. The result is now the entire contents can be viewed in the table. [0] https://bugs.openjdk.org/browse/JMC-7441 ------------- Commit messages: - 7441: JVM System information tables do not scroll horizontally Changes: https://git.openjdk.org/jmc/pull/505/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=505&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7441 Stats: 15 lines in 3 files changed: 8 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jmc/pull/505.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/505/head:pull/505 PR: https://git.openjdk.org/jmc/pull/505 From hirt at openjdk.org Fri Jul 14 11:35:06 2023 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 14 Jul 2023 11:35:06 GMT Subject: RFR: 7441: JVM System information tables do not scroll horizontally In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 01:24:18 GMT, Alex Macdonald wrote: > This PR addresses JMC-7441 [[0]](https://bugs.openjdk.org/browse/JMC-7441), in which the tables on the System tab in the JVM Browser don't scroll horizontally (very well). > > While looking into this I noticed it affects many more tables, potentially most notable would be the automated analysis report ui, but that should be taken care of in a separate ticket. > > The problem is that the column sizes aren't being set appropriately to the contents of the table. This affects the tables initialized with `SWT.VIRTUAL`, because these are lazy loaded and are not always fully filled out when it's time for the table to paint. I was playing around with an idea of adding a listener on the `SWT.Paint` event and having the columns re-sized in an attempt to keep these as virtual tables, but the initial re-paint was jarring visually. Also it might not make sense for (some of) these tables to be virtual; they don't contain a large amount of information and/or aren't mutable. > > For the sake of the JVM Browser System tab tables, I just made these tables non-virtual and added a column packing function to the ColumnManager. The result is now the entire contents can be viewed in the table. > > [0] https://bugs.openjdk.org/browse/JMC-7441 Marked as reviewed by hirt (Lead). ------------- PR Review: https://git.openjdk.org/jmc/pull/505#pullrequestreview-1530135396 From aptmac at openjdk.org Fri Jul 14 12:56:07 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 14 Jul 2023 12:56:07 GMT Subject: Integrated: 7441: JVM System information tables do not scroll horizontally In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 01:24:18 GMT, Alex Macdonald wrote: > This PR addresses JMC-7441 [[0]](https://bugs.openjdk.org/browse/JMC-7441), in which the tables on the System tab in the JVM Browser don't scroll horizontally (very well). > > While looking into this I noticed it affects many more tables, potentially most notable would be the automated analysis report ui, but that should be taken care of in a separate ticket. > > The problem is that the column sizes aren't being set appropriately to the contents of the table. This affects the tables initialized with `SWT.VIRTUAL`, because these are lazy loaded and are not always fully filled out when it's time for the table to paint. I was playing around with an idea of adding a listener on the `SWT.Paint` event and having the columns re-sized in an attempt to keep these as virtual tables, but the initial re-paint was jarring visually. Also it might not make sense for (some of) these tables to be virtual; they don't contain a large amount of information and/or aren't mutable. > > For the sake of the JVM Browser System tab tables, I just made these tables non-virtual and added a column packing function to the ColumnManager. The result is now the entire contents can be viewed in the table. > > [0] https://bugs.openjdk.org/browse/JMC-7441 This pull request has now been integrated. Changeset: eceb2792 Author: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/eceb2792dac7c686ca499d634184adda1e49c0d0 Stats: 15 lines in 3 files changed: 8 ins; 2 del; 5 mod 7441: JVM System information tables do not scroll horizontally Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/505 From aptmac at openjdk.org Fri Jul 14 14:19:25 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 14 Jul 2023 14:19:25 GMT Subject: RFR: 8101: Add ignore icon to automated analysis table Message-ID: This short PR addresses JMC-8108 [[0]](https://bugs.openjdk.org/browse/JMC-8101), in which there is no icon for "Ignore" rules in the automated analysis page table. Here there's just a new case added to the switch statement that assigns icons for the table. Before: ![Screenshot from 2023-07-13 16-57-04](https://github.com/openjdk/jmc/assets/10425301/9bce381d-ee04-4b91-b5fb-4fb103828016) After: ![Screenshot from 2023-07-13 23-03-55](https://github.com/openjdk/jmc/assets/10425301/62f0b2d4-5d0e-48a6-81ce-4b0c174cdd21) [0] https://bugs.openjdk.org/browse/JMC-8101 ------------- Commit messages: - 8101: Add ignore icon to automated analysis table Changes: https://git.openjdk.org/jmc/pull/506/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=506&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8101 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/506.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/506/head:pull/506 PR: https://git.openjdk.org/jmc/pull/506 From schaturvedi at openjdk.org Fri Jul 14 21:41:06 2023 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Fri, 14 Jul 2023 21:41:06 GMT Subject: RFR: 8101: Add ignore icon to automated analysis table In-Reply-To: References: Message-ID: <_0jXW21pfYvUm_Lt4U08uheN93LWIdRIIX-I23RQZfU=.e9245a30-c46b-42cc-bf2b-224b2cf2c6d6@github.com> On Fri, 14 Jul 2023 14:14:04 GMT, Alex Macdonald wrote: > This short PR addresses JMC-8108 [[0]](https://bugs.openjdk.org/browse/JMC-8101), in which there is no icon for "Ignore" rules in the automated analysis page table. Here there's just a new case added to the switch statement that assigns icons for the table. > > Before: > ![Screenshot from 2023-07-13 16-57-04](https://github.com/openjdk/jmc/assets/10425301/9bce381d-ee04-4b91-b5fb-4fb103828016) > > After: > ![Screenshot from 2023-07-13 23-03-55](https://github.com/openjdk/jmc/assets/10425301/62f0b2d4-5d0e-48a6-81ce-4b0c174cdd21) > > [0] https://bugs.openjdk.org/browse/JMC-8101 Looks good to me. ------------- Marked as reviewed by schaturvedi (Committer). PR Review: https://git.openjdk.org/jmc/pull/506#pullrequestreview-1531077038 From vpurnam at openjdk.org Sat Jul 15 05:13:05 2023 From: vpurnam at openjdk.org (Virag Purnam) Date: Sat, 15 Jul 2023 05:13:05 GMT Subject: RFR: 8101: Add ignore icon to automated analysis table In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 14:14:04 GMT, Alex Macdonald wrote: > This short PR addresses JMC-8108 [[0]](https://bugs.openjdk.org/browse/JMC-8101), in which there is no icon for "Ignore" rules in the automated analysis page table. Here there's just a new case added to the switch statement that assigns icons for the table. > > Before: > ![Screenshot from 2023-07-13 16-57-04](https://github.com/openjdk/jmc/assets/10425301/9bce381d-ee04-4b91-b5fb-4fb103828016) > > After: > ![Screenshot from 2023-07-13 23-03-55](https://github.com/openjdk/jmc/assets/10425301/62f0b2d4-5d0e-48a6-81ce-4b0c174cdd21) > > [0] https://bugs.openjdk.org/browse/JMC-8101 Marked as reviewed by vpurnam (Committer). ------------- PR Review: https://git.openjdk.org/jmc/pull/506#pullrequestreview-1531283536 From aptmac at openjdk.org Sat Jul 15 13:24:06 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Sat, 15 Jul 2023 13:24:06 GMT Subject: Integrated: 8101: Add ignore icon to automated analysis table In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 14:14:04 GMT, Alex Macdonald wrote: > This short PR addresses JMC-8108 [[0]](https://bugs.openjdk.org/browse/JMC-8101), in which there is no icon for "Ignore" rules in the automated analysis page table. Here there's just a new case added to the switch statement that assigns icons for the table. > > Before: > ![Screenshot from 2023-07-13 16-57-04](https://github.com/openjdk/jmc/assets/10425301/9bce381d-ee04-4b91-b5fb-4fb103828016) > > After: > ![Screenshot from 2023-07-13 23-03-55](https://github.com/openjdk/jmc/assets/10425301/62f0b2d4-5d0e-48a6-81ce-4b0c174cdd21) > > [0] https://bugs.openjdk.org/browse/JMC-8101 This pull request has now been integrated. Changeset: 952fb0df Author: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/952fb0df2afd1bed63f99f175506b21968a55666 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8101: Add ignore icon to automated analysis table Reviewed-by: schaturvedi, vpurnam ------------- PR: https://git.openjdk.org/jmc/pull/506 From vpurnam at openjdk.org Tue Jul 18 16:48:31 2023 From: vpurnam at openjdk.org (Virag Purnam) Date: Tue, 18 Jul 2023 16:48:31 GMT Subject: RFR: 8102: Automated analysis page does not expand the results for Windows Message-ID: To fix the bug https://bugs.openjdk.org/browse/JMC-8073, **rules_overview.html** had been modified and **.includes()** method was added. But this method does not work with all browsers e.g IE. On windows Automated analysis page does not expand the results. Fix: I have replaced all **.includes()** with widely supported **.indexOf()**. e.g ` e.id.includes("_name") `has been replaced with` e.id.indexOf("_name") !== -1` With this change it works in all platforms. ------------- Commit messages: - 8102: Automated analysis page does not expand the results for Windows Changes: https://git.openjdk.org/jmc/pull/507/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=507&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8102 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jmc/pull/507.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/507/head:pull/507 PR: https://git.openjdk.org/jmc/pull/507 From vpurnam at openjdk.org Tue Jul 18 16:58:04 2023 From: vpurnam at openjdk.org (Virag Purnam) Date: Tue, 18 Jul 2023 16:58:04 GMT Subject: RFR: 8102: Automated analysis page does not expand the results for Windows In-Reply-To: References: Message-ID: <_rwwDIlywFx7Jy637_tTozb-ubKE63vvwUgCafPvnK4=.453de53a-c339-430e-9d38-dc277b67dd4a@github.com> On Tue, 18 Jul 2023 16:42:24 GMT, Virag Purnam wrote: > To fix the bug https://bugs.openjdk.org/browse/JMC-8073, **rules_overview.html** had been modified and **.includes()** method was added. But this method does not work with all browsers e.g IE. On windows Automated analysis page does not expand the results. > > Fix: I have replaced all **.includes()** with widely supported **.indexOf()**. > e.g ` e.id.includes("_name") `has been replaced with` e.id.indexOf("_name") !== -1` > > With this change it works in all platforms. Hi @aptmac, could you please review the changes? With this fix rule result html pages expansion and collapsing of individual rule results works for windows as well. .includes() method is not supported by IE. ------------- PR Comment: https://git.openjdk.org/jmc/pull/507#issuecomment-1640594806 From aptmac at openjdk.org Tue Jul 18 16:58:05 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 18 Jul 2023 16:58:05 GMT Subject: RFR: 8102: Automated analysis page does not expand the results for Windows In-Reply-To: <_rwwDIlywFx7Jy637_tTozb-ubKE63vvwUgCafPvnK4=.453de53a-c339-430e-9d38-dc277b67dd4a@github.com> References: <_rwwDIlywFx7Jy637_tTozb-ubKE63vvwUgCafPvnK4=.453de53a-c339-430e-9d38-dc277b67dd4a@github.com> Message-ID: On Tue, 18 Jul 2023 16:53:46 GMT, Virag Purnam wrote: >> To fix the bug https://bugs.openjdk.org/browse/JMC-8073, **rules_overview.html** had been modified and **.includes()** method was added. But this method does not work with all browsers e.g IE. On windows Automated analysis page does not expand the results. >> >> Fix: I have replaced all **.includes()** with widely supported **.indexOf()**. >> e.g ` e.id.includes("_name") `has been replaced with` e.id.indexOf("_name") !== -1` >> >> With this change it works in all platforms. > > Hi @aptmac, could you please review the changes? With this fix rule result html pages expansion and collapsing of individual rule results works for windows as well. .includes() method is not supported by IE. @viragpurnam I've got a couple of builds hogging my local jmc repo at the moment, but I'll be able to take a look later this afternoon. I trust the code works, just would like to see it myself before I hit approve. ------------- PR Comment: https://git.openjdk.org/jmc/pull/507#issuecomment-1640599564 From aptmac at openjdk.org Tue Jul 18 17:45:03 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 18 Jul 2023 17:45:03 GMT Subject: RFR: 8102: Automated analysis page does not expand the results for Windows In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 16:42:24 GMT, Virag Purnam wrote: > To fix the bug https://bugs.openjdk.org/browse/JMC-8073, **rules_overview.html** had been modified and **.includes()** method was added. But this method does not work with all browsers e.g IE. On windows Automated analysis page does not expand the results. > > Fix: I have replaced all **.includes()** with widely supported **.indexOf()**. > e.g ` e.id.includes("_name") `has been replaced with` e.id.indexOf("_name") !== -1` > > With this change it works in all platforms. lgtm ------------- Marked as reviewed by aptmac (Reviewer). PR Review: https://git.openjdk.org/jmc/pull/507#pullrequestreview-1535601284 From vpurnam at openjdk.org Wed Jul 19 04:48:46 2023 From: vpurnam at openjdk.org (Virag Purnam) Date: Wed, 19 Jul 2023 04:48:46 GMT Subject: RFR: 8102: Automated analysis page does not expand the results for Windows In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 17:42:25 GMT, Alex Macdonald wrote: > lgtm Thanks. ------------- PR Comment: https://git.openjdk.org/jmc/pull/507#issuecomment-1641403326 From vpurnam at openjdk.org Wed Jul 19 17:45:48 2023 From: vpurnam at openjdk.org (Virag Purnam) Date: Wed, 19 Jul 2023 17:45:48 GMT Subject: Integrated: 8102: Automated analysis page does not expand the results for Windows In-Reply-To: References: Message-ID: <6eU2sabYH0FSlv5bWu3moPi0XJkfcqpEwoeuD1qBozc=.bdc93f22-91eb-4f2d-a96b-dce0c91fed90@github.com> On Tue, 18 Jul 2023 16:42:24 GMT, Virag Purnam wrote: > To fix the bug https://bugs.openjdk.org/browse/JMC-8073, **rules_overview.html** had been modified and **.includes()** method was added. But this method does not work with all browsers e.g IE. On windows Automated analysis page does not expand the results. > > Fix: I have replaced all **.includes()** with widely supported **.indexOf()**. > e.g ` e.id.includes("_name") `has been replaced with` e.id.indexOf("_name") !== -1` > > With this change it works in all platforms. This pull request has now been integrated. Changeset: 70e4f731 Author: Virag Purnam URL: https://git.openjdk.org/jmc/commit/70e4f731495f08c066e9dc548c02a58b844138f6 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8102: Automated analysis page does not expand the results for Windows Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/507 From aptmac at openjdk.org Thu Jul 20 14:03:15 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 20 Jul 2023 14:03:15 GMT Subject: RFR: 8103: Add user configuration for local JVM refresh interval Message-ID: This PR addresses JMC-8103 [[0]](https://bugs.openjdk.org/browse/JMC-8103), in which it would be nice to have a user control for adjusting the rate at which the JVM browser discovers JVMs. At the moment, the `LocalDescriptorProvider` scans every 5s for differences in local JVMs, and then goes through the process of creating a local descriptor, attaching, populating the jvm browser, etc. This PR adds an extra field to the Preferences under `Preferences -> JVM Browser -> Local` that lets the user specify how frequently (or infrequently) this scan should occur. As mentioned at the latest upstream community meeting, this value should probably have a lower-bound as to not scan too often, so I've selected 1000 ms to match similar refresh rates of the jvm browser. ![example](https://github.com/openjdk/jmc/assets/10425301/4dbe363f-a3d4-4513-9654-f99cfe71aaeb) [0] https://bugs.openjdk.org/browse/JMC-8103 ------------- Commit messages: - 8103: Add user configuration for local JVM refresh interval Changes: https://git.openjdk.org/jmc/pull/508/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=508&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8103 Stats: 45 lines in 6 files changed: 37 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jmc/pull/508.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/508/head:pull/508 PR: https://git.openjdk.org/jmc/pull/508 From hirt at openjdk.org Fri Jul 21 22:23:48 2023 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 21 Jul 2023 22:23:48 GMT Subject: RFR: 8103: Add user configuration for local JVM refresh interval In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 13:56:07 GMT, Alex Macdonald wrote: > This PR addresses JMC-8103 [[0]](https://bugs.openjdk.org/browse/JMC-8103), in which it would be nice to have a user control for adjusting the rate at which the JVM browser discovers JVMs. > > At the moment, the `LocalDescriptorProvider` scans every 5s for differences in local JVMs, and then goes through the process of creating a local descriptor, attaching, populating the jvm browser, etc. > > This PR adds an extra field to the Preferences under `Preferences -> JVM Browser -> Local` that lets the user specify how frequently (or infrequently) this scan should occur. As mentioned at the latest upstream community meeting, this value should probably have a lower-bound as to not scan too often, so I've selected 1000 ms to match similar refresh rates of the jvm browser. > > ![example](https://github.com/openjdk/jmc/assets/10425301/4dbe363f-a3d4-4513-9654-f99cfe71aaeb) > > > [0] https://bugs.openjdk.org/browse/JMC-8103 Marked as reviewed by hirt (Lead). Thanks for the contribution Alex! :) ------------- PR Review: https://git.openjdk.org/jmc/pull/508#pullrequestreview-1541900778 PR Comment: https://git.openjdk.org/jmc/pull/508#issuecomment-1646295145 From aptmac at openjdk.org Sat Jul 22 03:05:48 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Sat, 22 Jul 2023 03:05:48 GMT Subject: Integrated: 8103: Add user configuration for local JVM refresh interval In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 13:56:07 GMT, Alex Macdonald wrote: > This PR addresses JMC-8103 [[0]](https://bugs.openjdk.org/browse/JMC-8103), in which it would be nice to have a user control for adjusting the rate at which the JVM browser discovers JVMs. > > At the moment, the `LocalDescriptorProvider` scans every 5s for differences in local JVMs, and then goes through the process of creating a local descriptor, attaching, populating the jvm browser, etc. > > This PR adds an extra field to the Preferences under `Preferences -> JVM Browser -> Local` that lets the user specify how frequently (or infrequently) this scan should occur. As mentioned at the latest upstream community meeting, this value should probably have a lower-bound as to not scan too often, so I've selected 1000 ms to match similar refresh rates of the jvm browser. > > ![example](https://github.com/openjdk/jmc/assets/10425301/4dbe363f-a3d4-4513-9654-f99cfe71aaeb) > > > [0] https://bugs.openjdk.org/browse/JMC-8103 This pull request has now been integrated. Changeset: 688729fe Author: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/688729fe3852705a375739c1ff56b03b82a98741 Stats: 45 lines in 6 files changed: 37 ins; 1 del; 7 mod 8103: Add user configuration for local JVM refresh interval Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/508 From duke at openjdk.org Wed Jul 26 18:28:07 2023 From: duke at openjdk.org (Vincent Beelte) Date: Wed, 26 Jul 2023 18:28:07 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again Message-ID: One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. It looks to my like the issue is that the event groups must have chaged from when the test was written. Here is what that looks like currently for me on Windows with a jdk 17.0.7 ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into wizard_test - Merge remote-tracking branch 'origin/master' into wizard_test - improve test setup of JfrWizardTest.verifyMinimalRecordingEventSettings Changes: https://git.openjdk.org/jmc/pull/509/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=509&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8113 Stats: 32 lines in 2 files changed: 26 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/509.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/509/head:pull/509 PR: https://git.openjdk.org/jmc/pull/509 From aptmac at openjdk.org Wed Jul 26 18:28:07 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 26 Jul 2023 18:28:07 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 04:08:04 GMT, Vincent Beelte wrote: > One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. > > It looks to my like the issue is that the event groups must have chaged from when the test was written. > Here is what that looks like currently for me on Windows with a jdk 17.0.7 > ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) > The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. > > I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. Looks good to me, thanks for taking the time to look into this. I've opened an issue on jira that you can use for this PR: https://bugs.openjdk.org/browse/JMC-8113 ------------- PR Comment: https://git.openjdk.org/jmc/pull/509#issuecomment-1652237903 From duke at openjdk.org Wed Jul 26 18:28:07 2023 From: duke at openjdk.org (Vincent Beelte) Date: Wed, 26 Jul 2023 18:28:07 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: <-fGczzZFxBB9Ejcj2AzxUIkw4w12amZz20zJ-CVcQW8=.3b25f3b3-9789-471e-ba47-9a0bb00be173@github.com> On Tue, 25 Jul 2023 04:08:04 GMT, Vincent Beelte wrote: > One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. > > It looks to my like the issue is that the event groups must have chaged from when the test was written. > Here is what that looks like currently for me on Windows with a jdk 17.0.7 > ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) > The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. > > I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. The wiki seems to be offline but I assume I can do something like this to add the issue ------------- PR Comment: https://git.openjdk.org/jmc/pull/509#issuecomment-1652291793 From aptmac at openjdk.org Wed Jul 26 18:46:45 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 26 Jul 2023 18:46:45 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 04:08:04 GMT, Vincent Beelte wrote: > One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. > > It looks to my like the issue is that the event groups must have chaged from when the test was written. > Here is what that looks like currently for me on Windows with a jdk 17.0.7 > ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) > The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. > > I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/509#pullrequestreview-1548384906 From clanger at openjdk.org Thu Jul 27 10:34:47 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 10:34:47 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 04:08:04 GMT, Vincent Alexander Beelte wrote: > One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. > > It looks to my like the issue is that the event groups must have chaged from when the test was written. > Here is what that looks like currently for me on Windows with a jdk 17.0.7 > ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) > The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. > > I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. Some style comments. Please also update copyright years. application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 465: > 463: final var eventSettingsTree = getEventSettingsTree(); > 464: final var names = eventSettingsTree.getAllItemTexts(); > 465: for (var name : names) { You could simply do `for (var name : getEventSettingsTree().getAllItemTexts()) {` here application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 467: > 465: for (var name : names) { > 466: final var currentPath = name.toArray(String[]::new); > 467: setEventSetting(!desiredState, settingName, currentPath); Also here: `setEventSetting(!desiredState, settingName, name.toArray(String[]::new));` application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 469: > 467: setEventSetting(!desiredState, settingName, currentPath); > 468: } > 469: } Why are you using these additional block braces here? ------------- PR Review: https://git.openjdk.org/jmc/pull/509#pullrequestreview-1549533091 PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276085468 PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276087078 PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276084661 From duke at openjdk.org Thu Jul 27 12:58:50 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 12:58:50 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: <1YCTW-1cDrzHE8NFJzMl24ye80xMCTNcbIjptGoFhIY=.82e383db-f852-419b-9b84-97bf5d22ad95@github.com> On Thu, 27 Jul 2023 10:30:21 GMT, Christoph Langer wrote: >> One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. >> >> It looks to my like the issue is that the event groups must have chaged from when the test was written. >> Here is what that looks like currently for me on Windows with a jdk 17.0.7 >> ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) >> The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. >> >> I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. > > application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 465: > >> 463: final var eventSettingsTree = getEventSettingsTree(); >> 464: final var names = eventSettingsTree.getAllItemTexts(); >> 465: for (var name : names) { > > You could simply do `for (var name : getEventSettingsTree().getAllItemTexts()) {` here Yes I know. There was a version of this where I first also used the eventSettingsTree to select the path. But I removed that because it turned out to not be needed. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276243367 From duke at openjdk.org Thu Jul 27 13:01:49 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 13:01:49 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 10:31:13 GMT, Christoph Langer wrote: >> One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. >> >> It looks to my like the issue is that the event groups must have chaged from when the test was written. >> Here is what that looks like currently for me on Windows with a jdk 17.0.7 >> ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) >> The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. >> >> I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. > > application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 467: > >> 465: for (var name : names) { >> 466: final var currentPath = name.toArray(String[]::new); >> 467: setEventSetting(!desiredState, settingName, currentPath); > > Also here: `setEventSetting(!desiredState, settingName, name.toArray(String[]::new));` I mean yes but I would question that it is clearly "better". ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276246298 From duke at openjdk.org Thu Jul 27 13:04:47 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 13:04:47 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 10:29:27 GMT, Christoph Langer wrote: >> One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. >> >> It looks to my like the issue is that the event groups must have chaged from when the test was written. >> Here is what that looks like currently for me on Windows with a jdk 17.0.7 >> ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) >> The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. >> >> I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. > > application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 469: > >> 467: setEventSetting(!desiredState, settingName, currentPath); >> 468: } >> 469: } > > Why are you using these additional block braces here? The block delimits the part that deals with inverting everything before setting the actual path to the desired value. I wanted to give it more structure than just writing it inline but I also felt it is overkill to extract that part into another method. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276250188 From duke at openjdk.org Thu Jul 27 13:11:24 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 13:11:24 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again [v2] In-Reply-To: References: Message-ID: > One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. > > It looks to my like the issue is that the event groups must have chaged from when the test was written. > Here is what that looks like currently for me on Windows with a jdk 17.0.7 > ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) > The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. > > I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: add 2023 to copyright headers ------------- Changes: - all: https://git.openjdk.org/jmc/pull/509/files - new: https://git.openjdk.org/jmc/pull/509/files/d4c1e145..1cf39e0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=509&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=509&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jmc/pull/509.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/509/head:pull/509 PR: https://git.openjdk.org/jmc/pull/509 From duke at openjdk.org Thu Jul 27 13:15:50 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 13:15:50 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 13:11:24 GMT, Vincent Alexander Beelte wrote: >> One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. >> >> It looks to my like the issue is that the event groups must have chaged from when the test was written. >> Here is what that looks like currently for me on Windows with a jdk 17.0.7 >> ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) >> The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. >> >> I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. > > Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: > > add 2023 to copyright headers I am not quite sure if updating the copyright years is done manually but for just now I just added 2023 like I saw it done in one of the other pull requests here. ------------- PR Comment: https://git.openjdk.org/jmc/pull/509#issuecomment-1653604577 From duke at openjdk.org Thu Jul 27 13:18:50 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 13:18:50 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again [v2] In-Reply-To: <1YCTW-1cDrzHE8NFJzMl24ye80xMCTNcbIjptGoFhIY=.82e383db-f852-419b-9b84-97bf5d22ad95@github.com> References: <1YCTW-1cDrzHE8NFJzMl24ye80xMCTNcbIjptGoFhIY=.82e383db-f852-419b-9b84-97bf5d22ad95@github.com> Message-ID: <4FA7EVY0htD7f8RsjXLSAyI1PeseN_1eoMAw3LOAxWY=.95068714-f5d1-42fb-a1d9-b1b92eb7f189@github.com> On Thu, 27 Jul 2023 12:56:29 GMT, Vincent Alexander Beelte wrote: >> application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 465: >> >>> 463: final var eventSettingsTree = getEventSettingsTree(); >>> 464: final var names = eventSettingsTree.getAllItemTexts(); >>> 465: for (var name : names) { >> >> You could simply do `for (var name : getEventSettingsTree().getAllItemTexts()) {` here > > Yes I know. There was a version of this where I first also used the eventSettingsTree to select the path. But I removed that because it turned out to not be needed. other than that I really struggle to find a reason to do it one way or the other, other than someone saying "no really, please do it this way" :) ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276267418 From clanger at openjdk.org Thu Jul 27 13:48:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 13:48:49 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 13:11:24 GMT, Vincent Alexander Beelte wrote: >> One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. >> >> It looks to my like the issue is that the event groups must have chaged from when the test was written. >> Here is what that looks like currently for me on Windows with a jdk 17.0.7 >> ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) >> The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. >> >> I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. > > Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: > > add 2023 to copyright headers Copyright years update is correct, so from my end good to go, too. ------------- Marked as reviewed by clanger (Committer). PR Review: https://git.openjdk.org/jmc/pull/509#pullrequestreview-1549885982 From clanger at openjdk.org Thu Jul 27 13:48:50 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 13:48:50 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again [v2] In-Reply-To: <4FA7EVY0htD7f8RsjXLSAyI1PeseN_1eoMAw3LOAxWY=.95068714-f5d1-42fb-a1d9-b1b92eb7f189@github.com> References: <1YCTW-1cDrzHE8NFJzMl24ye80xMCTNcbIjptGoFhIY=.82e383db-f852-419b-9b84-97bf5d22ad95@github.com> <4FA7EVY0htD7f8RsjXLSAyI1PeseN_1eoMAw3LOAxWY=.95068714-f5d1-42fb-a1d9-b1b92eb7f189@github.com> Message-ID: On Thu, 27 Jul 2023 13:16:23 GMT, Vincent Alexander Beelte wrote: >> Yes I know. There was a version of this where I first also used the eventSettingsTree to select the path. But I removed that because it turned out to not be needed. > > other than that I really struggle to find a reason to do it one way or the other, other than someone saying "no really, please do it this way" :) Sure, it's a matter of taste. :) ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276303028 From clanger at openjdk.org Thu Jul 27 13:48:53 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 13:48:53 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 13:02:10 GMT, Vincent Alexander Beelte wrote: >> application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java line 469: >> >>> 467: setEventSetting(!desiredState, settingName, currentPath); >>> 468: } >>> 469: } >> >> Why are you using these additional block braces here? > > The block delimits the part that deals with inverting everything before setting the actual path to the desired value. I wanted to give it more structure than just writing it inline but I also felt it is overkill to extract that part into another method. OK, I personally don't like the block but again, matter of taste. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/509#discussion_r1276306276 From duke at openjdk.org Thu Jul 27 14:00:53 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 14:00:53 GMT Subject: RFR: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again [v2] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 13:11:24 GMT, Vincent Alexander Beelte wrote: >> One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. >> >> It looks to my like the issue is that the event groups must have chaged from when the test was written. >> Here is what that looks like currently for me on Windows with a jdk 17.0.7 >> ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) >> The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. >> >> I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. > > Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: > > add 2023 to copyright headers Ok so now I do another integrate command because I changed something? I think the bot would have told me but lets just try and see ------------- PR Comment: https://git.openjdk.org/jmc/pull/509#issuecomment-1653681854 From aptmac at openjdk.org Thu Jul 27 15:40:10 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 27 Jul 2023 15:40:10 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: <9FkM13ZGueg2S6-LXGygOj67Zdb1GMprYN6iyqNpHiM=.1e6f8c81-b4e8-492c-913e-0c7af5c41818@github.com> On Tue, 27 Jun 2023 16:06:45 GMT, Vincent Alexander Beelte wrote: > This pull request improves the performance of creating the model that the flame graph visualization is drawn from. > > The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. > The use case where that tends to happen to me goes as follows: > My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" > Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. > Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. > All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) > > My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. > > With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. > > When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: > ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) > This is filtered to on... Just sneaking in a couple of points while this is still fresh, I'll try to take an actual look at this some time soon. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. All in all with this specific jfr file and the current master (everything including commit [5ace151](https://github.com/openjdk/jmc/commit/5ace151b6dc00096b5b3212edfad40e86f8bcf8d)) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) This is would be a great fix, and there's already an outstanding JIRA ticket for something like this at: https://bugs.openjdk.org/browse/JMC-7080 > I was not able to run the ui tests with "mvn verify -P uitests -Dspotbugs.skip=true" maven fails for the module "org.openjdk.jmc.test.jemmy" with the message saying: "[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:3.0.4:integration-test (default-integration-test) on project org.openjdk.jmc.test.jemmy: Could not find application "org.openjdk.jmc.rcp.application.app" in the test runtime. Make sure that the test runtime includes the bundle which defines this application." This also happens on the master branch. I do not think I touched anything that would not already be failing a unitest, but if I am not mistaken contributors are expected to run them before their pull requests. So I might need some help with that. What operating system are you running on? I had encountered this last week (https://github.com/openjdk/jmc/pull/495#issuecomment-1597556556) when looking at the jmc/core refactoring PR, and from what I can tell it relates back to the commit (https://github.com/openjdk/jmc/commit/ae2fbf359aa8f7612a0d3e6f18857e08cfdfc309) to use JDK 17. I was able to reproduce this consistently on Linux, and @RealCLanger encountered this as well on Mac. I was able to run the uitests without issue on my Windows machine though, unless I had been mistakenly using an older commit. The good (?) news is that there's no flameview specific uitests to worry about verifying here, so running the uitests would be mainly to verify that these changes don't affect any of the other ui pages. Here's a jira issue that you can make reference to here for this PR: https://bugs.openjdk.org/browse/JMC-8112 ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1609940693 PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1652238680 From clanger at openjdk.org Thu Jul 27 15:40:10 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 15:40:10 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 16:06:45 GMT, Vincent Alexander Beelte wrote: > This pull request improves the performance of creating the model that the flame graph visualization is drawn from. > > The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. > The use case where that tends to happen to me goes as follows: > My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" > Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. > Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. > All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) > > My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. > > With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. > > When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: > ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) > This is filtered to on... > > I was not able to run the ui tests with "mvn verify -P uitests -Dspotbugs.skip=true" maven fails for the module "org.openjdk.jmc.test.jemmy" with the message saying: "[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:3.0.4:integration-test (default-integration-test) on project org.openjdk.jmc.test.jemmy: Could not find application "org.openjdk.jmc.rcp.application.app" in the test runtime. Make sure that the test runtime includes the bundle which defines this application." This also happens on the master branch. I do not think I touched anything that would not already be failing a unitest, but if I am not mistaken contributors are expected to run them before their pull requests. So I might need some help with that. > > What operating system are you running on? > > I had encountered this last week ([#495 (comment)](https://github.com/openjdk/jmc/pull/495#issuecomment-1597556556)) when looking at the jmc/core refactoring PR, and from what I can tell it relates back to the commit ([ae2fbf3](https://github.com/openjdk/jmc/commit/ae2fbf359aa8f7612a0d3e6f18857e08cfdfc309)) to use JDK 17. I was able to reproduce this consistently on Linux, and @RealCLanger encountered this as well on Mac. I was able to run the uitests without issue on my Windows machine though, unless I had been mistakenly using an older commit. Yes, I see this issue with the uitests and I'm looking into resolving it. In fact, that's what's holding me back from integrating #497. I will try to take a look today and then come back. As I see changes in some .classpath files etc., I would like to integrate #497 first and then see this PR getting merged. But since the oca is not yet verified I guess we still have some time anyway. ? Another hint: Please enable GitHub actions for PR verification. I think you have to turn it on here: https://github.com/grandmasterpixel/jmc/actions I integrated my project cleanup PR, please merge with master now. And I believe that I have found the root cause for the uitests failure. The explanation (workaround: use the clean target) and a fix can be found in #503. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1610853741 PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1613433944 From duke at openjdk.org Thu Jul 27 15:40:10 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 15:40:10 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements Message-ID: This pull request improves the performance of creating the model that the flame graph visualization is drawn from. The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. The use case where that tends to happen to me goes as follows: My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) This is filtered to only the threads of the flame graph threadpool and method profiling samples. It looks like a lot of the time is spend creating java.util streams and computing a node id To remove the streams I implemented StacktraceTreeModel.getOrCreateNode just using a plain old for each loop. To avoid computing the node id I moved Node.nodeId to do lazy initialization outside the constructor. (later I found that the nodeId wasn't actually used and I fully removed it) That improved my "benchmark" (me clicking filters and writing down the timing logs I added) of generating the flamegraph for all threads and all events in my 1.8 mio event file from about 28 seconds to about 4 seconds. That made the flamegraph look like this ![nostreams](https://github.com/openjdk/jmc/assets/917408/4693cb81-4fc3-4ff0-9026-a252c829cfaf) I wondered if I could get more performance if I removed the switch over an enum that seemed to add a Enum.ordinal call in FrameSeparator.getCategory but other than the code now looking a little nicer (at least to my eyes with the delegation instead of a switch) that did not do anything I could measure. I was still at 4 seconds for generating the graph for all threads and events. But given that it looked nicer and performed the same I still left it in the pull request so the final flamegraph looks like this ![end](https://github.com/openjdk/jmc/assets/917408/77ee0b04-c9a8-49b6-a243-4166b08ebc2b) Which at least to me does not contain any more obvious places other than maybe the big part of the AggregatableFrame.equals I did make one attempt of saving the Node.children as a Map but that was actually worse (about 8 seconds for the benchmark). I am guessing that is a case where the list is generally small enough that more time is lost from additionally having to compute hash codes than is gained from a better class of algorithm (or I just did it wrong ;)) I was not able to run the ui tests with "mvn verify -P uitests -Dspotbugs.skip=true" maven fails for the module "org.openjdk.jmc.test.jemmy" with the message saying: "[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:3.0.4:integration-test (default-integration-test) on project org.openjdk.jmc.test.jemmy: Could not find application "org.openjdk.jmc.rcp.application.app" in the test runtime. Make sure that the test runtime includes the bundle which defines this application." This also happens on the master branch. I do not think I touched anything that would not already be failing a unitest, but if I am not mistaken contributors are expected to run them before their pull requests. So I might need some help with that. Also there are a lot of unrelated changes in this pull request from code formatting. They come from the usual save action to format the full file and since I imported the formatter settings I do not think the formatting is wrong. I can go through and revert them if that is a problem. Some other unrelated changes are from eclipse being eclipse I assume. At least I did not intentionally touch any .project or .classpath I can revert those to if that is just something my eclipse did for my environment. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into flamegraph_performance - Merge branch 'openjdk:master' into flamegraph_performance - Merge remote-tracking branch 'origin/master' into flamegraph_performance - Merge remote-tracking branch 'origin/master' into flamegraph_performance - fix automatic missmerge - remove node id because it was unused - add a test for stop flag - document the stop flag and also check it in the inner loop. - see what happens when delegating directly to the enums - avoiding one more stream in strack trace tree model and making node id - ... and 2 more: https://git.openjdk.org/jmc/compare/688729fe...d5acdfcc Changes: https://git.openjdk.org/jmc/pull/502/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=502&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8112 Stats: 257 lines in 10 files changed: 102 ins; 50 del; 105 mod Patch: https://git.openjdk.org/jmc/pull/502.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/502/head:pull/502 PR: https://git.openjdk.org/jmc/pull/502 From duke at openjdk.org Thu Jul 27 15:40:10 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 15:40:10 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: On Wed, 28 Jun 2023 06:41:27 GMT, Christoph Langer wrote: > But since the oca is not yet verified I guess we still have some time anyway. Yes you do :) I am currently in the process of figuring out if I am in the "Individual Agreement" case or the "Company Agreement" case. > What operating system are you running on? [...] I am on Linux. If the tests work on Windows it sounds like one of those "Windows specific path or line ending is messing with the tools" problems. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1611086826 From duke at openjdk.org Thu Jul 27 15:40:10 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 15:40:10 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 16:06:45 GMT, Vincent Alexander Beelte wrote: > This pull request improves the performance of creating the model that the flame graph visualization is drawn from. > > The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. > The use case where that tends to happen to me goes as follows: > My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" > Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. > Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. > All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) > > My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. > > With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. > > When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: > ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) > This is filtered to on... merged it and "clean verify" seems to work. now the ui tests show some other strange behavior even on master which all of the following comments are about. One problem I could already fix or work around. The tests on linux seem to have issues with desktop scaling. I needed to go back to 100% from 200%. Otherwise it seems that in MCJemmyTestBase.initialize() line 91 `MC.setRecordingAnalysis(false)` the click coordinates do not seem to be computed correctly with 200% scaling. It does not seems to click the checkmark (not in the right place) and thus fails at that point. I am currently stuck at an issue where some test opens an "import connections" dialog and then inputs something like "7tmp7testExportImport2835912463012025242.xml" where the expected/asserted input is something like "/tmp/testExportImport2835912463012025242.xml". Which looks like the test driver forgot to hold shift when typing the slashes :) The tests in error for me currently are: ` ConnectionExportImportTest.testExportImport:93 ? TimeoutExpired State 'Waiting... ConnectionExportImportTest.testImportNonExistantFile:125 ? Jemmy Action 'typin... ConnectionExportImportTest.testSetMasterPassword:135 ? TimeoutExpired State 'W... CustomConnectionsTest.createNewFolder:66 ? TimeoutExpired State 'Waiting for 1... CustomConnectionsTest.editConnection:122 ? TimeoutExpired State 'Waiting for 1... CustomConnectionsTest.invalidConnection:113 ? TimeoutExpired State 'Waiting fo... CustomConnectionsTest.nestedFoldersConnections:79 ? TimeoutExpired State 'Wait... CustomConnectionsTest.renameConnection:104 ? TimeoutExpired State 'Waiting for... CustomConnectionsTest.renameFolder:72 ? TimeoutExpired State 'Waiting for 1 or... CustomConnectionsTest.validConnection:96 ? TimeoutExpired State 'Waiting for 1... ` But I am sure some of that is only because the dialog never closes. I have literally only just now tried that so I am still confident I will find what is going on there :) On the oca I will hopefully make progress this evening (german time) but I do not really expect that to be resolved even next week. I think I may have found the issue with the "7tmp7". There is a class called org.jemmy.input.DefaultCharBindingMap which looks like it is specifically taught how to type on an english and I believe swedish keyboard layout. But not (yet) a german one. edit: Also I just noticed, that's a library and not part of jmc or its own test utilities. Converted this to a draft because if I understood our opensource practices correctly there will be another new pull request be opened directly from the official accenture github account for this. As for the uitest keyboard problem I started going the path of least resistance, which seemed to be to just to set up a jmc build on my gaming pc. There I found I needed to only set the OS level keyboard layout to english for the tests to type the correct letters. Settings the OS level keyboard layout did not work on Linux so it might also be the case that I have an actual physical keyboard with english layout plugged into that pc. Did not run them in full yet though, they seemed to take a while and I did not have the time to wait for them. Ok it looks like I can proceed with this PR instead of opening a new one. I do not have a response/confirmation yet to my mail about being put on the accenture contributor list but the oca label is gone so thats a good sign I guess. I am going to attempt a "covered" command in a different comment and see if that does something. On the ui tests: I have not yet had a single run of them even on master that passed all tests. (about 5-8 runs in total) Some do not even fail in the same places from run to run. At least one of them looks like it actually can't succeed because its expectation/setup conflicts with what to me looks like a change in jdk17 maybe. I will provide specifics once I am back into it a little more. So reporting on the ui tests: I do not seem to have broken more of them. In fact I fixed one setup over in #509 But it looks like they are currently reporting actual bugs even on master. There are three tests that are currently failing regularly for me on Windows with a JDK 17.0.7 (specifically Temurin-17.0.7+7) They are ControlRecordingsTest.modifyEventPeriod, ControlRecordingsTest.modifyEventThreshold and ControlRecordingsTest.modifyRecordingEvents. ControlRecordingsTest.modifyRecordingEvents is the least likely to get a successful run. It basically never succeeds. The others are sucessfull every now and again. I clicked through the "test plan" of ControlRecordingsTest.modifyRecordingEvents manually (as in "no junit, no jemmy, just me") and I can confirm that I could reproduce the failure case. I think the details about that should be discussed elsewhere though, to not detract from the topic of this pull request. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1614451482 PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1614749649 PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1617483581 PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1644211007 PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1653863203 From aptmac at openjdk.org Thu Jul 27 15:40:10 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 27 Jul 2023 15:40:10 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 10:20:51 GMT, Vincent Alexander Beelte wrote: > merged it and "clean verify" seems to work. now the ui tests show some other strange behavior even on master which all of the following comments are about. Unfortunately the uitests are finicky on a good day, it might be better to run using `-fae` so they'll proceed even if they fail. Might give a better picture at which ones are the culprit. > I am currently stuck at an issue where some test opens an "import connections" dialog and then inputs something like "7tmp7testExportImport2835912463012025242.xml" where the expected/asserted input is something like "/tmp/testExportImport2835912463012025242.xml". Which looks like the test driver forgot to hold shift when typing the slashes :) Honestly could be something similar. A lot of times I see something where it lags for a second while typing, so if it's looking for a string like "localhost" it might have actually entered "localhooooooooost". The sad thing is that the failures seem to cascade, so if it times out looking for a dialog it can impact the subsequent tests. If you also happen to be using Wayland it might end up clicking in the wrong spots too. Good times. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1614650071 From aptmac at openjdk.org Thu Jul 27 15:59:54 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 27 Jul 2023 15:59:54 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 15:34:58 GMT, Vincent Alexander Beelte wrote: > So reporting on the ui tests: I do not seem to have broken more of them. In fact I fixed one setup over in #509 But it looks like they are currently reporting actual bugs even on master. There are three tests that are currently failing regularly for me on Windows with a JDK 17.0.7 (specifically Temurin-17.0.7+7) They are ControlRecordingsTest.modifyEventPeriod, ControlRecordingsTest.modifyEventThreshold and ControlRecordingsTest.modifyRecordingEvents. ControlRecordingsTest.modifyRecordingEvents is the least likely to get a successful run. It basically never succeeds. The others are sucessfull every now and again. I clicked through the "test plan" of ControlRecordingsTest.modifyRecordingEvents manually (as in "no junit, no jemmy, just me") and I can confirm that I could reproduce the failure case. I think the details about that should be discussed elsewhere though, to not detract from the topic of this pull request. Thanks for taking a run at the uitests, what you've written looks good to me. I can confirm I'm seeing errors at: ControlRecordingsTest.modifyEventThreshold:324 Event "Compilation" threshold value should be 5 ms but was: 1 s ControlRecordingsTest.modifyRecordingEvents:277 Event "Allocation Requiring GC" should be turned on but these will be covered by a different issue. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1653904359 From aptmac at openjdk.org Thu Jul 27 16:00:20 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 27 Jul 2023 16:00:20 GMT Subject: git: openjdk/jmc: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again Message-ID: <31df8fcd-60bd-4f97-8ff7-157c8a72804b@openjdk.org> Changeset: e0a24803 Author: Vincent Alexander Beelte Committer: Alex Macdonald Date: 2023-07-27 15:59:06 +0000 URL: https://git.openjdk.org/jmc/commit/e0a248032c2c29d107687b68a2818daf1901f460 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again Reviewed-by: aptmac, clanger ! application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/JfrWizardTest.java ! application/uitests/org.openjdk.jmc.test.jemmy/src/main/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrWizard.java From duke at openjdk.org Thu Jul 27 16:01:49 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Thu, 27 Jul 2023 16:01:49 GMT Subject: Integrated: 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again In-Reply-To: References: Message-ID: <09MiqD1CKCAJQRwPgekgPOi5ylFn6Hyg5yBIu-jo51E=.dbef1083-a1bd-44e8-a189-d50f40012fa2@github.com> On Tue, 25 Jul 2023 04:08:04 GMT, Vincent Alexander Beelte wrote: > One test I see failing all the time when I run the ui tests for my other pull requst is JfrWizardTest.verifyMinimalRecordingEventSettings. > > It looks to my like the issue is that the event groups must have chaged from when the test was written. > Here is what that looks like currently for me on Windows with a jdk 17.0.7 > ![JDK Mission Control 21 07 2023 20_13_20](https://github.com/openjdk/jmc/assets/917408/faa65318-5dd6-492b-ae2a-b5f4936a1f9d) > The Java Development Kit group is not explicitly disabled by the test and so it always fails when it tries to assert that only the "Flight Recorder">"Recording Setting" Event is enabled. > > I changed the test so that is does not need to explicitly disable other groups by name. I think even if for some reason this test failing is a result of my setup on this computer, this way is more robust to changes in the groups. This pull request has now been integrated. Changeset: e0a24803 Author: Vincent Alexander Beelte Committer: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/e0a248032c2c29d107687b68a2818daf1901f460 Stats: 34 lines in 2 files changed: 26 ins; 5 del; 3 mod 8113: Make JfrWizardTest.verifyMinimalRecordingEventSettings work again Reviewed-by: aptmac, clanger ------------- PR: https://git.openjdk.org/jmc/pull/509 From clanger at openjdk.org Fri Jul 28 06:16:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 28 Jul 2023 06:16:49 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 16:06:45 GMT, Vincent Alexander Beelte wrote: > This pull request improves the performance of creating the model that the flame graph visualization is drawn from. > > The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. > The use case where that tends to happen to me goes as follows: > My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" > Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. > Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. > All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) > > My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. > > With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. > > When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: > ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) > This is filtered to on... application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 50: > 48: import static org.openjdk.jmc.flightrecorder.flamegraph.Messages.FLAMEVIEW_TOGGLE_MINIMAP; > 49: import static org.openjdk.jmc.flightrecorder.flamegraph.MessagesUtils.getFlamegraphMessage; > 50: The static imports should move after the non-static imports. core/tests/org.openjdk.jmc.flightrecorder.test/src/main/java/org/openjdk/jmc/flightrecorder/test/StacktraceTreeModelTest.java line 38: > 36: import static java.util.Arrays.asList; > 37: import static org.junit.Assert.assertEquals; > 38: Same here, static imports should remain at the end of import section ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1277122385 PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1277150557 From duke at openjdk.org Fri Jul 28 06:47:05 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Fri, 28 Jul 2023 06:47:05 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v2] In-Reply-To: References: Message-ID: <9BH7MKVggHrQd7vx3Z2djQenXKLB-zV69WR05jyrJ3s=.abe77c7d-1eee-4344-85fe-aaf0c99b3ae3@github.com> > This pull request improves the performance of creating the model that the flame graph visualization is drawn from. > > The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. > The use case where that tends to happen to me goes as follows: > My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" > Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. > Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. > All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) > > My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. > > With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. > > When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: > ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) > This is filtered to on... Vincent Alexander Beelte 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 13 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into flamegraph_performance - Merge remote-tracking branch 'origin/master' into flamegraph_performance - Merge branch 'openjdk:master' into flamegraph_performance - Merge remote-tracking branch 'origin/master' into flamegraph_performance - Merge remote-tracking branch 'origin/master' into flamegraph_performance - fix automatic missmerge - remove node id because it was unused - add a test for stop flag - document the stop flag and also check it in the inner loop. log the isInvalid field with the duration - see what happens when delegating directly to the enums - ... and 3 more: https://git.openjdk.org/jmc/compare/27af7ee7...e1bd7912 ------------- Changes: - all: https://git.openjdk.org/jmc/pull/502/files - new: https://git.openjdk.org/jmc/pull/502/files/d5acdfcc..e1bd7912 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=502&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=502&range=00-01 Stats: 34 lines in 2 files changed: 26 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jmc/pull/502.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/502/head:pull/502 PR: https://git.openjdk.org/jmc/pull/502 From duke at openjdk.org Fri Jul 28 07:29:13 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Fri, 28 Jul 2023 07:29:13 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v3] In-Reply-To: References: Message-ID: > This pull request improves the performance of creating the model that the flame graph visualization is drawn from. > > The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. > The use case where that tends to happen to me goes as follows: > My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" > Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. > Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. > All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) > > My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. > > With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. > > When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: > ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) > This is filtered to on... Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: static imports last ------------- Changes: - all: https://git.openjdk.org/jmc/pull/502/files - new: https://git.openjdk.org/jmc/pull/502/files/e1bd7912..6d696175 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=502&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=502&range=01-02 Stats: 40 lines in 3 files changed: 20 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/502.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/502/head:pull/502 PR: https://git.openjdk.org/jmc/pull/502 From duke at openjdk.org Fri Jul 28 07:30:48 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Fri, 28 Jul 2023 07:30:48 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v2] In-Reply-To: <9BH7MKVggHrQd7vx3Z2djQenXKLB-zV69WR05jyrJ3s=.abe77c7d-1eee-4344-85fe-aaf0c99b3ae3@github.com> References: <9BH7MKVggHrQd7vx3Z2djQenXKLB-zV69WR05jyrJ3s=.abe77c7d-1eee-4344-85fe-aaf0c99b3ae3@github.com> Message-ID: On Fri, 28 Jul 2023 06:47:05 GMT, Vincent Alexander Beelte wrote: >> This pull request improves the performance of creating the model that the flame graph visualization is drawn from. >> >> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. >> The use case where that tends to happen to me goes as follows: >> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. >> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" >> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. >> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. >> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) >> >> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. >> >> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. >> >> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: >> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee... > > Vincent Alexander Beelte 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 13 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into flamegraph_performance > - Merge remote-tracking branch 'origin/master' into flamegraph_performance > - Merge branch 'openjdk:master' into flamegraph_performance > - Merge remote-tracking branch 'origin/master' into flamegraph_performance > - Merge remote-tracking branch 'origin/master' into flamegraph_performance > - fix automatic missmerge > - remove node id because it was unused > - add a test for stop flag > - document the stop flag and also check it in the inner loop. > log the isInvalid field with the duration > - see what happens when delegating directly to the enums > - ... and 3 more: https://git.openjdk.org/jmc/compare/1fc347f7...e1bd7912 I reconfigured my eclipse to move static imports to the bottom. Should I also add 2023 in the copyright headers for the files I changed. I noticed some of them don't have that yet. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1655187266 From clanger at openjdk.org Fri Jul 28 08:30:48 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 28 Jul 2023 08:30:48 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v2] In-Reply-To: References: <9BH7MKVggHrQd7vx3Z2djQenXKLB-zV69WR05jyrJ3s=.abe77c7d-1eee-4344-85fe-aaf0c99b3ae3@github.com> Message-ID: <9xp3HpTHV-f0oHPYEeM7XRtyhUyrzjjvrthxNC6DAz4=.8e3af7a2-9743-473e-a263-d7defac89ace@github.com> On Fri, 28 Jul 2023 07:28:37 GMT, Vincent Alexander Beelte wrote: > I reconfigured my eclipse to move static imports to the bottom. ? > Should I also add 2023 in the copyright headers for the files I changed. I noticed some of them don't have that yet. Oh yes, that tends to be forgotten. ? Thanks. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1655268262 From duke at openjdk.org Fri Jul 28 09:50:11 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Fri, 28 Jul 2023 09:50:11 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: > This pull request improves the performance of creating the model that the flame graph visualization is drawn from. > > The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. > The use case where that tends to happen to me goes as follows: > My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. > When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" > Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. > Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. > All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) > > My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. > > With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. > > When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: > ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee802d3e63) > This is filtered to on... Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: update copyright header with 2023 ------------- Changes: - all: https://git.openjdk.org/jmc/pull/502/files - new: https://git.openjdk.org/jmc/pull/502/files/6d696175..56362fc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=502&range=03 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=502&range=02-03 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jmc/pull/502.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/502/head:pull/502 PR: https://git.openjdk.org/jmc/pull/502 From clanger at openjdk.org Fri Jul 28 11:30:52 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 28 Jul 2023 11:30:52 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte wrote: >> This pull request improves the performance of creating the model that the flame graph visualization is drawn from. >> >> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. >> The use case where that tends to happen to me goes as follows: >> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. >> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" >> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. >> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. >> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) >> >> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. >> >> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. >> >> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: >> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee... > > Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: > > update copyright header with 2023 Looks good from my end, however, I just checked the build integration, not commenting about the code itself. Plus I'm not a Reviewer in the project - so it needs another review before integration. ------------- Marked as reviewed by clanger (Committer). PR Review: https://git.openjdk.org/jmc/pull/502#pullrequestreview-1551927813 From duke at openjdk.org Fri Jul 28 12:25:50 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Fri, 28 Jul 2023 12:25:50 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: <5mDplCtRgrj-vXH-geLBe1bbWT0eS-fIBFaxBzRb60k=.bf367dd2-51b0-48f1-88e7-1339aec4bc48@github.com> On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte wrote: >> This pull request improves the performance of creating the model that the flame graph visualization is drawn from. >> >> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. >> The use case where that tends to happen to me goes as follows: >> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. >> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" >> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. >> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. >> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) >> >> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. >> >> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. >> >> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: >> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee... > > Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: > > update copyright header with 2023 ok, I also do not have anything to add here until maybe another reviewer raises issues ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1655596416 From clanger at openjdk.org Mon Jul 31 11:36:51 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 31 Jul 2023 11:36:51 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: <5mN2qkVMU3-wxpSyjezGgtSKl2r7-duGSoJwrGISuug=.723d8a9f-0c79-453d-b8cb-e447348ca77e@github.com> On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte wrote: >> This pull request improves the performance of creating the model that the flame graph visualization is drawn from. >> >> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. >> The use case where that tends to happen to me goes as follows: >> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. >> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" >> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. >> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. >> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) >> >> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. >> >> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. >> >> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: >> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee... > > Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: > > update copyright header with 2023 > ok, I also do not have anything to add here until maybe another reviewer raises issues /integrate As I said above, I can't sponsor it at this time since I didn't review the actual code changes. Also I'm formally not a Reviewer here (yet), so it needs another review from at least a Committer. ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1658195369 From duke at openjdk.org Mon Jul 31 12:38:55 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Mon, 31 Jul 2023 12:38:55 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte wrote: >> This pull request improves the performance of creating the model that the flame graph visualization is drawn from. >> >> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task. >> The use case where that tends to happen to me goes as follows: >> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test. >> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two" >> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread. >> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it. >> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app) >> >> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel. >> >> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time. >> >> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick: >> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee... > > Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: > > update copyright header with 2023 sure sure no problem, I just would not know who the correct person to ask for an official review would be. ? ------------- PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1658290788