From christoph.langer at sap.com Mon Jul 1 08:02:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Jul 2019 08:02:11 +0000 Subject: JMC-6513: Wrong version of compiled classes when importing JMC maven projects in Eclipse with JDT Default Compiler Level of 11 In-Reply-To: References: Message-ID: Hi Marcus, thanks for your comments. I agree - it would be ideal if everything was maintained via Maven and all Eclipse settings would be handled by this. Maybe, if I find time, I'll dig deeper in this. Especially why the behavior is so different between Mac and Windows. However, for the time being, I'd appreciate if this can be pushed. Cheers, Christoph > -----Original Message----- > From: Marcus Hirt > Sent: Freitag, 28. Juni 2019 22:45 > To: Langer, Christoph ; Guru > > Cc: jmc-dev at openjdk.java.net > Subject: Re: JMC-6513: Wrong version of compiled classes when importing > JMC maven projects in Eclipse with JDT Default Compiler Level of 11 > > Hi Christoph, > > I agree; I see no harm in taking this patch, though I would love to > see Maven and Eclipse collaborate better. In the best of all worlds, > no Eclipse project files would be required, Maven would be the one > source of truth and a simple Maven import would be all that is > required. Guru, do you have any strong opinion here? > > Kind regards, > Marcus > > On Fri, Jun 28, 2019 at 9:58 PM Langer, Christoph > wrote: > > > > Ping: Any comments for this? > > > > > > > > From: Langer, Christoph > > Sent: Donnerstag, 20. Juni 2019 23:56 > > To: jmc-dev at openjdk.java.net > > Subject: JMC-6513: Wrong version of compiled classes when importing JMC > maven projects in Eclipse with JDT Default Compiler Level of 11 > > > > > > > > Hi, > > > > > > > > please let me know what you think of this patch: > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JMC-6513 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6513.0/ > > > > > > > > I'm having issues when importing the jmc projects into my Eclipse which > has a default JDK compiler level of 11. Although the JMC projects define a > JSE18 in their .classpath files, the classes get compiled with Java 11 version. > This can be helped by creating ".settings/org.eclipse.jdt.core.prefs" files > which set the compiler to 1.8. Then these issues were gone. So, in my patch I > propose to add them. A Java compiler level of 8 is needed in Eclipse because I > want to be able to run/debug with any JDK down to 8. > > > > > > > > Something is a bit weird though with maven import. On my Windows > Eclipse I observe that the import would generate these > .settings/org.eclipse.jdt.core.prefs as contained in the patch. However, this > import also regenerates some .classpath files which brings other issues and is > not what is wanted. On my Eclipse on Mac, I don't see neither > .settings/org.eclipse.jdt.core.prefs getting generated nor .classpath files > rewritten. Maven settings in both Eclipse installations seem to be the same. > Does anybody have an explanation for that? > > > > > > > > So, AFAICS, I don't think my patch causes any harm and can safely be used. > There's also precedence for that such as the projects in jmc/core (which > compile with JDK 1.7), as well as project > jmc/application/org.openjdk.jmc.osgi.extension which was introduced by > the patch for JMC-5859 [1]. > > > > > > > > Thanks > > > > Christoph > > > > > > > > [1] http://hg.openjdk.java.net/jmc/jmc/rev/2cc768144a86 > > > > > > From marcus.hirt at datadoghq.com Mon Jul 1 08:33:23 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 1 Jul 2019 10:33:23 +0200 Subject: JMC-6513: Wrong version of compiled classes when importing JMC maven projects in Eclipse with JDT Default Compiler Level of 11 In-Reply-To: References: Message-ID: Sounds good! Can you open a new bug on investigating how to get maven to be the single source of truth? I can push this. Kind regards, Marcus On Mon, Jul 1, 2019 at 10:02 AM Langer, Christoph wrote: > > Hi Marcus, > > thanks for your comments. I agree - it would be ideal if everything was maintained via Maven and all Eclipse settings would be handled by this. > > Maybe, if I find time, I'll dig deeper in this. Especially why the behavior is so different between Mac and Windows. > > However, for the time being, I'd appreciate if this can be pushed. > > Cheers, > Christoph > > > -----Original Message----- > > From: Marcus Hirt > > Sent: Freitag, 28. Juni 2019 22:45 > > To: Langer, Christoph ; Guru > > > > Cc: jmc-dev at openjdk.java.net > > Subject: Re: JMC-6513: Wrong version of compiled classes when importing > > JMC maven projects in Eclipse with JDT Default Compiler Level of 11 > > > > Hi Christoph, > > > > I agree; I see no harm in taking this patch, though I would love to > > see Maven and Eclipse collaborate better. In the best of all worlds, > > no Eclipse project files would be required, Maven would be the one > > source of truth and a simple Maven import would be all that is > > required. Guru, do you have any strong opinion here? > > > > Kind regards, > > Marcus > > > > On Fri, Jun 28, 2019 at 9:58 PM Langer, Christoph > > wrote: > > > > > > Ping: Any comments for this? > > > > > > > > > > > > From: Langer, Christoph > > > Sent: Donnerstag, 20. Juni 2019 23:56 > > > To: jmc-dev at openjdk.java.net > > > Subject: JMC-6513: Wrong version of compiled classes when importing JMC > > maven projects in Eclipse with JDT Default Compiler Level of 11 > > > > > > > > > > > > Hi, > > > > > > > > > > > > please let me know what you think of this patch: > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JMC-6513 > > > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6513.0/ > > > > > > > > > > > > I'm having issues when importing the jmc projects into my Eclipse which > > has a default JDK compiler level of 11. Although the JMC projects define a > > JSE18 in their .classpath files, the classes get compiled with Java 11 version. > > This can be helped by creating ".settings/org.eclipse.jdt.core.prefs" files > > which set the compiler to 1.8. Then these issues were gone. So, in my patch I > > propose to add them. A Java compiler level of 8 is needed in Eclipse because I > > want to be able to run/debug with any JDK down to 8. > > > > > > > > > > > > Something is a bit weird though with maven import. On my Windows > > Eclipse I observe that the import would generate these > > .settings/org.eclipse.jdt.core.prefs as contained in the patch. However, this > > import also regenerates some .classpath files which brings other issues and is > > not what is wanted. On my Eclipse on Mac, I don't see neither > > .settings/org.eclipse.jdt.core.prefs getting generated nor .classpath files > > rewritten. Maven settings in both Eclipse installations seem to be the same. > > Does anybody have an explanation for that? > > > > > > > > > > > > So, AFAICS, I don't think my patch causes any harm and can safely be used. > > There's also precedence for that such as the projects in jmc/core (which > > compile with JDK 1.7), as well as project > > jmc/application/org.openjdk.jmc.osgi.extension which was introduced by > > the patch for JMC-5859 [1]. > > > > > > > > > > > > Thanks > > > > > > Christoph > > > > > > > > > > > > [1] http://hg.openjdk.java.net/jmc/jmc/rev/2cc768144a86 > > > > > > > > > From marcus at hirt.se Mon Jul 1 09:38:01 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Mon, 01 Jul 2019 09:38:01 +0000 Subject: hg: jmc/jmc: JMC-6513: Explicitly setting compiler level to JDK 8 Message-ID: <201907010938.x619c2BY002401@aojmv0008.oracle.com> Changeset: 991934efcd7b Author: hirt Date: 2019-07-01 11:37 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/991934efcd7b JMC-6513: Explicitly setting compiler level to JDK 8 Reviewed-by: hirt Contributed-by: clanger + application/org.openjdk.jmc.alert/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.attach/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.browser.attach/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.browser.jdp/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.browser/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.commands/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.console.jconsole/.settings/org.eclipse.jdt.core.prefs ! application/org.openjdk.jmc.console.pde/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.console.persistence/.settings/org.eclipse.jdt.core.prefs ! application/org.openjdk.jmc.console.twitter/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.console.ui.diagnostic/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.console.ui.mbeanbrowser/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.console.ui.notification/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.console.ui.subscriptions/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.console.ui/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.docs/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.configuration/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.controlpanel.ui.configuration/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.controlpanel.ui/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.ext.g1/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.ext.jfx/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.metadata/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.pde/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.rules.extensionprovider/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.ui/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.greychart.ui/.settings/org.eclipse.jdt.core.prefs ! application/org.openjdk.jmc.greychart/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.ide.jdt/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.ide.launch/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.ide.ui/.settings/org.eclipse.jdt.core.prefs ! application/org.openjdk.jmc.javafx.osgi/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.jdp/.settings/org.eclipse.jdt.core.prefs ! application/org.openjdk.jmc.joverflow.ui/.settings/org.eclipse.jdt.core.prefs ! application/org.openjdk.jmc.joverflow/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.pde/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.rcp.application/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.rcp.intro/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.rjmx.ext/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.rjmx.services.jfr/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.rjmx.ui/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.rjmx/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.ui.common/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.ui/.settings/org.eclipse.jdt.core.prefs + application/tests/org.openjdk.jmc.flightrecorder.configuration.test/.settings/org.eclipse.jdt.core.prefs + application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.configuration.test/.settings/org.eclipse.jdt.core.prefs + application/tests/org.openjdk.jmc.ide.launch.test/.settings/org.eclipse.jdt.core.prefs ! application/tests/org.openjdk.jmc.joverflow.test/.settings/org.eclipse.jdt.core.prefs ! application/tests/org.openjdk.jmc.rjmx.test/.settings/org.eclipse.jdt.core.prefs ! application/tests/org.openjdk.jmc.ui.common.test/.settings/org.eclipse.jdt.core.prefs ! application/uitests/org.openjdk.jmc.console.persistence.uitest/.settings/org.eclipse.jdt.core.prefs ! application/uitests/org.openjdk.jmc.console.uitest/.settings/org.eclipse.jdt.core.prefs ! application/uitests/org.openjdk.jmc.rcp.application.uitest/.settings/org.eclipse.jdt.core.prefs ! core/org.openjdk.jmc.common/.settings/org.eclipse.jdt.core.prefs ! core/tests/org.openjdk.jmc.common.test/.settings/org.eclipse.jdt.core.prefs From christoph.langer at sap.com Mon Jul 1 21:29:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Jul 2019 21:29:01 +0000 Subject: JMC-6513: Wrong version of compiled classes when importing JMC maven projects in Eclipse with JDT Default Compiler Level of 11 In-Reply-To: References: Message-ID: Thank you, Marcus. I created https://bugs.openjdk.java.net/browse/JMC-6517. Feel free to edit... > -----Original Message----- > From: Marcus Hirt > Sent: Montag, 1. Juli 2019 10:33 > To: Langer, Christoph > Cc: Guru ; jmc-dev at openjdk.java.net > Subject: Re: JMC-6513: Wrong version of compiled classes when importing > JMC maven projects in Eclipse with JDT Default Compiler Level of 11 > > Sounds good! Can you open a new bug on investigating how to get maven > to be the single source of truth? I can push this. > > Kind regards, > Marcus > > On Mon, Jul 1, 2019 at 10:02 AM Langer, Christoph > wrote: > > > > Hi Marcus, > > > > thanks for your comments. I agree - it would be ideal if everything was > maintained via Maven and all Eclipse settings would be handled by this. > > > > Maybe, if I find time, I'll dig deeper in this. Especially why the behavior is so > different between Mac and Windows. > > > > However, for the time being, I'd appreciate if this can be pushed. > > > > Cheers, > > Christoph > > > > > -----Original Message----- > > > From: Marcus Hirt > > > Sent: Freitag, 28. Juni 2019 22:45 > > > To: Langer, Christoph ; Guru > > > > > > Cc: jmc-dev at openjdk.java.net > > > Subject: Re: JMC-6513: Wrong version of compiled classes when > importing > > > JMC maven projects in Eclipse with JDT Default Compiler Level of 11 > > > > > > Hi Christoph, > > > > > > I agree; I see no harm in taking this patch, though I would love to > > > see Maven and Eclipse collaborate better. In the best of all worlds, > > > no Eclipse project files would be required, Maven would be the one > > > source of truth and a simple Maven import would be all that is > > > required. Guru, do you have any strong opinion here? > > > > > > Kind regards, > > > Marcus > > > > > > On Fri, Jun 28, 2019 at 9:58 PM Langer, Christoph > > > wrote: > > > > > > > > Ping: Any comments for this? > > > > > > > > > > > > > > > > From: Langer, Christoph > > > > Sent: Donnerstag, 20. Juni 2019 23:56 > > > > To: jmc-dev at openjdk.java.net > > > > Subject: JMC-6513: Wrong version of compiled classes when importing > JMC > > > maven projects in Eclipse with JDT Default Compiler Level of 11 > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > please let me know what you think of this patch: > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JMC-6513 > > > > > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6513.0/ > > > > > > > > > > > > > > > > I'm having issues when importing the jmc projects into my Eclipse which > > > has a default JDK compiler level of 11. Although the JMC projects define a > > > JSE18 in their .classpath files, the classes get compiled with Java 11 > version. > > > This can be helped by creating ".settings/org.eclipse.jdt.core.prefs" files > > > which set the compiler to 1.8. Then these issues were gone. So, in my > patch I > > > propose to add them. A Java compiler level of 8 is needed in Eclipse > because I > > > want to be able to run/debug with any JDK down to 8. > > > > > > > > > > > > > > > > Something is a bit weird though with maven import. On my Windows > > > Eclipse I observe that the import would generate these > > > .settings/org.eclipse.jdt.core.prefs as contained in the patch. However, > this > > > import also regenerates some .classpath files which brings other issues > and is > > > not what is wanted. On my Eclipse on Mac, I don't see neither > > > .settings/org.eclipse.jdt.core.prefs getting generated nor .classpath files > > > rewritten. Maven settings in both Eclipse installations seem to be the > same. > > > Does anybody have an explanation for that? > > > > > > > > > > > > > > > > So, AFAICS, I don't think my patch causes any harm and can safely be > used. > > > There's also precedence for that such as the projects in jmc/core (which > > > compile with JDK 1.7), as well as project > > > jmc/application/org.openjdk.jmc.osgi.extension which was introduced by > > > the patch for JMC-5859 [1]. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Christoph > > > > > > > > > > > > > > > > [1] http://hg.openjdk.java.net/jmc/jmc/rev/2cc768144a86 > > > > > > > > > > > > From christoph.langer at sap.com Mon Jul 1 22:20:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Jul 2019 22:20:02 +0000 Subject: RFR(S): JMC-6518: Fix formatting of some notes in Flight Recorder starting page Message-ID: Hi, please review a minor messages cleanup for the Flight Recording dialog. The space following the colon needs to be placed outside the block. Bug: https://bugs.openjdk.java.net/browse/JMC-6518 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6518.0/ Thanks Christoph From marcus.hirt at datadoghq.com Mon Jul 1 22:40:14 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Tue, 2 Jul 2019 00:40:14 +0200 Subject: RFR(S): JMC-6518: Fix formatting of some notes in Flight Recorder starting page In-Reply-To: References: Message-ID: Looks good to me! /M On Tue, Jul 2, 2019 at 12:20 AM Langer, Christoph wrote: > > Hi, > > please review a minor messages cleanup for the Flight Recording dialog. The space following the colon needs to be placed outside the block. > > Bug: https://bugs.openjdk.java.net/browse/JMC-6518 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6518.0/ > > Thanks > Christoph > From marcus at hirt.se Mon Jul 1 22:47:36 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Mon, 01 Jul 2019 22:47:36 +0000 Subject: hg: jmc/jmc: JMC-6518: Fix formatting of some notes in the Start Flight Recording wizard Message-ID: <201907012247.x61MlaPh014370@aojmv0008.oracle.com> Changeset: d580fca65112 Author: hirt Date: 2019-07-02 00:47 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/d580fca65112 JMC-6518: Fix formatting of some notes in the Start Flight Recording wizard Reviewed-by: hirt Contributed-by: clanger ! application/l10n/org.openjdk.jmc.flightrecorder.controlpanel.ui.ja/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages_ja.properties ! application/l10n/org.openjdk.jmc.flightrecorder.controlpanel.ui.zh_CN/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages_zh_CN.properties ! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties From marcus at hirt.se Mon Jul 1 22:50:53 2019 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 2 Jul 2019 00:50:53 +0200 Subject: Sv: JMC-6513: Wrong version of compiled classes when importing JMC maven projects in Eclipse with JDT Default Compiler Level of 11 In-Reply-To: References: Message-ID: <013e01d5305f$6fcc6430$4f652c90$@hirt.se> Looks good! Thank you, Christoph! /M -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Langer, Christoph Skickat: den 1 juli 2019 23:29 Till: Marcus Hirt Kopia: jmc-dev at openjdk.java.net ?mne: RE: JMC-6513: Wrong version of compiled classes when importing JMC maven projects in Eclipse with JDT Default Compiler Level of 11 Thank you, Marcus. I created https://bugs.openjdk.java.net/browse/JMC-6517. Feel free to edit... > -----Original Message----- > From: Marcus Hirt > Sent: Montag, 1. Juli 2019 10:33 > To: Langer, Christoph > Cc: Guru ; jmc-dev at openjdk.java.net > Subject: Re: JMC-6513: Wrong version of compiled classes when > importing JMC maven projects in Eclipse with JDT Default Compiler > Level of 11 > > Sounds good! Can you open a new bug on investigating how to get maven > to be the single source of truth? I can push this. > > Kind regards, > Marcus > > On Mon, Jul 1, 2019 at 10:02 AM Langer, Christoph > wrote: > > > > Hi Marcus, > > > > thanks for your comments. I agree - it would be ideal if everything > > was > maintained via Maven and all Eclipse settings would be handled by this. > > > > Maybe, if I find time, I'll dig deeper in this. Especially why the > > behavior is so > different between Mac and Windows. > > > > However, for the time being, I'd appreciate if this can be pushed. > > > > Cheers, > > Christoph > > > > > -----Original Message----- > > > From: Marcus Hirt > > > Sent: Freitag, 28. Juni 2019 22:45 > > > To: Langer, Christoph ; Guru > > > > > > Cc: jmc-dev at openjdk.java.net > > > Subject: Re: JMC-6513: Wrong version of compiled classes when > importing > > > JMC maven projects in Eclipse with JDT Default Compiler Level of > > > 11 > > > > > > Hi Christoph, > > > > > > I agree; I see no harm in taking this patch, though I would love > > > to see Maven and Eclipse collaborate better. In the best of all > > > worlds, no Eclipse project files would be required, Maven would be > > > the one source of truth and a simple Maven import would be all > > > that is required. Guru, do you have any strong opinion here? > > > > > > Kind regards, > > > Marcus > > > > > > On Fri, Jun 28, 2019 at 9:58 PM Langer, Christoph > > > wrote: > > > > > > > > Ping: Any comments for this? > > > > > > > > > > > > > > > > From: Langer, Christoph > > > > Sent: Donnerstag, 20. Juni 2019 23:56 > > > > To: jmc-dev at openjdk.java.net > > > > Subject: JMC-6513: Wrong version of compiled classes when > > > > importing > JMC > > > maven projects in Eclipse with JDT Default Compiler Level of 11 > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > please let me know what you think of this patch: > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JMC-6513 > > > > > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6513.0/ > > > > > > > > > > > > > > > > I'm having issues when importing the jmc projects into my > > > > Eclipse which > > > has a default JDK compiler level of 11. Although the JMC projects > > > define a > > > JSE18 in their .classpath files, the classes get compiled with > > > Java 11 > version. > > > This can be helped by creating > > > ".settings/org.eclipse.jdt.core.prefs" files which set the > > > compiler to 1.8. Then these issues were gone. So, in my > patch I > > > propose to add them. A Java compiler level of 8 is needed in > > > Eclipse > because I > > > want to be able to run/debug with any JDK down to 8. > > > > > > > > > > > > > > > > Something is a bit weird though with maven import. On my Windows > > > Eclipse I observe that the import would generate these > > > .settings/org.eclipse.jdt.core.prefs as contained in the patch. > > > However, > this > > > import also regenerates some .classpath files which brings other > > > issues > and is > > > not what is wanted. On my Eclipse on Mac, I don't see neither > > > .settings/org.eclipse.jdt.core.prefs getting generated nor > > > .classpath files rewritten. Maven settings in both Eclipse > > > installations seem to be the > same. > > > Does anybody have an explanation for that? > > > > > > > > > > > > > > > > So, AFAICS, I don't think my patch causes any harm and can > > > > safely be > used. > > > There's also precedence for that such as the projects in jmc/core > > > (which compile with JDK 1.7), as well as project > > > jmc/application/org.openjdk.jmc.osgi.extension which was > > > introduced by the patch for JMC-5859 [1]. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Christoph > > > > > > > > > > > > > > > > [1] http://hg.openjdk.java.net/jmc/jmc/rev/2cc768144a86 > > > > > > > > > > > > From christoph.langer at sap.com Tue Jul 2 07:36:22 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Jul 2019 07:36:22 +0000 Subject: RFR(S): JMC-6518: Fix formatting of some notes in Flight Recorder starting page In-Reply-To: References: Message-ID: Thanks, Marcus for reviewing and pushing so quickly ?? > -----Original Message----- > From: Marcus Hirt > Sent: Dienstag, 2. Juli 2019 00:40 > To: Langer, Christoph > Cc: jmc-dev at openjdk.java.net > Subject: Re: RFR(S): JMC-6518: Fix formatting of some notes in Flight > Recorder starting page > > Looks good to me! > > /M > > On Tue, Jul 2, 2019 at 12:20 AM Langer, Christoph > wrote: > > > > Hi, > > > > please review a minor messages cleanup for the Flight Recording dialog. > The space following the colon needs to be placed outside the block. > > > > Bug: https://bugs.openjdk.java.net/browse/JMC-6518 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6518.0/ > > > > Thanks > > Christoph > > From christoph.langer at sap.com Tue Jul 2 15:24:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Jul 2019 15:24:39 +0000 Subject: RFR(S): JMC-6519: Set a correct default destination file for Flight Recording in JMC IDE Plugin mode Message-ID: Hi, here's another little fix. When using the JMC as IDE plugin, at the first start the default JFR recording file that is computed has a bad value. Trying to fix this. Bug: https://bugs.openjdk.java.net/browse/JMC-6519 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6519.0/ I'm wondering whether I could create an automated test here... Any suggestions how this could be done? Thanks Christoph From guru.hb at oracle.com Tue Jul 2 16:19:57 2019 From: guru.hb at oracle.com (Guru) Date: Tue, 2 Jul 2019 21:49:57 +0530 Subject: RFC: JMC-5657: Code coverage with Jacoco In-Reply-To: References: Message-ID: <8AF592BB-9D83-4437-B916-6F452DC9128D@oracle.com> Hi Carmine, Looks good to me, +1 (tested on Mac OS X) With few Nit 1. http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/raw_files/new/application/coverage/pom.xml and http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/raw_files/new/core/coverage/pom.xml In webrev.02 : Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. Expected format : Copyright (c) , , ? 2. Since you have modified few other files "application/pom.xml, application/tests/pom.xml, application/uitests/pom.xml, core/pom.xml and core/tests/pom.xml, Please update "Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved.? And you can also add "Copyright (c) 2019, Red Hat Inc. All rights reserved.? In the second line Before pushing the changes, please do update the above comments. Thanks, Guru > On 28-May-2019, at 7:44 PM, Carmine Vincenzo Russo wrote: > > Hi everyone, > > I took sometimes to fix all the issues, here is the update patch: http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/ > > I have made some comments inline, but for a easier reading here's a summarized version of everything in the patch: > - Two new pom.xml: ~/jmc/core/coverage/pom.xml and ~/jmc/application/coverage/pom.xml > - ~/jmc/core/coverage/pom.xml gets executed during the mvn clean install step to build JMC itself > - ~/jmc/application/coverage/pom.xml gets executed both with mvn verify and mvn verify -P uitests > - If you run just mvn verify the coverage will only show the percentage for ~/jmc/application/tests, while if you run mvn verify -P uitests the coverage will show both the percentage in ~/jmc/application/tests and ~/jmc/application/uitests in the same report. > - All the modules in ~/jmc/applicatin/tests and ~/jmc/application/uitests are dependencies in ~/jmc/application/coverage/pom.xml > - To make sure that everything works fine, the profile uitests is also in ~/jmc/application/coverage/pom.xml, this way the modules from ~/jmc/application/uitests get loaded only when the profile uitests is executed > - Both .gitignore and .hgignore got updated to avoid ~/jmc/*/coverage/coverage-report > - In ~/jmc/application/pom.xml all the modules are uncommented and working now > - Every unrelated and useless comment has been removed > > > On Tue, May 7, 2019 at 6:38 PM Guru > wrote: > > > Hi Carmine, > > > > Please check my comments inline. > > > > Thanks, > > Guru > > > On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo > > > wrote: > > > > > > Hello everyone, > > > > > > This patch adds Jacoco coverage over unit test in JMC. > > > The module covered in particular are: /core/tests and /application/tests. > > > > > > The patch addresses the issue JMC-5657[0], but as noted by Klara Ward[1], > > > instead of adding Jcov, it's better to add Jacoco. > > > > > > For the time being, each test group had a new module, report, where an > > > aggregate-report can be found. > > > You need to run 'mvn verify' in jmc root for /application/tests and in > > > /core for /core/tests to have the coverage report. > > Logically there are three build step > > 1. For releng > > 2. Core modules > > 3. Jmc product (i.e Application) > > Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for step > > 3). > > > Obviously all the 3 steps are needed, I also checked, the 'mvn verify' for > ~/jmc/core is automatically done while building the core modules on step 2. > For jmc product you still need to run 'mvn verify -P uitests' separately > after building the project since you need the test to be executed. > > Unless there is restriction on defining Jacoco in root of > > ~/jmc/core/pom.xml and ~/jmc/pom.xml. > > > > I explain this at the end. > > > > > There are also some aspects that concern me, so: Is this what we are > > > looking for? > > > The report for /core[2] looks good and clean. The report for > > > /application/tests[3][4] has good results, although there are some 0%, > > and > > > that is ok, but also some N/A. Should we keep the modules in the report > > > with only N/A? > > > > > > There are also some changes in /application/uitests when reading the > > patch, > > > they are not yet applied but I would like to add them to the next patch. > > Please file a follow on new JBS and link with old one (relates to > > JMC-5667). > > > > With 'next patch' I just meant the updated patch after the RFC, basically > what I have done now, just wanted to have your opinions before going > forward with the ~/uitests coverage. If a follow up issue is needed, I'll > ask Alex to open it. > > > > > This brings me to my second concern: should the tests and uitests in > > > /application have a unique report or should I keep them separate? > > Good to have Unique rather than separate. > > > > In the new patch attached ~/jmc/application/tests and > ~/jmc/applciation/uitests have a unique coverage in > ~/jmc/application/coverage. > > With Alex's help, I found out there was a problem with having directly a unique coverage report for both ~/jmc/application/tests and ~/jmc/application/uitests. > Because of this now we still have a unique report generated with ~/jmc/application/coverage/pom.xml but inside there is a profile uitests. This way all the dependencies needed for the uitests are only considered when the uitests are executed. Meanwhile with a simple mvn verify you get the coverage only for ~/jmc/application/tests. > > > > Lastly, do we want coverage with every verify build or do we want a maven > > > profile/flag to have the coverage only in some occasions? > > This could be based on how much time Jacoco Code coverage takes. If its > > negligible then good to have on every verify build or with a profile/flag. > > > > In all my tests and attempts the module itself never took more than 10s, > while the build doesn't seem to be affected. So basically I don't think > it's a problem to have always the coverage in every build. > > I took a quick look into this and ran `mvn verify` locally with and without the coverage patch, I saw: > > With Coverage: > core - 1 minute 17 seconds > jmc - 8 minutes 51 seconds > > Without Coverage: > core - 1 minute 3 seconds > jmc - 8 minutes 23 seconds > > > > > > Overall, how does the patch look like? Do you think there are some more > > > modules that need to be covered? And do you have any suggestions on how > > to > > > improve what I've done? > > If possible, please update the patch to ~/jmc/core/pom.xml and > > ~/jmc/pom.xml. > > > > As far as my knowledge goes, to have the report, we need a separate pom.xml > for the report, this because the report-aggregate[0] relies on > and not on , even the JaCoCo examples for this have their own > report module[1]. The best way, I think, is the current situation in which > we have ~/jmc/core/coverage/pom.xml and ~/jmc/application/coverage/pom.xml, > these generate and contains the coverage report, while in > ~/jmc/core/pom.xml and ~/jmc/application/pom.xml we have the JaCoCo agent > that makes the coverage possible. If we try to move everything in > ~/jmc/application/pom.xml and ~/jmc/core/pom.xml the reports will be > segregated in their own modules. Or if we try to move part of it in > ~/jmc/pom.xml we stiil need to have both the agent configuration in > ~/jmc/application/pom.xml and ~/jmc/core/pom.xml and the coverage as > separate modules. > > The aggregation of the coverage reports looks like it will require it's own pom.xml, as exemplified in a sample demo from the JaCoCo github. > https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate > > > All the changes and the new addition can be found here: > http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.01/ > > core/tests/pom.xml > - report is commented out > > All useless and unrelated comment have been removed or fixed to make everything works. > > > Overall I think the patch looks good. I would however like to see the .hgignore and .gitignore updated to exclude the coverage reports; there are a lot of files generated in */coverage/coverage-report/*. > > Both .gitignore and .hgignore got updated to ignore ~/jmc/*/coverage/coverage-report/ > > > Whoops, spoke a tad too soon. > > It's having difficulties at the moment when running uitests. https://travis-ci.org/aptmac/jmc-qa/builds/535820411 > > Apparently this was because of some reference to the old name uireport still around that I didn't notice, it's been taken care of now. > > There's also comments in the application/coverage/pom.xml for the update sites and RCP product. > > All the modules now are uncommented and working, for these three an additional tag was needed because those repositories only have pom files and not jar files. > > > Thanks, > Carmine > > > -- > Carmine Vincenzo Russo From ebaron at redhat.com Tue Jul 2 17:14:46 2019 From: ebaron at redhat.com (Elliott Baron) Date: Tue, 2 Jul 2019 13:14:46 -0400 Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies In-Reply-To: References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com> <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com> <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com> Message-ID: <4a82d545-7d94-d067-d260-fc9a625d316f@redhat.com> Hi Alex, On 2019-06-27 3:23 p.m., Alex Macdonald wrote: > On Tue, May 28, 2019 at 4:44 PM Elliott Baron > wrote: > > Hi Jie, > > On 2019-05-28 1:19 p.m., Jie Kang wrote: > > On Mon, May 27, 2019 at 12:10 PM Elliott Baron > wrote: > >> > >> Hi Marcus, > >> > >> On 2019-05-24 3:13 p.m., Marcus Hirt wrote: > >>> Very nice Elliot! This looks great! > >> > >> Glad to hear it, thanks! > >> > >>> How sure are you of the Japanese and > >>> Chinese translations? Would you want for someone to take a look > at them? > >> > >> These come from substituting the word for "percentile" (found > online) > >> into existing localized strings with the same sort of desired > phrasing > >> (e.g. File I/O Histogram Selection). If there is someone who could > >> verify/improve the translations, I would appreciate it. > > > The Japanese translations were given the thumbs up via Slack the other day. > > It looks like the only thing left to do is to update the platform > definition target for 2019-06 which was added two days ago [0], and it > should be good to go. Here's a revised webrev that also updates the new 2019-06 target platform: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.1/ Good to go? Thanks, Elliott From almacdon at redhat.com Tue Jul 2 19:04:31 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Tue, 2 Jul 2019 15:04:31 -0400 Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies In-Reply-To: <4a82d545-7d94-d067-d260-fc9a625d316f@redhat.com> References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com> <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com> <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com> <4a82d545-7d94-d067-d260-fc9a625d316f@redhat.com> Message-ID: On Tue, Jul 2, 2019 at 1:14 PM Elliott Baron wrote: > Hi Alex, > > On 2019-06-27 3:23 p.m., Alex Macdonald wrote: > > On Tue, May 28, 2019 at 4:44 PM Elliott Baron > > wrote: > > > > Hi Jie, > > > > On 2019-05-28 1:19 p.m., Jie Kang wrote: > > > On Mon, May 27, 2019 at 12:10 PM Elliott Baron > > wrote: > > >> > > >> Hi Marcus, > > >> > > >> On 2019-05-24 3:13 p.m., Marcus Hirt wrote: > > >>> Very nice Elliot! This looks great! > > >> > > >> Glad to hear it, thanks! > > >> > > >>> How sure are you of the Japanese and > > >>> Chinese translations? Would you want for someone to take a look > > at them? > > >> > > >> These come from substituting the word for "percentile" (found > > online) > > >> into existing localized strings with the same sort of desired > > phrasing > > >> (e.g. File I/O Histogram Selection). If there is someone who > could > > >> verify/improve the translations, I would appreciate it. > > > > > > The Japanese translations were given the thumbs up via Slack the other > day. > > > > It looks like the only thing left to do is to update the platform > > definition target for 2019-06 which was added two days ago [0], and it > > should be good to go. > > Here's a revised webrev that also updates the new 2019-06 target > platform: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.1/ Great, thanks. This looks good to go. > > > Good to go? > > Thanks, > Elliott > From marcus.hirt at datadoghq.com Tue Jul 2 19:05:34 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Tue, 2 Jul 2019 21:05:34 +0200 Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies In-Reply-To: <4a82d545-7d94-d067-d260-fc9a625d316f@redhat.com> References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com> <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com> <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com> <4a82d545-7d94-d067-d260-fc9a625d316f@redhat.com> Message-ID: Hi Elliott, For the new files you can scratch 2018 from the copyrights. Kind regards, Marcus On Tue, Jul 2, 2019 at 7:15 PM Elliott Baron wrote: > > Hi Alex, > > On 2019-06-27 3:23 p.m., Alex Macdonald wrote: > > On Tue, May 28, 2019 at 4:44 PM Elliott Baron > > wrote: > > > > Hi Jie, > > > > On 2019-05-28 1:19 p.m., Jie Kang wrote: > > > On Mon, May 27, 2019 at 12:10 PM Elliott Baron > > wrote: > > >> > > >> Hi Marcus, > > >> > > >> On 2019-05-24 3:13 p.m., Marcus Hirt wrote: > > >>> Very nice Elliot! This looks great! > > >> > > >> Glad to hear it, thanks! > > >> > > >>> How sure are you of the Japanese and > > >>> Chinese translations? Would you want for someone to take a look > > at them? > > >> > > >> These come from substituting the word for "percentile" (found > > online) > > >> into existing localized strings with the same sort of desired > > phrasing > > >> (e.g. File I/O Histogram Selection). If there is someone who could > > >> verify/improve the translations, I would appreciate it. > > > > > > The Japanese translations were given the thumbs up via Slack the other day. > > > > It looks like the only thing left to do is to update the platform > > definition target for 2019-06 which was added two days ago [0], and it > > should be good to go. > > Here's a revised webrev that also updates the new 2019-06 target > platform: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.1/ > > Good to go? > > Thanks, > Elliott From jescolem at redhat.com Tue Jul 2 19:56:17 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Tue, 2 Jul 2019 15:56:17 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: Here is an updated patch. It includes: - A message that reads "No 'Flag Changed' events found". I didn't add an explanation for why no events were found because it is possible that the table could be empty for two reasons simultaneously- some XFlagChanged events could be disabled and others could have simply not occurred. However, I am not sure if this message is informative enough. I have placed the message under the title of the table - let me know if this is a good location for it. - Two uitests that test if the table is correctly populated for a flight recording that has multiple XFlagChanged events and if the "No 'Flag Changed' events found" message appears for a flight recording where no XFlagChanged events occur. - Removed empty space/lines Let me know what you think, Jessye On Mon, Jun 24, 2019 at 10:58 AM Ken Dobson wrote: > > I agree, a simple string added to the table saying "No X events found" or > "X event has been disabled" would more than suffice. > > Ken > > > On Mon, Jun 24, 2019 at 7:07 AM Marcus Hirt > wrote: > > > Agree. Perhaps now would be a good time to discuss? > > > > I am, in general, hesitant to automatically hide UI elements. It has been > > tried in the past (e.g. Microsoft hiding menu elements not used much), with > > little success. That said, we should at the very least have some feedback > > showing people whether the lack of data is due to events being disabled or > > events not having occurred. What do you guys think? > > > > Kind regards, > > Marcus > > > > On Thu, Jun 20, 2019 at 8:35 PM Ken Dobson wrote: > > > >> There's a ticket here about how we should handle empty tables > >> https://bugs.openjdk.java.net/browse/JMC-4009 > >> I think it's an issue that might have a larger scope than just this bug > >> but > >> it's definitely worth addressing. > >> > >> Ken Dobson > >> > >> On Thu, Jun 20, 2019 at 1:30 PM Alex Macdonald > >> wrote: > >> > >> > On Thu, Jun 20, 2019 at 9:05 AM Jessye Coleman Shapiro < > >> > jescolem at redhat.com> > >> > wrote: > >> > > >> > > Hi Alex, > >> > > > >> > > I will make those changes and send an updated patch. > >> > > > >> > > >> > Err, whoops. I was reviewing your JMC-5706 patch at the same time as > >> this > >> > one, and must have applied the other patch when I thought it was this > >> one. > >> > The previous review actually applies to your JMC-5706 patch, so I'll > >> copy > >> > the review on that thread. > >> > > >> > As for this patch: > >> > > >> > My initial reaction was that the new table uses up a good portion of the > >> > page real-estate (which is okay), but I'm wondering if the table should > >> > only be displayed if it has values to display. Perhaps someone else > >> could > >> > share their opinions as well. > >> > > >> > There are empty spaces/lines at the following locations: > >> > - defaultPages.xml @ line 597 > >> > - JVMInformationPage.java @ lines 122, 162, 187, 227, 231, 258, 262, > >> 295, > >> > 296, 303, 305, 342, 346 > >> > > >> > The build & uitests pass [0], however because a new component was added > >> to > >> > the UI I'd like to see a uitest to ensure that everything is working as > >> > intended. > >> > > >> > [0] https://travis-ci.org/aptmac/jmc-qa/builds/548262559 > >> > > >> > > >> > > > >> > > Thank you! > >> > > > >> > > Jessye > >> > > > >> > > On Wed, Jun 19, 2019 at 3:45 PM Alex Macdonald > >> > > wrote: > >> > > > >> > >> Hi Jessye, > >> > >> > >> > >> On Fri, Jun 7, 2019 at 2:48 PM Jessye Coleman Shapiro < > >> > >> jescolem at redhat.com> wrote: > >> > >> > >> > >>> Hi, > >> > >>> > >> > >>> This patch addresses JMC-5499: Add XFlagChanged events to JVM > >> > Information > >> > >>> or subpage [0]. I have added a JVM Flags Log table to the JVM > >> > Internals > >> > >>> Page that displays XFlagChanged events. > >> > >>> > >> > >>> Please see the attached patch and let me know what you think. > >> > >>> > >> > >> > >> > >> The content of this patch look good to me. > >> > >> > >> > >> However, there are test failures: > >> > >> > >> > >> > TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 > >> > >> > >> > >> because the generated JfrRuleBaseline.xml doesn't match the hardcopy > >> one > >> > >> used to verify the test. This will need to be updated. > >> > >> > >> > >> There's also some empty spaces that can be cleaned up. > >> > >> > >> > >> JavaBlockingRule.java > >> > >> - empty space @ lines 134, 138, 151 > >> > >> - trailing empty space @ line 142 > >> > >> > >> > >> > >> > >>> > >> > >>> Thank you! > >> > >>> > >> > >>> Jessye Coleman-Shapiro > >> > >>> > >> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-5499 > >> > >> > >> > >> > >> > >> Cheers, > >> > >> > >> > >> Alex > >> > >> > >> > > > >> > > >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-5499.patch Type: text/x-patch Size: 23095 bytes Desc: not available URL: From jmatsuok at redhat.com Tue Jul 2 20:03:14 2019 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Tue, 2 Jul 2019 16:03:14 -0400 Subject: [PATCH] JMC-5706 JavaBlockingRule should report block times In-Reply-To: References: Message-ID: Hi Jessye, Looks good! Send the patch with commit message, summary, etc. to one of us and we can get it pushed for you. Cheers, - Josh On Fri, Jun 21, 2019 at 1:52 PM Alex Macdonald wrote: > Hi Jessye, > > On Thu, Jun 20, 2019 at 3:26 PM Jessye Coleman Shapiro < > jescolem at redhat.com> > wrote: > > > Hi Alex, > > > > On Thu, Jun 20, 2019 at 1:33 PM Alex Macdonald > > wrote: > > > >> Hi Jessye, > >> > >> On Tue, Jun 11, 2019 at 2:54 PM Jessye Coleman Shapiro < > >> jescolem at redhat.com> wrote: > >> > >>> Hello, > >>> > >>> This patch addresses JMC-5706: JavaBlockingRule should report block > times > >>> [0]. I have added the total time a top blocking monitor was blocked on > >>> to > >>> the information reported. > >>> > >>> I have also edited the 'groupedByThread' list filter condition to > ensure > >>> that only 'JavaMonitorEnter' events are being considered when > determining > >>> the 'mostBlockedThread'. Without the filter I was getting a null > >>> pointer > >>> exception, as the most common thread has not necessarily been blocked > and > >>> therefore may not have a blocking time associated with it - let me know > >>> if > >>> this is not the case. > >>> > >>> See the attached patch bellow and let me know what you think. > >>> > >> > >> I was looking your JMC-5499 patch at the same time as this one, and I > >> must have got their bug IDs reversed when I was taking a look through > them. > >> As a result, I posted my initial review for this patch on the e-mail > thread > >> for JMC-5499 [0]. So I'll copy the notes below: > >> > >> The content of this patch look good to me. > >> > >> However, there are test failures: > >> > >> > TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 > >> > >> because the generated JfrRuleBaseline.xml doesn't match the hardcopy one > >> used to verify the test. This will need to be updated. > >> > >> There's also some empty spaces that can be cleaned up. > >> > >> JavaBlockingRule.java > >> - empty space @ lines 134, 138, 151 > >> - trailing empty space @ line 142 > >> > >> > >>> > >>> Thank you! > >>> > >>> Jessye > >>> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-5706 > >> > >> > >> Cheers, > >> > >> Alex > >> > >> [0] > http://mail.openjdk.java.net/pipermail/jmc-dev/2019-June/001146.html > >> > > > > Here is the updated patch with empty and trailing space removed, as well > > as the TestRulesWithJfr.verifyAllResults test fixed. > > > > Great, thanks. The tests passed and it looks good to me. > > > > > > Thanks for the help, > > > > Jessye > > > > > Cheers, > > Alex > From marcus at hirt.se Tue Jul 2 20:29:15 2019 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 2 Jul 2019 22:29:15 +0200 Subject: RFR(S): JMC-6519: Set a correct default destination file for Flight Recording in JMC IDE Plugin mode In-Reply-To: References: Message-ID: <57C49CB6-280D-4BF0-9BF0-A76BA9FA757A@hirt.se> The automated tests are all run on the RCP, so would need more work. I think it?s fine to leave this one without a test. That said, did you try it on Windows + Linux and/or Mac? Kind regards, Marcus > On Jul 2, 2019, at 5:24 PM, Langer, Christoph wrote: > > Hi, > > here's another little fix. When using the JMC as IDE plugin, at the first start the default JFR recording file that is computed has a bad value. Trying to fix this. > > Bug: https://bugs.openjdk.java.net/browse/JMC-6519 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6519.0/ > > I'm wondering whether I could create an automated test here... Any suggestions how this could be done? > > Thanks > Christoph > From christoph.langer at sap.com Tue Jul 2 21:23:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Jul 2019 21:23:29 +0000 Subject: RFR(S): JMC-6519: Set a correct default destination file for Flight Recording in JMC IDE Plugin mode In-Reply-To: <57C49CB6-280D-4BF0-9BF0-A76BA9FA757A@hirt.se> References: <57C49CB6-280D-4BF0-9BF0-A76BA9FA757A@hirt.se> Message-ID: I tested it on Windows. Will also check on Mac/Linux and let you know. Thanks Christoph > -----Original Message----- > From: Marcus Hirt > Sent: Dienstag, 2. Juli 2019 22:29 > To: Langer, Christoph > Cc: jmc-dev at openjdk.java.net > Subject: Re: RFR(S): JMC-6519: Set a correct default destination file for Flight > Recording in JMC IDE Plugin mode > > The automated tests are all run on the RCP, so would need more work. I > think it?s fine to leave this one without a test. That said, did you try it on > Windows + Linux and/or Mac? > > Kind regards, > Marcus > > > On Jul 2, 2019, at 5:24 PM, Langer, Christoph > wrote: > > > > Hi, > > > > here's another little fix. When using the JMC as IDE plugin, at the first start > the default JFR recording file that is computed has a bad value. Trying to fix > this. > > > > Bug: https://bugs.openjdk.java.net/browse/JMC-6519 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6519.0/ > > > > I'm wondering whether I could create an automated test here... Any > suggestions how this could be done? > > > > Thanks > > Christoph > > From florian.david at gmail.com Wed Jul 3 15:52:07 2019 From: florian.david at gmail.com (Florian David) Date: Wed, 3 Jul 2019 17:52:07 +0200 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: Le jeu. 27 juin 2019 ? 23:38, Jie Kang a ?crit : > Hi Florian, > > Hi Jie, Thanks for the review. Please find the new one taking into account your feedback here: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.1/ > Changes look mostly good. > > # I have some suggestions and comments below: > > * The Messages also contain: > > CompareCpuRule_INFO_LIMIT=Competing CPU usage limit > CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other > processes needed to trigger an info notice > CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit > CompareCpuRule_WARNING_LIMIT_LONG=The amount of CPU used by other > processes needed to trigger a warning > > I think this patch should also alter these descriptions to reflect the > new calculation behind the rule. To be honest I'm not sure how to > describe the new meaning succinctly in words, otherwise I'd provide a > suggestion, sorry; > > I have updated these messages: CompareCpuRule_TEXT_INFO_LONG=The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine. ... CompareCpuRule_TEXT_MESSAGE=An average CPU load of {2} was caused by other processes during {0} starting at {1}. CompareCpuRule_INFO_LIMIT=Competing CPU usage info limit CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other processes times the overall CPU usage needed to trigger an info notice CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit I tried to keep these messages simple and not overwhelming the user with lot of details. However, if you think it should be even more detailed, I can be more precise. > # The following comments could be addressed in different Jira issues, if > at all: > > * The SpanToolkit is used twice on the items now, once for the max and > once for the ratio. Could the underlying iterations over the items be > combined? I understand they calculate different spans, one of which is > used in the message while the other is used for the score. Could they > be aligned? > > * It's curious that the SpanToolkit is given the warning limit whereas > the long message is generated if the score is above the info limit. As > well, the warning limit is used to determine if spans get combined > while the end result used for the score process is the longest span, > regardless of it's value's relation to the warning limit. Should it be > the longest span that's above the warning limit, if possible, > otherwise the longest span? I guess it depends on if the initial spans > vary in length or not. I'm not sure how to describe it but something > feels strange here. > > I agree, these comments are relevant. However I'm not yet a contributor thus I don't have rights to create Jira tickets :( How can we address that ? For the second point, I also believe there is something fishy in this code about using the warning limit instead of the info limit is incorrect. I'm not mastering spans already but passing warning limit to *getMaxSpanLimit* should exclude span below this limit, thus only triggering the rule if score is above warning limit only and never of it's between info and warning limits. Something is wrong in this workflow. # The following is just a question for the intended design: > > * After an initial read of these changes, I would expect that if I set > a warning limit of say 0.4, then a warning would be triggered if there > is a longest span where the CPU usage of other processes was 40% and > the total CPU usage was 100% I.e. the range is like [1]? Is that > right? > > [1] > x*y x: CPU Usage of Other Processes over the longest span of time > y: CPU Usage of All Processes over longest span of time > > Yes that's exactly the computation being done. The core idea is that when machine CPU is low, it's meaningless to trigger the rule since there is still enough CPU to run other processes. The multiplication by 'y' decreases the score in this case. Regards, Florian > > Regards, > > > On Thu, Jun 27, 2019 at 5:34 AM Florian David > wrote: > > > > Hi all, > > > > Please review this fix for the CPU load rule. > > > > JIRA: https://bugs.openjdk.java.net/browse/JMC-6512 > > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.0/ > > > > Regards, > > Florian > From ebaron at redhat.com Wed Jul 3 16:09:22 2019 From: ebaron at redhat.com (Elliott Baron) Date: Wed, 3 Jul 2019 12:09:22 -0400 Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies In-Reply-To: References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com> <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com> <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com> <4a82d545-7d94-d067-d260-fc9a625d316f@redhat.com> Message-ID: Hi Marcus, On 2019-07-02 3:05 p.m., Marcus Hirt wrote: > Hi Elliott, > > For the new files you can scratch 2018 from the copyrights. > Sure. Here is a revised webrev with the copyright dates changed: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.2/ Thanks, Elliott From marcus.hirt at datadoghq.com Wed Jul 3 16:11:44 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Wed, 3 Jul 2019 18:11:44 +0200 Subject: Review request JMC-6520: Remove old JDK version rule Message-ID: Hi all, Please review this change to remove the old JDK version rule. Jira: https://bugs.openjdk.java.net/browse/JMC-6520 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6520/webrev.0/ Kind regards, Marcus From marcus.hirt at datadoghq.com Wed Jul 3 16:20:10 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Wed, 3 Jul 2019 18:20:10 +0200 Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies In-Reply-To: References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com> <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com> <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com> <4a82d545-7d94-d067-d260-fc9a625d316f@redhat.com> Message-ID: Excellent! Good to go! Kind regards, Marcus On Wed, Jul 3, 2019 at 6:09 PM Elliott Baron wrote: > Hi Marcus, > > On 2019-07-02 3:05 p.m., Marcus Hirt wrote: > > Hi Elliott, > > > > For the new files you can scratch 2018 from the copyrights. > > > > Sure. Here is a revised webrev with the copyright dates changed: > http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.2/ > > Thanks, > Elliott > From almacdon at redhat.com Wed Jul 3 19:02:48 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Wed, 03 Jul 2019 19:02:48 +0000 Subject: hg: jmc/jmc: JMC-5327: Using HdrHistograms to visualize latencies Message-ID: <201907031902.x63J2mKP008811@aojmv0008.oracle.com> Changeset: 34ffc8031fa8 Author: ebaron Date: 2019-07-03 11:55 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/34ffc8031fa8 JMC-5327: Using HdrHistograms to visualize latencies Summary: Add HdrHistogram-backed table to show IO latency percentile distribution Reviewed-by: hirt, aptmac ! application/l10n/org.openjdk.jmc.flightrecorder.ui.ja/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages_ja.properties ! application/l10n/org.openjdk.jmc.flightrecorder.ui.zh_CN/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages_zh_CN.properties ! application/org.openjdk.jmc.flightrecorder.ui/META-INF/MANIFEST.MF ! application/org.openjdk.jmc.flightrecorder.ui/defaultPages.xml + application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/DurationHdrHistogram.java + application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/DurationPercentileTable.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ItemHistogram.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/FileIOPage.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/SocketIOPage.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties ! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/column/ColumnManager.java ! application/uitests/org.openjdk.jmc.flightrecorder.uitest/META-INF/MANIFEST.MF + application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/pages/FileIOPageTest.java + application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/pages/IOPageTestBase.java + application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/pages/SocketIOPageTest.java + application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/resources/jfr/io_test.jfr ! releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target ! releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target ! releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target ! releng/platform-definitions/platform-definition-2019-06/platform-definition-2019-06.target ! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target ! releng/third-party/pom.xml From carusso at redhat.com Thu Jul 4 08:52:30 2019 From: carusso at redhat.com (Carmine Vincenzo Russo) Date: Thu, 4 Jul 2019 10:52:30 +0200 Subject: RFC: JMC-5657: Code coverage with Jacoco In-Reply-To: <8AF592BB-9D83-4437-B916-6F452DC9128D@oracle.com> References: <8AF592BB-9D83-4437-B916-6F452DC9128D@oracle.com> Message-ID: Hi Guru, Just to let everyone know, here is the updated version: http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.03/ The old files are all updated with only "Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved." While the new one have both "Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved." in the first line and "Copyright (c) 2019, Red Hat Inc. All rights reserved." in the second line. Thanks, Carmine On Tue, Jul 2, 2019 at 6:20 PM Guru wrote: > Hi Carmine, > > Looks good to me, +1 (tested on Mac OS X) With few Nit > > 1. > http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/raw_files/new/application/coverage/pom.xml > and > http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/raw_files/new/core/coverage/pom.xml > In webrev.02 : Copyright (c) 2018, 2019, Oracle and/or its > affiliates. All rights reserved. > Expected format : Copyright (c) , year>, ? > > 2. Since you have modified few other files "application/pom.xml, > application/tests/pom.xml, application/uitests/pom.xml, core/pom.xml and > core/tests/pom.xml, Please update "Copyright (c) 2018, 2019, Oracle and/or > its affiliates. All rights reserved.? And you can also add "Copyright (c) > 2019, Red Hat Inc. All rights reserved.? In the second line > > Before pushing the changes, please do update the above comments. > > Thanks, > Guru > > On 28-May-2019, at 7:44 PM, Carmine Vincenzo Russo > wrote: > > Hi everyone, > > I took sometimes to fix all the issues, here is the update patch: > http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/ > > I have made some comments inline, but for a easier reading here's a > summarized version of everything in the patch: > - Two new pom.xml: ~/jmc/core/coverage/pom.xml and > ~/jmc/application/coverage/pom.xml > - ~/jmc/core/coverage/pom.xml gets executed during the *mvn clean install* > step to build JMC itself > - ~/jmc/application/coverage/pom.xml gets executed both with *mvn verify* > and *mvn verify -P uitests* > - If you run just *mvn verify* the coverage will only show the percentage > for ~/jmc/application/tests, while if you run *mvn verify -P uitests *the > coverage will show both the percentage in ~/jmc/application/tests and > ~/jmc/application/uitests in the same report. > - All the modules in ~/jmc/applicatin/tests and ~/jmc/application/uitests > are dependencies in ~/jmc/application/coverage/pom.xml > - To make sure that everything works fine, the profile *uitests* is also > in ~/jmc/application/coverage/pom.xml, this way the modules from > ~/jmc/application/uitests get loaded only when the profile uitests is > executed > - Both .gitignore and .hgignore got updated to avoid > ~/jmc/*/coverage/coverage-report > - In ~/jmc/application/pom.xml all the modules are uncommented and working > now > - Every unrelated and useless comment has been removed > > >>>> On Tue, May 7, 2019 at 6:38 PM Guru wrote: >>>> >>>> > Hi Carmine, >>>> > >>>> > Please check my comments inline. >>>> > >>>> > Thanks, >>>> > Guru >>>> > > On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo < >>>> carusso at redhat.com> >>>> > wrote: >>>> > > >>>> > > Hello everyone, >>>> > > >>>> > > This patch adds Jacoco coverage over unit test in JMC. >>>> > > The module covered in particular are: /core/tests and >>>> /application/tests. >>>> > > >>>> > > The patch addresses the issue JMC-5657[0], but as noted by Klara >>>> Ward[1], >>>> > > instead of adding Jcov, it's better to add Jacoco. >>>> > > >>>> > > For the time being, each test group had a new module, report, where >>>> an >>>> > > aggregate-report can be found. >>>> > > You need to run 'mvn verify' in jmc root for /application/tests and >>>> in >>>> > > /core for /core/tests to have the coverage report. >>>> > Logically there are three build step >>>> > 1. For releng >>>> > 2. Core modules >>>> > 3. Jmc product (i.e Application) >>>> > Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for >>>> step >>>> > 3). >>>> >>>> >>>> Obviously all the 3 steps are needed, I also checked, the 'mvn verify' >>>> for >>>> ~/jmc/core is automatically done while building the core modules on >>>> step 2. >>>> For jmc product you still need to run 'mvn verify -P uitests' separately >>>> after building the project since you need the test to be executed. >>>> >>>> Unless there is restriction on defining Jacoco in root of >>>> > ~/jmc/core/pom.xml and ~/jmc/pom.xml. >>>> > >>>> >>>> I explain this at the end. >>>> >>>> >>>> > > There are also some aspects that concern me, so: Is this what we are >>>> > > looking for? >>>> > > The report for /core[2] looks good and clean. The report for >>>> > > /application/tests[3][4] has good results, although there are some >>>> 0%, >>>> > and >>>> > > that is ok, but also some N/A. Should we keep the modules in the >>>> report >>>> > > with only N/A? >>>> > > >>>> > > There are also some changes in /application/uitests when reading the >>>> > patch, >>>> > > they are not yet applied but I would like to add them to the next >>>> patch. >>>> > Please file a follow on new JBS and link with old one (relates to >>>> > JMC-5667). >>>> > >>>> >>>> With 'next patch' I just meant the updated patch after the RFC, >>>> basically >>>> what I have done now, just wanted to have your opinions before going >>>> forward with the ~/uitests coverage. If a follow up issue is needed, >>>> I'll >>>> ask Alex to open it. >>>> >>>> >>>> > > This brings me to my second concern: should the tests and uitests in >>>> > > /application have a unique report or should I keep them separate? >>>> > Good to have Unique rather than separate. >>>> > >>>> >>>> In the new patch attached ~/jmc/application/tests and >>>> ~/jmc/applciation/uitests have a unique coverage in >>>> ~/jmc/application/coverage. >>>> >>> > With Alex's help, I found out there was a problem with having directly a > unique coverage report for both ~/jmc/application/tests and > ~/jmc/application/uitests. > Because of this now we still have a unique report generated with > ~/jmc/application/coverage/pom.xml but inside there is a profile *uitests*. > This way all the dependencies needed for the uitests are only considered > when the uitests are executed. Meanwhile with a simple *mvn verify* you > get the coverage only for ~/jmc/application/tests. > > >> > > Lastly, do we want coverage with every verify build or do we want a >>>> maven >>>> > > profile/flag to have the coverage only in some occasions? >>>> > This could be based on how much time Jacoco Code coverage takes. If >>>> its >>>> > negligible then good to have on every verify build or with a >>>> profile/flag. >>>> > >>>> >>>> In all my tests and attempts the module itself never took more than 10s, >>>> while the build doesn't seem to be affected. So basically I don't think >>>> it's a problem to have always the coverage in every build. >>>> >>> >>> I took a quick look into this and ran `mvn verify` locally with and >>> without the coverage patch, I saw: >>> >>> With Coverage: >>> core - 1 minute 17 seconds >>> jmc - 8 minutes 51 seconds >>> >>> Without Coverage: >>> core - 1 minute 3 seconds >>> jmc - 8 minutes 23 seconds >>> >>> >>>> >>>> > > Overall, how does the patch look like? Do you think there are some >>>> more >>>> > > modules that need to be covered? And do you have any suggestions on >>>> how >>>> > to >>>> > > improve what I've done? >>>> > If possible, please update the patch to ~/jmc/core/pom.xml and >>>> > ~/jmc/pom.xml. >>>> > >>>> >>>> As far as my knowledge goes, to have the report, we need a separate >>>> pom.xml >>>> for the report, this because the report-aggregate[0] relies on >>>> >>>> and not on , even the JaCoCo examples for this have their own >>>> report module[1]. The best way, I think, is the current situation in >>>> which >>>> we have ~/jmc/core/coverage/pom.xml and >>>> ~/jmc/application/coverage/pom.xml, >>>> these generate and contains the coverage report, while in >>>> ~/jmc/core/pom.xml and ~/jmc/application/pom.xml we have the JaCoCo >>>> agent >>>> that makes the coverage possible. If we try to move everything in >>>> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml the reports will be >>>> segregated in their own modules. Or if we try to move part of it in >>>> ~/jmc/pom.xml we stiil need to have both the agent configuration in >>>> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml and the coverage as >>>> separate modules. >>>> >>> >>> The aggregation of the coverage reports looks like it will require it's >>> own pom.xml, as exemplified in a sample demo from the JaCoCo github. >>> >>> https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate >>> >>> >>>> >>>> All the changes and the new addition can be found here: >>>> http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.01/ >>>> >>> >>> core/tests/pom.xml >>> - report is commented out >>> >> > All useless and unrelated comment have been removed or fixed to make > everything works. > > >> >>> Overall I think the patch looks good. I would however like to see the >>> .hgignore and .gitignore updated to exclude the coverage reports; there are >>> a lot of files generated in */coverage/coverage-report/*. >>> >> > Both .gitignore and .hgignore got updated to ignore > ~/jmc/*/coverage/coverage-report/ > > >> >> Whoops, spoke a tad too soon. >> >> It's having difficulties at the moment when running uitests. >> https://travis-ci.org/aptmac/jmc-qa/builds/535820411 >> > > Apparently this was because of some reference to the old name *uireport* > still around that I didn't notice, it's been taken care of now. > > >> There's also comments in the application/coverage/pom.xml for the update >> sites and RCP product. >> > > All the modules now are uncommented and working, for these three an > additional tag was needed because those repositories only have pom files > and not jar files. > > > Thanks, > Carmine > > > -- > Carmine Vincenzo Russo > > > -- Carmine Vincenzo Russo From carusso at redhat.com Thu Jul 4 10:05:29 2019 From: carusso at redhat.com (Carmine Vincenzo Russo) Date: Thu, 4 Jul 2019 12:05:29 +0200 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: <5D14E918.80302@oracle.com> References: <5D14E918.80302@oracle.com> Message-ID: Hi Erik, Thank you for your response. On Thu, Jun 27, 2019 at 6:05 PM Erik Gahlin wrote: > Hi Carmine , > > Searching the home directory could take a very long time. It could also > open the wrong file if several files have the same name. I don't think > it is the correct approach. > I know, starting from the user home is a little bit extreme and can take a while, therefore instead I'm starting from the current directory in the updated patch and searching the subdirectories from there. Since JMC doesn't have a specific folder to save the recordings it all depends on the users. As for files with the same name, there is the same problem, JMC gives the possibility to choose the name for every recordings, therefore to have two files with the same name the user should do it on purpose. > > Have you tried Paths.get(".", filename) ? > > It will look in the current working directory. To see if the full path > is correct do > > path.normalize().toAbsolutePath() > > if this doesn't work, it could be because of some magic happening in jmc > launcher, in which case the current directory have to be extracted in > the launcher code. > Updated the patch with you suggestions regarding Paths, everything seems to work fine. At the moment a full path, a path with ~/ and a filename both in the current directory or in a subdirectories of the current directory open a recording. Also I made some tests for the function findFile, there are 3 tests right now: - EmptyPathTest: tests what happens with an empty string as filename. - ValidFileNameTest: tests with a temp file whether findFile can find the correct file. - InvalidFileNameTest: tests what happens when the given filename doesn't exists. Here the updated patch: http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.01/ Thanks, Carmine > Erik > > Hi, > > > > On Fri, Jun 21, 2019 at 10:39 AM Jie Kang wrote: > > > >> On Fri, Jun 21, 2019 at 8:31 AM Carmine Vincenzo Russo > >> wrote: > >>> Hello, > >>> > >>> The patch addresses the issue JMC-6173[0]. > >>> I have added a check to see if the path is full or not. If it falls in > >> the > >>> second case, starting from the user home it recursively search for the > >>> given file name in all the not hidden folder. > >>> There was also a problem with relative path like ~/record/test.jfr, now > >>> fixed. > >>> I tested the patch with full path, relative path, filename only and > null > >>> value. > >>> > >>> I'm planning to add few tests, at least for a valid filename, an > invalid > >>> filename and a null value. > >>> > >>> See the attached patch bellow and let me know what you think. > >> I don't see an attachment unfortunately; was it missed or maybe > stripped? > >> > > Carmine sent me a note saying he attached the patch to the e-mail but it > > doesn't appear to show up here. Instead, please find his patch at the > > following webrev: > > > > http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.00/ > > > > I believe he's looking into unit tests at the moment, but wanted feedback > > on his implementation before going forward. > > > > > >> Regards, > >> > >>> Thank you! > >>> Carmine > >>> > >>> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-6173 > >>> > >>> -- > >>> Carmine Vincenzo Russo > > Cheers, > > > > Alex > > -- Carmine Vincenzo Russo From guru.hb at oracle.com Thu Jul 4 10:05:48 2019 From: guru.hb at oracle.com (Guru) Date: Thu, 4 Jul 2019 15:35:48 +0530 Subject: RFC: JMC-5657: Code coverage with Jacoco In-Reply-To: References: <8AF592BB-9D83-4437-B916-6F452DC9128D@oracle.com> Message-ID: +1 @webrev.03 Thanks, Guru > On 04-Jul-2019, at 2:22 PM, Carmine Vincenzo Russo wrote: > > Hi Guru, > > Just to let everyone know, here is the updated version: http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.03/ > > The old files are all updated with only "Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved." > While the new one have both "Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved." in the first line and "Copyright (c) 2019, Red Hat Inc. All rights reserved." in the second line. > > Thanks, > Carmine > > > On Tue, Jul 2, 2019 at 6:20 PM Guru > wrote: > Hi Carmine, > > Looks good to me, +1 (tested on Mac OS X) With few Nit > > 1. http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/raw_files/new/application/coverage/pom.xml and http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/raw_files/new/core/coverage/pom.xml > In webrev.02 : Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. > Expected format : Copyright (c) , , ? > > 2. Since you have modified few other files "application/pom.xml, application/tests/pom.xml, application/uitests/pom.xml, core/pom.xml and core/tests/pom.xml, Please update "Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved.? And you can also add "Copyright (c) 2019, Red Hat Inc. All rights reserved.? In the second line > > Before pushing the changes, please do update the above comments. > > Thanks, > Guru > >> On 28-May-2019, at 7:44 PM, Carmine Vincenzo Russo > wrote: >> >> Hi everyone, >> >> I took sometimes to fix all the issues, here is the update patch: http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/ >> >> I have made some comments inline, but for a easier reading here's a summarized version of everything in the patch: >> - Two new pom.xml: ~/jmc/core/coverage/pom.xml and ~/jmc/application/coverage/pom.xml >> - ~/jmc/core/coverage/pom.xml gets executed during the mvn clean install step to build JMC itself >> - ~/jmc/application/coverage/pom.xml gets executed both with mvn verify and mvn verify -P uitests >> - If you run just mvn verify the coverage will only show the percentage for ~/jmc/application/tests, while if you run mvn verify -P uitests the coverage will show both the percentage in ~/jmc/application/tests and ~/jmc/application/uitests in the same report. >> - All the modules in ~/jmc/applicatin/tests and ~/jmc/application/uitests are dependencies in ~/jmc/application/coverage/pom.xml >> - To make sure that everything works fine, the profile uitests is also in ~/jmc/application/coverage/pom.xml, this way the modules from ~/jmc/application/uitests get loaded only when the profile uitests is executed >> - Both .gitignore and .hgignore got updated to avoid ~/jmc/*/coverage/coverage-report >> - In ~/jmc/application/pom.xml all the modules are uncommented and working now >> - Every unrelated and useless comment has been removed >> >> >> On Tue, May 7, 2019 at 6:38 PM Guru > wrote: >> >> > Hi Carmine, >> > >> > Please check my comments inline. >> > >> > Thanks, >> > Guru >> > > On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo > >> > wrote: >> > > >> > > Hello everyone, >> > > >> > > This patch adds Jacoco coverage over unit test in JMC. >> > > The module covered in particular are: /core/tests and /application/tests. >> > > >> > > The patch addresses the issue JMC-5657[0], but as noted by Klara Ward[1], >> > > instead of adding Jcov, it's better to add Jacoco. >> > > >> > > For the time being, each test group had a new module, report, where an >> > > aggregate-report can be found. >> > > You need to run 'mvn verify' in jmc root for /application/tests and in >> > > /core for /core/tests to have the coverage report. >> > Logically there are three build step >> > 1. For releng >> > 2. Core modules >> > 3. Jmc product (i.e Application) >> > Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for step >> > 3). >> >> >> Obviously all the 3 steps are needed, I also checked, the 'mvn verify' for >> ~/jmc/core is automatically done while building the core modules on step 2. >> For jmc product you still need to run 'mvn verify -P uitests' separately >> after building the project since you need the test to be executed. >> >> Unless there is restriction on defining Jacoco in root of >> > ~/jmc/core/pom.xml and ~/jmc/pom.xml. >> > >> >> I explain this at the end. >> >> >> > > There are also some aspects that concern me, so: Is this what we are >> > > looking for? >> > > The report for /core[2] looks good and clean. The report for >> > > /application/tests[3][4] has good results, although there are some 0%, >> > and >> > > that is ok, but also some N/A. Should we keep the modules in the report >> > > with only N/A? >> > > >> > > There are also some changes in /application/uitests when reading the >> > patch, >> > > they are not yet applied but I would like to add them to the next patch. >> > Please file a follow on new JBS and link with old one (relates to >> > JMC-5667). >> > >> >> With 'next patch' I just meant the updated patch after the RFC, basically >> what I have done now, just wanted to have your opinions before going >> forward with the ~/uitests coverage. If a follow up issue is needed, I'll >> ask Alex to open it. >> >> >> > > This brings me to my second concern: should the tests and uitests in >> > > /application have a unique report or should I keep them separate? >> > Good to have Unique rather than separate. >> > >> >> In the new patch attached ~/jmc/application/tests and >> ~/jmc/applciation/uitests have a unique coverage in >> ~/jmc/application/coverage. >> >> With Alex's help, I found out there was a problem with having directly a unique coverage report for both ~/jmc/application/tests and ~/jmc/application/uitests. >> Because of this now we still have a unique report generated with ~/jmc/application/coverage/pom.xml but inside there is a profile uitests. This way all the dependencies needed for the uitests are only considered when the uitests are executed. Meanwhile with a simple mvn verify you get the coverage only for ~/jmc/application/tests. >> >> > > Lastly, do we want coverage with every verify build or do we want a maven >> > > profile/flag to have the coverage only in some occasions? >> > This could be based on how much time Jacoco Code coverage takes. If its >> > negligible then good to have on every verify build or with a profile/flag. >> > >> >> In all my tests and attempts the module itself never took more than 10s, >> while the build doesn't seem to be affected. So basically I don't think >> it's a problem to have always the coverage in every build. >> >> I took a quick look into this and ran `mvn verify` locally with and without the coverage patch, I saw: >> >> With Coverage: >> core - 1 minute 17 seconds >> jmc - 8 minutes 51 seconds >> >> Without Coverage: >> core - 1 minute 3 seconds >> jmc - 8 minutes 23 seconds >> >> >> >> > > Overall, how does the patch look like? Do you think there are some more >> > > modules that need to be covered? And do you have any suggestions on how >> > to >> > > improve what I've done? >> > If possible, please update the patch to ~/jmc/core/pom.xml and >> > ~/jmc/pom.xml. >> > >> >> As far as my knowledge goes, to have the report, we need a separate pom.xml >> for the report, this because the report-aggregate[0] relies on >> and not on , even the JaCoCo examples for this have their own >> report module[1]. The best way, I think, is the current situation in which >> we have ~/jmc/core/coverage/pom.xml and ~/jmc/application/coverage/pom.xml, >> these generate and contains the coverage report, while in >> ~/jmc/core/pom.xml and ~/jmc/application/pom.xml we have the JaCoCo agent >> that makes the coverage possible. If we try to move everything in >> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml the reports will be >> segregated in their own modules. Or if we try to move part of it in >> ~/jmc/pom.xml we stiil need to have both the agent configuration in >> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml and the coverage as >> separate modules. >> >> The aggregation of the coverage reports looks like it will require it's own pom.xml, as exemplified in a sample demo from the JaCoCo github. >> https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate >> >> >> All the changes and the new addition can be found here: >> http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.01/ >> >> core/tests/pom.xml >> - report is commented out >> >> All useless and unrelated comment have been removed or fixed to make everything works. >> >> >> Overall I think the patch looks good. I would however like to see the .hgignore and .gitignore updated to exclude the coverage reports; there are a lot of files generated in */coverage/coverage-report/*. >> >> Both .gitignore and .hgignore got updated to ignore ~/jmc/*/coverage/coverage-report/ >> >> >> Whoops, spoke a tad too soon. >> >> It's having difficulties at the moment when running uitests. https://travis-ci.org/aptmac/jmc-qa/builds/535820411 >> >> Apparently this was because of some reference to the old name uireport still around that I didn't notice, it's been taken care of now. >> >> There's also comments in the application/coverage/pom.xml for the update sites and RCP product. >> >> All the modules now are uncommented and working, for these three an additional tag was needed because those repositories only have pom files and not jar files. >> >> >> Thanks, >> Carmine >> >> >> -- >> Carmine Vincenzo Russo > > > > -- > Carmine Vincenzo Russo From almacdon at redhat.com Thu Jul 4 14:12:37 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Thu, 04 Jul 2019 14:12:37 +0000 Subject: hg: jmc/jmc: JMC-5657: Start using JaCoCo for code coverage Message-ID: <201907041412.x64ECbU3004806@aojmv0008.oracle.com> Changeset: 76adc33bafb0 Author: aptmac Date: 2019-07-03 15:07 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/76adc33bafb0 JMC-5657: Start using JaCoCo for code coverage Summary: Added code coverage with JaCoCo for all the modules in both jmc/core/ and jmc/application Reviewed-by: ghb, aptmac Contributed-by: Carmine Vincenzo Russo ! .gitignore ! .hgignore + application/coverage/pom.xml ! application/pom.xml ! application/tests/pom.xml ! application/uitests/pom.xml + core/coverage/pom.xml ! core/pom.xml ! core/tests/pom.xml From jescolem at redhat.com Thu Jul 4 15:42:52 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Thu, 4 Jul 2019 11:42:52 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: Here is an updated version of the patch: http://cr.openjdk.java.net/~aptmac/JMC-5499/webrev.01/ I modified the uitests in JVMInformationPageTest to act as general checks for table population instead of asserting exact table entries. String comparisons of dates were failing in some environments and not others. Let me know what you think, Jessye On Tue, Jul 2, 2019 at 3:56 PM Jessye Coleman Shapiro wrote: > Here is an updated patch. It includes: > > - A message that reads "No 'Flag Changed' events found". I didn't add > an explanation for why no events were found because it is possible > that the table could be empty for two reasons simultaneously- some > XFlagChanged events could be disabled and others could have simply not > occurred. However, I am not sure if this message is informative > enough. I have placed the message under the title of the table - let > me know if this is a good location for it. > - Two uitests that test if the table is correctly populated for a > flight recording that has multiple XFlagChanged events and if the "No > 'Flag Changed' events found" message appears for a flight recording > where no XFlagChanged events occur. > - Removed empty space/lines > > Let me know what you think, > > Jessye > > On Mon, Jun 24, 2019 at 10:58 AM Ken Dobson wrote: > > > > I agree, a simple string added to the table saying "No X events found" or > > "X event has been disabled" would more than suffice. > > > > Ken > > > > > > On Mon, Jun 24, 2019 at 7:07 AM Marcus Hirt > > wrote: > > > > > Agree. Perhaps now would be a good time to discuss? > > > > > > I am, in general, hesitant to automatically hide UI elements. It has > been > > > tried in the past (e.g. Microsoft hiding menu elements not used much), > with > > > little success. That said, we should at the very least have some > feedback > > > showing people whether the lack of data is due to events being > disabled or > > > events not having occurred. What do you guys think? > > > > > > Kind regards, > > > Marcus > > > > > > On Thu, Jun 20, 2019 at 8:35 PM Ken Dobson wrote: > > > > > >> There's a ticket here about how we should handle empty tables > > >> https://bugs.openjdk.java.net/browse/JMC-4009 > > >> I think it's an issue that might have a larger scope than just this > bug > > >> but > > >> it's definitely worth addressing. > > >> > > >> Ken Dobson > > >> > > >> On Thu, Jun 20, 2019 at 1:30 PM Alex Macdonald > > >> wrote: > > >> > > >> > On Thu, Jun 20, 2019 at 9:05 AM Jessye Coleman Shapiro < > > >> > jescolem at redhat.com> > > >> > wrote: > > >> > > > >> > > Hi Alex, > > >> > > > > >> > > I will make those changes and send an updated patch. > > >> > > > > >> > > > >> > Err, whoops. I was reviewing your JMC-5706 patch at the same time as > > >> this > > >> > one, and must have applied the other patch when I thought it was > this > > >> one. > > >> > The previous review actually applies to your JMC-5706 patch, so I'll > > >> copy > > >> > the review on that thread. > > >> > > > >> > As for this patch: > > >> > > > >> > My initial reaction was that the new table uses up a good portion > of the > > >> > page real-estate (which is okay), but I'm wondering if the table > should > > >> > only be displayed if it has values to display. Perhaps someone else > > >> could > > >> > share their opinions as well. > > >> > > > >> > There are empty spaces/lines at the following locations: > > >> > - defaultPages.xml @ line 597 > > >> > - JVMInformationPage.java @ lines 122, 162, 187, 227, 231, 258, 262, > > >> 295, > > >> > 296, 303, 305, 342, 346 > > >> > > > >> > The build & uitests pass [0], however because a new component was > added > > >> to > > >> > the UI I'd like to see a uitest to ensure that everything is > working as > > >> > intended. > > >> > > > >> > [0] https://travis-ci.org/aptmac/jmc-qa/builds/548262559 > > >> > > > >> > > > >> > > > > >> > > Thank you! > > >> > > > > >> > > Jessye > > >> > > > > >> > > On Wed, Jun 19, 2019 at 3:45 PM Alex Macdonald < > almacdon at redhat.com> > > >> > > wrote: > > >> > > > > >> > >> Hi Jessye, > > >> > >> > > >> > >> On Fri, Jun 7, 2019 at 2:48 PM Jessye Coleman Shapiro < > > >> > >> jescolem at redhat.com> wrote: > > >> > >> > > >> > >>> Hi, > > >> > >>> > > >> > >>> This patch addresses JMC-5499: Add XFlagChanged events to JVM > > >> > Information > > >> > >>> or subpage [0]. I have added a JVM Flags Log table to the JVM > > >> > Internals > > >> > >>> Page that displays XFlagChanged events. > > >> > >>> > > >> > >>> Please see the attached patch and let me know what you think. > > >> > >>> > > >> > >> > > >> > >> The content of this patch look good to me. > > >> > >> > > >> > >> However, there are test failures: > > >> > >> > > >> > >> > TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 > > >> > >> > > >> > >> because the generated JfrRuleBaseline.xml doesn't match the > hardcopy > > >> one > > >> > >> used to verify the test. This will need to be updated. > > >> > >> > > >> > >> There's also some empty spaces that can be cleaned up. > > >> > >> > > >> > >> JavaBlockingRule.java > > >> > >> - empty space @ lines 134, 138, 151 > > >> > >> - trailing empty space @ line 142 > > >> > >> > > >> > >> > > >> > >>> > > >> > >>> Thank you! > > >> > >>> > > >> > >>> Jessye Coleman-Shapiro > > >> > >>> > > >> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-5499 > > >> > >> > > >> > >> > > >> > >> Cheers, > > >> > >> > > >> > >> Alex > > >> > >> > > >> > > > > >> > > > >> > > > > From almacdon at redhat.com Thu Jul 4 17:42:45 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 4 Jul 2019 13:42:45 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: On Thu, Jul 4, 2019 at 11:43 AM Jessye Coleman Shapiro wrote: > Here is an updated version of the patch: > http://cr.openjdk.java.net/~aptmac/JMC-5499/webrev.01/ > > > I modified the uitests in JVMInformationPageTest to act as general checks > for table population instead of asserting exact table entries. String > comparisons of dates were failing in some environments and not others. > The test file looks good, just a couple nits: - there will need to be a license header for the file - the second test is missing the "Log" part in the method name to indicate the "LogTable" like written in the previous test - the string value for "Old Value" could be retrieved from Messages - now that JMC-5327 is pushed there's a folder for flightrecorder page uitests, this could be placed in there (alongside FileIOPageTest, etc.) No issues or failures when running these tests: https://travis-ci.org/aptmac/jmc-qa/builds/554307170 > > Let me know what you think, > > Jessye > > > On Tue, Jul 2, 2019 at 3:56 PM Jessye Coleman Shapiro > > wrote: > > > Here is an updated patch. It includes: > > > > - A message that reads "No 'Flag Changed' events found". I didn't add > > an explanation for why no events were found because it is possible > > that the table could be empty for two reasons simultaneously- some > > XFlagChanged events could be disabled and others could have simply not > > occurred. However, I am not sure if this message is informative > > enough. I have placed the message under the title of the table - let > > me know if this is a good location for it. > I think this is good for now. I do agree with Marcus's statement about not hiding away UI elements that we're not using. My initial inclination was that the table itself could be not displayed, but because this table is a component of sash form then the header title would still be visible (and the sash weights adjusted to reclaim space). However, that's still a band-aid solution to the bigger problem of better handling empty states. There is already an issue in JIRA for this sort of behaviour (JMC-4009), so I'll take a couple ideas and chime in there. > - Two uitests that test if the table is correctly populated for a > > flight recording that has multiple XFlagChanged events and if the "No > > 'Flag Changed' events found" message appears for a flight recording > > where no XFlagChanged events occur. > > - Removed empty space/lines > > > > Let me know what you think, > > > > Jessye > > > > On Mon, Jun 24, 2019 at 10:58 AM Ken Dobson wrote: > > > > > > I agree, a simple string added to the table saying "No X events found" > or > > > "X event has been disabled" would more than suffice. > > > > > > Ken > > > > > > > > > On Mon, Jun 24, 2019 at 7:07 AM Marcus Hirt > > > > wrote: > > > > > > > Agree. Perhaps now would be a good time to discuss? > > > > > > > > I am, in general, hesitant to automatically hide UI elements. It has > > been > > > > tried in the past (e.g. Microsoft hiding menu elements not used > much), > > with > > > > little success. That said, we should at the very least have some > > feedback > > > > showing people whether the lack of data is due to events being > > disabled or > > > > events not having occurred. What do you guys think? > > > > > > > > Kind regards, > > > > Marcus > > > > > > > > On Thu, Jun 20, 2019 at 8:35 PM Ken Dobson > wrote: > > > > > > > >> There's a ticket here about how we should handle empty tables > > > >> https://bugs.openjdk.java.net/browse/JMC-4009 > > > >> I think it's an issue that might have a larger scope than just this > > bug > > > >> but > > > >> it's definitely worth addressing. > > > >> > > > >> Ken Dobson > > > >> > > > >> On Thu, Jun 20, 2019 at 1:30 PM Alex Macdonald > > > > >> wrote: > > > >> > > > >> > On Thu, Jun 20, 2019 at 9:05 AM Jessye Coleman Shapiro < > > > >> > jescolem at redhat.com> > > > >> > wrote: > > > >> > > > > >> > > Hi Alex, > > > >> > > > > > >> > > I will make those changes and send an updated patch. > > > >> > > > > > >> > > > > >> > Err, whoops. I was reviewing your JMC-5706 patch at the same time > as > > > >> this > > > >> > one, and must have applied the other patch when I thought it was > > this > > > >> one. > > > >> > The previous review actually applies to your JMC-5706 patch, so > I'll > > > >> copy > > > >> > the review on that thread. > > > >> > > > > >> > As for this patch: > > > >> > > > > >> > My initial reaction was that the new table uses up a good portion > > of the > > > >> > page real-estate (which is okay), but I'm wondering if the table > > should > > > >> > only be displayed if it has values to display. Perhaps someone > else > > > >> could > > > >> > share their opinions as well. > > > >> > > > > >> > There are empty spaces/lines at the following locations: > > > >> > - defaultPages.xml @ line 597 > > > >> > - JVMInformationPage.java @ lines 122, 162, 187, 227, 231, 258, > 262, > > > >> 295, > > > >> > 296, 303, 305, 342, 346 > > > >> > > > > >> > The build & uitests pass [0], however because a new component was > > added > > > >> to > > > >> > the UI I'd like to see a uitest to ensure that everything is > > working as > > > >> > intended. > > > >> > > > > >> > [0] https://travis-ci.org/aptmac/jmc-qa/builds/548262559 > > > >> > > > > >> > > > > >> > > > > > >> > > Thank you! > > > >> > > > > > >> > > Jessye > > > >> > > > > > >> > > On Wed, Jun 19, 2019 at 3:45 PM Alex Macdonald < > > almacdon at redhat.com> > > > >> > > wrote: > > > >> > > > > > >> > >> Hi Jessye, > > > >> > >> > > > >> > >> On Fri, Jun 7, 2019 at 2:48 PM Jessye Coleman Shapiro < > > > >> > >> jescolem at redhat.com> wrote: > > > >> > >> > > > >> > >>> Hi, > > > >> > >>> > > > >> > >>> This patch addresses JMC-5499: Add XFlagChanged events to JVM > > > >> > Information > > > >> > >>> or subpage [0]. I have added a JVM Flags Log table to the JVM > > > >> > Internals > > > >> > >>> Page that displays XFlagChanged events. > > > >> > >>> > > > >> > >>> Please see the attached patch and let me know what you think. > > > >> > >>> > > > >> > >> > > > >> > >> The content of this patch look good to me. > > > >> > >> > > > >> > >> However, there are test failures: > > > >> > >> > > > >> > >> > TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 > > > >> > >> > > > >> > >> because the generated JfrRuleBaseline.xml doesn't match the > > hardcopy > > > >> one > > > >> > >> used to verify the test. This will need to be updated. > > > >> > >> > > > >> > >> There's also some empty spaces that can be cleaned up. > > > >> > >> > > > >> > >> JavaBlockingRule.java > > > >> > >> - empty space @ lines 134, 138, 151 > > > >> > >> - trailing empty space @ line 142 > > > >> > >> > > > >> > >> > > > >> > >>> > > > >> > >>> Thank you! > > > >> > >>> > > > >> > >>> Jessye Coleman-Shapiro > > > >> > >>> > > > >> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-5499 > > > >> > >> > > > >> > >> > > > >> > >> Cheers, > > > >> > >> > > > >> > >> Alex > > > >> > >> > > > >> > > > > > >> > > > > >> > > > > > > > From guru.hb at oracle.com Fri Jul 5 02:16:18 2019 From: guru.hb at oracle.com (Guru) Date: Fri, 5 Jul 2019 07:46:18 +0530 Subject: Review request JMC-6520: Remove old JDK version rule In-Reply-To: References: Message-ID: +1, Looks good to me. Thanks, Guru > On 03-Jul-2019, at 9:41 PM, Marcus Hirt wrote: > > Hi all, > > Please review this change to remove the old JDK version rule. > > > Jira: https://bugs.openjdk.java.net/browse/JMC-6520 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6520/webrev.0/ > > > Kind regards, > Marcus From neugens at redhat.com Fri Jul 5 07:50:00 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 5 Jul 2019 09:50:00 +0200 Subject: Review request JMC-6520: Remove old JDK version rule In-Reply-To: References: Message-ID: Yes, thanks! Cheers, Mario On Fri, Jul 5, 2019 at 4:17 AM Guru wrote: > > +1, Looks good to me. > > Thanks, > Guru > > On 03-Jul-2019, at 9:41 PM, Marcus Hirt wrote: > > > > Hi all, > > > > Please review this change to remove the old JDK version rule. > > > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-6520 > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6520/webrev.0/ > > > > > > Kind regards, > > Marcus > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at datadoghq.com Fri Jul 5 14:46:21 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Fri, 5 Jul 2019 16:46:21 +0200 Subject: EOI Demos and Planning In-Reply-To: References: Message-ID: Hi all, The EOI demos and planning will be the 22nd of July, 16:00 CET. Invites have been sent out. If you didn't receive an invite, and would like to attend, ping me in the slack or e-mail me! Kind regards, Marcus On Mon, Jun 24, 2019 at 1:53 PM Marcus Hirt wrote: > Hi all, > > It would be great to meet up for iteration demos at the end of this > (extended) summer iteration! > > Here are a few time slots that I am considering: > 16:00 CET Friday the 19th of July > 16:00 CET Monday the 22nd of July > 18:00 CET Monday the 22nd of July > > To make it easier to choose a time, I'll have a vote in the #planning > channel on the Slack [1]. > Ping me if you need an invite! > > Kind regards, > Marcus > > [1] https://join.slack.com/t/jdkmissioncontrol/signup > From jmatsuok at redhat.com Fri Jul 5 14:59:58 2019 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Fri, 05 Jul 2019 14:59:58 +0000 Subject: hg: jmc/jmc: JMC-5706: JavaBlocking rule should report total block times Message-ID: <201907051459.x65ExwSE013339@aojmv0008.oracle.com> Changeset: 2fac6ba730a3 Author: jmatsuoka Date: 2019-07-05 10:59 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/2fac6ba730a3 JMC-5706: JavaBlocking rule should report total block times Summary: Added total block time to information displayed about most blocked thread or class Reviewed-by: aptmac, jmatsuoka Contributed-by: Jessye Coleman-Shapiro ! 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/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml From marcus at hirt.se Fri Jul 5 15:36:23 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Fri, 05 Jul 2019 15:36:23 +0000 Subject: hg: jmc/jmc: JMC-6520: Removing the old JDK version rule Message-ID: <201907051536.x65FaNLA003561@aojmv0008.oracle.com> Changeset: 659b7d0350d6 Author: hirt Date: 2019-07-05 17:36 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/659b7d0350d6 JMC-6520: Removing the old JDK version rule Reviewed-by: ghb,neugens - core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/UnsupportedJdkVersionRule.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/META-INF/services/org.openjdk.jmc.flightrecorder.rules.IRule ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml From jkang at redhat.com Mon Jul 8 14:58:59 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 8 Jul 2019 10:58:59 -0400 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: On Wed, Jul 3, 2019 at 11:52 AM Florian David wrote: > > > > Le jeu. 27 juin 2019 ? 23:38, Jie Kang a ?crit : >> >> Hi Florian, >> > Hi Jie, > > Thanks for the review. Please find the new one taking into account your feedback here: > http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.1/ > >> >> Changes look mostly good. >> >> # I have some suggestions and comments below: >> >> * The Messages also contain: >> >> CompareCpuRule_INFO_LIMIT=Competing CPU usage limit >> CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other >> processes needed to trigger an info notice >> CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit >> CompareCpuRule_WARNING_LIMIT_LONG=The amount of CPU used by other >> processes needed to trigger a warning >> >> I think this patch should also alter these descriptions to reflect the >> new calculation behind the rule. To be honest I'm not sure how to >> describe the new meaning succinctly in words, otherwise I'd provide a >> suggestion, sorry; >> > I have updated these messages: > > CompareCpuRule_TEXT_INFO_LONG=The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine. > ... > CompareCpuRule_TEXT_MESSAGE=An average CPU load of {2} was caused by other processes during {0} starting at {1}. > CompareCpuRule_INFO_LIMIT=Competing CPU usage info limit > CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other processes times the overall CPU usage needed to trigger an info notice > CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit > > I tried to keep these messages simple and not overwhelming the user with lot of details. > However, if you think it should be even more detailed, I can be more precise. Hey Florian, These messages are fine with me. Unfortunately some of the tests now fail: [ERROR] Failures: [ERROR] TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 I am guessing the JfrRuleBaseline.xml needs to have some more updates for the new changes. I think the rest of the patch looks fine! > >> >> # The following comments could be addressed in different Jira issues, if at all: >> >> * The SpanToolkit is used twice on the items now, once for the max and >> once for the ratio. Could the underlying iterations over the items be >> combined? I understand they calculate different spans, one of which is >> used in the message while the other is used for the score. Could they >> be aligned? >> >> * It's curious that the SpanToolkit is given the warning limit whereas >> the long message is generated if the score is above the info limit. As >> well, the warning limit is used to determine if spans get combined >> while the end result used for the score process is the longest span, >> regardless of it's value's relation to the warning limit. Should it be >> the longest span that's above the warning limit, if possible, >> otherwise the longest span? I guess it depends on if the initial spans >> vary in length or not. I'm not sure how to describe it but something >> feels strange here. >> > I agree, these comments are relevant. However I'm not yet a contributor > thus I don't have rights to create Jira tickets :( How can we address that ? I think you can ask Marcus to create a Jira ticket for you. Regards, > > For the second point, I also believe there is something fishy in this code > about using the warning limit instead of the info limit is incorrect. I'm not > mastering spans already but passing warning limit to getMaxSpanLimit > should exclude span below this limit, thus only triggering the rule if score > is above warning limit only and never of it's between info and warning limits. > Something is wrong in this workflow. > >> # The following is just a question for the intended design: >> >> * After an initial read of these changes, I would expect that if I set >> a warning limit of say 0.4, then a warning would be triggered if there >> is a longest span where the CPU usage of other processes was 40% and >> the total CPU usage was 100% I.e. the range is like [1]? Is that >> right? >> >> [1] >> x*y> x: CPU Usage of Other Processes over the longest span of time >> y: CPU Usage of All Processes over longest span of time >> > Yes that's exactly the computation being done. The core idea is that when > machine CPU is low, it's meaningless to trigger the rule since there is still enough > CPU to run other processes. The multiplication by 'y' decreases the score > in this case. > > Regards, > Florian > >> >> >> Regards, >> >> >> On Thu, Jun 27, 2019 at 5:34 AM Florian David wrote: >> > >> > Hi all, >> > >> > Please review this fix for the CPU load rule. >> > >> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6512 >> > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.0/ >> > >> > Regards, >> > Florian From marcus.hirt at datadoghq.com Mon Jul 8 15:25:30 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 8 Jul 2019 11:25:30 -0400 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: Jira ticket opened here: https://bugs.openjdk.java.net/browse/JMC-6523 /M On Mon, Jul 8, 2019 at 10:59 AM Jie Kang wrote: > On Wed, Jul 3, 2019 at 11:52 AM Florian David > wrote: > > > > > > > > Le jeu. 27 juin 2019 ? 23:38, Jie Kang a ?crit : > >> > >> Hi Florian, > >> > > Hi Jie, > > > > Thanks for the review. Please find the new one taking into account your > feedback here: > > http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.1/ > > > >> > >> Changes look mostly good. > >> > >> # I have some suggestions and comments below: > >> > >> * The Messages also contain: > >> > >> CompareCpuRule_INFO_LIMIT=Competing CPU usage limit > >> CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other > >> processes needed to trigger an info notice > >> CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit > >> CompareCpuRule_WARNING_LIMIT_LONG=The amount of CPU used by other > >> processes needed to trigger a warning > >> > >> I think this patch should also alter these descriptions to reflect the > >> new calculation behind the rule. To be honest I'm not sure how to > >> describe the new meaning succinctly in words, otherwise I'd provide a > >> suggestion, sorry; > >> > > I have updated these messages: > > > > CompareCpuRule_TEXT_INFO_LONG=The application performance can be > affected when the machine is under heavy load and there are other processes > that use CPU or other resources on the same computer. To profile > representatively or get higher throughput, shut down other resource > intensive processes running on the machine. > > ... > > CompareCpuRule_TEXT_MESSAGE=An average CPU load of {2} was caused by > other processes during {0} starting at {1}. > > CompareCpuRule_INFO_LIMIT=Competing CPU usage info limit > > CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other processes > times the overall CPU usage needed to trigger an info notice > > CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit > > > > I tried to keep these messages simple and not overwhelming the user with > lot of details. > > However, if you think it should be even more detailed, I can be more > precise. > > Hey Florian, > > These messages are fine with me. Unfortunately some of the tests now fail: > > [ERROR] Failures: > [ERROR] TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 > > I am guessing the JfrRuleBaseline.xml needs to have some more updates > for the new changes. > > I think the rest of the patch looks fine! > > > > >> > >> # The following comments could be addressed in different Jira issues, > if at all: > >> > >> * The SpanToolkit is used twice on the items now, once for the max and > >> once for the ratio. Could the underlying iterations over the items be > >> combined? I understand they calculate different spans, one of which is > >> used in the message while the other is used for the score. Could they > >> be aligned? > >> > >> * It's curious that the SpanToolkit is given the warning limit whereas > >> the long message is generated if the score is above the info limit. As > >> well, the warning limit is used to determine if spans get combined > >> while the end result used for the score process is the longest span, > >> regardless of it's value's relation to the warning limit. Should it be > >> the longest span that's above the warning limit, if possible, > >> otherwise the longest span? I guess it depends on if the initial spans > >> vary in length or not. I'm not sure how to describe it but something > >> feels strange here. > >> > > I agree, these comments are relevant. However I'm not yet a contributor > > thus I don't have rights to create Jira tickets :( How can we address > that ? > > I think you can ask Marcus to create a Jira ticket for you. > > > Regards, > > > > > > > For the second point, I also believe there is something fishy in this > code > > about using the warning limit instead of the info limit is incorrect. > I'm not > > mastering spans already but passing warning limit to getMaxSpanLimit > > should exclude span below this limit, thus only triggering the rule if > score > > is above warning limit only and never of it's between info and warning > limits. > > Something is wrong in this workflow. > > > >> # The following is just a question for the intended design: > >> > >> * After an initial read of these changes, I would expect that if I set > >> a warning limit of say 0.4, then a warning would be triggered if there > >> is a longest span where the CPU usage of other processes was 40% and > >> the total CPU usage was 100% I.e. the range is like [1]? Is that > >> right? > >> > >> [1] > >> x*y >> x: CPU Usage of Other Processes over the longest span of time > >> y: CPU Usage of All Processes over longest span of time > >> > > Yes that's exactly the computation being done. The core idea is that when > > machine CPU is low, it's meaningless to trigger the rule since there is > still enough > > CPU to run other processes. The multiplication by 'y' decreases the score > > in this case. > > > > Regards, > > Florian > > > >> > >> > >> Regards, > >> > >> > >> On Thu, Jun 27, 2019 at 5:34 AM Florian David > wrote: > >> > > >> > Hi all, > >> > > >> > Please review this fix for the CPU load rule. > >> > > >> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6512 > >> > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.0/ > >> > > >> > Regards, > >> > Florian > From jkang at redhat.com Mon Jul 8 19:57:24 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 8 Jul 2019 15:57:24 -0400 Subject: RFC: JMC-6524: Rename Launcher files and exclude spaces Message-ID: Hi, Please review the attached patch targeting JMC-6524 [1]. I tried to create a webrev but of course, the webrev system did not enjoy the files with spaces in them. It renames the launcher files, replacing ' ' (spaces) with '-' and removed usages of brackets '(' and ')'. If there are any stronger opinions on how the files should be renamed, please do let me know! I would be glad to accommodate. I have tried using these configurations with Eclipse 2019-03 on Fedora 30 (X11). Testing on other system setups would be appreciated! Regards, [1] https://bugs.openjdk.java.net/browse/JMC-6524 -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6524.patch Type: text/x-patch Size: 8757 bytes Desc: not available URL: From jkang at redhat.com Mon Jul 8 20:03:38 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 8 Jul 2019 16:03:38 -0400 Subject: Review request for JMC-JMC-4057: Adding experimental flame graph view. In-Reply-To: <08f401d52844$b1857ba0$149072e0$@hirt.se> References: <08f401d52844$b1857ba0$149072e0$@hirt.se> Message-ID: On Fri, Jun 21, 2019 at 11:19 AM Marcus Hirt wrote: > > Hi all, > > Please review this change to add an experimental flame graph view. > See known issues in the Jira. > > Also cleaning up some imports, and excluding JOverflow from the > development launchers until JMC-6343 is fixed. > > Jira: https://bugs.openjdk.java.net/browse/JMC-4057 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.0/ Hi Marcus, I have one comment below: * There are two spotbugs failures: VA_FORMAT_STRING_USES_NEWLINE: For TraceTreeUtils.printTree:110, the format string can use %n instead of /n for a platform-specific line separator. The use of \n can also be altered in TraceTreeUtils.printTree:104 to be platform-independent via System.lineSeparator(). SBSC_USE_STRINGBUFFER_CONCATENATION: For TraceTreeUtils.indent:119, spotbugs would prefer a StringBuilder/StringBuffer for building the result. Apart from this, I think this patch as an initial commit of this work looks good! It worked for me on Fedora 30. For the record, I was not able to view the launcher changes due to the webrev issue. I have opened a JIRA issue [1] to track it and also supplied a potential fix through the mailing list [2]. [1] https://bugs.openjdk.java.net/browse/JMC-6524 [2] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-July/001226.html Regards, > > Kind regards, > Marcus > From erik.gahlin at oracle.com Mon Jul 8 20:47:20 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 8 Jul 2019 22:47:20 +0200 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: References: <5D14E918.80302@oracle.com> Message-ID: <5D23ABD8.3020401@oracle.com> Hi Carmine, See comments inline. > Hi Erik, > > Thank you for your response. > > On Thu, Jun 27, 2019 at 6:05 PM Erik Gahlin > wrote: > > Hi Carmine , > > Searching the home directory could take a very long time. It could > also > open the wrong file if several files have the same name. I don't > think > it is the correct approach. > > > I know, starting from the user home is a little bit extreme and can > take a while, therefore instead I'm starting from the current directory It's the same problem. On my computer, it could take an hour if I am in the wrong directory or a network share. I don't know any other applications that searches for a file in subdirectories. > in the updated patch and searching the subdirectories from there. > Since JMC doesn't have a specific folder to save the recordings it all > depends on the users. This is primarily meant for command-line users. For example, $ java -XX:StartFlightRecording -jar my.jar ... $ jcmd 4711 JFR.dump filename=dump.jfr $ jmc -open recording.jfr The cumbersome part here is to switch to a GUI and do various operations with the mouse. > As for files with the same name, there is the same problem, JMC gives > the possibility to choose the name for every recordings, therefore to > have two files with the same name the user should do it on purpose. > > > Have you tried Paths.get(".", filename) ? > > It will look in the current working directory. To see if the full > path > is correct do > > path.normalize().toAbsolutePath() > > if this doesn't work, it could be because of some magic happening > in jmc > launcher, in which case the current directory have to be extracted in > the launcher code. > > > Updated the patch with you suggestions regarding Paths, everything > seems to work fine. Good, have you tried on the most common OSes (Mac, Linux and Windows)? Thanks Erik > At the moment a full path, a path with ~/ and a filename both in the > current directory or in a subdirectories of the current directory open > a recording. > Also I made some tests for the function findFile, there are 3 tests > right now: > - EmptyPathTest: tests what happens with an empty string as filename. > - ValidFileNameTest: tests with a temp file whether findFile can find > the correct file. > - InvalidFileNameTest: tests what happens when the given filename > doesn't exists. > Here the updated patch: > http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.01/ > > > Thanks, > Carmine > > > Erik > > Hi, > > > > On Fri, Jun 21, 2019 at 10:39 AM Jie Kang > wrote: > > > >> On Fri, Jun 21, 2019 at 8:31 AM Carmine Vincenzo Russo > >> > wrote: > >>> Hello, > >>> > >>> The patch addresses the issue JMC-6173[0]. > >>> I have added a check to see if the path is full or not. If it > falls in > >> the > >>> second case, starting from the user home it recursively search > for the > >>> given file name in all the not hidden folder. > >>> There was also a problem with relative path like > ~/record/test.jfr, now > >>> fixed. > >>> I tested the patch with full path, relative path, filename > only and null > >>> value. > >>> > >>> I'm planning to add few tests, at least for a valid filename, > an invalid > >>> filename and a null value. > >>> > >>> See the attached patch bellow and let me know what you think. > >> I don't see an attachment unfortunately; was it missed or maybe > stripped? > >> > > Carmine sent me a note saying he attached the patch to the > e-mail but it > > doesn't appear to show up here. Instead, please find his patch > at the > > following webrev: > > > > http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.00/ > > > > > I believe he's looking into unit tests at the moment, but wanted > feedback > > on his implementation before going forward. > > > > > >> Regards, > >> > >>> Thank you! > >>> Carmine > >>> > >>> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-6173 > >>> > >>> -- > >>> Carmine Vincenzo Russo > > Cheers, > > > > Alex > > > > -- > Carmine Vincenzo Russo From jescolem at redhat.com Tue Jul 9 17:03:32 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Tue, 9 Jul 2019 13:03:32 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: Hi, Here is the webrev for an updated patch: http://cr.openjdk.java.net/~aptmac/JMC-5499/webrev.02/ On Thu, Jul 4, 2019 at 1:43 PM Alex Macdonald wrote: > > On Thu, Jul 4, 2019 at 11:43 AM Jessye Coleman Shapiro < jescolem at redhat.com> wrote: >> >> Here is an updated version of the patch: >> http://cr.openjdk.java.net/~aptmac/JMC-5499/webrev.01/ >> >> >> I modified the uitests in JVMInformationPageTest to act as general checks >> for table population instead of asserting exact table entries. String >> comparisons of dates were failing in some environments and not others. > > > The test file looks good, just a couple nits: > - there will need to be a license header for the file > - the second test is missing the "Log" part in the method name to indicate the "LogTable" like written in the previous test > - the string value for "Old Value" could be retrieved from Messages > - now that JMC-5327 is pushed there's a folder for flightrecorder page uitests, this could be placed in there (alongside FileIOPageTest, etc.) > I have added those changed to the patch - thanks > No issues or failures when running these tests: https://travis-ci.org/aptmac/jmc-qa/builds/554307170 > >> >> >> Let me know what you think, >> >> Jessye >> >> >> On Tue, Jul 2, 2019 at 3:56 PM Jessye Coleman Shapiro < jescolem at redhat.com> >> wrote: >> >> > Here is an updated patch. It includes: >> > >> > - A message that reads "No 'Flag Changed' events found". I didn't add >> > an explanation for why no events were found because it is possible >> > that the table could be empty for two reasons simultaneously- some >> > XFlagChanged events could be disabled and others could have simply not >> > occurred. However, I am not sure if this message is informative >> > enough. I have placed the message under the title of the table - let >> > me know if this is a good location for it. > > > I think this is good for now. I do agree with Marcus's statement about not hiding away UI elements that we're not using. My initial inclination was that the table itself could be not displayed, but because this table is a component of sash form then the header title would still be visible (and the sash weights adjusted to reclaim space). However, that's still a band-aid solution to the bigger problem of better handling empty states. There is already an issue in JIRA for this sort of behaviour (JMC-4009), so I'll take a couple ideas and chime in there. > >> > - Two uitests that test if the table is correctly populated for a >> > flight recording that has multiple XFlagChanged events and if the "No >> > 'Flag Changed' events found" message appears for a flight recording >> > where no XFlagChanged events occur. >> > - Removed empty space/lines >> > >> > Let me know what you think, >> > >> > Jessye >> > >> > On Mon, Jun 24, 2019 at 10:58 AM Ken Dobson wrote: >> > > >> > > I agree, a simple string added to the table saying "No X events found" or >> > > "X event has been disabled" would more than suffice. >> > > >> > > Ken >> > > >> > > >> > > On Mon, Jun 24, 2019 at 7:07 AM Marcus Hirt < marcus.hirt at datadoghq.com> >> > > wrote: >> > > >> > > > Agree. Perhaps now would be a good time to discuss? >> > > > >> > > > I am, in general, hesitant to automatically hide UI elements. It has >> > been >> > > > tried in the past (e.g. Microsoft hiding menu elements not used much), >> > with >> > > > little success. That said, we should at the very least have some >> > feedback >> > > > showing people whether the lack of data is due to events being >> > disabled or >> > > > events not having occurred. What do you guys think? >> > > > >> > > > Kind regards, >> > > > Marcus >> > > > >> > > > On Thu, Jun 20, 2019 at 8:35 PM Ken Dobson wrote: >> > > > >> > > >> There's a ticket here about how we should handle empty tables >> > > >> https://bugs.openjdk.java.net/browse/JMC-4009 >> > > >> I think it's an issue that might have a larger scope than just this >> > bug >> > > >> but >> > > >> it's definitely worth addressing. >> > > >> >> > > >> Ken Dobson >> > > >> >> > > >> On Thu, Jun 20, 2019 at 1:30 PM Alex Macdonald < almacdon at redhat.com> >> > > >> wrote: >> > > >> >> > > >> > On Thu, Jun 20, 2019 at 9:05 AM Jessye Coleman Shapiro < >> > > >> > jescolem at redhat.com> >> > > >> > wrote: >> > > >> > >> > > >> > > Hi Alex, >> > > >> > > >> > > >> > > I will make those changes and send an updated patch. >> > > >> > > >> > > >> > >> > > >> > Err, whoops. I was reviewing your JMC-5706 patch at the same time as >> > > >> this >> > > >> > one, and must have applied the other patch when I thought it was >> > this >> > > >> one. >> > > >> > The previous review actually applies to your JMC-5706 patch, so I'll >> > > >> copy >> > > >> > the review on that thread. >> > > >> > >> > > >> > As for this patch: >> > > >> > >> > > >> > My initial reaction was that the new table uses up a good portion >> > of the >> > > >> > page real-estate (which is okay), but I'm wondering if the table >> > should >> > > >> > only be displayed if it has values to display. Perhaps someone else >> > > >> could >> > > >> > share their opinions as well. >> > > >> > >> > > >> > There are empty spaces/lines at the following locations: >> > > >> > - defaultPages.xml @ line 597 >> > > >> > - JVMInformationPage.java @ lines 122, 162, 187, 227, 231, 258, 262, >> > > >> 295, >> > > >> > 296, 303, 305, 342, 346 >> > > >> > >> > > >> > The build & uitests pass [0], however because a new component was >> > added >> > > >> to >> > > >> > the UI I'd like to see a uitest to ensure that everything is >> > working as >> > > >> > intended. >> > > >> > >> > > >> > [0] https://travis-ci.org/aptmac/jmc-qa/builds/548262559 >> > > >> > >> > > >> > >> > > >> > > >> > > >> > > Thank you! >> > > >> > > >> > > >> > > Jessye >> > > >> > > >> > > >> > > On Wed, Jun 19, 2019 at 3:45 PM Alex Macdonald < >> > almacdon at redhat.com> >> > > >> > > wrote: >> > > >> > > >> > > >> > >> Hi Jessye, >> > > >> > >> >> > > >> > >> On Fri, Jun 7, 2019 at 2:48 PM Jessye Coleman Shapiro < >> > > >> > >> jescolem at redhat.com> wrote: >> > > >> > >> >> > > >> > >>> Hi, >> > > >> > >>> >> > > >> > >>> This patch addresses JMC-5499: Add XFlagChanged events to JVM >> > > >> > Information >> > > >> > >>> or subpage [0]. I have added a JVM Flags Log table to the JVM >> > > >> > Internals >> > > >> > >>> Page that displays XFlagChanged events. >> > > >> > >>> >> > > >> > >>> Please see the attached patch and let me know what you think. >> > > >> > >>> >> > > >> > >> >> > > >> > >> The content of this patch look good to me. >> > > >> > >> >> > > >> > >> However, there are test failures: >> > > >> > >> >> > > >> > >> > TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 >> > > >> > >> >> > > >> > >> because the generated JfrRuleBaseline.xml doesn't match the >> > hardcopy >> > > >> one >> > > >> > >> used to verify the test. This will need to be updated. >> > > >> > >> >> > > >> > >> There's also some empty spaces that can be cleaned up. >> > > >> > >> >> > > >> > >> JavaBlockingRule.java >> > > >> > >> - empty space @ lines 134, 138, 151 >> > > >> > >> - trailing empty space @ line 142 >> > > >> > >> >> > > >> > >> >> > > >> > >>> >> > > >> > >>> Thank you! >> > > >> > >>> >> > > >> > >>> Jessye Coleman-Shapiro >> > > >> > >>> >> > > >> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-5499 >> > > >> > >> >> > > >> > >> >> > > >> > >> Cheers, >> > > >> > >> >> > > >> > >> Alex >> > > >> > >> >> > > >> > > >> > > >> > >> > > >> >> > > > >> > From florian.david at gmail.com Wed Jul 10 16:03:03 2019 From: florian.david at gmail.com (Florian David) Date: Wed, 10 Jul 2019 12:03:03 -0400 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: I updated the patch and tests are passing. I also corrected 2 more messages (CompareCpuRule_INFO_LIMIT and CompareCpuRule_WARNING_LIMIT). I have also rebased the patch so that it can be applied to the last revision (659b7d0350d6). Link: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.2/ Le lun. 8 juil. 2019 ? 11:25, Marcus Hirt a ?crit : > Jira ticket opened here: > https://bugs.openjdk.java.net/browse/JMC-6523 > > /M > > On Mon, Jul 8, 2019 at 10:59 AM Jie Kang wrote: > >> On Wed, Jul 3, 2019 at 11:52 AM Florian David >> wrote: >> > >> > >> > >> > Le jeu. 27 juin 2019 ? 23:38, Jie Kang a ?crit : >> >> >> >> Hi Florian, >> >> >> > Hi Jie, >> > >> > Thanks for the review. Please find the new one taking into account your >> feedback here: >> > http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.1/ >> > >> >> >> >> Changes look mostly good. >> >> >> >> # I have some suggestions and comments below: >> >> >> >> * The Messages also contain: >> >> >> >> CompareCpuRule_INFO_LIMIT=Competing CPU usage limit >> >> CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other >> >> processes needed to trigger an info notice >> >> CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit >> >> CompareCpuRule_WARNING_LIMIT_LONG=The amount of CPU used by other >> >> processes needed to trigger a warning >> >> >> >> I think this patch should also alter these descriptions to reflect the >> >> new calculation behind the rule. To be honest I'm not sure how to >> >> describe the new meaning succinctly in words, otherwise I'd provide a >> >> suggestion, sorry; >> >> >> > I have updated these messages: >> > >> > CompareCpuRule_TEXT_INFO_LONG=The application performance can be >> affected when the machine is under heavy load and there are other processes >> that use CPU or other resources on the same computer. To profile >> representatively or get higher throughput, shut down other resource >> intensive processes running on the machine. >> > ... >> > CompareCpuRule_TEXT_MESSAGE=An average CPU load of {2} was caused by >> other processes during {0} starting at {1}. >> > CompareCpuRule_INFO_LIMIT=Competing CPU usage info limit >> > CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other >> processes times the overall CPU usage needed to trigger an info notice >> > CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit >> > >> > I tried to keep these messages simple and not overwhelming the user >> with lot of details. >> > However, if you think it should be even more detailed, I can be more >> precise. >> >> Hey Florian, >> >> These messages are fine with me. Unfortunately some of the tests now fail: >> >> [ERROR] Failures: >> [ERROR] TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 >> >> I am guessing the JfrRuleBaseline.xml needs to have some more updates >> for the new changes. >> >> I think the rest of the patch looks fine! >> >> > >> >> >> >> # The following comments could be addressed in different Jira issues, >> if at all: >> >> >> >> * The SpanToolkit is used twice on the items now, once for the max and >> >> once for the ratio. Could the underlying iterations over the items be >> >> combined? I understand they calculate different spans, one of which is >> >> used in the message while the other is used for the score. Could they >> >> be aligned? >> >> >> >> * It's curious that the SpanToolkit is given the warning limit whereas >> >> the long message is generated if the score is above the info limit. As >> >> well, the warning limit is used to determine if spans get combined >> >> while the end result used for the score process is the longest span, >> >> regardless of it's value's relation to the warning limit. Should it be >> >> the longest span that's above the warning limit, if possible, >> >> otherwise the longest span? I guess it depends on if the initial spans >> >> vary in length or not. I'm not sure how to describe it but something >> >> feels strange here. >> >> >> > I agree, these comments are relevant. However I'm not yet a contributor >> > thus I don't have rights to create Jira tickets :( How can we address >> that ? >> >> I think you can ask Marcus to create a Jira ticket for you. >> >> >> Regards, >> >> >> >> > >> > For the second point, I also believe there is something fishy in this >> code >> > about using the warning limit instead of the info limit is incorrect. >> I'm not >> > mastering spans already but passing warning limit to getMaxSpanLimit >> > should exclude span below this limit, thus only triggering the rule if >> score >> > is above warning limit only and never of it's between info and warning >> limits. >> > Something is wrong in this workflow. >> > >> >> # The following is just a question for the intended design: >> >> >> >> * After an initial read of these changes, I would expect that if I set >> >> a warning limit of say 0.4, then a warning would be triggered if there >> >> is a longest span where the CPU usage of other processes was 40% and >> >> the total CPU usage was 100% I.e. the range is like [1]? Is that >> >> right? >> >> >> >> [1] >> >> x*y> >> x: CPU Usage of Other Processes over the longest span of time >> >> y: CPU Usage of All Processes over longest span of time >> >> >> > Yes that's exactly the computation being done. The core idea is that >> when >> > machine CPU is low, it's meaningless to trigger the rule since there is >> still enough >> > CPU to run other processes. The multiplication by 'y' decreases the >> score >> > in this case. >> > >> > Regards, >> > Florian >> > >> >> >> >> >> >> Regards, >> >> >> >> >> >> On Thu, Jun 27, 2019 at 5:34 AM Florian David >> wrote: >> >> > >> >> > Hi all, >> >> > >> >> > Please review this fix for the CPU load rule. >> >> > >> >> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6512 >> >> > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.0/ >> >> > >> >> > Regards, >> >> > Florian >> > From florian.david at datadoghq.com Thu Jul 11 13:33:10 2019 From: florian.david at datadoghq.com (Florian David) Date: Thu, 11 Jul 2019 09:33:10 -0400 Subject: Review request JMC-5701: GC stall rule never reports OK result Message-ID: Hi ! Please find a review to fix the GC stall rule. JIRA: https://bugs.openjdk.java.net/browse/JMC-5701 Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-5701/webrev.0/ Regards, Florian From hdafgard at gmail.com Thu Jul 11 15:32:12 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Thu, 11 Jul 2019 11:32:12 -0400 Subject: Review request JMC-5701: GC stall rule never reports OK result In-Reply-To: References: Message-ID: This change looks good to me! Cheers, Henrik Dafg?rd On Thu, 11 Jul 2019 at 09:33, Florian David wrote: > Hi ! > > Please find a review to fix the GC stall rule. > > JIRA: https://bugs.openjdk.java.net/browse/JMC-5701 > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-5701/webrev.0/ > > Regards, > Florian > -- // Henrik Dafg?rd From marcus.hirt at datadoghq.com Thu Jul 11 17:21:26 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 11 Jul 2019 13:21:26 -0400 Subject: Review request JMC-5701: GC stall rule never reports OK result In-Reply-To: References: Message-ID: Henrik, Can you sponsor this change? Kind regards, Marcus On Thu, Jul 11, 2019 at 11:32 AM Henrik Dafg?rd wrote: > > This change looks good to me! > > > Cheers, > Henrik Dafg?rd > > On Thu, 11 Jul 2019 at 09:33, Florian David > wrote: > > > Hi ! > > > > Please find a review to fix the GC stall rule. > > > > JIRA: https://bugs.openjdk.java.net/browse/JMC-5701 > > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-5701/webrev.0/ > > > > Regards, > > Florian > > > -- > // Henrik Dafg?rd From jkang at redhat.com Thu Jul 11 18:05:15 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 11 Jul 2019 14:05:15 -0400 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: On Wed, Jul 10, 2019 at 12:03 PM Florian David wrote: > > I updated the patch and tests are passing. I also corrected 2 more messages (CompareCpuRule_INFO_LIMIT and CompareCpuRule_WARNING_LIMIT). > I have also rebased the patch so that it can be applied to the last revision (659b7d0350d6). > > Link: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.2/ Hey Florian, Thanks for the update. It looks good to me. Regards, > > Le lun. 8 juil. 2019 ? 11:25, Marcus Hirt a ?crit : >> >> Jira ticket opened here: >> https://bugs.openjdk.java.net/browse/JMC-6523 >> >> /M >> >> On Mon, Jul 8, 2019 at 10:59 AM Jie Kang wrote: >>> >>> On Wed, Jul 3, 2019 at 11:52 AM Florian David wrote: >>> > >>> > >>> > >>> > Le jeu. 27 juin 2019 ? 23:38, Jie Kang a ?crit : >>> >> >>> >> Hi Florian, >>> >> >>> > Hi Jie, >>> > >>> > Thanks for the review. Please find the new one taking into account your feedback here: >>> > http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.1/ >>> > >>> >> >>> >> Changes look mostly good. >>> >> >>> >> # I have some suggestions and comments below: >>> >> >>> >> * The Messages also contain: >>> >> >>> >> CompareCpuRule_INFO_LIMIT=Competing CPU usage limit >>> >> CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other >>> >> processes needed to trigger an info notice >>> >> CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit >>> >> CompareCpuRule_WARNING_LIMIT_LONG=The amount of CPU used by other >>> >> processes needed to trigger a warning >>> >> >>> >> I think this patch should also alter these descriptions to reflect the >>> >> new calculation behind the rule. To be honest I'm not sure how to >>> >> describe the new meaning succinctly in words, otherwise I'd provide a >>> >> suggestion, sorry; >>> >> >>> > I have updated these messages: >>> > >>> > CompareCpuRule_TEXT_INFO_LONG=The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine. >>> > ... >>> > CompareCpuRule_TEXT_MESSAGE=An average CPU load of {2} was caused by other processes during {0} starting at {1}. >>> > CompareCpuRule_INFO_LIMIT=Competing CPU usage info limit >>> > CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other processes times the overall CPU usage needed to trigger an info notice >>> > CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit >>> > >>> > I tried to keep these messages simple and not overwhelming the user with lot of details. >>> > However, if you think it should be even more detailed, I can be more precise. >>> >>> Hey Florian, >>> >>> These messages are fine with me. Unfortunately some of the tests now fail: >>> >>> [ERROR] Failures: >>> [ERROR] TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 >>> >>> I am guessing the JfrRuleBaseline.xml needs to have some more updates >>> for the new changes. >>> >>> I think the rest of the patch looks fine! >>> >>> > >>> >> >>> >> # The following comments could be addressed in different Jira issues, if at all: >>> >> >>> >> * The SpanToolkit is used twice on the items now, once for the max and >>> >> once for the ratio. Could the underlying iterations over the items be >>> >> combined? I understand they calculate different spans, one of which is >>> >> used in the message while the other is used for the score. Could they >>> >> be aligned? >>> >> >>> >> * It's curious that the SpanToolkit is given the warning limit whereas >>> >> the long message is generated if the score is above the info limit. As >>> >> well, the warning limit is used to determine if spans get combined >>> >> while the end result used for the score process is the longest span, >>> >> regardless of it's value's relation to the warning limit. Should it be >>> >> the longest span that's above the warning limit, if possible, >>> >> otherwise the longest span? I guess it depends on if the initial spans >>> >> vary in length or not. I'm not sure how to describe it but something >>> >> feels strange here. >>> >> >>> > I agree, these comments are relevant. However I'm not yet a contributor >>> > thus I don't have rights to create Jira tickets :( How can we address that ? >>> >>> I think you can ask Marcus to create a Jira ticket for you. >>> >>> >>> Regards, >>> >>> >>> >>> > >>> > For the second point, I also believe there is something fishy in this code >>> > about using the warning limit instead of the info limit is incorrect. I'm not >>> > mastering spans already but passing warning limit to getMaxSpanLimit >>> > should exclude span below this limit, thus only triggering the rule if score >>> > is above warning limit only and never of it's between info and warning limits. >>> > Something is wrong in this workflow. >>> > >>> >> # The following is just a question for the intended design: >>> >> >>> >> * After an initial read of these changes, I would expect that if I set >>> >> a warning limit of say 0.4, then a warning would be triggered if there >>> >> is a longest span where the CPU usage of other processes was 40% and >>> >> the total CPU usage was 100% I.e. the range is like [1]? Is that >>> >> right? >>> >> >>> >> [1] >>> >> x*y>> >> x: CPU Usage of Other Processes over the longest span of time >>> >> y: CPU Usage of All Processes over longest span of time >>> >> >>> > Yes that's exactly the computation being done. The core idea is that when >>> > machine CPU is low, it's meaningless to trigger the rule since there is still enough >>> > CPU to run other processes. The multiplication by 'y' decreases the score >>> > in this case. >>> > >>> > Regards, >>> > Florian >>> > >>> >> >>> >> >>> >> Regards, >>> >> >>> >> >>> >> On Thu, Jun 27, 2019 at 5:34 AM Florian David wrote: >>> >> > >>> >> > Hi all, >>> >> > >>> >> > Please review this fix for the CPU load rule. >>> >> > >>> >> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6512 >>> >> > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.0/ >>> >> > >>> >> > Regards, >>> >> > Florian From jkang at redhat.com Thu Jul 11 18:40:59 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 11 Jul 2019 14:40:59 -0400 Subject: Review request for JMC-JMC-4057: Adding experimental flame graph view. In-Reply-To: References: <08f401d52844$b1857ba0$149072e0$@hirt.se> Message-ID: On Tue, Jul 9, 2019 at 6:31 PM Marcus Hirt wrote: > > Hi Jie, > > Thanks for taking a look! > > Here's an updated version: > http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.1/ Hi Marcus, I have one minor nit for: --- /dev/null 2019-07-09 22:26:24.682716100 +0200 +++ new/application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceTreeUtils.java 2019-07-09 23:56:58.542672600 +0200 [...] + public static String printTree(TraceNode node) { + StringBuilder builder = new StringBuilder(); + builder.append("=== Tree Printout ===%n"); When I tried a reproducer in a static main: StringBuilder b = new StringBuilder(); b.append("Hi%nBob!"); System.out.println(b.toString()); The result is Hi!%nBob! I think it would be more appropriate to use System.lineSeparator() The patch good to me; I think it's okay without further review from me! (Adding jmc-dev list to CC) Regards, > > Kind regards, > Marcus > > On Mon, Jul 8, 2019 at 4:04 PM Jie Kang wrote: > > > > On Fri, Jun 21, 2019 at 11:19 AM Marcus Hirt wrote: > > > > > > Hi all, > > > > > > Please review this change to add an experimental flame graph view. > > > See known issues in the Jira. > > > > > > Also cleaning up some imports, and excluding JOverflow from the > > > development launchers until JMC-6343 is fixed. > > > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-4057 > > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.0/ > > > > Hi Marcus, > > > > I have one comment below: > > > > * > > There are two spotbugs failures: > > VA_FORMAT_STRING_USES_NEWLINE: For TraceTreeUtils.printTree:110, the > > format string can use %n instead of /n for a platform-specific line > > separator. The use of \n can also be altered in > > TraceTreeUtils.printTree:104 to be platform-independent via > > System.lineSeparator(). > > SBSC_USE_STRINGBUFFER_CONCATENATION: For TraceTreeUtils.indent:119, > > spotbugs would prefer a StringBuilder/StringBuffer for building the > > result. > > > > Apart from this, I think this patch as an initial commit of this work > > looks good! It worked for me on Fedora 30. For the record, I was not > > able to view the launcher changes due to the webrev issue. I have > > opened a JIRA issue [1] to track it and also supplied a potential fix > > through the mailing list [2]. > > > > [1] https://bugs.openjdk.java.net/browse/JMC-6524 > > [2] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-July/001226.html > > > > > > Regards, > > > > > > > > Kind regards, > > > Marcus > > > From marcus.hirt at datadoghq.com Thu Jul 11 21:14:45 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 11 Jul 2019 17:14:45 -0400 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: Looks good to me too! I or Henrik will sponsor this one. Kind regards, Marcus On Thu, Jul 11, 2019 at 2:05 PM Jie Kang wrote: > > On Wed, Jul 10, 2019 at 12:03 PM Florian David wrote: > > > > I updated the patch and tests are passing. I also corrected 2 more messages (CompareCpuRule_INFO_LIMIT and CompareCpuRule_WARNING_LIMIT). > > I have also rebased the patch so that it can be applied to the last revision (659b7d0350d6). > > > > Link: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.2/ > > Hey Florian, > > Thanks for the update. It looks good to me. > > > Regards, > > > > > > Le lun. 8 juil. 2019 ? 11:25, Marcus Hirt a ?crit : > >> > >> Jira ticket opened here: > >> https://bugs.openjdk.java.net/browse/JMC-6523 > >> > >> /M > >> > >> On Mon, Jul 8, 2019 at 10:59 AM Jie Kang wrote: > >>> > >>> On Wed, Jul 3, 2019 at 11:52 AM Florian David wrote: > >>> > > >>> > > >>> > > >>> > Le jeu. 27 juin 2019 ? 23:38, Jie Kang a ?crit : > >>> >> > >>> >> Hi Florian, > >>> >> > >>> > Hi Jie, > >>> > > >>> > Thanks for the review. Please find the new one taking into account your feedback here: > >>> > http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.1/ > >>> > > >>> >> > >>> >> Changes look mostly good. > >>> >> > >>> >> # I have some suggestions and comments below: > >>> >> > >>> >> * The Messages also contain: > >>> >> > >>> >> CompareCpuRule_INFO_LIMIT=Competing CPU usage limit > >>> >> CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other > >>> >> processes needed to trigger an info notice > >>> >> CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit > >>> >> CompareCpuRule_WARNING_LIMIT_LONG=The amount of CPU used by other > >>> >> processes needed to trigger a warning > >>> >> > >>> >> I think this patch should also alter these descriptions to reflect the > >>> >> new calculation behind the rule. To be honest I'm not sure how to > >>> >> describe the new meaning succinctly in words, otherwise I'd provide a > >>> >> suggestion, sorry; > >>> >> > >>> > I have updated these messages: > >>> > > >>> > CompareCpuRule_TEXT_INFO_LONG=The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine. > >>> > ... > >>> > CompareCpuRule_TEXT_MESSAGE=An average CPU load of {2} was caused by other processes during {0} starting at {1}. > >>> > CompareCpuRule_INFO_LIMIT=Competing CPU usage info limit > >>> > CompareCpuRule_INFO_LIMIT_LONG=The amount of CPU used by other processes times the overall CPU usage needed to trigger an info notice > >>> > CompareCpuRule_WARNING_LIMIT=Competing CPU usage warning limit > >>> > > >>> > I tried to keep these messages simple and not overwhelming the user with lot of details. > >>> > However, if you think it should be even more detailed, I can be more precise. > >>> > >>> Hey Florian, > >>> > >>> These messages are fine with me. Unfortunately some of the tests now fail: > >>> > >>> [ERROR] Failures: > >>> [ERROR] TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 > >>> > >>> I am guessing the JfrRuleBaseline.xml needs to have some more updates > >>> for the new changes. > >>> > >>> I think the rest of the patch looks fine! > >>> > >>> > > >>> >> > >>> >> # The following comments could be addressed in different Jira issues, if at all: > >>> >> > >>> >> * The SpanToolkit is used twice on the items now, once for the max and > >>> >> once for the ratio. Could the underlying iterations over the items be > >>> >> combined? I understand they calculate different spans, one of which is > >>> >> used in the message while the other is used for the score. Could they > >>> >> be aligned? > >>> >> > >>> >> * It's curious that the SpanToolkit is given the warning limit whereas > >>> >> the long message is generated if the score is above the info limit. As > >>> >> well, the warning limit is used to determine if spans get combined > >>> >> while the end result used for the score process is the longest span, > >>> >> regardless of it's value's relation to the warning limit. Should it be > >>> >> the longest span that's above the warning limit, if possible, > >>> >> otherwise the longest span? I guess it depends on if the initial spans > >>> >> vary in length or not. I'm not sure how to describe it but something > >>> >> feels strange here. > >>> >> > >>> > I agree, these comments are relevant. However I'm not yet a contributor > >>> > thus I don't have rights to create Jira tickets :( How can we address that ? > >>> > >>> I think you can ask Marcus to create a Jira ticket for you. > >>> > >>> > >>> Regards, > >>> > >>> > >>> > >>> > > >>> > For the second point, I also believe there is something fishy in this code > >>> > about using the warning limit instead of the info limit is incorrect. I'm not > >>> > mastering spans already but passing warning limit to getMaxSpanLimit > >>> > should exclude span below this limit, thus only triggering the rule if score > >>> > is above warning limit only and never of it's between info and warning limits. > >>> > Something is wrong in this workflow. > >>> > > >>> >> # The following is just a question for the intended design: > >>> >> > >>> >> * After an initial read of these changes, I would expect that if I set > >>> >> a warning limit of say 0.4, then a warning would be triggered if there > >>> >> is a longest span where the CPU usage of other processes was 40% and > >>> >> the total CPU usage was 100% I.e. the range is like [1]? Is that > >>> >> right? > >>> >> > >>> >> [1] > >>> >> x*y >>> >> x: CPU Usage of Other Processes over the longest span of time > >>> >> y: CPU Usage of All Processes over longest span of time > >>> >> > >>> > Yes that's exactly the computation being done. The core idea is that when > >>> > machine CPU is low, it's meaningless to trigger the rule since there is still enough > >>> > CPU to run other processes. The multiplication by 'y' decreases the score > >>> > in this case. > >>> > > >>> > Regards, > >>> > Florian > >>> > > >>> >> > >>> >> > >>> >> Regards, > >>> >> > >>> >> > >>> >> On Thu, Jun 27, 2019 at 5:34 AM Florian David wrote: > >>> >> > > >>> >> > Hi all, > >>> >> > > >>> >> > Please review this fix for the CPU load rule. > >>> >> > > >>> >> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6512 > >>> >> > Webrev: http://cr.openjdk.java.net/~hirt/fdavid/JMC-6512/webrev.0/ > >>> >> > > >>> >> > Regards, > >>> >> > Florian From marcus at hirt.se Thu Jul 11 21:24:09 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Thu, 11 Jul 2019 21:24:09 +0000 Subject: hg: jmc/jmc: JMC-6512: Competing CPU load rule should take overall load into account Message-ID: <201907112124.x6BLO9uH004775@aojmv0008.oracle.com> Changeset: 1a6383c0d0d0 Author: hirt Date: 2019-07-11 17:23 -0400 URL: https://hg.openjdk.java.net/jmc/jmc/rev/1a6383c0d0d0 JMC-6512: Competing CPU load rule should take overall load into account Reviewed-by: jkang, hirt Contributed-by: Florian David ! 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/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties ! 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/messages/internal/Messages.java ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml From marcus.hirt at datadoghq.com Thu Jul 11 21:55:56 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 11 Jul 2019 17:55:56 -0400 Subject: Review request for JMC-JMC-4057: Adding experimental flame graph view. In-Reply-To: References: <08f401d52844$b1857ba0$149072e0$@hirt.se> Message-ID: Excellent! Henrik, can you also review? Kind regards, Marcus On Thu, Jul 11, 2019 at 2:41 PM Jie Kang wrote: > > On Tue, Jul 9, 2019 at 6:31 PM Marcus Hirt wrote: > > > > Hi Jie, > > > > Thanks for taking a look! > > > > Here's an updated version: > > http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.1/ > > Hi Marcus, > > I have one minor nit for: > > --- /dev/null 2019-07-09 22:26:24.682716100 +0200 > +++ new/application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceTreeUtils.java > 2019-07-09 23:56:58.542672600 +0200 > [...] > + public static String printTree(TraceNode node) { > + StringBuilder builder = new StringBuilder(); > + builder.append("=== Tree Printout ===%n"); > > When I tried a reproducer in a static main: > > StringBuilder b = new StringBuilder(); > b.append("Hi%nBob!"); > System.out.println(b.toString()); > > The result is > > Hi!%nBob! > > I think it would be more appropriate to use System.lineSeparator() > > The patch good to me; I think it's okay without further review from me! > > (Adding jmc-dev list to CC) > > > Regards, > > > > > Kind regards, > > Marcus > > > > On Mon, Jul 8, 2019 at 4:04 PM Jie Kang wrote: > > > > > > On Fri, Jun 21, 2019 at 11:19 AM Marcus Hirt wrote: > > > > > > > > Hi all, > > > > > > > > Please review this change to add an experimental flame graph view. > > > > See known issues in the Jira. > > > > > > > > Also cleaning up some imports, and excluding JOverflow from the > > > > development launchers until JMC-6343 is fixed. > > > > > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-4057 > > > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.0/ > > > > > > Hi Marcus, > > > > > > I have one comment below: > > > > > > * > > > There are two spotbugs failures: > > > VA_FORMAT_STRING_USES_NEWLINE: For TraceTreeUtils.printTree:110, the > > > format string can use %n instead of /n for a platform-specific line > > > separator. The use of \n can also be altered in > > > TraceTreeUtils.printTree:104 to be platform-independent via > > > System.lineSeparator(). > > > SBSC_USE_STRINGBUFFER_CONCATENATION: For TraceTreeUtils.indent:119, > > > spotbugs would prefer a StringBuilder/StringBuffer for building the > > > result. > > > > > > Apart from this, I think this patch as an initial commit of this work > > > looks good! It worked for me on Fedora 30. For the record, I was not > > > able to view the launcher changes due to the webrev issue. I have > > > opened a JIRA issue [1] to track it and also supplied a potential fix > > > through the mailing list [2]. > > > > > > [1] https://bugs.openjdk.java.net/browse/JMC-6524 > > > [2] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-July/001226.html > > > > > > > > > Regards, > > > > > > > > > > > Kind regards, > > > > Marcus > > > > From hdafgard at gmail.com Thu Jul 11 21:56:22 2019 From: hdafgard at gmail.com (hdafgard at gmail.com) Date: Thu, 11 Jul 2019 21:56:22 +0000 Subject: hg: jmc/jmc: JMC-5701: GC stall rule never reports OK result Message-ID: <201907112156.x6BLuMTh021450@aojmv0008.oracle.com> Changeset: febe45d094b7 Author: hdafgard Date: 2019-07-11 17:52 -0400 URL: https://hg.openjdk.java.net/jmc/jmc/rev/febe45d094b7 JMC-5701: GC stall rule never reports OK result Summary: Require GC events to be both unavailable and disabled to return a N/A result Reviewed-by: hdafgard Contributed-by: Florian David ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GcStallRule.java ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml From hdafgard at gmail.com Thu Jul 11 22:47:06 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Thu, 11 Jul 2019 18:47:06 -0400 Subject: Review request for JMC-JMC-4057: Adding experimental flame graph view. In-Reply-To: References: <08f401d52844$b1857ba0$149072e0$@hirt.se> Message-ID: I think this looks good, although in FlameGraphView.toJson returns an empty string for a null value, this wouldn't be valid JSON. Cheers, Henrik Dafg?rd On Thu, 11 Jul 2019 at 17:56, Marcus Hirt wrote: > Excellent! Henrik, can you also review? > > Kind regards, > Marcus > > On Thu, Jul 11, 2019 at 2:41 PM Jie Kang wrote: > > > > On Tue, Jul 9, 2019 at 6:31 PM Marcus Hirt > wrote: > > > > > > Hi Jie, > > > > > > Thanks for taking a look! > > > > > > Here's an updated version: > > > http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.1/ > > > > Hi Marcus, > > > > I have one minor nit for: > > > > --- /dev/null 2019-07-09 22:26:24.682716100 +0200 > > +++ > new/application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceTreeUtils.java > > 2019-07-09 23:56:58.542672600 +0200 > > [...] > > + public static String printTree(TraceNode node) { > > + StringBuilder builder = new StringBuilder(); > > + builder.append("=== Tree Printout ===%n"); > > > > When I tried a reproducer in a static main: > > > > StringBuilder b = new StringBuilder(); > > b.append("Hi%nBob!"); > > System.out.println(b.toString()); > > > > The result is > > > > Hi!%nBob! > > > > I think it would be more appropriate to use System.lineSeparator() > > > > The patch good to me; I think it's okay without further review from me! > > > > (Adding jmc-dev list to CC) > > > > > > Regards, > > > > > > > > Kind regards, > > > Marcus > > > > > > On Mon, Jul 8, 2019 at 4:04 PM Jie Kang wrote: > > > > > > > > On Fri, Jun 21, 2019 at 11:19 AM Marcus Hirt wrote: > > > > > > > > > > Hi all, > > > > > > > > > > Please review this change to add an experimental flame graph view. > > > > > See known issues in the Jira. > > > > > > > > > > Also cleaning up some imports, and excluding JOverflow from the > > > > > development launchers until JMC-6343 is fixed. > > > > > > > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-4057 > > > > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.0/ > > > > > > > > Hi Marcus, > > > > > > > > I have one comment below: > > > > > > > > * > > > > There are two spotbugs failures: > > > > VA_FORMAT_STRING_USES_NEWLINE: For TraceTreeUtils.printTree:110, the > > > > format string can use %n instead of /n for a platform-specific line > > > > separator. The use of \n can also be altered in > > > > TraceTreeUtils.printTree:104 to be platform-independent via > > > > System.lineSeparator(). > > > > SBSC_USE_STRINGBUFFER_CONCATENATION: For TraceTreeUtils.indent:119, > > > > spotbugs would prefer a StringBuilder/StringBuffer for building the > > > > result. > > > > > > > > Apart from this, I think this patch as an initial commit of this work > > > > looks good! It worked for me on Fedora 30. For the record, I was not > > > > able to view the launcher changes due to the webrev issue. I have > > > > opened a JIRA issue [1] to track it and also supplied a potential fix > > > > through the mailing list [2]. > > > > > > > > [1] https://bugs.openjdk.java.net/browse/JMC-6524 > > > > [2] > http://mail.openjdk.java.net/pipermail/jmc-dev/2019-July/001226.html > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Kind regards, > > > > > Marcus > > > > > > From marcus.hirt at datadoghq.com Thu Jul 11 22:50:43 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 11 Jul 2019 18:50:43 -0400 Subject: Review request for JMC-JMC-4057: Adding experimental flame graph view. In-Reply-To: References: <08f401d52844$b1857ba0$149072e0$@hirt.se> Message-ID: Thanks Henrik! /M On Thu, Jul 11, 2019 at 6:47 PM Henrik Dafg?rd wrote: > > I think this looks good, although in FlameGraphView.toJson returns an empty string for a null value, this wouldn't be valid JSON. > > > Cheers, > Henrik Dafg?rd > > > On Thu, 11 Jul 2019 at 17:56, Marcus Hirt wrote: >> >> Excellent! Henrik, can you also review? >> >> Kind regards, >> Marcus >> >> On Thu, Jul 11, 2019 at 2:41 PM Jie Kang wrote: >> > >> > On Tue, Jul 9, 2019 at 6:31 PM Marcus Hirt wrote: >> > > >> > > Hi Jie, >> > > >> > > Thanks for taking a look! >> > > >> > > Here's an updated version: >> > > http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.1/ >> > >> > Hi Marcus, >> > >> > I have one minor nit for: >> > >> > --- /dev/null 2019-07-09 22:26:24.682716100 +0200 >> > +++ new/application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceTreeUtils.java >> > 2019-07-09 23:56:58.542672600 +0200 >> > [...] >> > + public static String printTree(TraceNode node) { >> > + StringBuilder builder = new StringBuilder(); >> > + builder.append("=== Tree Printout ===%n"); >> > >> > When I tried a reproducer in a static main: >> > >> > StringBuilder b = new StringBuilder(); >> > b.append("Hi%nBob!"); >> > System.out.println(b.toString()); >> > >> > The result is >> > >> > Hi!%nBob! >> > >> > I think it would be more appropriate to use System.lineSeparator() >> > >> > The patch good to me; I think it's okay without further review from me! >> > >> > (Adding jmc-dev list to CC) >> > >> > >> > Regards, >> > >> > > >> > > Kind regards, >> > > Marcus >> > > >> > > On Mon, Jul 8, 2019 at 4:04 PM Jie Kang wrote: >> > > > >> > > > On Fri, Jun 21, 2019 at 11:19 AM Marcus Hirt wrote: >> > > > > >> > > > > Hi all, >> > > > > >> > > > > Please review this change to add an experimental flame graph view. >> > > > > See known issues in the Jira. >> > > > > >> > > > > Also cleaning up some imports, and excluding JOverflow from the >> > > > > development launchers until JMC-6343 is fixed. >> > > > > >> > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-4057 >> > > > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-4057/webrev.0/ >> > > > >> > > > Hi Marcus, >> > > > >> > > > I have one comment below: >> > > > >> > > > * >> > > > There are two spotbugs failures: >> > > > VA_FORMAT_STRING_USES_NEWLINE: For TraceTreeUtils.printTree:110, the >> > > > format string can use %n instead of /n for a platform-specific line >> > > > separator. The use of \n can also be altered in >> > > > TraceTreeUtils.printTree:104 to be platform-independent via >> > > > System.lineSeparator(). >> > > > SBSC_USE_STRINGBUFFER_CONCATENATION: For TraceTreeUtils.indent:119, >> > > > spotbugs would prefer a StringBuilder/StringBuffer for building the >> > > > result. >> > > > >> > > > Apart from this, I think this patch as an initial commit of this work >> > > > looks good! It worked for me on Fedora 30. For the record, I was not >> > > > able to view the launcher changes due to the webrev issue. I have >> > > > opened a JIRA issue [1] to track it and also supplied a potential fix >> > > > through the mailing list [2]. >> > > > >> > > > [1] https://bugs.openjdk.java.net/browse/JMC-6524 >> > > > [2] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-July/001226.html >> > > > >> > > > >> > > > Regards, >> > > > >> > > > > >> > > > > Kind regards, >> > > > > Marcus >> > > > > From carusso at redhat.com Fri Jul 12 11:42:55 2019 From: carusso at redhat.com (Carmine Vincenzo Russo) Date: Fri, 12 Jul 2019 13:42:55 +0200 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: <5D23ABD8.3020401@oracle.com> References: <5D14E918.80302@oracle.com> <5D23ABD8.3020401@oracle.com> Message-ID: Hi Erik, I want to point out a couple of things before going forward. In the issue description it says to use $ jmc -open recording.jfr instead of $ jmc -open /Demo/recording.jfr That's why I assumed the subdirectories where needed. While I get from your words that we are working in the directory /Demo and from the command line it needs the full path even if the file is in the current directory. Please correct me if I am wrong. Another thing is that I tried with the sequence of command you suggested as use case, when I run $ jcmd 4711 JFR.dump filename=dump.jfr It saves the recording in the application directory and not in my current working directory, therefore everything should be executed in the application directory for your use case, or in alternative we should use a full path, but since it is in a different directory the issue shouldn't apply to it. To summarize, if the issue is about opening the recording in the current directory, it already works for me without any patch (tested on Fedora). If is about opening the recording from somewhere else, than can you give me more details about the issue? It's not really clear. Thanks, Carmine On Mon, Jul 8, 2019 at 10:47 PM Erik Gahlin wrote: > Hi Carmine, > > See comments inline. > > > Hi Erik, > > Thank you for your response. > > On Thu, Jun 27, 2019 at 6:05 PM Erik Gahlin > wrote: > >> Hi Carmine , >> >> Searching the home directory could take a very long time. It could also >> open the wrong file if several files have the same name. I don't think >> it is the correct approach. >> > > I know, starting from the user home is a little bit extreme and can take a > while, therefore instead I'm starting from the current directory > > It's the same problem. > > On my computer, it could take an hour if I am in the wrong directory or a > network share. I don't know any other applications that searches for a file > in subdirectories. > > in the updated patch and searching the subdirectories from there. > Since JMC doesn't have a specific folder to save the recordings it all > depends on the users. > > This is primarily meant for command-line users. For example, > > $ java -XX:StartFlightRecording -jar my.jar > ... > $ jcmd 4711 JFR.dump filename=dump.jfr > $ jmc -open recording.jfr > > The cumbersome part here is to switch to a GUI and do various operations > with the mouse. > > As for files with the same name, there is the same problem, JMC gives the > possibility to choose the name for every recordings, therefore to have two > files with the same name the user should do it on purpose. > > >> >> Have you tried Paths.get(".", filename) ? >> >> It will look in the current working directory. To see if the full path >> is correct do >> >> path.normalize().toAbsolutePath() >> >> if this doesn't work, it could be because of some magic happening in jmc >> launcher, in which case the current directory have to be extracted in >> the launcher code. >> > > Updated the patch with you suggestions regarding Paths, everything seems > to work fine. > > Good, have you tried on the most common OSes (Mac, Linux and Windows)? > > Thanks > Erik > > At the moment a full path, a path with ~/ and a filename both in the > current directory or in a subdirectories of the current directory open a > recording. > Also I made some tests for the function findFile, there are 3 tests right > now: > - EmptyPathTest: tests what happens with an empty string as filename. > - ValidFileNameTest: tests with a temp file whether findFile can find the > correct file. > - InvalidFileNameTest: tests what happens when the given filename doesn't > exists. > > Here the updated patch: > http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.01/ > > Thanks, > Carmine > > >> Erik >> > Hi, >> > >> > On Fri, Jun 21, 2019 at 10:39 AM Jie Kang wrote: >> > >> >> On Fri, Jun 21, 2019 at 8:31 AM Carmine Vincenzo Russo >> >> wrote: >> >>> Hello, >> >>> >> >>> The patch addresses the issue JMC-6173[0]. >> >>> I have added a check to see if the path is full or not. If it falls in >> >> the >> >>> second case, starting from the user home it recursively search for the >> >>> given file name in all the not hidden folder. >> >>> There was also a problem with relative path like ~/record/test.jfr, >> now >> >>> fixed. >> >>> I tested the patch with full path, relative path, filename only and >> null >> >>> value. >> >>> >> >>> I'm planning to add few tests, at least for a valid filename, an >> invalid >> >>> filename and a null value. >> >>> >> >>> See the attached patch bellow and let me know what you think. >> >> I don't see an attachment unfortunately; was it missed or maybe >> stripped? >> >> >> > Carmine sent me a note saying he attached the patch to the e-mail but it >> > doesn't appear to show up here. Instead, please find his patch at the >> > following webrev: >> > >> > http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.00/ >> > >> > I believe he's looking into unit tests at the moment, but wanted >> feedback >> > on his implementation before going forward. >> > >> > >> >> Regards, >> >> >> >>> Thank you! >> >>> Carmine >> >>> >> >>> >> >>> [0] https://bugs.openjdk.java.net/browse/JMC-6173 >> >>> >> >>> -- >> >>> Carmine Vincenzo Russo >> > Cheers, >> > >> > Alex >> >> > > -- > Carmine Vincenzo Russo > > > -- Carmine Vincenzo Russo From neugens at redhat.com Fri Jul 12 11:56:01 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 12 Jul 2019 13:56:01 +0200 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: References: <5D14E918.80302@oracle.com> <5D23ABD8.3020401@oracle.com> Message-ID: On Fri, Jul 12, 2019 at 1:43 PM Carmine Vincenzo Russo wrote: > > Hi Erik, > > I want to point out a couple of things before going forward. > > In the issue description it says to use $ jmc -open recording.jfr instead > of $ jmc -open /Demo/recording.jfr > That's why I assumed the subdirectories where needed. While I get from your > words that we are working in the directory /Demo and from the command line > it needs the full path even if the file is in the current directory. Please > correct me if I am wrong. I jump on that only now, and I admit I don't have the full context, but this is what I understood being the problem. Basically we have those two use cases are: 1. A full path is always given 2. We open a file in the *current working directory* 1 is the default, it seems we need to implement 2, however I just tried on RHEL 8 too and I can't reproduce it. Perhaps this is an issue just on OSX? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Fri Jul 12 12:54:34 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 12 Jul 2019 14:54:34 +0200 Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency In-Reply-To: References: Message-ID: On 25/06/2019 18:28, Jie Kang wrote: > On Wed, Jun 5, 2019 at 9:52 AM Alex Macdonald wrote: >> >> Hi Jie, >> >> On Wed, May 29, 2019 at 9:36 AM Jie Kang wrote: >>> >>> Hi, >>> >>> The attached patch adds a case for contentType "hertz", annotation >>> "jdk.jfr.Frequency" used in JFR events like CPUTimeStampCounter, to >>> use the Hertz unit introduced in JMC-5768. >>> >>> The following is a before and after image for the event browser for >>> CPUTimeStampCounter >>> https://imgur.com/a/cSVlmOM >>> >>> How does it look? >> >> >> This looks good to me. >> >> Just a note from playing around with the patch, CPUTimeStampCounter was updated in changeset 2cf5bec8d8ba [0] to use hertz instead of frequency per second. As a result, older recordings will still show their numerical value as per their jfr file, but newer recordings will now correctly use the hz unit. > > Thanks. Any chance this could get another review? It's a tiny patch. Hi Jie, Sorry, I missed that you needed a second review. The patch looks fine to me to go. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From almacdon at redhat.com Fri Jul 12 14:18:37 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Fri, 12 Jul 2019 10:18:37 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: Hi Jessye, On Tue, Jul 9, 2019 at 1:03 PM Jessye Coleman Shapiro wrote: > Hi, > > Here is the webrev for an updated patch: > http://cr.openjdk.java.net/~aptmac/JMC-5499/webrev.02/ > Great, thank you for accommodating the changes. I have two minor nits, being: - JVMInformationPage - - line 48: the new line that separates the eclipse & jmc imports was removed - - line 298: there should be a space before the SWT.NONE These two changes aren't large enough to warrant a re-review, so this looks good to me! > > > On Thu, Jul 4, 2019 at 1:43 PM Alex Macdonald wrote: > > > > On Thu, Jul 4, 2019 at 11:43 AM Jessye Coleman Shapiro < > jescolem at redhat.com> wrote: > >> > >> Here is an updated version of the patch: > >> http://cr.openjdk.java.net/~aptmac/JMC-5499/webrev.01/ > >> > >> > >> I modified the uitests in JVMInformationPageTest to act as general > checks > >> for table population instead of asserting exact table entries. String > >> comparisons of dates were failing in some environments and not others. > > > > > > The test file looks good, just a couple nits: > > - there will need to be a license header for the file > > - the second test is missing the "Log" part in the method name to > indicate the "LogTable" like written in the previous test > > - the string value for "Old Value" could be retrieved from Messages > > - now that JMC-5327 is pushed there's a folder for flightrecorder page > uitests, this could be placed in there (alongside FileIOPageTest, etc.) > > > > I have added those changed to the patch - thanks > > > No issues or failures when running these tests: > https://travis-ci.org/aptmac/jmc-qa/builds/554307170 > > > >> > >> > >> Let me know what you think, > >> > >> Jessye > >> > >> > >> On Tue, Jul 2, 2019 at 3:56 PM Jessye Coleman Shapiro < > jescolem at redhat.com> > >> wrote: > >> > >> > Here is an updated patch. It includes: > >> > > >> > - A message that reads "No 'Flag Changed' events found". I didn't add > >> > an explanation for why no events were found because it is possible > >> > that the table could be empty for two reasons simultaneously- some > >> > XFlagChanged events could be disabled and others could have simply not > >> > occurred. However, I am not sure if this message is informative > >> > enough. I have placed the message under the title of the table - let > >> > me know if this is a good location for it. > > > > > > I think this is good for now. I do agree with Marcus's statement about > not hiding away UI elements that we're not using. My initial inclination > was that the table itself could be not displayed, but because this table is > a component of sash form then the header title would still be visible (and > the sash weights adjusted to reclaim space). However, that's still a > band-aid solution to the bigger problem of better handling empty states. > There is already an issue in JIRA for this sort of behaviour (JMC-4009), so > I'll take a couple ideas and chime in there. > > > >> > - Two uitests that test if the table is correctly populated for a > >> > flight recording that has multiple XFlagChanged events and if the "No > >> > 'Flag Changed' events found" message appears for a flight recording > >> > where no XFlagChanged events occur. > >> > - Removed empty space/lines > >> > > >> > Let me know what you think, > >> > > >> > Jessye > >> > > >> > On Mon, Jun 24, 2019 at 10:58 AM Ken Dobson > wrote: > >> > > > >> > > I agree, a simple string added to the table saying "No X events > found" or > >> > > "X event has been disabled" would more than suffice. > >> > > > >> > > Ken > >> > > > >> > > > >> > > On Mon, Jun 24, 2019 at 7:07 AM Marcus Hirt < > marcus.hirt at datadoghq.com> > >> > > wrote: > >> > > > >> > > > Agree. Perhaps now would be a good time to discuss? > >> > > > > >> > > > I am, in general, hesitant to automatically hide UI elements. It > has > >> > been > >> > > > tried in the past (e.g. Microsoft hiding menu elements not used > much), > >> > with > >> > > > little success. That said, we should at the very least have some > >> > feedback > >> > > > showing people whether the lack of data is due to events being > >> > disabled or > >> > > > events not having occurred. What do you guys think? > >> > > > > >> > > > Kind regards, > >> > > > Marcus > >> > > > > >> > > > On Thu, Jun 20, 2019 at 8:35 PM Ken Dobson > wrote: > >> > > > > >> > > >> There's a ticket here about how we should handle empty tables > >> > > >> https://bugs.openjdk.java.net/browse/JMC-4009 > >> > > >> I think it's an issue that might have a larger scope than just > this > >> > bug > >> > > >> but > >> > > >> it's definitely worth addressing. > >> > > >> > >> > > >> Ken Dobson > >> > > >> > >> > > >> On Thu, Jun 20, 2019 at 1:30 PM Alex Macdonald < > almacdon at redhat.com> > >> > > >> wrote: > >> > > >> > >> > > >> > On Thu, Jun 20, 2019 at 9:05 AM Jessye Coleman Shapiro < > >> > > >> > jescolem at redhat.com> > >> > > >> > wrote: > >> > > >> > > >> > > >> > > Hi Alex, > >> > > >> > > > >> > > >> > > I will make those changes and send an updated patch. > >> > > >> > > > >> > > >> > > >> > > >> > Err, whoops. I was reviewing your JMC-5706 patch at the same > time as > >> > > >> this > >> > > >> > one, and must have applied the other patch when I thought it > was > >> > this > >> > > >> one. > >> > > >> > The previous review actually applies to your JMC-5706 patch, > so I'll > >> > > >> copy > >> > > >> > the review on that thread. > >> > > >> > > >> > > >> > As for this patch: > >> > > >> > > >> > > >> > My initial reaction was that the new table uses up a good > portion > >> > of the > >> > > >> > page real-estate (which is okay), but I'm wondering if the > table > >> > should > >> > > >> > only be displayed if it has values to display. Perhaps someone > else > >> > > >> could > >> > > >> > share their opinions as well. > >> > > >> > > >> > > >> > There are empty spaces/lines at the following locations: > >> > > >> > - defaultPages.xml @ line 597 > >> > > >> > - JVMInformationPage.java @ lines 122, 162, 187, 227, 231, > 258, 262, > >> > > >> 295, > >> > > >> > 296, 303, 305, 342, 346 > >> > > >> > > >> > > >> > The build & uitests pass [0], however because a new component > was > >> > added > >> > > >> to > >> > > >> > the UI I'd like to see a uitest to ensure that everything is > >> > working as > >> > > >> > intended. > >> > > >> > > >> > > >> > [0] https://travis-ci.org/aptmac/jmc-qa/builds/548262559 > >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > Thank you! > >> > > >> > > > >> > > >> > > Jessye > >> > > >> > > > >> > > >> > > On Wed, Jun 19, 2019 at 3:45 PM Alex Macdonald < > >> > almacdon at redhat.com> > >> > > >> > > wrote: > >> > > >> > > > >> > > >> > >> Hi Jessye, > >> > > >> > >> > >> > > >> > >> On Fri, Jun 7, 2019 at 2:48 PM Jessye Coleman Shapiro < > >> > > >> > >> jescolem at redhat.com> wrote: > >> > > >> > >> > >> > > >> > >>> Hi, > >> > > >> > >>> > >> > > >> > >>> This patch addresses JMC-5499: Add XFlagChanged events to > JVM > >> > > >> > Information > >> > > >> > >>> or subpage [0]. I have added a JVM Flags Log table to the > JVM > >> > > >> > Internals > >> > > >> > >>> Page that displays XFlagChanged events. > >> > > >> > >>> > >> > > >> > >>> Please see the attached patch and let me know what you > think. > >> > > >> > >>> > >> > > >> > >> > >> > > >> > >> The content of this patch look good to me. > >> > > >> > >> > >> > > >> > >> However, there are test failures: > >> > > >> > >> > >> > > >> > >> > > TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159 > >> > > >> > >> > >> > > >> > >> because the generated JfrRuleBaseline.xml doesn't match the > >> > hardcopy > >> > > >> one > >> > > >> > >> used to verify the test. This will need to be updated. > >> > > >> > >> > >> > > >> > >> There's also some empty spaces that can be cleaned up. > >> > > >> > >> > >> > > >> > >> JavaBlockingRule.java > >> > > >> > >> - empty space @ lines 134, 138, 151 > >> > > >> > >> - trailing empty space @ line 142 > >> > > >> > >> > >> > > >> > >> > >> > > >> > >>> > >> > > >> > >>> Thank you! > >> > > >> > >>> > >> > > >> > >>> Jessye Coleman-Shapiro > >> > > >> > >>> > >> > > >> > >>> [0] https://bugs.openjdk.java.net/browse/JMC-5499 > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> Cheers, > >> > > >> > >> > >> > > >> > >> Alex > >> > > >> > >> > >> > > >> > > > >> > > >> > > >> > > >> > >> > > > > >> > > From kxu at redhat.com Fri Jul 12 20:50:21 2019 From: kxu at redhat.com (Arvin Kangcheng Xu) Date: Fri, 12 Jul 2019 16:50:21 -0400 Subject: [PATCH] JMC-6082: JOverflow does not handle large heap dumps well Message-ID: Hello all, This patch addresses JMC-6082 (JOverflow does not handle large heap dumps well) [0]. The problem: the dump file is closed prematurely after only a part of the file content is pre-fetched into the cache. In case of cache misses, subsequent reads from an already-closed file will result in a stream closed exception. Please see the attached patch, and let me know your thoughts. Thank you very much! Regards, Kangcheng [0] https://bugs.openjdk.java.net/browse/JMC-6082 -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6082.patch Type: text/x-patch Size: 1136 bytes Desc: not available URL: From marcus.hirt at datadoghq.com Fri Jul 12 22:51:42 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Fri, 12 Jul 2019 18:51:42 -0400 Subject: [PATCH] JMC-6082: JOverflow does not handle large heap dumps well In-Reply-To: References: Message-ID: LGTM! Kind regards, Marcus On Fri, Jul 12, 2019 at 4:50 PM Arvin Kangcheng Xu wrote: > > Hello all, > > This patch addresses JMC-6082 (JOverflow does not handle large > heap dumps well) [0]. > > The problem: the dump file is closed prematurely after only a part of > the file content is pre-fetched into the cache. In case of cache > misses, subsequent reads from an already-closed file will result in a > stream closed exception. > > Please see the attached patch, and let me know your thoughts. Thank > you very much! > > Regards, > Kangcheng > > [0] https://bugs.openjdk.java.net/browse/JMC-6082 From marcus at hirt.se Sat Jul 13 13:33:19 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Sat, 13 Jul 2019 13:33:19 +0000 Subject: hg: jmc/jmc: JMC-4057: Flame graph view delivered as experimental plug-in Message-ID: <201907131333.x6DDXJ4F027449@aojmv0008.oracle.com> Changeset: 1488ed0683c8 Author: hirt Date: 2019-07-13 15:33 +0200 URL: https://hg.openjdk.java.net/jmc/jmc/rev/1488ed0683c8 JMC-4057: Flame graph view delivered as experimental plug-in Reviewed-by: Jie Kang , hdafgard Contributed-by: hirt, mwengner, Nenad Bogojevic + application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/.project + application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/build.properties + application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/feature.properties + application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/feature.xml + application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/pom.xml + application/org.openjdk.jmc.flightrecorder.ext.flameview/.classpath + application/org.openjdk.jmc.flightrecorder.ext.flameview/.project + application/org.openjdk.jmc.flightrecorder.ext.flameview/.settings/org.eclipse.jdt.core.prefs + application/org.openjdk.jmc.flightrecorder.ext.flameview/.settings/org.eclipse.m2e.core.prefs + application/org.openjdk.jmc.flightrecorder.ext.flameview/META-INF/MANIFEST.MF + application/org.openjdk.jmc.flightrecorder.ext.flameview/build.properties + application/org.openjdk.jmc.flightrecorder.ext.flameview/icons/flame.png + application/org.openjdk.jmc.flightrecorder.ext.flameview/icons/flame at 2x.png + application/org.openjdk.jmc.flightrecorder.ext.flameview/plugin.properties + application/org.openjdk.jmc.flightrecorder.ext.flameview/plugin.xml + application/org.openjdk.jmc.flightrecorder.ext.flameview/pom.xml + application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceNode.java + application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceTreeUtils.java + application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/views/FlameGraphView.java + application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/views/page.html ! application/org.openjdk.jmc.updatesite.ide/category.xml ! application/org.openjdk.jmc.updatesite.ide/feature.xml ! application/org.openjdk.jmc.updatesite.rcp/category.xml ! application/org.openjdk.jmc.updatesite.rcp/feature.xml ! application/pom.xml ! application/uitests/org.openjdk.jmc.console.uitest/src/test/java/org/openjdk/jmc/console/uitest/ConsolePreferencesTest.java ! configuration/ide/eclipse/launchers/JMC Eclipse plug-ins (JDK 8).launch ! configuration/ide/eclipse/launchers/JMC Eclipse plug-ins.launch ! configuration/ide/eclipse/launchers/JMC RCP plug-ins (JDK 8).launch ! configuration/ide/eclipse/launchers/JMC RCP plug-ins.launch ! core/org.openjdk.jmc.flightrecorder.rules.jdk/.settings/org.eclipse.jdt.core.prefs ! core/org.openjdk.jmc.flightrecorder.rules/.settings/org.eclipse.jdt.core.prefs From neugens at redhat.com Tue Jul 16 15:26:37 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 16 Jul 2019 17:26:37 +0200 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: On 12/07/2019 16:18, Alex Macdonald wrote: > These two changes aren't large enough to warrant a re-review, so this looks > good to me! I'm also fine with this once you implement the small changes that Alex suggested please consider that reviewed. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From almacdon at redhat.com Tue Jul 16 15:44:18 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Tue, 16 Jul 2019 11:44:18 -0400 Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency In-Reply-To: References: Message-ID: On Fri, Jul 12, 2019 at 8:54 AM Mario Torre wrote: > On 25/06/2019 18:28, Jie Kang wrote: > > On Wed, Jun 5, 2019 at 9:52 AM Alex Macdonald > wrote: > >> > >> Hi Jie, > >> > >> On Wed, May 29, 2019 at 9:36 AM Jie Kang wrote: > >>> > >>> Hi, > >>> > >>> The attached patch adds a case for contentType "hertz", annotation > >>> "jdk.jfr.Frequency" used in JFR events like CPUTimeStampCounter, to > >>> use the Hertz unit introduced in JMC-5768. > >>> > >>> The following is a before and after image for the event browser for > >>> CPUTimeStampCounter > >>> https://imgur.com/a/cSVlmOM > >>> > >>> How does it look? > >> > >> > >> This looks good to me. > >> > >> Just a note from playing around with the patch, CPUTimeStampCounter was > updated in changeset 2cf5bec8d8ba [0] to use hertz instead of frequency per > second. As a result, older recordings will still show their numerical value > as per their jfr file, but newer recordings will now correctly use the hz > unit. > > > > Thanks. Any chance this could get another review? It's a tiny patch. > > Hi Jie, > > Sorry, I missed that you needed a second review. The patch looks fine to > me to go. > Great! I can sponsor this patch and will push shortly. > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > Cheers, Alex From almacdon at redhat.com Tue Jul 16 15:46:19 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Tue, 16 Jul 2019 15:46:19 +0000 Subject: hg: jmc/jmc: JMC-6492: Add unit support for jdk.jfr.Frequency Message-ID: <201907161546.x6GFkJuT008610@aojmv0008.oracle.com> Changeset: db29f018093b Author: aptmac Date: 2019-07-16 11:42 -0400 URL: https://hg.openjdk.java.net/jmc/jmc/rev/db29f018093b JMC-6492: Add unit support for jdk.jfr.Frequency Reviewed-by: aptmac, neugens Contributed-by: Jie Kang ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/ChunkMetadata.java From almacdon at redhat.com Tue Jul 16 19:06:00 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Tue, 16 Jul 2019 19:06:00 +0000 Subject: hg: jmc/jmc: JMC-5499: Add XFlagChanged events to JVM Internals Page Message-ID: <201907161906.x6GJ60Ka009986@aojmv0008.oracle.com> Changeset: e1f66e88dba9 Author: aptmac Date: 2019-07-16 14:05 -0400 URL: https://hg.openjdk.java.net/jmc/jmc/rev/e1f66e88dba9 JMC-5499: Add XFlagChanged events to JVM Internals Page Summary: Created JVM Flags Log table on JVM Internals Page to display XFlagChanged events. Reviewed-by: aptmac, neugens Contributed-by: Jessye Coleman-Shapiro ! application/org.openjdk.jmc.flightrecorder.ui/defaultPages.xml ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/JVMInformationPage.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties + application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/pages/JVMInformationPageTest.java + application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/resources/jfr/flags_changed.jfr ! 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/messages/internal/Messages.java From almacdon at redhat.com Wed Jul 17 17:25:44 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Wed, 17 Jul 2019 17:25:44 +0000 Subject: hg: jmc/jmc: JMC-6082: JOverflow does not handle large heap dumps well Message-ID: <201907171725.x6HHPimc017480@aojmv0008.oracle.com> Changeset: 76af4214ed3a Author: aptmac Date: 2019-07-17 12:53 -0400 URL: https://hg.openjdk.java.net/jmc/jmc/rev/76af4214ed3a JMC-6082: JOverflow does not handle large heap dumps well Summary: Corrected CachedReadBufferFactory from closing dump files prematurely Reviewed-by: hirt Contributed-by: Kangcheng Xu ! application/org.openjdk.jmc.joverflow/src/main/java/org/openjdk/jmc/joverflow/heap/parser/ReadBuffer.java From neugens at redhat.com Wed Jul 17 18:21:06 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 17 Jul 2019 20:21:06 +0200 Subject: Result: New jmc Committer: Ken Dobson Message-ID: Voting for Ken Dobson [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Cheers, Mario [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-June/001169.html -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hdafgard at gmail.com Mon Jul 22 11:17:47 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Mon, 22 Jul 2019 13:17:47 +0200 Subject: Review Request for JMC-6537: Autoboxing rule is slow Message-ID: Hi all, The attached patch is a proposal to fix the somewhat inefficient Autoboxing rule. This should provide a ~4x performance increase without changing the output of the rule. Cheers, Henrik Dafg?rd From aazores at redhat.com Mon Jul 22 12:13:35 2019 From: aazores at redhat.com (Andrew Azores) Date: Mon, 22 Jul 2019 08:13:35 -0400 Subject: Review Request for JMC-6537: Autoboxing rule is slow In-Reply-To: References: Message-ID: Hi Henrik, On Mon, 2019-07-22 at 13:17 +0200, Henrik Dafg?rd wrote: > Hi all, > > The attached patch is a proposal to fix the somewhat inefficient > Autoboxing > rule. This should provide a ~4x performance increase without changing > the > output of the rule. > > > Cheers, > Henrik Dafg?rd I think your attachment got missed or scrubbed. -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From hdafgard at gmail.com Mon Jul 22 13:26:16 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Mon, 22 Jul 2019 15:26:16 +0200 Subject: Review Request for JMC-6537: Autoboxing rule is slow In-Reply-To: References: Message-ID: Hi all again, Sorry about that, I put up a webrev instead. Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6537/webrev.0/index.html JIRA: https://bugs.openjdk.java.net/browse/JMC-6537 Cheers, Henrik Dafg?rd On Mon, 22 Jul 2019 at 14:19, Andrew Azores wrote: > Hi Henrik, > > On Mon, 2019-07-22 at 13:17 +0200, Henrik Dafg?rd wrote: > > Hi all, > > > > The attached patch is a proposal to fix the somewhat inefficient > > Autoboxing > > rule. This should provide a ~4x performance increase without changing > > the > > output of the rule. > > > > > > Cheers, > > Henrik Dafg?rd > > I think your attachment got missed or scrubbed. > > -- > Andrew Azores > Software Engineer, OpenJDK Team > Red Hat > > From marcus.hirt at datadoghq.com Mon Jul 22 13:37:17 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 22 Jul 2019 15:37:17 +0200 Subject: Review Request for JMC-6537: Autoboxing rule is slow In-Reply-To: References: Message-ID: Hi Henrik, Since it is always the valueOf method you're checking for, wouldn't it be nicer (and also avoiding some allocations), to simply first check the method name and then the class name (and not fuse the class and method name together in the Predicate)? Also, don't forget to update/add the copyright year. Kind regards, Marcus On Mon, Jul 22, 2019 at 3:26 PM Henrik Dafg?rd wrote: > > Hi all again, > > Sorry about that, I put up a webrev instead. > Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6537/webrev.0/index.html > JIRA: https://bugs.openjdk.java.net/browse/JMC-6537 > > > Cheers, > Henrik Dafg?rd > > > On Mon, 22 Jul 2019 at 14:19, Andrew Azores wrote: > > > Hi Henrik, > > > > On Mon, 2019-07-22 at 13:17 +0200, Henrik Dafg?rd wrote: > > > Hi all, > > > > > > The attached patch is a proposal to fix the somewhat inefficient > > > Autoboxing > > > rule. This should provide a ~4x performance increase without changing > > > the > > > output of the rule. > > > > > > > > > Cheers, > > > Henrik Dafg?rd > > > > I think your attachment got missed or scrubbed. > > > > -- > > Andrew Azores > > Software Engineer, OpenJDK Team > > Red Hat > > > > From hdafgard at gmail.com Mon Jul 22 14:58:58 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Mon, 22 Jul 2019 16:58:58 +0200 Subject: Review Request for JMC-6537: Autoboxing rule is slow In-Reply-To: References: Message-ID: Yeah, that would be a good change. Cheers, Henrik Dafg?rd On Mon, 22 Jul 2019 at 15:37, Marcus Hirt wrote: > Hi Henrik, > > Since it is always the valueOf method you're checking for, wouldn't it > be nicer (and also avoiding some allocations), to simply first check > the method name and then the class name (and not fuse the class and > method name together in the Predicate)? Also, don't forget to > update/add the copyright year. > > Kind regards, > Marcus > > On Mon, Jul 22, 2019 at 3:26 PM Henrik Dafg?rd wrote: > > > > Hi all again, > > > > Sorry about that, I put up a webrev instead. > > Webrev: > http://cr.openjdk.java.net/~hdafgard/JMC-6537/webrev.0/index.html > > JIRA: https://bugs.openjdk.java.net/browse/JMC-6537 > > > > > > Cheers, > > Henrik Dafg?rd > > > > > > On Mon, 22 Jul 2019 at 14:19, Andrew Azores wrote: > > > > > Hi Henrik, > > > > > > On Mon, 2019-07-22 at 13:17 +0200, Henrik Dafg?rd wrote: > > > > Hi all, > > > > > > > > The attached patch is a proposal to fix the somewhat inefficient > > > > Autoboxing > > > > rule. This should provide a ~4x performance increase without changing > > > > the > > > > output of the rule. > > > > > > > > > > > > Cheers, > > > > Henrik Dafg?rd > > > > > > I think your attachment got missed or scrubbed. > > > > > > -- > > > Andrew Azores > > > Software Engineer, OpenJDK Team > > > Red Hat > > > > > > > From almacdon at redhat.com Mon Jul 22 16:14:49 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Mon, 22 Jul 2019 12:14:49 -0400 Subject: RFC: JMC-6524: Rename Launcher files and exclude spaces In-Reply-To: References: Message-ID: Hi Jie, On Mon, Jul 8, 2019 at 4:08 PM Jie Kang wrote: > Hi, > > Please review the attached patch targeting JMC-6524 [1]. I tried to > create a webrev but of course, the webrev system did not enjoy the > files with spaces in them. > > It renames the launcher files, replacing ' ' (spaces) with '-' and > removed usages of brackets '(' and ')'. If there are any stronger > opinions on how the files should be renamed, please do let me know! I > would be glad to accommodate. > > I have tried using these configurations with Eclipse 2019-03 on Fedora > 30 (X11). Testing on other system setups would be appreciated! > The configurations worked for me on both my Linux & Windows machines (on Eclipse 2018-09 & 2019-03). There were updates to the JMC plug-in launchers as part of the flame graph commit [0], so this patch no longer applies cleanly and will require a rebase for those affected files. > > > Regards, > > [1] https://bugs.openjdk.java.net/browse/JMC-6524 Cheers, Alex [0] http://hg.openjdk.java.net/jmc/jmc/rev/1488ed0683c8 From jkang at redhat.com Mon Jul 22 16:48:36 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 22 Jul 2019 12:48:36 -0400 Subject: RFC: JMC-6524: Rename Launcher files and exclude spaces In-Reply-To: References: Message-ID: On Mon, Jul 22, 2019 at 12:15 PM Alex Macdonald wrote: > > Hi Jie, > > On Mon, Jul 8, 2019 at 4:08 PM Jie Kang wrote: >> >> Hi, >> >> Please review the attached patch targeting JMC-6524 [1]. I tried to >> create a webrev but of course, the webrev system did not enjoy the >> files with spaces in them. >> >> It renames the launcher files, replacing ' ' (spaces) with '-' and >> removed usages of brackets '(' and ')'. If there are any stronger >> opinions on how the files should be renamed, please do let me know! I >> would be glad to accommodate. >> >> I have tried using these configurations with Eclipse 2019-03 on Fedora >> 30 (X11). Testing on other system setups would be appreciated! > > > The configurations worked for me on both my Linux & Windows machines (on Eclipse 2018-09 & 2019-03). > > There were updates to the JMC plug-in launchers as part of the flame graph commit [0], so this patch no longer applies cleanly and will require a rebase for those affected files. Hi Alex, Thanks for the review. I've attached an updated patch. If a second reviewer could take a look, I'd appreciate it. Regards, > >> >> >> >> Regards, >> >> [1] https://bugs.openjdk.java.net/browse/JMC-6524 > > > Cheers, > > Alex > > [0] http://hg.openjdk.java.net/jmc/jmc/rev/1488ed0683c8 -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6524-2.patch Type: text/x-patch Size: 8629 bytes Desc: not available URL: From marcus.hirt at datadoghq.com Mon Jul 22 16:52:45 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 22 Jul 2019 18:52:45 +0200 Subject: RFC: JMC-6524: Rename Launcher files and exclude spaces In-Reply-To: References: Message-ID: Looks good to me! Kind regards, Marcus On Mon, Jul 22, 2019 at 6:49 PM Jie Kang wrote: > > On Mon, Jul 22, 2019 at 12:15 PM Alex Macdonald wrote: > > > > Hi Jie, > > > > On Mon, Jul 8, 2019 at 4:08 PM Jie Kang wrote: > >> > >> Hi, > >> > >> Please review the attached patch targeting JMC-6524 [1]. I tried to > >> create a webrev but of course, the webrev system did not enjoy the > >> files with spaces in them. > >> > >> It renames the launcher files, replacing ' ' (spaces) with '-' and > >> removed usages of brackets '(' and ')'. If there are any stronger > >> opinions on how the files should be renamed, please do let me know! I > >> would be glad to accommodate. > >> > >> I have tried using these configurations with Eclipse 2019-03 on Fedora > >> 30 (X11). Testing on other system setups would be appreciated! > > > > > > The configurations worked for me on both my Linux & Windows machines (on Eclipse 2018-09 & 2019-03). > > > > There were updates to the JMC plug-in launchers as part of the flame graph commit [0], so this patch no longer applies cleanly and will require a rebase for those affected files. > > Hi Alex, > > Thanks for the review. I've attached an updated patch. If a second > reviewer could take a look, I'd appreciate it. > > > Regards, > > > > >> > >> > >> > >> Regards, > >> > >> [1] https://bugs.openjdk.java.net/browse/JMC-6524 > > > > > > Cheers, > > > > Alex > > > > [0] http://hg.openjdk.java.net/jmc/jmc/rev/1488ed0683c8 From almacdon at redhat.com Mon Jul 22 18:51:30 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Mon, 22 Jul 2019 14:51:30 -0400 Subject: RFC: JMC-6524: Rename Launcher files and exclude spaces In-Reply-To: References: Message-ID: On Mon, Jul 22, 2019 at 12:48 PM Jie Kang wrote: > On Mon, Jul 22, 2019 at 12:15 PM Alex Macdonald > wrote: > > > > Hi Jie, > > > > On Mon, Jul 8, 2019 at 4:08 PM Jie Kang wrote: > >> > >> Hi, > >> > >> Please review the attached patch targeting JMC-6524 [1]. I tried to > >> create a webrev but of course, the webrev system did not enjoy the > >> files with spaces in them. > >> > >> It renames the launcher files, replacing ' ' (spaces) with '-' and > >> removed usages of brackets '(' and ')'. If there are any stronger > >> opinions on how the files should be renamed, please do let me know! I > >> would be glad to accommodate. > >> > >> I have tried using these configurations with Eclipse 2019-03 on Fedora > >> 30 (X11). Testing on other system setups would be appreciated! > > > > > > The configurations worked for me on both my Linux & Windows machines (on > Eclipse 2018-09 & 2019-03). > > > > There were updates to the JMC plug-in launchers as part of the flame > graph commit [0], so this patch no longer applies cleanly and will require > a rebase for those affected files. > > Hi Alex, > > Thanks for the review. I've attached an updated patch. If a second > reviewer could take a look, I'd appreciate it. > Great, I can sponsor this patch for you. > > > Regards, > > > > >> > >> > >> > >> Regards, > >> > >> [1] https://bugs.openjdk.java.net/browse/JMC-6524 > > > > > > Cheers, > > > > Alex > > > > [0] http://hg.openjdk.java.net/jmc/jmc/rev/1488ed0683c8 > From almacdon at redhat.com Mon Jul 22 18:53:18 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Mon, 22 Jul 2019 18:53:18 +0000 Subject: hg: jmc/jmc: JMC-6524: Rename Launcher files and exclude spaces Message-ID: <201907221853.x6MIrIQu022660@aojmv0008.oracle.com> Changeset: 3e4f0437a856 Author: aptmac Date: 2019-07-22 14:41 -0400 URL: https://hg.openjdk.java.net/jmc/jmc/rev/3e4f0437a856 JMC-6524: Rename Launcher files and exclude spaces Reviewed-by: hirt, aptmac Contributed-by: Jie Kang - configuration/ide/eclipse/launchers/JMC Eclipse (JDK 8).launch - configuration/ide/eclipse/launchers/JMC Eclipse plug-ins (JDK 8).launch - configuration/ide/eclipse/launchers/JMC Eclipse plug-ins.launch - configuration/ide/eclipse/launchers/JMC Eclipse.launch - configuration/ide/eclipse/launchers/JMC RCP (JDK 8).launch - configuration/ide/eclipse/launchers/JMC RCP plug-ins (JDK 8).launch - configuration/ide/eclipse/launchers/JMC RCP plug-ins.launch - configuration/ide/eclipse/launchers/JMC RCP.launch + configuration/ide/eclipse/launchers/JMC-Eclipse-JDK-8.launch + configuration/ide/eclipse/launchers/JMC-Eclipse-plug-ins-JDK-8.launch + configuration/ide/eclipse/launchers/JMC-Eclipse-plug-ins.launch + configuration/ide/eclipse/launchers/JMC-Eclipse.launch + configuration/ide/eclipse/launchers/JMC-RCP-JDK-8.launch + configuration/ide/eclipse/launchers/JMC-RCP-plug-ins-JDK-8.launch + configuration/ide/eclipse/launchers/JMC-RCP-plug-ins.launch + configuration/ide/eclipse/launchers/JMC-RCP.launch - configuration/ide/eclipse/launchers/Remote RCP Debugging.launch + configuration/ide/eclipse/launchers/Remote-RCP-Debugging.launch From hdafgard at gmail.com Mon Jul 22 18:58:25 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Mon, 22 Jul 2019 20:58:25 +0200 Subject: Review Request for JMC-6537: Autoboxing rule is slow In-Reply-To: References: Message-ID: Updated webrev here: http://cr.openjdk.java.net/~hdafgard/JMC-6537/webrev.2/index.html On Mon, 22 Jul 2019 at 16:58, Henrik Dafg?rd wrote: > Yeah, that would be a good change. > > > Cheers, > Henrik Dafg?rd > > > On Mon, 22 Jul 2019 at 15:37, Marcus Hirt > wrote: > >> Hi Henrik, >> >> Since it is always the valueOf method you're checking for, wouldn't it >> be nicer (and also avoiding some allocations), to simply first check >> the method name and then the class name (and not fuse the class and >> method name together in the Predicate)? Also, don't forget to >> update/add the copyright year. >> >> Kind regards, >> Marcus >> >> On Mon, Jul 22, 2019 at 3:26 PM Henrik Dafg?rd >> wrote: >> > >> > Hi all again, >> > >> > Sorry about that, I put up a webrev instead. >> > Webrev: >> http://cr.openjdk.java.net/~hdafgard/JMC-6537/webrev.0/index.html >> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6537 >> > >> > >> > Cheers, >> > Henrik Dafg?rd >> > >> > >> > On Mon, 22 Jul 2019 at 14:19, Andrew Azores wrote: >> > >> > > Hi Henrik, >> > > >> > > On Mon, 2019-07-22 at 13:17 +0200, Henrik Dafg?rd wrote: >> > > > Hi all, >> > > > >> > > > The attached patch is a proposal to fix the somewhat inefficient >> > > > Autoboxing >> > > > rule. This should provide a ~4x performance increase without >> changing >> > > > the >> > > > output of the rule. >> > > > >> > > > >> > > > Cheers, >> > > > Henrik Dafg?rd >> > > >> > > I think your attachment got missed or scrubbed. >> > > >> > > -- >> > > Andrew Azores >> > > Software Engineer, OpenJDK Team >> > > Red Hat >> > > >> > > >> > From marcus.hirt at datadoghq.com Mon Jul 22 20:09:47 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 22 Jul 2019 22:09:47 +0200 Subject: Review Request for JMC-6537: Autoboxing rule is slow In-Reply-To: References: Message-ID: Looks good! Kind regards, Marcus On Mon, Jul 22, 2019 at 8:58 PM Henrik Dafg?rd wrote: > > Updated webrev here: http://cr.openjdk.java.net/~hdafgard/JMC-6537/webrev.2/index.html > > > On Mon, 22 Jul 2019 at 16:58, Henrik Dafg?rd wrote: >> >> Yeah, that would be a good change. >> >> >> Cheers, >> Henrik Dafg?rd >> >> >> On Mon, 22 Jul 2019 at 15:37, Marcus Hirt wrote: >>> >>> Hi Henrik, >>> >>> Since it is always the valueOf method you're checking for, wouldn't it >>> be nicer (and also avoiding some allocations), to simply first check >>> the method name and then the class name (and not fuse the class and >>> method name together in the Predicate)? Also, don't forget to >>> update/add the copyright year. >>> >>> Kind regards, >>> Marcus >>> >>> On Mon, Jul 22, 2019 at 3:26 PM Henrik Dafg?rd wrote: >>> > >>> > Hi all again, >>> > >>> > Sorry about that, I put up a webrev instead. >>> > Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6537/webrev.0/index.html >>> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6537 >>> > >>> > >>> > Cheers, >>> > Henrik Dafg?rd >>> > >>> > >>> > On Mon, 22 Jul 2019 at 14:19, Andrew Azores wrote: >>> > >>> > > Hi Henrik, >>> > > >>> > > On Mon, 2019-07-22 at 13:17 +0200, Henrik Dafg?rd wrote: >>> > > > Hi all, >>> > > > >>> > > > The attached patch is a proposal to fix the somewhat inefficient >>> > > > Autoboxing >>> > > > rule. This should provide a ~4x performance increase without changing >>> > > > the >>> > > > output of the rule. >>> > > > >>> > > > >>> > > > Cheers, >>> > > > Henrik Dafg?rd >>> > > >>> > > I think your attachment got missed or scrubbed. >>> > > >>> > > -- >>> > > Andrew Azores >>> > > Software Engineer, OpenJDK Team >>> > > Red Hat >>> > > >>> > > From carusso at redhat.com Tue Jul 23 09:21:53 2019 From: carusso at redhat.com (Carmine Vincenzo Russo) Date: Tue, 23 Jul 2019 11:21:53 +0200 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: References: <5D14E918.80302@oracle.com> <5D23ABD8.3020401@oracle.com> Message-ID: Hi Mario, Thanks for your reply. I want to apologize but I misunderstood the issue, therefore I can not work on it because I only have a Fedora machine available. Sorry for the inconvenience, Thanks, Carmine On Fri, Jul 12, 2019 at 1:56 PM Mario Torre wrote: > On Fri, Jul 12, 2019 at 1:43 PM Carmine Vincenzo Russo > wrote: > > > > Hi Erik, > > > > I want to point out a couple of things before going forward. > > > > In the issue description it says to use $ jmc -open recording.jfr instead > > of $ jmc -open /Demo/recording.jfr > > That's why I assumed the subdirectories where needed. While I get from > your > > words that we are working in the directory /Demo and from the command > line > > it needs the full path even if the file is in the current directory. > Please > > correct me if I am wrong. > > I jump on that only now, and I admit I don't have the full context, > but this is what I understood being the problem. > > Basically we have those two use cases are: > > 1. A full path is always given > 2. We open a file in the *current working directory* > > 1 is the default, it seems we need to implement 2, however I just > tried on RHEL 8 too and I can't reproduce it. Perhaps this is an issue > just on OSX? > > Cheers, > Mario > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > -- Carmine Vincenzo Russo From erik.gahlin at oracle.com Tue Jul 23 09:53:03 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 23 Jul 2019 11:53:03 +0200 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: References: <5D14E918.80302@oracle.com> <5D23ABD8.3020401@oracle.com> Message-ID: Hi Carmine, > On 12 Jul 2019, at 13:42, Carmine Vincenzo Russo wrote: > > Hi Erik, > > I want to point out a couple of things before going forward. > > In the issue description it says to use $ jmc -open recording.jfr instead of $ jmc -open /Demo/recording.jfr > That's why I assumed the subdirectories where needed. While I get from your words that we are working in the directory /Demo and from the command line it needs the full path even if the file is in the current directory. Please correct me if I am wrong. Correct. > > Another thing is that I tried with the sequence of command you suggested as use case, when I run > $ jcmd 4711 JFR.dump filename=dump.jfr > It saves the recording in the application directory and not in my current working directory, It will save in a directory relative to where the java process was started from, unless you give a full path. (It?s hard to do anything about jcmd, because JVM has no knowledge from where jcmd was launched.) > therefore everything should be executed in the application directory for your use case, > or in alternative we should use a full path, but since it is in a different directory the issue shouldn't apply to it. > > To summarize, > if the issue is about opening the recording in the current directory, it already works for me without any patch (tested on Fedora). I could not get it to work on Mac OS X, I needed to use the full path. Erik > If is about opening the recording from somewhere else, than can you give me more details about the issue? It's not really clear. > > Thanks, > > Carmine > > > > On Mon, Jul 8, 2019 at 10:47 PM Erik Gahlin > wrote: > Hi Carmine, > > See comments inline. > >> Hi Erik, >> >> Thank you for your response. >> >> On Thu, Jun 27, 2019 at 6:05 PM Erik Gahlin > wrote: >> Hi Carmine , >> >> Searching the home directory could take a very long time. It could also >> open the wrong file if several files have the same name. I don't think >> it is the correct approach. >> >> I know, starting from the user home is a little bit extreme and can take a while, therefore instead I'm starting from the current directory > It's the same problem. > > On my computer, it could take an hour if I am in the wrong directory or a network share. I don't know any other applications that searches for a file in subdirectories. > >> in the updated patch and searching the subdirectories from there. >> Since JMC doesn't have a specific folder to save the recordings it all depends on the users. > This is primarily meant for command-line users. For example, > > $ java -XX:StartFlightRecording -jar my.jar > ... > $ jcmd 4711 JFR.dump filename=dump.jfr > $ jmc -open recording.jfr > > The cumbersome part here is to switch to a GUI and do various operations with the mouse. > >> As for files with the same name, there is the same problem, JMC gives the possibility to choose the name for every recordings, therefore to have two files with the same name the user should do it on purpose. >> >> >> Have you tried Paths.get(".", filename) ? >> >> It will look in the current working directory. To see if the full path >> is correct do >> >> path.normalize().toAbsolutePath() >> >> if this doesn't work, it could be because of some magic happening in jmc >> launcher, in which case the current directory have to be extracted in >> the launcher code. >> >> Updated the patch with you suggestions regarding Paths, everything seems to work fine. > Good, have you tried on the most common OSes (Mac, Linux and Windows)? > > Thanks > Erik > >> At the moment a full path, a path with ~/ and a filename both in the current directory or in a subdirectories of the current directory open a recording. >> Also I made some tests for the function findFile, there are 3 tests right now: >> - EmptyPathTest: tests what happens with an empty string as filename. >> - ValidFileNameTest: tests with a temp file whether findFile can find the correct file. >> - InvalidFileNameTest: tests what happens when the given filename doesn't exists. >> >> Here the updated patch: http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.01/ >> >> Thanks, >> Carmine >> >> >> Erik >> > Hi, >> > >> > On Fri, Jun 21, 2019 at 10:39 AM Jie Kang > wrote: >> > >> >> On Fri, Jun 21, 2019 at 8:31 AM Carmine Vincenzo Russo >> >> > wrote: >> >>> Hello, >> >>> >> >>> The patch addresses the issue JMC-6173[0]. >> >>> I have added a check to see if the path is full or not. If it falls in >> >> the >> >>> second case, starting from the user home it recursively search for the >> >>> given file name in all the not hidden folder. >> >>> There was also a problem with relative path like ~/record/test.jfr, now >> >>> fixed. >> >>> I tested the patch with full path, relative path, filename only and null >> >>> value. >> >>> >> >>> I'm planning to add few tests, at least for a valid filename, an invalid >> >>> filename and a null value. >> >>> >> >>> See the attached patch bellow and let me know what you think. >> >> I don't see an attachment unfortunately; was it missed or maybe stripped? >> >> >> > Carmine sent me a note saying he attached the patch to the e-mail but it >> > doesn't appear to show up here. Instead, please find his patch at the >> > following webrev: >> > >> > http://cr.openjdk.java.net/~aptmac/JMC-6173/webrev.00/ >> > >> > I believe he's looking into unit tests at the moment, but wanted feedback >> > on his implementation before going forward. >> > >> > >> >> Regards, >> >> >> >>> Thank you! >> >>> Carmine >> >>> >> >>> >> >>> [0] https://bugs.openjdk.java.net/browse/JMC-6173 >> >>> >> >>> -- >> >>> Carmine Vincenzo Russo >> > Cheers, >> > >> > Alex >> >> >> >> -- >> Carmine Vincenzo Russo > > > > -- > Carmine Vincenzo Russo From hdafgard at gmail.com Tue Jul 23 11:51:51 2019 From: hdafgard at gmail.com (hdafgard at gmail.com) Date: Tue, 23 Jul 2019 11:51:51 +0000 Subject: hg: jmc/jmc: JMC-6537: Autoboxing rule is slow Message-ID: <201907231151.x6NBppQB026514@aojmv0008.oracle.com> Changeset: 527d408d2a4e Author: hdafgard Date: 2019-07-22 15:14 +0200 URL: https://hg.openjdk.java.net/jmc/jmc/rev/527d408d2a4e JMC-6537: Autoboxing rule is slow Summary: Rewrote autoboxing rule to use StacktraceModel instead of Aggregators with String-based IItemFilters to improve performance Reviewed-by: mhirt ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AutoBoxingRule.java From kdobson at redhat.com Tue Jul 23 14:29:26 2019 From: kdobson at redhat.com (Ken Dobson) Date: Tue, 23 Jul 2019 10:29:26 -0400 Subject: JMC-5640: Used Heap After GC Chart Message-ID: Hi all, Here is a patch that adds a Used Heap Post GC chart to the Garbage Collections page. The implementation is a bit hacky but the only way I could find to add a variation of an attribute already being displayed on a page was to create a duplicate attribute in JdkAttributes.java as well as compare names for uniqueness as identifiers are no longer unique if we intend to look at different subsets of the same attribute. If anyone has any ideas as to how to enact this change in a way that allows us to maintain consistency with the way the other pages operate as well as a way to avoid multiple copies of attributes feel free to share them. Bug Id: https://bugs.openjdk.java.net/browse/JMC-5640 Webrev: http://cr.openjdk.java.net/~kdobson/JMC-5640/webrev/ Thanks, Ken From hdafgard at gmail.com Thu Jul 25 17:36:45 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Thu, 25 Jul 2019 19:36:45 +0200 Subject: Review Request for JMC-6467 Message-ID: Hi all, Please review this request for generalizing the G1 Heap Layout page. The pages.xml file that contains the new default color values could use one or two suggestions for Shenandoah events, if anyone has particular suggestions for default color values there. JIRA: https://bugs.openjdk.java.net/browse/JMC-6467 Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.0/ Cheers, Henrik Dafg?rd From sasiddiq at redhat.com Thu Jul 25 21:42:48 2019 From: sasiddiq at redhat.com (Salman Siddiqui) Date: Thu, 25 Jul 2019 21:42:48 +0000 Subject: Review Request for JMC-5923: Add allocation pressure column to stacktrace view Message-ID: Hi all, Here is patch that adds a column to the stacktrace view to display normalized allocation pressure. The allocation pressure is a ratio of the size of the allocations of a particular class to the size of total allocations from that stacktrace frame. Also, as per suggestion from Marcus, I have normalized the count that is displayed in the stacktrace view (this is similar to what is already being displayed in the tool tip for the count). JIRA issue: https://bugs.openjdk.java.net/browse/JMC-5923 Related GitHub issue: https://github.com/JDKMissionControl/jmc/issues/6 Patch is below. Thanks, Salman diff --git a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java index 7b576f3..cd8234a 100644 --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java @@ -435,6 +435,7 @@ public class Messages extends NLS { public static String SELECT_RANGE_WIZARD_TEXT; public static String SELECT_RANGE_WIZARD_TITLE; public static String SELECT_RANGE_WIZARD_TO_MUCH_SELECTED_WARNING; + public static String STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME; public static String STACKTRACE_VIEW_COUNT_COLUMN_NAME; public static String STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY; public static String STACKTRACE_VIEW_FRAME_GROUP_CHOOSE; diff --git a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java index 2b51e80..9d96016 100644 --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java @@ -92,10 +92,16 @@ import org.eclipse.ui.part.ViewPart; import org.openjdk.jmc.common.IDisplayable; import org.openjdk.jmc.common.IMCFrame; import org.openjdk.jmc.common.IState; +import org.openjdk.jmc.common.collection.IteratorToolkit; import org.openjdk.jmc.common.collection.SimpleArray; +import org.openjdk.jmc.common.item.IItem; import org.openjdk.jmc.common.item.IItemCollection; +import org.openjdk.jmc.common.item.IItemFilter; +import org.openjdk.jmc.common.item.ItemFilters; import org.openjdk.jmc.common.unit.UnitLookup; import org.openjdk.jmc.common.util.StateToolkit; +import org.openjdk.jmc.flightrecorder.jdk.JdkAggregators; +import org.openjdk.jmc.flightrecorder.jdk.JdkFilters; import org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator; import org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator.FrameCategorization; import org.openjdk.jmc.flightrecorder.stacktrace.StacktraceFormatToolkit; @@ -181,7 +187,7 @@ public class StacktraceView extends ViewPart implements ISelectionListener { private static final Color COUNT_COLOR = SWTColorToolkit.getColor(new RGB(100, 200, 100)); private static final String SIBLINGS_IMG_KEY = "siblingsColor"; //$NON-NLS-1$ private static final Color SIBLINGS_COUNT_COLOR = SWTColorToolkit.getColor(new RGB(170, 250, 170)); - private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150}; + private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150, 150}; private static final String THREAD_ROOT_KEY = "threadRootAtTop"; //$NON-NLS-1$ private static final String FRAME_OPTIMIZATION_KEY = "distinguishFramesByOptimization"; //$NON-NLS-1$ private static final String FRAME_CATEGORIZATION_KEY = "distinguishFramesCategorization"; //$NON-NLS-1$ @@ -491,7 +497,7 @@ public class StacktraceView extends ViewPart implements ISelectionListener { new StacktraceViewToolTipSupport(viewer); MCContextMenuManager mm = MCContextMenuManager.create(viewer.getControl()); CopySelectionAction copyAction = new CopySelectionAction(viewer, - FormatToolkit.selectionFormatter(stackTraceLabelProvider, countLabelProvider)); + FormatToolkit.selectionFormatter(stackTraceLabelProvider, countLabelProvider, allocPressureLabelProvider)); InFocusHandlerActivator.install(viewer.getControl(), copyAction); mm.appendToGroup(MCContextMenuManager.GROUP_EDIT, copyAction); mm.appendToGroup(MCContextMenuManager.GROUP_EDIT, CopySettings.getInstance().createContributionItem()); @@ -515,6 +521,8 @@ public class StacktraceView extends ViewPart implements ISelectionListener { .setLabelProvider(stackTraceLabelProvider); buildColumn(viewer, Messages.STACKTRACE_VIEW_COUNT_COLUMN_NAME, SWT.RIGHT, columnWidths[1]) .setLabelProvider(countLabelProvider); + buildColumn(viewer, Messages.STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME, SWT.RIGHT, columnWidths[2]) + .setLabelProvider(allocPressureLabelProvider); PlatformUI.getWorkbench().getHelpSystem().setHelp(viewer.getControl(), HELP_CONTEXT_ID); @@ -731,7 +739,13 @@ public class StacktraceView extends ViewPart implements ISelectionListener { private final ColumnLabelProvider countLabelProvider = new ColumnLabelProvider() { @Override public String getText(Object element) { - return Integer.toString(((StacktraceFrame) element).getItemCount()); + // display normalized count (percentage of total count) + StacktraceFrame frame = (StacktraceFrame) element; + Fork rootFork = getRootFork(frame.getBranch().getParentFork()); + int itemCount = frame.getItemCount(); + int totalCount = rootFork.getItemsInFork(); + return UnitLookup.PERCENT_UNITY.quantity(itemCount / (double) totalCount) + .displayUsing(IDisplayable.AUTO); } @Override @@ -756,6 +770,31 @@ public class StacktraceView extends ViewPart implements ISelectionListener { } }; + private final ColumnLabelProvider allocPressureLabelProvider = new ColumnLabelProvider() { + @Override + public String getText(Object element) { + StacktraceFrame frame = (StacktraceFrame) element; + + SimpleArray items = frame.getItems(); + Branch branch = frame.getBranch(); + SimpleArray allItems = new SimpleArray(branch.getFirstFrame().getItems().elements()); + for (StacktraceFrame f: branch.getTailFrames()) { + allItems.addAll(f.getItems().elements()); + } + + IItemCollection itemsCollection = ItemCollectionToolkit.build(IteratorToolkit.toList(items.iterator(), items.size()).stream()); + IItemCollection allItemsCollection = ItemCollectionToolkit.build(IteratorToolkit.toList(allItems.iterator(), items.size()).stream()); + + try { + Double itemsAlloc = itemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue(); + Double allItemsAlloc = allItemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue(); + return String.format("%.1f %%", (itemsAlloc / allItemsAlloc ) * 100); + } catch (NullPointerException e) { // ALLOCATION_TOTAL is only available in Memory page + return ""; + } + } + }; + private final ColumnLabelProvider stackTraceLabelProvider = new ColumnLabelProvider() { @Override diff --git a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties index cd954bd..96ce600 100644 --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties @@ -418,6 +418,7 @@ STORED_SELECTIONS_SIZE_UNPARSABLE=Number of stored selections to keep: {0} STORE_SELECTION_ACTION=Store Selection STORE_AND_ACTIVATE_SELECTION_ACTION=Store and Set As Focused Selection +STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME=Allocation Pressure STACKTRACE_VIEW_COUNT_COLUMN_NAME=Count STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY=Distinguish Frames By STACKTRACE_VIEW_FRAME_GROUP_CHOOSE=Choose Frame Group From sasiddiq at redhat.com Fri Jul 26 14:14:08 2019 From: sasiddiq at redhat.com (Salman Siddiqui) Date: Fri, 26 Jul 2019 14:14:08 +0000 Subject: Review Request for JMC-5923: Add allocation pressure column to stacktrace view In-Reply-To: References: Message-ID: Hi all, Here is a webrev for the patch: https://cr.openjdk.java.net/~aptmac/JMC-5923/webrev.00/ Thanks, Salman On Thu, Jul 25, 2019 at 9:42 PM Salman Siddiqui wrote: > Hi all, > > Here is patch that adds a column to the stacktrace view to display > normalized allocation pressure. The allocation pressure is a ratio of the > size of the allocations of a particular class to the size of total > allocations from that stacktrace frame. > > Also, as per suggestion from Marcus, I have normalized the count that is > displayed in the stacktrace view (this is similar to what is already being > displayed in the tool tip for the count). > > JIRA issue: https://bugs.openjdk.java.net/browse/JMC-5923 > Related GitHub issue: https://github.com/JDKMissionControl/jmc/issues/6 > > Patch is below. > > Thanks, > Salman > > > diff --git > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java > index 7b576f3..cd8234a 100644 > --- > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java > +++ > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java > @@ -435,6 +435,7 @@ public class Messages extends NLS { > public static String SELECT_RANGE_WIZARD_TEXT; > public static String SELECT_RANGE_WIZARD_TITLE; > public static String SELECT_RANGE_WIZARD_TO_MUCH_SELECTED_WARNING; > + public static String STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME; > public static String STACKTRACE_VIEW_COUNT_COLUMN_NAME; > public static String STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY; > public static String STACKTRACE_VIEW_FRAME_GROUP_CHOOSE; > diff --git > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java > index 2b51e80..9d96016 100644 > --- > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java > +++ > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java > @@ -92,10 +92,16 @@ import org.eclipse.ui.part.ViewPart; > import org.openjdk.jmc.common.IDisplayable; > import org.openjdk.jmc.common.IMCFrame; > import org.openjdk.jmc.common.IState; > +import org.openjdk.jmc.common.collection.IteratorToolkit; > import org.openjdk.jmc.common.collection.SimpleArray; > +import org.openjdk.jmc.common.item.IItem; > import org.openjdk.jmc.common.item.IItemCollection; > +import org.openjdk.jmc.common.item.IItemFilter; > +import org.openjdk.jmc.common.item.ItemFilters; > import org.openjdk.jmc.common.unit.UnitLookup; > import org.openjdk.jmc.common.util.StateToolkit; > +import org.openjdk.jmc.flightrecorder.jdk.JdkAggregators; > +import org.openjdk.jmc.flightrecorder.jdk.JdkFilters; > import org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator; > import > org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator.FrameCategorization; > import org.openjdk.jmc.flightrecorder.stacktrace.StacktraceFormatToolkit; > @@ -181,7 +187,7 @@ public class StacktraceView extends ViewPart > implements ISelectionListener { > private static final Color COUNT_COLOR = SWTColorToolkit.getColor(new > RGB(100, 200, 100)); > private static final String SIBLINGS_IMG_KEY = "siblingsColor"; > //$NON-NLS-1$ > private static final Color SIBLINGS_COUNT_COLOR = > SWTColorToolkit.getColor(new RGB(170, 250, 170)); > - private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150}; > + private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150, 150}; > private static final String THREAD_ROOT_KEY = "threadRootAtTop"; > //$NON-NLS-1$ > private static final String FRAME_OPTIMIZATION_KEY = > "distinguishFramesByOptimization"; //$NON-NLS-1$ > private static final String FRAME_CATEGORIZATION_KEY = > "distinguishFramesCategorization"; //$NON-NLS-1$ > @@ -491,7 +497,7 @@ public class StacktraceView extends ViewPart > implements ISelectionListener { > new StacktraceViewToolTipSupport(viewer); > MCContextMenuManager mm = > MCContextMenuManager.create(viewer.getControl()); > CopySelectionAction copyAction = new CopySelectionAction(viewer, > - FormatToolkit.selectionFormatter(stackTraceLabelProvider, > countLabelProvider)); > + FormatToolkit.selectionFormatter(stackTraceLabelProvider, > countLabelProvider, allocPressureLabelProvider)); > InFocusHandlerActivator.install(viewer.getControl(), copyAction); > mm.appendToGroup(MCContextMenuManager.GROUP_EDIT, copyAction); > mm.appendToGroup(MCContextMenuManager.GROUP_EDIT, > CopySettings.getInstance().createContributionItem()); > @@ -515,6 +521,8 @@ public class StacktraceView extends ViewPart > implements ISelectionListener { > .setLabelProvider(stackTraceLabelProvider); > buildColumn(viewer, Messages.STACKTRACE_VIEW_COUNT_COLUMN_NAME, > SWT.RIGHT, columnWidths[1]) > .setLabelProvider(countLabelProvider); > + buildColumn(viewer, Messages.STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME, > SWT.RIGHT, columnWidths[2]) > + .setLabelProvider(allocPressureLabelProvider); > > PlatformUI.getWorkbench().getHelpSystem().setHelp(viewer.getControl(), > HELP_CONTEXT_ID); > > @@ -731,7 +739,13 @@ public class StacktraceView extends ViewPart > implements ISelectionListener { > private final ColumnLabelProvider countLabelProvider = new > ColumnLabelProvider() { > @Override > public String getText(Object element) { > - return Integer.toString(((StacktraceFrame) element).getItemCount()); > + // display normalized count (percentage of total count) > + StacktraceFrame frame = (StacktraceFrame) element; > + Fork rootFork = getRootFork(frame.getBranch().getParentFork()); > + int itemCount = frame.getItemCount(); > + int totalCount = rootFork.getItemsInFork(); > + return UnitLookup.PERCENT_UNITY.quantity(itemCount / (double) totalCount) > + .displayUsing(IDisplayable.AUTO); > } > > @Override > @@ -756,6 +770,31 @@ public class StacktraceView extends ViewPart > implements ISelectionListener { > } > }; > > + private final ColumnLabelProvider allocPressureLabelProvider = new > ColumnLabelProvider() { > + @Override > + public String getText(Object element) { > + StacktraceFrame frame = (StacktraceFrame) element; > + > + SimpleArray items = frame.getItems(); > + Branch branch = frame.getBranch(); > + SimpleArray allItems = new > SimpleArray(branch.getFirstFrame().getItems().elements()); > + for (StacktraceFrame f: branch.getTailFrames()) { > + allItems.addAll(f.getItems().elements()); > + } > + > + IItemCollection itemsCollection = > ItemCollectionToolkit.build(IteratorToolkit.toList(items.iterator(), > items.size()).stream()); > + IItemCollection allItemsCollection = > ItemCollectionToolkit.build(IteratorToolkit.toList(allItems.iterator(), > items.size()).stream()); > + > + try { > + Double itemsAlloc = > itemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue(); > + Double allItemsAlloc = > allItemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue(); > + return String.format("%.1f %%", (itemsAlloc / allItemsAlloc ) * 100); > + } catch (NullPointerException e) { // ALLOCATION_TOTAL is only available > in Memory page > + return ""; > + } > + } > + }; > + > private final ColumnLabelProvider stackTraceLabelProvider = new > ColumnLabelProvider() { > > @Override > diff --git > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties > index cd954bd..96ce600 100644 > --- > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties > +++ > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties > @@ -418,6 +418,7 @@ STORED_SELECTIONS_SIZE_UNPARSABLE=Number of stored > selections to keep: {0} > STORE_SELECTION_ACTION=Store Selection > STORE_AND_ACTIVATE_SELECTION_ACTION=Store and Set As Focused Selection > > +STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME=Allocation Pressure > STACKTRACE_VIEW_COUNT_COLUMN_NAME=Count > STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY=Distinguish Frames By > STACKTRACE_VIEW_FRAME_GROUP_CHOOSE=Choose Frame Group > > > From marcus.hirt at datadoghq.com Fri Jul 26 19:35:43 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Fri, 26 Jul 2019 21:35:43 +0200 Subject: Review request for JMC-6541: Using more compact notation for Flame View json data Message-ID: Hi all, Please review this fix for using a more compact notation for the json used with the Flame View. This CR also takes care of JMC-6530 (update to the latest flame view library) and may even fix the Windows label rendering problem, though I haven't had a chance to test that yet. Jira: https://bugs.openjdk.java.net/browse/JMC-6541 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6541/webrev.0/ Kind regards, Marcus From hdafgard at gmail.com Mon Jul 29 11:50:08 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Mon, 29 Jul 2019 13:50:08 +0200 Subject: Review request for JMC-6541: Using more compact notation for Flame View json data In-Reply-To: References: Message-ID: This looks good to me! Cheers, Henrik Dafg?rd On Fri, 26 Jul 2019 at 21:36, Marcus Hirt wrote: > Hi all, > > Please review this fix for using a more compact notation for the json > used with the Flame View. > This CR also takes care of JMC-6530 (update to the latest flame view > library) and may even fix the Windows label rendering problem, though > I haven't had a chance to test that yet. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6541 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6541/webrev.0/ > > Kind regards, > Marcus > From marcus at hirt.se Mon Jul 29 12:14:34 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Mon, 29 Jul 2019 12:14:34 +0000 Subject: hg: jmc/jmc: JMC-6541: Switching to more compact data format for the flame graph json, also updating to new version of the flame graph library (JMC-6530) Message-ID: <201907291214.x6TCEY86024607@aojmv0008.oracle.com> Changeset: 91a803e741ac Author: hirt Date: 2019-07-29 14:14 +0200 URL: https://hg.openjdk.java.net/jmc/jmc/rev/91a803e741ac JMC-6541: Switching to more compact data format for the flame graph json, also updating to new version of the flame graph library (JMC-6530) Reviewed-by: hdafgard ! application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/views/FlameGraphView.java ! application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/views/page.html From almacdon at redhat.com Mon Jul 29 16:03:14 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Mon, 29 Jul 2019 12:03:14 -0400 Subject: Review Request for JMC-6467 In-Reply-To: References: Message-ID: Hi Henrik, On Thu, Jul 25, 2019 at 1:37 PM Henrik Dafg?rd wrote: > Hi all, > > Please review this request for generalizing the G1 Heap Layout page. The > pages.xml file that contains the new default color values could use one or > two suggestions for Shenandoah events, if anyone has particular suggestions > for default color values there. > I've applied the patch and tried to open the Heap Layout page, however I'm running into a NPE when G1Page.createRegionList() [0] is adding items to "allRegions". For type jdk.ShenandoahHeapRegionInformation, the "typeAccessor" variable [1] is coming back null, which ultimately causes an NPE when trying to to retrieve a value from it [2]. Taking a bit of a deeper look there seems to be a mismatch between the structure of REGION_STATE and what I'm observing in the list of accessors. G1Constants is looking for (state, Type(text)), however the actual value of the key involving state is (state, Linear(number)). To quickly test I was able to retrieve a value using attr("state", "State", NUMBER), however this doesn't match the return type of customAccessor(). I only have one shenandoah jfr file that I've been using, if you aren't experiencing this exception would you be able to provide a basic jfr file for verifying the behaviour? [0] http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l442 [1] http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l453 [2] http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l458 > JIRA: https://bugs.openjdk.java.net/browse/JMC-6467 > Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.0/ > > > Cheers, > Henrik Dafg?rd > Cheers, Alex From hdafgard at gmail.com Tue Jul 30 11:45:43 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Tue, 30 Jul 2019 13:45:43 +0200 Subject: Review Request for JMC-6467 In-Reply-To: References: Message-ID: Hi Alex, Thanks for finding this, the issue seems to be that I mis-typed the type string for Jdk.ShenandoahRegionStateChange as Jdk.ShenandoahRegionTypeChange. Fixing that solved the NPEs. Updated Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.1/ Cheers, Henrik Dafg?rd On Mon, 29 Jul 2019 at 18:03, Alex Macdonald wrote: > Hi Henrik, > > On Thu, Jul 25, 2019 at 1:37 PM Henrik Dafg?rd wrote: > >> Hi all, >> >> Please review this request for generalizing the G1 Heap Layout page. The >> pages.xml file that contains the new default color values could use one or >> two suggestions for Shenandoah events, if anyone has particular >> suggestions >> for default color values there. >> > > I've applied the patch and tried to open the Heap Layout page, however I'm > running into a NPE when G1Page.createRegionList() [0] is adding items to > "allRegions". > > For type jdk.ShenandoahHeapRegionInformation, the "typeAccessor" variable > [1] is coming back null, which ultimately causes an NPE when trying to to > retrieve a value from it [2]. Taking a bit of a deeper look there seems to > be a mismatch between the structure of REGION_STATE and what I'm observing > in the list of accessors. G1Constants is looking for (state, Type(text)), > however the actual value of the key involving state is (state, > Linear(number)). To quickly test I was able to retrieve a value using > attr("state", "State", NUMBER), however this doesn't match the return type > of customAccessor(). > > I only have one shenandoah jfr file that I've been using, if you aren't > experiencing this exception would you be able to provide a basic jfr file > for verifying the behaviour? > > [0] > http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l442 > [1] > http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l453 > [2] > http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l458 > > >> JIRA: https://bugs.openjdk.java.net/browse/JMC-6467 >> Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.0/ >> >> >> Cheers, >> Henrik Dafg?rd >> > > Cheers, > > Alex > From almacdon at redhat.com Tue Jul 30 15:04:20 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Tue, 30 Jul 2019 11:04:20 -0400 Subject: Review Request for JMC-6467 In-Reply-To: References: Message-ID: Hi Henrik, On Tue, Jul 30, 2019 at 7:45 AM Henrik Dafg?rd wrote: > Hi Alex, > > Thanks for finding this, the issue seems to be that I mis-typed the type > string for Jdk.ShenandoahRegionStateChange as > Jdk.ShenandoahRegionTypeChange. Fixing that solved the NPEs. > > Updated Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.1/ > > Hm, it looks like I'm still encountering the same problem as before. It wasn't that branch of the if-statement in G1Constants which was running into problems (but good a typo was caught), but rather the one above it: [..] } else if (type.getIdentifier().equals(JdkTypeIDs.GC_SHENANDOAH_HEAP_REGION_INFORMATION)) { return REGION_STATE.getAccessor(type); } [..] The returned value here is null for me. When I take a look at the passed type object it is correctly a jdk.ShenandoahHeapRegionInformation, however the state attribute looks like: type.m_accessors[2] = Attribute(state, Linear(number))=org.openjdk.jmc.common.unit.StructContentType$AccessorEntry at 5b32e0b1 but the REGION_STATE is looking for PLAIN_TEXT ("text"), which is a mismatch. For reference here's the stack trace that gets displayed in the jfr editor page: java.lang.NullPointerException at org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.createRegionList(G1Page.java:443) at org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.setUpHeapDumps(G1Page.java:454) at org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.(G1Page.java:218) at org.openjdk.jmc.flightrecorder.ext.g1.G1Page.display(G1Page.java:586) at org.openjdk.jmc.flightrecorder.ui.JfrEditor.displayPage(JfrEditor.java:232) at org.openjdk.jmc.flightrecorder.ui.JfrEditor.navigateTo(JfrEditor.java:216) at org.openjdk.jmc.flightrecorder.ui.JfrOutlinePage.selectionChanged(JfrOutlinePage.java:449) > Cheers, > Henrik Dafg?rd > > > On Mon, 29 Jul 2019 at 18:03, Alex Macdonald wrote: > >> Hi Henrik, >> >> On Thu, Jul 25, 2019 at 1:37 PM Henrik Dafg?rd >> wrote: >> >>> Hi all, >>> >>> Please review this request for generalizing the G1 Heap Layout page. The >>> pages.xml file that contains the new default color values could use one >>> or >>> two suggestions for Shenandoah events, if anyone has particular >>> suggestions >>> for default color values there. >>> >> >> I've applied the patch and tried to open the Heap Layout page, however >> I'm running into a NPE when G1Page.createRegionList() [0] is adding items >> to "allRegions". >> >> For type jdk.ShenandoahHeapRegionInformation, the "typeAccessor" variable >> [1] is coming back null, which ultimately causes an NPE when trying to to >> retrieve a value from it [2]. Taking a bit of a deeper look there seems to >> be a mismatch between the structure of REGION_STATE and what I'm observing >> in the list of accessors. G1Constants is looking for (state, Type(text)), >> however the actual value of the key involving state is (state, >> Linear(number)). To quickly test I was able to retrieve a value using >> attr("state", "State", NUMBER), however this doesn't match the return type >> of customAccessor(). >> >> I only have one shenandoah jfr file that I've been using, if you aren't >> experiencing this exception would you be able to provide a basic jfr file >> for verifying the behaviour? >> >> [0] >> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l442 >> [1] >> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l453 >> [2] >> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l458 >> >> >>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6467 >>> Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.0/ >>> >>> >>> Cheers, >>> Henrik Dafg?rd >>> >> >> Cheers, >> >> Alex >> > From jkang at redhat.com Tue Jul 30 20:48:29 2019 From: jkang at redhat.com (Jie Kang) Date: Tue, 30 Jul 2019 16:48:29 -0400 Subject: JMC-5640: Used Heap After GC Chart In-Reply-To: References: Message-ID: On Tue, Jul 23, 2019 at 10:29 AM Ken Dobson wrote: > > Hi all, > > Here is a patch that adds a Used Heap Post GC chart to the Garbage > Collections page. > The implementation is a bit hacky but the only way I could find to add a > variation of an attribute already being displayed on a page was to create a > duplicate attribute in JdkAttributes.java as well as compare names for > uniqueness as identifiers are no longer unique if we intend to look at > different subsets of the same attribute. > > If anyone has any ideas as to how to enact this change in a way that allows > us to maintain consistency with the way the other pages operate as well as > a way to avoid multiple copies of attributes feel free to share them. > > Bug Id: https://bugs.openjdk.java.net/browse/JMC-5640 > Webrev: http://cr.openjdk.java.net/~kdobson/JMC-5640/webrev/ Hey Ken, One minor nit: DataPageToolkit.buildLinesRow(Messages.GarbageCollectionsPage_ROW_HEAP, Messages.GarbageCollectionsPage_ROW_HEAP_DESC, allItems, false, HEAP_SUMMARY, legendFilter, UnitLookup.BYTE.quantity(0), null).ifPresent(rows::add); + DataPageToolkit.buildLinesRow("Heap Post GC", + "Heap Post GC", allItems, false, HEAP_SUMMARY_POST_GC, legendFilter, + UnitLookup.BYTE.quantity(0), null).ifPresent(rows::add); You should add a String for "Heap Post GC" to Messages and reference that instead, like how it's done above your addition. The rest looks fine to me. Regarding the 'hacky' Attributes addition, it's a bit complicated. The toolkit code being used doesn't cover the situation where you are showing the same attribute filtered two different ways in the same chart. Though it can be confusing, the distinction does need to be made somewhere along the line. I think this patch is okay but I could see an issue made to address this use-case more cleanly. Trying to re-work the existing code might take some time. Regards, > > Thanks, > > Ken From almacdon at redhat.com Wed Jul 31 19:43:06 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Wed, 31 Jul 2019 15:43:06 -0400 Subject: Review Request for JMC-6467 In-Reply-To: References: Message-ID: Hi Henrik, On Tue, Jul 30, 2019 at 11:04 AM Alex Macdonald wrote: > Hi Henrik, > > On Tue, Jul 30, 2019 at 7:45 AM Henrik Dafg?rd wrote: > >> Hi Alex, >> >> Thanks for finding this, the issue seems to be that I mis-typed the type >> string for Jdk.ShenandoahRegionStateChange as >> Jdk.ShenandoahRegionTypeChange. Fixing that solved the NPEs. >> >> Updated Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.1/ >> >> > Hm, it looks like I'm still encountering the same problem as before. It > wasn't that branch of the if-statement in G1Constants which was running > into problems (but good a typo was caught), but rather the one above it: > > [..] > } else if > (type.getIdentifier().equals(JdkTypeIDs.GC_SHENANDOAH_HEAP_REGION_INFORMATION)) > { > return REGION_STATE.getAccessor(type); > } > [..] > > The returned value here is null for me. When I take a look at the passed > type object it is correctly a jdk.ShenandoahHeapRegionInformation, however > the state attribute looks like: > > type.m_accessors[2] = Attribute(state, > Linear(number))=org.openjdk.jmc.common.unit.StructContentType$AccessorEntry at 5b32e0b1 > > but the REGION_STATE is looking for PLAIN_TEXT ("text"), which is a > mismatch. > > For reference here's the stack trace that gets displayed in the jfr editor > page: > > java.lang.NullPointerException > at > org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.createRegionList(G1Page.java:443) > at > org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.setUpHeapDumps(G1Page.java:454) > at > org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.(G1Page.java:218) > at org.openjdk.jmc.flightrecorder.ext.g1.G1Page.display(G1Page.java:586) > at > org.openjdk.jmc.flightrecorder.ui.JfrEditor.displayPage(JfrEditor.java:232) > at > org.openjdk.jmc.flightrecorder.ui.JfrEditor.navigateTo(JfrEditor.java:216) > at > org.openjdk.jmc.flightrecorder.ui.JfrOutlinePage.selectionChanged(JfrOutlinePage.java:449) > My mistake, it looks like the recording I've been using may be irrelevant because it was using a work-in-progress implementation of the shenandoah events rather than the final ones. Ken has supplied me a newer shenandoah recording and the page is visible and working now. As for some minor nits: There are a handful of empty spaces/tabs that can be cleaned up: - ColorMap (9) - G1Page (4) - TypeIDs (2) Also the page name has been generalized from "G1 Heap Layout", would now also be a good time to update the other instances of g1* throughout the extension? > Cheers, >> Henrik Dafg?rd >> >> >> On Mon, 29 Jul 2019 at 18:03, Alex Macdonald wrote: >> >>> Hi Henrik, >>> >>> On Thu, Jul 25, 2019 at 1:37 PM Henrik Dafg?rd >>> wrote: >>> >>>> Hi all, >>>> >>>> Please review this request for generalizing the G1 Heap Layout page. The >>>> pages.xml file that contains the new default color values could use one >>>> or >>>> two suggestions for Shenandoah events, if anyone has particular >>>> suggestions >>>> for default color values there. >>>> >>> >>> I've applied the patch and tried to open the Heap Layout page, however >>> I'm running into a NPE when G1Page.createRegionList() [0] is adding items >>> to "allRegions". >>> >>> For type jdk.ShenandoahHeapRegionInformation, the "typeAccessor" >>> variable [1] is coming back null, which ultimately causes an NPE when >>> trying to to retrieve a value from it [2]. Taking a bit of a deeper look >>> there seems to be a mismatch between the structure of REGION_STATE and what >>> I'm observing in the list of accessors. G1Constants is looking for (state, >>> Type(text)), however the actual value of the key involving state is (state, >>> Linear(number)). To quickly test I was able to retrieve a value using >>> attr("state", "State", NUMBER), however this doesn't match the return type >>> of customAccessor(). >>> >>> I only have one shenandoah jfr file that I've been using, if you aren't >>> experiencing this exception would you be able to provide a basic jfr file >>> for verifying the behaviour? >>> >>> [0] >>> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l442 >>> [1] >>> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l453 >>> [2] >>> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l458 >>> >>> >>>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6467 >>>> Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.0/ >>>> >>>> >>>> Cheers, >>>> Henrik Dafg?rd >>>> >>> >>> Cheers, >>> >>> Alex >>> >>