From guru.hb at oracle.com Tue Aug 4 09:31:52 2020 From: guru.hb at oracle.com (Guru) Date: Tue, 4 Aug 2020 15:01:52 +0530 Subject: RFR: 6000: Get rid of build warnings in the JMC agent Message-ID: <679A5FB5-1E35-4E66-A40A-C1A4733F336D@oracle.com> Hi, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JMC-6000 PR : https://github.com/openjdk/jmc/pull/103 Thanks, Guru From jmatsuoka at openjdk.java.net Wed Aug 5 21:40:00 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Wed, 5 Aug 2020 21:40:00 GMT Subject: RFR: 6886: Agent ASM components are constructed with the wrong version of =?UTF-8?B?4oCm?= Message-ID: This PR addresses JMC-6886. When we bumped the version of ASM up to 8.0.1 it broke the agent since some of the calls we were using started to enforce opcodes above ASM7. This PR updates the constructed ASM components to use Opcodes.ASM8 instead of Opcodes.ASM5. ------------- Commit messages: - 6886: Agent ASM components are constructed with the wrong version of Opcodes Changes: https://git.openjdk.java.net/jmc/pull/104/files Webrev: https://webrevs.openjdk.java.net/jmc/104/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6886 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jmc/pull/104.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/104/head:pull/104 PR: https://git.openjdk.java.net/jmc/pull/104 From ghb at openjdk.java.net Thu Aug 6 13:35:49 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 6 Aug 2020 13:35:49 GMT Subject: RFR: 6886: Agent ASM components are constructed with the wrong version of =?UTF-8?B?4oCm?= In-Reply-To: References: Message-ID: On Wed, 5 Aug 2020 21:35:02 GMT, Joshua Matsuoka wrote: > This PR addresses JMC-6886. When we bumped the version of ASM up to 8.0.1 it broke the agent since some of the calls we > were using started to enforce opcodes above ASM7. This PR updates the constructed ASM components to use Opcodes.ASM8 > instead of Opcodes.ASM5. looks good to me ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jmc/pull/104 From jmatsuoka at openjdk.java.net Fri Aug 7 14:36:18 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Fri, 7 Aug 2020 14:36:18 GMT Subject: Integrated: 6886: Agent ASM components are constructed with the wrong version of =?UTF-8?B?4oCm?= In-Reply-To: References: Message-ID: On Wed, 5 Aug 2020 21:35:02 GMT, Joshua Matsuoka wrote: > This PR addresses JMC-6886. When we bumped the version of ASM up to 8.0.1 it broke the agent since some of the calls we > were using started to enforce opcodes above ASM7. This PR updates the constructed ASM components to use Opcodes.ASM8 > instead of Opcodes.ASM5. This pull request has now been integrated. Changeset: a6ff5345 Author: Joshua Matsuoka URL: https://git.openjdk.java.net/jmc/commit/a6ff5345 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 6886: Agent ASM components are constructed with the wrong version of ? Reviewed-by: ghb ------------- PR: https://git.openjdk.java.net/jmc/pull/104 From jmatsuoka at openjdk.java.net Fri Aug 7 18:20:22 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Fri, 7 Aug 2020 18:20:22 GMT Subject: RFR: 6870: defineEventProbes is incorrect when probes occupy different classes In-Reply-To: References: Message-ID: On Tue, 21 Jul 2020 18:13:37 GMT, Jessye Coleman-Shapiro wrote: > Previously, when the agent MXBean operation `defineEventProbes(xmlDescription)` was called with an XML description only > containing probes from new classes, existing probes in other classes were not reverted. This patch fixes > `TransformRegistry.modify(xmlDescription)` so that this does not happen. Hi Jessye, The changes look good to me! ------------- PR: https://git.openjdk.java.net/jmc/pull/97 From jmatsuoka at openjdk.java.net Fri Aug 7 18:27:17 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Fri, 7 Aug 2020 18:27:17 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 22:42:37 GMT, Jessye Coleman-Shapiro wrote: > This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the > counterpart of `AgentControllerMXBean.defineEventProbes()`. Hi Jessye, Changes look good to me! ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From github.com+4610701+jpbempel at openjdk.java.net Tue Aug 11 13:17:27 2020 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Tue, 11 Aug 2020 13:17:27 GMT Subject: RFR: 6885: VM_OPERATION_DURATION aggregator does not filter on type Message-ID: Missing VM_OPERATION type to filter only on VM operations ------------- Commit messages: - fix formatting - Fix VM_OPERATION_DURATION aggregator Changes: https://git.openjdk.java.net/jmc/pull/101/files Webrev: https://webrevs.openjdk.java.net/jmc/101/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6885 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/101.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/101/head:pull/101 PR: https://git.openjdk.java.net/jmc/pull/101 From hirt at openjdk.java.net Tue Aug 11 13:17:27 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 11 Aug 2020 13:17:27 GMT Subject: RFR: 6885: VM_OPERATION_DURATION aggregator does not filter on type In-Reply-To: References: Message-ID: <2W_rsfyOcqhxFQnCkKWUv3AzbHWc_JLklIySQjhGSV0=.d1fd4437-d9bb-4658-909c-a35a59ab6454@github.com> On Fri, 31 Jul 2020 12:43:11 GMT, Jean-Philippe Bempel wrote: > Missing VM_OPERATION type to filter only on VM operations @jpbempel - you should write /covered in a separate comment on this PR. ------------- PR: https://git.openjdk.java.net/jmc/pull/101 From hirt at openjdk.java.net Tue Aug 11 13:33:13 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 11 Aug 2020 13:33:13 GMT Subject: RFR: 6885: VM_OPERATION_DURATION aggregator does not filter on type In-Reply-To: References: Message-ID: <04MYY3J9s-WK1P4jJAzuqNAp67TwFQVlv5URJe9VCKc=.f26c4a7c-88d9-4949-a950-17b84288f047@github.com> On Fri, 31 Jul 2020 12:43:11 GMT, Jean-Philippe Bempel wrote: > Missing VM_OPERATION type to filter only on VM operations Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/101 From github.com+4610701+jpbempel at openjdk.java.net Thu Aug 13 17:49:22 2020 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Thu, 13 Aug 2020 17:49:22 GMT Subject: Integrated: 6885: VM_OPERATION_DURATION aggregator does not filter on type In-Reply-To: References: Message-ID: On Fri, 31 Jul 2020 12:43:11 GMT, Jean-Philippe Bempel wrote: > Missing VM_OPERATION type to filter only on VM operations This pull request has now been integrated. Changeset: 38f9835b Author: jean-philippe bempel Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/38f9835b Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 6885: VM_OPERATION_DURATION aggregator does not filter on type Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/101 From aptmac at openjdk.java.net Tue Aug 18 14:20:41 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 18 Aug 2020 14:20:41 GMT Subject: RFR: 6870: defineEventProbes is incorrect when probes occupy different classes In-Reply-To: References: Message-ID: On Tue, 21 Jul 2020 18:13:37 GMT, Jessye Coleman-Shapiro wrote: > Previously, when the agent MXBean operation `defineEventProbes(xmlDescription)` was called with an XML description only > containing probes from new classes, existing probes in other classes were not reverted. This patch fixes > `TransformRegistry.modify(xmlDescription)` so that this does not happen. LGTM! ------------- Marked as reviewed by aptmac (Committer). PR: https://git.openjdk.java.net/jmc/pull/97 From jescolem at openjdk.java.net Tue Aug 18 17:15:39 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Tue, 18 Aug 2020 17:15:39 GMT Subject: Integrated: 6870: defineEventProbes is incorrect when probes occupy different classes In-Reply-To: References: Message-ID: <0SOXHNCVNsxfUn8A9udWPOA2ONcy6Rmq9r_IsXOSbZI=.dca3dbc1-e802-496a-b60a-de79dc057fd6@github.com> On Tue, 21 Jul 2020 18:13:37 GMT, Jessye Coleman-Shapiro wrote: > Previously, when the agent MXBean operation `defineEventProbes(xmlDescription)` was called with an XML description only > containing probes from new classes, existing probes in other classes were not reverted. This patch fixes > `TransformRegistry.modify(xmlDescription)` so that this does not happen. This pull request has now been integrated. Changeset: 3aa92e4e Author: Jessye Coleman-Shapiro Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/3aa92e4e Stats: 63 lines in 4 files changed: 20 ins; 15 del; 28 mod 6870: defineEventProbes is incorrect when probes occupy different classes Reviewed-by: aptmac, hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/97 From hirt at openjdk.java.net Tue Aug 18 17:15:39 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 18 Aug 2020 17:15:39 GMT Subject: RFR: 6870: defineEventProbes is incorrect when probes occupy different classes In-Reply-To: References: Message-ID: On Tue, 21 Jul 2020 18:13:37 GMT, Jessye Coleman-Shapiro wrote: > Previously, when the agent MXBean operation `defineEventProbes(xmlDescription)` was called with an XML description only > containing probes from new classes, existing probes in other classes were not reverted. This patch fixes > `TransformRegistry.modify(xmlDescription)` so that this does not happen. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/97 From hirt at openjdk.java.net Tue Aug 18 17:21:56 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 18 Aug 2020 17:21:56 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 22:42:37 GMT, Jessye Coleman-Shapiro wrote: > This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the > counterpart of `AgentControllerMXBean.defineEventProbes()`. I think it would be nice with a few tests showing the failure modes, and some javadocs around what to expect from the API (especially in terms of failure modes / exceptions), for example setting invalid XML, setting invalid XML and then attempting reading it back and so on. ------------- Changes requested by hirt (Lead). PR: https://git.openjdk.java.net/jmc/pull/99 From hirt at openjdk.java.net Tue Aug 18 17:27:47 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 18 Aug 2020 17:27:47 GMT Subject: RFR: 6487: The TOPIC word in topic constants should either be the first word or removed [v2] In-Reply-To: References: Message-ID: <6hsBBeAvvYFuxLBe11LG4rw7AmBzRbzDBv__RGRgw3w=.7688b257-c2f2-4174-8a17-32572d94ac7e@github.com> > Simply removed "_TOPIC". Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Making spotless happy ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/102/files - new: https://git.openjdk.java.net/jmc/pull/102/files/82c7de1d..1da2bf8c Webrevs: - full: https://webrevs.openjdk.java.net/jmc/102/webrev.01 - incr: https://webrevs.openjdk.java.net/jmc/102/webrev.00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/102/head:pull/102 PR: https://git.openjdk.java.net/jmc/pull/102 From jescolem at openjdk.java.net Tue Aug 18 18:27:30 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Tue, 18 Aug 2020 18:27:30 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v2] In-Reply-To: References: Message-ID: > This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the > counterpart of `AgentControllerMXBean.defineEventProbes()`. Jessye Coleman-Shapiro has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Add javadoc for retrieveCurrentTransforms - Add test for invalid xml inputted - create retrieveEventProbes() operation ------------- Changes: https://git.openjdk.java.net/jmc/pull/99/files Webrev: https://webrevs.openjdk.java.net/jmc/99/webrev.01 Stats: 157 lines in 7 files changed: 157 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/99/head:pull/99 PR: https://git.openjdk.java.net/jmc/pull/99 From jescolem at openjdk.java.net Tue Aug 18 18:51:07 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Tue, 18 Aug 2020 18:51:07 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v2] In-Reply-To: References: Message-ID: On Tue, 18 Aug 2020 17:19:37 GMT, Marcus Hirt wrote: > I think it would be nice with a few tests showing the failure modes, and some javadocs around what to expect from the > API (especially in terms of failure modes / exceptions), for example setting invalid XML, setting invalid XML and then > attempting reading it back and so on. Currently, an XML configuration is only stored if it can be successfully instrumented. If a new configuration cannot be instrumented, the current configuration that has already been successfully applied is not overwritten. I have added a test `TestDefaultTransformRegistry.testModifyInvalidXml` that makes sure that an invalid configuration is not instrumented or stored. I have added the test within this file as `DefaultTransformRegistry.modify` is where a new XML configuration is stored if it has no errors. In my initial commit I added a general test for `AgentControllerMXBean.retrieveCurrentTransforms` that covers the case when a XML configuration is successfully applied. Let me know if these tests cover the failure modes properly! I have also added a javadoc for the `AgentControllerMXBean.retrieveCurrentTransforms` operation - hopefully its functionality is more clear now. ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From hirt at openjdk.java.net Tue Aug 18 22:13:16 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 18 Aug 2020 22:13:16 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v2] In-Reply-To: References: Message-ID: On Tue, 18 Aug 2020 18:27:30 GMT, Jessye Coleman-Shapiro wrote: >> This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the >> counterpart of `AgentControllerMXBean.defineEventProbes()`. > > Jessye Coleman-Shapiro has updated the pull request with a new target base due to a merge or a rebase. The pull request > now contains three commits: > - Add javadoc for retrieveCurrentTransforms > - Add test for invalid xml inputted > - create retrieveEventProbes() operation Changes requested by hirt (Lead). agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentControllerMXBean.java line 39: > 38: > 39: public void defineEventProbes(String xmlDescription) throws Exception; > 40: Javadoc here explaining when exceptions are thrown (I assume when providing an invalid probe definition). agent/src/test/java/org/openjdk/jmc/agent/test/TestRetrieveEventProbes.java line 75: > 74: } > 75: > 76: public void test() { Test here at least testing providing an invalid probe definition to the MBean, and ensuring that the appropriate effect happens. ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From jescolem at openjdk.java.net Wed Aug 19 15:41:58 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Wed, 19 Aug 2020 15:41:58 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v3] In-Reply-To: References: Message-ID: > This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the > counterpart of `AgentControllerMXBean.defineEventProbes()`. Jessye Coleman-Shapiro has updated the pull request incrementally with one additional commit since the last revision: Add javadoc and test for retrieving an invalid configuration ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/99/files - new: https://git.openjdk.java.net/jmc/pull/99/files/16ea4d3d..80b5757a Webrevs: - full: https://webrevs.openjdk.java.net/jmc/99/webrev.02 - incr: https://webrevs.openjdk.java.net/jmc/99/webrev.01-02 Stats: 21 lines in 2 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/99/head:pull/99 PR: https://git.openjdk.java.net/jmc/pull/99 From jescolem at openjdk.java.net Wed Aug 19 15:42:02 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Wed, 19 Aug 2020 15:42:02 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v2] In-Reply-To: References: Message-ID: On Tue, 18 Aug 2020 22:10:48 GMT, Marcus Hirt wrote: >> Jessye Coleman-Shapiro has updated the pull request with a new target base due to a merge or a rebase. The pull request >> now contains three commits: >> - Add javadoc for retrieveCurrentTransforms >> - Add test for invalid xml inputted >> - create retrieveEventProbes() operation > > agent/src/test/java/org/openjdk/jmc/agent/test/TestRetrieveEventProbes.java line 75: > >> 74: } >> 75: >> 76: public void test() { > > Test here at least testing providing an invalid probe definition to the MBean, and ensuring that the appropriate effect > happens. Test added in 80b5757 > agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentControllerMXBean.java line 39: > >> 38: >> 39: public void defineEventProbes(String xmlDescription) throws Exception; >> 40: > > Javadoc here explaining when exceptions are thrown (I assume when providing an invalid probe definition). Javadoc added in 80b5757 ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From hirt at openjdk.java.net Wed Aug 19 16:53:16 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 19 Aug 2020 16:53:16 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v3] In-Reply-To: References: Message-ID: On Wed, 19 Aug 2020 15:41:58 GMT, Jessye Coleman-Shapiro wrote: >> This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the >> counterpart of `AgentControllerMXBean.defineEventProbes()`. > > Jessye Coleman-Shapiro has updated the pull request incrementally with one additional commit since the last revision: > > Add javadoc and test for retrieving an invalid configuration agent/src/test/java/org/openjdk/jmc/agent/test/TestRetrieveEventProbes.java line 82: > 81: String invalidConfiguration = XML_TEST_DESCRIPTION.concat(""); > 82: mbean.defineEventProbes(invalidConfiguration); > 83: Assert.assertEquals(mbean.retrieveEventProbes(), initialConfiguration); This is just a matter of taste, but I would have expected the definition to fail exceptionally with information about the invalid configuration, hopefully giving a hint of what went wrong (in the case of e.g. bad XML where the XML went wrong, simply propagating the exception). And then (just as it is done) let subsequent reads of the configuration return the last valid one. ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From github.com+11866488+Schalli1987 at openjdk.java.net Wed Aug 19 19:26:59 2020 From: github.com+11866488+Schalli1987 at openjdk.java.net (Schalli1987) Date: Wed, 19 Aug 2020 19:26:59 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC Message-ID: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> Second try, I signed the OCA last week (also I do not have any response). This script provides an easy way to package JMC by just calling a single command. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into enhancement/buildScript - fix path to jmc in output - Merge remote-tracking branch 'origin/master' into enhancement/buildScript - Add build script for linux Changes: https://git.openjdk.java.net/jmc/pull/100/files Webrev: https://webrevs.openjdk.java.net/jmc/100/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6889 Stats: 170 lines in 2 files changed: 170 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/100.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/100/head:pull/100 PR: https://git.openjdk.java.net/jmc/pull/100 From hirt at openjdk.java.net Wed Aug 19 19:26:59 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 19 Aug 2020 19:26:59 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC In-Reply-To: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> References: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> Message-ID: On Sat, 25 Jul 2020 16:17:18 GMT, Schalli1987 wrote: > Second try, I signed the OCA last week (also I do not have any response). > > This script provides an easy way to package JMC by just calling a single command. Great to hear that the OCA has been signed! Sorry about all of this being a little bit involved. Good news, once you're through this part of the process, it's done for all eternity. There are a lot of vacations right now, so it may take a little bit longer than usual. Feel free to open the [Skara issue](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) if you haven't already. ------------- PR: https://git.openjdk.java.net/jmc/pull/100 From github.com+11866488+Schalli1987 at openjdk.java.net Wed Aug 19 19:26:59 2020 From: github.com+11866488+Schalli1987 at openjdk.java.net (Schalli1987) Date: Wed, 19 Aug 2020 19:26:59 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC In-Reply-To: References: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> Message-ID: On Mon, 27 Jul 2020 08:32:08 GMT, Marcus Hirt wrote: > Great to hear that the OCA has been signed! Sorry about all of this being a little bit involved. Good news, once you're > through this part of the process, it's done for all eternity. There are a lot of vacations right now, so it may take a > little bit longer than usual. Feel free to open the [Skara > issue](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) if you haven't already. OCA has now been accepted. I don't think there's a Skara issue for this right now, and it seems that I can't create one. I need to log in but I do not have and account and there's no way to register? ------------- PR: https://git.openjdk.java.net/jmc/pull/100 From hirt at openjdk.java.net Wed Aug 19 19:26:59 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 19 Aug 2020 19:26:59 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC In-Reply-To: References: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> Message-ID: On Mon, 17 Aug 2020 19:08:24 GMT, Schalli1987 wrote: >> Great to hear that the OCA has been signed! Sorry about all of this being a little bit involved. Good news, once you're >> through this part of the process, it's done for all eternity. There are a lot of vacations right now, so it may take a >> little bit longer than usual. Feel free to open the [Skara >> issue](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) if you haven't already. > >> Great to hear that the OCA has been signed! Sorry about all of this being a little bit involved. Good news, once you're >> through this part of the process, it's done for all eternity. There are a lot of vacations right now, so it may take a >> little bit longer than usual. Feel free to open the [Skara >> issue](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) if you haven't already. > > OCA has now been accepted. I don't think there's a Skara issue for this right now, and it seems that I can't create one. > I need to log in but I do not have and account and there's no way to register? Ah. If you don't have an OpenJDK identity, then that doesn't matter. ------------- PR: https://git.openjdk.java.net/jmc/pull/100 From hirt at openjdk.java.net Wed Aug 19 19:30:42 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 19 Aug 2020 19:30:42 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC In-Reply-To: References: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> Message-ID: <4AO0dFySn13BwKDUbJ2bcihK-s4Uxife8ynIw-RmiYs=.d22aca73-a421-4492-b20b-139ce12471d8@github.com> On Mon, 17 Aug 2020 19:19:22 GMT, Marcus Hirt wrote: >>> Great to hear that the OCA has been signed! Sorry about all of this being a little bit involved. Good news, once you're >>> through this part of the process, it's done for all eternity. There are a lot of vacations right now, so it may take a >>> little bit longer than usual. Feel free to open the [Skara >>> issue](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) if you haven't already. >> >> OCA has now been accepted. I don't think there's a Skara issue for this right now, and it seems that I can't create one. >> I need to log in but I do not have and account and there's no way to register? > > Ah. If you don't have an OpenJDK identity, then that doesn't matter. One thing that I see beginners struggling with is running the built product. Perhaps being able to launch the built product could be a target? And perhaps with -vm $JAVA_HOME/bin added? For Mac: target/products/org.openjdk.jmc/macosx/cocoa/x86_64/JDK\ Mission\ Control.app/Contents/MacOS/jmc -vm $JAVA_HOME/bin For Linux: target/products/org.openjdk.jmc/linux/gtk/x86_64/jmc -vm $JAVA_HOME/bin ------------- PR: https://git.openjdk.java.net/jmc/pull/100 From hirt at openjdk.java.net Wed Aug 19 19:36:27 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 19 Aug 2020 19:36:27 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC In-Reply-To: <4AO0dFySn13BwKDUbJ2bcihK-s4Uxife8ynIw-RmiYs=.d22aca73-a421-4492-b20b-139ce12471d8@github.com> References: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> <4AO0dFySn13BwKDUbJ2bcihK-s4Uxife8ynIw-RmiYs=.d22aca73-a421-4492-b20b-139ce12471d8@github.com> Message-ID: On Wed, 19 Aug 2020 19:28:28 GMT, Marcus Hirt wrote: >> Ah. If you don't have an OpenJDK identity, then that doesn't matter. > > One thing that I see beginners struggling with is running the built product. Perhaps being able to launch the built > product could be a target? And perhaps with -vm $JAVA_HOME/bin added? > For Mac: > target/products/org.openjdk.jmc/macosx/cocoa/x86_64/JDK\ Mission\ Control.app/Contents/MacOS/jmc -vm $JAVA_HOME/bin > > For Linux: > target/products/org.openjdk.jmc/linux/gtk/x86_64/jmc -vm $JAVA_HOME/bin We should ensure that the script works on both Mac and Linux. Check $OSTYPE. If it starts with darwin, then MacOS X. ------------- PR: https://git.openjdk.java.net/jmc/pull/100 From reinhapa at openjdk.java.net Wed Aug 19 19:40:42 2020 From: reinhapa at openjdk.java.net (Patrick Reinhart) Date: Wed, 19 Aug 2020 19:40:42 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC In-Reply-To: References: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> Message-ID: On Mon, 17 Aug 2020 19:08:24 GMT, Schalli1987 wrote: >> Great to hear that the OCA has been signed! Sorry about all of this being a little bit involved. Good news, once you're >> through this part of the process, it's done for all eternity. There are a lot of vacations right now, so it may take a >> little bit longer than usual. Feel free to open the [Skara >> issue](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) if you haven't already. > >> Great to hear that the OCA has been signed! Sorry about all of this being a little bit involved. Good news, once you're >> through this part of the process, it's done for all eternity. There are a lot of vacations right now, so it may take a >> little bit longer than usual. Feel free to open the [Skara >> issue](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) if you haven't already. > > OCA has now been accepted. I don't think there's a Skara issue for this right now, and it seems that I can't create one. > I need to log in but I do not have and account and there's no way to register? @Schalli1987 it would also be nice to check for the existence of maven and a java runtime as precondition too... ------------- PR: https://git.openjdk.java.net/jmc/pull/100 From jescolem at openjdk.java.net Wed Aug 19 19:44:11 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Wed, 19 Aug 2020 19:44:11 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v3] In-Reply-To: References: Message-ID: <8XVqEhk7fDssPnMpE-93qITdX688GAfIHitYOf7O848=.381b1b74-943d-46b5-9d00-775d0148359d@github.com> On Wed, 19 Aug 2020 16:51:04 GMT, Marcus Hirt wrote: >> Jessye Coleman-Shapiro has updated the pull request incrementally with one additional commit since the last revision: >> >> Add javadoc and test for retrieving an invalid configuration > > agent/src/test/java/org/openjdk/jmc/agent/test/TestRetrieveEventProbes.java line 82: > >> 81: String invalidConfiguration = XML_TEST_DESCRIPTION.concat(""); >> 82: mbean.defineEventProbes(invalidConfiguration); >> 83: Assert.assertEquals(mbean.retrieveEventProbes(), initialConfiguration); > > This is just a matter of taste, but I would have expected the definition to fail exceptionally with information about > the invalid configuration, hopefully giving a hint of what went wrong (in the case of e.g. bad XML where the XML went > wrong, simply propagating the exception). And then (just as it is done) let subsequent reads of the configuration > return the last valid one. Yes, I do agree with you - right now how it is handled is an error is logged when the definition fails, but no exception is thrown. Since this is more specific to `defineEventProbes` instead of `retrieveEventProbes`, perhaps a separate issue should be created to address this? ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From hirt at openjdk.java.net Wed Aug 19 20:57:37 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 19 Aug 2020 20:57:37 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v3] In-Reply-To: References: Message-ID: On Wed, 19 Aug 2020 15:41:58 GMT, Jessye Coleman-Shapiro wrote: >> This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the >> counterpart of `AgentControllerMXBean.defineEventProbes()`. > > Jessye Coleman-Shapiro has updated the pull request incrementally with one additional commit since the last revision: > > Add javadoc and test for retrieving an invalid configuration Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From hirt at openjdk.java.net Wed Aug 19 20:57:38 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 19 Aug 2020 20:57:38 GMT Subject: RFR: 6875: Add agent MXBean operation to return instrumented xml configuration [v3] In-Reply-To: <8XVqEhk7fDssPnMpE-93qITdX688GAfIHitYOf7O848=.381b1b74-943d-46b5-9d00-775d0148359d@github.com> References: <8XVqEhk7fDssPnMpE-93qITdX688GAfIHitYOf7O848=.381b1b74-943d-46b5-9d00-775d0148359d@github.com> Message-ID: On Wed, 19 Aug 2020 19:41:56 GMT, Jessye Coleman-Shapiro wrote: >> agent/src/test/java/org/openjdk/jmc/agent/test/TestRetrieveEventProbes.java line 82: >> >>> 81: String invalidConfiguration = XML_TEST_DESCRIPTION.concat(""); >>> 82: mbean.defineEventProbes(invalidConfiguration); >>> 83: Assert.assertEquals(mbean.retrieveEventProbes(), initialConfiguration); >> >> This is just a matter of taste, but I would have expected the definition to fail exceptionally with information about >> the invalid configuration, hopefully giving a hint of what went wrong (in the case of e.g. bad XML where the XML went >> wrong, simply propagating the exception). And then (just as it is done) let subsequent reads of the configuration >> return the last valid one. > > Yes, I do agree with you - right now how it is handled is an error is logged when the definition fails, but no > exception is thrown. Since this is more specific to `defineEventProbes` instead of `retrieveEventProbes`, perhaps a > separate issue should be created to address this? Ok. I opened up JMC-6890 for this. ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From jmatsuoka at openjdk.java.net Wed Aug 19 22:37:45 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Wed, 19 Aug 2020 22:37:45 GMT Subject: RFR: 6887: Agent instrumentation fails silently if method descriptors don't match Message-ID: Hi, This PR addresses JMC-6887. Currently when the agent is given an XML description that has an otherwise correct probe definition, but an incorrect method descriptor the instrumentation will inject the event classes but not the method, essentially failing silently. The JFRTransformDescriptor will now track whether the ClassVisitor has found a matching method or not, and in the event that the ClassVisitor reaches the end of the class without finding a matching method it will log a warning to the user that no matching method was found. This will also catch the case where a non-existent method is specified for instrumentation, which will currently fail silently in the same way. ------------- Commit messages: - 6887: Agent instrumentation fails silently if method descriptors don't match Changes: https://git.openjdk.java.net/jmc/pull/105/files Webrev: https://webrevs.openjdk.java.net/jmc/105/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6887 Stats: 142 lines in 4 files changed: 141 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/105.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/105/head:pull/105 PR: https://git.openjdk.java.net/jmc/pull/105 From jescolem at openjdk.java.net Thu Aug 20 13:25:50 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Thu, 20 Aug 2020 13:25:50 GMT Subject: Integrated: 6875: Add agent MXBean operation to return instrumented xml configuration In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 22:42:37 GMT, Jessye Coleman-Shapiro wrote: > This patch adds the MXBean operation `AgentControllerMXBean.retrieveEventProbes()` to the agent. This function is the > counterpart of `AgentControllerMXBean.defineEventProbes()`. This pull request has now been integrated. Changeset: f157e54f Author: Jessye Coleman-Shapiro Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/f157e54f Stats: 175 lines in 7 files changed: 0 ins; 175 del; 0 mod 6875: Add agent MXBean operation to return instrumented xml configuration Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/99 From hirt at openjdk.java.net Thu Aug 20 13:30:02 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 20 Aug 2020 13:30:02 GMT Subject: RFR: 6000: Get rid of build warnings in the JMC agent In-Reply-To: References: Message-ID: On Tue, 4 Aug 2020 01:10:37 GMT, Guru Hb wrote: > Solution : excluded "module-info.class" and META-INF/MANIFEST.MF (maven-shade-plugin has detected that some class files > are present in two or more jars). for below warnings > > [WARNING] Discovered module-info.class. Shading will break its strong encapsulation. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/103 From hirt at openjdk.java.net Thu Aug 20 13:35:18 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 20 Aug 2020 13:35:18 GMT Subject: RFR: 6889: Provide build script for making it easier to build JMC In-Reply-To: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> References: <8SDd3AYfWvUS7ewAym4GIU4-YuX9gkQPoiL3_Jznpgs=.2aceb975-6bd4-417b-b04a-559f021d351c@github.com> Message-ID: On Sat, 25 Jul 2020 16:17:18 GMT, Schalli1987 wrote: > Second try, I signed the OCA last week (also I do not have any response). > > This script provides an easy way to package JMC by just calling a single command. We should ensure that the script works on both Mac and Linux. Check $OSTYPE. If it starts with darwin, then MacOS X. One thing that I see beginners struggling with is running the built product. Perhaps adding a --run which simply launch the latest build? And perhaps launch with -vm $JAVA_HOME/bin added? For Mac: target/products/org.openjdk.jmc/macosx/cocoa/x86_64/JDK\ Mission\ Control.app/Contents/MacOS/jmc -vm $JAVA_HOME/bin For Linux: target/products/org.openjdk.jmc/linux/gtk/x86_64/jmc -vm $JAVA_HOME/bin ------------- Changes requested by hirt (Lead). PR: https://git.openjdk.java.net/jmc/pull/100 From marcus.hirt at datadoghq.com Thu Aug 20 13:55:35 2020 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 20 Aug 2020 15:55:35 +0200 Subject: Jessye and Arvin Message-ID: Hi all, Jessye's and Arvin's internship at Red Hat is ending now in August, and I just wanted to take this opportunity to thank them both for all the hard work that they've put into helping the community. JMC is better for it! Kudos and thank you both! :) Kind regards, Marcus From hirt at openjdk.java.net Thu Aug 20 14:12:15 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 20 Aug 2020 14:12:15 GMT Subject: RFR: 6887: Agent instrumentation fails silently if method descriptors don't match In-Reply-To: References: Message-ID: <41BICorMyjB0BDeQ2k32DOVc2KKeLrmgsNCKqKr4Bhs=.7f0842b0-dbc8-48b0-a770-a7382373944c@github.com> On Wed, 19 Aug 2020 22:32:17 GMT, Joshua Matsuoka wrote: > Hi, > > This PR addresses JMC-6887. Currently when the agent is given an XML description that has an otherwise correct probe > definition, but an incorrect method descriptor the instrumentation will inject the event classes but not the method, > essentially failing silently. The JFRTransformDescriptor will now track whether the ClassVisitor has found a matching > method or not, and in the event that the ClassVisitor reaches the end of the class without finding a matching method it > will log a warning to the user that no matching method was found. This will also catch the case where a non-existent > method is specified for instrumentation, which will currently fail silently in the same way. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/105 From neugens at redhat.com Thu Aug 20 15:52:10 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 20 Aug 2020 17:52:10 +0200 Subject: Jessye and Arvin In-Reply-To: References: Message-ID: Hi Marcus, Well said! Jessye and Arvin have done some truly terrific work, I am glad to have had the opportunity to with closely with them. Thank you both! Cheers, Mario On Thursday, August 20, 2020, Marcus Hirt wrote: > Hi all, > > Jessye's and Arvin's internship at Red Hat is ending now in August, and I > just wanted to take this opportunity to thank them both for all the hard > work that they've put into helping the community. JMC is better for it! > > Kudos and thank you both! :) > > Kind regards, > Marcus > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From adinn at redhat.com Thu Aug 20 16:03:39 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Aug 2020 17:03:39 +0100 Subject: Jessye and Arvin In-Reply-To: References: Message-ID: <759f74ba-0761-c736-e120-8a4331173181@redhat.com> On 20/08/2020 14:55, Marcus Hirt wrote: > Jessye's and Arvin's internship at Red Hat is ending now in August, and I > just wanted to take this opportunity to thank them both for all the hard > work that they've put into helping the community. JMC is better for it! > > Kudos and thank you both! :) Yes, indeed. Our Toronto office seems to have the knack of finding outstanding interns. Many thanks to Jessye and Arvin for making a really significant contribution to the project. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From jmatsuoka at openjdk.java.net Thu Aug 20 17:13:58 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Thu, 20 Aug 2020 17:13:58 GMT Subject: Integrated: 6887: Agent instrumentation fails silently if method descriptors don't match In-Reply-To: References: Message-ID: On Wed, 19 Aug 2020 22:32:17 GMT, Joshua Matsuoka wrote: > Hi, > > This PR addresses JMC-6887. Currently when the agent is given an XML description that has an otherwise correct probe > definition, but an incorrect method descriptor the instrumentation will inject the event classes but not the method, > essentially failing silently. The JFRTransformDescriptor will now track whether the ClassVisitor has found a matching > method or not, and in the event that the ClassVisitor reaches the end of the class without finding a matching method it > will log a warning to the user that no matching method was found. This will also catch the case where a non-existent > method is specified for instrumentation, which will currently fail silently in the same way. This pull request has now been integrated. Changeset: 76d656cd Author: Joshua Matsuoka URL: https://git.openjdk.java.net/jmc/commit/76d656cd Stats: 142 lines in 4 files changed: 0 ins; 141 del; 1 mod 6887: Agent instrumentation fails silently if method descriptors don't match Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/105 From ghb at openjdk.java.net Fri Aug 21 15:01:15 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 21 Aug 2020 15:01:15 GMT Subject: Integrated: 6000: Get rid of build warnings in the JMC agent In-Reply-To: References: Message-ID: On Tue, 4 Aug 2020 01:10:37 GMT, Guru Hb wrote: > Solution : excluded "module-info.class" and META-INF/MANIFEST.MF (maven-shade-plugin has detected that some class files > are present in two or more jars). for below warnings > > [WARNING] Discovered module-info.class. Shading will break its strong encapsulation. This pull request has now been integrated. Changeset: db64b84a Author: Guru Hb URL: https://git.openjdk.java.net/jmc/commit/db64b84a Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod 6000: Get rid of build warnings in the JMC agent Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/103 From aptmac at openjdk.java.net Tue Aug 25 14:11:15 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 25 Aug 2020 14:11:15 GMT Subject: RFR: 6364: Improvements to the Thread Graph [v3] In-Reply-To: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> Message-ID: > This patch addresses JMC-6364 [[0]](https://bugs.openjdk.java.net/browse/JMC-6364), the epic for tracking Improvements > to the JFR Thread Graph. This RFR is also a follow-up to an RFC > [[1]](http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html) that was posted to the jmc-dev list and > incorporates the feedback that was brought up during discussion. The new design and features was imagined in > collaboration with our UX team, and the implementation has been a joint effort between myself and Jessye (@jessyec-s) - > we had been originally collaborating on a fork of the old (unofficial) JMC GitHub repo. I've folded all the commits > down into one because the older commits were merged using PRs with a similar format (e.g., `jmc/pull/23`) to this repo, > so to avoid accidental noise (sorry about that) on other PRs I've just folded them away. If anyone is interested in the > individual commits that got to this point, I've kept them around in the old repo > [[2]](https://github.com/aptmac/jmc-old/commits/jfr-threads-page). This PR aims to improve the usability and > functionality of the JFR Threads Page by extending and enhancing existing classes. In an attempt to not clutter this PR > with lots of images and explanatory text, I've created a gist > [[3]](https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36) that provides information and images/gifs of the > new components and intended functionality. Gist: https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36 > Summary of changes: > - Introduction of canvases to display the thread names (left) and timeline (bottom) > - Scrolled composites to house the text and chart canvases, for vertical scrolling of the chart area > - Timeline canvas (bottom) is draggable for panning the chart > - Current threads table has been re-located to a popup table > - New filter bar (top) which alters the chart view based on time ranges and desired visible activity lanes > - New display bar (right) which houses the zoom mechanics > - New zoom pan component for easily navigating the chart > - Introduction of a colour palette to increase contrast between neighbouring activity lanes > - Controls to change the height of the thread lanes > - updated and new uitests > > Before: > ![before](https://i.imgur.com/TNfGrtJ.png) > > After: > ![after](https://user-images.githubusercontent.com/10425301/71993902-dfd93200-3205-11ea-8249-cc50409a7a9f.png) > > Let me know if you have any questions about the design & functionality. > > [0] https://bugs.openjdk.java.net/browse/JMC-6364 > [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html > [2] https://github.com/aptmac/jmc-old/commits/jfr-threads-page > [3] https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36 Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: - chore: cleanup string usage and image for overview mode button - chore: update layouts in ThreadsPageUILayout and minor cleanup - chore(windows): fix a couple of bugs that were inhibiting proper display on Windows - chore: update the license headers to 2020 + include third party licenses for FontAwesome and PatternFly - feat: improve re-sizing and resetting of lane heights - fix: run spotless and fix spotbugs errors - test: include tests for the chart and table hiding actions - feat: replace popup table with foldable sashform While an interesting feature, trying to persist settings and selections from the FilterEditor and table within the former popup table was not a realistic feat. After demoing the threads page work at the latest bi-weekly JMC hangout meeting, it was noted that it'd be nice to be able to easily interact with the table and update selections and filters. Based on this information, this commit replaces the popup table with a foldable sashform using controls proposed in JMC-6386. This allows the user to quickly hide and unhide both the table or chart based on their workflow. - fix: redraw the canvases only if they are not disposed - fix: ensure that the chart and text canvases redraw on the ui thread - ... and 14 more: https://git.openjdk.java.net/jmc/compare/081bdc93...031668e1 ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/27/files - new: https://git.openjdk.java.net/jmc/pull/27/files/08a7b1a4..031668e1 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/27/webrev.02 - incr: https://webrevs.openjdk.java.net/jmc/27/webrev.01-02 Stats: 13115 lines in 179 files changed: 6646 ins; 1562 del; 4907 mod Patch: https://git.openjdk.java.net/jmc/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/27/head:pull/27 PR: https://git.openjdk.java.net/jmc/pull/27 From aptmac at openjdk.java.net Tue Aug 25 14:20:19 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 25 Aug 2020 14:20:19 GMT Subject: RFR: 6364: Improvements to the Thread Graph In-Reply-To: <1rFwH_fS08Lr6VT09rAPl5aOjeoDyyfAK1l1DaktMB8=.e94b0d05-4244-46b2-848e-c83f7aa3917a@github.com> References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com> <1rFwH_fS08Lr6VT09rAPl5aOjeoDyyfAK1l1DaktMB8=.e94b0d05-4244-46b2-848e-c83f7aa3917a@github.com> Message-ID: On Wed, 17 Jun 2020 20:20:56 GMT, Brice Dutheil wrote: >> Hi @thegreystone, I rebased the branch yesterday to be on top of master, and included a new commit based on the >> feedback that makes the dropdown lane filter act like the Edit Lanes Dialog (screenshot below). Does the outdated tag >> automatically remove itself what some criteria is met? Edit: I also see that the checks failed, it looks like there's >> something wrong with the builds at the moment, I've been seeing similar errors on my travis builds as well >> ![2020-04-27-171139_1177x829_scrot](https://user-images.githubusercontent.com/10425301/80604806-301c1000-8a00-11ea-82ce-88e55cc5d744.png) > > Hi just for the record how this is handled when there's a lot of threads to deal with. > > ![image](https://user-images.githubusercontent.com/803621/84946230-a8da4700-b0e8-11ea-9058-54a51490fd5a.png) Hi everyone, The following commits update this PR based on the feedback on the Threads Page document (posted in Slack) [0], and then rebased to sit ontop of the current master branch. The major changes include: - reverting some of the colour palette modifications to restore "urgency" of some colours - removal of the right-side toolbar and migrating its controls to the top bar - setting the minimum readible lane height by default & fixing the lane height controls - adding functionality for an "legacy" zoomed out mode of one-past the minimum lane height, which mimics the current threads page display (including restoring the mousewheel zoom in this mode) - the popup table has been reworked to be a foldable table with an implementation based off an old JMC-6368 proposed patch - placing the new threads page implementation into it's own page, so the current and new pages can live simultaneously Here's a handful of screenshots and gifs showing the new modifications: Threads Page (Linux): ![0-overview](https://user-images.githubusercontent.com/10425301/91185566-fdd3a400-e6bb-11ea-82f6-bb3f0abc3260.png) Threads Page (Windows): ![0-windows](https://user-images.githubusercontent.com/10425301/91185573-00ce9480-e6bc-11ea-86d5-ca3be0b426f2.png) Overview Mode (Linux): ![2-legacy-mode](https://user-images.githubusercontent.com/10425301/91185593-05934880-e6bc-11ea-9164-9be5f0dbd2bc.png) Legacy Page (Linux): ![3-legacy-page](https://user-images.githubusercontent.com/10425301/91185646-1a6fdc00-e6bc-11ea-854f-660574e7b4c9.png) Gif of the overview mode toggle (Linux): ![legacy-mode](https://user-images.githubusercontent.com/10425301/91185675-2065bd00-e6bc-11ea-97ea-de2c74bc15fe.gif) Gif of the foldable table and lane selection (Linux): ![fold-table](https://user-images.githubusercontent.com/10425301/91185707-278ccb00-e6bc-11ea-9581-dd8925ea94f9.gif) As usual, I've been testing the functionality and behavior on my Linux & Windows machines, and they work okay from what I've seen. If someone could double-check that this behaves as expected on a Mac it'd be greatly appreciated. [0] https://docs.google.com/document/d/1fY5xXJKcg84vLGySzOZ7JjVqvZyZeSsGq7syTK5ETCM/edit [1] https://bugs.openjdk.java.net/browse/JMC-6368 ------------- PR: https://git.openjdk.java.net/jmc/pull/27 From aptmac at openjdk.java.net Tue Aug 25 14:22:21 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 25 Aug 2020 14:22:21 GMT Subject: RFR: 6531: Make the flame chart view render labels on windows In-Reply-To: References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com> <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com> <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com> Message-ID: On Wed, 10 Jun 2020 15:41:19 GMT, Marcus Hirt wrote: >>> Dumb question, but would a shorter path be to run babel against d3 (Or have that as part of the build?) >>> >>> That would eliminate the need to maintain your own version and make updating a lot easier. >> >> Not a dumb question! I've given this a look, but I don't think Babel is able to help us out here. Specifically I'm >> finding a bunch of resources on the internet mixing up terminology.. >> Babel seems to be able to covert back to ECMA2015, which is ES6. Internet Explorer here requires ES5 (or "ECMA2009"), >> which is outside the realm of Babel's capabilities. >>> Hi Alex! >>> >>> I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585 is getting closer to release. Any chance you could see if >>> that works as a drop-in replacement? >> >> I've checked out the gerrit patch and managed to get it to build (it looks like there's still more work to be done to >> get tests to pass), but it doesn't seem to be working. I'm _mostly_ sure I added the relevant parts in the relevant >> places, but the new property `-Dorg.eclipse.swt.browser.DefaultType=chromium` doesn't seem to be having any effect. >> I'll keep an eye on this bug as it updates. > > :'( Chromium support has been added to SWT, and the Flamegraph should be able to display once configured. https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585 As such, there is no specific support required for Windows, and this PR can be dropped. ------------- PR: https://git.openjdk.java.net/jmc/pull/41 From aptmac at openjdk.java.net Tue Aug 25 14:22:21 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 25 Aug 2020 14:22:21 GMT Subject: Withdrawn: 6531: Make the flame chart view render labels on windows In-Reply-To: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com> References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com> Message-ID: On Wed, 22 Jan 2020 21:57:59 GMT, Alex Macdonald wrote: > This PR addresses JMC-6531 [[0]](https://bugs.openjdk.java.net/browse/JMC-6531), in which the flame chart view displays > nothing in Windows. > tl;dr: the proposed solution uses a fork of d3-flame-graph [[1]](https://github.com/aptmac/d3-flame-graph) which > substitutes the incompatible svg element with one that works with Internet Explorer, and modifies the flameviewColoring > script to work with an older ECMA version. Screenshot of Windows: > ![windows-works](https://user-images.githubusercontent.com/10425301/72937103-7cd3b900-3d36-11ea-9939-8c71880cfbee.png) > > For reference, here's the same view in Linux: > ![2020-01-22-165007_1913x1031_scrot](https://user-images.githubusercontent.com/10425301/72937506-4480aa80-3d37-11ea-9628-431f240dd457.png) > > When I had originally taken a look into the SWT Browser and compatibility with Windows, it looked as though we'd be > able to use Edge as an embedded browser, which would be nice because it already plays nice with the d3-flame-graph > library. After quite a bit of trial and error I was first able to get d3 to work (making simple line charts), and then > found that d3-flame-graph version <= 2.0.2 will work. With this older version of d3-flame-graph the coloured labels > will be drawn, but no text is shown - regardless of the SWT browser property being set to IE or Edge .. which makes it > look like Edge can be used for visiting external webpages, but not local ones (internal browser stays IE). This is > because the foreignObject element is incompatible with IE, and this has already been raised as an issue and closed as a > "wontfix" by the maintainer on the upstream repo [[2]](https://github.com/spiermar/d3-flame-graph/issues/84). I made > a fork of the d3-flame-graph repo [[1]](https://github.com/aptmac/d3-flame-graph), which accomplishes two things: > - substitutes `` for `` > [[3]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211) > - trims the text in the labels because the ellipsis css doesn't work > [[4]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238) > > This forked version of d3-flame-graph is downloaded by the maven-download-plugin like the other jslibs, and is used if > the Environment type is `WINDOWS` as detected in `FlameGraphView.java` > [[5]](https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102). > Now that the flame chart view works at this point, I had to edit `flameviewColoring.java` to be compatible with IE. > From what I can find, Internet Explorer uses JScript, which in it's latest version supports ECMA 5 > [[6]](https://en.wikipedia.org/wiki/JScript#JScript). This means no maps, no named functions, etc. Lastly, and not > completely related to this issue, I changed the name of `page.template` to `template.html` because my IDE won't provide > syntax highlighting unless the file ends with -.html, and it was a big help here. If it's deemed unecessary I can just > drop the associated commit. Let me know what you think! [0] https://bugs.openjdk.java.net/browse/JMC-6531 > [1] https://github.com/aptmac/d3-flame-graph > [2] https://github.com/spiermar/d3-flame-graph/issues/84 > [3] > https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211 > [4] > https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238 > [5] > https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102 > [6] https://en.wikipedia.org/wiki/JScript#JScript This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jmc/pull/41 From aptmac at openjdk.java.net Tue Aug 25 14:35:16 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 25 Aug 2020 14:35:16 GMT Subject: RFR: 6364: Improvements to the Thread Graph [v4] In-Reply-To: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> Message-ID: <7OwyKi4S6_1SAYdWgMOM2EdiJsJcqxCtmBgk7O8zc08=.7c5ec603-84f7-4849-978d-95274af96dd7@github.com> > This patch addresses JMC-6364 [[0]](https://bugs.openjdk.java.net/browse/JMC-6364), the epic for tracking Improvements > to the JFR Thread Graph. This RFR is also a follow-up to an RFC > [[1]](http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html) that was posted to the jmc-dev list and > incorporates the feedback that was brought up during discussion. The new design and features was imagined in > collaboration with our UX team, and the implementation has been a joint effort between myself and Jessye (@jessyec-s) - > we had been originally collaborating on a fork of the old (unofficial) JMC GitHub repo. I've folded all the commits > down into one because the older commits were merged using PRs with a similar format (e.g., `jmc/pull/23`) to this repo, > so to avoid accidental noise (sorry about that) on other PRs I've just folded them away. If anyone is interested in the > individual commits that got to this point, I've kept them around in the old repo > [[2]](https://github.com/aptmac/jmc-old/commits/jfr-threads-page). This PR aims to improve the usability and > functionality of the JFR Threads Page by extending and enhancing existing classes. In an attempt to not clutter this PR > with lots of images and explanatory text, I've created a gist > [[3]](https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36) that provides information and images/gifs of the > new components and intended functionality. Gist: https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36 > Summary of changes: > - Introduction of canvases to display the thread names (left) and timeline (bottom) > - Scrolled composites to house the text and chart canvases, for vertical scrolling of the chart area > - Timeline canvas (bottom) is draggable for panning the chart > - Current threads table has been re-located to a popup table > - New filter bar (top) which alters the chart view based on time ranges and desired visible activity lanes > - New display bar (right) which houses the zoom mechanics > - New zoom pan component for easily navigating the chart > - Introduction of a colour palette to increase contrast between neighbouring activity lanes > - Controls to change the height of the thread lanes > - updated and new uitests > > Before: > ![before](https://i.imgur.com/TNfGrtJ.png) > > After: > ![after](https://user-images.githubusercontent.com/10425301/71993902-dfd93200-3205-11ea-8249-cc50409a7a9f.png) > > Let me know if you have any questions about the design & functionality. > > [0] https://bugs.openjdk.java.net/browse/JMC-6364 > [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html > [2] https://github.com/aptmac/jmc-old/commits/jfr-threads-page > [3] https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36 Alex Macdonald has updated the pull request incrementally with one additional commit since the last revision: run mvn:spotless for uitests ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/27/files - new: https://git.openjdk.java.net/jmc/pull/27/files/031668e1..d8cfe7d4 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/27/webrev.03 - incr: https://webrevs.openjdk.java.net/jmc/27/webrev.02-03 Stats: 70 lines in 3 files changed: 1 ins; 0 del; 69 mod Patch: https://git.openjdk.java.net/jmc/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/27/head:pull/27 PR: https://git.openjdk.java.net/jmc/pull/27 From jkang at openjdk.java.net Wed Aug 26 18:25:19 2020 From: jkang at openjdk.java.net (Jie Kang) Date: Wed, 26 Aug 2020 18:25:19 GMT Subject: RFR: 6897: Remove unused javax imports Message-ID: JMC seemed to run fine with this patch. I was able to use the MXBeanBrowser, dump a flight recording of JMC and view the flight recording. ------------- Commit messages: - 6897: Remove unused javax imports Changes: https://git.openjdk.java.net/jmc/pull/106/files Webrev: https://webrevs.openjdk.java.net/jmc/106/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6897 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/106.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/106/head:pull/106 PR: https://git.openjdk.java.net/jmc/pull/106 From github.com+803621+bric3 at openjdk.java.net Sat Aug 29 14:24:57 2020 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Sat, 29 Aug 2020 14:24:57 GMT Subject: RFR: 6364: Improvements to the Thread Graph In-Reply-To: References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com> <1rFwH_fS08Lr6VT09rAPl5aOjeoDyyfAK1l1DaktMB8=.e94b0d05-4244-46b2-848e-c83f7aa3917a@github.com> Message-ID: On Tue, 25 Aug 2020 14:18:02 GMT, Alex Macdonald wrote: >> Hi just for the record how this is handled when there's a lot of threads to deal with. >> >> ![image](https://user-images.githubusercontent.com/803621/84946230-a8da4700-b0e8-11ea-9058-54a51490fd5a.png) > > Hi everyone, > > The following commits update this PR based on the feedback on the Threads Page document (posted in Slack) [0], and then > rebased to sit ontop of the current master branch. > The major changes include: > - reverting some of the colour palette modifications to restore "urgency" of some colours > - removal of the right-side toolbar and migrating its controls to the top bar > - setting the minimum readible lane height by default & fixing the lane height controls > - adding functionality for an "legacy" zoomed out mode of one-past the minimum lane height, which mimics the current > threads page display (including restoring the mousewheel zoom in this mode) > - the popup table has been reworked to be a foldable table with an implementation based off an old JMC-6368 proposed patch > - placing the new threads page implementation into it's own page, so the current and new pages can live simultaneously > > Here's a handful of screenshots and gifs showing the new modifications: > > Threads Page (Linux): > ![0-overview](https://user-images.githubusercontent.com/10425301/91185566-fdd3a400-e6bb-11ea-82f6-bb3f0abc3260.png) > > Threads Page (Windows): > ![0-windows](https://user-images.githubusercontent.com/10425301/91185573-00ce9480-e6bc-11ea-86d5-ca3be0b426f2.png) > > Overview Mode (Linux): > ![2-legacy-mode](https://user-images.githubusercontent.com/10425301/91185593-05934880-e6bc-11ea-9164-9be5f0dbd2bc.png) > > Legacy Page (Linux): > ![3-legacy-page](https://user-images.githubusercontent.com/10425301/91185646-1a6fdc00-e6bc-11ea-854f-660574e7b4c9.png) > > Gif of the overview mode toggle (Linux): > ![legacy-mode](https://user-images.githubusercontent.com/10425301/91185675-2065bd00-e6bc-11ea-97ea-de2c74bc15fe.gif) > > Gif of the foldable table and lane selection (Linux): > ![fold-table](https://user-images.githubusercontent.com/10425301/91185707-278ccb00-e6bc-11ea-9581-dd8925ea94f9.gif) > > As usual, I've been testing the functionality and behavior on my Linux & Windows machines, and they work okay from what > I've seen. If someone could double-check that this behaves as expected on a Mac it'd be greatly appreciated. > [0] https://docs.google.com/document/d/1fY5xXJKcg84vLGySzOZ7JjVqvZyZeSsGq7syTK5ETCM/edit > [1] https://bugs.openjdk.java.net/browse/JMC-6368 Hi I just wanted to give it a try but JMC keeps complaining about missing JDK. $ ./target/products/org.openjdk.jmc/macosx/cocoa/x86_64/JDK\ Mission\ Control.app/Contents/MacOS/jmc -vm /Users/bric3/.asdf/installs/java/corretto-8.262.10.1/bin/ Started recording 1. Use jcmd 79275 JFR.dump name=JMC_Default filename=FILEPATH to copy recording data to file. No Java runtime present, requesting install. Any idea how to make this work ? ------------- PR: https://git.openjdk.java.net/jmc/pull/27 From github.com+803621+bric3 at openjdk.java.net Sun Aug 30 12:47:45 2020 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Sun, 30 Aug 2020 12:47:45 GMT Subject: RFR: 6364: Improvements to the Thread Graph In-Reply-To: References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com> <1rFwH_fS08Lr6VT09rAPl5aOjeoDyyfAK1l1DaktMB8=.e94b0d05-4244-46b2-848e-c83f7aa3917a@github.com> Message-ID: On Sat, 29 Aug 2020 14:22:20 GMT, Brice Dutheil wrote: >> Hi everyone, >> >> The following commits update this PR based on the feedback on the Threads Page document (posted in Slack) [0], and then >> rebased to sit ontop of the current master branch. >> The major changes include: >> - reverting some of the colour palette modifications to restore "urgency" of some colours >> - removal of the right-side toolbar and migrating its controls to the top bar >> - setting the minimum readible lane height by default & fixing the lane height controls >> - adding functionality for an "legacy" zoomed out mode of one-past the minimum lane height, which mimics the current >> threads page display (including restoring the mousewheel zoom in this mode) >> - the popup table has been reworked to be a foldable table with an implementation based off an old JMC-6368 proposed patch >> - placing the new threads page implementation into it's own page, so the current and new pages can live simultaneously >> >> Here's a handful of screenshots and gifs showing the new modifications: >> >> Threads Page (Linux): >> ![0-overview](https://user-images.githubusercontent.com/10425301/91185566-fdd3a400-e6bb-11ea-82f6-bb3f0abc3260.png) >> >> Threads Page (Windows): >> ![0-windows](https://user-images.githubusercontent.com/10425301/91185573-00ce9480-e6bc-11ea-86d5-ca3be0b426f2.png) >> >> Overview Mode (Linux): >> ![2-legacy-mode](https://user-images.githubusercontent.com/10425301/91185593-05934880-e6bc-11ea-9164-9be5f0dbd2bc.png) >> >> Legacy Page (Linux): >> ![3-legacy-page](https://user-images.githubusercontent.com/10425301/91185646-1a6fdc00-e6bc-11ea-854f-660574e7b4c9.png) >> >> Gif of the overview mode toggle (Linux): >> ![legacy-mode](https://user-images.githubusercontent.com/10425301/91185675-2065bd00-e6bc-11ea-97ea-de2c74bc15fe.gif) >> >> Gif of the foldable table and lane selection (Linux): >> ![fold-table](https://user-images.githubusercontent.com/10425301/91185707-278ccb00-e6bc-11ea-9581-dd8925ea94f9.gif) >> >> As usual, I've been testing the functionality and behavior on my Linux & Windows machines, and they work okay from what >> I've seen. If someone could double-check that this behaves as expected on a Mac it'd be greatly appreciated. >> [0] https://docs.google.com/document/d/1fY5xXJKcg84vLGySzOZ7JjVqvZyZeSsGq7syTK5ETCM/edit >> [1] https://bugs.openjdk.java.net/browse/JMC-6368 > > EDIT I'm able to open JDK Mission Control, just not from the command line but from the Finder. I'll test the thread > view in the comming days. > First good news, it's able to open recording where the thread view didn't work before, because there was too many > threads. However the UI is slow. > ---- > > Hi I just wanted to give it a try but JMC keeps complaining about missing JDK. > > $ ./target/products/org.openjdk.jmc/macosx/cocoa/x86_64/JDK\ Mission\ Control.app/Contents/MacOS/jmc -vm > /Users/bric3/.asdf/installs/java/corretto-8.262.10.1/bin/ Started recording 1. > > Use jcmd 79275 JFR.dump name=JMC_Default filename=FILEPATH to copy recording data to file. > No Java runtime present, requesting install. > > Any idea how to make this work ? Hi, I noticed that when selecting a part of thread lane, like an event, then the cell/label is half dimed : JFR thread top half JFR thread bottom half ------------- PR: https://git.openjdk.java.net/jmc/pull/27 From github.com+803621+bric3 at openjdk.java.net Sun Aug 30 13:14:40 2020 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Sun, 30 Aug 2020 13:14:40 GMT Subject: RFR: 6364: Improvements to the Thread Graph In-Reply-To: References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com> <1rFwH_fS08Lr6VT09rAPl5aOjeoDyyfAK1l1DaktMB8=.e94b0d05-4244-46b2-848e-c83f7aa3917a@github.com> Message-ID: On Sun, 30 Aug 2020 12:45:38 GMT, Brice Dutheil wrote: >> EDIT I'm able to open JDK Mission Control, just not from the command line but from the Finder. I'll test the thread >> view in the comming days. >> First good news, it's able to open recording where the thread view didn't work before, because there was too many >> threads. However the UI is slow. >> ---- >> >> Hi I just wanted to give it a try but JMC keeps complaining about missing JDK. >> >> $ ./target/products/org.openjdk.jmc/macosx/cocoa/x86_64/JDK\ Mission\ Control.app/Contents/MacOS/jmc -vm >> /Users/bric3/.asdf/installs/java/corretto-8.262.10.1/bin/ Started recording 1. >> >> Use jcmd 79275 JFR.dump name=JMC_Default filename=FILEPATH to copy recording data to file. >> No Java runtime present, requesting install. >> >> Any idea how to make this work ? > > Hi, I noticed that when selecting a part of thread lane, like an event, then the cell/label is half dimed : > > JFR thread top half src="https://user-images.githubusercontent.com/803621/91659293-3665ea00-eacf-11ea-9fa7-0b86db536590.png"> width="684" alt="JFR thread bottom half" > src="https://user-images.githubusercontent.com/803621/91659298-37971700-eacf-11ea-8c53-d99cf9e1f4ea.png"> I also noticed that the overview mode indicates "too much content", for recording of applications having a high number of threads. And when the display area is not big enough, e.g. on 13 inches laptop or when the thread table is expanded. ![too much content on overview, thread table expanded](https://user-images.githubusercontent.com/803621/91659801-7a0e2300-ead2-11ea-911b-ebf4e79d3228.png) ![overview ok, external screen, thread table hidden](https://user-images.githubusercontent.com/803621/91659799-72e71500-ead2-11ea-8ebf-7433031fae2b.png) ------------- PR: https://git.openjdk.java.net/jmc/pull/27