From guru.hb at oracle.com Mon Jul 2 08:57:40 2018 From: guru.hb at oracle.com (guru.hb at oracle.com) Date: Mon, 02 Jul 2018 08:57:40 +0000 Subject: hg: jmc/jmc: JMC-6057: Update Platform definition to photon Message-ID: <201807020857.w628vfnk011757@aojmv0008.oracle.com> Changeset: fdd143d6ff86 Author: ghb Date: 2018-07-02 14:27 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/fdd143d6ff86 JMC-6057: Update Platform definition to photon Reviewed-by: hirt ! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target From marcus.hirt at oracle.com Mon Jul 2 13:37:49 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Mon, 02 Jul 2018 15:37:49 +0200 Subject: Review request for re-opened 6050: test failure. Message-ID: <2721410E-F603-436B-B7CD-F42A6EB82B16@oracle.com> Hi all, I re-opened JMC-6050 since a related test had not been fixed. I also cleaned up a little bit. Would appreciate a review: http://cr.openjdk.java.net/~hirt/JMC-6050/webrev.2/ Things that would be good to do at a later point: Rename EventAvailability.NONE (perhaps to EventAvailability.UNAVAILABLE, but that may be too confusing for historical reasons). Consider switching NONE and DISABLED?s availability score (care must be taken so that current code does not rely on the current ordering). (The whole RulesToolkit class could benefit from some cleanup and optimization.) Kind regards, Marcus From jayathirth.d.v at oracle.com Mon Jul 2 15:14:34 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 2 Jul 2018 08:14:34 -0700 (PDT) Subject: Review request for re-opened 6050: test failure. In-Reply-To: <2721410E-F603-436B-B7CD-F42A6EB82B16@oracle.com> References: <2721410E-F603-436B-B7CD-F42A6EB82B16@oracle.com> Message-ID: <46bdbe21-6a6e-40f8-872f-394d05828b3b@default> Hi Marcus, Please find my observation: When I ran unit tests with latest code from http://hg.openjdk.java.net/jmc/jmc/ I saw ?org.openjdk.jmc.flightrecorder.rules.jdk.test? failing in the morning. After applying your changes there are no unit test failures. Also I see that the newly added RulesToolkit.isMoreAvailableThan() is not used and we are using only RulesToolkit.isLessAvailableThan() in RulesToolkit. getLeastAvailable(). We can remove RulesToolkit.isMoreAvailableThan() function and clarify @return Java documentation comment of RulesToolkit.isLessAvailableThan() with " true if this EventAvailability is less available than the provided one, else return false" Thanks, Jay -----Original Message----- From: Marcus Hirt Sent: Monday, July 02, 2018 7:08 PM To: jmc-dev at openjdk.java.net Subject: Review request for re-opened 6050: test failure. Hi all, I re-opened JMC-6050 since a related test had not been fixed. I also cleaned up a little bit. Would appreciate a review: http://cr.openjdk.java.net/~hirt/JMC-6050/webrev.2/ Things that would be good to do at a later point: Rename EventAvailability.NONE (perhaps to EventAvailability.UNAVAILABLE, but that may be too confusing for historical reasons). Consider switching NONE and DISABLED?s availability score (care must be taken so that current code does not rely on the current ordering). (The whole RulesToolkit class could benefit from some cleanup and optimization.) Kind regards, Marcus From sharath.ballal at oracle.com Mon Jul 2 15:59:12 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 2 Jul 2018 08:59:12 -0700 (PDT) Subject: Review request for re-opened 6050: test failure. In-Reply-To: <2721410E-F603-436B-B7CD-F42A6EB82B16@oracle.com> References: <2721410E-F603-436B-B7CD-F42A6EB82B16@oracle.com> Message-ID: <133aad89-68a9-4c51-922e-bf5e54708bf4@default> Looks good Marcus. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Monday, July 02, 2018 7:08 PM To: jmc-dev at openjdk.java.net Subject: Review request for re-opened 6050: test failure. Hi all, I re-opened JMC-6050 since a related test had not been fixed. I also cleaned up a little bit. Would appreciate a review: http://cr.openjdk.java.net/~hirt/JMC-6050/webrev.2/ Things that would be good to do at a later point: Rename EventAvailability.NONE (perhaps to EventAvailability.UNAVAILABLE, but that may be too confusing for historical reasons). Consider switching NONE and DISABLED?s availability score (care must be taken so that current code does not rely on the current ordering). (The whole RulesToolkit class could benefit from some cleanup and optimization.) Kind regards, Marcus From marcus.hirt at oracle.com Mon Jul 2 16:03:58 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Mon, 02 Jul 2018 18:03:58 +0200 Subject: Review request for re-opened 6050: test failure. In-Reply-To: References: <2721410E-F603-436B-B7CD-F42A6EB82B16@oracle.com> Message-ID: Hi Jay, Thanks for the reviews! I'll go ahead and check this in with the suggested change. Kind regards, Marcus ?On 2018-07-02, 17:14, "Jayathirth D V" wrote: Hi Marcus, Please find my observation: When I ran unit tests with latest code from http://hg.openjdk.java.net/jmc/jmc/ I saw ?org.openjdk.jmc.flightrecorder.rules.jdk.test? failing in the morning. After applying your changes there are no unit test failures. Also I see that the newly added RulesToolkit.isMoreAvailableThan() is not used and we are using only RulesToolkit.isLessAvailableThan() in RulesToolkit. getLeastAvailable(). We can remove RulesToolkit.isMoreAvailableThan() function and clarify @return Java documentation comment of RulesToolkit.isLessAvailableThan() with " true if this EventAvailability is less available than the provided one, else return false" Thanks, Jay -----Original Message----- From: Marcus Hirt Sent: Monday, July 02, 2018 7:08 PM To: jmc-dev at openjdk.java.net Subject: Review request for re-opened 6050: test failure. Hi all, I re-opened JMC-6050 since a related test had not been fixed. I also cleaned up a little bit. Would appreciate a review: http://cr.openjdk.java.net/~hirt/JMC-6050/webrev.2/ Things that would be good to do at a later point: Rename EventAvailability.NONE (perhaps to EventAvailability.UNAVAILABLE, but that may be too confusing for historical reasons). Consider switching NONE and DISABLED?s availability score (care must be taken so that current code does not rely on the current ordering). (The whole RulesToolkit class could benefit from some cleanup and optimization.) Kind regards, Marcus From marcus.hirt at oracle.com Mon Jul 2 16:10:36 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Mon, 02 Jul 2018 16:10:36 +0000 Subject: hg: jmc/jmc: JMC-6050: Fixing tests and cleanup. Message-ID: <201807021610.w62GAaXR008061@aojmv0008.oracle.com> Changeset: 0d435f78ae78 Author: hirt Date: 2018-07-02 18:10 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/0d435f78ae78 JMC-6050: Fixing tests and cleanup. Reviewed-by: sballal,jdv ! application/org.openjdk.jmc.flightrecorder.ext.jfx/src/main/java/org/openjdk/jmc/flightrecorder/ext/jfx/JfxPulseDurationRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLoadingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DMSIncidentRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DiscouragedGcOptionsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DiscouragedVmOptionsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ManagementAgentRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/RecordingSettingsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/io/FileReadRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/BiasedLockingRevocationPauseRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/BiasedLockingRevocationRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/VMOperationRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AllocationByClassRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AllocationByThreadRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GcLockerRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/HighGcRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/IncreasingLiveSetRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/IncreasingMetaspaceLiveSetRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/LongGcPauseRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/MetaspaceOomRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/TlabAllocationRatioRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml From marcus.hirt at oracle.com Mon Jul 2 18:04:28 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Mon, 02 Jul 2018 20:04:28 +0200 Subject: Review request for JMC-5617: Better icon for the Threads page. Message-ID: <29C9DC95-7420-40D5-BCAF-9C571B64E5A9@oracle.com> Hi all, Small change to use the old Thread Graph icon for the Threads page: Jira: https://bugs.openjdk.java.net/browse/JMC-5617 Webrev: http://cr.openjdk.java.net/~hirt/JMC-5617/webrev.0/ Kind regards, Marcus From guru.hb at oracle.com Tue Jul 3 05:31:35 2018 From: guru.hb at oracle.com (Guru) Date: Tue, 3 Jul 2018 11:01:35 +0530 Subject: Review request for JMC-5617: Better icon for the Threads page. In-Reply-To: <29C9DC95-7420-40D5-BCAF-9C571B64E5A9@oracle.com> References: <29C9DC95-7420-40D5-BCAF-9C571B64E5A9@oracle.com> Message-ID: <5DA9DAE0-6143-4E97-B7F0-06C5971ACEFF@oracle.com> +1, Looks good to me. -Guru > On 02-Jul-2018, at 11:34 PM, Marcus Hirt wrote: > > Hi all, > > Small change to use the old Thread Graph icon for the Threads page: > > Jira: https://bugs.openjdk.java.net/browse/JMC-5617 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-5617/webrev.0/ > > Kind regards, > Marcus > > From sharath.ballal at oracle.com Tue Jul 3 10:55:12 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 3 Jul 2018 03:55:12 -0700 (PDT) Subject: Review request for JMC-5617: Better icon for the Threads page. In-Reply-To: <29C9DC95-7420-40D5-BCAF-9C571B64E5A9@oracle.com> References: <29C9DC95-7420-40D5-BCAF-9C571B64E5A9@oracle.com> Message-ID: Looks good Marcus. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Monday, July 02, 2018 11:34 PM To: jmc-dev at openjdk.java.net Subject: Review request for JMC-5617: Better icon for the Threads page. Hi all, Small change to use the old Thread Graph icon for the Threads page: Jira: https://bugs.openjdk.java.net/browse/JMC-5617 Webrev: http://cr.openjdk.java.net/~hirt/JMC-5617/webrev.0/ Kind regards, Marcus From marcus.hirt at oracle.com Tue Jul 3 10:57:08 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 03 Jul 2018 12:57:08 +0200 Subject: Summer review policy for the JMC project. Message-ID: <4B26CCB6-ECE6-4FA2-BD1C-FEA10DBD0DC2@oracle.com> Hi all, Over the summer I suggest that we, in addition to the normal review policy (a single Reviewer reviewing contributions to JMC), also allow the following review policy: Two people that are not reviewers, but that are (1) involved in the JMC- project, and that are (2) on the OpenJDK Census, can perform a review. Please let me know what you think! Kind regards, Marcus From marcus.hirt at oracle.com Tue Jul 3 11:01:59 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 03 Jul 2018 11:01:59 +0000 Subject: hg: jmc/jmc: JMC-5617: Using the old Thread Graph icon for the Threads page Message-ID: <201807031101.w63B1xGr016107@aojmv0008.oracle.com> Changeset: 26fffc578721 Author: hirt Date: 2018-07-03 13:01 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/26fffc578721 JMC-5617: Using the old Thread Graph icon for the Threads page Reviewed-by: ghb,sballal + application/org.openjdk.jmc.flightrecorder.ui/icons/pages/threadgraph.png - application/org.openjdk.jmc.flightrecorder.ui/icons/threadgraph_16x16.gif ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ImageConstants.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java From neugens at redhat.com Tue Jul 3 11:01:27 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 3 Jul 2018 13:01:27 +0200 Subject: Summer review policy for the JMC project. In-Reply-To: <4B26CCB6-ECE6-4FA2-BD1C-FEA10DBD0DC2@oracle.com> References: <4B26CCB6-ECE6-4FA2-BD1C-FEA10DBD0DC2@oracle.com> Message-ID: On Tue, Jul 3, 2018 at 12:57 PM, Marcus Hirt wrote: > Hi all, > > Over the summer I suggest that we, in addition to the normal review policy (a > single Reviewer reviewing contributions to JMC), also allow the following > review policy: > > Two people that are not reviewers, but that are (1) involved in the JMC- > project, and that are (2) on the OpenJDK Census, can perform a review. > > Please let me know what you think! Hello Marcus, Makes sense! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From klara at kth.se Tue Jul 3 11:31:55 2018 From: klara at kth.se (Klara Ward) Date: Tue, 3 Jul 2018 13:31:55 +0200 Subject: Summer review policy for the JMC project. In-Reply-To: References: <4B26CCB6-ECE6-4FA2-BD1C-FEA10DBD0DC2@oracle.com> Message-ID: <5978A38C-6EC2-4683-A484-1A022D0609C5@kth.se> Makes sense to me. Are those people a few known individuals? // Klara > 3 juli 2018 kl. 13:01 skrev Mario Torre : > >> On Tue, Jul 3, 2018 at 12:57 PM, Marcus Hirt wrote: >> Hi all, >> >> Over the summer I suggest that we, in addition to the normal review policy (a >> single Reviewer reviewing contributions to JMC), also allow the following >> review policy: >> >> Two people that are not reviewers, but that are (1) involved in the JMC- >> project, and that are (2) on the OpenJDK Census, can perform a review. >> >> Please let me know what you think! > > Hello Marcus, > > Makes sense! > > Cheers, > Mario > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Tue Jul 3 11:45:14 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 03 Jul 2018 13:45:14 +0200 Subject: Summer review policy for the JMC project. In-Reply-To: <9F82C687-C1A8-44D6-AA16-27F85A9BD9DE@kth.se> References: <4B26CCB6-ECE6-4FA2-BD1C-FEA10DBD0DC2@oracle.com> <9F82C687-C1A8-44D6-AA16-27F85A9BD9DE@kth.se> Message-ID: <58DDCF2F-11B2-41B1-A74C-09A1994C46C4@oracle.com> Off the top of my head: Mario, Sharath, Guru and Jay. Could be more. Kind regards, Marcus ?On 2018-07-03, 13:32, "Klara Ward" wrote: Makes sense to me. Are those people a few known individuals? // Klara > 3 juli 2018 kl. 13:01 skrev Mario Torre : > >> On Tue, Jul 3, 2018 at 12:57 PM, Marcus Hirt wrote: >> Hi all, >> >> Over the summer I suggest that we, in addition to the normal review policy (a >> single Reviewer reviewing contributions to JMC), also allow the following >> review policy: >> >> Two people that are not reviewers, but that are (1) involved in the JMC- >> project, and that are (2) on the OpenJDK Census, can perform a review. >> >> Please let me know what you think! > > Hello Marcus, > > Makes sense! > > Cheers, > Mario > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Tue Jul 3 11:49:07 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 03 Jul 2018 13:49:07 +0200 Subject: Review request for JMC-6060: Enabling support for cleanup.remove_redundant_modifiers Message-ID: <82633054-5DFA-4997-BE73-49C2F1B6F1CB@oracle.com> Hi all, Eclipse Photon has a nice cleanup feature for removing redundant modifiers. It should be enabled in the template: Jira: https://bugs.openjdk.java.net/browse/JMC-6060 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6060/webrev.0/ Kind regards, Marcus From guru.hb at oracle.com Tue Jul 3 11:53:11 2018 From: guru.hb at oracle.com (Guru) Date: Tue, 3 Jul 2018 17:23:11 +0530 Subject: Review request for JMC-6060: Enabling support for cleanup.remove_redundant_modifiers In-Reply-To: <82633054-5DFA-4997-BE73-49C2F1B6F1CB@oracle.com> References: <82633054-5DFA-4997-BE73-49C2F1B6F1CB@oracle.com> Message-ID: <4E34F803-F8CC-4409-B907-79F8F93FD163@oracle.com> +1, Looks good to me. -Guru > On 03-Jul-2018, at 5:19 PM, Marcus Hirt wrote: > > https://bugs.openjdk.java.net/browse/JMC-6060 From sharath.ballal at oracle.com Tue Jul 3 11:57:35 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 3 Jul 2018 04:57:35 -0700 (PDT) Subject: Review request for JMC-6060: Enabling support for cleanup.remove_redundant_modifiers In-Reply-To: <82633054-5DFA-4997-BE73-49C2F1B6F1CB@oracle.com> References: <82633054-5DFA-4997-BE73-49C2F1B6F1CB@oracle.com> Message-ID: Looks good Marcus. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Tuesday, July 03, 2018 5:19 PM To: jmc-dev at openjdk.java.net Subject: Review request for JMC-6060: Enabling support for cleanup.remove_redundant_modifiers Hi all, Eclipse Photon has a nice cleanup feature for removing redundant modifiers. It should be enabled in the template: Jira: https://bugs.openjdk.java.net/browse/JMC-6060 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6060/webrev.0/ Kind regards, Marcus From marcus.hirt at oracle.com Tue Jul 3 12:08:12 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 03 Jul 2018 12:08:12 +0000 Subject: hg: jmc/jmc: JMC-6060: Enabling removal of redundant modifiers in the cleanup template Message-ID: <201807031208.w63C8Ck2006304@aojmv0008.oracle.com> Changeset: d8e7505ee14e Author: hirt Date: 2018-07-03 14:08 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/d8e7505ee14e JMC-6060: Enabling removal of redundant modifiers in the cleanup template Reviewed-by: ghb,sballal ! configuration/ide/eclipse/formatting/clean-up-with-formatting.xml From marcus.hirt at oracle.com Tue Jul 3 12:51:09 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 03 Jul 2018 14:51:09 +0200 Subject: Review request for JMC-6061: running cleanup on core Message-ID: <68652756-98BA-45C6-9551-DD040BFE0520@oracle.com> Hi all, This patch is not quite as scary as it looks. Many files have whitespace changes only. That said, I'd rather do these changes as early as possible. Jira: https://bugs.openjdk.java.net/browse/JMC-6061 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6061/webrev.0/ Kind regards, Marcus From neugens at redhat.com Tue Jul 3 13:36:52 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 3 Jul 2018 15:36:52 +0200 Subject: Review request for JMC-6061: running cleanup on core In-Reply-To: <68652756-98BA-45C6-9551-DD040BFE0520@oracle.com> References: <68652756-98BA-45C6-9551-DD040BFE0520@oracle.com> Message-ID: On Tue, Jul 3, 2018 at 2:51 PM, Marcus Hirt wrote: > Hi all, > > This patch is not quite as scary as it looks. Many files have whitespace > changes only. That said, I'd rather do these changes as early as possible. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6061 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6061/webrev.0/ > > Kind regards, > Marcus Hi Marcus, I pick an easy one for the start :) The patch looks generally good (well, as you say is mostly about white spaces), I have a question though, do we have a coding guidelines? For instance, we are aligning now the enum fields to the same column and the start of the definition, is that the recommended style? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Tue Jul 3 14:55:06 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 03 Jul 2018 16:55:06 +0200 Subject: Review request for JMC-6061: running cleanup on core In-Reply-To: References: <68652756-98BA-45C6-9551-DD040BFE0520@oracle.com> Message-ID: <37541C83-86BD-4EB0-B6E4-40A2CF832B6A@oracle.com> Hi Mario, There is a style guide. The formatting parts are encoded into the formatting settings (configuration/ide/eclipse/formatting/formatting.xml). There are other parts to the style guide too, as how to handle acronyms/initialisms (there will probably be a check-in soon that will correct some wrongly named classes). I will try to update the wiki with style guide elements. Kind regards, Marcus ?On 2018-07-03, 15:42, "Mario Torre" wrote: On Tue, Jul 3, 2018 at 2:51 PM, Marcus Hirt wrote: > Hi all, > > This patch is not quite as scary as it looks. Many files have whitespace > changes only. That said, I'd rather do these changes as early as possible. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6061 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6061/webrev.0/ > > Kind regards, > Marcus Hi Marcus, I pick an easy one for the start :) The patch looks generally good (well, as you say is mostly about white spaces), I have a question though, do we have a coding guidelines? For instance, we are aligning now the enum fields to the same column and the start of the definition, is that the recommended style? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jayathirth.d.v at oracle.com Tue Jul 3 17:41:04 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 3 Jul 2018 10:41:04 -0700 (PDT) Subject: Review request for JMC-6061: running cleanup on core In-Reply-To: <68652756-98BA-45C6-9551-DD040BFE0520@oracle.com> References: <68652756-98BA-45C6-9551-DD040BFE0520@oracle.com> Message-ID: Hi Marcus, Since it is a cleanup task and number of files is huge, I didn't go through all the files. I imported your changes and verified for build and unit tests in my Windows 7 machine and there are no failures. Changes are fine. Thanks, Jay -----Original Message----- From: Marcus Hirt Sent: Tuesday, July 03, 2018 6:21 PM To: jmc-dev at openjdk.java.net Subject: Review request for JMC-6061: running cleanup on core Hi all, This patch is not quite as scary as it looks. Many files have whitespace changes only. That said, I'd rather do these changes as early as possible. Jira: https://bugs.openjdk.java.net/browse/JMC-6061 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6061/webrev.0/ Kind regards, Marcus From marcus.hirt at oracle.com Tue Jul 3 18:47:59 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 03 Jul 2018 18:47:59 +0000 Subject: hg: jmc/jmc: JMC-6061: Running cleanup on the core projects Message-ID: <201807031847.w63IlxJZ017095@aojmv0008.oracle.com> Changeset: 6a85b8897212 Author: hirt Date: 2018-07-03 20:47 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/6a85b8897212 JMC-6061: Running cleanup on the core projects Reviewed-by: neugens,jdv ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IDescribable.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IDisplayable.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCClassLoader.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCFrame.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCMethod.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCModule.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCOldObject.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCOldObjectArray.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCOldObjectField.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCOldObjectGcRoot.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCPackage.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCStackTrace.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCThread.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCThreadGroup.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IMCType.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IPredicate.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IState.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IStateful.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/IWritableState.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/AbstractIterator.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/ArrayToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/BoundedList.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/EntryHashMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/FastAccessNumberMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/IteratorToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/KeyInValueMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/ListToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/MapToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/collection/SimpleArray.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/io/IOToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/io/ValidatingObjectInputStream.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/AccessorKey.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/Aggregators.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/Attribute.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/CachingAccessor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/CanonicalAccessorFactory.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/GroupingAggregator.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IAccessorFactory.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IAccessorKey.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IAggregator.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IAttribute.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/ICanonicalAccessorFactory.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItem.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemCollection.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemConsumer.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemConsumerFactory.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemFilter.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemIterable.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemQuery.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IMemberAccessor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IType.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IValueBuilder.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/ItemFilters.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/ItemQueryBuilder.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/ItemToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/PersistableItemFilter.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/RangeMatchPolicy.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/package-info.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/messages/internal/Messages.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/package-info.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/BinaryPrefix.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/BinaryScaleFactor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/BinaryUnitSelector.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/ComparableConstraint.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/ContentType.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/CustomUnitSelector.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/DecimalPrefix.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/DecimalScaleFactor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/DecimalUnitSelector.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/DisplayFormatter.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IConstrainedMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IConstraint.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IDescribedMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IFormatter.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IIncrementalFormatter.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IMutableConstrainedMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IOptionDescriptor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IPersister.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IPrefix.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IQuantity.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IRange.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IScalarAffineTransform.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/ITypedQuantity.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/IUnit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/ImpreciseScaleFactor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/KindOfQuantity.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/LinearKindOfQuantity.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/LinearUnit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/LongPostOffsetTransform.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/LongPreOffsetTransform.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/LongScaleFactor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/MutableConstrainedMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/QuantitiesToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/QuantityConversionException.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/QuantityRange.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/RangeContentType.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/ScalarQuantity.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/ScaleFactor.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/SimpleAffineTransform.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/SimpleConstrainedMap.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/StructContentType.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampKind.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampUnit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TypedUnit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/UnitLookup.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/WrappingPersister.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/package-info.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/ColorToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/CompositeKey.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/ExceptionToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/FormatThreadLocal.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/FormatToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/IPreferenceValueProvider.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/LabeledIdentifier.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MCClassLoader.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MCFrame.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MCMethod.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MCOldObject.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MCPackage.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MCStackTrace.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MCType.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MemberAccessorToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MethodToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/Pair.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/PredicateToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/SortedHead.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/StateElement.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/StateElementWriter.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/StateToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/StatefulState.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/StringToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypedPreference.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/XmlToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/version/JavaVMVersionToolkit.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/version/JavaVersion.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/version/JavaVersionSupport.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/version/package-info.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/RulePreferences.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/combine/Combinable.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/combine/Combiner.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/combine/SpanLimit.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/combine/SpanSquare.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/combine/SpanToolkit.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/compilation/CodeCacheRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/cpu/CompareCpuRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/cpu/HighJvmCpuRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/cpu/ManyRunningProcessesRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/HaltsProvider.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/JvmInternalsDataProvider.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/MethodProfilingDataProvider.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/ObjectStatisticsDataProvider.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/StacktraceDataProvider.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/exceptions/ErrorRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/exceptions/ExceptionRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/BufferLostRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLoadingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DMSIncidentRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DebugNonSafepointsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DiscouragedGcOptionsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DiscouragedVmOptionsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DumpReasonRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/FewSampledThreadsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/FlightRecordingSupportRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ManagementAgentRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/OptionsCheckRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/PasswordsInArgumentsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/PasswordsInEnvironmentRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/PasswordsInSystemPropertiesRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/RecordingSettingsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/StackDepthSettingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/VerifyNoneRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/io/FileReadRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/io/FileWriteRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/io/SocketReadRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/io/SocketWriteRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/BiasedLockingRevocationPauseRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/BiasedLockingRevocationRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/ContextSwitchRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/JavaBlockingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/MethodProfilingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/VMOperationRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AllocationByClassRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AllocationByThreadRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/ApplicationHaltsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AutoBoxingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/CollectorType.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/CompressedOopsRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GarbageCollectionsInfo.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GcFreedRatioRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GcLockerRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GcPauseRatioRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GcStallRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/HeapContentRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/HeapInspectionRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/HighGcRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/IncreasingLiveSetRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/IncreasingMetaspaceLiveSetRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/LongGcPauseRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/LowOnPhysicalMemoryRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/MetaspaceOomRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/ReferenceStatisticsType.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/StringDeduplicationRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/SystemGcRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/TlabAllocationRatioRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/ClassEntry.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/ColumnInfo.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/IItemResultSet.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/ItemResultSetException.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/ItemResultSetFactory.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/SingleEntryItemCollection.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/package-info.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/AbstractRule.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/IRule.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/Result.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/RuleRegistry.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/Severity.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/internal/IRuleProvider.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/package-info.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/report/JfrReportPermission.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/report/JfrRulesReport.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/report/html/JfrHtmlRulesReport.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/report/html/internal/HtmlResultGroup.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/report/html/internal/HtmlResultProvider.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/report/html/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/report/html/internal/RulesHtmlToolkit.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/ITreeNode.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/ITreeVisitor.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/ItemTreeBuilder.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/ItemTreeToolkit.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/Range.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/TimeRangeFilter.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/TimeRangeThreadFilter.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/TreeNode.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/traversal/BFIterator.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/traversal/BFTreeVisitor.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/traversal/DFIterator.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/traversal/DFTreeVisitor.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/traversal/LayerBreakdownGenerator.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/traversal/LayerBreakdownVisitor.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/traversal/LongestDurationIterator.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/JfrRuleTopics.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java ! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/SlidingWindowToolkit.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/CouldNotLoadRecordingException.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/EventCollection.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/JfrAttributes.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/JfrLoaderToolkit.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/RecordingPrinter.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/ChunkInfo.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/EventAppearance.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/EventArray.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/FlightRecordingLoader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/IChunkLoader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/IChunkSupplier.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/InvalidJfrFileException.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/NotEnoughMemoryException.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/VersionNotSupportedException.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/Chunk.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/ItemBuilder.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/LoaderContext.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/RepositoryBuilder.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ArrayReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/BooleanReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ChunkLoaderV0.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ChunkMetadata.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ChunkStructure.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/CompositeReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ConstantEntryList.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ConstantMap.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ConstantReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ContentTypeParser.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/DataStructureParser.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/EventParserManager.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/EventTypeParser.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/IArrayElementParser.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/IValueReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/NumberReaders.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/Offset.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ProducerParser.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/QuantityReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/ReaderFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/StringReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/TypedArrayParser.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/UTFStringParser.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/GlobalObjectPool.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/IPoolFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/JavaThreadFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/JfrThread.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/MethodFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/OSThreadFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/OldObjectFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/StackTraceFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/ThreadGroup.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/ThreadGroupFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/factories/TypeFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/model/ContentTypeDescriptor.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/model/DataStructure.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/model/DataType.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/model/EventTypeDescriptor.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/model/ProducerDescriptor.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/model/Transition.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v0/model/ValueDescriptor.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/ChunkLoaderV1.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/ChunkMetadata.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/ChunkStructure.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/IDataInput.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/SeekableInputStream.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/ValueReaders.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/util/CanonicalConstantMap.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/util/DataInputToolkit.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/util/DisjointBuilder.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/util/JfrInternalConstants.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/util/ParserToolkit.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkFilters.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkQueries.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkTypeIDs.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/memleak/ReferenceTreeModel.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/memleak/ReferenceTreeObject.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/IEventSink.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/IEventSinkFactory.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/IParserExtension.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/ParserExtensionRegistry.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/ValueField.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/filter/FilterExtension.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/filter/IOnLoadFilter.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/filter/OnLoadFilters.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/package-info.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/JdkTypeIDsPreJdk9.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/Messages.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/SettingsTransformer.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/SyntheticAttributeExtension.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/FrameSeparator.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceFormatToolkit.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceFrame.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModel.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/util/ChunkReader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/util/SplitRecording.java From guru.hb at oracle.com Fri Jul 6 04:49:56 2018 From: guru.hb at oracle.com (Guru) Date: Fri, 6 Jul 2018 10:19:56 +0530 Subject: Review request: JMC-5989: Publish nightly builds as SNAPSHOT builds on Sonatype Message-ID: <26DDADE1-10AB-4377-8CDE-2E82C1ED8C1D@oracle.com> Hi Marcus, Please review the fix for : https://bugs.openjdk.java.net/browse/JMC-5989 Webrev : http://cr.openjdk.java.net/~ghb/JMC-5989/webrev.0/ Thanks, Guru From guru.hb at oracle.com Fri Jul 6 11:32:25 2018 From: guru.hb at oracle.com (Guru) Date: Fri, 6 Jul 2018 17:02:25 +0530 Subject: Review request: JMC-5989: Publish nightly builds as SNAPSHOT builds on Sonatype In-Reply-To: <26DDADE1-10AB-4377-8CDE-2E82C1ED8C1D@oracle.com> References: <26DDADE1-10AB-4377-8CDE-2E82C1ED8C1D@oracle.com> Message-ID: <316CF758-2617-4B0D-9E1D-48819BC85A1B@oracle.com> Updated webrev : http://cr.openjdk.java.net/~ghb/JMC-5989/webrev.1/ Removed Comments, updated ?Description? and corrected the indentation. Thanks, Guru > On 06-Jul-2018, at 10:19 AM, Guru wrote: > > Hi Marcus, > > Please review the fix for : https://bugs.openjdk.java.net/browse/JMC-5989 > Webrev : http://cr.openjdk.java.net/~ghb/JMC-5989/webrev.0/ > > Thanks, > Guru From marcus.hirt at oracle.com Fri Jul 6 11:33:54 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Fri, 06 Jul 2018 13:33:54 +0200 Subject: Review request: JMC-5989: Publish nightly builds as SNAPSHOT builds on Sonatype In-Reply-To: <9884187D-EABC-4C21-B330-A3F87BEBB860@oracle.com> References: <26DDADE1-10AB-4377-8CDE-2E82C1ED8C1D@oracle.com> <9884187D-EABC-4C21-B330-A3F87BEBB860@oracle.com> Message-ID: <2B4F9EEE-3164-4E34-90F4-12DB840EAF6B@oracle.com> Looks good! /M From: Guru Date: Friday, 6 July 2018 at 13:32 To: Marcus Hirt , Sharath Ballal , Jayathirth D V Cc: Subject: Re: Review request: JMC-5989: Publish nightly builds as SNAPSHOT builds on Sonatype Updated webrev :?http://cr.openjdk.java.net/~ghb/JMC-5989/webrev.1/? Removed Comments, updated ?Description? and corrected the indentation.? Thanks, Guru On 06-Jul-2018, at 10:19 AM, Guru wrote: Hi Marcus, Please review the fix for :?https://bugs.openjdk.java.net/browse/JMC-5989 Webrev :?http://cr.openjdk.java.net/~ghb/JMC-5989/webrev.0/? Thanks, Guru From guru.hb at oracle.com Fri Jul 6 13:47:06 2018 From: guru.hb at oracle.com (guru.hb at oracle.com) Date: Fri, 06 Jul 2018 13:47:06 +0000 Subject: hg: jmc/jmc: JMC-5989: Publish nightly builds as SNAPSHOT builds on Sonatype Message-ID: <201807061347.w66Dl6ST004653@aojmv0008.oracle.com> Changeset: 0da02fdc014d Author: ghb Date: 2018-07-06 19:16 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/0da02fdc014d JMC-5989: Publish nightly builds as SNAPSHOT builds on Sonatype Reviewed-by: hirt ! core/org.openjdk.jmc.agent/pom.xml ! core/org.openjdk.jmc.common/pom.xml ! core/org.openjdk.jmc.flightrecorder.rules.jdk/pom.xml ! core/org.openjdk.jmc.flightrecorder.rules/pom.xml ! core/org.openjdk.jmc.flightrecorder/pom.xml ! pom.xml From guru.hb at oracle.com Tue Jul 10 10:05:08 2018 From: guru.hb at oracle.com (Guru) Date: Tue, 10 Jul 2018 15:35:08 +0530 Subject: Review request: JMC-6072: Incorrect artifactId for snapshot build Message-ID: <45274D0E-0336-4396-A6B7-77C5D7A72993@oracle.com> Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JMC-6072 webrev : http://cr.openjdk.java.net/~ghb/JMC-6072/webrev.0 Thanks, Guru From marcus.hirt at oracle.com Tue Jul 10 20:30:48 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 10 Jul 2018 22:30:48 +0200 Subject: Review request: JMC-6072: Incorrect artifactId for snapshot build In-Reply-To: <677C3E50-4300-4222-A034-7603EE35967B@oracle.com> References: <677C3E50-4300-4222-A034-7603EE35967B@oracle.com> Message-ID: <5639AF97-4EAB-40BC-A32D-7488B257D45A@oracle.com> On vacation here, but shouldn?t the Bundle-SymbolicNames remain the way they are? Or in other words, when I have an OSGi dependency on, say, common, I would have a dependency on the org.openjdk.jmc.common bundle. When I have a Maven dependency on one of the Maven artifacts, I have a dependency on groupId=org.openjdk.jmc, artifactId=common. Kind regards, Marcus From: Guru Date: Tuesday, 10 July 2018 at 12:05 To: Marcus Hirt , Jayathirth D V , Sharath Ballal Cc: Subject: Review request: JMC-6072: Incorrect artifactId for snapshot build Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JMC-6072 webrev : http://cr.openjdk.java.net/~ghb/JMC-6072/webrev.0 Thanks, Guru From sharath.ballal at oracle.com Sat Jul 14 05:01:48 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 13 Jul 2018 22:01:48 -0700 (PDT) Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Message-ID: <19b30c54-28d8-449c-b45a-20c64f82fcf3@default> The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. 2. Changes to some of the tests and their baseline files. Testing done: mvn verify passes. JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. JDK 11 - Recording, loading and automated analysis works. Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ Kindly review the fix. Thanks, Sharath From: Sharath Ballal [mailto:sharath.ballal at oracle.com] Sent: Friday, June 08, 2018 3:03 PM To: 'jmc-dev at openjdk.java.net' Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Hello, Pls review fix for the following P1 issue: ID: https://bugs.openjdk.java.net/browse/JMC-5895 Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ Thanks, Sharath From marcus.hirt at oracle.com Sat Jul 14 18:58:43 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Sat, 14 Jul 2018 20:58:43 +0200 Subject: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' In-Reply-To: References: Message-ID: Hi Sharath, Some minor nits: In SyntheticAttributeExtension.java: + eventTypeId = JdkTypeIDsPreJdk11.translate(eventTypeId); if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) && JdkTypeIDs.RECORDING_SETTING.equals(eventTypeId)) { return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; } The translated eventTypeId is only used once, instead of redefining the parameter, please consider just translating the eventTypeId where it is used: if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) && JdkTypeIDs.RECORDING_SETTING.equals(JdkTypeIDsPreJdk11.translate(eventTypeId))) { return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; } Indentation problem in needTransform in JdkTypeIDsPreJdk11: 211 /** 212 * Determine if a typeId needs to be transformed into a JDK 11 type id. 213 * 214 * @param typeId 215 * type id 216 * @return true if transformation is needed, false otherwise. 217 */ 218 public static boolean needTransform(String typeId) { 219 if (typeId.startsWith(PREFIX)) { 220 return false; 221 } 222 return typeId.startsWith(EVENT_ID_ROOT) || typeId.startsWith(PREFIX_9_10) ; 223 } 224 Kind regards, Marcus ?On 2018-07-14, 07:02, "jmc-dev on behalf of Sharath Ballal" wrote: The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. 2. Changes to some of the tests and their baseline files. Testing done: mvn verify passes. JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. JDK 11 - Recording, loading and automated analysis works. Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ Kindly review the fix. Thanks, Sharath From: Sharath Ballal [mailto:sharath.ballal at oracle.com] Sent: Friday, June 08, 2018 3:03 PM To: 'jmc-dev at openjdk.java.net' Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Hello, Pls review fix for the following P1 issue: ID: https://bugs.openjdk.java.net/browse/JMC-5895 Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ Thanks, Sharath From jayathirth.d.v at oracle.com Sat Jul 14 19:44:06 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sat, 14 Jul 2018 12:44:06 -0700 (PDT) Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' In-Reply-To: <19b30c54-28d8-449c-b45a-20c64f82fcf3@default> References: <19b30c54-28d8-449c-b45a-20c64f82fcf3@default> Message-ID: Hi Sharath, Please find my observations: After webrev.02 , For each event in the code to check whether we have Event from JDK 9 or 10 we are using JdkTypeIDsPreJdk11.needtransform() function. This might make automated analysis take more time. We can completely remove the usage of this verification if we maintain JDK 9/10 Event types in a file like JdkTypeIDs.java. We can have new file like Jdk9TypeIDs.java with events starting from "com.oracle.jdk.". After doing above thing we can make following changes in other files: In SettingsTransformer.java: In wrapSinkFactory.create() we can use: if (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(identifier) || Jdk9TypeIDs.RECORDING_SETTING.equals(identifier)) { Both these conditions will take care of whether event is from JDK 7/8 & 9/10. We can remove needtransform() check while validating created SettingsTransformer object. In SettingsTransformer() constructor, for Jdk 9/10 events looks like we are not able to find any field which matches END_TIME. So we are creating EventSink with all the data structures. In SettingsTransformer.addEvent() we can remove the check for JdkTypeIDsPreJdk11.needTransform() because we are creating SettingsTransformer only when we know we have event types from JDK 7/8/9/10. In SyntheticAttributeExtension.java: If we have Jdk9TypeIDs.java there is no need to explicitly call JdkTypeIDsPreJdk11.translate(). Also here we can use single if block like: public String getValueInterpretation(String eventTypeId, String fieldId) { if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) && (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(eventTypeId) || Jdk9TypeIDs.RECORDING_SETTING.equals(eventTypeId) || JdkTypeIDs.RECORDING_SETTING.equals(eventTypeId) { return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; } return null; } In JdkTypeIDsPreJdk11.java: With above changes we can remove needtransform() function. Generic change in TypeManager.java: Looks like there is no need to create new function createStructReaderV2(). We can use createStructReaderV1() by adding new "switch identifiers" as most of them are same between createStructReaderV1() & createStructReaderV2 (). Since I am new to JMC project I wanted to verify things before mentioning my observations. So I made above changes locally and was able to build and run unit tests without failure:) Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Saturday, July 14, 2018 10:32 AM To: jmc-dev at openjdk.java.net Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. 2. Changes to some of the tests and their baseline files. Testing done: mvn verify passes. JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. JDK 11 - Recording, loading and automated analysis works. Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ Kindly review the fix. Thanks, Sharath From: Sharath Ballal [mailto:sharath.ballal at oracle.com] Sent: Friday, June 08, 2018 3:03 PM To: 'jmc-dev at openjdk.java.net' Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Hello, Pls review fix for the following P1 issue: ID: https://bugs.openjdk.java.net/browse/JMC-5895 Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ Thanks, Sharath From marcus.hirt at oracle.com Sat Jul 14 20:54:50 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Sat, 14 Jul 2018 22:54:50 +0200 Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' In-Reply-To: References: <19b30c54-28d8-449c-b45a-20c64f82fcf3@default> Message-ID: <403C2ED8-B17A-4A83-8657-6C1883EA0E3E@oracle.com> Good points Jay! To make the difference between v1 and v2 more maintainable and clear, we should probably have v1 and v2 being their own parsers with (plenty of) shared infrastructure. That said, since we need to get an EA out soon, I think that can wait. I think it may be a good idea to have a Jdk9TypeIDs.java, at least for a subset of the type IDs (like RECORDING_SETTING), but since no one should be using it, except our internal machinery, it should be package visible only. I think we can keep createStructReaderV2, as a first step in making a clean separation between v1 and v2, but I am not religious about it. Kind regards, Marcus (still on vacation, but back mid next week) > On 14 Jul 2018, at 21:44, Jayathirth D V wrote: > > Hi Sharath, > > Please find my observations: > > After webrev.02 , For each event in the code to check whether we have Event from JDK 9 or 10 we are using JdkTypeIDsPreJdk11.needtransform() function. This might make automated analysis take more time. We can completely remove the usage of this verification if we maintain JDK 9/10 Event types in a file like JdkTypeIDs.java. We can have new file like Jdk9TypeIDs.java with events starting from "com.oracle.jdk.". > > After doing above thing we can make following changes in other files: > > In SettingsTransformer.java: > In wrapSinkFactory.create() we can use: > if (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(identifier) || > Jdk9TypeIDs.RECORDING_SETTING.equals(identifier)) { > > Both these conditions will take care of whether event is from JDK 7/8 & 9/10. We can remove needtransform() check while validating created SettingsTransformer object. > > In SettingsTransformer() constructor, for Jdk 9/10 events looks like we are not able to find any field which matches END_TIME. So we are creating EventSink with all the data structures. > In SettingsTransformer.addEvent() we can remove the check for JdkTypeIDsPreJdk11.needTransform() because we are creating SettingsTransformer only when we know we have event types from JDK 7/8/9/10. > > In SyntheticAttributeExtension.java: > If we have Jdk9TypeIDs.java there is no need to explicitly call JdkTypeIDsPreJdk11.translate(). Also here we can use single if block like: > public String getValueInterpretation(String eventTypeId, String fieldId) { > if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) > && (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(eventTypeId) || > Jdk9TypeIDs.RECORDING_SETTING.equals(eventTypeId) || > JdkTypeIDs.RECORDING_SETTING.equals(eventTypeId) { > return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; > } > return null; > } > > In JdkTypeIDsPreJdk11.java: > With above changes we can remove needtransform() function. > > Generic change in TypeManager.java: > Looks like there is no need to create new function createStructReaderV2(). We can use createStructReaderV1() by adding new "switch identifiers" as most of them are same between createStructReaderV1() & createStructReaderV2 (). > > Since I am new to JMC project I wanted to verify things before mentioning my observations. So I made above changes locally and was able to build and run unit tests without failure:) > > Thanks, > Jay > > -----Original Message----- > From: Sharath Ballal > Sent: Saturday, July 14, 2018 10:32 AM > To: jmc-dev at openjdk.java.net > Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: > > 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. > > 2. Changes to some of the tests and their baseline files. > > > > Testing done: > > mvn verify passes. > > JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. > > JDK 11 - Recording, loading and automated analysis works. > > > > Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ > > Kindly review the fix. > > > > Thanks, > > Sharath > > > > > > From: Sharath Ballal [mailto:sharath.ballal at oracle.com] > Sent: Friday, June 08, 2018 3:03 PM > To: 'jmc-dev at openjdk.java.net' > Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > > > Hello, > > > > Pls review fix for the following P1 issue: > > > > ID: https://bugs.openjdk.java.net/browse/JMC-5895 > > Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ > > > > Thanks, > > Sharath > > > > From sharath.ballal at oracle.com Mon Jul 16 06:23:38 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 15 Jul 2018 23:23:38 -0700 (PDT) Subject: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' In-Reply-To: References: Message-ID: Thanks Marcus, I have done the changes. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Sunday, July 15, 2018 12:29 AM To: Sharath Ballal; jmc-dev at openjdk.java.net Subject: Re: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Hi Sharath, Some minor nits: In SyntheticAttributeExtension.java: + eventTypeId = JdkTypeIDsPreJdk11.translate(eventTypeId); if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) && JdkTypeIDs.RECORDING_SETTING.equals(eventTypeId)) { return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; } The translated eventTypeId is only used once, instead of redefining the parameter, please consider just translating the eventTypeId where it is used: if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) && JdkTypeIDs.RECORDING_SETTING.equals(JdkTypeIDsPreJdk11.translate(eventTypeId))) { return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; } [Sharath Ballal] Done. Indentation problem in needTransform in JdkTypeIDsPreJdk11: 211 /** 212 * Determine if a typeId needs to be transformed into a JDK 11 type id. 213 * 214 * @param typeId 215 * type id 216 * @return true if transformation is needed, false otherwise. 217 */ 218 public static boolean needTransform(String typeId) { 219 if (typeId.startsWith(PREFIX)) { 220 return false; 221 } 222 return typeId.startsWith(EVENT_ID_ROOT) || typeId.startsWith(PREFIX_9_10) ; 223 } 224 [Sharath Ballal] Done Kind regards, Marcus ?On 2018-07-14, 07:02, "jmc-dev on behalf of Sharath Ballal" wrote: The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. 2. Changes to some of the tests and their baseline files. Testing done: mvn verify passes. JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. JDK 11 - Recording, loading and automated analysis works. Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ Kindly review the fix. Thanks, Sharath From: Sharath Ballal [mailto:sharath.ballal at oracle.com] Sent: Friday, June 08, 2018 3:03 PM To: 'jmc-dev at openjdk.java.net' Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Hello, Pls review fix for the following P1 issue: ID: https://bugs.openjdk.java.net/browse/JMC-5895 Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ Thanks, Sharath From sharath.ballal at oracle.com Mon Jul 16 06:50:45 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 15 Jul 2018 23:50:45 -0700 (PDT) Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' In-Reply-To: <403C2ED8-B17A-4A83-8657-6C1883EA0E3E@oracle.com> References: <19b30c54-28d8-449c-b45a-20c64f82fcf3@default> <403C2ED8-B17A-4A83-8657-6C1883EA0E3E@oracle.com> Message-ID: <116ee01c-d4b1-49ca-a4b3-c667bf818e8d@default> Thanks Marcus and Jay for the comments. My reasoning for not having a Jdk9TypeIDs.java is to avoid one new file every time there is a change in the event ids. Since the consensus is to have a Jdk9TypeIDs.java, I will open another bug to address this and the related comments Jay mentioned. > I think we can keep createStructReaderV2, as a first step in making a clean separation between v1 and v2, but I am not religious about it. OK. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Sunday, July 15, 2018 2:25 AM To: Jayathirth D V Cc: Sharath Ballal; jmc-dev at openjdk.java.net Subject: Re: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Good points Jay! To make the difference between v1 and v2 more maintainable and clear, we should probably have v1 and v2 being their own parsers with (plenty of) shared infrastructure. That said, since we need to get an EA out soon, I think that can wait. I think it may be a good idea to have a Jdk9TypeIDs.java, at least for a subset of the type IDs (like RECORDING_SETTING), but since no one should be using it, except our internal machinery, it should be package visible only. I think we can keep createStructReaderV2, as a first step in making a clean separation between v1 and v2, but I am not religious about it. Kind regards, Marcus (still on vacation, but back mid next week) > On 14 Jul 2018, at 21:44, Jayathirth D V wrote: > > Hi Sharath, > > Please find my observations: > > After webrev.02 , For each event in the code to check whether we have Event from JDK 9 or 10 we are using JdkTypeIDsPreJdk11.needtransform() function. This might make automated analysis take more time. We can completely remove the usage of this verification if we maintain JDK 9/10 Event types in a file like JdkTypeIDs.java. We can have new file like Jdk9TypeIDs.java with events starting from "com.oracle.jdk.". > > After doing above thing we can make following changes in other files: > > In SettingsTransformer.java: > In wrapSinkFactory.create() we can use: > if (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(identifier) || > Jdk9TypeIDs.RECORDING_SETTING.equals(identifier)) { > > Both these conditions will take care of whether event is from JDK 7/8 & 9/10. We can remove needtransform() check while validating created SettingsTransformer object. > > In SettingsTransformer() constructor, for Jdk 9/10 events looks like we are not able to find any field which matches END_TIME. So we are creating EventSink with all the data structures. > In SettingsTransformer.addEvent() we can remove the check for JdkTypeIDsPreJdk11.needTransform() because we are creating SettingsTransformer only when we know we have event types from JDK 7/8/9/10. > > In SyntheticAttributeExtension.java: > If we have Jdk9TypeIDs.java there is no need to explicitly call JdkTypeIDsPreJdk11.translate(). Also here we can use single if block like: > public String getValueInterpretation(String eventTypeId, String fieldId) { > if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) > && (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(eventTypeId) || > Jdk9TypeIDs.RECORDING_SETTING.equals(eventTypeId) || > JdkTypeIDs.RECORDING_SETTING.equals(eventTypeId) { > return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; > } > return null; > } > > In JdkTypeIDsPreJdk11.java: > With above changes we can remove needtransform() function. > > Generic change in TypeManager.java: > Looks like there is no need to create new function createStructReaderV2(). We can use createStructReaderV1() by adding new "switch identifiers" as most of them are same between createStructReaderV1() & createStructReaderV2 (). > > Since I am new to JMC project I wanted to verify things before mentioning my observations. So I made above changes locally and was able to build and run unit tests without failure:) > > Thanks, > Jay > > -----Original Message----- > From: Sharath Ballal > Sent: Saturday, July 14, 2018 10:32 AM > To: jmc-dev at openjdk.java.net > Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: > > 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. > > 2. Changes to some of the tests and their baseline files. > > > > Testing done: > > mvn verify passes. > > JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. > > JDK 11 - Recording, loading and automated analysis works. > > > > Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ > > Kindly review the fix. > > > > Thanks, > > Sharath > > > > > > From: Sharath Ballal [mailto:sharath.ballal at oracle.com] > Sent: Friday, June 08, 2018 3:03 PM > To: 'jmc-dev at openjdk.java.net' > Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > > > Hello, > > > > Pls review fix for the following P1 issue: > > > > ID: https://bugs.openjdk.java.net/browse/JMC-5895 > > Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ > > > > Thanks, > > Sharath > > > > From jayathirth.d.v at oracle.com Mon Jul 16 07:09:31 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 16 Jul 2018 00:09:31 -0700 (PDT) Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' In-Reply-To: <116ee01c-d4b1-49ca-a4b3-c667bf818e8d@default> References: <19b30c54-28d8-449c-b45a-20c64f82fcf3@default> <403C2ED8-B17A-4A83-8657-6C1883EA0E3E@oracle.com> <116ee01c-d4b1-49ca-a4b3-c667bf818e8d@default> Message-ID: Hi Sharath, I thought we wanted to make changes related to Jdk9Types.java as part of this bug. But if we want to take it up later in separate bug that is also fine with me. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Monday, July 16, 2018 12:21 PM To: Marcus Hirt; Jayathirth D V Cc: jmc-dev at openjdk.java.net Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Thanks Marcus and Jay for the comments. My reasoning for not having a Jdk9TypeIDs.java is to avoid one new file every time there is a change in the event ids. Since the consensus is to have a Jdk9TypeIDs.java, I will open another bug to address this and the related comments Jay mentioned. > I think we can keep createStructReaderV2, as a first step in making a clean separation between v1 and v2, but I am not religious about it. OK. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Sunday, July 15, 2018 2:25 AM To: Jayathirth D V Cc: Sharath Ballal; jmc-dev at openjdk.java.net Subject: Re: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Good points Jay! To make the difference between v1 and v2 more maintainable and clear, we should probably have v1 and v2 being their own parsers with (plenty of) shared infrastructure. That said, since we need to get an EA out soon, I think that can wait. I think it may be a good idea to have a Jdk9TypeIDs.java, at least for a subset of the type IDs (like RECORDING_SETTING), but since no one should be using it, except our internal machinery, it should be package visible only. I think we can keep createStructReaderV2, as a first step in making a clean separation between v1 and v2, but I am not religious about it. Kind regards, Marcus (still on vacation, but back mid next week) > On 14 Jul 2018, at 21:44, Jayathirth D V wrote: > > Hi Sharath, > > Please find my observations: > > After webrev.02 , For each event in the code to check whether we have Event from JDK 9 or 10 we are using JdkTypeIDsPreJdk11.needtransform() function. This might make automated analysis take more time. We can completely remove the usage of this verification if we maintain JDK 9/10 Event types in a file like JdkTypeIDs.java. We can have new file like Jdk9TypeIDs.java with events starting from "com.oracle.jdk.". > > After doing above thing we can make following changes in other files: > > In SettingsTransformer.java: > In wrapSinkFactory.create() we can use: > if (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(identifier) || > Jdk9TypeIDs.RECORDING_SETTING.equals(identifier)) { > > Both these conditions will take care of whether event is from JDK 7/8 & 9/10. We can remove needtransform() check while validating created SettingsTransformer object. > > In SettingsTransformer() constructor, for Jdk 9/10 events looks like we are not able to find any field which matches END_TIME. So we are creating EventSink with all the data structures. > In SettingsTransformer.addEvent() we can remove the check for JdkTypeIDsPreJdk11.needTransform() because we are creating SettingsTransformer only when we know we have event types from JDK 7/8/9/10. > > In SyntheticAttributeExtension.java: > If we have Jdk9TypeIDs.java there is no need to explicitly call JdkTypeIDsPreJdk11.translate(). Also here we can use single if block like: > public String getValueInterpretation(String eventTypeId, String fieldId) { > if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) > && (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(eventTypeId) || > Jdk9TypeIDs.RECORDING_SETTING.equals(eventTypeId) || > JdkTypeIDs.RECORDING_SETTING.equals(eventTypeId) { > return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; > } > return null; > } > > In JdkTypeIDsPreJdk11.java: > With above changes we can remove needtransform() function. > > Generic change in TypeManager.java: > Looks like there is no need to create new function createStructReaderV2(). We can use createStructReaderV1() by adding new "switch identifiers" as most of them are same between createStructReaderV1() & createStructReaderV2 (). > > Since I am new to JMC project I wanted to verify things before mentioning my observations. So I made above changes locally and was able to build and run unit tests without failure:) > > Thanks, > Jay > > -----Original Message----- > From: Sharath Ballal > Sent: Saturday, July 14, 2018 10:32 AM > To: jmc-dev at openjdk.java.net > Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: > > 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. > > 2. Changes to some of the tests and their baseline files. > > > > Testing done: > > mvn verify passes. > > JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. > > JDK 11 - Recording, loading and automated analysis works. > > > > Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ > > Kindly review the fix. > > > > Thanks, > > Sharath > > > > > > From: Sharath Ballal [mailto:sharath.ballal at oracle.com] > Sent: Friday, June 08, 2018 3:03 PM > To: 'jmc-dev at openjdk.java.net' > Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > > > Hello, > > > > Pls review fix for the following P1 issue: > > > > ID: https://bugs.openjdk.java.net/browse/JMC-5895 > > Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ > > > > Thanks, > > Sharath > > > > From sharath.ballal at oracle.com Mon Jul 16 10:57:20 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 16 Jul 2018 03:57:20 -0700 (PDT) Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' In-Reply-To: References: <19b30c54-28d8-449c-b45a-20c64f82fcf3@default> <403C2ED8-B17A-4A83-8657-6C1883EA0E3E@oracle.com> <116ee01c-d4b1-49ca-a4b3-c667bf818e8d@default> Message-ID: <65a193b3-eba7-43d5-ba9d-ce754d8b959c@default> Thanks Jay. I have opened https://bugs.openjdk.java.net/browse/JMC-6075 to address the pending comments. Marcus, Jay, Latest webrev is (addressing the nits): http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.04/ I plan to checkin the code tomorrow if no other comments are there. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Monday, July 16, 2018 12:40 PM To: Sharath Ballal Cc: jmc-dev at openjdk.java.net Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Hi Sharath, I thought we wanted to make changes related to Jdk9Types.java as part of this bug. But if we want to take it up later in separate bug that is also fine with me. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Monday, July 16, 2018 12:21 PM To: Marcus Hirt; Jayathirth D V Cc: jmc-dev at openjdk.java.net Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Thanks Marcus and Jay for the comments. My reasoning for not having a Jdk9TypeIDs.java is to avoid one new file every time there is a change in the event ids. Since the consensus is to have a Jdk9TypeIDs.java, I will open another bug to address this and the related comments Jay mentioned. > I think we can keep createStructReaderV2, as a first step in making a clean separation between v1 and v2, but I am not religious about it. OK. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Sunday, July 15, 2018 2:25 AM To: Jayathirth D V Cc: Sharath Ballal; jmc-dev at openjdk.java.net Subject: Re: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Good points Jay! To make the difference between v1 and v2 more maintainable and clear, we should probably have v1 and v2 being their own parsers with (plenty of) shared infrastructure. That said, since we need to get an EA out soon, I think that can wait. I think it may be a good idea to have a Jdk9TypeIDs.java, at least for a subset of the type IDs (like RECORDING_SETTING), but since no one should be using it, except our internal machinery, it should be package visible only. I think we can keep createStructReaderV2, as a first step in making a clean separation between v1 and v2, but I am not religious about it. Kind regards, Marcus (still on vacation, but back mid next week) > On 14 Jul 2018, at 21:44, Jayathirth D V wrote: > > Hi Sharath, > > Please find my observations: > > After webrev.02 , For each event in the code to check whether we have Event from JDK 9 or 10 we are using JdkTypeIDsPreJdk11.needtransform() function. This might make automated analysis take more time. We can completely remove the usage of this verification if we maintain JDK 9/10 Event types in a file like JdkTypeIDs.java. We can have new file like Jdk9TypeIDs.java with events starting from "com.oracle.jdk.". > > After doing above thing we can make following changes in other files: > > In SettingsTransformer.java: > In wrapSinkFactory.create() we can use: > if (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(identifier) || > Jdk9TypeIDs.RECORDING_SETTING.equals(identifier)) { > > Both these conditions will take care of whether event is from JDK 7/8 & 9/10. We can remove needtransform() check while validating created SettingsTransformer object. > > In SettingsTransformer() constructor, for Jdk 9/10 events looks like we are not able to find any field which matches END_TIME. So we are creating EventSink with all the data structures. > In SettingsTransformer.addEvent() we can remove the check for JdkTypeIDsPreJdk11.needTransform() because we are creating SettingsTransformer only when we know we have event types from JDK 7/8/9/10. > > In SyntheticAttributeExtension.java: > If we have Jdk9TypeIDs.java there is no need to explicitly call JdkTypeIDsPreJdk11.translate(). Also here we can use single if block like: > public String getValueInterpretation(String eventTypeId, String fieldId) { > if (REC_SETTING_EVENT_ID_ATTRIBUTE.getIdentifier().equals(fieldId) > && (JdkTypeIDsPreJdk11.RECORDING_SETTING.equals(eventTypeId) || > Jdk9TypeIDs.RECORDING_SETTING.equals(eventTypeId) || > JdkTypeIDs.RECORDING_SETTING.equals(eventTypeId) { > return JfrInternalConstants.TYPE_IDENTIFIER_VALUE_INTERPRETATION; > } > return null; > } > > In JdkTypeIDsPreJdk11.java: > With above changes we can remove needtransform() function. > > Generic change in TypeManager.java: > Looks like there is no need to create new function createStructReaderV2(). We can use createStructReaderV1() by adding new "switch identifiers" as most of them are same between createStructReaderV1() & createStructReaderV2 (). > > Since I am new to JMC project I wanted to verify things before mentioning my observations. So I made above changes locally and was able to build and run unit tests without failure:) > > Thanks, > Jay > > -----Original Message----- > From: Sharath Ballal > Sent: Saturday, July 14, 2018 10:32 AM > To: jmc-dev at openjdk.java.net > Subject: RE: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > The fix has undergone changes from last time as 'mvn verify' was failing. The code changes now include: > > 1. Changes to the V1 parser to use the SettingsTransformer for JDK 9 & 10 events. > > 2. Changes to some of the tests and their baseline files. > > > > Testing done: > > mvn verify passes. > > JDK 7/8/9/10 - Recording, loading and automated analysis works. Verified that scores of the automated analysis doesn't change from earlier. > > JDK 11 - Recording, loading and automated analysis works. > > > > Latest webrev at : http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.03/ > > Kindly review the fix. > > > > Thanks, > > Sharath > > > > > > From: Sharath Ballal [mailto:sharath.ballal at oracle.com] > Sent: Friday, June 08, 2018 3:03 PM > To: 'jmc-dev at openjdk.java.net' > Subject: RFR: JMC-5895 - JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' > > > > Hello, > > > > Pls review fix for the following P1 issue: > > > > ID: https://bugs.openjdk.java.net/browse/JMC-5895 > > Webrev: http://cr.openjdk.java.net/~sballal/JMC-5895/webrev.00/ > > > > Thanks, > > Sharath > > > > From sharath.ballal at oracle.com Tue Jul 17 08:52:11 2018 From: sharath.ballal at oracle.com (sharath.ballal at oracle.com) Date: Tue, 17 Jul 2018 08:52:11 +0000 Subject: hg: jmc/jmc: JMC-5895: JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Message-ID: <201807170852.w6H8qBWh007437@aojmv0008.oracle.com> Changeset: 67890b8d02fe Author: sballal Date: 2018-07-17 14:21 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/67890b8d02fe JMC-5895: JFR in JDK 11 changed event paths from 'com.oracle.jdk' to 'jdk', and type paths from 'com.oracle.jfr.types' to 'jdk.types' Reviewed-by: hirt, jdv Contributed-by:sharath.ballal at oracle.com, marcus.hirt at oracle.com ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/FlightRecordingLoader.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkTypeIDs.java + core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/JdkTypeIDsPreJdk11.java - core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/JdkTypeIDsPreJdk9.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/SettingsTransformer.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/SyntheticAttributeExtension.java ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/java/org/openjdk/jmc/flightrecorder/test/FilteredRecordingTest.java ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/7u40.jfr.txt ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/7u60.jfr.txt ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/7u76.jfr.txt ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/8u0.jfr.txt ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/8u20.jfr.txt ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/8u40.jfr.txt ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/8u60.jfr.txt ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/printouts/9u0.jfr.txt From marcus.hirt at oracle.com Wed Jul 18 20:39:29 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Wed, 18 Jul 2018 20:39:29 +0000 Subject: hg: jmc/jmc: JMC-6079: Updating readme Message-ID: <201807182039.w6IKdTCB027196@aojmv0008.oracle.com> Changeset: f780f2d6012b Author: hirt Date: 2018-07-18 22:38 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/f780f2d6012b JMC-6079: Updating readme Reviewed-by: hirt Contributed-by: reinhapa ! README.md From jmatsuok at redhat.com Thu Jul 19 21:39:22 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Thu, 19 Jul 2018 17:39:22 -0400 Subject: [PATCH] Fix JMC-5398 Message-ID: Hi, The following patch fixes JMC-5398 [1]. The bug was twofold, first when attempting to attach to a JVM that was either busy or suspended JMC would hang, and second upon restarting the JVM browser would not list any JVMs. This patch adds a timeout to the problematic calls. This ensures that during JVM discovery problematic JVMs are skipped when attaching times out, keeping the JVM browser functioning properly, as well as ensuring that we don't hang when attempting to open the JMX console or start a flight recording for a problematic JVM. The timeout is currently 5 seconds but can easily be changed if this is too short/long. [1] https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5398?filter=allopenissues Thoughts? Cheers, - Josh -------------- next part -------------- A non-text attachment was scrubbed... Name: JMC-5398-Candidate-3.patch Type: text/x-patch Size: 20061 bytes Desc: not available URL: From jayathirth.d.v at oracle.com Fri Jul 20 08:04:55 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 20 Jul 2018 01:04:55 -0700 (PDT) Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Message-ID: <4cc51664-a173-42cf-ac53-23243f915958@default> Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6075 Webrev : http://cr.openjdk.java.net/~jdv/6075/webrev.00/ Issue: In SettingTransformer and SyntheticAttributeExtension, whenever we have RECORDING_SETTING from JDK9/10 we translate these events to JDK11 type. Solution: We have static variables which we use for Pre JDK9 events in JdkTypeIDsPreJdk11. For JDK9/10 RECORDING_SETTING event type also we can maintain a static variable in JdkTypeIDsPreJdk11 and use it wherever applicable. This will avoid conversion of JDK9/10 RECORDING_SETTING event to JDK11 type. I have removed usage of JdkTypeIDsPreJdk11.needTransform() because we will be creating SettingTransform object only when have Pre-JDK 11 RECORDING_SETTING event type. Also there is some cleanup done in SettingTransformer. I have ran unit tests and there are no failures. Also used JDK 7/8/9/10/11 recordings and I don't see any difference in Automated-analysis results before and after change. Thanks, Jay From marcus.hirt at oracle.com Fri Jul 20 08:14:44 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Fri, 20 Jul 2018 10:14:44 +0200 Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer In-Reply-To: References: Message-ID: Hi Jay, Looks fine. Go ahead! /M ?On 2018-07-20, 10:05, "jmc-dev on behalf of Jayathirth D V" wrote: Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6075 Webrev : http://cr.openjdk.java.net/~jdv/6075/webrev.00/ Issue: In SettingTransformer and SyntheticAttributeExtension, whenever we have RECORDING_SETTING from JDK9/10 we translate these events to JDK11 type. Solution: We have static variables which we use for Pre JDK9 events in JdkTypeIDsPreJdk11. For JDK9/10 RECORDING_SETTING event type also we can maintain a static variable in JdkTypeIDsPreJdk11 and use it wherever applicable. This will avoid conversion of JDK9/10 RECORDING_SETTING event to JDK11 type. I have removed usage of JdkTypeIDsPreJdk11.needTransform() because we will be creating SettingTransform object only when have Pre-JDK 11 RECORDING_SETTING event type. Also there is some cleanup done in SettingTransformer. I have ran unit tests and there are no failures. Also used JDK 7/8/9/10/11 recordings and I don't see any difference in Automated-analysis results before and after change. Thanks, Jay From jayathirth.d.v at oracle.com Fri Jul 20 08:55:24 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 20 Jul 2018 01:55:24 -0700 (PDT) Subject: RFR JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator Message-ID: <6c003314-1a0f-4a21-b380-8b8c77d8c3a8@default> Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6086 Webrev : http://cr.openjdk.java.net/~jdv/6086/webrev.00/ Issue: When we try to read compressed JFR file in ChunkReader, we use StreamChunkIterator and store the decoded stream. But when we reach end of stream we are not releasing the open stream. Solution: Close the open stream when we reach end of file. Ran unit tests and there are no failures. Also there are no problems with JDK 7/8/9/10/11 automated analysis results. Thanks, Jay From marcus.hirt at oracle.com Fri Jul 20 11:28:06 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Fri, 20 Jul 2018 13:28:06 +0200 Subject: RFR JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator In-Reply-To: References: Message-ID: Hi Jay, May I suggest instead doing: if (!hasNext) { IOToolkit.closeSilently(inputStream); } /M ?On 2018-07-20, 10:55, "jmc-dev on behalf of Jayathirth D V" wrote: Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6086 Webrev : http://cr.openjdk.java.net/~jdv/6086/webrev.00/ Issue: When we try to read compressed JFR file in ChunkReader, we use StreamChunkIterator and store the decoded stream. But when we reach end of stream we are not releasing the open stream. Solution: Close the open stream when we reach end of file. Ran unit tests and there are no failures. Also there are no problems with JDK 7/8/9/10/11 automated analysis results. Thanks, Jay From neugens at redhat.com Fri Jul 20 15:07:00 2018 From: neugens at redhat.com (Mario Torre) Date: Fri, 20 Jul 2018 17:07:00 +0200 Subject: [PATCH] Fix JMC-5398 In-Reply-To: References: Message-ID: Hi Joshua, The patch looks good, however I would like a second reviewer, especially considering that someone should push your patch if accepted (which I can do of course but at this stage I still prefer if someone from Oracle does it/or gives the OK). I have only one nitpick: + private static final String ATTACH_TIMED_OUT_ERROR_MESSAGE = "Timed out attempting to attach to target JVM!"; I believe that if this is not marked for translation it should be followed by //$NON-NLS-1$ or eclipse will mark a warning about this line. I'm not sure if this code will work on Java 9+, of course that's a concern valid for the existing code too, I'm not sure if Marcus prefer to address that in one go or with a separate patch (assuming there may be other areas of interest, perhaps a separate patch is better, I didn't see a bug regarding this, perhaps we should file one?). Cheers, Mario On Thu, Jul 19, 2018 at 11:39 PM, Joshua Matsuoka wrote: > Hi, > > The following patch fixes JMC-5398 [1]. The bug was twofold, first when > attempting to attach to a JVM that was either busy or suspended JMC would > hang, and second upon restarting the JVM browser would not list any JVMs. > > This patch adds a timeout to the problematic calls. This ensures that > during JVM discovery problematic JVMs are skipped when attaching times out, > keeping the JVM browser functioning properly, as well as ensuring that we > don't hang when attempting to open the JMX console or start a flight > recording for a problematic JVM. > > The timeout is currently 5 seconds but can easily be changed if this is too > short/long. > > [1] > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5398?filter=allopenissues > > Thoughts? > > Cheers, > > - Josh -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sharath.ballal at oracle.com Fri Jul 20 16:39:07 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 20 Jul 2018 09:39:07 -0700 (PDT) Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer In-Reply-To: <4cc51664-a173-42cf-ac53-23243f915958@default> References: <4cc51664-a173-42cf-ac53-23243f915958@default> Message-ID: Hi Jay, SettingsTransformer.java - if (st.isValid() || (needsTransform && st.isValidV1())) { + if (st.isValid() || st.isValidV1()) { You should not remove the ' needsTransform' here. We are using it to distinguish between JDK 7/8 and JDK 9/10. Else for 7/8 if st.isValidV1() returns true the condition will go through even though it should not. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Friday, July 20, 2018 1:35 PM To: jmc-dev at openjdk.java.net Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6075 Webrev : http://cr.openjdk.java.net/~jdv/6075/webrev.00/ Issue: In SettingTransformer and SyntheticAttributeExtension, whenever we have RECORDING_SETTING from JDK9/10 we translate these events to JDK11 type. Solution: We have static variables which we use for Pre JDK9 events in JdkTypeIDsPreJdk11. For JDK9/10 RECORDING_SETTING event type also we can maintain a static variable in JdkTypeIDsPreJdk11 and use it wherever applicable. This will avoid conversion of JDK9/10 RECORDING_SETTING event to JDK11 type. I have removed usage of JdkTypeIDsPreJdk11.needTransform() because we will be creating SettingTransform object only when have Pre-JDK 11 RECORDING_SETTING event type. Also there is some cleanup done in SettingTransformer. I have ran unit tests and there are no failures. Also used JDK 7/8/9/10/11 recordings and I don't see any difference in Automated-analysis results before and after change. Thanks, Jay From jayathirth.d.v at oracle.com Sat Jul 21 08:50:24 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sat, 21 Jul 2018 01:50:24 -0700 (PDT) Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer In-Reply-To: References: <4cc51664-a173-42cf-ac53-23243f915958@default> Message-ID: <4712cf5f-6516-43ad-91d1-af57e2750794@default> Hi Sharath, Thanks for your inputs. The needTransform() logic that was present was not differentiating between JDK7/8 & JDK 9/10 events. It has the logic to differentiate between JDK7/8/9/10 & JDK 11 events. public static boolean needTransform(String typeId) { if (typeId.startsWith(PREFIX)) { return false; } return typeId.startsWith(EVENT_ID_ROOT) || typeId.startsWith(PREFIX_9_10); } So needTransform variable previously present for validating SettingTransformer object was not differentiating SettingsTransformer created between JDK7/8 & JDK9/10. Even when we use needTransform variable, If we get JDK 7/8 events and st.isValidV1() returns true we will still use the invalid SettingsTransformer object. That said, we should have tighter checks for validating SettingsTransformer object differently between JDK 7/8 & JDK 9/10. So I have added new checks before we return SettingsTransformer object. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6075/webrev.01/ No unit test failures with latest code. There are no differences in Automated analysis results too. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Friday, July 20, 2018 10:09 PM To: Jayathirth D V; jmc-dev at openjdk.java.net Subject: RE: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hi Jay, SettingsTransformer.java - if (st.isValid() || (needsTransform && st.isValidV1())) { + if (st.isValid() || st.isValidV1()) { You should not remove the ' needsTransform' here. We are using it to distinguish between JDK 7/8 and JDK 9/10. Else for 7/8 if st.isValidV1() returns true the condition will go through even though it should not. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Friday, July 20, 2018 1:35 PM To: jmc-dev at openjdk.java.net Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6075 Webrev : http://cr.openjdk.java.net/~jdv/6075/webrev.00/ Issue: In SettingTransformer and SyntheticAttributeExtension, whenever we have RECORDING_SETTING from JDK9/10 we translate these events to JDK11 type. Solution: We have static variables which we use for Pre JDK9 events in JdkTypeIDsPreJdk11. For JDK9/10 RECORDING_SETTING event type also we can maintain a static variable in JdkTypeIDsPreJdk11 and use it wherever applicable. This will avoid conversion of JDK9/10 RECORDING_SETTING event to JDK11 type. I have removed usage of JdkTypeIDsPreJdk11.needTransform() because we will be creating SettingTransform object only when have Pre-JDK 11 RECORDING_SETTING event type. Also there is some cleanup done in SettingTransformer. I have ran unit tests and there are no failures. Also used JDK 7/8/9/10/11 recordings and I don't see any difference in Automated-analysis results before and after change. Thanks, Jay From jayathirth.d.v at oracle.com Sat Jul 21 09:34:52 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sat, 21 Jul 2018 02:34:52 -0700 (PDT) Subject: RFR JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator In-Reply-To: References: Message-ID: Hi Marcus, Thanks for your inputs. It's good to know that we have IO utility. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6086/webrev.01/ Thanks, Jay -----Original Message----- From: Marcus Hirt Sent: Friday, July 20, 2018 4:58 PM To: Jayathirth D V; jmc-dev at openjdk.java.net Subject: Re: RFR JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator Hi Jay, May I suggest instead doing: if (!hasNext) { IOToolkit.closeSilently(inputStream); } /M ?On 2018-07-20, 10:55, "jmc-dev on behalf of Jayathirth D V" wrote: Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6086 Webrev : http://cr.openjdk.java.net/~jdv/6086/webrev.00/ Issue: When we try to read compressed JFR file in ChunkReader, we use StreamChunkIterator and store the decoded stream. But when we reach end of stream we are not releasing the open stream. Solution: Close the open stream when we reach end of file. Ran unit tests and there are no failures. Also there are no problems with JDK 7/8/9/10/11 automated analysis results. Thanks, Jay From marcus.hirt at oracle.com Sat Jul 21 11:54:24 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Sat, 21 Jul 2018 13:54:24 +0200 Subject: RFR JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator In-Reply-To: References: Message-ID: Looks good! /M - Excuse me if terse; sent from my phone. > On 21 Jul 2018, at 11:34, Jayathirth D V wrote: > > Hi Marcus, > > Thanks for your inputs. > It's good to know that we have IO utility. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6086/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Marcus Hirt > Sent: Friday, July 20, 2018 4:58 PM > To: Jayathirth D V; jmc-dev at openjdk.java.net > Subject: Re: RFR JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator > > Hi Jay, > > May I suggest instead doing: > > if (!hasNext) { > IOToolkit.closeSilently(inputStream); > } > > /M > > ?On 2018-07-20, 10:55, "jmc-dev on behalf of Jayathirth D V" wrote: > > Hello All, > > > > Please review the following fix in JMC 7 : > > > > Bug : https://bugs.openjdk.java.net/browse/JMC-6086 > > Webrev : http://cr.openjdk.java.net/~jdv/6086/webrev.00/ > > > > Issue: When we try to read compressed JFR file in ChunkReader, we use StreamChunkIterator and store the decoded stream. But when we reach end of stream we are not releasing the open stream. > > > > Solution: Close the open stream when we reach end of file. > > > > Ran unit tests and there are no failures. Also there are no problems with JDK 7/8/9/10/11 automated analysis results. > > > > Thanks, > > Jay > > > > > > From sharath.ballal at oracle.com Sat Jul 21 15:37:55 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sat, 21 Jul 2018 08:37:55 -0700 (PDT) Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer In-Reply-To: <4712cf5f-6516-43ad-91d1-af57e2750794@default> References: <4cc51664-a173-42cf-ac53-23243f915958@default> <4712cf5f-6516-43ad-91d1-af57e2750794@default> Message-ID: <0378634e-615a-4bd7-8345-b92f52f7e2e0@default> Looks Good Jay. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Saturday, July 21, 2018 2:20 PM To: Sharath Ballal; jmc-dev at openjdk.java.net Subject: RE: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hi Sharath, Thanks for your inputs. The needTransform() logic that was present was not differentiating between JDK7/8 & JDK 9/10 events. It has the logic to differentiate between JDK7/8/9/10 & JDK 11 events. public static boolean needTransform(String typeId) { if (typeId.startsWith(PREFIX)) { return false; } return typeId.startsWith(EVENT_ID_ROOT) || typeId.startsWith(PREFIX_9_10); } So needTransform variable previously present for validating SettingTransformer object was not differentiating SettingsTransformer created between JDK7/8 & JDK9/10. Even when we use needTransform variable, If we get JDK 7/8 events and st.isValidV1() returns true we will still use the invalid SettingsTransformer object. That said, we should have tighter checks for validating SettingsTransformer object differently between JDK 7/8 & JDK 9/10. So I have added new checks before we return SettingsTransformer object. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6075/webrev.01/ No unit test failures with latest code. There are no differences in Automated analysis results too. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Friday, July 20, 2018 10:09 PM To: Jayathirth D V; jmc-dev at openjdk.java.net Subject: RE: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hi Jay, SettingsTransformer.java - if (st.isValid() || (needsTransform && st.isValidV1())) { + if (st.isValid() || st.isValidV1()) { You should not remove the ' needsTransform' here. We are using it to distinguish between JDK 7/8 and JDK 9/10. Else for 7/8 if st.isValidV1() returns true the condition will go through even though it should not. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Friday, July 20, 2018 1:35 PM To: jmc-dev at openjdk.java.net Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6075 Webrev : http://cr.openjdk.java.net/~jdv/6075/webrev.00/ Issue: In SettingTransformer and SyntheticAttributeExtension, whenever we have RECORDING_SETTING from JDK9/10 we translate these events to JDK11 type. Solution: We have static variables which we use for Pre JDK9 events in JdkTypeIDsPreJdk11. For JDK9/10 RECORDING_SETTING event type also we can maintain a static variable in JdkTypeIDsPreJdk11 and use it wherever applicable. This will avoid conversion of JDK9/10 RECORDING_SETTING event to JDK11 type. I have removed usage of JdkTypeIDsPreJdk11.needTransform() because we will be creating SettingTransform object only when have Pre-JDK 11 RECORDING_SETTING event type. Also there is some cleanup done in SettingTransformer. I have ran unit tests and there are no failures. Also used JDK 7/8/9/10/11 recordings and I don't see any difference in Automated-analysis results before and after change. Thanks, Jay From jayathirth.d.v at oracle.com Sun Jul 22 04:26:24 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sat, 21 Jul 2018 21:26:24 -0700 (PDT) Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer In-Reply-To: <0378634e-615a-4bd7-8345-b92f52f7e2e0@default> References: <4cc51664-a173-42cf-ac53-23243f915958@default> <4712cf5f-6516-43ad-91d1-af57e2750794@default> <0378634e-615a-4bd7-8345-b92f52f7e2e0@default> Message-ID: Hi Marcus, Sharath has approved latest webrev : http://cr.openjdk.java.net/~jdv/6075/webrev.01/ Please review the latest change. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Saturday, July 21, 2018 9:08 PM To: Jayathirth D V; jmc-dev at openjdk.java.net Subject: RE: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Looks Good Jay. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Saturday, July 21, 2018 2:20 PM To: Sharath Ballal; jmc-dev at openjdk.java.net Subject: RE: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hi Sharath, Thanks for your inputs. The needTransform() logic that was present was not differentiating between JDK7/8 & JDK 9/10 events. It has the logic to differentiate between JDK7/8/9/10 & JDK 11 events. public static boolean needTransform(String typeId) { if (typeId.startsWith(PREFIX)) { return false; } return typeId.startsWith(EVENT_ID_ROOT) || typeId.startsWith(PREFIX_9_10); } So needTransform variable previously present for validating SettingTransformer object was not differentiating SettingsTransformer created between JDK7/8 & JDK9/10. Even when we use needTransform variable, If we get JDK 7/8 events and st.isValidV1() returns true we will still use the invalid SettingsTransformer object. That said, we should have tighter checks for validating SettingsTransformer object differently between JDK 7/8 & JDK 9/10. So I have added new checks before we return SettingsTransformer object. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6075/webrev.01/ No unit test failures with latest code. There are no differences in Automated analysis results too. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Friday, July 20, 2018 10:09 PM To: Jayathirth D V; jmc-dev at openjdk.java.net Subject: RE: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hi Jay, SettingsTransformer.java - if (st.isValid() || (needsTransform && st.isValidV1())) { + if (st.isValid() || st.isValidV1()) { You should not remove the ' needsTransform' here. We are using it to distinguish between JDK 7/8 and JDK 9/10. Else for 7/8 if st.isValidV1() returns true the condition will go through even though it should not. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Friday, July 20, 2018 1:35 PM To: jmc-dev at openjdk.java.net Subject: RFR JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Hello All, Please review the following fix in JMC 7 : Bug : https://bugs.openjdk.java.net/browse/JMC-6075 Webrev : http://cr.openjdk.java.net/~jdv/6075/webrev.00/ Issue: In SettingTransformer and SyntheticAttributeExtension, whenever we have RECORDING_SETTING from JDK9/10 we translate these events to JDK11 type. Solution: We have static variables which we use for Pre JDK9 events in JdkTypeIDsPreJdk11. For JDK9/10 RECORDING_SETTING event type also we can maintain a static variable in JdkTypeIDsPreJdk11 and use it wherever applicable. This will avoid conversion of JDK9/10 RECORDING_SETTING event to JDK11 type. I have removed usage of JdkTypeIDsPreJdk11.needTransform() because we will be creating SettingTransform object only when have Pre-JDK 11 RECORDING_SETTING event type. Also there is some cleanup done in SettingTransformer. I have ran unit tests and there are no failures. Also used JDK 7/8/9/10/11 recordings and I don't see any difference in Automated-analysis results before and after change. Thanks, Jay From guru.hb at oracle.com Mon Jul 23 08:29:36 2018 From: guru.hb at oracle.com (guru.hb at oracle.com) Date: Mon, 23 Jul 2018 08:29:36 +0000 Subject: hg: jmc/jmc: JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator Message-ID: <201807230829.w6N8Ta7l013780@aojmv0008.oracle.com> Changeset: 1407a87a6750 Author: jdv Date: 2018-07-23 13:59 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/1407a87a6750 JMC-6086: Unreleased stream when we reach end of decoding in StreamChunkIterator Reviewed-by: hirt ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/util/ChunkReader.java From marcus.hirt at oracle.com Tue Jul 24 14:58:05 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 24 Jul 2018 17:58:05 +0300 Subject: [PATCH] Fix JMC-5398 In-Reply-To: <366AB89C-94DC-4B69-AE40-0112646C4AD4@redhat.com> References: <366AB89C-94DC-4B69-AE40-0112646C4AD4@redhat.com> Message-ID: <195E25BF-054B-43E3-807C-890637510CBB@oracle.com> Hi Joshua, Greetings from JCrete! Looks good! I realized that there are a few NON-NLS tags missing in core elsewhere. Will open a new bug and simply just push the changes (trivial), unless someone disagrees. Kind regards, Marcus ?On 2018-07-20, 18:07, "jmc-dev on behalf of Mario Torre" wrote: Hi Joshua, The patch looks good, however I would like a second reviewer, especially considering that someone should push your patch if accepted (which I can do of course but at this stage I still prefer if someone from Oracle does it/or gives the OK). I have only one nitpick: + private static final String ATTACH_TIMED_OUT_ERROR_MESSAGE = "Timed out attempting to attach to target JVM!"; I believe that if this is not marked for translation it should be followed by //$NON-NLS-1$ or eclipse will mark a warning about this line. I'm not sure if this code will work on Java 9+, of course that's a concern valid for the existing code too, I'm not sure if Marcus prefer to address that in one go or with a separate patch (assuming there may be other areas of interest, perhaps a separate patch is better, I didn't see a bug regarding this, perhaps we should file one?). Cheers, Mario On Thu, Jul 19, 2018 at 11:39 PM, Joshua Matsuoka wrote: > Hi, > > The following patch fixes JMC-5398 [1]. The bug was twofold, first when > attempting to attach to a JVM that was either busy or suspended JMC would > hang, and second upon restarting the JVM browser would not list any JVMs. > > This patch adds a timeout to the problematic calls. This ensures that > during JVM discovery problematic JVMs are skipped when attaching times out, > keeping the JVM browser functioning properly, as well as ensuring that we > don't hang when attempting to open the JMX console or start a flight > recording for a problematic JVM. > > The timeout is currently 5 seconds but can easily be changed if this is too > short/long. > > [1] > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5398?filter=allopenissues > > Thoughts? > > Cheers, > > - Josh -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Tue Jul 24 15:05:17 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 24 Jul 2018 15:05:17 +0000 Subject: hg: jmc/jmc: JMC-6098: Adding missing NON-NLS tags Message-ID: <201807241505.w6OF5H1N018168@aojmv0008.oracle.com> Changeset: dbee4a46b0fe Author: hirt Date: 2018-07-24 18:05 +0300 URL: http://hg.openjdk.java.net/jmc/jmc/rev/dbee4a46b0fe JMC-6098: Adding missing NON-NLS tags ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AllocationByClassRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AllocationByThreadRule.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/util/ChunkReader.java From jmatsuok at redhat.com Tue Jul 24 15:20:36 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Tue, 24 Jul 2018 11:20:36 -0400 Subject: [PATCH] Fix JMC-5398 In-Reply-To: <195E25BF-054B-43E3-807C-890637510CBB@oracle.com> References: <366AB89C-94DC-4B69-AE40-0112646C4AD4@redhat.com> <195E25BF-054B-43E3-807C-890637510CBB@oracle.com> Message-ID: Hi Marcus, Mario, Here's the updated patch with the missing NON-NLS-1 tag added. Cheers, - Josh On Tue, Jul 24, 2018 at 10:58 AM, Marcus Hirt wrote: > Hi Joshua, > > Greetings from JCrete! Looks good! I realized that there are a few NON-NLS > tags missing in core elsewhere. Will open a new bug and simply just push > the changes (trivial), unless someone disagrees. > > Kind regards, > Marcus > > ?On 2018-07-20, 18:07, "jmc-dev on behalf of Mario Torre" < > jmc-dev-bounces at openjdk.java.net on behalf of neugens at redhat.com> wrote: > > Hi Joshua, > > The patch looks good, however I would like a second reviewer, > especially considering that someone should push your patch if accepted > (which I can do of course but at this stage I still prefer if someone > from Oracle does it/or gives the OK). > > I have only one nitpick: > > + private static final String ATTACH_TIMED_OUT_ERROR_MESSAGE = > "Timed out attempting to attach to target JVM!"; > > I believe that if this is not marked for translation it should be > followed by //$NON-NLS-1$ or eclipse will mark a warning about this > line. > > I'm not sure if this code will work on Java 9+, of course that's a > concern valid for the existing code too, I'm not sure if Marcus prefer > to address that in one go or with a separate patch (assuming there may > be other areas of interest, perhaps a separate patch is better, I > didn't see a bug regarding this, perhaps we should file one?). > > Cheers, > Mario > > > On Thu, Jul 19, 2018 at 11:39 PM, Joshua Matsuoka > wrote: > > Hi, > > > > The following patch fixes JMC-5398 [1]. The bug was twofold, first > when > > attempting to attach to a JVM that was either busy or suspended JMC > would > > hang, and second upon restarting the JVM browser would not list any > JVMs. > > > > This patch adds a timeout to the problematic calls. This ensures that > > during JVM discovery problematic JVMs are skipped when attaching > times out, > > keeping the JVM browser functioning properly, as well as ensuring > that we > > don't hang when attempting to open the JMX console or start a flight > > recording for a problematic JVM. > > > > The timeout is currently 5 seconds but can easily be changed if this > is too > > short/long. > > > > [1] > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5398? > filter=allopenissues > > > > Thoughts? > > > > Cheers, > > > > - Josh > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: JMC-5398-1.patch Type: text/x-patch Size: 20451 bytes Desc: not available URL: From guru.hb at oracle.com Wed Jul 25 06:51:15 2018 From: guru.hb at oracle.com (guru.hb at oracle.com) Date: Wed, 25 Jul 2018 06:51:15 +0000 Subject: hg: jmc/jmc: JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Message-ID: <201807250651.w6P6pFVg018446@aojmv0008.oracle.com> Changeset: 9a579a7aeec4 Author: jdv Date: 2018-07-25 12:20 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/9a579a7aeec4 JMC-6075: Avoid conversion for RECORDING_SETTING event from JDK9/10 in SettingsTransformer Reviewed-by: hirt, sballal ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/JdkTypeIDsPreJdk11.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/SettingsTransformer.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/parser/synthetic/SyntheticAttributeExtension.java From sharath.ballal at oracle.com Mon Jul 30 04:40:56 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 29 Jul 2018 21:40:56 -0700 (PDT) Subject: RFR JMC-6104: Java Application/Thread Activity does not show the graph Message-ID: Hello, Pls review this fix. The issue was that in the "Java Application" page if "Thread Activity" checkbox was selected in the legend no bars in the graph was getting generated. (More details in the bug.) Reason is that the event id path "com.oracle.jdk" was hard coded in some places. Fix is to use the global constants. JBS: https://bugs.openjdk.java.net/browse/JMC-6104 Webrev: http://cr.openjdk.java.net/~sballal/JMC-6104/webrev.00/ Testing: Mvn verify passes. I loaded JDK 7/8/9/10/11 recordings and verified under "Java Application", "Thread Activity" shows the bars in the graph. "Threads" page under "Java Application" also shows the bars in the graph. Thanks, Sharath From jayathirth.d.v at oracle.com Mon Jul 30 09:20:39 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 30 Jul 2018 02:20:39 -0700 (PDT) Subject: RFR JMC-6104: Java Application/Thread Activity does not show the graph In-Reply-To: References: Message-ID: <01e858bf-092f-4df4-928d-53bc6bb24bc3@default> Hi Sharath, After your change I was able to see graph for thread activity. And there are no unit tests failures in my Win 7 machine. Changes are fine. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Monday, July 30, 2018 10:11 AM To: jmc-dev at openjdk.java.net Subject: RFR JMC-6104: Java Application/Thread Activity does not show the graph Hello, Pls review this fix. The issue was that in the "Java Application" page if "Thread Activity" checkbox was selected in the legend no bars in the graph was getting generated. (More details in the bug.) Reason is that the event id path "com.oracle.jdk" was hard coded in some places. Fix is to use the global constants. JBS: https://bugs.openjdk.java.net/browse/JMC-6104 Webrev: http://cr.openjdk.java.net/~sballal/JMC-6104/webrev.00/ Testing: Mvn verify passes. I loaded JDK 7/8/9/10/11 recordings and verified under "Java Application", "Thread Activity" shows the bars in the graph. "Threads" page under "Java Application" also shows the bars in the graph. Thanks, Sharath From sharath.ballal at oracle.com Mon Jul 30 09:24:43 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 30 Jul 2018 02:24:43 -0700 (PDT) Subject: RFR JMC-6104: Java Application/Thread Activity does not show the graph In-Reply-To: <01e858bf-092f-4df4-928d-53bc6bb24bc3@default> References: <01e858bf-092f-4df4-928d-53bc6bb24bc3@default> Message-ID: <383b9d9a-326e-4755-b875-1194f6587964@default> Thanks for the review Jay. Thanks, Sharath -----Original Message----- From: Jayathirth D V Sent: Monday, July 30, 2018 2:51 PM To: Sharath Ballal; jmc-dev at openjdk.java.net Subject: RE: RFR JMC-6104: Java Application/Thread Activity does not show the graph Hi Sharath, After your change I was able to see graph for thread activity. And there are no unit tests failures in my Win 7 machine. Changes are fine. Thanks, Jay -----Original Message----- From: Sharath Ballal Sent: Monday, July 30, 2018 10:11 AM To: jmc-dev at openjdk.java.net Subject: RFR JMC-6104: Java Application/Thread Activity does not show the graph Hello, Pls review this fix. The issue was that in the "Java Application" page if "Thread Activity" checkbox was selected in the legend no bars in the graph was getting generated. (More details in the bug.) Reason is that the event id path "com.oracle.jdk" was hard coded in some places. Fix is to use the global constants. JBS: https://bugs.openjdk.java.net/browse/JMC-6104 Webrev: http://cr.openjdk.java.net/~sballal/JMC-6104/webrev.00/ Testing: Mvn verify passes. I loaded JDK 7/8/9/10/11 recordings and verified under "Java Application", "Thread Activity" shows the bars in the graph. "Threads" page under "Java Application" also shows the bars in the graph. Thanks, Sharath From marcus.hirt at oracle.com Mon Jul 30 09:58:26 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Mon, 30 Jul 2018 11:58:26 +0200 Subject: RFR JMC-6104: Java Application/Thread Activity does not show the graph In-Reply-To: <8DC32511-16D6-4C75-833F-F6E1672CE385@oracle.com> References: <8DC32511-16D6-4C75-833F-F6E1672CE385@oracle.com> Message-ID: <041CE2DD-8D73-4EBE-AF1A-5AA6BD41CF16@oracle.com> Looks fine! Go ahead! /M ?On 2018-07-30, 06:41, "jmc-dev on behalf of Sharath Ballal" wrote: Hello, Pls review this fix. The issue was that in the "Java Application" page if "Thread Activity" checkbox was selected in the legend no bars in the graph was getting generated. (More details in the bug.) Reason is that the event id path "com.oracle.jdk" was hard coded in some places. Fix is to use the global constants. JBS: https://bugs.openjdk.java.net/browse/JMC-6104 Webrev: http://cr.openjdk.java.net/~sballal/JMC-6104/webrev.00/ Testing: Mvn verify passes. I loaded JDK 7/8/9/10/11 recordings and verified under "Java Application", "Thread Activity" shows the bars in the graph. "Threads" page under "Java Application" also shows the bars in the graph. Thanks, Sharath From sharath.ballal at oracle.com Mon Jul 30 10:19:40 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 30 Jul 2018 03:19:40 -0700 (PDT) Subject: RFR JMC-6104: Java Application/Thread Activity does not show the graph In-Reply-To: <041CE2DD-8D73-4EBE-AF1A-5AA6BD41CF16@oracle.com> References: <8DC32511-16D6-4C75-833F-F6E1672CE385@oracle.com> <041CE2DD-8D73-4EBE-AF1A-5AA6BD41CF16@oracle.com> Message-ID: Thanks for the review Marcus. Thanks, Sharath -----Original Message----- From: Marcus Hirt Sent: Monday, July 30, 2018 3:28 PM To: Sharath Ballal; jmc-dev at openjdk.java.net Subject: Re: RFR JMC-6104: Java Application/Thread Activity does not show the graph Looks fine! Go ahead! /M ?On 2018-07-30, 06:41, "jmc-dev on behalf of Sharath Ballal" wrote: Hello, Pls review this fix. The issue was that in the "Java Application" page if "Thread Activity" checkbox was selected in the legend no bars in the graph was getting generated. (More details in the bug.) Reason is that the event id path "com.oracle.jdk" was hard coded in some places. Fix is to use the global constants. JBS: https://bugs.openjdk.java.net/browse/JMC-6104 Webrev: http://cr.openjdk.java.net/~sballal/JMC-6104/webrev.00/ Testing: Mvn verify passes. I loaded JDK 7/8/9/10/11 recordings and verified under "Java Application", "Thread Activity" shows the bars in the graph. "Threads" page under "Java Application" also shows the bars in the graph. Thanks, Sharath From sharath.ballal at oracle.com Tue Jul 31 04:41:39 2018 From: sharath.ballal at oracle.com (sharath.ballal at oracle.com) Date: Tue, 31 Jul 2018 04:41:39 +0000 Subject: hg: jmc/jmc: JMC-6104: Java Application/Thread Activity does not show the graph Message-ID: <201807310441.w6V4fd8v015473@aojmv0008.oracle.com> Changeset: aa5c84fe6da1 Author: sballal Date: 2018-07-31 10:10 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/aa5c84fe6da1 JMC-6104: Java Application/Thread Activity does not show the graph Reviewed-by: hirt, jdv ! application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Constants.java ! application/org.openjdk.jmc.flightrecorder.ui/defaultPages.xml ! application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.test/META-INF/MANIFEST.MF ! application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.test/src/test/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/model/test/EventConfigurationModelTest.java ! application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.test/src/test/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/model/test/JfcAndServerSettingsCombinationTest.java ! application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.test/src/test/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/test/PropertyContentBuilderTest.java ! application/tests/org.openjdk.jmc.rjmx.services.jfr.test/META-INF/MANIFEST.MF ! application/tests/org.openjdk.jmc.rjmx.services.jfr.test/src/test/java/org/openjdk/jmc/rjmx/services/jfr/test/OnlineEventOptionsTest.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkTypeIDs.java From marcus.hirt at oracle.com Tue Jul 31 11:03:47 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 31 Jul 2018 11:03:47 +0000 Subject: hg: jmc/jmc: JMC-6093: Revising splash screen to contain micro and Early Access Message-ID: <201807311103.w6VB3ljE000471@aojmv0008.oracle.com> Changeset: f9987e62b984 Author: hirt Date: 2018-07-31 12:57 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/f9987e62b984 JMC-6093: Revising splash screen to contain micro and Early Access Reviewed-by: ghb, jdv ! application/org.openjdk.jmc.rcp.application/splash.bmp From marcus.hirt at oracle.com Tue Jul 31 11:16:11 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 31 Jul 2018 11:16:11 +0000 Subject: hg: jmc/jmc-graphics: JMC-6093: Updated splash screen Message-ID: <201807311116.w6VBGBwC003791@aojmv0008.oracle.com> Changeset: 4fc02b10f5ce Author: hirt Date: 2018-07-31 13:06 +0200 URL: http://hg.openjdk.java.net/jmc/jmc-graphics/rev/4fc02b10f5ce JMC-6093: Updated splash screen ! psd/splash/splash_7_highres.psd From marcus.hirt at oracle.com Tue Jul 31 16:09:52 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 31 Jul 2018 18:09:52 +0200 Subject: [PATCH] Fix JMC-5398 In-Reply-To: References: <366AB89C-94DC-4B69-AE40-0112646C4AD4@redhat.com> <195E25BF-054B-43E3-807C-890637510CBB@oracle.com> Message-ID: Hi Joshua, Looks fine! Mario should be able to sponsor your patch ? he is a committer. Kind regards, Marcus From: Joshua Matsuoka Date: Tuesday, 24 July 2018 at 17:20 To: Marcus Hirt Cc: Mario Torre , Subject: Re: [PATCH] Fix JMC-5398 Hi Marcus, Mario, Here's the updated patch with the missing NON-NLS-1 tag added. Cheers, - Josh On Tue, Jul 24, 2018 at 10:58 AM, Marcus Hirt wrote: Hi Joshua, Greetings from JCrete! Looks good! I realized that there are a few NON-NLS tags missing in core elsewhere. Will open a new bug and simply just push the changes (trivial), unless someone disagrees. Kind regards, Marcus ?On 2018-07-20, 18:07, "jmc-dev on behalf of Mario Torre" wrote: Hi Joshua, The patch looks good, however I would like a second reviewer, especially considering that someone should push your patch if accepted (which I can do of course but at this stage I still prefer if someone from Oracle does it/or gives the OK). I have only one nitpick: + private static final String ATTACH_TIMED_OUT_ERROR_MESSAGE = "Timed out attempting to attach to target JVM!"; I believe that if this is not marked for translation it should be followed by //$NON-NLS-1$ or eclipse will mark a warning about this line. I'm not sure if this code will work on Java 9+, of course that's a concern valid for the existing code too, I'm not sure if Marcus prefer to address that in one go or with a separate patch (assuming there may be other areas of interest, perhaps a separate patch is better, I didn't see a bug regarding this, perhaps we should file one?). Cheers, Mario On Thu, Jul 19, 2018 at 11:39 PM, Joshua Matsuoka wrote: > Hi, > > The following patch fixes JMC-5398 [1]. The bug was twofold, first when > attempting to attach to a JVM that was either busy or suspended JMC would > hang, and second upon restarting the JVM browser would not list any JVMs. > > This patch adds a timeout to the problematic calls. This ensures that > during JVM discovery problematic JVMs are skipped when attaching times out, > keeping the JVM browser functioning properly, as well as ensuring that we > don't hang when attempting to open the JMX console or start a flight > recording for a problematic JVM. > > The timeout is currently 5 seconds but can easily be changed if this is too > short/long. > > [1] > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5398?filter=allopenissues > > Thoughts? > > Cheers, > > - Josh -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Tue Jul 31 16:32:21 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 31 Jul 2018 18:32:21 +0200 Subject: [PATCH] Fix JMC-5398 In-Reply-To: References: <366AB89C-94DC-4B69-AE40-0112646C4AD4@redhat.com> <195E25BF-054B-43E3-807C-890637510CBB@oracle.com> Message-ID: On Tue, Jul 31, 2018 at 6:09 PM, Marcus Hirt wrote: > Hi Joshua, > > > > Looks fine! Mario should be able to sponsor your patch ? he is a committer. Hi Marcus, Joshua, Sure, I'll commit for him thanks for the OK! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Tue Jul 31 16:56:37 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 31 Jul 2018 18:56:37 +0200 Subject: OpenJDK authors now assignable in the Jira. Message-ID: <6EAE4375-6EEE-4355-8ED7-1CBE491CF3DE@oracle.com> Hi all, Jira issues for the JMC project should now be assignable to OpenJDK authors. Please let me know if you run into any trouble! /M From patrick at reini.net Tue Jul 31 17:46:41 2018 From: patrick at reini.net (Patrick Reinhart) Date: Tue, 31 Jul 2018 19:46:41 +0200 Subject: OpenJDK authors now assignable in the Jira. In-Reply-To: <6EAE4375-6EEE-4355-8ED7-1CBE491CF3DE@oracle.com> References: <6EAE4375-6EEE-4355-8ED7-1CBE491CF3DE@oracle.com> Message-ID: Works like a charm :-) -Patrick Am 31.07.2018 um 18:56 schrieb Marcus Hirt: > Hi all, > > Jira issues for the JMC project should now be assignable to OpenJDK authors. > Please let me know if you run into any trouble! > > /M > > From neugens.limasoftware at gmail.com Tue Jul 31 18:02:59 2018 From: neugens.limasoftware at gmail.com (neugens.limasoftware at gmail.com) Date: Tue, 31 Jul 2018 18:02:59 +0000 Subject: hg: jmc/jmc: JMC-5398: Call to "attach busy" JVM hangs and blocks the listing of other local JVMs Message-ID: <201807311802.w6VI2xI2003888@aojmv0008.oracle.com> Changeset: 49f6575169ce Author: neugens Date: 2018-07-31 20:02 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/49f6575169ce JMC-5398: Call to "attach busy" JVM hangs and blocks the listing of other local JVMs Summary: Add timeouts to ensure connecting to busy or blocked JVMs does not block forever Reviewed-by: neugens, hirt Contributed-by: Joshua Matsuoka ! application/org.openjdk.jmc.browser.attach/src/main/java/org/openjdk/jmc/browser/attach/LocalConnectionDescriptor.java ! application/org.openjdk.jmc.browser.attach/src/main/java/org/openjdk/jmc/browser/attach/LocalJVMToolkit.java