From markus.gronlund at oracle.com Sat Jun 1 08:16:17 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Sat, 1 Jun 2019 01:16:17 -0700 (PDT) Subject: RFR: 8216283: Allow shorter method sampling interval than 10 ms In-Reply-To: <5CE2E811.4060904@oracle.com> References: <5CE2E811.4060904@oracle.com> Message-ID: Hi Erik, Looks good. Thanks Markus -----Original Message----- From: Erik Gahlin Sent: den 20 maj 2019 19:47 To: hotspot-jfr-dev at openjdk.java.net Cc: jmc-dev at openjdk.java.net Subject: RFR: 8216283: Allow shorter method sampling interval than 10 ms Hi, Could I please have a review of a fix that allows method sampling to happen at a higher rate. The current limit of 10 ms exists because method sampling used to occur in the VM period task. Method sampling now happens in a separate thread. This was changed in JDK 9. The minimum accepted interval is lowered from 10 ms to 1 ms for both native and Java samples, but configuration files have been changed so native sampling interval can not be set lower than 20 ms using JMC Recording Wizard controls. Manual edit of the event setting allows 1 ms. The reason for this is to avoid excessive number native sample events. Purpose of native sampling is to detect "stuck threads". That is, threads that have called into native, but not returned. Most of the native samples will however be threads waiting in native, for example on a socket. Going below 20 ms adds little value, since a stuck thread is typically in native for a longer period of time. Method sampling in Java on the other hand can be set to 1 ms in a new "mode" called "Extreme". To avoid confusion, I didn't want to use "Maximum" since it means 10 ms in earlier releases. Webrev: http://cr.openjdk.java.net/~egahlin/8216283/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216283 Testing: Tried to set the interval in the JMC Recording Wizard and verified that the correct interval was set in JVM using: $ jcmd JFR.check verbose=true Thanks Erik From marcus at hirt.se Sun Jun 2 19:56:01 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Sun, 02 Jun 2019 19:56:01 +0000 Subject: hg: jmc/jmc7: Added tag 7.0.0-ga for changeset 9871e02a9e40 Message-ID: <201906021956.x52Ju1uL014486@aojmv0008.oracle.com> Changeset: 57ac4537c994 Author: hirt Date: 2019-06-02 21:55 +0200 URL: http://hg.openjdk.java.net/jmc/jmc7/rev/57ac4537c994 Added tag 7.0.0-ga for changeset 9871e02a9e40 ! .hgtags From marcus at hirt.se Sun Jun 2 21:34:35 2019 From: marcus at hirt.se (Marcus Hirt) Date: Sun, 2 Jun 2019 23:34:35 +0200 Subject: JDK Mission Control 7.0.0 done! Message-ID: <015601d5198a$f98c4b40$eca4e1c0$@hirt.se> Hi all, The source release for JDK Mission Control 7.0.0 is thus complete. A big thank you to everyone who contributed to this release! Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r marcus at hirt.se Skickat: den 2 juni 2019 21:56 Till: jmc-dev at openjdk.java.net ?mne: hg: jmc/jmc7: Added tag 7.0.0-ga for changeset 9871e02a9e40 Changeset: 57ac4537c994 Author: hirt Date: 2019-06-02 21:55 +0200 URL: http://hg.openjdk.java.net/jmc/jmc7/rev/57ac4537c994 Added tag 7.0.0-ga for changeset 9871e02a9e40 ! .hgtags From evgeniia at azul.com Mon Jun 3 07:09:34 2019 From: evgeniia at azul.com (Evgeniia Stepanova) Date: Mon, 3 Jun 2019 07:09:34 +0000 Subject: JMC 7.0.0 final testing. In-Reply-To: <001501d51536$60605180$2120f480$@hirt.se> References: <001501d51536$60605180$2120f480$@hirt.se> Message-ID: <0a79c4aae5d6431496a9cb8630354635@azul.com> Hi Marcus! Sorry for the delay. Azul have tested latest jmc changes, no critical issues found. Tested on Win10, MacOS Sierra and Ubuntu18. Also we've tested JVM connections to the following platforms and runtimes: Solaris10 x86 (zulu8), Solaris11 x86 (zulu11), Solaris10 SPARC (zulu8), AlpineMusl (zulu8), Win64 (zulu8x32), Lunux64 (zing11), Lunux64 (zulu11), MacOS (openjdk11). Everything looks good. Thank you very much, Evgeniia > -----Original Message----- > From: jmc-dev On Behalf Of Marcus > Hirt > Sent: Tuesday, May 28, 2019 12:19 PM > To: jmc-dev at openjdk.java.net > Subject: JMC 7.0.0 final testing. > > Hi all, > > The last changes just went into JMC 7 and final testing is now underway. > Unless something unexpected pops up, what is currently in the jmc7 repo (at > changeset 128:9871e02a9e40) is what will be tagged as 7.0.0-ga for the JMC > 7.0.0 source release. > > Kind regards, > Marcus From neugens at redhat.com Mon Jun 3 07:09:54 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 09:09:54 +0200 Subject: JDK Mission Control 7.0.0 done! In-Reply-To: <015601d5198a$f98c4b40$eca4e1c0$@hirt.se> References: <015601d5198a$f98c4b40$eca4e1c0$@hirt.se> Message-ID: Congratulations! Cheers, Mario On Sun, Jun 2, 2019 at 11:56 PM Marcus Hirt wrote: > > Hi all, > > The source release for JDK Mission Control 7.0.0 is thus complete. > > A big thank you to everyone who contributed to this release! > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r marcus at hirt.se > Skickat: den 2 juni 2019 21:56 > Till: jmc-dev at openjdk.java.net > ?mne: hg: jmc/jmc7: Added tag 7.0.0-ga for changeset 9871e02a9e40 > > Changeset: 57ac4537c994 > Author: hirt > Date: 2019-06-02 21:55 +0200 > URL: http://hg.openjdk.java.net/jmc/jmc7/rev/57ac4537c994 > > Added tag 7.0.0-ga for changeset 9871e02a9e40 > > ! .hgtags > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From simone.bordet at gmail.com Mon Jun 3 09:33:22 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 3 Jun 2019 11:33:22 +0200 Subject: Cannot build JMC Message-ID: Hi, JMC 7.0.0-ga. I'm following what's in the README and the build fails for me at the "mvn package" command from the JMC root directory: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation failure: Compilation failure: [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] [ERROR] import javafx.application.Platform; [ERROR] ^^^^^^ There are other 20 errors similar to this one. Ideas? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From marcus.hirt at datadoghq.com Mon Jun 3 09:37:41 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 3 Jun 2019 11:37:41 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hi Simone, Are you sure you have the p2 repo up and running? http://hirt.se/blog/?p=947 Kind regards, Marcus On Mon, Jun 3, 2019 at 11:33 AM Simone Bordet wrote: > > Hi, > > JMC 7.0.0-ga. > > I'm following what's in the README and the build fails for me at the > "mvn package" command from the JMC root directory: > > [ERROR] Failed to execute goal > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > failure: Compilation failure: > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > [ERROR] import javafx.application.Platform; > [ERROR] ^^^^^^ > > There are other 20 errors similar to this one. > > Ideas? > > Thanks! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From neugens at redhat.com Mon Jun 3 09:42:28 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 11:42:28 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: What system are you on? On RHEL 8 (and 7) for example there's no bundled JFX, while there is on Fedora. So if you are using a system where no JFX is present (any build of OpenJDK and any Oracle JDK since 11) then you either need to install it or patch the JFX bits out. I think the JFX bits should be optional on JMC but we're not there yet. Cheers, Mario On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > Hi, > > JMC 7.0.0-ga. > > I'm following what's in the README and the build fails for me at the > "mvn package" command from the JMC root directory: > > [ERROR] Failed to execute goal > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > failure: Compilation failure: > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > [ERROR] import javafx.application.Platform; > [ERROR] ^^^^^^ > > There are other 20 errors similar to this one. > > Ideas? > > Thanks! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From simone.bordet at gmail.com Mon Jun 3 10:04:51 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 3 Jun 2019 12:04:51 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hi Marcus, On Mon, Jun 3, 2019 at 11:37 AM Marcus Hirt wrote: > > Hi Simone, > > Are you sure you have the p2 repo up and running? > http://hirt.se/blog/?p=947 Yes, everything is setup as per README and your blog. I was using AdoptOpenJDK 8u212, which does not ship JFX. Once I downloaded Oracle 8u212, the build succeeded. Perhaps you can add a note to the build instructions? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Jun 3 10:11:55 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 3 Jun 2019 12:11:55 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hi, On Mon, Jun 3, 2019 at 12:04 PM Simone Bordet wrote: > Once I downloaded Oracle 8u212, the build succeeded. But I cannot run the built JMC with JDK8 - is that expected? I see a popup window with a number of JVM options that include JDK 9+ JPMS directives such as --add-exports etc. If I run the built JMC with JDK 12.0.1 (but I guess any JDK 9+) it will run fine. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From neugens at redhat.com Mon Jun 3 10:12:04 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 12:12:04 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 12:05 PM Simone Bordet wrote: > > Hi Marcus, > > On Mon, Jun 3, 2019 at 11:37 AM Marcus Hirt wrote: > > > > Hi Simone, > > > > Are you sure you have the p2 repo up and running? > > http://hirt.se/blog/?p=947 > > Yes, everything is setup as per README and your blog. > > I was using AdoptOpenJDK 8u212, which does not ship JFX. > > Once I downloaded Oracle 8u212, the build succeeded. > > Perhaps you can add a note to the build instructions? Yes, but we shouldn't be requiring JFX, however nice it is. 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 Mon Jun 3 10:21:27 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 12:21:27 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: I think this is a bug as it should be possible to select the correct .ini file based on the JVM you are using. Nevertheless, you can create an alternative jmc.ini file without the modules directives, just copy the default one and remove all the modules stuff, then launch JMC with this option -launcher.ini jdk8.ini (our of memory, so the actual option may be slightly different but this should get you closer). Cheers, Mario On Mon, Jun 3, 2019 at 12:12 PM Simone Bordet wrote: > > Hi, > > On Mon, Jun 3, 2019 at 12:04 PM Simone Bordet wrote: > > Once I downloaded Oracle 8u212, the build succeeded. > > But I cannot run the built JMC with JDK8 - is that expected? > I see a popup window with a number of JVM options that include JDK 9+ > JPMS directives such as --add-exports etc. > > If I run the built JMC with JDK 12.0.1 (but I guess any JDK 9+) it > will run fine. > > Thanks! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz -- 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 Jun 3 11:45:51 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Mon, 3 Jun 2019 13:45:51 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hi Simone, The build should be runnable with a JDK8, this should be ensured by the "-XX:+IgnoreUnrecognizedVMOptions" flag to ignore the JDK9+ specific options. Regards, Henrik Dafg?rd On Mon, 3 Jun 2019 at 12:12, Simone Bordet wrote: > Hi, > > On Mon, Jun 3, 2019 at 12:04 PM Simone Bordet > wrote: > > Once I downloaded Oracle 8u212, the build succeeded. > > But I cannot run the built JMC with JDK8 - is that expected? > I see a popup window with a number of JVM options that include JDK 9+ > JPMS directives such as --add-exports etc. > > If I run the built JMC with JDK 12.0.1 (but I guess any JDK 9+) it > will run fine. > > Thanks! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > From marcus.hirt at datadoghq.com Mon Jun 3 12:11:11 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 3 Jun 2019 14:11:11 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: The JavaFX bits are used by optional plug-ins, and they should be downloaded from maven central when required. It should be possible to build JMC without having JavaFX linked into the JDK. I actually thought this was already the case. I will open an Issue. Kind regards, Marcus On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: > > What system are you on? > > On RHEL 8 (and 7) for example there's no bundled JFX, while there is > on Fedora. So if you are using a system where no JFX is present (any > build of OpenJDK and any Oracle JDK since 11) then you either need to > install it or patch the JFX bits out. > > I think the JFX bits should be optional on JMC but we're not there yet. > > Cheers, > Mario > > On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > > > Hi, > > > > JMC 7.0.0-ga. > > > > I'm following what's in the README and the build fails for me at the > > "mvn package" command from the JMC root directory: > > > > [ERROR] Failed to execute goal > > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > > failure: Compilation failure: > > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > > [ERROR] import javafx.application.Platform; > > [ERROR] ^^^^^^ > > > > There are other 20 errors similar to this one. > > > > Ideas? > > > > Thanks! > > > > -- > > Simone Bordet > > --- > > Finally, no matter how good the architecture and design are, > > to deliver bug-free software with optimal performance and reliability, > > the implementation technique must be flawless. Victoria Livschitz > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Jun 3 13:21:15 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 15:21:15 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: To be fair, I also thought this was the case already, I remember Jie proposing a patch, but I may confuse with what we have in our downstream RPM (or maybe we just pushed the patch to 7.x and not to the 7.0 branch). Can you please assign this bug to Jie I think he may be able to backport the RPM patch into upstream. Cheers, Mario On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt wrote: > > The JavaFX bits are used by optional plug-ins, and they should be > downloaded from maven central when required. It should be possible to > build JMC without having JavaFX linked into the JDK. I actually > thought this was already the case. I will open an Issue. > > Kind regards, > Marcus > > On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: > > > > What system are you on? > > > > On RHEL 8 (and 7) for example there's no bundled JFX, while there is > > on Fedora. So if you are using a system where no JFX is present (any > > build of OpenJDK and any Oracle JDK since 11) then you either need to > > install it or patch the JFX bits out. > > > > I think the JFX bits should be optional on JMC but we're not there yet. > > > > Cheers, > > Mario > > > > On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > > > > > Hi, > > > > > > JMC 7.0.0-ga. > > > > > > I'm following what's in the README and the build fails for me at the > > > "mvn package" command from the JMC root directory: > > > > > > [ERROR] Failed to execute goal > > > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > > > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > > > failure: Compilation failure: > > > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > > > [ERROR] import javafx.application.Platform; > > > [ERROR] ^^^^^^ > > > > > > There are other 20 errors similar to this one. > > > > > > Ideas? > > > > > > Thanks! > > > > > > -- > > > Simone Bordet > > > --- > > > Finally, no matter how good the architecture and design are, > > > to deliver bug-free software with optimal performance and reliability, > > > the implementation technique must be flawless. Victoria Livschitz > > > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- 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 Mon Jun 3 13:29:36 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 3 Jun 2019 15:29:36 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: The idea is that it should still be possible to build JOverflow with a JDK 8 not including JavaFX. The javafx packages should be downloaded from Maven Central by default and exposed through the local p2 repositiory. JOverflow is a pretty useful tool. Unless the patch Jie has actually builds JOverflow, I think a closer look is warranted. Kind regards, Marcus On Mon, Jun 3, 2019 at 3:21 PM Mario Torre wrote: > > To be fair, I also thought this was the case already, I remember Jie > proposing a patch, but I may confuse with what we have in our > downstream RPM (or maybe we just pushed the patch to 7.x and not to > the 7.0 branch). > > Can you please assign this bug to Jie I think he may be able to > backport the RPM patch into upstream. > > Cheers, > Mario > > On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt wrote: > > > > The JavaFX bits are used by optional plug-ins, and they should be > > downloaded from maven central when required. It should be possible to > > build JMC without having JavaFX linked into the JDK. I actually > > thought this was already the case. I will open an Issue. > > > > Kind regards, > > Marcus > > > > On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: > > > > > > What system are you on? > > > > > > On RHEL 8 (and 7) for example there's no bundled JFX, while there is > > > on Fedora. So if you are using a system where no JFX is present (any > > > build of OpenJDK and any Oracle JDK since 11) then you either need to > > > install it or patch the JFX bits out. > > > > > > I think the JFX bits should be optional on JMC but we're not there yet. > > > > > > Cheers, > > > Mario > > > > > > On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > > > > > > > Hi, > > > > > > > > JMC 7.0.0-ga. > > > > > > > > I'm following what's in the README and the build fails for me at the > > > > "mvn package" command from the JMC root directory: > > > > > > > > [ERROR] Failed to execute goal > > > > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > > > > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > > > > failure: Compilation failure: > > > > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > > > > [ERROR] import javafx.application.Platform; > > > > [ERROR] ^^^^^^ > > > > > > > > There are other 20 errors similar to this one. > > > > > > > > Ideas? > > > > > > > > Thanks! > > > > > > > > -- > > > > Simone Bordet > > > > --- > > > > Finally, no matter how good the architecture and design are, > > > > to deliver bug-free software with optimal performance and reliability, > > > > the implementation technique must be flawless. Victoria Livschitz > > > > > > > > > > > > -- > > > Mario Torre > > > Associate Manager, Software Engineering > > > Red Hat GmbH > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Jun 3 13:52:09 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 15:52:09 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Yes, but if it's an *optional* plugin it shouldn't build by default unless someone specifically ask for it. We should probably consider rewriting JOverflow with pure Eclipse API, especially if we want to build it by default, JavaFX isn't being packaged in many Linux distributions. Cheers, Mario On Mon, Jun 3, 2019 at 3:30 PM Marcus Hirt wrote: > > The idea is that it should still be possible to build JOverflow with a > JDK 8 not including JavaFX. The javafx packages should be downloaded > from Maven Central by default and exposed through the local p2 > repositiory. JOverflow is a pretty useful tool. Unless the patch Jie > has actually builds JOverflow, I think a closer look is warranted. > > Kind regards, > Marcus > > On Mon, Jun 3, 2019 at 3:21 PM Mario Torre wrote: > > > > To be fair, I also thought this was the case already, I remember Jie > > proposing a patch, but I may confuse with what we have in our > > downstream RPM (or maybe we just pushed the patch to 7.x and not to > > the 7.0 branch). > > > > Can you please assign this bug to Jie I think he may be able to > > backport the RPM patch into upstream. > > > > Cheers, > > Mario > > > > On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt wrote: > > > > > > The JavaFX bits are used by optional plug-ins, and they should be > > > downloaded from maven central when required. It should be possible to > > > build JMC without having JavaFX linked into the JDK. I actually > > > thought this was already the case. I will open an Issue. > > > > > > Kind regards, > > > Marcus > > > > > > On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: > > > > > > > > What system are you on? > > > > > > > > On RHEL 8 (and 7) for example there's no bundled JFX, while there is > > > > on Fedora. So if you are using a system where no JFX is present (any > > > > build of OpenJDK and any Oracle JDK since 11) then you either need to > > > > install it or patch the JFX bits out. > > > > > > > > I think the JFX bits should be optional on JMC but we're not there yet. > > > > > > > > Cheers, > > > > Mario > > > > > > > > On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > > > > > > > > > Hi, > > > > > > > > > > JMC 7.0.0-ga. > > > > > > > > > > I'm following what's in the README and the build fails for me at the > > > > > "mvn package" command from the JMC root directory: > > > > > > > > > > [ERROR] Failed to execute goal > > > > > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > > > > > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > > > > > failure: Compilation failure: > > > > > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > > > > > [ERROR] import javafx.application.Platform; > > > > > [ERROR] ^^^^^^ > > > > > > > > > > There are other 20 errors similar to this one. > > > > > > > > > > Ideas? > > > > > > > > > > Thanks! > > > > > > > > > > -- > > > > > Simone Bordet > > > > > --- > > > > > Finally, no matter how good the architecture and design are, > > > > > to deliver bug-free software with optimal performance and reliability, > > > > > the implementation technique must be flawless. Victoria Livschitz > > > > > > > > > > > > > > > > -- > > > > Mario Torre > > > > Associate Manager, Software Engineering > > > > Red Hat GmbH > > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jkang at redhat.com Mon Jun 3 16:52:25 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 3 Jun 2019 12:52:25 -0400 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hi Marcus, I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8 without OpenJFX. My search shows that this was not backported to jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently remove all usages of OpenJFX, even the JOverflow plugin itself, when building. * I will setup a system to verify the situation with jmc/jmc7 repo and OpenJDK 8 and see if a backport would fix the issue. In the event that this does, would you like to see a backport request of JMC-6370 from me to jmc/jmc7? * I will also test building JOverflow with OpenJDK 8 not including JavaFX to verify the p2 work that was done in jmc/jmc. [1] https://bugs.openjdk.java.net/browse/JMC-6370 http://hg.openjdk.java.net/jmc/jmc/rev/1a1a3bc8115b Apologies, On Mon, Jun 3, 2019 at 9:30 AM Marcus Hirt wrote: > > The idea is that it should still be possible to build JOverflow with a > JDK 8 not including JavaFX. The javafx packages should be downloaded > from Maven Central by default and exposed through the local p2 > repositiory. JOverflow is a pretty useful tool. Unless the patch Jie > has actually builds JOverflow, I think a closer look is warranted. > > Kind regards, > Marcus > > On Mon, Jun 3, 2019 at 3:21 PM Mario Torre wrote: > > > > To be fair, I also thought this was the case already, I remember Jie > > proposing a patch, but I may confuse with what we have in our > > downstream RPM (or maybe we just pushed the patch to 7.x and not to > > the 7.0 branch). > > > > Can you please assign this bug to Jie I think he may be able to > > backport the RPM patch into upstream. > > > > Cheers, > > Mario > > > > On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt wrote: > > > > > > The JavaFX bits are used by optional plug-ins, and they should be > > > downloaded from maven central when required. It should be possible to > > > build JMC without having JavaFX linked into the JDK. I actually > > > thought this was already the case. I will open an Issue. > > > > > > Kind regards, > > > Marcus > > > > > > On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: > > > > > > > > What system are you on? > > > > > > > > On RHEL 8 (and 7) for example there's no bundled JFX, while there is > > > > on Fedora. So if you are using a system where no JFX is present (any > > > > build of OpenJDK and any Oracle JDK since 11) then you either need to > > > > install it or patch the JFX bits out. > > > > > > > > I think the JFX bits should be optional on JMC but we're not there yet. > > > > > > > > Cheers, > > > > Mario > > > > > > > > On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > > > > > > > > > Hi, > > > > > > > > > > JMC 7.0.0-ga. > > > > > > > > > > I'm following what's in the README and the build fails for me at the > > > > > "mvn package" command from the JMC root directory: > > > > > > > > > > [ERROR] Failed to execute goal > > > > > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > > > > > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > > > > > failure: Compilation failure: > > > > > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > > > > > [ERROR] import javafx.application.Platform; > > > > > [ERROR] ^^^^^^ > > > > > > > > > > There are other 20 errors similar to this one. > > > > > > > > > > Ideas? > > > > > > > > > > Thanks! > > > > > > > > > > -- > > > > > Simone Bordet > > > > > --- > > > > > Finally, no matter how good the architecture and design are, > > > > > to deliver bug-free software with optimal performance and reliability, > > > > > the implementation technique must be flawless. Victoria Livschitz > > > > > > > > > > > > > > > > -- > > > > Mario Torre > > > > Associate Manager, Software Engineering > > > > Red Hat GmbH > > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From simone.bordet at gmail.com Mon Jun 3 17:10:34 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 3 Jun 2019 19:10:34 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hi, On Mon, Jun 3, 2019 at 1:46 PM Henrik Dafg?rd wrote: > > Hi Simone, > > The build should be runnable with a JDK8, this should be ensured by the "-XX:+IgnoreUnrecognizedVMOptions" flag to ignore the JDK9+ specific options. But I don't execute "java ..." so that I can add command line options. I execute "jmc" and that's it (and it picks a bunch of "java" command line options from elsewhere). So if JMC can't be run out of the box with JDK 8 that's ok - just need to know it. It's weird that it requires JDK 8 to build (and a very specific vendor), but then when you try to run it from the same terminal you just built it, it does not start. However, at the end it's just some documentation problem and I got it running. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From marcus.hirt at datadoghq.com Mon Jun 3 17:14:03 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 3 Jun 2019 19:14:03 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: That depends. The plan is to resolve where to host update sites etc for 7.1.0, so perhaps this not being back-ported to 7.0.0 is acceptable. Oracle will be fine either way. You guys (Red Hat) exclude it anyways. It would be if Azul needs this backport. Anyone from Azul having a strong opinion on this? Kind regards, Marcus On Mon, Jun 3, 2019 at 6:52 PM Jie Kang wrote: > > Hi Marcus, > > I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8 > without OpenJFX. My search shows that this was not backported to > jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently > remove all usages of OpenJFX, even the JOverflow plugin itself, when > building. > > * I will setup a system to verify the situation with jmc/jmc7 repo and > OpenJDK 8 and see if a backport would fix the issue. In the event that > this does, would you like to see a backport request of JMC-6370 from > me to jmc/jmc7? > * I will also test building JOverflow with OpenJDK 8 not including > JavaFX to verify the p2 work that was done in jmc/jmc. > > [1] > https://bugs.openjdk.java.net/browse/JMC-6370 > http://hg.openjdk.java.net/jmc/jmc/rev/1a1a3bc8115b > > > Apologies, > > On Mon, Jun 3, 2019 at 9:30 AM Marcus Hirt wrote: > > > > The idea is that it should still be possible to build JOverflow with a > > JDK 8 not including JavaFX. The javafx packages should be downloaded > > from Maven Central by default and exposed through the local p2 > > repositiory. JOverflow is a pretty useful tool. Unless the patch Jie > > has actually builds JOverflow, I think a closer look is warranted. > > > > Kind regards, > > Marcus > > > > On Mon, Jun 3, 2019 at 3:21 PM Mario Torre wrote: > > > > > > To be fair, I also thought this was the case already, I remember Jie > > > proposing a patch, but I may confuse with what we have in our > > > downstream RPM (or maybe we just pushed the patch to 7.x and not to > > > the 7.0 branch). > > > > > > Can you please assign this bug to Jie I think he may be able to > > > backport the RPM patch into upstream. > > > > > > Cheers, > > > Mario > > > > > > On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt wrote: > > > > > > > > The JavaFX bits are used by optional plug-ins, and they should be > > > > downloaded from maven central when required. It should be possible to > > > > build JMC without having JavaFX linked into the JDK. I actually > > > > thought this was already the case. I will open an Issue. > > > > > > > > Kind regards, > > > > Marcus > > > > > > > > On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: > > > > > > > > > > What system are you on? > > > > > > > > > > On RHEL 8 (and 7) for example there's no bundled JFX, while there is > > > > > on Fedora. So if you are using a system where no JFX is present (any > > > > > build of OpenJDK and any Oracle JDK since 11) then you either need to > > > > > install it or patch the JFX bits out. > > > > > > > > > > I think the JFX bits should be optional on JMC but we're not there yet. > > > > > > > > > > Cheers, > > > > > Mario > > > > > > > > > > On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > JMC 7.0.0-ga. > > > > > > > > > > > > I'm following what's in the README and the build fails for me at the > > > > > > "mvn package" command from the JMC root directory: > > > > > > > > > > > > [ERROR] Failed to execute goal > > > > > > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > > > > > > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > > > > > > failure: Compilation failure: > > > > > > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > > > > > > [ERROR] import javafx.application.Platform; > > > > > > [ERROR] ^^^^^^ > > > > > > > > > > > > There are other 20 errors similar to this one. > > > > > > > > > > > > Ideas? > > > > > > > > > > > > Thanks! > > > > > > > > > > > > -- > > > > > > Simone Bordet > > > > > > --- > > > > > > Finally, no matter how good the architecture and design are, > > > > > > to deliver bug-free software with optimal performance and reliability, > > > > > > the implementation technique must be flawless. Victoria Livschitz > > > > > > > > > > > > > > > > > > > > -- > > > > > Mario Torre > > > > > Associate Manager, Software Engineering > > > > > Red Hat GmbH > > > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > > > > > > > > -- > > > Mario Torre > > > Associate Manager, Software Engineering > > > Red Hat GmbH > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Jun 3 17:15:39 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 19:15:39 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 7:11 PM Simone Bordet wrote: > > Hi, > > On Mon, Jun 3, 2019 at 1:46 PM Henrik Dafg?rd wrote: > > > > Hi Simone, > > > > The build should be runnable with a JDK8, this should be ensured by the "-XX:+IgnoreUnrecognizedVMOptions" flag to ignore the JDK9+ specific options. > > But I don't execute "java ..." so that I can add command line options. It needs to be added to the jmc.ini so it gets picked up by default. I'll prepare a patch tomorrow unless Marcus is faster. > So if JMC can't be run out of the box with JDK 8 that's ok - just need > to know it. > It's weird that it requires JDK 8 to build (and a very specific > vendor), but then when you try to run it from the same terminal you > just built it, it does not start. JMC shouldn't need any specific vendor (and it doesn't), in this case it's just a misstep due to JavaFX which isn't part of any Java distribution and somehow slipped through the release (this is because Fedora does bundle OpenJFX and I think most of us tested it there). 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 Mon Jun 3 17:18:22 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 3 Jun 2019 19:18:22 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 7:14 PM Marcus Hirt wrote: > > That depends. The plan is to resolve where to host update sites etc > for 7.1.0, so perhaps this not being back-ported to 7.0.0 is > acceptable. Oracle will be fine either way. You guys (Red Hat) exclude > it anyways. It would be if Azul needs this backport. Anyone from Azul > having a strong opinion on this? I'm fine with not backporting it, but we need to think about upstream first not what Red Hat or Oracle does in their builds. JavaFX at runtime is not a given so we need to be sure things only get compiled when it's present, when the plugin is specifically requested (or it wouldn't be optional) and in this case if the maven build can access the OpenJFX distribution via maven central and this can be used at runtime when building from sources directly from upstream. Cheers, Mario > Kind regards, > Marcus > > On Mon, Jun 3, 2019 at 6:52 PM Jie Kang wrote: > > > > Hi Marcus, > > > > I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8 > > without OpenJFX. My search shows that this was not backported to > > jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently > > remove all usages of OpenJFX, even the JOverflow plugin itself, when > > building. > > > > * I will setup a system to verify the situation with jmc/jmc7 repo and > > OpenJDK 8 and see if a backport would fix the issue. In the event that > > this does, would you like to see a backport request of JMC-6370 from > > me to jmc/jmc7? > > * I will also test building JOverflow with OpenJDK 8 not including > > JavaFX to verify the p2 work that was done in jmc/jmc. > > > > [1] > > https://bugs.openjdk.java.net/browse/JMC-6370 > > http://hg.openjdk.java.net/jmc/jmc/rev/1a1a3bc8115b > > > > > > Apologies, > > > > On Mon, Jun 3, 2019 at 9:30 AM Marcus Hirt wrote: > > > > > > The idea is that it should still be possible to build JOverflow with a > > > JDK 8 not including JavaFX. The javafx packages should be downloaded > > > from Maven Central by default and exposed through the local p2 > > > repositiory. JOverflow is a pretty useful tool. Unless the patch Jie > > > has actually builds JOverflow, I think a closer look is warranted. > > > > > > Kind regards, > > > Marcus > > > > > > On Mon, Jun 3, 2019 at 3:21 PM Mario Torre wrote: > > > > > > > > To be fair, I also thought this was the case already, I remember Jie > > > > proposing a patch, but I may confuse with what we have in our > > > > downstream RPM (or maybe we just pushed the patch to 7.x and not to > > > > the 7.0 branch). > > > > > > > > Can you please assign this bug to Jie I think he may be able to > > > > backport the RPM patch into upstream. > > > > > > > > Cheers, > > > > Mario > > > > > > > > On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt wrote: > > > > > > > > > > The JavaFX bits are used by optional plug-ins, and they should be > > > > > downloaded from maven central when required. It should be possible to > > > > > build JMC without having JavaFX linked into the JDK. I actually > > > > > thought this was already the case. I will open an Issue. > > > > > > > > > > Kind regards, > > > > > Marcus > > > > > > > > > > On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: > > > > > > > > > > > > What system are you on? > > > > > > > > > > > > On RHEL 8 (and 7) for example there's no bundled JFX, while there is > > > > > > on Fedora. So if you are using a system where no JFX is present (any > > > > > > build of OpenJDK and any Oracle JDK since 11) then you either need to > > > > > > install it or patch the JFX bits out. > > > > > > > > > > > > I think the JFX bits should be optional on JMC but we're not there yet. > > > > > > > > > > > > Cheers, > > > > > > Mario > > > > > > > > > > > > On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > JMC 7.0.0-ga. > > > > > > > > > > > > > > I'm following what's in the README and the build fails for me at the > > > > > > > "mvn package" command from the JMC root directory: > > > > > > > > > > > > > > [ERROR] Failed to execute goal > > > > > > > org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > > > > > > > (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation > > > > > > > failure: Compilation failure: > > > > > > > [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > > > > > > > [ERROR] import javafx.application.Platform; > > > > > > > [ERROR] ^^^^^^ > > > > > > > > > > > > > > There are other 20 errors similar to this one. > > > > > > > > > > > > > > Ideas? > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > -- > > > > > > > Simone Bordet > > > > > > > --- > > > > > > > Finally, no matter how good the architecture and design are, > > > > > > > to deliver bug-free software with optimal performance and reliability, > > > > > > > the implementation technique must be flawless. Victoria Livschitz > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Mario Torre > > > > > > Associate Manager, Software Engineering > > > > > > Red Hat GmbH > > > > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > > > > > > > > > > > > -- > > > > Mario Torre > > > > Associate Manager, Software Engineering > > > > Red Hat GmbH > > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jkang at redhat.com Mon Jun 3 17:20:44 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 3 Jun 2019 13:20:44 -0400 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hey Simone, You can also edit the jmc.ini file to add or remove options that would be used when running 'jmc'. Or, this can be patched in source file so the jmc.ini that is generated on build has the arguments you'd prefer. The source should be: application/org.openjdk.jmc.rcp.product/jmc.product On Mon, Jun 3, 2019 at 1:11 PM Simone Bordet wrote: > > Hi, > > On Mon, Jun 3, 2019 at 1:46 PM Henrik Dafg?rd wrote: > > > > Hi Simone, > > > > The build should be runnable with a JDK8, this should be ensured by the "-XX:+IgnoreUnrecognizedVMOptions" flag to ignore the JDK9+ specific options. > > But I don't execute "java ..." so that I can add command line options. > > I execute "jmc" and that's it (and it picks a bunch of "java" command > line options from elsewhere). > > So if JMC can't be run out of the box with JDK 8 that's ok - just need > to know it. > It's weird that it requires JDK 8 to build (and a very specific > vendor), but then when you try to run it from the same terminal you > just built it, it does not start. > > However, at the end it's just some documentation problem and I got it running. > > Thanks! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Jun 3 17:26:34 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 3 Jun 2019 19:26:34 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hi, On Mon, Jun 3, 2019 at 6:53 PM Jie Kang wrote: > I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8 > without OpenJFX. My search shows that this was not backported to > jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently > remove all usages of OpenJFX, even the JOverflow plugin itself, when > building. Pardon my intrusion here, but so RedHat's JMC is not really the JMC from the official repository tag (e.g. 7.0.0-ga) but it's a different JMC with things removed and possibly things added? How do I know the differences between the two? -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From jkang at redhat.com Mon Jun 3 18:04:11 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 3 Jun 2019 14:04:11 -0400 Subject: Cannot build JMC In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 1:26 PM Simone Bordet wrote: > > Hi, > > On Mon, Jun 3, 2019 at 6:53 PM Jie Kang wrote: > > I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8 > > without OpenJFX. My search shows that this was not backported to > > jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently > > remove all usages of OpenJFX, even the JOverflow plugin itself, when > > building. > > Pardon my intrusion here, but so RedHat's JMC is not really the JMC > from the official repository tag (e.g. 7.0.0-ga) but it's a different > JMC with things removed and possibly things added? > How do I know the differences between the two? Hi, Right, so considering 'upstream' as the OpenJDK JMC community project, and downstreams as e.g. Red Hat, Oracle, or Azul. Red Hat does not have binary distributions of JMC. I do hope to work in the upstream community to have 'upstream' binary builds available, similar to AdoptOpenJDK builds of the JDK. For Red Hat, the currently available downstream release of JMC is in RHEL (Red hat Enterprise Linux) through the SCL (Software Collections) program under the package name 'rh-jmc-jmc'. This was made available March 13, 2019 in rhscl-3.2.z and is an early release of the upstream jmc/jmc7 repository, as at the time, there was no 7.0.0-ga tag. As you point out, there is little 'official' documentation on differences from the jmc7 upstream build. I guess this was missed on my part, sorry. Sources for RHEL packages are always made available somewhere. Here is a link to the spec and patches for rh-jmc-jmc [0]. [0] https://git.centos.org/rpms/rh-jmc-jmc/blob/c7/f/SOURCES I can say that it is as close to the upstream content as possible and that will always be my intent. It may include backports from upstream jmc -> jmc7 that upstream does not do in order to fix things for users, but I would be very surprised to see feature additions that are not upstream first. I do commit as best I can to the upstream first philosophy! The only difference of note at this time, in my opinion, is that it excludes all of the optional plugins (such as JOverflow as we do not support OpenJFX in RHEL). There are plans to include the other optional plugins on a case-by-case basis in future releases, and/or to provide users the ability to point to update sites at their own risk, similar to the Eclipse distributions in Fedora and RHEL. The RHEL release very closely mimics that of the Fedora release, so if you're interested in what updates to RHEL might look like, you can see the Fedora jmc package repository here [1], where you can see exactly what patches are carried (check branch 'jmc', and in a week or two, 'jmc7'). The spec file has comments with justifications for each patch (I sincerely hope). Some of these are obsolete as changes have been made to upstream that resolve the issue, such as the update to use javamail 1.6.x. Other changes will always be around as the build system requirements differ from upstream (offline only, dependencies from other rpms on the system, package *only* as an Eclipse RCP application so a number of modules need not be built, and so on and so forth). [1] https://src.fedoraproject.org/rpms/jmc For what it's worth, I am in the process of updating the Fedora JMC module with * updated 'latest' stream tracking the latest commit in jmc/jmc; I am probably going to update this once every 3 months, or maybe 6, kind of as time permits. * updated 'jmc7' stream tracking the jmc-7.0.0-ga tag in jmc/jm7: This will only update if jmc/jmc7 sees updates Afterwards, the patches applied will look very different. I hope this helps! P.s. It's entirely possible other downstream distributions differ from the upstream sources. Hopefully they will have documentation or even better, source code, available too! Regards, > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From jmatsuok at redhat.com Mon Jun 3 20:51:10 2019 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Mon, 03 Jun 2019 20:51:10 +0000 Subject: hg: jmc/jmc: JMC-6252: Method Profiling rule appears to be taking forever to evaluate Message-ID: <201906032051.x53KpAak029286@aojmv0008.oracle.com> Changeset: 7c0748da48ec Author: jmatsuoka Date: 2019-06-03 16:50 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/7c0748da48ec JMC-6252: Method Profiling rule appears to be taking forever to evaluate Summary: Resolved a race condition where rules were added to the queue without being consumed. Corrected JavaScript command execution order so UI is correctly updated. Reviewed-by: hdafgard Contributed-by: Kangcheng Xu ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultReportUi.java From marcus at hirt.se Mon Jun 3 22:03:40 2019 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 4 Jun 2019 00:03:40 +0200 Subject: Sv: jmc/jmc: JMC-6252: Method Profiling rule appears to be taking forever to evaluate In-Reply-To: <201906032051.x53KpAak029286@aojmv0008.oracle.com> References: <201906032051.x53KpAak029286@aojmv0008.oracle.com> Message-ID: <024701d51a58$33e04e40$9ba0eac0$@hirt.se> Woho! :) /M -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r jmatsuok at redhat.com Skickat: den 3 juni 2019 22:51 Till: jmc-dev at openjdk.java.net ?mne: hg: jmc/jmc: JMC-6252: Method Profiling rule appears to be taking forever to evaluate Changeset: 7c0748da48ec Author: jmatsuoka Date: 2019-06-03 16:50 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/7c0748da48ec JMC-6252: Method Profiling rule appears to be taking forever to evaluate Summary: Resolved a race condition where rules were added to the queue without being consumed. Corrected JavaScript command execution order so UI is correctly updated. Reviewed-by: hdafgard Contributed-by: Kangcheng Xu ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/fl ightrecorder/ui/overview/ResultReportUi.java From abrygin at azul.com Tue Jun 4 07:52:55 2019 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 4 Jun 2019 07:52:55 +0000 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Hello Marcus, > On Jun 3, 2019, at 8:14 PM, Marcus Hirt wrote: > > That depends. The plan is to resolve where to host update sites etc > for 7.1.0, so perhaps this not being back-ported to 7.0.0 is > acceptable. Oracle will be fine either way. You guys (Red Hat) exclude > it anyways. It would be if Azul needs this backport. Anyone from Azul > having a strong opinion on this? we use jdk8 with openjfx to build jmc7, so we do not need this backport. Thanks, Andrew > > Kind regards, > Marcus > > On Mon, Jun 3, 2019 at 6:52 PM Jie Kang wrote: >> >> Hi Marcus, >> >> I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8 >> without OpenJFX. My search shows that this was not backported to >> jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently >> remove all usages of OpenJFX, even the JOverflow plugin itself, when >> building. >> >> * I will setup a system to verify the situation with jmc/jmc7 repo and >> OpenJDK 8 and see if a backport would fix the issue. In the event that >> this does, would you like to see a backport request of JMC-6370 from >> me to jmc/jmc7? >> * I will also test building JOverflow with OpenJDK 8 not including >> JavaFX to verify the p2 work that was done in jmc/jmc. >> >> [1] >> https://bugs.openjdk.java.net/browse/JMC-6370 >> http://hg.openjdk.java.net/jmc/jmc/rev/1a1a3bc8115b >> >> >> Apologies, >> >> On Mon, Jun 3, 2019 at 9:30 AM Marcus Hirt wrote: >>> >>> The idea is that it should still be possible to build JOverflow with a >>> JDK 8 not including JavaFX. The javafx packages should be downloaded >>> from Maven Central by default and exposed through the local p2 >>> repositiory. JOverflow is a pretty useful tool. Unless the patch Jie >>> has actually builds JOverflow, I think a closer look is warranted. >>> >>> Kind regards, >>> Marcus >>> >>> On Mon, Jun 3, 2019 at 3:21 PM Mario Torre wrote: >>>> >>>> To be fair, I also thought this was the case already, I remember Jie >>>> proposing a patch, but I may confuse with what we have in our >>>> downstream RPM (or maybe we just pushed the patch to 7.x and not to >>>> the 7.0 branch). >>>> >>>> Can you please assign this bug to Jie I think he may be able to >>>> backport the RPM patch into upstream. >>>> >>>> Cheers, >>>> Mario >>>> >>>> On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt wrote: >>>>> >>>>> The JavaFX bits are used by optional plug-ins, and they should be >>>>> downloaded from maven central when required. It should be possible to >>>>> build JMC without having JavaFX linked into the JDK. I actually >>>>> thought this was already the case. I will open an Issue. >>>>> >>>>> Kind regards, >>>>> Marcus >>>>> >>>>> On Mon, Jun 3, 2019 at 11:43 AM Mario Torre wrote: >>>>>> >>>>>> What system are you on? >>>>>> >>>>>> On RHEL 8 (and 7) for example there's no bundled JFX, while there is >>>>>> on Fedora. So if you are using a system where no JFX is present (any >>>>>> build of OpenJDK and any Oracle JDK since 11) then you either need to >>>>>> install it or patch the JFX bits out. >>>>>> >>>>>> I think the JFX bits should be optional on JMC but we're not there yet. >>>>>> >>>>>> Cheers, >>>>>> Mario >>>>>> >>>>>> On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> JMC 7.0.0-ga. >>>>>>> >>>>>>> I'm following what's in the README and the build fails for me at the >>>>>>> "mvn package" command from the JMC root directory: >>>>>>> >>>>>>> [ERROR] Failed to execute goal >>>>>>> org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile >>>>>>> (default-compile) on project org.openjdk.jmc.javafx.osgi: Compilation >>>>>>> failure: Compilation failure: >>>>>>> [ERROR] /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] >>>>>>> [ERROR] import javafx.application.Platform; >>>>>>> [ERROR] ^^^^^^ >>>>>>> >>>>>>> There are other 20 errors similar to this one. >>>>>>> >>>>>>> Ideas? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> Simone Bordet >>>>>>> --- >>>>>>> Finally, no matter how good the architecture and design are, >>>>>>> to deliver bug-free software with optimal performance and reliability, >>>>>>> the implementation technique must be flawless. Victoria Livschitz >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mario Torre >>>>>> Associate Manager, Software Engineering >>>>>> Red Hat GmbH >>>>>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 >>>> >>>> >>>> >>>> -- >>>> 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 Tue Jun 4 07:55:01 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Tue, 4 Jun 2019 09:55:01 +0200 Subject: Cannot build JMC In-Reply-To: References: Message-ID: Thanks Andrew! Kind regards, Marcus On Tue, 4 Jun 2019 at 09:52, Andrew Brygin wrote: > Hello Marcus, > > > On Jun 3, 2019, at 8:14 PM, Marcus Hirt > wrote: > > > > That depends. The plan is to resolve where to host update sites etc > > for 7.1.0, so perhaps this not being back-ported to 7.0.0 is > > acceptable. Oracle will be fine either way. You guys (Red Hat) exclude > > it anyways. It would be if Azul needs this backport. Anyone from Azul > > having a strong opinion on this? > > we use jdk8 with openjfx to build jmc7, so we do not need this backport. > > Thanks, > Andrew > > > > > Kind regards, > > Marcus > > > > On Mon, Jun 3, 2019 at 6:52 PM Jie Kang wrote: > >> > >> Hi Marcus, > >> > >> I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8 > >> without OpenJFX. My search shows that this was not backported to > >> jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently > >> remove all usages of OpenJFX, even the JOverflow plugin itself, when > >> building. > >> > >> * I will setup a system to verify the situation with jmc/jmc7 repo and > >> OpenJDK 8 and see if a backport would fix the issue. In the event that > >> this does, would you like to see a backport request of JMC-6370 from > >> me to jmc/jmc7? > >> * I will also test building JOverflow with OpenJDK 8 not including > >> JavaFX to verify the p2 work that was done in jmc/jmc. > >> > >> [1] > >> https://bugs.openjdk.java.net/browse/JMC-6370 > >> http://hg.openjdk.java.net/jmc/jmc/rev/1a1a3bc8115b > >> > >> > >> Apologies, > >> > >> On Mon, Jun 3, 2019 at 9:30 AM Marcus Hirt > wrote: > >>> > >>> The idea is that it should still be possible to build JOverflow with a > >>> JDK 8 not including JavaFX. The javafx packages should be downloaded > >>> from Maven Central by default and exposed through the local p2 > >>> repositiory. JOverflow is a pretty useful tool. Unless the patch Jie > >>> has actually builds JOverflow, I think a closer look is warranted. > >>> > >>> Kind regards, > >>> Marcus > >>> > >>> On Mon, Jun 3, 2019 at 3:21 PM Mario Torre wrote: > >>>> > >>>> To be fair, I also thought this was the case already, I remember Jie > >>>> proposing a patch, but I may confuse with what we have in our > >>>> downstream RPM (or maybe we just pushed the patch to 7.x and not to > >>>> the 7.0 branch). > >>>> > >>>> Can you please assign this bug to Jie I think he may be able to > >>>> backport the RPM patch into upstream. > >>>> > >>>> Cheers, > >>>> Mario > >>>> > >>>> On Mon, Jun 3, 2019 at 2:11 PM Marcus Hirt > wrote: > >>>>> > >>>>> The JavaFX bits are used by optional plug-ins, and they should be > >>>>> downloaded from maven central when required. It should be possible to > >>>>> build JMC without having JavaFX linked into the JDK. I actually > >>>>> thought this was already the case. I will open an Issue. > >>>>> > >>>>> Kind regards, > >>>>> Marcus > >>>>> > >>>>> On Mon, Jun 3, 2019 at 11:43 AM Mario Torre > wrote: > >>>>>> > >>>>>> What system are you on? > >>>>>> > >>>>>> On RHEL 8 (and 7) for example there's no bundled JFX, while there is > >>>>>> on Fedora. So if you are using a system where no JFX is present (any > >>>>>> build of OpenJDK and any Oracle JDK since 11) then you either need > to > >>>>>> install it or patch the JFX bits out. > >>>>>> > >>>>>> I think the JFX bits should be optional on JMC but we're not there > yet. > >>>>>> > >>>>>> Cheers, > >>>>>> Mario > >>>>>> > >>>>>> On Mon, Jun 3, 2019 at 11:34 AM Simone Bordet < > simone.bordet at gmail.com> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> JMC 7.0.0-ga. > >>>>>>> > >>>>>>> I'm following what's in the README and the build fails for me at > the > >>>>>>> "mvn package" command from the JMC root directory: > >>>>>>> > >>>>>>> [ERROR] Failed to execute goal > >>>>>>> org.eclipse.tycho:tycho-compiler-plugin:1.4.0:compile > >>>>>>> (default-compile) on project org.openjdk.jmc.javafx.osgi: > Compilation > >>>>>>> failure: Compilation failure: > >>>>>>> [ERROR] > /home/simon/opensource/openjdk/jmc7/application/org.openjdk.jmc.javafx.osgi/src/main/java/org/openjdk/jmc/javafx/osgi/FXToolkit.java:[42] > >>>>>>> [ERROR] import javafx.application.Platform; > >>>>>>> [ERROR] ^^^^^^ > >>>>>>> > >>>>>>> There are other 20 errors similar to this one. > >>>>>>> > >>>>>>> Ideas? > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> -- > >>>>>>> Simone Bordet > >>>>>>> --- > >>>>>>> Finally, no matter how good the architecture and design are, > >>>>>>> to deliver bug-free software with optimal performance and > reliability, > >>>>>>> the implementation technique must be flawless. Victoria Livschitz > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Mario Torre > >>>>>> Associate Manager, Software Engineering > >>>>>> Red Hat GmbH > >>>>>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > >>>> > >>>> > >>>> > >>>> -- > >>>> 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 Jun 4 12:22:54 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Tue, 4 Jun 2019 08:22:54 -0400 Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context menu In-Reply-To: References: <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com> Message-ID: Hi everyone, On Thu, May 9, 2019 at 11:32 AM Mario Torre wrote: > Likewise! > > Cheers, > Mario > Last week Marcus reported that this functionality was not working on Windows [0], which also causes uitests to fail. I setup Eclipse on my home Windows machine and took a look into what was happening. In the original JMC-4466 patch, the intention was that hovering an item in the ChartCanvas would set the hovered item in a variable that could be found by the threads page remove thread action. This would allow for hideThread() to see where the hovered item should be removed from the list of threads. When the cursor exits the chart canvas, this hovered item variable would be reset [1], which is where the problem comes in. My oversight here was that mouseExit() gets called when using clicking a context menu item (in addition to simply moving the cursor off the chart). On my Linux machines, mouseExit() gets called *after* the hide thread action [2] occurs, so there isn't a problem. However, on Windows the mouseExit() gets called immediately after clicking a context menu action, and *before* hideThread() gets a chance to run, so the action tries to remove a null thread and the chart remains unchanged. webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/fix-4466-0/ The proposed fix here adds a conditional to the mouseExit() to verify that the hovered item value only gets reset if the cursor it outside the bounds of the chart canvas. Additionally, there appears to an issue with the focusing of the chart and table when running uitests. As a result, the test fails to select the 7 threads from the table and hide them from the chart. It's interesting because doesn't happen on my F29 machine, but I have seen it in Fedora 30 and on my Windows machine. The proposed fix for this is to ensure that JMC has focus when the mouse & keyboard actions are taking place. I'm also curious if this focusing issue could be related to JMC-6488, where the uitests fail to open the preferences dialog. I see this on Windows (but not all the time), and when it occurs I can usually correct it by manually hovering my mouse over top of JMC.. but this will require further investigation. Thoughts? Cheers, Alex [0] https://bugs.openjdk.java.net/browse/JMC-4466 [1] http://hg.openjdk.java.net/jmc/jmc/file/e3ea3697d0b3/application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/misc/ChartCanvas.java#l156 [2] http://hg.openjdk.java.net/jmc/jmc/file/e3ea3697d0b3/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java#l235 [3] https://bugs.openjdk.java.net/browse/JMC-6488 > On Mon, May 6, 2019 at 7:34 AM Guru wrote: > > > > +1, Looks good to me. > > > > Thanks > > Guru > > > On 04-May-2019, at 1:54 AM, Alex Macdonald > wrote: > > > > > > Hi, > > > > > > On Wed, Apr 17, 2019 at 12:33 PM Alex Macdonald > wrote: > > > Hi Guru, > > > > > > On Fri, Apr 12, 2019 at 2:04 PM Guru guru.hb at oracle.com>> wrote: > > > Hi Alex, > > > > > > I have tested your patch (Works as expected) and Looks good (except > for Mario?s Comment for which you are addressing the same). > > > > > > +nit : > > > Most of the places the some of the declaration is in alphabetical > order and for some reason over the time its not. Wish we could spend little > more time to keep the uniformity going ahead. > > > Please re-arange the lines accordingly. Find the same example for one > of the file and few more which needs to be taken care of. > > > + Messages.java : > > > 492 public static String ThreadsPage_HIDE_THREAD_ACTION; > > > 493 public static String > ThreadsPage_RESET_CHART_TO_SELECTION_ACTION; > > > 494 public static String ThreadsPage_EDIT_LANES; > > > > > > Could have been like below > > > 491 public static String ThreadDumpsPage_PAGE_NAME; > > > 492 public static String ThreadsPage_EDIT_LANES; > > > 493 public static String ThreadsPage_HIDE_THREAD_ACTION; > > > 494 public static String ThreadsPage_LANE_TOOLTIP_TITLE; > > > 495 public static String ThreadsPage_NAME; > > > 496 public static String > ThreadsPage_RESET_CHART_TO_SELECTION_ACTION; > > > 497 public static String TlabPage_PAGE_NAME; > > > > > > Few more below which can be also re-aligned > > > > > > + flightrecorder/ui/messages/internal/messages.properties > > > + ui/charts/messages.properties > > > + MCJemmyBase.java > > > 77 import org.jemmy.interfaces.Mouse.MouseButtons; > > > > > > + ThreadsPage.java: > > > comment "Adds the hide thread and reset chart actions to the context > menu" > > > Please update some thing like or a better one. > > > "Context menu will be udpated with thread which needs to be hiden as > well as resets the chart action." > > > > > > "the point at which to right-click and open the context menu" --> > origin point of context (right-click) > > > > > > ChartCanvas.java : > > > Please change the order of getter/setters followed by reset i.e > > > (1) getActiveScopeName, (2) setActiveScopeName and (3) > resetActiveScopeName instead of (1), (3) and (2). > > > > > > Great, thank you for the review! I've addressed the formatting issues > and have an updated webrev for this patch. > > > > > > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ < > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/> [6] > > > > > > Previously I used string equivalence to determine which thread lane to > hide, however as Mario pointed out this would not work in the cases where > multiple threads share the same name. The rendered row on the chart does > not contain information regarding the source material (other than it's > name), so I've added an attribute that will hold the IMCThread information > so when the lane is hovered the IMCThread objects can be checked for > equivalence instead. Let me know what you think about this approach. > > > > > > I've updated the patch to add a couple more assertions to one of the > unit tests. Please let me know what you think. > > > > > > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ < > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/> [7] > > > Travis CI Build: https://travis-ci.org/aptmac/jmc-qa/builds/527928758 > [8] > > > > > > > > > > > > Thanks, > > > Guru > > > > > >> On 12-Apr-2019, at 7:58 PM, Alex Macdonald > wrote: > > >> > > >> On Fri, Apr 12, 2019 at 10:19 AM Mario Torre > wrote: > > >> > > >>> On Fri, 2019-04-05 at 13:28 -0400, Alex Macdonald wrote: > > >>>> Hi, > > >>>> > > >>>> The following webrev [0] addresses issue JMC-4466 [1], in which the > > >>>> user > > >>>> should be able to hide threads from the thread chart using context > > >>>> menu > > >>>> actions. > > >>>> > > >>>> This patch adds functionality to the context menu to hide threads > > >>>> from the > > >>>> chart. Additionally, I thought there should be an option to restore > > >>>> the > > >>>> chart to the current selection to "unhide" the threads, so I've also > > >>>> included a menu item that does such that. I've included a GIF [2] to > > >>>> demonstrate how the actions work (note the gif was made before I > > >>>> touched up > > >>>> some of the strings, so some of the wording may be off). > > >>>> > > >>>> The "hide thread" action is only enabled while there are threads > that > > >>>> can > > >>>> be hidden, and the "reset chart" option is only enabled while the > > >>>> chart has > > >>>> been modified (i.e., has thread(s) hidden) [3][4]. I've also > included > > >>>> uitests that perform the new actions on the chart, and verify the > > >>>> results > > >>>> based on the enablement values of the menu items. > > >>>> > > >>>> Lastly, I've tested these tests and changes locally on my machine > and > > >>>> using > > >>>> Travis [5], but these are both Linux environments and it would be > > >>>> nice to > > >>>> make sure there are no issues on Windows / Mac. > > >>>> > > >>>> Thoughts? > > >>>> > > >>>> Cheers, > > >>>> > > >>>> Alex > > >>>> > > >>>> [0] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/ < > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/> > > >>>> [1] https://bugs.openjdk.java.net/browse/JMC-4466 < > https://bugs.openjdk.java.net/browse/JMC-4466> > > >>>> [2] https://imgur.com/BkeXkVX > > >>>> [3] https://imgur.com/dhuTmkE > > >>>> [4] https://imgur.com/W7NzOj7 > > >>>> [5] https://travis-ci.org/aptmac/jmc-qa/builds/516268811 < > https://travis-ci.org/aptmac/jmc-qa/builds/516268811> > > >>> > > >>> Hi Alex, > > >>> > > >>> The patch looks generally good, the only question I have is regarding > > >>> the thread selection by name: > > >>> > > >>> + private int indexOfThreadName(String name) { > > >>> + for (int i = 0; i < this.threadRows.size() && name != null; i++) > { > > >>> + if (this.threadRows.get(i) instanceof QuantitySpanRenderer) { > > >>> + if (name.equals(((QuantitySpanRenderer) > > >>> + this.threadRows.get(i)).getName())) { > > >>> + return i; > > >>> + } > > >>> + } > > >>> + } > > >>> + return -1; > > >>> + } > > >>> > > >>> What happens when two threads have the same name? This will make > > >>> disappear the very fist one with this name encountered, not > necessarily > > >>> the one the user clicked on, isn't it? > > >>> > > >> > > >> Ah good call, I hadn't thought about that case. I'll come back with a > > >> revised webrev. > > >> > > >> > > >>> > > >>> Cheers, > > >>> Mario > > >>> -- > > >>> Mario Torre > > >>> Associate Manager, Software Engineering > > >>> Red Hat GmbH > > > >>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > >>> > > >> > > >> Thanks, > > >> > > >> Alex > > > > > > > > > Cheers, > > > > > > Alex > > > > > > [6] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ < > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/> > > > > > > Cheers, > > > > > > Alex > > > > > > [7] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ < > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/> > > > [8] https://travis-ci.org/aptmac/jmc-qa/builds/527928758 < > https://travis-ci.org/aptmac/jmc-qa/builds/527928758> > > > > -- > 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 Jun 4 16:37:59 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Tue, 4 Jun 2019 12:37:59 -0400 Subject: RFR: JMC-6493 - Update Jemmy to version 2.0.0 Message-ID: Hi, The following webrev [0] addresses JMC-6493, which updates Jemmy to the latest current version. Yesterday an update went through to Jemmy [1] which updates the version from 1.0.2 to 2.0.0 and adjusts a couple of the package names. As a result, some of the paths we have in JMC are now out of date and require updating. Thoughts? Cheers, Alex [0] http://cr.openjdk.java.net/~aptmac/JMC-6493/webrev.00 [1] https://hg.openjdk.java.net/code-tools/jemmy/v3/rev/c1848648774f From almacdon at redhat.com Tue Jun 4 18:06:46 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Tue, 4 Jun 2019 14:06:46 -0400 Subject: [PATCH] JMC-6485 *.jfc" file extension set as default on Open File In-Reply-To: References: Message-ID: Hi Jessye, On Thu, May 23, 2019 at 1:58 PM Jessye Coleman Shapiro wrote: > On Thu, May 23, 2019 at 12:10 PM Jessye Coleman Shapiro < > jescolem at redhat.com> > wrote: > > > Hello, > > > > This patch fixes the JMC-6485 bug where file extensions in the Open File > > pop-up were being set to ".jfc" instead of "*" by default [0]. This was > > an eclipse FileDialog bug and was fixed in the Eclipse 4.10 release in > > December 2018 [1]. This patch reverts the JMC-6151 workaround [2] that > was > > created for this FileDialog bug and was mentioned in JMC-6171 [3]. > > > This looks good to me. > > See the attached patch bellow. > It's not a concern at the moment (and doesn't require a new patch IMO), but when you go to export the patch make sure to change the header title from JMC-6151 to JMC-6171. > > > > Thank you! > > > > [0] https://bugs.openjdk.java.net/browse/JMC-6485 > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540164 > > [2] https://bugs.openjdk.java.net/browse/JMC-6151 > > [3] https://bugs.openjdk.java.net/browse/JMC-6171 > > > > > > > To clarify, this patch addresses JMC-6171 with comment to revert JMC-6151 > and it does not fix JMC-6485, though it is related. > > Sorry if there was any confusion. > > Jessye > Cheers, Alex From jescolem at redhat.com Tue Jun 4 18:33:47 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Tue, 4 Jun 2019 14:33:47 -0400 Subject: [PATCH] JMC-6485 *.jfc" file extension set as default on Open File In-Reply-To: References: Message-ID: Hi Alex, Thanks - I will be sure to change the header title. Jessye On Tue, Jun 4, 2019 at 2:07 PM Alex Macdonald wrote: > Hi Jessye, > > On Thu, May 23, 2019 at 1:58 PM Jessye Coleman Shapiro < > jescolem at redhat.com> wrote: > >> On Thu, May 23, 2019 at 12:10 PM Jessye Coleman Shapiro < >> jescolem at redhat.com> >> wrote: >> >> > Hello, >> > >> > This patch fixes the JMC-6485 bug where file extensions in the Open File >> > pop-up were being set to ".jfc" instead of "*" by default [0]. This >> was >> > an eclipse FileDialog bug and was fixed in the Eclipse 4.10 release in >> > December 2018 [1]. This patch reverts the JMC-6151 workaround [2] that >> was >> > created for this FileDialog bug and was mentioned in JMC-6171 [3]. >> > >> > > This looks good to me. > > >> > See the attached patch bellow. >> > > It's not a concern at the moment (and doesn't require a new patch IMO), > but when you go to export the patch make sure to change the header title > from JMC-6151 to JMC-6171. > > >> > >> > Thank you! >> > >> > [0] https://bugs.openjdk.java.net/browse/JMC-6485 >> > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540164 >> > [2] https://bugs.openjdk.java.net/browse/JMC-6151 >> > [3] https://bugs.openjdk.java.net/browse/JMC-6171 >> > >> > >> > >> To clarify, this patch addresses JMC-6171 with comment to revert JMC-6151 >> and it does not fix JMC-6485, though it is related. >> >> Sorry if there was any confusion. >> >> Jessye >> > > Cheers, > > Alex > From jmatsuok at redhat.com Tue Jun 4 20:03:00 2019 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Tue, 4 Jun 2019 16:03:00 -0400 Subject: [PATCH] JMC-6485 *.jfc" file extension set as default on Open File In-Reply-To: References: Message-ID: Hi Jessye, Looks good! I'll push this for you. Cheers, - Josh On Tue, Jun 4, 2019 at 2:34 PM Jessye Coleman Shapiro wrote: > Hi Alex, > > Thanks - I will be sure to change the header title. > > Jessye > > On Tue, Jun 4, 2019 at 2:07 PM Alex Macdonald wrote: > > > Hi Jessye, > > > > On Thu, May 23, 2019 at 1:58 PM Jessye Coleman Shapiro < > > jescolem at redhat.com> wrote: > > > >> On Thu, May 23, 2019 at 12:10 PM Jessye Coleman Shapiro < > >> jescolem at redhat.com> > >> wrote: > >> > >> > Hello, > >> > > >> > This patch fixes the JMC-6485 bug where file extensions in the Open > File > >> > pop-up were being set to ".jfc" instead of "*" by default [0]. This > >> was > >> > an eclipse FileDialog bug and was fixed in the Eclipse 4.10 release in > >> > December 2018 [1]. This patch reverts the JMC-6151 workaround [2] > that > >> was > >> > created for this FileDialog bug and was mentioned in JMC-6171 [3]. > >> > > >> > > > > This looks good to me. > > > > > >> > See the attached patch bellow. > >> > > > > It's not a concern at the moment (and doesn't require a new patch IMO), > > but when you go to export the patch make sure to change the header title > > from JMC-6151 to JMC-6171. > > > > > >> > > >> > Thank you! > >> > > >> > [0] https://bugs.openjdk.java.net/browse/JMC-6485 > >> > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540164 > >> > [2] https://bugs.openjdk.java.net/browse/JMC-6151 > >> > [3] https://bugs.openjdk.java.net/browse/JMC-6171 > >> > > >> > > >> > > >> To clarify, this patch addresses JMC-6171 with comment to revert > JMC-6151 > >> and it does not fix JMC-6485, though it is related. > >> > >> Sorry if there was any confusion. > >> > >> Jessye > >> > > > > Cheers, > > > > Alex > > > From kdobson at redhat.com Tue Jun 4 20:44:27 2019 From: kdobson at redhat.com (Ken Dobson) Date: Tue, 4 Jun 2019 16:44:27 -0400 Subject: JMC-5368: Clear Stacktrace View when editor is closed Message-ID: Here's a small patch that clears the stacktrace view when all JfrEditors are closed rather than persisting the most recent stacktrace. Bug ID: https://bugs.openjdk.java.net/browse/JMC-5368 Webrev: http://cr.openjdk.java.net/~kdobson/JMC-5368/webrev/ Thanks, Ken Dobson From marcus.hirt at datadoghq.com Wed Jun 5 11:32:05 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Wed, 5 Jun 2019 13:32:05 +0200 Subject: JMC-5368: Clear Stacktrace View when editor is closed In-Reply-To: References: Message-ID: LGTM! :) Kind regards, Marcus On Tue, Jun 4, 2019 at 10:44 PM Ken Dobson wrote: > Here's a small patch that clears the stacktrace view when all JfrEditors > are closed rather than persisting the most recent stacktrace. > > Bug ID: https://bugs.openjdk.java.net/browse/JMC-5368 > Webrev: http://cr.openjdk.java.net/~kdobson/JMC-5368/webrev/ > > Thanks, > > Ken Dobson > From almacdon at redhat.com Wed Jun 5 13:51:44 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Wed, 5 Jun 2019 09:51:44 -0400 Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency In-Reply-To: References: Message-ID: 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. > > > Regards, > Cheers, Alex [0] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2cf5bec8d8ba From jmatsuok at redhat.com Wed Jun 5 14:19:40 2019 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Wed, 05 Jun 2019 14:19:40 +0000 Subject: hg: jmc/jmc: JMC-6171: (Mac OSX) FileDialog.setfilterIndex() doesn't work as expected Message-ID: <201906051419.x55EJfEV028130@aojmv0008.oracle.com> Changeset: 2d0b17897390 Author: jmatsuoka Date: 2019-06-05 10:18 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/2d0b17897390 JMC-6171: (Mac OSX) FileDialog.setfilterIndex() doesn't work as expected Summary: Revert workaround for the file dialog bug on Mac OS X, which is now fixed in the Eclipse 4.10 release Reviewed-by: aptmac, jmatsuoka Contributed-by: Jessye Coleman-Shapiro ! application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java From hdafgard at gmail.com Wed Jun 5 14:54:27 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Wed, 5 Jun 2019 16:54:27 +0200 Subject: JMC-5368: Clear Stacktrace View when editor is closed In-Reply-To: References: Message-ID: Looks good to me as well, the only note I'd give is that if we're strictly following the formatting style the "else if" statement should not be on a new line. Cheers, Henrik Dafg?rd On Wed, 5 Jun 2019 at 13:32, Marcus Hirt wrote: > LGTM! :) > > Kind regards, > Marcus > > On Tue, Jun 4, 2019 at 10:44 PM Ken Dobson wrote: > > > Here's a small patch that clears the stacktrace view when all JfrEditors > > are closed rather than persisting the most recent stacktrace. > > > > Bug ID: https://bugs.openjdk.java.net/browse/JMC-5368 > > Webrev: http://cr.openjdk.java.net/~kdobson/JMC-5368/webrev/ > > > > Thanks, > > > > Ken Dobson > > > From jmatsuok at redhat.com Wed Jun 5 15:05:33 2019 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Wed, 05 Jun 2019 15:05:33 +0000 Subject: hg: jmc/jmc: 5368: Clear stacktrace view when editor is closed Message-ID: <201906051505.x55F5XPw028511@aojmv0008.oracle.com> Changeset: c565a2a4bf74 Author: kdobson Date: 2019-06-05 10:24 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/c565a2a4bf74 5368: Clear stacktrace view when editor is closed Summary: Stacktrace clears on close Reviewed by: hirt ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java From erik.gahlin at oracle.com Wed Jun 5 16:18:28 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 5 Jun 2019 18:18:28 +0200 Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency In-Reply-To: References: Message-ID: Frequency can also be used in combination with DataAmount. For example, the Network Utilization event can have a rate of 100 Mbps using the annotations @Frequency @DataAmount(DataAmount.BITS) in combination. I am thinking of adding two units, Frequency.HERTZ and Frequency.PER_SECOND. Question is, what should be the default? I'm leaning towards PER_SECOND as it seems more common. This is not for JDK 13, as it requires a CSR request and some bake time. Erik > 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. > > >> >> Regards, >> > Cheers, > > Alex > > [0] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2cf5bec8d8ba From jkang at redhat.com Wed Jun 5 16:47:55 2019 From: jkang at redhat.com (Jie Kang) Date: Wed, 5 Jun 2019 12:47:55 -0400 Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency In-Reply-To: References: Message-ID: On Wed, Jun 5, 2019 at 12:21 PM Erik Gahlin wrote: > > Frequency can also be used in combination with DataAmount. > > For example, the Network Utilization event can have a rate of 100 Mbps > using the annotations @Frequency @DataAmount(DataAmount.BITS) in > combination. For what it's worth, JMC-6348 [1] is an open issue for supporting multiple content types such as in the NetworkUtilization event. I took a brief look in the past and I expect work on it in the next few months but not likely from myself, unfortunately. [1] https://bugs.openjdk.java.net/browse/JMC-6438 > > I am thinking of adding two units, Frequency.HERTZ and > Frequency.PER_SECOND. I'm a little confused of the difference between the two; isn't Hertz unit s^-1, also "per second"? Regards, > > Question is, what should be the default? > > I'm leaning towards PER_SECOND as it seems more common. This is not for > JDK 13, as it requires a CSR request and some bake time. > > Erik > > > 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. > > > > > >> > >> Regards, > >> > > Cheers, > > > > Alex > > > > [0] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2cf5bec8d8ba > > From erik.gahlin at oracle.com Thu Jun 6 09:18:14 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 6 Jun 2019 11:18:14 +0200 Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency In-Reply-To: References: Message-ID: <8ac32f83-653a-0f43-26fb-138dca1b00dd@oracle.com> Den 05/06/19 kl. 18:47, skrev Jie Kang: > On Wed, Jun 5, 2019 at 12:21 PM Erik Gahlin wrote: >> Frequency can also be used in combination with DataAmount. >> >> For example, the Network Utilization event can have a rate of 100 Mbps >> using the annotations @Frequency @DataAmount(DataAmount.BITS) in >> combination. > For what it's worth, JMC-6348 [1] is an open issue for supporting > multiple content types such as in the NetworkUtilization event. I took > a brief look in the past and I expect work on it in the next few > months but not likely from myself, unfortunately. > > [1] https://bugs.openjdk.java.net/browse/JMC-6438 > >> I am thinking of adding two units, Frequency.HERTZ and >> Frequency.PER_SECOND. > I'm a little confused of the difference between the two; isn't Hertz > unit s^-1, also "per second"? "unit" was perhaps not the right word, but 1000 with @Frequency("HERTZ") would result in "1 kHz" while @Frequency("PER_SECOND") would become 1 k/s", "1000 kps" or perhaps "1000 /s" The first form could be used with CPUTimeStampCounter and the second form would work well with ExceptionStatistics or ThreadContextSwitchRate. DIdn't know about the other open issue, so combinations is perhaps best done best done in that enhancement. Erik > > >> Question is, what should be the default? >> >> I'm leaning towards PER_SECOND as it seems more common. This is not for >> JDK 13, as it requires a CSR request and some bake time. >> >> Erik >> >>> 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. >>> >>> >>>> Regards, >>>> >>> Cheers, >>> >>> Alex >>> >>> [0] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2cf5bec8d8ba >> From marcus at hirt.se Fri Jun 7 13:14:39 2019 From: marcus at hirt.se (Marcus Hirt) Date: Fri, 7 Jun 2019 15:14:39 +0200 Subject: Review request for JMC-6497: Adding missing license headers Message-ID: <001e01d51d32$f6791b80$e36b5280$@hirt.se> Hi all, Please review this fix to add missing license headers. Jira: https://bugs.openjdk.java.net/browse/JMC-6497 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6497/webrev.0/ Kind regards, Marcus From neugens at redhat.com Fri Jun 7 13:19:00 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 7 Jun 2019 15:19:00 +0200 Subject: Review request for JMC-6497: Adding missing license headers In-Reply-To: <001e01d51d32$f6791b80$e36b5280$@hirt.se> References: <001e01d51d32$f6791b80$e36b5280$@hirt.se> Message-ID: Approved, and thanks! Cheers, Mario On Fri, Jun 7, 2019 at 3:15 PM Marcus Hirt wrote: > > Hi all, > > > > Please review this fix to add missing license headers. > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-6497 > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6497/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 hdafgard at gmail.com Fri Jun 7 13:19:42 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Fri, 7 Jun 2019 15:19:42 +0200 Subject: Review request for JMC-6497: Adding missing license headers In-Reply-To: <001e01d51d32$f6791b80$e36b5280$@hirt.se> References: <001e01d51d32$f6791b80$e36b5280$@hirt.se> Message-ID: Ship it! Cheers, Henrik Dafg?rd On Fri, 7 Jun 2019 at 15:15, Marcus Hirt wrote: > Hi all, > > > > Please review this fix to add missing license headers. > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-6497 > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6497/webrev.0/ > > > > Kind regards, > > Marcus > > From neugens at redhat.com Fri Jun 7 13:21:06 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 7 Jun 2019 15:21:06 +0200 Subject: Review request for JMC-6497: Adding missing license headers In-Reply-To: References: <001e01d51d32$f6791b80$e36b5280$@hirt.se> Message-ID: Actually, a minor back thought, the first line Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. Shouldn't that read 2019 only? Being a new file? Cheers, Mario On Fri, Jun 7, 2019 at 3:19 PM Mario Torre wrote: > > Approved, and thanks! > > Cheers, > Mario > > On Fri, Jun 7, 2019 at 3:15 PM Marcus Hirt wrote: > > > > Hi all, > > > > > > > > Please review this fix to add missing license headers. > > > > > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-6497 > > > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6497/webrev.0/ > > > > > > > > Kind regards, > > > > Marcus > > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus at hirt.se Fri Jun 7 13:29:39 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Fri, 07 Jun 2019 13:29:39 +0000 Subject: hg: jmc/jmc: JMC-6497: Adding missing license header Message-ID: <201906071329.x57DTdgD002692@aojmv0008.oracle.com> Changeset: c333d40a4556 Author: hirt Date: 2019-06-07 15:29 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/c333d40a4556 JMC-6497: Adding missing license header Reviewed-by: neugens, hdafgard ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/exceptions/FatalErrorRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/FullGcRule.java From marcus at hirt.se Fri Jun 7 13:37:50 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Fri, 07 Jun 2019 13:37:50 +0000 Subject: hg: jmc/jmc7: JMC-6498: Adding license header (backport of JMC-6497) Message-ID: <201906071337.x57Dbo3U008048@aojmv0008.oracle.com> Changeset: 6be1a897a17b Author: hirt Date: 2019-06-07 15:34 +0200 URL: http://hg.openjdk.java.net/jmc/jmc7/rev/6be1a897a17b JMC-6498: Adding license header (backport of JMC-6497) Reviewed-by: neugens, hdafgard ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/exceptions/FatalErrorRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/FullGcRule.java From almacdon at redhat.com Fri Jun 7 15:57:29 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Fri, 7 Jun 2019 11:57:29 -0400 Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context menu In-Reply-To: References: <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com> Message-ID: On Tue, Jun 4, 2019 at 8:35 AM Marcus Hirt wrote: > Hi Alex, > > Thank you for looking into this. Looks good to me! > Great, thanks for the review! I'll push this momentarily. > > Kind regards, > Marcus > > On Tue, Jun 4, 2019 at 2:23 PM Alex Macdonald wrote: > >> Hi everyone, >> >> On Thu, May 9, 2019 at 11:32 AM Mario Torre wrote: >> >> > Likewise! >> > >> > Cheers, >> > Mario >> > >> >> Last week Marcus reported that this functionality was not working on >> Windows [0], which also causes uitests to fail. >> >> I setup Eclipse on my home Windows machine and took a look into what was >> happening. In the original JMC-4466 patch, the intention was that hovering >> an item in the ChartCanvas would set the hovered item in a variable that >> could be found by the threads page remove thread action. This would allow >> for hideThread() to see where the hovered item should be removed from the >> list of threads. When the cursor exits the chart canvas, this hovered item >> variable would be reset [1], which is where the problem comes in. My >> oversight here was that mouseExit() gets called when using clicking a >> context menu item (in addition to simply moving the cursor off the chart). >> On my Linux machines, mouseExit() gets called *after* the hide thread >> action [2] occurs, so there isn't a problem. However, on Windows the >> mouseExit() gets called immediately after clicking a context menu action, >> and *before* hideThread() gets a chance to run, so the action tries to >> remove a null thread and the chart remains unchanged. >> >> webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/fix-4466-0/ >> >> The proposed fix here adds a conditional to the mouseExit() to verify that >> the hovered item value only gets reset if the cursor it outside the bounds >> of the chart canvas. >> >> Additionally, there appears to an issue with the focusing of the chart and >> table when running uitests. As a result, the test fails to select the 7 >> threads from the table and hide them from the chart. It's interesting >> because doesn't happen on my F29 machine, but I have seen it in Fedora 30 >> and on my Windows machine. The proposed fix for this is to ensure that JMC >> has focus when the mouse & keyboard actions are taking place. I'm also >> curious if this focusing issue could be related to JMC-6488, where the >> uitests fail to open the preferences dialog. I see this on Windows (but >> not >> all the time), and when it occurs I can usually correct it by manually >> hovering my mouse over top of JMC.. but this will require further >> investigation. >> >> Thoughts? >> >> Cheers, >> >> Alex >> >> [0] https://bugs.openjdk.java.net/browse/JMC-4466 >> [1] >> >> http://hg.openjdk.java.net/jmc/jmc/file/e3ea3697d0b3/application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/misc/ChartCanvas.java#l156 >> [2] >> >> http://hg.openjdk.java.net/jmc/jmc/file/e3ea3697d0b3/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java#l235 >> [3] https://bugs.openjdk.java.net/browse/JMC-6488 >> >> >> > On Mon, May 6, 2019 at 7:34 AM Guru wrote: >> > > >> > > +1, Looks good to me. >> > > >> > > Thanks >> > > Guru >> > > > On 04-May-2019, at 1:54 AM, Alex Macdonald >> > wrote: >> > > > >> > > > Hi, >> > > > >> > > > On Wed, Apr 17, 2019 at 12:33 PM Alex Macdonald < >> almacdon at redhat.com >> > > wrote: >> > > > Hi Guru, >> > > > >> > > > On Fri, Apr 12, 2019 at 2:04 PM Guru > > guru.hb at oracle.com>> wrote: >> > > > Hi Alex, >> > > > >> > > > I have tested your patch (Works as expected) and Looks good (except >> > for Mario?s Comment for which you are addressing the same). >> > > > >> > > > +nit : >> > > > Most of the places the some of the declaration is in alphabetical >> > order and for some reason over the time its not. Wish we could spend >> little >> > more time to keep the uniformity going ahead. >> > > > Please re-arange the lines accordingly. Find the same example for >> one >> > of the file and few more which needs to be taken care of. >> > > > + Messages.java : >> > > > 492 public static String ThreadsPage_HIDE_THREAD_ACTION; >> > > > 493 public static String >> > ThreadsPage_RESET_CHART_TO_SELECTION_ACTION; >> > > > 494 public static String ThreadsPage_EDIT_LANES; >> > > > >> > > > Could have been like below >> > > > 491 public static String ThreadDumpsPage_PAGE_NAME; >> > > > 492 public static String ThreadsPage_EDIT_LANES; >> > > > 493 public static String ThreadsPage_HIDE_THREAD_ACTION; >> > > > 494 public static String ThreadsPage_LANE_TOOLTIP_TITLE; >> > > > 495 public static String ThreadsPage_NAME; >> > > > 496 public static String >> > ThreadsPage_RESET_CHART_TO_SELECTION_ACTION; >> > > > 497 public static String TlabPage_PAGE_NAME; >> > > > >> > > > Few more below which can be also re-aligned >> > > > >> > > > + flightrecorder/ui/messages/internal/messages.properties >> > > > + ui/charts/messages.properties >> > > > + MCJemmyBase.java >> > > > 77 import org.jemmy.interfaces.Mouse.MouseButtons; >> > > > >> > > > + ThreadsPage.java: >> > > > comment "Adds the hide thread and reset chart actions to the >> context >> > menu" >> > > > Please update some thing like or a better one. >> > > > "Context menu will be udpated with thread which needs to be hiden >> as >> > well as resets the chart action." >> > > > >> > > > "the point at which to right-click and open the context menu" --> >> > origin point of context (right-click) >> > > > >> > > > ChartCanvas.java : >> > > > Please change the order of getter/setters followed by reset i.e >> > > > (1) getActiveScopeName, (2) setActiveScopeName and (3) >> > resetActiveScopeName instead of (1), (3) and (2). >> > > > >> > > > Great, thank you for the review! I've addressed the formatting >> issues >> > and have an updated webrev for this patch. >> > > > >> > > > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ < >> > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/> [6] >> > > > >> > > > Previously I used string equivalence to determine which thread lane >> to >> > hide, however as Mario pointed out this would not work in the cases >> where >> > multiple threads share the same name. The rendered row on the chart does >> > not contain information regarding the source material (other than it's >> > name), so I've added an attribute that will hold the IMCThread >> information >> > so when the lane is hovered the IMCThread objects can be checked for >> > equivalence instead. Let me know what you think about this approach. >> > > > >> > > > I've updated the patch to add a couple more assertions to one of the >> > unit tests. Please let me know what you think. >> > > > >> > > > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ < >> > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/> [7] >> > > > Travis CI Build: >> https://travis-ci.org/aptmac/jmc-qa/builds/527928758 >> > [8] >> > > > >> > > > >> > > > >> > > > Thanks, >> > > > Guru >> > > > >> > > >> On 12-Apr-2019, at 7:58 PM, Alex Macdonald > > > wrote: >> > > >> >> > > >> On Fri, Apr 12, 2019 at 10:19 AM Mario Torre > > > wrote: >> > > >> >> > > >>> On Fri, 2019-04-05 at 13:28 -0400, Alex Macdonald wrote: >> > > >>>> Hi, >> > > >>>> >> > > >>>> The following webrev [0] addresses issue JMC-4466 [1], in which >> the >> > > >>>> user >> > > >>>> should be able to hide threads from the thread chart using >> context >> > > >>>> menu >> > > >>>> actions. >> > > >>>> >> > > >>>> This patch adds functionality to the context menu to hide threads >> > > >>>> from the >> > > >>>> chart. Additionally, I thought there should be an option to >> restore >> > > >>>> the >> > > >>>> chart to the current selection to "unhide" the threads, so I've >> also >> > > >>>> included a menu item that does such that. I've included a GIF >> [2] to >> > > >>>> demonstrate how the actions work (note the gif was made before I >> > > >>>> touched up >> > > >>>> some of the strings, so some of the wording may be off). >> > > >>>> >> > > >>>> The "hide thread" action is only enabled while there are threads >> > that >> > > >>>> can >> > > >>>> be hidden, and the "reset chart" option is only enabled while the >> > > >>>> chart has >> > > >>>> been modified (i.e., has thread(s) hidden) [3][4]. I've also >> > included >> > > >>>> uitests that perform the new actions on the chart, and verify the >> > > >>>> results >> > > >>>> based on the enablement values of the menu items. >> > > >>>> >> > > >>>> Lastly, I've tested these tests and changes locally on my machine >> > and >> > > >>>> using >> > > >>>> Travis [5], but these are both Linux environments and it would be >> > > >>>> nice to >> > > >>>> make sure there are no issues on Windows / Mac. >> > > >>>> >> > > >>>> Thoughts? >> > > >>>> >> > > >>>> Cheers, >> > > >>>> >> > > >>>> Alex >> > > >>>> >> > > >>>> [0] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/ < >> > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/> >> > > >>>> [1] https://bugs.openjdk.java.net/browse/JMC-4466 < >> > https://bugs.openjdk.java.net/browse/JMC-4466> >> > > >>>> [2] https://imgur.com/BkeXkVX >> > > >>>> [3] https://imgur.com/dhuTmkE >> > > >>>> [4] https://imgur.com/W7NzOj7 >> > > >>>> [5] https://travis-ci.org/aptmac/jmc-qa/builds/516268811 < >> > https://travis-ci.org/aptmac/jmc-qa/builds/516268811> >> > > >>> >> > > >>> Hi Alex, >> > > >>> >> > > >>> The patch looks generally good, the only question I have is >> regarding >> > > >>> the thread selection by name: >> > > >>> >> > > >>> + private int indexOfThreadName(String name) { >> > > >>> + for (int i = 0; i < this.threadRows.size() && name != null; >> i++) >> > { >> > > >>> + if (this.threadRows.get(i) instanceof QuantitySpanRenderer) >> { >> > > >>> + if (name.equals(((QuantitySpanRenderer) >> > > >>> + this.threadRows.get(i)).getName())) { >> > > >>> + return i; >> > > >>> + } >> > > >>> + } >> > > >>> + } >> > > >>> + return -1; >> > > >>> + } >> > > >>> >> > > >>> What happens when two threads have the same name? This will make >> > > >>> disappear the very fist one with this name encountered, not >> > necessarily >> > > >>> the one the user clicked on, isn't it? >> > > >>> >> > > >> >> > > >> Ah good call, I hadn't thought about that case. I'll come back >> with a >> > > >> revised webrev. >> > > >> >> > > >> >> > > >>> >> > > >>> Cheers, >> > > >>> Mario >> > > >>> -- >> > > >>> Mario Torre >> > > >>> Associate Manager, Software Engineering >> > > >>> Red Hat GmbH > >> > > >>> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 >> > > >>> >> > > >> >> > > >> Thanks, >> > > >> >> > > >> Alex >> > > > >> > > > >> > > > Cheers, >> > > > >> > > > Alex >> > > > >> > > > [6] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ < >> > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/> >> > > > >> > > > Cheers, >> > > > >> > > > Alex >> > > > >> > > > [7] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ < >> > http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/> >> > > > [8] https://travis-ci.org/aptmac/jmc-qa/builds/527928758 < >> > https://travis-ci.org/aptmac/jmc-qa/builds/527928758> >> > >> > >> > >> > -- >> > 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 Jun 7 16:11:19 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Fri, 07 Jun 2019 16:11:19 +0000 Subject: hg: jmc/jmc: JMC-4466: Fix the hide thread functionality in Windows and JfrThreadsPageTest uitest failures Message-ID: <201906071611.x57GBJ9q018633@aojmv0008.oracle.com> Changeset: ca6ac83aa5b9 Author: aptmac Date: 2019-06-07 11:07 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/ca6ac83aa5b9 JMC-4466: Fix the hide thread functionality in Windows and JfrThreadsPageTest uitest failures Summary: The hide thread functionality on the JFR Threads page was not working as intended in Windows. Additionally, the uitests would sometimes not focus the table when trying to make a selection, causing the tests to fail. Reviewed-by: hirt ! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/misc/ChartCanvas.java ! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCChartCanvas.java ! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCTable.java From jescolem at redhat.com Fri Jun 7 18:47:32 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Fri, 7 Jun 2019 14:47:32 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage Message-ID: 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. Thank you! Jessye Coleman-Shapiro [0] https://bugs.openjdk.java.net/browse/JMC-5499 -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-5499.patch Type: text/x-patch Size: 18581 bytes Desc: not available URL: From neugens at redhat.com Tue Jun 11 09:30:17 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 11 Jun 2019 11:30:17 +0200 Subject: RFC: JMC-6505: Cannot run JMC on JDK 8 by default Message-ID: <20cd04bb-354e-3bcc-5bdf-1b45d51f1a68@redhat.com> Hi! A couple of weeks ago there was mention of issues with JMC running on top of JDK 8 due to the modules related options in the jmc.ini file, so I went ahead and created a bug id and a fix: http://cr.openjdk.java.net/~neugens/JMC-6505/webrev/ The fix simply adds IgnoreUnrecognizedVMOptions so that the VM doesn't stop. This also helps when running JMC on top of OpenJDK 8 that do not have the JFR patches backported. I'm not sure if there's a way to unit-test this patch? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kdobson at redhat.com Tue Jun 11 16:28:03 2019 From: kdobson at redhat.com (Ken Dobson) Date: Tue, 11 Jun 2019 12:28:03 -0400 Subject: JMC-6466: Visualizing dictionary size events Message-ID: Hi all, I'm looking into supporting some new events that have just been implemented for dictionary sizes. [0][1] I'm looking for some insight into what ways to visualize them in a way that would be beneficial to the user as well as any ideas for rules that would be helpful as wel;. If there are a number of ideas I'll open up some new enhancement tickets to keep this from this ticket getting to large. Thanks, Ken [0] https://bugs.openjdk.java.net/browse/JDK-8185525 [1] https://bugs.openjdk.java.net/browse/JMC-6466 From jescolem at redhat.com Tue Jun 11 18:53:28 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Tue, 11 Jun 2019 14:53:28 -0400 Subject: [PATCH] JMC-5706 JavaBlockingRule should report block times Message-ID: 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. Thank you! Jessye [0] https://bugs.openjdk.java.net/browse/JMC-5706 -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-5706.patch Type: text/x-patch Size: 4870 bytes Desc: not available URL: From marcus.hirt at datadoghq.com Wed Jun 12 17:20:16 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Wed, 12 Jun 2019 19:20:16 +0200 Subject: RFC: JMC-6505: Cannot run JMC on JDK 8 by default In-Reply-To: <20cd04bb-354e-3bcc-5bdf-1b45d51f1a68@redhat.com> References: <20cd04bb-354e-3bcc-5bdf-1b45d51f1a68@redhat.com> Message-ID: Looks fine to me! Kind regards, Marcus On Tue, Jun 11, 2019 at 11:30 AM Mario Torre wrote: > Hi! > > A couple of weeks ago there was mention of issues with JMC running on > top of JDK 8 due to the modules related options in the jmc.ini file, so > I went ahead and created a bug id and a fix: > > http://cr.openjdk.java.net/~neugens/JMC-6505/webrev/ > > The fix simply adds IgnoreUnrecognizedVMOptions so that the VM doesn't > stop. This also helps when running JMC on top of OpenJDK 8 that do not > have the JFR patches backported. > > I'm not sure if there's a way to unit-test this patch? > > 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 Thu Jun 13 09:42:11 2019 From: neugens at redhat.com (neugens at redhat.com) Date: Thu, 13 Jun 2019 09:42:11 +0000 Subject: hg: jmc/jmc: JMC-6505: Cannot run JMC on JDK 8 by default Message-ID: <201906130942.x5D9gCV5025310@aojmv0008.oracle.com> Changeset: b8e4bfe95f7c Author: neugens Date: 2019-06-13 11:41 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/b8e4bfe95f7c JMC-6505: Cannot run JMC on JDK 8 by default Summary: Add +IgnoreUnrecognizedVMOptions to the jmc.ini so that JVM with no modules or support for JFR can still run JMC Reviewed-by: hirt ! application/org.openjdk.jmc.rcp.product/jmc.product From almacdon at redhat.com Wed Jun 19 19:44:36 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Wed, 19 Jun 2019 15:44:36 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: Hi Jessye, On Fri, Jun 7, 2019 at 2:48 PM Jessye Coleman Shapiro 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 kdobson at redhat.com Wed Jun 19 21:04:06 2019 From: kdobson at redhat.com (Ken Dobson) Date: Wed, 19 Jun 2019 17:04:06 -0400 Subject: JMC-6466: Visualize the new Dictionary Events Message-ID: Hi all, I spoke to the implementer of the dictionary size events and got some ideas for rules/visualizations that I thought I'd share here to get some feedback. The full event attributes can be viewed here https://bugs.openjdk.java.net/browse/JDK-8185525 . For these possible rules most of them seem pretty straightforward it's just a matter of deciding what the appropriate heuristics are. Possible Rules 1. Check for frequent table resizing 2.Check for large difference between maximumBucketSize and AverageBucketSize as it can indicate a security issue 3. Check BucketCountVariance and bucketCountStandardDev for large values that indicate irregular distribution 4. Large insertion and removal rates (post start-up phase) These events default to being emitted every 10s. I think most of these rules could be achieved using a sliding window much like a number of other rules are implemented. Visualization 1. A visualization for when a table resizes Something like a line chart could easily added to show this. However not sure what page it would best fit on. Please respond if you think any or all of these possible rules are worth implementing as well if you have ideas as to what appropriate heuristics might be to trigger these rules. As well any other visualization ideas would be great as well. Thanks, Ken Dobson From jescolem at redhat.com Thu Jun 20 13:05:25 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Thu, 20 Jun 2019 09:05:25 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: Hi Alex, I will make those changes and send an updated patch. 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 > 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 Jun 20 17:29:43 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 20 Jun 2019 13:29:43 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: On Thu, Jun 20, 2019 at 9:05 AM Jessye Coleman Shapiro 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 >> > From almacdon at redhat.com Thu Jun 20 17:32:44 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 20 Jun 2019 13:32:44 -0400 Subject: [PATCH] JMC-5706 JavaBlockingRule should report block times In-Reply-To: References: Message-ID: Hi Jessye, On Tue, Jun 11, 2019 at 2:54 PM Jessye Coleman Shapiro 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 From kdobson at redhat.com Thu Jun 20 18:35:06 2019 From: kdobson at redhat.com (Ken Dobson) Date: Thu, 20 Jun 2019 14:35:06 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: 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 > >> > > > From jescolem at redhat.com Thu Jun 20 19:26:30 2019 From: jescolem at redhat.com (Jessye Coleman Shapiro) Date: Thu, 20 Jun 2019 15:26:30 -0400 Subject: [PATCH] JMC-5706 JavaBlockingRule should report block times In-Reply-To: References: Message-ID: 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. Thanks for the help, Jessye -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-5706.patch Type: text/x-patch Size: 6207 bytes Desc: not available URL: From christoph.langer at sap.com Thu Jun 20 21:55:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Jun 2019 21:55:59 +0000 Subject: JMC-6513: Wrong version of compiled classes when importing JMC maven projects in Eclipse with JDT Default Compiler Level of 11 Message-ID: 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 carusso at redhat.com Fri Jun 21 12:30:47 2019 From: carusso at redhat.com (Carmine Vincenzo Russo) Date: Fri, 21 Jun 2019 14:30:47 +0200 Subject: RFC: JMC-6173: jmc -open requires full path Message-ID: 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. Thank you! Carmine [0] https://bugs.openjdk.java.net/browse/JMC-6173 -- Carmine Vincenzo Russo From christoph.langer at sap.com Fri Jun 21 12:32:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Jun 2019 12:32:58 +0000 Subject: JMC-6514: Add Eclipse 2019-06 target definition Message-ID: Hi, now that Eclipse 2019-06 is released, we should use it in JMC. Here?s the patch. Bug: https://bugs.openjdk.java.net/browse/JMC-6514 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6514.0/ I tested the build and the import on Windows. It went all well. So, please review and sponsor it ?? Best regards Christoph From marcus at hirt.se Fri Jun 21 14:21:23 2019 From: marcus at hirt.se (Marcus Hirt) Date: Fri, 21 Jun 2019 16:21:23 +0200 Subject: Sv: JMC-6514: Add Eclipse 2019-06 target definition In-Reply-To: References: Message-ID: <08ef01d5283c$9ab9bbf0$d02d33d0$@hirt.se> Looks good! I can sponsor this one. Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Langer, Christoph Skickat: den 21 juni 2019 14:33 Till: jmc-dev at openjdk.java.net ?mne: JMC-6514: Add Eclipse 2019-06 target definition Hi, now that Eclipse 2019-06 is released, we should use it in JMC. Here?s the patch. Bug: https://bugs.openjdk.java.net/browse/JMC-6514 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6514.0/ I tested the build and the import on Windows. It went all well. So, please review and sponsor it ?? Best regards Christoph From christoph.langer at sap.com Fri Jun 21 14:34:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Jun 2019 14:34:01 +0000 Subject: JMC-6514: Add Eclipse 2019-06 target definition In-Reply-To: <08ef01d5283c$9ab9bbf0$d02d33d0$@hirt.se> References: <08ef01d5283c$9ab9bbf0$d02d33d0$@hirt.se> Message-ID: Hi Marcus, thanks, that would be very welcome. Maybe you can also make me a JMC author then ?? Best regards Christoph > -----Original Message----- > From: Marcus Hirt > Sent: Freitag, 21. Juni 2019 16:21 > To: Langer, Christoph ; jmc- > dev at openjdk.java.net > Subject: Sv: JMC-6514: Add Eclipse 2019-06 target definition > > Looks good! I can sponsor this one. > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Langer, Christoph > Skickat: den 21 juni 2019 14:33 > Till: jmc-dev at openjdk.java.net > ?mne: JMC-6514: Add Eclipse 2019-06 target definition > > Hi, > > now that Eclipse 2019-06 is released, we should use it in JMC. Here?s the > patch. > > Bug: https://bugs.openjdk.java.net/browse/JMC-6514 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6514.0/ > > I tested the build and the import on Windows. It went all well. So, please > review and sponsor it ?? > > Best regards > Christoph > From jkang at redhat.com Fri Jun 21 14:38:31 2019 From: jkang at redhat.com (Jie Kang) Date: Fri, 21 Jun 2019 10:38:31 -0400 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: References: Message-ID: 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? Regards, > > Thank you! > Carmine > > > [0] https://bugs.openjdk.java.net/browse/JMC-6173 > > -- > Carmine Vincenzo Russo From marcus at hirt.se Fri Jun 21 15:19:17 2019 From: marcus at hirt.se (Marcus Hirt) Date: Fri, 21 Jun 2019 17:19:17 +0200 Subject: Review request for JMC-JMC-4057: Adding experimental flame graph view. Message-ID: <08f401d52844$b1857ba0$149072e0$@hirt.se> 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/ Kind regards, Marcus From almacdon at redhat.com Fri Jun 21 17:51:29 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Fri, 21 Jun 2019 13:51:29 -0400 Subject: [PATCH] JMC-5706 JavaBlockingRule should report block times In-Reply-To: References: Message-ID: Hi Jessye, On Thu, Jun 20, 2019 at 3:26 PM Jessye Coleman Shapiro 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 guru.hb at oracle.com Mon Jun 24 05:38:32 2019 From: guru.hb at oracle.com (Guru) Date: Mon, 24 Jun 2019 11:08:32 +0530 Subject: JMC-6514: Add Eclipse 2019-06 target definition In-Reply-To: <08ef01d5283c$9ab9bbf0$d02d33d0$@hirt.se> References: <08ef01d5283c$9ab9bbf0$d02d33d0$@hirt.se> Message-ID: +1, Looks good to me. Thanks Guru > On 21-Jun-2019, at 7:51 PM, Marcus Hirt wrote: > > Looks good! I can sponsor this one. > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Langer, Christoph > Skickat: den 21 juni 2019 14:33 > Till: jmc-dev at openjdk.java.net > ?mne: JMC-6514: Add Eclipse 2019-06 target definition > > Hi, > > now that Eclipse 2019-06 is released, we should use it in JMC. Here?s the patch. > > Bug: https://bugs.openjdk.java.net/browse/JMC-6514 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6514.0/ > > I tested the build and the import on Windows. It went all well. So, please review and sponsor it ?? > > Best regards > Christoph > > From marcus.hirt at datadoghq.com Mon Jun 24 11:07:03 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 24 Jun 2019 13:07:03 +0200 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: 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 > > >> > > > > > > From marcus.hirt at datadoghq.com Mon Jun 24 11:53:52 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 24 Jun 2019 13:53:52 +0200 Subject: EOI Demos and Planning Message-ID: 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 kdobson at redhat.com Mon Jun 24 14:57:21 2019 From: kdobson at redhat.com (Ken Dobson) Date: Mon, 24 Jun 2019 10:57:21 -0400 Subject: [PATCH] JMC-5499 Add XFlagChanged events to JVM Information or subpage In-Reply-To: References: Message-ID: 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 >> > >> >> > > >> > >> > From marcus at hirt.se Tue Jun 25 10:33:02 2019 From: marcus at hirt.se (marcus at hirt.se) Date: Tue, 25 Jun 2019 10:33:02 +0000 Subject: hg: jmc/jmc: JMC-6514: Upgrading to Eclipse 2019-06 Message-ID: <201906251033.x5PAX2gP014423@aojmv0008.oracle.com> Changeset: 5e0a199762b6 Author: hirt Date: 2019-06-25 12:32 +0200 URL: http://hg.openjdk.java.net/jmc/jmc/rev/5e0a199762b6 JMC-6514: Upgrading to Eclipse 2019-06 Reviewed-by: hirt, ghb Contributed-by: clanger ! pom.xml + releng/platform-definitions/platform-definition-2019-06/.project + releng/platform-definitions/platform-definition-2019-06/platform-definition-2019-06.target + releng/platform-definitions/platform-definition-2019-06/pom.xml ! releng/platform-definitions/pom.xml From marcus.hirt at datadoghq.com Tue Jun 25 10:34:00 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Tue, 25 Jun 2019 12:34:00 +0200 Subject: JMC-6514: Add Eclipse 2019-06 target definition In-Reply-To: References: Message-ID: Pushed! Thank you for your contribution! Kind regards, Marcus On Fri, Jun 21, 2019 at 2:33 PM Langer, Christoph wrote: > > Hi, > > now that Eclipse 2019-06 is released, we should use it in JMC. Here?s the patch. > > Bug: https://bugs.openjdk.java.net/browse/JMC-6514 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/JMC-6514.0/ > > I tested the build and the import on Windows. It went all well. So, please review and sponsor it > > Best regards > Christoph > From marcus at hirt.se Tue Jun 25 12:02:45 2019 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 25 Jun 2019 14:02:45 +0200 Subject: Sv: EOI Demos and Planning In-Reply-To: References: Message-ID: <012001d52b4d$e65d2d80$b3178880$@hirt.se> I'll close the poll tomorrow (26th of June), 17:00 CET. Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Marcus Hirt Skickat: den 24 juni 2019 13:54 Till: jmc-dev at openjdk.java.net ?mne: EOI Demos and Planning 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 jkang at redhat.com Tue Jun 25 16:28:39 2019 From: jkang at redhat.com (Jie Kang) Date: Tue, 25 Jun 2019 12:28:39 -0400 Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency In-Reply-To: References: Message-ID: 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. Regards, > >> >> >> >> Regards, > > > Cheers, > > Alex > > [0] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2cf5bec8d8ba -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6492.patch Type: text/x-patch Size: 1377 bytes Desc: not available URL: From neugens at redhat.com Tue Jun 25 17:34:43 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 25 Jun 2019 19:34:43 +0200 Subject: CFV: New jmc Committer: Ken Dobson Message-ID: I hereby nominate Ken Dobson to jmc Committer. Ken has been a prolific contributor to JDK Mission Control over the past months, with at least 15 contributions (and one for JFR) and more in the works: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6241 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4721 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5703 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5359 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5663 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6191 https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6260 https://bugs.openjdk.java.net/browse/JDK-8221507 https://bugs.openjdk.java.net/browse/JMC-4469 https://bugs.openjdk.java.net/browse/JMC-5368 https://bugs.openjdk.java.net/browse/JMC-4645 https://bugs.openjdk.java.net/browse/JMC-6285 https://bugs.openjdk.java.net/browse/JMC-6223 https://bugs.openjdk.java.net/browse/JMC-5640 Votes are due by 2019-07-09 at 18:00 CET. Only current jmc Committers and Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Kind regards, Mario [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jmatsuok at redhat.com Tue Jun 25 17:58:54 2019 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Tue, 25 Jun 2019 13:58:54 -0400 Subject: CFV: New jmc Committer: Ken Dobson In-Reply-To: References: Message-ID: Vote: Yes Cheers, - Josh On Tue, Jun 25, 2019 at 1:36 PM Mario Torre wrote: > I hereby nominate Ken Dobson to jmc Committer. > > Ken has been a prolific contributor to JDK Mission Control over the > past months, with at least 15 contributions (and one for JFR) and more > in the works: > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6241 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4721 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5703 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5359 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5663 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6191 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6260 > https://bugs.openjdk.java.net/browse/JDK-8221507 > https://bugs.openjdk.java.net/browse/JMC-4469 > https://bugs.openjdk.java.net/browse/JMC-5368 > https://bugs.openjdk.java.net/browse/JMC-4645 > https://bugs.openjdk.java.net/browse/JMC-6285 > https://bugs.openjdk.java.net/browse/JMC-6223 > https://bugs.openjdk.java.net/browse/JMC-5640 > > Votes are due by 2019-07-09 at 18:00 CET. > > Only current jmc Committers and Reviewers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Mario > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From marcus at hirt.se Tue Jun 25 18:01:51 2019 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 25 Jun 2019 20:01:51 +0200 Subject: CFV: New jmc Committer: Ken Dobson Message-ID: <034d01d52b80$10907ad0$31b17070$@hirt.se> Vote: yes Kind regards, Marcus From neugens at redhat.com Tue Jun 25 18:25:20 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 25 Jun 2019 20:25:20 +0200 Subject: CFV: New jmc Committer: Ken Dobson In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario On Tuesday, June 25, 2019, Mario Torre wrote: > I hereby nominate Ken Dobson to jmc Committer. > > Ken has been a prolific contributor to JDK Mission Control over the > past months, with at least 15 contributions (and one for JFR) and more > in the works: > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6241 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4721 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5703 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5359 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5663 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6191 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6260 > https://bugs.openjdk.java.net/browse/JDK-8221507 > https://bugs.openjdk.java.net/browse/JMC-4469 > https://bugs.openjdk.java.net/browse/JMC-5368 > https://bugs.openjdk.java.net/browse/JMC-4645 > https://bugs.openjdk.java.net/browse/JMC-6285 > https://bugs.openjdk.java.net/browse/JMC-6223 > https://bugs.openjdk.java.net/browse/JMC-5640 > > Votes are due by 2019-07-09 at 18:00 CET. > > Only current jmc Committers and Reviewers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Mario > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From almacdon at redhat.com Tue Jun 25 19:12:22 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Tue, 25 Jun 2019 15:12:22 -0400 Subject: CFV: New jmc Committer: Ken Dobson In-Reply-To: References: Message-ID: Vote: Yes Cheers, Alex On Tue, Jun 25, 2019 at 1:36 PM Mario Torre wrote: > I hereby nominate Ken Dobson to jmc Committer. > > Ken has been a prolific contributor to JDK Mission Control over the > past months, with at least 15 contributions (and one for JFR) and more > in the works: > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6241 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4721 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5703 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5359 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5663 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6191 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6260 > https://bugs.openjdk.java.net/browse/JDK-8221507 > https://bugs.openjdk.java.net/browse/JMC-4469 > https://bugs.openjdk.java.net/browse/JMC-5368 > https://bugs.openjdk.java.net/browse/JMC-4645 > https://bugs.openjdk.java.net/browse/JMC-6285 > https://bugs.openjdk.java.net/browse/JMC-6223 > https://bugs.openjdk.java.net/browse/JMC-5640 > > Votes are due by 2019-07-09 at 18:00 CET. > > Only current jmc Committers and Reviewers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Mario > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From hdafgard at gmail.com Tue Jun 25 23:48:00 2019 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Wed, 26 Jun 2019 09:48:00 +1000 Subject: CFV: New jmc Committer: Ken Dobson In-Reply-To: References: Message-ID: Vote: yes Cheers, Henrik Dafg?rd On Wed, 26 Jun 2019 at 05:13, Alex Macdonald wrote: > Vote: Yes > > Cheers, > > Alex > > On Tue, Jun 25, 2019 at 1:36 PM Mario Torre wrote: > > > I hereby nominate Ken Dobson to jmc Committer. > > > > Ken has been a prolific contributor to JDK Mission Control over the > > past months, with at least 15 contributions (and one for JFR) and more > > in the works: > > > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6241 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4721 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5703 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5359 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5663 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6191 > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6260 > > https://bugs.openjdk.java.net/browse/JDK-8221507 > > https://bugs.openjdk.java.net/browse/JMC-4469 > > https://bugs.openjdk.java.net/browse/JMC-5368 > > https://bugs.openjdk.java.net/browse/JMC-4645 > > https://bugs.openjdk.java.net/browse/JMC-6285 > > https://bugs.openjdk.java.net/browse/JMC-6223 > > https://bugs.openjdk.java.net/browse/JMC-5640 > > > > Votes are due by 2019-07-09 at 18:00 CET. > > > > Only current jmc Committers and Reviewers [1] are eligible to vote on > > this nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Lazy Consensus voting instructions, see [2]. > > > > Kind regards, > > Mario > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > -- // Henrik Dafg?rd From guru.hb at oracle.com Wed Jun 26 03:46:28 2019 From: guru.hb at oracle.com (Guru) Date: Wed, 26 Jun 2019 09:16:28 +0530 Subject: CFV: New jmc Committer: Ken Dobson In-Reply-To: References: Message-ID: <36A3B026-C69E-4E1E-9ADA-99921311BA37@oracle.com> Vote: Yes -Guru > On 25-Jun-2019, at 11:04 PM, Mario Torre wrote: > > I hereby nominate Ken Dobson to jmc Committer. > > Ken has been a prolific contributor to JDK Mission Control over the > past months, with at least 15 contributions (and one for JFR) and more > in the works: > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6241 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4721 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5703 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5359 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5663 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6191 > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6260 > https://bugs.openjdk.java.net/browse/JDK-8221507 > https://bugs.openjdk.java.net/browse/JMC-4469 > https://bugs.openjdk.java.net/browse/JMC-5368 > https://bugs.openjdk.java.net/browse/JMC-4645 > https://bugs.openjdk.java.net/browse/JMC-6285 > https://bugs.openjdk.java.net/browse/JMC-6223 > https://bugs.openjdk.java.net/browse/JMC-5640 > > Votes are due by 2019-07-09 at 18:00 CET. > > Only current jmc Committers and Reviewers [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Kind regards, > Mario > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kxu at redhat.com Wed Jun 26 14:04:09 2019 From: kxu at redhat.com (Kangcheng Xu) Date: Wed, 26 Jun 2019 10:04:09 -0400 Subject: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup In-Reply-To: References: <0a2801d5128d$27491f90$75db5eb0$@hirt.se> Message-ID: Hello, This is the updated patch, and I've verified it doesn't cause conflicts with recent changes. Please see the attachment below. Thanks! Arvin Xu On Fri, 21 Jun 2019 at 10:00, Kangcheng Xu wrote: > > ---------- Forwarded message --------- > From: Kangcheng Xu > Date: Tue, May 28, 2019 at 2:47 PM > Subject: Re: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup > To: Marcus Hirt > > > Hi, > > This is updated to change all JMC callers of MCPathEditorInput(File) > to use the alternative constructor as requested. > > Arvin Kangcheng Xu > > On Fri, May 24, 2019 at 9:18 PM Kangcheng Xu wrote: > > > > Hello, > > > > On Fri, May 24, 2019 at 8:12 PM Marcus Hirt wrote: > > > > > > Hi there! > > > > > > There seem to be other users of that class that use the > > > default constructor presumably because they do not want > > > to persist their opening of files, such as trigger > > > actions. One could argue that maybe they should end up > > > in the recently opened list too, but I believe this is > > > at least the reason for the current behavior. > > > > Yes, I agree with you. Sorry I didn't realize this earlier. > > > > > A slightly more defensive solution could be to instead: > > > > > > diff -r 4c9efa5eb5b8 application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java > > > --- a/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java Fri May 24 13:05:05 2019 +0200 > > > +++ b/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java Sat May 25 01:59:12 2019 +0200 > > > @@ -161,7 +161,7 @@ > > > for (String name : names) { > > > final File file = new File(filterPath + File.separator + name); > > > if (file.exists()) { > > > - WorkbenchToolkit.openEditor(inWindow, new MCPathEditorInput(file)); > > > + WorkbenchToolkit.openEditor(inWindow, new MCPathEditorInput(file, true)); > > > } else { > > > if (++numberOfFilesNotFound > 1) { > > > notFound.append('\n'); > > > > A modified patch file is attached. Additionally, > > `MCPathEditorInput(File)' constructor is now marked deprecated. > > > > > Kind regards, > > > Marcus > > > > Thanks very much for the advice! > > > > Arvin Kangcheng Xu -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6484.patch Type: text/x-patch Size: 11217 bytes Desc: not available URL: From marcus at hirt.se Wed Jun 26 16:41:10 2019 From: marcus at hirt.se (Marcus Hirt) Date: Wed, 26 Jun 2019 18:41:10 +0200 Subject: Sv: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup In-Reply-To: References: <0a2801d5128d$27491f90$75db5eb0$@hirt.se> Message-ID: <09a001d52c3d$f5a89130$e0f9b390$@hirt.se> Looks good! (The summary has a small spelling error: Summary: Marked MCPathEditorInput(File) constructor -->depreacated<--.) Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Kangcheng Xu Skickat: den 26 juni 2019 16:04 Till: Alex Macdonald Kopia: jmc-dev at openjdk.java.net ?mne: Re: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup Hello, This is the updated patch, and I've verified it doesn't cause conflicts with recent changes. Please see the attachment below. Thanks! Arvin Xu On Fri, 21 Jun 2019 at 10:00, Kangcheng Xu wrote: > > ---------- Forwarded message --------- > From: Kangcheng Xu > Date: Tue, May 28, 2019 at 2:47 PM > Subject: Re: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on > startup > To: Marcus Hirt > > > Hi, > > This is updated to change all JMC callers of MCPathEditorInput(File) > to use the alternative constructor as requested. > > Arvin Kangcheng Xu > > On Fri, May 24, 2019 at 9:18 PM Kangcheng Xu wrote: > > > > Hello, > > > > On Fri, May 24, 2019 at 8:12 PM Marcus Hirt wrote: > > > > > > Hi there! > > > > > > There seem to be other users of that class that use the default > > > constructor presumably because they do not want to persist their > > > opening of files, such as trigger actions. One could argue that > > > maybe they should end up in the recently opened list too, but I > > > believe this is at least the reason for the current behavior. > > > > Yes, I agree with you. Sorry I didn't realize this earlier. > > > > > A slightly more defensive solution could be to instead: > > > > > > diff -r 4c9efa5eb5b8 application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java > > > --- a/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java Fri May 24 13:05:05 2019 +0200 > > > +++ b/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java Sat May 25 01:59:12 2019 +0200 > > > @@ -161,7 +161,7 @@ > > > for (String name : names) { > > > final File file = new File(filterPath + File.separator + name); > > > if (file.exists()) { > > > - WorkbenchToolkit.openEditor(inWindow, new MCPathEditorInput(file)); > > > + > > > + WorkbenchToolkit.openEditor(inWindow, new > > > + MCPathEditorInput(file, true)); > > > } else { > > > if (++numberOfFilesNotFound > 1) { > > > > > > notFound.append('\n'); > > > > A modified patch file is attached. Additionally, > > `MCPathEditorInput(File)' constructor is now marked deprecated. > > > > > Kind regards, > > > Marcus > > > > Thanks very much for the advice! > > > > Arvin Kangcheng Xu From florian.david at gmail.com Thu Jun 27 09:33:47 2019 From: florian.david at gmail.com (Florian David) Date: Thu, 27 Jun 2019 11:33:47 +0200 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account Message-ID: 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 Thu Jun 27 10:24:01 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 27 Jun 2019 12:24:01 +0200 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: Florian is submitting on behalf of Datadog; Datadog has a signed OCA. https://www.oracle.com/technetwork/community/oca-486395.html#d Kind regards, Marcus On Thu, Jun 27, 2019 at 11: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 almacdon at redhat.com Thu Jun 27 13:37:03 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 27 Jun 2019 09:37:03 -0400 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: References: Message-ID: 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 From almacdon at redhat.com Thu Jun 27 13:57:50 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 27 Jun 2019 09:57:50 -0400 Subject: RFR: JMC-6368: Foldable threads table in the Threads page In-Reply-To: References: Message-ID: On Fri, May 10, 2019 at 2:16 PM Alex Macdonald wrote: > Hi, > > The following webrev [0] addresses issue JMC-6368 [1], in which the user > should be able to fold away the table and graph on the Threads page to > reclaim screen real-estate. > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-6368/webrev.01 Please see the above webrev for an updated version of this patch. While the previous implementation worked in Linux, I started running into problems when running the same patch on Windows. The first issue was that I had the toolbar buttons enable/disable themselves to prevent the user from folding away both the chart and the table, however having a button be both selected & disabled is not possible in Windows. The second issue had to do with layouts. There's a specific use case where if the sash weight for a component is 0 (i.e., it's folded), the user can still click the sash itself to make the component visible. As a result, I needed to put an actionlistener on the sash to detect these events so the toolbar buttons can be reset accordingly. The sash itself is not built until the children are added and layout() is called, but what stumped me for so long was that in Linux everything would get laid out as expected, but in Windows there was a gaping whitespace to the right of the page that only existed until the page was resized/redrawn. The solution was to dispose of the chart legend before calling layout() (which makes sense), but I'm still a bit confused as to why this looked fine on Linux but not in Windows. > I had previously attached two proof-of-concept gifs to the JIRA issue [1], > and after discussion on Slack it looked like taking the route of POC2 > (adding toolbar actions along side existing page controls) was the short > term win, and that POC1 (UI components collapsing into a vertical bar of > some sort) should be investigated as it's own issue and potentially > implemented across the UI. This patch introduces two selectable items to > the toolbar which allow the user to expand either the table or graph to > fill the screen, and then fold away the other component. In a way to > prevent both components from being folded away (and viewing nothing) there > are controls to disable toolbar items when only 1 component is visible (one > is already folded), and enable them when both are visible (and one can be > folded away). > > I've included a couple of screen shots that display the page with: > - both the table and graph visible [2] > - the table folded and the graph visible [3] > - the graph folded and the table visible [4] > > and a couple of gifs to show > - the general flow of the controls [5] > - the folds persisting a reload of the jfr file [6] > > I wrote a couple of uitests that verify some behaviour by interacting with > the toolbar items and verifying the weights of the SashForm; passing Travis > build available [7] > I've included a couple more uitests, and the build looks ok on both Linux & Windows. Passing Travis CI log: https://api.travis-ci.org/v3/job/550842345/log.txt > > Thoughts? > > Cheers, > > Alex > > [0] http://cr.openjdk.java.net/~aptmac/JMC-6368/webrev.00/ > [1] https://bugs.openjdk.java.net/browse/JMC-6368 > [2] https://imgur.com/XW99H5L > [3] https://imgur.com/d0d7Wln > [4] https://imgur.com/ibPgaWw > [5] https://imgur.com/QZzZZUN > [6] https://imgur.com/gUNfpTX > [7] https://travis-ci.org/aptmac/jmc-qa/builds/530418716 > From kxu at redhat.com Thu Jun 27 14:08:23 2019 From: kxu at redhat.com (Kangcheng Xu) Date: Thu, 27 Jun 2019 10:08:23 -0400 Subject: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup In-Reply-To: <09a001d52c3d$f5a89130$e0f9b390$@hirt.se> References: <0a2801d5128d$27491f90$75db5eb0$@hirt.se> <09a001d52c3d$f5a89130$e0f9b390$@hirt.se> Message-ID: Sorry for the typo. The attachment is updated with correct spelling. Thanks! Arvin On Wed, 26 Jun 2019 at 12:47, Marcus Hirt wrote: > > Looks good! > > (The summary has a small spelling error: > Summary: Marked MCPathEditorInput(File) constructor -->depreacated<--.) > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Kangcheng Xu > Skickat: den 26 juni 2019 16:04 > Till: Alex Macdonald > Kopia: jmc-dev at openjdk.java.net > ?mne: Re: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup > > Hello, > > This is the updated patch, and I've verified it doesn't cause conflicts with recent changes. > Please see the attachment below. Thanks! > > Arvin Xu > > On Fri, 21 Jun 2019 at 10:00, Kangcheng Xu wrote: > > > > ---------- Forwarded message --------- > > From: Kangcheng Xu > > Date: Tue, May 28, 2019 at 2:47 PM > > Subject: Re: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on > > startup > > To: Marcus Hirt > > > > > > Hi, > > > > This is updated to change all JMC callers of MCPathEditorInput(File) > > to use the alternative constructor as requested. > > > > Arvin Kangcheng Xu > > > > On Fri, May 24, 2019 at 9:18 PM Kangcheng Xu wrote: > > > > > > Hello, > > > > > > On Fri, May 24, 2019 at 8:12 PM Marcus Hirt wrote: > > > > > > > > Hi there! > > > > > > > > There seem to be other users of that class that use the default > > > > constructor presumably because they do not want to persist their > > > > opening of files, such as trigger actions. One could argue that > > > > maybe they should end up in the recently opened list too, but I > > > > believe this is at least the reason for the current behavior. > > > > > > Yes, I agree with you. Sorry I didn't realize this earlier. > > > > > > > A slightly more defensive solution could be to instead: > > > > > > > > diff -r 4c9efa5eb5b8 application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java > > > > --- a/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java Fri May 24 13:05:05 2019 +0200 > > > > +++ b/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java Sat May 25 01:59:12 2019 +0200 > > > > @@ -161,7 +161,7 @@ > > > > for (String name : names) { > > > > final File file = new File(filterPath + File.separator + name); > > > > if (file.exists()) { > > > > - WorkbenchToolkit.openEditor(inWindow, new MCPathEditorInput(file)); > > > > + > > > > + WorkbenchToolkit.openEditor(inWindow, new > > > > + MCPathEditorInput(file, true)); > > > > } else { > > > > if (++numberOfFilesNotFound > 1) { > > > > > > > > notFound.append('\n'); > > > > > > A modified patch file is attached. Additionally, > > > `MCPathEditorInput(File)' constructor is now marked deprecated. > > > > > > > Kind regards, > > > > Marcus > > > > > > Thanks very much for the advice! > > > > > > Arvin Kangcheng Xu > -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6484.patch Type: text/x-patch Size: 11216 bytes Desc: not available URL: From erik.gahlin at oracle.com Thu Jun 27 16:04:40 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 27 Jun 2019 18:04:40 +0200 Subject: RFC: JMC-6173: jmc -open requires full path In-Reply-To: References: Message-ID: <5D14E918.80302@oracle.com> 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. 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. 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 From almacdon at redhat.com Thu Jun 27 18:25:59 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 27 Jun 2019 14:25:59 -0400 Subject: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup In-Reply-To: References: <0a2801d5128d$27491f90$75db5eb0$@hirt.se> <09a001d52c3d$f5a89130$e0f9b390$@hirt.se> Message-ID: On Thu, Jun 27, 2019 at 10:08 AM Kangcheng Xu wrote: > Sorry for the typo. The attachment is updated with correct spelling. > Great, thanks for the updated patch! This looks good to me. I can sponsor this change and will push shortly. Cheers, Alex > Thanks! > Arvin > > On Wed, 26 Jun 2019 at 12:47, Marcus Hirt wrote: > > > > Looks good! > > > > (The summary has a small spelling error: > > Summary: Marked MCPathEditorInput(File) constructor -->depreacated<--.) > > > > Kind regards, > > Marcus > > > > -----Ursprungligt meddelande----- > > Fr?n: jmc-dev F?r Kangcheng Xu > > Skickat: den 26 juni 2019 16:04 > > Till: Alex Macdonald > > Kopia: jmc-dev at openjdk.java.net > > ?mne: Re: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on > startup > > > > Hello, > > > > This is the updated patch, and I've verified it doesn't cause conflicts > with recent changes. > > Please see the attachment below. Thanks! > > > > Arvin Xu > > > > On Fri, 21 Jun 2019 at 10:00, Kangcheng Xu wrote: > > > > > > ---------- Forwarded message --------- > > > From: Kangcheng Xu > > > Date: Tue, May 28, 2019 at 2:47 PM > > > Subject: Re: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on > > > startup > > > To: Marcus Hirt > > > > > > > > > Hi, > > > > > > This is updated to change all JMC callers of MCPathEditorInput(File) > > > to use the alternative constructor as requested. > > > > > > Arvin Kangcheng Xu > > > > > > On Fri, May 24, 2019 at 9:18 PM Kangcheng Xu wrote: > > > > > > > > Hello, > > > > > > > > On Fri, May 24, 2019 at 8:12 PM Marcus Hirt wrote: > > > > > > > > > > Hi there! > > > > > > > > > > There seem to be other users of that class that use the default > > > > > constructor presumably because they do not want to persist their > > > > > opening of files, such as trigger actions. One could argue that > > > > > maybe they should end up in the recently opened list too, but I > > > > > believe this is at least the reason for the current behavior. > > > > > > > > Yes, I agree with you. Sorry I didn't realize this earlier. > > > > > > > > > A slightly more defensive solution could be to instead: > > > > > > > > > > diff -r 4c9efa5eb5b8 > application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java > > > > > --- > a/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java > Fri May 24 13:05:05 2019 +0200 > > > > > +++ > b/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java > Sat May 25 01:59:12 2019 +0200 > > > > > @@ -161,7 +161,7 @@ > > > > > for (String name : names) { > > > > > final File file = new > File(filterPath + File.separator + name); > > > > > if (file.exists()) { > > > > > - > WorkbenchToolkit.openEditor(inWindow, new MCPathEditorInput(file)); > > > > > + > > > > > + WorkbenchToolkit.openEditor(inWindow, new > > > > > + MCPathEditorInput(file, true)); > > > > > } else { > > > > > if > (++numberOfFilesNotFound > 1) { > > > > > > > > > > notFound.append('\n'); > > > > > > > > A modified patch file is attached. Additionally, > > > > `MCPathEditorInput(File)' constructor is now marked deprecated. > > > > > > > > > Kind regards, > > > > > Marcus > > > > > > > > Thanks very much for the advice! > > > > > > > > Arvin Kangcheng Xu > > > From almacdon at redhat.com Thu Jun 27 18:49:50 2019 From: almacdon at redhat.com (almacdon at redhat.com) Date: Thu, 27 Jun 2019 18:49:50 +0000 Subject: hg: jmc/jmc: JMC-6484: "Recent Files" sub-menu not populated on startup Message-ID: <201906271849.x5RIno0O028598@aojmv0008.oracle.com> Changeset: d21dff9c3d4d Author: aptmac Date: 2019-06-27 14:41 -0400 URL: http://hg.openjdk.java.net/jmc/jmc/rev/d21dff9c3d4d JMC-6484: "Recent Files" sub-menu not populated on startup Summary: Marked MCPathEditorInput(File) constructor deprecated. Updated all callers to use the alternative constructor. Contributed-by: Kangcheng Xu ! application/org.openjdk.jmc.console.ui.notification/src/main/java/org/openjdk/jmc/console/ui/notification/action/TriggerActionStartTimeBoundRecording.java ! application/org.openjdk.jmc.console.ui.notification/src/main/java/org/openjdk/jmc/console/ui/notification/action/WriteAndOpenRecordingJob.java ! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/jobs/DumpRecordingJob.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrEditor.java ! application/org.openjdk.jmc.ide.launch/src/main/java/org/openjdk/jmc/ide/launch/JfrLaunchDelegateHelper.java ! application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/HeapDumpAction.java ! application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/MissionControlEditorDropAdapter.java ! application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/OpenDocumentEventProcessor.java ! application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java ! application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/commands/OpenFile.java ! application/org.openjdk.jmc.rcp.intro/src/main/java/org/openjdk/jmc/rcp/intro/FlightRecordingExampleAction.java ! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/MCPathEditorInput.java ! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/TestHelper.java From almacdon at redhat.com Thu Jun 27 19:23:42 2019 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 27 Jun 2019 15:23:42 -0400 Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies In-Reply-To: <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com> References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com> <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com> <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com> Message-ID: 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. Cheers, Alex [0] http://hg.openjdk.java.net/jmc/jmc/rev/5e0a199762b6 > > > > Hi Elliott, > > > > For what it's worth, I asked a native Chinese speaker to look at the > > Chinese translations without knowledge of the English ones and he says > > they make sense and was also able to translate them to what was > > written in English. > > > > That's good to hear. Thanks for your help! > > Elliott > From jkang at redhat.com Thu Jun 27 21:38:12 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 27 Jun 2019 17:38:12 -0400 Subject: Review request JMC-6512: for Competing CPU load rule should take overall load into account In-Reply-To: References: Message-ID: Hi Florian, 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; # 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. # 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 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 christoph.langer at sap.com Fri Jun 28 19:57:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 28 Jun 2019 19:57:50 +0000 Subject: JMC-6513: Wrong version of compiled classes when importing JMC maven projects in Eclipse with JDT Default Compiler Level of 11 Message-ID: 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 Fri Jun 28 20:45:03 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Fri, 28 Jun 2019 22:45:03 +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: 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 > > >