From hdafgard at gmail.com Sat Dec 1 15:32:09 2018 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Sat, 1 Dec 2018 16:32:09 +0100 Subject: JMC-6208 Fix font rendering on macOS Message-ID: Hi all, http://cr.openjdk.java.net/~hdafgard/6208/webrev.0/ https://bugs.openjdk.java.net/browse/JMC-6208 Font rendering on macOS Mojave regressed when Apple disabled subpixel font rendering by default, but the root cause on our side was that we never actually applied the anti-aliasing preferences in AwtCanvas, which was used by the JFR GUI. This is why the Console GUI looks fine, since it gets a graphics context in a different way and properly applies AA. Regards, Henrik Dafg?rd From marcus at hirt.se Sat Dec 1 18:16:58 2018 From: marcus at hirt.se (Marcus Hirt) Date: Sat, 1 Dec 2018 19:16:58 +0100 Subject: SV: JMC-6208 Fix font rendering on macOS In-Reply-To: References: Message-ID: <097001d489a2$0c53e900$24fbbb00$@hirt.se> Looks great! Thanks for the contribution! Feel free to push at your leisure. /M -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Henrik Dafg?rd Skickat: den 1 december 2018 16:32 Till: jmc-dev at openjdk.java.net ?mne: JMC-6208 Fix font rendering on macOS Hi all, http://cr.openjdk.java.net/~hdafgard/6208/webrev.0/ https://bugs.openjdk.java.net/browse/JMC-6208 Font rendering on macOS Mojave regressed when Apple disabled subpixel font rendering by default, but the root cause on our side was that we never actually applied the anti-aliasing preferences in AwtCanvas, which was used by the JFR GUI. This is why the Console GUI looks fine, since it gets a graphics context in a different way and properly applies AA. Regards, Henrik Dafg?rd From marcus at hirt.se Mon Dec 3 11:33:26 2018 From: marcus at hirt.se (Marcus Hirt) Date: Mon, 3 Dec 2018 12:33:26 +0100 Subject: RFR: JMC-6124: Defaulting to OpenJDK 11 development launchers, and moving the old Oracle JDK 8 specific launchers Message-ID: <32db01d48afc$01e2a7d0$05a7f770$@hirt.se> Hi all, Please review this fix to use OpenJDK 11 development launchers by default, and providing a separate set of Oracle JDK launchers. Jira: https://bugs.openjdk.java.net/browse/JMC-6214 Patch: http://cr.openjdk.java.net/~hirt/JMC-6214/launcherdiff.txt Kind regards, Marcus From jkang at redhat.com Mon Dec 3 13:49:28 2018 From: jkang at redhat.com (Jie Kang) Date: Mon, 3 Dec 2018 08:49:28 -0500 Subject: JMC package and linking libraries Message-ID: Hi, When sym-linking all dependent library jars, JMC unfortunately pulls in eclipse-platform package as a dependency to satisfy some of the jars. This package brings in 397 M worth of dependencies, even though the jars that we are interested in are only a tiny fraction of that; JMC itself is less than 70 M, with the RPM being slightly smaller due to some features being removed. I think Fedora's bundled library policy has become less strict but it would still not correct for us to deliver JMC with eclipse packages bundled. I don't think there's anything we can do except ask for the eclipse package to ship sub-packages, if at all possible. Is this even an issue to worry about? Regards, From hdafgard at gmail.com Mon Dec 3 14:10:43 2018 From: hdafgard at gmail.com (hdafgard at gmail.com) Date: Mon, 03 Dec 2018 14:10:43 +0000 Subject: hg: jmc/jmc: JMC-6208 support anti-aliasing preferences for AwtCanvas Message-ID: <201812031410.wB3EAhFb018685@aojmv0008.oracle.com> Changeset: c83d9167ba4e Author: hdafgard Date: 2018-11-23 11:56 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/c83d9167ba4e JMC-6208 support anti-aliasing preferences for AwtCanvas ! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/misc/AwtCanvas.java From kdobson at redhat.com Mon Dec 3 14:51:43 2018 From: kdobson at redhat.com (Ken Dobson) Date: Mon, 3 Dec 2018 09:51:43 -0500 Subject: JMC-5698: Improving Duplicate Flags rule In-Reply-To: <8E97560D-21D2-4E00-A13F-F773FDF6CB82@oracle.com> References: <7A9BCC98-8205-4ADF-9B5D-E743717704D4@redhat.com> <87621B9B-A7F4-4A58-B8DD-74B3B8ECF6E4@oracle.com> <8E97560D-21D2-4E00-A13F-F773FDF6CB82@oracle.com> Message-ID: I've attached a patch file. Mario would you be able to sponsor this? Thanks, Ken On Fri, Nov 30, 2018 at 5:15 PM Marcus Hirt wrote: > Hi Ken, > > You're good to go! > > Kind regards, > Marcus > > On 2018-11-23, 21:50, "jmc-dev on behalf of Joshua Matsuoka" < > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> wrote: > > > I've applied and taken a look at the changes and they look good! > > Cheers, > > - Josh > > (Resending to list without the very long quoted message) > > ?On 2018-11-08, 22:52, "jmc-dev on behalf of Marcus Hirt" < > jmc-dev-bounces at openjdk.java.net on behalf of marcus.hirt at oracle.com> > wrote: > > Hi Ken, > > I took a quick look, and it looks fine to me. If someone else could > take a closer look, that would be great! > > Kind regards, > Marcus > > ?On 2018-11-08, 22:11, "jmc-dev on behalf of Ken Dobson" < > jmc-dev-bounces at openjdk.java.net on behalf of kdobson at redhat.com> wrote: > > Hi all, > > This is a patch to improve the output of the Duplicate Flags rule > to be > more clear. I've attached a screenshot showing the new output. > Please > review it and let me know if you have any comments. > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 > > Thanks, > > Ken Dobson > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: duplicateflagswtest.patch Type: text/x-patch Size: 11901 bytes Desc: not available URL: From neugens at redhat.com Mon Dec 3 15:08:02 2018 From: neugens at redhat.com (Mario Torre) Date: Mon, 03 Dec 2018 16:08:02 +0100 Subject: JMC-5698: Improving Duplicate Flags rule In-Reply-To: References: <7A9BCC98-8205-4ADF-9B5D-E743717704D4@redhat.com> <87621B9B-A7F4-4A58-B8DD-74B3B8ECF6E4@oracle.com> <8E97560D-21D2-4E00-A13F-F773FDF6CB82@oracle.com> Message-ID: <8a2788fec0820d67dc2890efc86e3bb5524a80f5.camel@redhat.com> On Mon, 2018-12-03 at 09:51 -0500, Ken Dobson wrote: > I've attached a patch file. Mario would you be able to sponsor this? > > Thanks, > > Ken Sure, I'll do so today. Cheers, Mario > On Fri, Nov 30, 2018 at 5:15 PM Marcus Hirt > wrote: > > > Hi Ken, > > > > You're good to go! > > > > Kind regards, > > Marcus > > > > On 2018-11-23, 21:50, "jmc-dev on behalf of Joshua Matsuoka" < > > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> > > wrote: > > > > > > I've applied and taken a look at the changes and they look > > good! > > > > Cheers, > > > > - Josh > > > > (Resending to list without the very long quoted message) > > > > ?On 2018-11-08, 22:52, "jmc-dev on behalf of Marcus Hirt" < > > jmc-dev-bounces at openjdk.java.net on behalf of > > marcus.hirt at oracle.com> > > wrote: > > > > Hi Ken, > > > > I took a quick look, and it looks fine to me. If someone else > > could > > take a closer look, that would be great! > > > > Kind regards, > > Marcus > > > > ?On 2018-11-08, 22:11, "jmc-dev on behalf of Ken Dobson" < > > jmc-dev-bounces at openjdk.java.net on behalf of kdobson at redhat.com> > > wrote: > > > > Hi all, > > > > This is a patch to improve the output of the Duplicate > > Flags rule > > to be > > more clear. I've attached a screenshot showing the new > > output. > > Please > > review it and let me know if you have any comments. > > > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 > > > > Thanks, > > > > Ken Dobson > > > > > > > > -- 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 Dec 3 15:11:14 2018 From: jkang at redhat.com (Jie Kang) Date: Mon, 3 Dec 2018 10:11:14 -0500 Subject: JMC package and linking libraries In-Reply-To: References: Message-ID: Hi, Sorry for the noise all, I didn't intend to send this to list. For more context, it's to do with attempts to package JMC in Fedora that Salman announced @ http://mail.openjdk.java.net/pipermail/jmc-dev/2018-November/000424.html Sincere apologies, On Mon, Dec 3, 2018 at 8:49 AM Jie Kang wrote: > > Hi, > > When sym-linking all dependent library jars, JMC unfortunately pulls > in eclipse-platform package as a dependency to satisfy some of the > jars. This package brings in 397 M worth of dependencies, even though > the jars that we are interested in are only a tiny fraction of that; > JMC itself is less than 70 M, with the RPM being slightly smaller due > to some features being removed. > > I think Fedora's bundled library policy has become less strict but it > would still not correct for us to deliver JMC with eclipse packages > bundled. I don't think there's anything we can do except ask for the > eclipse package to ship sub-packages, if at all possible. Is this even > an issue to worry about? > > > Regards, From guru.hb at oracle.com Mon Dec 3 15:18:46 2018 From: guru.hb at oracle.com (Guru) Date: Mon, 3 Dec 2018 20:48:46 +0530 Subject: RFR: JMC-6124: Defaulting to OpenJDK 11 development launchers, and moving the old Oracle JDK 8 specific launchers In-Reply-To: <32db01d48afc$01e2a7d0$05a7f770$@hirt.se> References: <32db01d48afc$01e2a7d0$05a7f770$@hirt.se> Message-ID: <743E93A0-6D20-4E07-80EC-4F750BCD7FB5@oracle.com> +1 looks good to me. > On 03-Dec-2018, at 5:03 PM, Marcus Hirt wrote: > > Hi all, > > Please review this fix to use OpenJDK 11 development launchers by default, > and providing a separate set of Oracle JDK launchers. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6214 > Patch: http://cr.openjdk.java.net/~hirt/JMC-6214/launcherdiff.txt > > Kind regards, > Marcus > From almacdon at redhat.com Mon Dec 3 15:22:55 2018 From: almacdon at redhat.com (Alex Macdonald) Date: Mon, 3 Dec 2018 10:22:55 -0500 Subject: RFR: JMC-6149: Distinguish by package with default packages in the traces does not work Message-ID: Hi, This patch addresses JMC-6149 [0], in which the stack trace tree disappears when a default package is encountered when selecting the option "Distinguish Frames by Package". For testing purposes, I have been using the memoryleak.jfr recording that is available as an attachment on JMC-6127 [1] The problem here is a NPE being thrown when checking whether if the category object equals the cached lastCategory object [2]. If the current frame has no corresponding package then the package attribute will be null [3], which then causes "category" to be null. In StructTypes.java [4], there are precautions in place for handling unknown methods and classes [5] so null values aren't passed around, but nothing in place to handle unknown packages. This patch introduces a null check in the IMCType implementation to mimic how the method [6] and class [7] implementations currently handle null values. Additionally, a null check must be made in the convertNames() and getName() methods that access the package name, because if it is null then the MethodToolkit.refTypeToBinaryJLS() [8] will throw an NPE when trying to get the length of the name. I've taken a couple screenshots to show the before and after of this patch, as well as a couple gifs to show how to reproduce the behaviour. Link to imgur album: https://imgur.com/a/0hNekjh Before (image): https://imgur.com/VnvwMkQ Before (gif): https://imgur.com/gZcPDCF After (image): https://imgur.com/TOyalSG After (gif): https://imgur.com/7GaCMII Thoughts? Cheers, Alex [0] https://bugs.openjdk.java.net/browse/JMC-6149 [1] https://bugs.openjdk.java.net/browse/JMC-6127 [2] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModel.java#l197 [3] https://imgur.com/ktUJvo5 [4] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java [5] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l67 [6] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l580 [7] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l661 [8] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MethodToolkit.java#l219 -------------- next part -------------- A non-text attachment was scrubbed... Name: 6149-0.patch Type: text/x-patch Size: 1977 bytes Desc: not available URL: From marcus.hirt at oracle.com Mon Dec 3 15:25:16 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Mon, 03 Dec 2018 15:25:16 +0000 Subject: hg: jmc/jmc: JMC-6124: Defaulting to OpenJDK 11 development launchers and providing a separate set of Oracle JDK 8 launchers Message-ID: <201812031525.wB3FPG6V024972@aojmv0008.oracle.com> Changeset: e7f91b6dc4c5 Author: hirt Date: 2018-12-03 16:23 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/e7f91b6dc4c5 JMC-6124: Defaulting to OpenJDK 11 development launchers and providing a separate set of Oracle JDK 8 launchers Reviewed-by: ghb + configuration/ide/eclipse/launchers/JMC Eclipse (JDK 8).launch + configuration/ide/eclipse/launchers/JMC Eclipse plug-ins (JDK 8).launch ! configuration/ide/eclipse/launchers/JMC Eclipse plug-ins.launch ! configuration/ide/eclipse/launchers/JMC Eclipse.launch + configuration/ide/eclipse/launchers/JMC RCP (JDK 8).launch + configuration/ide/eclipse/launchers/JMC RCP plug-ins (JDK 8).launch ! configuration/ide/eclipse/launchers/JMC RCP plug-ins.launch ! configuration/ide/eclipse/launchers/JMC RCP.launch ! configuration/ide/eclipse/launchers/Remote RCP Debugging.launch From marcus.hirt at oracle.com Mon Dec 3 15:35:35 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Mon, 03 Dec 2018 16:35:35 +0100 Subject: Switching Eclipse. Message-ID: <585D0CC1-9B83-4CC7-ADFE-7C3FC6D5AA5E@oracle.com> Hi all, For the development launchers for OpenJDK 11 to work properly, I suggest switching to Eclipse 2018-09 and installing the JDK 11 plug-in from the Eclipse Marketplace. Eclipse 2018-12, whilst almost ready, will not be available until the 19th (it will however not require a plug-in for JDK 11 support). Kind regards, Marcus From marcus.hirt at oracle.com Mon Dec 3 15:40:10 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Mon, 03 Dec 2018 16:40:10 +0100 Subject: JMC-6149: Distinguish by package with default packages in the traces does not work In-Reply-To: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> References: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> Message-ID: Looks good Alex! Kind regards, Marcus ?On 2018-12-03, 16:25, "jmc-dev on behalf of Alex Macdonald" wrote: Hi, This patch addresses JMC-6149 [0], in which the stack trace tree disappears when a default package is encountered when selecting the option "Distinguish Frames by Package". For testing purposes, I have been using the memoryleak.jfr recording that is available as an attachment on JMC-6127 [1] The problem here is a NPE being thrown when checking whether if the category object equals the cached lastCategory object [2]. If the current frame has no corresponding package then the package attribute will be null [3], which then causes "category" to be null. In StructTypes.java [4], there are precautions in place for handling unknown methods and classes [5] so null values aren't passed around, but nothing in place to handle unknown packages. This patch introduces a null check in the IMCType implementation to mimic how the method [6] and class [7] implementations currently handle null values. Additionally, a null check must be made in the convertNames() and getName() methods that access the package name, because if it is null then the MethodToolkit.refTypeToBinaryJLS() [8] will throw an NPE when trying to get the length of the name. I've taken a couple screenshots to show the before and after of this patch, as well as a couple gifs to show how to reproduce the behaviour. Link to imgur album: https://imgur.com/a/0hNekjh Before (image): https://imgur.com/VnvwMkQ Before (gif): https://imgur.com/gZcPDCF After (image): https://imgur.com/TOyalSG After (gif): https://imgur.com/7GaCMII Thoughts? Cheers, Alex [0] https://bugs.openjdk.java.net/browse/JMC-6149 [1] https://bugs.openjdk.java.net/browse/JMC-6127 [2] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModel.java#l197 [3] https://imgur.com/ktUJvo5 [4] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java [5] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l67 [6] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l580 [7] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l661 [8] http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MethodToolkit.java#l219 From neugens.limasoftware at gmail.com Mon Dec 3 15:55:06 2018 From: neugens.limasoftware at gmail.com (neugens.limasoftware at gmail.com) Date: Mon, 03 Dec 2018 15:55:06 +0000 Subject: hg: jmc/jmc: JMC-5698: Improving Duplicate Flags Rule Message-ID: <201812031555.wB3Ft72Z009374@aojmv0008.oracle.com> Changeset: bf99a1135248 Author: neugens Date: 2018-12-03 16:54 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/bf99a1135248 JMC-5698: Improving Duplicate Flags Rule Summary: Improve clarity by outputting the specific flags that are duplicates of each other Reviewedby: hirt, Jmatsuoka contributed-by: Ken Dobson ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/JvmInternalsDataProvider.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml From jmatsuok at redhat.com Mon Dec 3 16:52:47 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Mon, 3 Dec 2018 11:52:47 -0500 Subject: JMC-6222 Allow filtering by package for the Method Profiling Rule In-Reply-To: <18465BD2-DBCB-4949-BBF4-92B2A50D8E60@oracle.com> References: <9F04118A-ABD3-4A53-8F7B-16060B5EAC9C@redhat.com> <18465BD2-DBCB-4949-BBF4-92B2A50D8E60@oracle.com> Message-ID: Hi Marcus, Here's an updated webrev: http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.01/ Cheers, - Josh On Fri, Nov 30, 2018 at 5:23 PM Marcus Hirt wrote: > Hi Josh! > > Quickly tried your patch, but get this: > java.util.concurrent.ExecutionException: > java.lang.UnsupportedOperationException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.openjdk.jmc.flightrecorder.ui.RuleManager$EvaluateJob.run(RuleManager.java:117) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) > Caused by: java.lang.UnsupportedOperationException > at java.util.AbstractList.remove(AbstractList.java:161) > at java.util.AbstractList$Itr.remove(AbstractList.java:374) > at java.util.AbstractCollection.removeAll(AbstractCollection.java:376) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1$1.processPath(MethodProfilingRule.java:462) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1$1.getValue(MethodProfilingRule.java:421) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1$1.getValue(MethodProfilingRule.java:405) > at > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl.getValue(GroupingAggregator.java:164) > at > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl.getValue(GroupingAggregator.java:134) > at > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Aggregators.java:97) > at > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Aggregators.java:81) > at > org.openjdk.jmc.flightrecorder.ui.ItemIterableToolkit.aggregate(ItemIterableToolkit.java:128) > at > org.openjdk.jmc.flightrecorder.ui.ItemCollectionToolkit$StreamBackedItemCollection.getAggregate(ItemCollectionToolkit.java:91) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1.performCalculation(MethodProfilingRule.java:467) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1.visitWindow(MethodProfilingRule.java:344) > at > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.slidingWindowUnordered(SlidingWindowToolkit.java:200) > at > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.slidingWindowUnordered(SlidingWindowToolkit.java:158) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.getResult(MethodProfilingRule.java:239) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.access$000(MethodProfilingRule.java:97) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$MethodProfilingCallable.call(MethodProfilingRule.java:196) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$MethodProfilingCallable.call(MethodProfilingRule.java:184) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.lang.Thread.run(Thread.java:748) > > The regexp used: > java\.util\..* > And input file: > The "before" file from here: > > https://github.com/thegreystone/jmc-tutorial/tree/master/projects/02_JFR_HotMethods > > Kind regards, > Marcus > > ?On 2018-11-30, 17:25, "jmc-dev on behalf of Joshua Matsuoka" < > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> wrote: > > Hi, > > The following patch adds support for filtering the method profiling > rule by > package name. When a regex is supplied via TypedPreferences, it will > drop > any frames matching the regex until reaching the first one that doesnt > match, treating that one as the hot frame. > > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.00/jmc.patch > > Thoughts? > > Bug ID: > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6222?filter=allopenissues > > Cheers, > > - Josh > > > > > From marcus at hirt.se Mon Dec 3 18:35:55 2018 From: marcus at hirt.se (Marcus Hirt) Date: Mon, 3 Dec 2018 19:35:55 +0100 Subject: SV: JMC-6222 Allow filtering by package for the Method Profiling Rule In-Reply-To: References: <9F04118A-ABD3-4A53-8F7B-16060B5EAC9C@redhat.com> <18465BD2-DBCB-4949-BBF4-92B2A50D8E60@oracle.com> Message-ID: <37a601d48b37$06f0bf10$14d23d30$@hirt.se> Hi Josh, Probably just want to look at the package: MethodProfilingRule at 454: Matcher m = excludes.matcher(frame.getMethod().getType().getPackage().getName()); I think it would be nice to add the following as default: public static final TypedPreference EXCLUDED_PACKAGE_REGEXP = new TypedPreference<>( "method.profiling.evaluation.excluded.package", //$NON-NLS-1$ Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES), Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES_DESC), UnitLookup.PLAIN_TEXT.getPersister(), "java\\.(lang|util)"); Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Joshua Matsuoka Skickat: den 3 december 2018 17:53 Till: Marcus Hirt Kopia: jmc-dev at openjdk.java.net ?mne: Re: JMC-6222 Allow filtering by package for the Method Profiling Rule Hi Marcus, Here's an updated webrev: http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.01/ Cheers, - Josh On Fri, Nov 30, 2018 at 5:23 PM Marcus Hirt wrote: > Hi Josh! > > Quickly tried your patch, but get this: > java.util.concurrent.ExecutionException: > java.lang.UnsupportedOperationException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.openjdk.jmc.flightrecorder.ui.RuleManager$EvaluateJob.run(RuleMana > ger.java:117) at > org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) > Caused by: java.lang.UnsupportedOperationException > at java.util.AbstractList.remove(AbstractList.java:161) > at java.util.AbstractList$Itr.remove(AbstractList.java:374) > at java.util.AbstractCollection.removeAll(AbstractCollection.java:376) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > $1.processPath(MethodProfilingRule.java:462) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > $1.getValue(MethodProfilingRule.java:421) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > $1.getValue(MethodProfilingRule.java:405) > at > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > getValue(GroupingAggregator.java:164) > at > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > getValue(GroupingAggregator.java:134) > at > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > regators.java:97) > at > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > regators.java:81) > at > org.openjdk.jmc.flightrecorder.ui.ItemIterableToolkit.aggregate(ItemIt > erableToolkit.java:128) > at > org.openjdk.jmc.flightrecorder.ui.ItemCollectionToolkit$StreamBackedIt > emCollection.getAggregate(ItemCollectionToolkit.java:91) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > .performCalculation(MethodProfilingRule.java:467) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > .visitWindow(MethodProfilingRule.java:344) > at > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > WindowUnordered(SlidingWindowToolkit.java:200) > at > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > WindowUnordered(SlidingWindowToolkit.java:158) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.g > etResult(MethodProfilingRule.java:239) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.a > ccess$000(MethodProfilingRule.java:97) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > ethodProfilingCallable.call(MethodProfilingRule.java:196) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > ethodProfilingCallable.call(MethodProfilingRule.java:184) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.lang.Thread.run(Thread.java:748) > > The regexp used: > java\.util\..* > And input file: > The "before" file from here: > > https://github.com/thegreystone/jmc-tutorial/tree/master/projects/02_J > FR_HotMethods > > Kind regards, > Marcus > > ?On 2018-11-30, 17:25, "jmc-dev on behalf of Joshua Matsuoka" < > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> wrote: > > Hi, > > The following patch adds support for filtering the method > profiling rule by > package name. When a regex is supplied via TypedPreferences, it > will drop > any frames matching the regex until reaching the first one that doesnt > match, treating that one as the hot frame. > > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.00/jmc.patch > > Thoughts? > > Bug ID: > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6222?filter=allo > penissues > > Cheers, > > - Josh > > > > > From almacdon at redhat.com Mon Dec 3 19:58:28 2018 From: almacdon at redhat.com (Alex Macdonald) Date: Mon, 3 Dec 2018 14:58:28 -0500 Subject: JMC-6149: Distinguish by package with default packages in the traces does not work In-Reply-To: References: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> Message-ID: Hi Marcus, On Mon, Dec 3, 2018 at 10:40 AM Marcus Hirt wrote: > Looks good Alex! > > Kind regards, > Marcus > Great! Thanks for reviewing it. I've attached an exported patch ready for pushing, Mario are you able to sponsor this one? Cheers, Alex > > ?On 2018-12-03, 16:25, "jmc-dev on behalf of Alex Macdonald" < > jmc-dev-bounces at openjdk.java.net on behalf of almacdon at redhat.com> wrote: > > Hi, > > This patch addresses JMC-6149 [0], in which the stack trace tree > disappears > when a default package is encountered when selecting the option > "Distinguish Frames by Package". For testing purposes, I have been > using > the memoryleak.jfr recording that is available as an attachment on > JMC-6127 > [1] > > The problem here is a NPE being thrown when checking whether if the > category object equals the cached lastCategory object [2]. If the > current > frame has no corresponding package then the package attribute will be > null > [3], which then causes "category" to be null. > > In StructTypes.java [4], there are precautions in place for handling > unknown methods and classes [5] so null values aren't passed around, > but > nothing in place to handle unknown packages. This patch introduces a > null > check in the IMCType implementation to mimic how the method [6] and > class > [7] implementations currently handle null values. Additionally, a null > check must be made in the convertNames() and getName() methods that > access > the package name, because if it is null then the > MethodToolkit.refTypeToBinaryJLS() [8] will throw an NPE when trying > to get > the length of the name. > > I've taken a couple screenshots to show the before and after of this > patch, > as well as a couple gifs to show how to reproduce the behaviour. Link > to > imgur album: https://imgur.com/a/0hNekjh > > Before (image): https://imgur.com/VnvwMkQ > Before (gif): https://imgur.com/gZcPDCF > After (image): https://imgur.com/TOyalSG > After (gif): https://imgur.com/7GaCMII > > Thoughts? > > Cheers, > > Alex > > [0] https://bugs.openjdk.java.net/browse/JMC-6149 > [1] https://bugs.openjdk.java.net/browse/JMC-6127 > [2] > > http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModel.java#l197 > [3] https://imgur.com/ktUJvo5 > [4] > > http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java > [5] > > http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l67 > [6] > > http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l580 > [7] > > http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l661 > [8] > > http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MethodToolkit.java#l219 > > > > > From ebaron at redhat.com Tue Dec 4 00:24:05 2018 From: ebaron at redhat.com (Elliott Baron) Date: Mon, 3 Dec 2018 19:24:05 -0500 Subject: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables Message-ID: <7af50a8e-fb2d-ab54-2084-f67c494cc14c@redhat.com> Hi, This patch fixes an issue where font sizes vary between columns of certain trees and tables, when the user changes the editor font size. This happens for columns that use the JFace text font, which is also used for text editors in Eclipse. The text font is used as a visual hint for columns that may contain editable values. Other columns use the JFace default font, which derives from the native system default. This simple fix creates a separate font, derived from the JFace text font, that sets its height to that of the default font. This ensures tree/table columns have consistent font sizes, while also retaining the text font face as an indicator for modifiable fields. The font is added to the shared JFace FontRegistry, and is disposed of along with the Display. I have included a new UI test case to verify that our modified font is used for the LabelProvider that was previously using the JFace text font. While I made progress towards some of the other goals mentioned in the bug, such as allowing all text in JMC to have its size adjusted using keyboard shortcuts, we decided to defer such a far-reaching change to a later date [1]. Perhaps we could create another bug for such a feature. How does the attached patch look? Thanks, Elliott [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2018-November/000456.html -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6180.patch Type: text/x-patch Size: 10355 bytes Desc: not available URL: From neugens at redhat.com Tue Dec 4 07:46:50 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 4 Dec 2018 08:46:50 +0100 Subject: JMC-6149: Distinguish by package with default packages in the traces does not work In-Reply-To: References: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> Message-ID: Hi Alex, I pushed the fix. While checking it out, I thought it would be nice to use a different indication for the default package, "null" sounds weird, especially since the package name isn't really "null", at most an empty string. Do you think we can follow up this fix with some other string, perhaps something like "Default Package"? Marcus, do you think this is a good idea? Cheers, Mario On Mon, Dec 3, 2018 at 8:59 PM Alex Macdonald wrote: > > Hi Marcus, > > On Mon, Dec 3, 2018 at 10:40 AM Marcus Hirt wrote: >> >> Looks good Alex! >> >> Kind regards, >> Marcus > > > Great! Thanks for reviewing it. > > I've attached an exported patch ready for pushing, Mario are you able to sponsor this one? > > Cheers, > > Alex > >> >> >> ?On 2018-12-03, 16:25, "jmc-dev on behalf of Alex Macdonald" wrote: >> >> Hi, >> >> This patch addresses JMC-6149 [0], in which the stack trace tree disappears >> when a default package is encountered when selecting the option >> "Distinguish Frames by Package". For testing purposes, I have been using >> the memoryleak.jfr recording that is available as an attachment on JMC-6127 >> [1] >> >> The problem here is a NPE being thrown when checking whether if the >> category object equals the cached lastCategory object [2]. If the current >> frame has no corresponding package then the package attribute will be null >> [3], which then causes "category" to be null. >> >> In StructTypes.java [4], there are precautions in place for handling >> unknown methods and classes [5] so null values aren't passed around, but >> nothing in place to handle unknown packages. This patch introduces a null >> check in the IMCType implementation to mimic how the method [6] and class >> [7] implementations currently handle null values. Additionally, a null >> check must be made in the convertNames() and getName() methods that access >> the package name, because if it is null then the >> MethodToolkit.refTypeToBinaryJLS() [8] will throw an NPE when trying to get >> the length of the name. >> >> I've taken a couple screenshots to show the before and after of this patch, >> as well as a couple gifs to show how to reproduce the behaviour. Link to >> imgur album: https://imgur.com/a/0hNekjh >> >> Before (image): https://imgur.com/VnvwMkQ >> Before (gif): https://imgur.com/gZcPDCF >> After (image): https://imgur.com/TOyalSG >> After (gif): https://imgur.com/7GaCMII >> >> Thoughts? >> >> Cheers, >> >> Alex >> >> [0] https://bugs.openjdk.java.net/browse/JMC-6149 >> [1] https://bugs.openjdk.java.net/browse/JMC-6127 >> [2] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModel.java#l197 >> [3] https://imgur.com/ktUJvo5 >> [4] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java >> [5] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l67 >> [6] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l580 >> [7] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l661 >> [8] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/MethodToolkit.java#l219 >> >> >> >> -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens.limasoftware at gmail.com Tue Dec 4 07:43:51 2018 From: neugens.limasoftware at gmail.com (neugens.limasoftware at gmail.com) Date: Tue, 04 Dec 2018 07:43:51 +0000 Subject: hg: jmc/jmc: JMC-6149: Distinguish by package with default packages in the traces does not work Message-ID: <201812040743.wB47hpPF028721@aojmv0008.oracle.com> Changeset: 96ff10493237 Author: neugens Date: 2018-12-04 08:43 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/96ff10493237 JMC-6149: Distinguish by package with default packages in the traces does not work Reviewed-by: hirt Contributed-by: Alex Macdonald ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java From marcus at hirt.se Tue Dec 4 10:29:03 2018 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 4 Dec 2018 11:29:03 +0100 Subject: SV: JMC-6149: Distinguish by package with default packages in the traces does not work In-Reply-To: References: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> Message-ID: <3acf01d48bbc$2d9cf2c0$88d6d840$@hirt.se> Hi Mario, Agreed. That said, there is perhaps a need render a stand alone default package in a human readable way, and what the core API itself returns. The API needs to return a valid package name, possibly the empty string (or null) for the default package. When we _render_ the default package, it depends on the context how we probably want to render. As part of a FQN, it should be the empty string. As a stand-alone package only rendering in the StackTrace-view, when grouping on package, possibly something like , to underline that there is a package and not a missing data error. Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Mario Torre Skickat: den 4 december 2018 08:47 Till: Alex Macdonald Kopia: jmc-dev at openjdk.java.net ?mne: Re: JMC-6149: Distinguish by package with default packages in the traces does not work Hi Alex, I pushed the fix. While checking it out, I thought it would be nice to use a different indication for the default package, "null" sounds weird, especially since the package name isn't really "null", at most an empty string. Do you think we can follow up this fix with some other string, perhaps something like "Default Package"? Marcus, do you think this is a good idea? Cheers, Mario On Mon, Dec 3, 2018 at 8:59 PM Alex Macdonald wrote: > > Hi Marcus, > > On Mon, Dec 3, 2018 at 10:40 AM Marcus Hirt wrote: >> >> Looks good Alex! >> >> Kind regards, >> Marcus > > > Great! Thanks for reviewing it. > > I've attached an exported patch ready for pushing, Mario are you able to sponsor this one? > > Cheers, > > Alex > >> >> >> ?On 2018-12-03, 16:25, "jmc-dev on behalf of Alex Macdonald" wrote: >> >> Hi, >> >> This patch addresses JMC-6149 [0], in which the stack trace tree disappears >> when a default package is encountered when selecting the option >> "Distinguish Frames by Package". For testing purposes, I have been using >> the memoryleak.jfr recording that is available as an attachment on JMC-6127 >> [1] >> >> The problem here is a NPE being thrown when checking whether if the >> category object equals the cached lastCategory object [2]. If the current >> frame has no corresponding package then the package attribute will be null >> [3], which then causes "category" to be null. >> >> In StructTypes.java [4], there are precautions in place for handling >> unknown methods and classes [5] so null values aren't passed around, but >> nothing in place to handle unknown packages. This patch introduces a null >> check in the IMCType implementation to mimic how the method [6] and class >> [7] implementations currently handle null values. Additionally, a null >> check must be made in the convertNames() and getName() methods that access >> the package name, because if it is null then the >> MethodToolkit.refTypeToBinaryJLS() [8] will throw an NPE when trying to get >> the length of the name. >> >> I've taken a couple screenshots to show the before and after of this patch, >> as well as a couple gifs to show how to reproduce the behaviour. Link to >> imgur album: https://imgur.com/a/0hNekjh >> >> Before (image): https://imgur.com/VnvwMkQ >> Before (gif): https://imgur.com/gZcPDCF >> After (image): https://imgur.com/TOyalSG >> After (gif): https://imgur.com/7GaCMII >> >> Thoughts? >> >> Cheers, >> >> Alex >> >> [0] https://bugs.openjdk.java.net/browse/JMC-6149 >> [1] https://bugs.openjdk.java.net/browse/JMC-6127 >> [2] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModel.java#l197 >> [3] https://imgur.com/ktUJvo5 >> [4] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java >> [5] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l67 >> [6] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l580 >> [7] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l661 >> [8] >> >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk >> .jmc.common/src/main/java/org/openjdk/jmc/common/util/MethodToolkit.j >> ava#l219 >> >> >> >> -- 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 Dec 4 10:32:04 2018 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 4 Dec 2018 11:32:04 +0100 Subject: SV: JMC-6149: Distinguish by package with default packages in the traces does not work In-Reply-To: References: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> Message-ID: <3ada01d48bbc$9998fdc0$cccaf940$@hirt.se> Trying that again. Heh. Hi Mario, Agreed. That said, there is probably a difference in how to render a stand alone default package in a human readable way, and what the core API itself returns. The API needs to return a valid package name, possibly the empty string (or null) for the default package. When we _render_ the default package, it depends on the context how we probably want to render. As part of a FQN, it should be the empty string. As a stand alone package only rendering in the StackTrace-view, when grouping on package, possibly something like , to underline that there is a package and not a missing data error. Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Mario Torre Skickat: den 4 december 2018 08:47 Till: Alex Macdonald Kopia: jmc-dev at openjdk.java.net ?mne: Re: JMC-6149: Distinguish by package with default packages in the traces does not work Hi Alex, I pushed the fix. While checking it out, I thought it would be nice to use a different indication for the default package, "null" sounds weird, especially since the package name isn't really "null", at most an empty string. Do you think we can follow up this fix with some other string, perhaps something like "Default Package"? Marcus, do you think this is a good idea? Cheers, Mario On Mon, Dec 3, 2018 at 8:59 PM Alex Macdonald wrote: > > Hi Marcus, > > On Mon, Dec 3, 2018 at 10:40 AM Marcus Hirt wrote: >> >> Looks good Alex! >> >> Kind regards, >> Marcus > > > Great! Thanks for reviewing it. > > I've attached an exported patch ready for pushing, Mario are you able to sponsor this one? > > Cheers, > > Alex > >> >> >> ?On 2018-12-03, 16:25, "jmc-dev on behalf of Alex Macdonald" wrote: >> >> Hi, >> >> This patch addresses JMC-6149 [0], in which the stack trace tree disappears >> when a default package is encountered when selecting the option >> "Distinguish Frames by Package". For testing purposes, I have been using >> the memoryleak.jfr recording that is available as an attachment on JMC-6127 >> [1] >> >> The problem here is a NPE being thrown when checking whether if the >> category object equals the cached lastCategory object [2]. If the current >> frame has no corresponding package then the package attribute will be null >> [3], which then causes "category" to be null. >> >> In StructTypes.java [4], there are precautions in place for handling >> unknown methods and classes [5] so null values aren't passed around, but >> nothing in place to handle unknown packages. This patch introduces a null >> check in the IMCType implementation to mimic how the method [6] and class >> [7] implementations currently handle null values. Additionally, a null >> check must be made in the convertNames() and getName() methods that access >> the package name, because if it is null then the >> MethodToolkit.refTypeToBinaryJLS() [8] will throw an NPE when trying to get >> the length of the name. >> >> I've taken a couple screenshots to show the before and after of this patch, >> as well as a couple gifs to show how to reproduce the behaviour. Link to >> imgur album: https://imgur.com/a/0hNekjh >> >> Before (image): https://imgur.com/VnvwMkQ >> Before (gif): https://imgur.com/gZcPDCF >> After (image): https://imgur.com/TOyalSG >> After (gif): https://imgur.com/7GaCMII >> >> Thoughts? >> >> Cheers, >> >> Alex >> >> [0] https://bugs.openjdk.java.net/browse/JMC-6149 >> [1] https://bugs.openjdk.java.net/browse/JMC-6127 >> [2] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModel.java#l197 >> [3] https://imgur.com/ktUJvo5 >> [4] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java >> [5] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l67 >> [6] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l580 >> [7] >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/StructTypes.java#l661 >> [8] >> >> http://hg.openjdk.java.net/jmc/jmc/file/997060a24c42/core/org.openjdk >> .jmc.common/src/main/java/org/openjdk/jmc/common/util/MethodToolkit.j >> ava#l219 >> >> >> >> -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Tue Dec 4 12:32:27 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 4 Dec 2018 13:32:27 +0100 Subject: JMC-6149: Distinguish by package with default packages in the traces does not work In-Reply-To: <3ada01d48bbc$9998fdc0$cccaf940$@hirt.se> References: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> <3ada01d48bbc$9998fdc0$cccaf940$@hirt.se> Message-ID: On Tue, Dec 4, 2018 at 11:32 AM Marcus Hirt wrote: > > Trying that again. Heh. > > Hi Mario, > > Agreed. That said, there is probably a difference in how to render a stand alone > default package in a human readable way, and what the core API itself returns. > The API needs to return a valid package name, possibly the empty string (or > null) for the default package. When we _render_ the default package, it depends > on the context how we probably want to render. As part of a FQN, it should be > the empty string. As a stand alone package only rendering in the > StackTrace-view, when grouping on package, possibly something like , > to underline that there is a package and not a missing data error. Yes, exactly what I had in mind, and works very well, I think this is what other tools use as well. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Tue Dec 4 14:14:36 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 04 Dec 2018 15:14:36 +0100 Subject: JMC-6149: Distinguish by package with default packages in the traces does not work In-Reply-To: References: <07DA27CC-7EA4-4C37-AF8C-1E331343DFC1@redhat.com> <3ada01d48bbc$9998fdc0$cccaf940$@hirt.se> Message-ID: <365163F3-E6E1-43E5-AA57-9B4A36131C73@oracle.com> Using brackets is also what we do in other places in JMC to denote special/empty values, for example in the selection and aspect combo-boxes, so it would fit well. Kind regards, Marcus ?On 2018-12-04, 13:34, "jmc-dev on behalf of Mario Torre" wrote: On Tue, Dec 4, 2018 at 11:32 AM Marcus Hirt wrote: > > Trying that again. Heh. > > Hi Mario, > > Agreed. That said, there is probably a difference in how to render a stand alone > default package in a human readable way, and what the core API itself returns. > The API needs to return a valid package name, possibly the empty string (or > null) for the default package. When we _render_ the default package, it depends > on the context how we probably want to render. As part of a FQN, it should be > the empty string. As a stand alone package only rendering in the > StackTrace-view, when grouping on package, possibly something like , > to underline that there is a package and not a missing data error. Yes, exactly what I had in mind, and works very well, I think this is what other tools use as well. Cheers, Mario -- 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 Dec 4 20:33:10 2018 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 4 Dec 2018 21:33:10 +0100 Subject: RFR: JMC-6206: Making the agent prototype work on OpenJDK 11 Message-ID: <4bd101d48c10$9231f560$b695e020$@hirt.se> Hi all, Please review this fix to get the early agent prototype to work on OpenJDK 11. Jira: https://bugs.openjdk.java.net/browse/JMC-6206 Patch: http://cr.openjdk.java.net/~hirt/JMC-6206/webrev.01/ Kind regards, Marcus From kdobson at redhat.com Tue Dec 4 20:43:46 2018 From: kdobson at redhat.com (Ken Dobson) Date: Tue, 4 Dec 2018 15:43:46 -0500 Subject: JMC-6241: Leaking Context Menu items Message-ID: Hi all, This patch does a couple things. 1. It fixes the leaking context menu items which resulted in the context menu having multiple sets of the same thread activity lanes listed. 2. It adds a context menu to the Garbage Collections Page legend as there already was one for the Java Application page. 3. Fixes a small bug that lead to the Thread Activity lane on the GC page only refreshing if it was turned off and then back on again. If someone could give it a review that would be great. https://bugs.openjdk.java.net/browse/JMC-6241 Thanks, Ken Dobson diff -r 4629e44fd8ea application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ThreadGraphLanes.java --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ThreadGraphLanes.java Thu Nov 08 12:45:05 2018 +0100 +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ThreadGraphLanes.java Tue Dec 04 15:08:07 2018 -0500 @@ -99,14 +99,14 @@ this.actions = new ArrayList<>(); } - public void openEditLanesDialog(MCContextMenuManager mm) { + public void openEditLanesDialog(MCContextMenuManager mm, boolean isLegendMenu) { // FIXME: Might there be other interesting events that don't really have duration? EventTypeFolderNode typeTree = dataSourceSupplier.get().getTypeTree(ItemCollectionToolkit .stream(dataSourceSupplier.get().getItems()).filter(this::typeWithThreadAndDuration)); laneDefs = LaneEditor.openDialog(typeTree, laneDefs.stream().collect(Collectors.toList()), Messages.JavaApplicationPage_EDIT_THREAD_LANES_DIALOG_TITLE, Messages.JavaApplicationPage_EDIT_THREAD_LANES_DIALOG_MESSAGE); - updateContextMenu(mm); + updateContextMenu(mm, isLegendMenu); buildChart.run(); } @@ -214,16 +214,26 @@ naLanes = lanesByApplicability.get(false); return Collections.emptyList(); } - - private List actionIdentifiers = new ArrayList<>(); + + //create two action identifiers to handle the chart context menu and the legend context menu + private List chartActionIdentifiers = new ArrayList<>(); + private List legendActionIdentifiers = new ArrayList<>(); - public void updateContextMenu(MCContextMenuManager mm) { - for (String id : actionIdentifiers) { - mm.remove(id); + public void updateContextMenu(MCContextMenuManager mm, boolean isLegendMenu) { + + if(isLegendMenu) { + for (String id : legendActionIdentifiers) { + mm.remove(id); + } + legendActionIdentifiers.clear(); + } else { + for (String id : chartActionIdentifiers) { + mm.remove(id); + } + chartActionIdentifiers.clear(); } - actionIdentifiers.clear(); if (mm.indexOf(EDIT_LANES) == -1) { - IAction action = ActionToolkit.action(() -> this.openEditLanesDialog(mm), + IAction action = ActionToolkit.action(() -> this.openEditLanesDialog(mm, isLegendMenu), Messages.JavaApplicationPage_EDIT_THREAD_LANES_ACTION, FlightRecorderUI.getDefault().getMCImageDescriptor(ImageConstants.ICON_LANES_EDIT)); action.setId(EDIT_LANES); @@ -245,7 +255,11 @@ }; String identifier = ld.getName() + checkAction.hashCode(); checkAction.setId(identifier); - actionIdentifiers.add(identifier); + if (isLegendMenu) { + legendActionIdentifiers.add(identifier); + } else { + chartActionIdentifiers.add(identifier); + } checkAction.setChecked(ld.isEnabled()); // FIXME: Add a tooltip here mm.add(checkAction); diff -r 4629e44fd8ea application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/GarbageCollectionsPage.java --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/GarbageCollectionsPage.java Thu Nov 08 12:45:05 2018 +0100 +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/GarbageCollectionsPage.java Tue Dec 04 15:08:07 2018 -0500 @@ -54,6 +54,7 @@ import org.eclipse.jface.action.IAction; import org.eclipse.jface.resource.ImageDescriptor; import org.eclipse.jface.viewers.ArrayContentProvider; +import org.eclipse.jface.viewers.CheckboxTableViewer; import org.eclipse.jface.viewers.ColumnViewerToolTipSupport; import org.eclipse.jface.viewers.IStructuredSelection; import org.eclipse.jface.viewers.TableViewer; @@ -335,8 +336,10 @@ gcInfoFolder = new CTabFolder(tableSash, SWT.NONE); phasesList = PHASES.buildWithoutBorder(gcInfoFolder, TableSettings.forState(state.getChild(PHASE_LIST))); - phasesList.getManager().getViewer().addSelectionChangedListener( - e -> pageContainer.showSelection(ItemCollectionToolkit.build(phasesList.getSelection().get()))); + phasesList.getManager().getViewer().addSelectionChangedListener(e -> { + buildChart(); + pageContainer.showSelection(ItemCollectionToolkit.build(phasesList.getSelection().get())); + }); phasesFilter = FilterComponent.createFilterComponent(phasesList, phasesFilterState, getDataSource().getItems().apply(JdkFilters.GC_PAUSE_PHASE), pageContainer.getSelectionStore()::getSelections, this::onPhasesFilterChange); @@ -372,14 +375,14 @@ chartCanvas = new ChartCanvas(chartContainer); chartCanvas.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true)); ActionToolkit.loadCheckState(state.getChild(CHART), allChartSeriesActions.stream()); - Control chartLegend = ActionUiToolkit.buildCheckboxControl(chartContainer, - allChartSeriesActions.stream().filter(a -> includeAttribute(a.getId())), true); + CheckboxTableViewer chartLegend = ActionUiToolkit.buildCheckboxViewer(chartContainer, + allChartSeriesActions.stream().filter(a -> includeAttribute(a.getId()))); GridData gd = new GridData(SWT.FILL, SWT.FILL, false, true); gd.widthHint = 180; - chartLegend.setLayoutData(gd); + chartLegend.getControl().setLayoutData(gd); lanes = new ThreadGraphLanes(() -> getDataSource(), () -> buildChart()); lanes.initializeChartConfiguration(Stream.of(state.getChildren(THREAD_LANES))); - IAction editLanesAction = ActionToolkit.action(() -> lanes.openEditLanesDialog(mm), + IAction editLanesAction = ActionToolkit.action(() -> lanes.openEditLanesDialog(mm, false), Messages.ThreadsPage_EDIT_LANES, FlightRecorderUI.getDefault().getMCImageDescriptor(ImageConstants.ICON_LANES_EDIT)); form.getToolBarManager().add(editLanesAction); @@ -404,7 +407,8 @@ phasesList.getManager().setSelectionState(phasesSelection); metaspaceList.getManager().setSelectionState(metaspaceSelection); mm = (MCContextMenuManager) chartCanvas.getContextMenu(); - lanes.updateContextMenu(mm); + lanes.updateContextMenu(mm, false); + lanes.updateContextMenu(MCContextMenuManager.create(chartLegend.getControl()), true); // Older recordings may not have thread information in pause events. // In those cases there is no need for the thread activity actions. diff -r 4629e44fd8ea application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/JavaApplicationPage.java --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/JavaApplicationPage.java Thu Nov 08 12:45:05 2018 +0100 +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/JavaApplicationPage.java Tue Dec 04 15:08:07 2018 -0500 @@ -224,14 +224,14 @@ mm = (MCContextMenuManager) chartCanvas.getContextMenu(); // FIXME: The lanes field is initialized by initializeChartConfiguration which is called by the super constructor. This is too indirect for SpotBugs to resolve and should be simplified. - lanes.updateContextMenu(mm); - lanes.updateContextMenu(MCContextMenuManager.create(chartLegend.getControl())); + lanes.updateContextMenu(mm, false); + lanes.updateContextMenu(MCContextMenuManager.create(chartLegend.getControl()), true); buildChart(); addResultActions(form); tableFilterComponent.loadState(state.getChild(METHOD_PROFILING_TABLE_FILTER)); form.getToolBarManager() - .add(ActionToolkit.action(() -> lanes.openEditLanesDialog(mm), Messages.ThreadsPage_EDIT_LANES, + .add(ActionToolkit.action(() -> lanes.openEditLanesDialog(mm, false), Messages.ThreadsPage_EDIT_LANES, FlightRecorderUI.getDefault().getMCImageDescriptor(ImageConstants.ICON_LANES_EDIT))); form.getToolBarManager().add(new Separator()); OrientationAction.installActions(form, sash); diff -r 4629e44fd8ea application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java Thu Nov 08 12:45:05 2018 +0100 +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java Tue Dec 04 15:08:07 2018 -0500 @@ -162,10 +162,10 @@ sash.setOrientation(SWT.HORIZONTAL); mm.add(new Separator()); // FIXME: The lanes field is initialized by initializeChartConfiguration which is called by the super constructor. This is too indirect for SpotBugs to resolve and should be simplified. - lanes.updateContextMenu(mm); + lanes.updateContextMenu(mm, false); form.getToolBarManager() - .add(ActionToolkit.action(() -> lanes.openEditLanesDialog(mm), Messages.ThreadsPage_EDIT_LANES, + .add(ActionToolkit.action(() -> lanes.openEditLanesDialog(mm, false), Messages.ThreadsPage_EDIT_LANES, FlightRecorderUI.getDefault().getMCImageDescriptor(ImageConstants.ICON_LANES_EDIT))); form.getToolBarManager().update(true); chartLegend.getControl().dispose(); From jmatsuok at redhat.com Tue Dec 4 21:43:57 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Tue, 4 Dec 2018 16:43:57 -0500 Subject: JMC-6222 Allow filtering by package for the Method Profiling Rule In-Reply-To: <37a601d48b37$06f0bf10$14d23d30$@hirt.se> References: <9F04118A-ABD3-4A53-8F7B-16060B5EAC9C@redhat.com> <18465BD2-DBCB-4949-BBF4-92B2A50D8E60@oracle.com> <37a601d48b37$06f0bf10$14d23d30$@hirt.se> Message-ID: Hi Marcus, Here's an updated patch. http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.02/ Cheers, - Josh On Mon, Dec 3, 2018 at 1:36 PM Marcus Hirt wrote: > Hi Josh, > > Probably just want to look at the package: > > MethodProfilingRule at 454: > Matcher m = > excludes.matcher(frame.getMethod().getType().getPackage().getName()); > > I think it would be nice to add the following as default: > public static final TypedPreference > EXCLUDED_PACKAGE_REGEXP = new TypedPreference<>( > "method.profiling.evaluation.excluded.package", > //$NON-NLS-1$ > > Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES), > > Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES_DESC), > UnitLookup.PLAIN_TEXT.getPersister(), > "java\\.(lang|util)"); > > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Joshua Matsuoka > Skickat: den 3 december 2018 17:53 > Till: Marcus Hirt > Kopia: jmc-dev at openjdk.java.net > ?mne: Re: JMC-6222 Allow filtering by package for the Method Profiling Rule > > Hi Marcus, > > Here's an updated webrev: > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.01/ > > Cheers, > > - Josh > > On Fri, Nov 30, 2018 at 5:23 PM Marcus Hirt > wrote: > > > Hi Josh! > > > > Quickly tried your patch, but get this: > > java.util.concurrent.ExecutionException: > > java.lang.UnsupportedOperationException > > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > > at > > org.openjdk.jmc.flightrecorder.ui.RuleManager$EvaluateJob.run(RuleMana > > ger.java:117) at > > org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) > > Caused by: java.lang.UnsupportedOperationException > > at java.util.AbstractList.remove(AbstractList.java:161) > > at java.util.AbstractList$Itr.remove(AbstractList.java:374) > > at java.util.AbstractCollection.removeAll(AbstractCollection.java:376) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > $1.processPath(MethodProfilingRule.java:462) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > $1.getValue(MethodProfilingRule.java:421) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > $1.getValue(MethodProfilingRule.java:405) > > at > > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > > getValue(GroupingAggregator.java:164) > > at > > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > > getValue(GroupingAggregator.java:134) > > at > > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > > regators.java:97) > > at > > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > > regators.java:81) > > at > > org.openjdk.jmc.flightrecorder.ui.ItemIterableToolkit.aggregate(ItemIt > > erableToolkit.java:128) > > at > > org.openjdk.jmc.flightrecorder.ui.ItemCollectionToolkit$StreamBackedIt > > emCollection.getAggregate(ItemCollectionToolkit.java:91) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > .performCalculation(MethodProfilingRule.java:467) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > .visitWindow(MethodProfilingRule.java:344) > > at > > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > > WindowUnordered(SlidingWindowToolkit.java:200) > > at > > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > > WindowUnordered(SlidingWindowToolkit.java:158) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.g > > etResult(MethodProfilingRule.java:239) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.a > > ccess$000(MethodProfilingRule.java:97) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > > ethodProfilingCallable.call(MethodProfilingRule.java:196) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > > ethodProfilingCallable.call(MethodProfilingRule.java:184) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at java.lang.Thread.run(Thread.java:748) > > > > The regexp used: > > java\.util\..* > > And input file: > > The "before" file from here: > > > > https://github.com/thegreystone/jmc-tutorial/tree/master/projects/02_J > > FR_HotMethods > > > > Kind regards, > > Marcus > > > > ?On 2018-11-30, 17:25, "jmc-dev on behalf of Joshua Matsuoka" < > > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> > wrote: > > > > Hi, > > > > The following patch adds support for filtering the method > > profiling rule by > > package name. When a regex is supplied via TypedPreferences, it > > will drop > > any frames matching the regex until reaching the first one that > doesnt > > match, treating that one as the hot frame. > > > > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.00/jmc.patch > > > > Thoughts? > > > > Bug ID: > > > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6222?filter=allo > > penissues > > > > Cheers, > > > > - Josh > > > > > > > > > > > > From marcus.hirt at oracle.com Wed Dec 5 09:07:10 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 05 Dec 2018 10:07:10 +0100 Subject: JMC-6222 Allow filtering by package for the Method Profiling Rule In-Reply-To: <0F9CE34B-4B05-4ABC-BB2F-E9895EE7D289@redhat.com> References: <9F04118A-ABD3-4A53-8F7B-16060B5EAC9C@redhat.com> <18465BD2-DBCB-4949-BBF4-92B2A50D8E60@oracle.com> <37a601d48b37$06f0bf10$14d23d30$@hirt.se> <0F9CE34B-4B05-4ABC-BB2F-E9895EE7D289@redhat.com> Message-ID: <11DC989F-CDF5-4F69-9328-2279192374D5@oracle.com> Looks good Josh! /M From: Joshua Matsuoka Date: Tuesday, 4 December 2018 at 22:44 To: Cc: Marcus Hirt , Subject: Re: JMC-6222 Allow filtering by package for the Method Profiling Rule Hi Marcus, Here's an updated patch. http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.02/ Cheers, - Josh On Mon, Dec 3, 2018 at 1:36 PM Marcus Hirt wrote: Hi Josh, Probably just want to look at the package: MethodProfilingRule at 454: Matcher m = excludes.matcher(frame.getMethod().getType().getPackage().getName()); I think it would be nice to add the following as default: public static final TypedPreference EXCLUDED_PACKAGE_REGEXP = new TypedPreference<>( "method.profiling.evaluation.excluded.package", //$NON-NLS-1$ Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES), Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES_DESC), UnitLookup.PLAIN_TEXT.getPersister(), "java\\.(lang|util)"); Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Joshua Matsuoka Skickat: den 3 december 2018 17:53 Till: Marcus Hirt Kopia: jmc-dev at openjdk.java.net ?mne: Re: JMC-6222 Allow filtering by package for the Method Profiling Rule Hi Marcus, Here's an updated webrev: http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.01/ Cheers, - Josh On Fri, Nov 30, 2018 at 5:23 PM Marcus Hirt wrote: > Hi Josh! > > Quickly tried your patch, but get this: > java.util.concurrent.ExecutionException: > java.lang.UnsupportedOperationException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.openjdk.jmc.flightrecorder.ui.RuleManager$EvaluateJob.run(RuleMana > ger.java:117) at > org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) > Caused by: java.lang.UnsupportedOperationException > at java.util.AbstractList.remove(AbstractList.java:161) > at java.util.AbstractList$Itr.remove(AbstractList.java:374) > at java.util.AbstractCollection.removeAll(AbstractCollection.java:376) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > $1.processPath(MethodProfilingRule.java:462) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > $1.getValue(MethodProfilingRule.java:421) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > $1.getValue(MethodProfilingRule.java:405) > at > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > getValue(GroupingAggregator.java:164) > at > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > getValue(GroupingAggregator.java:134) > at > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > regators.java:97) > at > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > regators.java:81) > at > org.openjdk.jmc.flightrecorder.ui.ItemIterableToolkit.aggregate(ItemIt > erableToolkit.java:128) > at > org.openjdk.jmc.flightrecorder.ui.ItemCollectionToolkit$StreamBackedIt > emCollection.getAggregate(ItemCollectionToolkit.java:91) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > .performCalculation(MethodProfilingRule.java:467) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > .visitWindow(MethodProfilingRule.java:344) > at > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > WindowUnordered(SlidingWindowToolkit.java:200) > at > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > WindowUnordered(SlidingWindowToolkit.java:158) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.g > etResult(MethodProfilingRule.java:239) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.a > ccess$000(MethodProfilingRule.java:97) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > ethodProfilingCallable.call(MethodProfilingRule.java:196) > at > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > ethodProfilingCallable.call(MethodProfilingRule.java:184) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.lang.Thread.run(Thread.java:748) > > The regexp used: > java\.util\..* > And input file: > The "before" file from here: > > https://github.com/thegreystone/jmc-tutorial/tree/master/projects/02_J > FR_HotMethods > > Kind regards, > Marcus > > ?On 2018-11-30, 17:25, "jmc-dev on behalf of Joshua Matsuoka" < > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> wrote: > > Hi, > > The following patch adds support for filtering the method > profiling rule by > package name. When a regex is supplied via TypedPreferences, it > will drop > any frames matching the regex until reaching the first one that doesnt > match, treating that one as the hot frame. > > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.00/jmc.patch > > Thoughts? > > Bug ID: > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6222?filter=allo > penissues > > Cheers, > > - Josh > > > > > From marcus.hirt at oracle.com Wed Dec 5 11:19:16 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 05 Dec 2018 12:19:16 +0100 Subject: Stabilization and branching of JMC 7.0.0 Message-ID: Hi all, The time has come to focus on stabilizing and branching off JMC 7. The iteration starting later today (JMC 7 Sprint 19 Stabilization) will focus stabilization, and we will branch off jmc 7 at the end of that iteration (the 17th of December). I will also start moving enhancements and low priority bugs. Please let me know if there is any bug-fix that you have in-progress or that you think must be fixed in 7.0.0. Kind regards, Marcus From guru.hb at oracle.com Wed Dec 5 14:40:10 2018 From: guru.hb at oracle.com (Guru) Date: Wed, 5 Dec 2018 20:10:10 +0530 Subject: RFR: JMC-6206: Making the agent prototype work on OpenJDK 11 In-Reply-To: <4bd101d48c10$9231f560$b695e020$@hirt.se> References: <4bd101d48c10$9231f560$b695e020$@hirt.se> Message-ID: <0D943A68-3B71-4DF0-B9EB-76FA9437BC04@oracle.com> +1, Looks good to me. > On 05-Dec-2018, at 2:03 AM, Marcus Hirt wrote: > > Hi all, > > Please review this fix to get the early agent prototype to work on OpenJDK > 11. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6206 > Patch: http://cr.openjdk.java.net/~hirt/JMC-6206/webrev.01/ > > Kind regards, > Marcus > From guru.hb at oracle.com Wed Dec 5 14:44:49 2018 From: guru.hb at oracle.com (guru.hb at oracle.com) Date: Wed, 05 Dec 2018 14:44:49 +0000 Subject: hg: jmc/jmc: JMC-6127: Live Objects Page do not forward selections correctly Message-ID: <201812051444.wB5EinrW028017@aojmv0008.oracle.com> Changeset: c3fef197760c Author: ghb Date: 2018-12-05 20:14 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/c3fef197760c JMC-6127: Live Objects Page do not forward selections correctly Reviewed-by: hirt ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/MemoryLeakPage.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/memleak/ReferenceTreeModel.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/memleak/ReferenceTreeObject.java From marcus.hirt at oracle.com Wed Dec 5 15:02:08 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Wed, 05 Dec 2018 15:02:08 +0000 Subject: hg: jmc/jmc: JMC-6206: Making the agent prototype work on OpenJDK 11 Message-ID: <201812051502.wB5F29ld005545@aojmv0008.oracle.com> Changeset: 72f62e3d9eec Author: hirt Date: 2018-12-05 16:00 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/72f62e3d9eec JMC-6206: Making the agent prototype work on OpenJDK 11 Reviewed-by: ghb ! core/org.openjdk.jmc.agent/README.md ! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Agent.java - core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/TransformType.java ! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFRClassVisitor.java ! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFRUtils.java ! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfrnext/impl/JFRNextClassVisitor.java ! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/TypeUtils.java From jmatsuok at redhat.com Wed Dec 5 15:37:34 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Wed, 5 Dec 2018 10:37:34 -0500 Subject: JMC-6222 Allow filtering by package for the Method Profiling Rule In-Reply-To: <11DC989F-CDF5-4F69-9328-2279192374D5@oracle.com> References: <9F04118A-ABD3-4A53-8F7B-16060B5EAC9C@redhat.com> <18465BD2-DBCB-4949-BBF4-92B2A50D8E60@oracle.com> <37a601d48b37$06f0bf10$14d23d30$@hirt.se> <0F9CE34B-4B05-4ABC-BB2F-E9895EE7D289@redhat.com> <11DC989F-CDF5-4F69-9328-2279192374D5@oracle.com> Message-ID: Hi Marcus, Thanks for the review! Here's an exported patch, Mario could you sponsor it? Cheers, - Josh On Wed, Dec 5, 2018 at 4:09 AM Marcus Hirt wrote: > Looks good Josh! > > > > /M > > > > *From: *Joshua Matsuoka > *Date: *Tuesday, 4 December 2018 at 22:44 > *To: * > *Cc: *Marcus Hirt , > *Subject: *Re: JMC-6222 Allow filtering by package for the Method > Profiling Rule > > > > Hi Marcus, > > > > Here's an updated patch. > > > > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.02/ > > > > Cheers, > > > > - Josh > > > > On Mon, Dec 3, 2018 at 1:36 PM Marcus Hirt wrote: > > Hi Josh, > > Probably just want to look at the package: > > MethodProfilingRule at 454: > Matcher m = > excludes.matcher(frame.getMethod().getType().getPackage().getName()); > > I think it would be nice to add the following as default: > public static final TypedPreference > EXCLUDED_PACKAGE_REGEXP = new TypedPreference<>( > "method.profiling.evaluation.excluded.package", > //$NON-NLS-1$ > > Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES), > > Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES_DESC), > UnitLookup.PLAIN_TEXT.getPersister(), > "java\\.(lang|util)"); > > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Joshua Matsuoka > Skickat: den 3 december 2018 17:53 > Till: Marcus Hirt > Kopia: jmc-dev at openjdk.java.net > ?mne: Re: JMC-6222 Allow filtering by package for the Method Profiling Rule > > Hi Marcus, > > Here's an updated webrev: > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.01/ > > Cheers, > > - Josh > > On Fri, Nov 30, 2018 at 5:23 PM Marcus Hirt > wrote: > > > Hi Josh! > > > > Quickly tried your patch, but get this: > > java.util.concurrent.ExecutionException: > > java.lang.UnsupportedOperationException > > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > > at > > org.openjdk.jmc.flightrecorder.ui.RuleManager$EvaluateJob.run(RuleMana > > ger.java:117) at > > org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) > > Caused by: java.lang.UnsupportedOperationException > > at java.util.AbstractList.remove(AbstractList.java:161) > > at java.util.AbstractList$Itr.remove(AbstractList.java:374) > > at java.util.AbstractCollection.removeAll(AbstractCollection.java:376) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > $1.processPath(MethodProfilingRule.java:462) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > $1.getValue(MethodProfilingRule.java:421) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > $1.getValue(MethodProfilingRule.java:405) > > at > > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > > getValue(GroupingAggregator.java:164) > > at > > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. > > getValue(GroupingAggregator.java:134) > > at > > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > > regators.java:97) > > at > > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg > > regators.java:81) > > at > > org.openjdk.jmc.flightrecorder.ui.ItemIterableToolkit.aggregate(ItemIt > > erableToolkit.java:128) > > at > > org.openjdk.jmc.flightrecorder.ui.ItemCollectionToolkit$StreamBackedIt > > emCollection.getAggregate(ItemCollectionToolkit.java:91) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > .performCalculation(MethodProfilingRule.java:467) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 > > .visitWindow(MethodProfilingRule.java:344) > > at > > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > > WindowUnordered(SlidingWindowToolkit.java:200) > > at > > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding > > WindowUnordered(SlidingWindowToolkit.java:158) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.g > > etResult(MethodProfilingRule.java:239) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.a > > ccess$000(MethodProfilingRule.java:97) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > > ethodProfilingCallable.call(MethodProfilingRule.java:196) > > at > > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M > > ethodProfilingCallable.call(MethodProfilingRule.java:184) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at java.lang.Thread.run(Thread.java:748) > > > > The regexp used: > > java\.util\..* > > And input file: > > The "before" file from here: > > > > https://github.com/thegreystone/jmc-tutorial/tree/master/projects/02_J > > FR_HotMethods > > > > Kind regards, > > Marcus > > > > ?On 2018-11-30, 17:25, "jmc-dev on behalf of Joshua Matsuoka" < > > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> > wrote: > > > > Hi, > > > > The following patch adds support for filtering the method > > profiling rule by > > package name. When a regex is supplied via TypedPreferences, it > > will drop > > any frames matching the regex until reaching the first one that > doesnt > > match, treating that one as the hot frame. > > > > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.00/jmc.patch > > > > Thoughts? > > > > Bug ID: > > > > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6222?filter=allo > > penissues > > > > Cheers, > > > > - Josh > > > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: JMC-6222.patch Type: text/x-patch Size: 11334 bytes Desc: not available URL: From neugens.limasoftware at gmail.com Wed Dec 5 15:52:45 2018 From: neugens.limasoftware at gmail.com (neugens.limasoftware at gmail.com) Date: Wed, 05 Dec 2018 15:52:45 +0000 Subject: hg: jmc/jmc: JMC-6222: Allow filtering by package for the Method Profiling Rule Message-ID: <201812051552.wB5FqjfP029355@aojmv0008.oracle.com> Changeset: e24e4b6bb431 Author: jmatsuoka Date: 2018-12-05 10:26 -0500 URL: http://hg.openjdk.java.net/jmc/jmc/rev/e24e4b6bb431 JMC-6222: Allow filtering by package for the Method Profiling Rule Summary: Add functionality to allow for filtering of certain packages in the stack trace used by the method profiling rule. Reviewed-by: hirt ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/MethodProfilingRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml From neugens at redhat.com Wed Dec 5 15:52:47 2018 From: neugens at redhat.com (Mario Torre) Date: Wed, 5 Dec 2018 16:52:47 +0100 Subject: JMC-6222 Allow filtering by package for the Method Profiling Rule In-Reply-To: References: <9F04118A-ABD3-4A53-8F7B-16060B5EAC9C@redhat.com> <18465BD2-DBCB-4949-BBF4-92B2A50D8E60@oracle.com> <37a601d48b37$06f0bf10$14d23d30$@hirt.se> <0F9CE34B-4B05-4ABC-BB2F-E9895EE7D289@redhat.com> <11DC989F-CDF5-4F69-9328-2279192374D5@oracle.com> Message-ID: Done :) Cheers, Mario On Wed, Dec 5, 2018 at 4:37 PM Joshua Matsuoka wrote: > > Hi Marcus, > > Thanks for the review! Here's an exported patch, Mario could you sponsor it? > > Cheers, > > - Josh > > On Wed, Dec 5, 2018 at 4:09 AM Marcus Hirt wrote: >> >> Looks good Josh! >> >> >> >> /M >> >> >> >> From: Joshua Matsuoka >> Date: Tuesday, 4 December 2018 at 22:44 >> To: >> Cc: Marcus Hirt , >> Subject: Re: JMC-6222 Allow filtering by package for the Method Profiling Rule >> >> >> >> Hi Marcus, >> >> >> >> Here's an updated patch. >> >> >> >> http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.02/ >> >> >> >> Cheers, >> >> >> >> - Josh >> >> >> >> On Mon, Dec 3, 2018 at 1:36 PM Marcus Hirt wrote: >> >> Hi Josh, >> >> Probably just want to look at the package: >> >> MethodProfilingRule at 454: >> Matcher m = excludes.matcher(frame.getMethod().getType().getPackage().getName()); >> >> I think it would be nice to add the following as default: >> public static final TypedPreference EXCLUDED_PACKAGE_REGEXP = new TypedPreference<>( >> "method.profiling.evaluation.excluded.package", //$NON-NLS-1$ >> Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES), >> Messages.getString(Messages.MethodProfilingRule_EXCLUDED_PACKAGES_DESC), >> UnitLookup.PLAIN_TEXT.getPersister(), "java\\.(lang|util)"); >> >> >> Kind regards, >> Marcus >> >> -----Ursprungligt meddelande----- >> Fr?n: jmc-dev F?r Joshua Matsuoka >> Skickat: den 3 december 2018 17:53 >> Till: Marcus Hirt >> Kopia: jmc-dev at openjdk.java.net >> ?mne: Re: JMC-6222 Allow filtering by package for the Method Profiling Rule >> >> Hi Marcus, >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.01/ >> >> Cheers, >> >> - Josh >> >> On Fri, Nov 30, 2018 at 5:23 PM Marcus Hirt wrote: >> >> > Hi Josh! >> > >> > Quickly tried your patch, but get this: >> > java.util.concurrent.ExecutionException: >> > java.lang.UnsupportedOperationException >> > at java.util.concurrent.FutureTask.report(FutureTask.java:122) >> > at java.util.concurrent.FutureTask.get(FutureTask.java:192) >> > at >> > org.openjdk.jmc.flightrecorder.ui.RuleManager$EvaluateJob.run(RuleMana >> > ger.java:117) at >> > org.eclipse.core.internal.jobs.Worker.run(Worker.java:60) >> > Caused by: java.lang.UnsupportedOperationException >> > at java.util.AbstractList.remove(AbstractList.java:161) >> > at java.util.AbstractList$Itr.remove(AbstractList.java:374) >> > at java.util.AbstractCollection.removeAll(AbstractCollection.java:376) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 >> > $1.processPath(MethodProfilingRule.java:462) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 >> > $1.getValue(MethodProfilingRule.java:421) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 >> > $1.getValue(MethodProfilingRule.java:405) >> > at >> > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. >> > getValue(GroupingAggregator.java:164) >> > at >> > org.openjdk.jmc.common.item.GroupingAggregator$GroupingAggregatorImpl. >> > getValue(GroupingAggregator.java:134) >> > at >> > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg >> > regators.java:97) >> > at >> > org.openjdk.jmc.common.item.Aggregators$MergingAggregator.getValue(Agg >> > regators.java:81) >> > at >> > org.openjdk.jmc.flightrecorder.ui.ItemIterableToolkit.aggregate(ItemIt >> > erableToolkit.java:128) >> > at >> > org.openjdk.jmc.flightrecorder.ui.ItemCollectionToolkit$StreamBackedIt >> > emCollection.getAggregate(ItemCollectionToolkit.java:91) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 >> > .performCalculation(MethodProfilingRule.java:467) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$1 >> > .visitWindow(MethodProfilingRule.java:344) >> > at >> > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding >> > WindowUnordered(SlidingWindowToolkit.java:200) >> > at >> > org.openjdk.jmc.flightrecorder.rules.util.SlidingWindowToolkit.sliding >> > WindowUnordered(SlidingWindowToolkit.java:158) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.g >> > etResult(MethodProfilingRule.java:239) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule.a >> > ccess$000(MethodProfilingRule.java:97) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M >> > ethodProfilingCallable.call(MethodProfilingRule.java:196) >> > at >> > org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$M >> > ethodProfilingCallable.call(MethodProfilingRule.java:184) >> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> > at java.lang.Thread.run(Thread.java:748) >> > >> > The regexp used: >> > java\.util\..* >> > And input file: >> > The "before" file from here: >> > >> > https://github.com/thegreystone/jmc-tutorial/tree/master/projects/02_J >> > FR_HotMethods >> > >> > Kind regards, >> > Marcus >> > >> > ?On 2018-11-30, 17:25, "jmc-dev on behalf of Joshua Matsuoka" < >> > jmc-dev-bounces at openjdk.java.net on behalf of jmatsuok at redhat.com> wrote: >> > >> > Hi, >> > >> > The following patch adds support for filtering the method >> > profiling rule by >> > package name. When a regex is supplied via TypedPreferences, it >> > will drop >> > any frames matching the regex until reaching the first one that doesnt >> > match, treating that one as the hot frame. >> > >> > http://cr.openjdk.java.net/~jmatsuoka/JMC-6222/webrev.00/jmc.patch >> > >> > Thoughts? >> > >> > Bug ID: >> > >> > https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6222?filter=allo >> > penissues >> > >> > Cheers, >> > >> > - Josh >> > >> > >> > >> > >> > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Wed Dec 5 15:58:04 2018 From: neugens at redhat.com (Mario Torre) Date: Wed, 05 Dec 2018 16:58:04 +0100 Subject: Stabilization and branching of JMC 7.0.0 In-Reply-To: References: Message-ID: On Wed, 2018-12-05 at 12:19 +0100, Marcus Hirt wrote: > Hi all, > > The time has come to focus on stabilizing and branching off JMC 7. > The > iteration starting later today (JMC 7 Sprint 19 Stabilization) will > focus > stabilization, and we will branch off jmc 7 at the end of that > iteration (the > 17th of December). I will also start moving enhancements and low > priority bugs. > Please let me know if there is any bug-fix that you have in-progress > or that > you think must be fixed in 7.0.0. > > Kind regards, > Marcus Can we fork a jmc-7.0 repository and keep the jmc-dev open for development (maybe increasing version numbers)? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus at hirt.se Wed Dec 5 16:04:00 2018 From: marcus at hirt.se (Marcus Hirt) Date: Wed, 5 Dec 2018 17:04:00 +0100 Subject: SV: Stabilization and branching of JMC 7.0.0 In-Reply-To: References: Message-ID: <5da301d48cb4$22d12200$68736600$@hirt.se> Hi Mario, That is the plan, and it is happening the 17th. Would you need it sooner? Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Mario Torre Skickat: den 5 december 2018 16:58 Till: Marcus Hirt ; jmc-dev at openjdk.java.net ?mne: Re: Stabilization and branching of JMC 7.0.0 On Wed, 2018-12-05 at 12:19 +0100, Marcus Hirt wrote: > Hi all, > > The time has come to focus on stabilizing and branching off JMC 7. > The > iteration starting later today (JMC 7 Sprint 19 Stabilization) will > focus stabilization, and we will branch off jmc 7 at the end of that > iteration (the 17th of December). I will also start moving > enhancements and low priority bugs. > Please let me know if there is any bug-fix that you have in-progress > or that you think must be fixed in 7.0.0. > > Kind regards, > Marcus Can we fork a jmc-7.0 repository and keep the jmc-dev open for development (maybe increasing version numbers)? 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 Wed Dec 5 16:08:09 2018 From: neugens at redhat.com (Mario Torre) Date: Wed, 5 Dec 2018 17:08:09 +0100 Subject: Stabilization and branching of JMC 7.0.0 In-Reply-To: <5da301d48cb4$22d12200$68736600$@hirt.se> References: <5da301d48cb4$22d12200$68736600$@hirt.se> Message-ID: On Wed, Dec 5, 2018 at 5:04 PM Marcus Hirt wrote: > > Hi Mario, > > That is the plan, and it is happening the 17th. Would > you need it sooner? No, that's perfectly fine! Cheers, Mario > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Mario Torre > Skickat: den 5 december 2018 16:58 > Till: Marcus Hirt ; jmc-dev at openjdk.java.net > ?mne: Re: Stabilization and branching of JMC 7.0.0 > > On Wed, 2018-12-05 at 12:19 +0100, Marcus Hirt wrote: > > Hi all, > > > > The time has come to focus on stabilizing and branching off JMC 7. > > The > > iteration starting later today (JMC 7 Sprint 19 Stabilization) will > > focus stabilization, and we will branch off jmc 7 at the end of that > > iteration (the 17th of December). I will also start moving > > enhancements and low priority bugs. > > Please let me know if there is any bug-fix that you have in-progress > > or that you think must be fixed in 7.0.0. > > > > Kind regards, > > Marcus > > Can we fork a jmc-7.0 repository and keep the jmc-dev open for development (maybe increasing version numbers)? > > Cheers, > Mario > -- > 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 oracle.com Wed Dec 5 20:23:39 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 05 Dec 2018 21:23:39 +0100 Subject: CFV: New jmc Committer: Joshua Matsuoka Message-ID: <584CA65A-FA24-4F6F-8D84-53371F32B977@oracle.com> I hereby nominate Joshua Matsuoka to jmc Committer. Josh has been a prolific contributor to JDK Mission Control over the past months, with 8 contributions already and 2 in the works. He has been a fast learner, shown great initiative and an ability to work independently with very little supervision. Votes are due by 2018-12-13, 17:00 CET. Only current jmc Committers (and Reviewers, of course) [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, Marcus [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From neugens at redhat.com Wed Dec 5 22:27:20 2018 From: neugens at redhat.com (Mario Torre) Date: Wed, 5 Dec 2018 22:27:20 +0000 Subject: CFV: New jmc Committer: Joshua Matsuoka In-Reply-To: <584CA65A-FA24-4F6F-8D84-53371F32B977@oracle.com> References: <584CA65A-FA24-4F6F-8D84-53371F32B977@oracle.com> Message-ID: Vote: Yes! Cheers, Mario ? Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ________________________________ From: jmc-dev on behalf of Marcus Hirt Sent: Wednesday, December 5, 2018 21:24 To: jmc-dev at openjdk.java.net Subject: CFV: New jmc Committer: Joshua Matsuoka I hereby nominate Joshua Matsuoka to jmc Committer. Josh has been a prolific contributor to JDK Mission Control over the past months, with 8 contributions already and 2 in the works. He has been a fast learner, shown great initiative and an ability to work independently with very little supervision. Votes are due by 2018-12-13, 17:00 CET. Only current jmc Committers (and Reviewers, of course) [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, Marcus [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From jmatsuok at redhat.com Thu Dec 6 16:42:57 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Thu, 6 Dec 2018 11:42:57 -0500 Subject: JMC-6241: Leaking Context Menu items In-Reply-To: References: Message-ID: Hi Ken, I applied the patch and it works well. Looks good. Cheers, - Josh On Tue, Dec 4, 2018 at 3:45 PM Ken Dobson wrote: > Hi all, > > This patch does a couple things. > 1. It fixes the leaking context menu items which resulted in the context > menu having multiple sets of the same thread activity lanes listed. > 2. It adds a context menu to the Garbage Collections Page legend as there > already was one for the Java Application page. > 3. Fixes a small bug that lead to the Thread Activity lane on the GC page > only refreshing if it was turned off and then back on again. > > If someone could give it a review that would be great. > > https://bugs.openjdk.java.net/browse/JMC-6241 > > Thanks, > > Ken Dobson > > From marcus.hirt at oracle.com Thu Dec 6 18:15:14 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Thu, 06 Dec 2018 18:15:14 +0000 Subject: hg: jmc/jmc: JMC-0000: Updating README development setup instructions Message-ID: <201812061815.wB6IFFdU011913@aojmv0008.oracle.com> Changeset: abb4b7f54009 Author: hirt Date: 2018-12-06 19:12 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/abb4b7f54009 JMC-0000: Updating README development setup instructions ! README.md From marcus.hirt at oracle.com Thu Dec 6 18:34:30 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 06 Dec 2018 19:34:30 +0100 Subject: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> Message-ID: <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> Hi Elliott, Just one nit - don't forget to put //$NON-NLS-1$ tags on string constants that should not be localized, e.g.: private static final String FIXED_TEXT_FONT = "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ Looks fine - don't need another review after fixing this. Thank you for your contribution! Kind regards, Marcus ?On 2018-12-04, 01:24, "jmc-dev on behalf of Elliott Baron" wrote: Hi, This patch fixes an issue where font sizes vary between columns of certain trees and tables, when the user changes the editor font size. This happens for columns that use the JFace text font, which is also used for text editors in Eclipse. The text font is used as a visual hint for columns that may contain editable values. Other columns use the JFace default font, which derives from the native system default. This simple fix creates a separate font, derived from the JFace text font, that sets its height to that of the default font. This ensures tree/table columns have consistent font sizes, while also retaining the text font face as an indicator for modifiable fields. The font is added to the shared JFace FontRegistry, and is disposed of along with the Display. I have included a new UI test case to verify that our modified font is used for the LabelProvider that was previously using the JFace text font. While I made progress towards some of the other goals mentioned in the bug, such as allowing all text in JMC to have its size adjusted using keyboard shortcuts, we decided to defer such a far-reaching change to a later date [1]. Perhaps we could create another bug for such a feature. How does the attached patch look? Thanks, Elliott [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2018-November/000456.html From ebaron at redhat.com Thu Dec 6 20:09:47 2018 From: ebaron at redhat.com (Elliott Baron) Date: Thu, 6 Dec 2018 15:09:47 -0500 Subject: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> Message-ID: <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> Hi Marcus, On 2018-12-06 1:34 p.m., Marcus Hirt wrote: > Hi Elliott, > > Just one nit - don't forget to put //$NON-NLS-1$ tags on string constants that > should not be localized, e.g.: > > private static final String FIXED_TEXT_FONT = "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ > > Looks fine - don't need another review after fixing this. > > Thank you for your contribution! > > Kind regards, > Marcus Thanks for the review! I have added the missing NON-NLS tag (and set Eclipse to warn me in the future). Am I correct that these tags are not required for test classes? Thanks, Elliott > > ?On 2018-12-04, 01:24, "jmc-dev on behalf of Elliott Baron" wrote: > > Hi, > > This patch fixes an issue where font sizes vary between columns of > certain trees and tables, when the user changes the editor font size. > This happens for columns that use the JFace text font, which is also > used for text editors in Eclipse. The text font is used as a visual hint > for columns that may contain editable values. Other columns use the > JFace default font, which derives from the native system default. > > This simple fix creates a separate font, derived from the JFace text > font, that sets its height to that of the default font. This ensures > tree/table columns have consistent font sizes, while also retaining the > text font face as an indicator for modifiable fields. The font is added > to the shared JFace FontRegistry, and is disposed of along with the Display. > > I have included a new UI test case to verify that our modified font is > used for the LabelProvider that was previously using the JFace text font. > > While I made progress towards some of the other goals mentioned in the > bug, such as allowing all text in JMC to have its size adjusted using > keyboard shortcuts, we decided to defer such a far-reaching change to a > later date [1]. Perhaps we could create another bug for such a feature. > > How does the attached patch look? > > Thanks, > Elliott > > [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2018-November/000456.html > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6180-v2.patch Type: text/x-patch Size: 10369 bytes Desc: not available URL: From marcus at hirt.se Thu Dec 6 21:54:52 2018 From: marcus at hirt.se (Marcus Hirt) Date: Thu, 6 Dec 2018 22:54:52 +0100 Subject: SV: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> Message-ID: <61e201d48dae$512126a0$f36373e0$@hirt.se> Quite frankly, we shouldn't need to, but I think we currently do this across all code. Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Elliott Baron Skickat: den 6 december 2018 21:10 Till: Marcus Hirt ; jmc-dev at openjdk.java.net ?mne: Re: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables Hi Marcus, On 2018-12-06 1:34 p.m., Marcus Hirt wrote: > Hi Elliott, > > Just one nit - don't forget to put //$NON-NLS-1$ tags on string > constants that should not be localized, e.g.: > > private static final String FIXED_TEXT_FONT = > "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ > > Looks fine - don't need another review after fixing this. > > Thank you for your contribution! > > Kind regards, > Marcus Thanks for the review! I have added the missing NON-NLS tag (and set Eclipse to warn me in the future). Am I correct that these tags are not required for test classes? Thanks, Elliott > > ?On 2018-12-04, 01:24, "jmc-dev on behalf of Elliott Baron" wrote: > > Hi, > > This patch fixes an issue where font sizes vary between columns of > certain trees and tables, when the user changes the editor font size. > This happens for columns that use the JFace text font, which is also > used for text editors in Eclipse. The text font is used as a visual hint > for columns that may contain editable values. Other columns use the > JFace default font, which derives from the native system default. > > This simple fix creates a separate font, derived from the JFace text > font, that sets its height to that of the default font. This ensures > tree/table columns have consistent font sizes, while also retaining the > text font face as an indicator for modifiable fields. The font is added > to the shared JFace FontRegistry, and is disposed of along with the Display. > > I have included a new UI test case to verify that our modified font is > used for the LabelProvider that was previously using the JFace text font. > > While I made progress towards some of the other goals mentioned in the > bug, such as allowing all text in JMC to have its size adjusted using > keyboard shortcuts, we decided to defer such a far-reaching change to a > later date [1]. Perhaps we could create another bug for such a feature. > > How does the attached patch look? > > Thanks, > Elliott > > [1] > http://mail.openjdk.java.net/pipermail/jmc-dev/2018-November/000456.ht > ml > > > > From aazores at redhat.com Mon Dec 10 21:36:19 2018 From: aazores at redhat.com (Andrew Azores) Date: Mon, 10 Dec 2018 16:36:19 -0500 Subject: RFR: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS Message-ID: Hi, Here is a patch addressing JMC-5596 [0]. A new JFR rule is added which detects Full GC occurrences when either the G1 or CMS collectors are in use. The implementation for detecting these events is based on my own reading through and testing of JDK (11) sources, as well as discussions on the hotspot-jfr-dev list [1]. For G1 the collections are detected by filtering for jdk.GarbageCollection events where the gcName field is set to "G1Full", since the G1 sources do in fact have separate tracers to identify New, Old, and Full collections by G1. Furthermore, manual testing shows perfect agreement between the G1Full event count and the "Pause Full" log message (-XX:+PrintGCDetails) count. For CMS the picture is a little more hazy, but the jdk.OldGarbageCollection event is used, since this appears to be emitted in the expected situations and was mentioned in the hotspot-jfr-dev discussion. Unfortunately, CMS does not have separate tracers like G1, so the jdk.GarbageCollection events seemingly cannot be filtered by the type of collection that they represent. In my testing there are sometimes discrepancies between the number of OldGarbageCollection events emitted and the number of "Pause Full" messages, but I have never seen a situation where there was 0 of one and >0 of the other (ie. a false positive or false negative result). I suspect there is a pathway that leads to >1 OldGarbageCollection event being emitted for only one log message. Additionally, I have refactored the CollectorType enum, which is used by this new FullGcRule as well as the existing GcStallRule. I've updated the enum members so that it is inline with the GcName enum within the JDK itself, and cleaned up the implemenation of getOldCollectorType slightly. [0] https://bugs.openjdk.java.net/browse/JMC-5596 [1] http://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2018-December/000271.html Thanks, -- Andrew Azores Software Engineer, OpenJDK Team Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: fullgcrule-01.patch Type: text/x-patch Size: 16331 bytes Desc: not available URL: From marcus.hirt at oracle.com Tue Dec 11 11:09:37 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 11 Dec 2018 12:09:37 +0100 Subject: Release date update? Message-ID: Hi all, In a release team meeting today it was asked if we could consider releasing JMC 7 around the JDK 12 release instead (and support both JDK 11 and 12). The motivation is that the releases would be shortly after one another, and that the act of releasing takes an effort. I don't see a big problem with this - we get some additional time to get 12 support right (one release less to worry about), we get a little bit more time to fix bugs, and we may even have time to bring some safe and low hanging fruit back from 7.1.0. I would suggest sticking with JDK 11 (LTS) as the JDK to embed. We may want to consider taking a look at Eclipse 2018-12, since we know it contains fixes we want. Please let me know what do you think. Kind regards, Marcus From marcus at hirt.se Tue Dec 11 12:36:09 2018 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 11 Dec 2018 13:36:09 +0100 Subject: SV: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: References: Message-ID: <012b01d4914e$17c39fc0$474adf40$@hirt.se> Hi Andrew, Looks good, but please fix the associated tests first, then I'll take a closer look. <--8<--> [ERROR] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 9.674 s <<< FAILURE! - in org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr [ERROR] verifyOneResult(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr) Time elapsed: 2.398 s <<< FAILURE! java.lang.AssertionError: Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report. at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159) at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyOneResult(TestRulesWithJfr.java:126) [ERROR] verifyAllResults(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr) Time elapsed: 7.234 s <<< FAILURE! java.lang.AssertionError: Report for file "wls-medrec-jdk9.jfr", rule result for "FullGc" could not be found in the other report. Report for file "wldf.jfr", rule result for "FullGc" could not be found in the other report. Report for file "stringdedup_enabled_jdk9.jfr", rule result for "FullGc" could not be found in the other report. Report for file "parallel-on-singlecpu.jfr", rule result for "FullGc" could not be found in the other report. Report for file "parallel-gc_cpu.jfr", rule result for "FullGc" could not be found in the other report. Report for file "flight_recording_hidden.jfr", rule result for "FullGc" could not be found in the other report. Report for file "crash_jdk9.jfr", rule result for "FullGc" could not be found in the other report. Report for file "allocation_10s_fixed.jfr", rule result for "FullGc" could not be found in the other report. Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report. at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159) at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyAllResults(TestRulesWithJfr.java:132) <--8<--> Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Andrew Azores Skickat: den 10 december 2018 22:36 Till: jmc-dev at openjdk.java.net ?mne: RFR: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS Hi, Here is a patch addressing JMC-5596 [0]. A new JFR rule is added which detects Full GC occurrences when either the G1 or CMS collectors are in use. The implementation for detecting these events is based on my own reading through and testing of JDK (11) sources, as well as discussions on the hotspot-jfr-dev list [1]. For G1 the collections are detected by filtering for jdk.GarbageCollection events where the gcName field is set to "G1Full", since the G1 sources do in fact have separate tracers to identify New, Old, and Full collections by G1. Furthermore, manual testing shows perfect agreement between the G1Full event count and the "Pause Full" log message (-XX:+PrintGCDetails) count. For CMS the picture is a little more hazy, but the jdk.OldGarbageCollection event is used, since this appears to be emitted in the expected situations and was mentioned in the hotspot-jfr-dev discussion. Unfortunately, CMS does not have separate tracers like G1, so the jdk.GarbageCollection events seemingly cannot be filtered by the type of collection that they represent. In my testing there are sometimes discrepancies between the number of OldGarbageCollection events emitted and the number of "Pause Full" messages, but I have never seen a situation where there was 0 of one and >0 of the other (ie. a false positive or false negative result). I suspect there is a pathway that leads to >1 OldGarbageCollection event being emitted for only one log message. Additionally, I have refactored the CollectorType enum, which is used by this new FullGcRule as well as the existing GcStallRule. I've updated the enum members so that it is inline with the GcName enum within the JDK itself, and cleaned up the implemenation of getOldCollectorType slightly. [0] https://bugs.openjdk.java.net/browse/JMC-5596 [1] http://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2018-December/000271.html Thanks, -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From marcus at hirt.se Tue Dec 11 12:52:04 2018 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 11 Dec 2018 13:52:04 +0100 Subject: RFR: JMC-6266: JDK 8 specific code in core (String.join) Message-ID: <015201d49150$516e2090$f44a61b0$@hirt.se> Hi all, Please review this fix for getting rid of some JDK 8-specific code that has snuck into core. Jira: https://bugs.openjdk.java.net/browse/JMC-6266 Patch: <---8<---> diff -r abb4b7f54009 core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/ flightrecorder/rules/jdk/general/DuplicateFlagsRule.java --- a/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Thu Dec 06 19:12:44 2018 +0100 +++ b/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Tue Dec 11 13:47:26 2018 +0100 @@ -44,6 +44,7 @@ import org.openjdk.jmc.common.item.Aggregators; import org.openjdk.jmc.common.item.IItemCollection; import org.openjdk.jmc.common.util.IPreferenceValueProvider; +import org.openjdk.jmc.common.util.StringToolkit; import org.openjdk.jmc.common.util.TypedPreference; import org.openjdk.jmc.flightrecorder.jdk.JdkAttributes; import org.openjdk.jmc.flightrecorder.jdk.JdkFilters; @@ -81,7 +82,7 @@ StringBuilder sb = new StringBuilder(); sb.append("
    "); //$NON-NLS-1$ for (ArrayList dupe : dupes) { - sb.append("
  • " + Encode.forHtml(String.join(", ", dupe)) + "
  • "); //$NON-NLS-1$ //$NON-NLS-2$ + sb.append("
  • " + Encode.forHtml(StringToolkit.join(dupe, ", ")) + "
  • "); //$NON-NLS-1$ //$NON-NLS-2$ } sb.append("
"); //$NON-NLS-1$ String shortDescription = dupes.size() > 1 <---8<---> Kind regards, Marcus From neugens at redhat.com Tue Dec 11 12:55:04 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 11 Dec 2018 13:55:04 +0100 Subject: Release date update? In-Reply-To: References: Message-ID: <0aee361530babb524d0e43a82e027a1493a8d66a.camel@redhat.com> On Tue, 2018-12-11 at 12:09 +0100, Marcus Hirt wrote: > Hi all, > > In a release team meeting today it was asked if we could consider > releasing > JMC 7 around the JDK 12 release instead (and support both JDK 11 and > 12). The > motivation is that the releases would be shortly after one another, > and that > the act of releasing takes an effort. I don't see a big problem with > this - we > get some additional time to get 12 support right (one release less to > worry > about), we get a little bit more time to fix bugs, and we may even > have time > to bring some safe and low hanging fruit back from 7.1.0. > > I would suggest sticking with JDK 11 (LTS) as the JDK to embed. We > may want to > consider taking a look at Eclipse 2018-12, since we know it contains > fixes we > want. > > Please let me know what do you think. > > Kind regards, > Marcus It sounds like a good idea. We could even skip 7.0 and release 7.1 directly to keep synch with the original plan of having 7.0 -> 11, 7.1 -> 12 etc.. It doesn't really matter that much however, so if you already have most of the targets in JIRA divided for 7.0 and 7.1 etc... makes sense to keep things as they are and just move the release a bit forward. Cheers, Mario -- 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 Dec 11 15:20:06 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Tue, 11 Dec 2018 10:20:06 -0500 Subject: RFR: JMC-6266: JDK 8 specific code in core (String.join) In-Reply-To: <015201d49150$516e2090$f44a61b0$@hirt.se> References: <015201d49150$516e2090$f44a61b0$@hirt.se> Message-ID: Hi Marcus, Looks good. Cheers, - Josh On Tue, Dec 11, 2018 at 7:52 AM Marcus Hirt wrote: > Hi all, > > Please review this fix for getting rid of some JDK 8-specific code that has > snuck into core. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6266 > Patch: > > <---8<---> > diff -r abb4b7f54009 > > core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/ > flightrecorder/rules/jdk/general/DuplicateFlagsRule.java > --- > > a/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm > c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Thu Dec 06 > 19:12:44 2018 +0100 > +++ > > b/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm > c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Tue Dec 11 > 13:47:26 2018 +0100 > @@ -44,6 +44,7 @@ > import org.openjdk.jmc.common.item.Aggregators; > import org.openjdk.jmc.common.item.IItemCollection; > import org.openjdk.jmc.common.util.IPreferenceValueProvider; > +import org.openjdk.jmc.common.util.StringToolkit; > import org.openjdk.jmc.common.util.TypedPreference; > import org.openjdk.jmc.flightrecorder.jdk.JdkAttributes; > import org.openjdk.jmc.flightrecorder.jdk.JdkFilters; > @@ -81,7 +82,7 @@ > StringBuilder sb = new StringBuilder(); > sb.append("
    "); //$NON-NLS-1$ > for (ArrayList dupe : dupes) { > - sb.append("
  • " + > Encode.forHtml(String.join(", ", dupe)) + "
  • "); //$NON-NLS-1$ > //$NON-NLS-2$ > + sb.append("
  • " + > Encode.forHtml(StringToolkit.join(dupe, ", ")) + "
  • "); //$NON-NLS-1$ > //$NON-NLS-2$ > } > sb.append("
"); //$NON-NLS-1$ > String shortDescription = dupes.size() > 1 > <---8<---> > > Kind regards, > Marcus > > From marcus at hirt.se Tue Dec 11 18:10:23 2018 From: marcus at hirt.se (Marcus Hirt) Date: Tue, 11 Dec 2018 19:10:23 +0100 Subject: SV: RFR: JMC-6266: JDK 8 specific code in core (String.join) In-Reply-To: References: <015201d49150$516e2090$f44a61b0$@hirt.se> Message-ID: <02c701d4917c$c90b24f0$5b216ed0$@hirt.se> Can I get a +1 on this silly little fix? ;) Kind regards, Marcus Fr?n: Joshua Matsuoka Skickat: den 11 december 2018 16:20 Till: Marcus Hirt Kopia: jmc-dev at openjdk.java.net ?mne: Re: RFR: JMC-6266: JDK 8 specific code in core (String.join) Hi Marcus, Looks good. Cheers, - Josh On Tue, Dec 11, 2018 at 7:52 AM Marcus Hirt > wrote: Hi all, Please review this fix for getting rid of some JDK 8-specific code that has snuck into core. Jira: https://bugs.openjdk.java.net/browse/JMC-6266 Patch: <---8<---> diff -r abb4b7f54009 core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/ flightrecorder/rules/jdk/general/DuplicateFlagsRule.java --- a/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Thu Dec 06 19:12:44 2018 +0100 +++ b/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Tue Dec 11 13:47:26 2018 +0100 @@ -44,6 +44,7 @@ import org.openjdk.jmc.common.item.Aggregators; import org.openjdk.jmc.common.item.IItemCollection; import org.openjdk.jmc.common.util.IPreferenceValueProvider; +import org.openjdk.jmc.common.util.StringToolkit; import org.openjdk.jmc.common.util.TypedPreference; import org.openjdk.jmc.flightrecorder.jdk.JdkAttributes; import org.openjdk.jmc.flightrecorder.jdk.JdkFilters; @@ -81,7 +82,7 @@ StringBuilder sb = new StringBuilder(); sb.append("
    "); //$NON-NLS-1$ for (ArrayList dupe : dupes) { - sb.append("
  • " + Encode.forHtml(String.join(", ", dupe)) + "
  • "); //$NON-NLS-1$ //$NON-NLS-2$ + sb.append("
  • " + Encode.forHtml(StringToolkit.join(dupe, ", ")) + "
  • "); //$NON-NLS-1$ //$NON-NLS-2$ } sb.append("
"); //$NON-NLS-1$ String shortDescription = dupes.size() > 1 <---8<---> Kind regards, Marcus From ebaron at redhat.com Tue Dec 11 18:11:41 2018 From: ebaron at redhat.com (Elliott Baron) Date: Tue, 11 Dec 2018 13:11:41 -0500 Subject: SV: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: <61e201d48dae$512126a0$f36373e0$@hirt.se> References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> <61e201d48dae$512126a0$f36373e0$@hirt.se> Message-ID: Hi Marcus, On 2018-12-06 4:54 p.m., Marcus Hirt wrote: > Quite frankly, we shouldn't need to, but I think we currently do > this across all code. It looks like at least the UI tests don't use NON-NLS tags. This seems to be intentional since the checked-in Eclipse settings are set to ignore non-externalized string literals [1]: > eclipse.preferences.version=1 > org.eclipse.jdt.core.compiler.problem.nonExternalizedStringLiteral=ignore Should I add the tags to my test for this patch, or is the latest patch good to go? Thanks, Elliott [1] http://hg.openjdk.java.net/jmc/jmc/file/abb4b7f54009/application/uitests/org.openjdk.jmc.browser.uitest/.settings/org.eclipse.jdt.core.prefs#l2 > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Elliott Baron > Skickat: den 6 december 2018 21:10 > Till: Marcus Hirt ; jmc-dev at openjdk.java.net > ?mne: Re: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables > > Hi Marcus, > > On 2018-12-06 1:34 p.m., Marcus Hirt wrote: >> Hi Elliott, >> >> Just one nit - don't forget to put //$NON-NLS-1$ tags on string >> constants that should not be localized, e.g.: >> >> private static final String FIXED_TEXT_FONT = >> "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ >> >> Looks fine - don't need another review after fixing this. >> >> Thank you for your contribution! >> >> Kind regards, >> Marcus > > Thanks for the review! > > I have added the missing NON-NLS tag (and set Eclipse to warn me in the future). Am I correct that these tags are not required for test classes? > > Thanks, > Elliott -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6180-v2.patch Type: text/x-patch Size: 10369 bytes Desc: not available URL: From marcus.hirt at oracle.com Tue Dec 11 18:16:51 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 11 Dec 2018 19:16:51 +0100 Subject: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> <61e201d48dae$512126a0$f36373e0$@hirt.se> Message-ID: <1FF8AE2E-06D6-4518-A144-78C3B9EA1B3D@oracle.com> Yep! Good to go! Kind regards, Marcus ?On 2018-12-11, 19:11, "Elliott Baron" wrote: Hi Marcus, On 2018-12-06 4:54 p.m., Marcus Hirt wrote: > Quite frankly, we shouldn't need to, but I think we currently do > this across all code. It looks like at least the UI tests don't use NON-NLS tags. This seems to be intentional since the checked-in Eclipse settings are set to ignore non-externalized string literals [1]: > eclipse.preferences.version=1 > org.eclipse.jdt.core.compiler.problem.nonExternalizedStringLiteral=ignore Should I add the tags to my test for this patch, or is the latest patch good to go? Thanks, Elliott [1] http://hg.openjdk.java.net/jmc/jmc/file/abb4b7f54009/application/uitests/org.openjdk.jmc.browser.uitest/.settings/org.eclipse.jdt.core.prefs#l2 > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Elliott Baron > Skickat: den 6 december 2018 21:10 > Till: Marcus Hirt ; jmc-dev at openjdk.java.net > ?mne: Re: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables > > Hi Marcus, > > On 2018-12-06 1:34 p.m., Marcus Hirt wrote: >> Hi Elliott, >> >> Just one nit - don't forget to put //$NON-NLS-1$ tags on string >> constants that should not be localized, e.g.: >> >> private static final String FIXED_TEXT_FONT = >> "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ >> >> Looks fine - don't need another review after fixing this. >> >> Thank you for your contribution! >> >> Kind regards, >> Marcus > > Thanks for the review! > > I have added the missing NON-NLS tag (and set Eclipse to warn me in the future). Am I correct that these tags are not required for test classes? > > Thanks, > Elliott From marcus.hirt at oracle.com Tue Dec 11 18:27:17 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 11 Dec 2018 19:27:17 +0100 Subject: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> <61e201d48dae$512126a0$f36373e0$@hirt.se> Message-ID: There seem to be uitest classes that do contain NON-NLS tags. I will open a bug to clean this up. Kind regards, Marcus ?On 2018-12-11, 19:11, "Elliott Baron" wrote: Hi Marcus, On 2018-12-06 4:54 p.m., Marcus Hirt wrote: > Quite frankly, we shouldn't need to, but I think we currently do > this across all code. It looks like at least the UI tests don't use NON-NLS tags. This seems to be intentional since the checked-in Eclipse settings are set to ignore non-externalized string literals [1]: > eclipse.preferences.version=1 > org.eclipse.jdt.core.compiler.problem.nonExternalizedStringLiteral=ignore Should I add the tags to my test for this patch, or is the latest patch good to go? Thanks, Elliott [1] http://hg.openjdk.java.net/jmc/jmc/file/abb4b7f54009/application/uitests/org.openjdk.jmc.browser.uitest/.settings/org.eclipse.jdt.core.prefs#l2 > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Elliott Baron > Skickat: den 6 december 2018 21:10 > Till: Marcus Hirt ; jmc-dev at openjdk.java.net > ?mne: Re: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables > > Hi Marcus, > > On 2018-12-06 1:34 p.m., Marcus Hirt wrote: >> Hi Elliott, >> >> Just one nit - don't forget to put //$NON-NLS-1$ tags on string >> constants that should not be localized, e.g.: >> >> private static final String FIXED_TEXT_FONT = >> "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ >> >> Looks fine - don't need another review after fixing this. >> >> Thank you for your contribution! >> >> Kind regards, >> Marcus > > Thanks for the review! > > I have added the missing NON-NLS tag (and set Eclipse to warn me in the future). Am I correct that these tags are not required for test classes? > > Thanks, > Elliott From miro.wengner at gmail.com Tue Dec 11 19:10:09 2018 From: miro.wengner at gmail.com (Miro Wengner) Date: Tue, 11 Dec 2018 20:10:09 +0100 Subject: RFR: JMC-6266: JDK 8 specific code in core (String.join) In-Reply-To: <02c701d4917c$c90b24f0$5b216ed0$@hirt.se> References: <015201d49150$516e2090$f44a61b0$@hirt.se> <02c701d4917c$c90b24f0$5b216ed0$@hirt.se> Message-ID: <00C030B2-46B3-47FF-9764-C839C3A6EDB0@gmail.com> Hi Marcus, I?ve test your little ?silly? fix, I?ve also tested with oracle-jdk1.7_80 JfrHtmlRulesReport looks good to me Kind Regards, Miro > On Dec 11, 2018, at 7:10 PM, Marcus Hirt wrote: > > Can I get a +1 on this silly little fix? ;) > > > > Kind regards, > > Marcus > > > > Fr?n: Joshua Matsuoka > Skickat: den 11 december 2018 16:20 > Till: Marcus Hirt > Kopia: jmc-dev at openjdk.java.net > ?mne: Re: RFR: JMC-6266: JDK 8 specific code in core (String.join) > > > > Hi Marcus, > > > > Looks good. > > > > Cheers, > > > > - Josh > > > > On Tue, Dec 11, 2018 at 7:52 AM Marcus Hirt > wrote: > > Hi all, > > Please review this fix for getting rid of some JDK 8-specific code that has > snuck into core. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6266 > Patch: > > <---8<---> > diff -r abb4b7f54009 > core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/ > flightrecorder/rules/jdk/general/DuplicateFlagsRule.java > --- > a/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm > c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Thu Dec 06 > 19:12:44 2018 +0100 > +++ > b/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jm > c/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java Tue Dec 11 > 13:47:26 2018 +0100 > @@ -44,6 +44,7 @@ > import org.openjdk.jmc.common.item.Aggregators; > import org.openjdk.jmc.common.item.IItemCollection; > import org.openjdk.jmc.common.util.IPreferenceValueProvider; > +import org.openjdk.jmc.common.util.StringToolkit; > import org.openjdk.jmc.common.util.TypedPreference; > import org.openjdk.jmc.flightrecorder.jdk.JdkAttributes; > import org.openjdk.jmc.flightrecorder.jdk.JdkFilters; > @@ -81,7 +82,7 @@ > StringBuilder sb = new StringBuilder(); > sb.append("
    "); //$NON-NLS-1$ > for (ArrayList dupe : dupes) { > - sb.append("
  • " + > Encode.forHtml(String.join(", ", dupe)) + "
  • "); //$NON-NLS-1$ > //$NON-NLS-2$ > + sb.append("
  • " + > Encode.forHtml(StringToolkit.join(dupe, ", ")) + "
  • "); //$NON-NLS-1$ > //$NON-NLS-2$ > } > sb.append("
"); //$NON-NLS-1$ > String shortDescription = dupes.size() > 1 > <---8<---> > > Kind regards, > Marcus > From marcus.hirt at oracle.com Tue Dec 11 19:15:08 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 11 Dec 2018 19:15:08 +0000 Subject: hg: jmc/jmc: JMC-6266: Making core compile with/run on JDK 7 again Message-ID: <201812111915.wBBJF8ts027879@aojmv0008.oracle.com> Changeset: 48b0eb1e3f18 Author: hirt Date: 2018-12-11 20:11 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/48b0eb1e3f18 JMC-6266: Making core compile with/run on JDK 7 again Reviewed-by: jmatsuoka,mwengner ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/DuplicateFlagsRule.java From aazores at redhat.com Tue Dec 11 20:30:50 2018 From: aazores at redhat.com (Andrew Azores) Date: Tue, 11 Dec 2018 15:30:50 -0500 Subject: SV: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: <012b01d4914e$17c39fc0$474adf40$@hirt.se> References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> Message-ID: On 2018-12-11 7:36 a.m., Marcus Hirt wrote: > Hi Andrew, > > Looks good, but please fix the associated tests first, then > I'll take a closer look. > > <--8<--> > [ERROR] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 9.674 s <<< FAILURE! - in org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr > [ERROR] verifyOneResult(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr) Time elapsed: 2.398 s <<< FAILURE! > java.lang.AssertionError: > > > Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report. > at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159) > at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyOneResult(TestRulesWithJfr.java:126) > > [ERROR] verifyAllResults(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr) Time elapsed: 7.234 s <<< FAILURE! > java.lang.AssertionError: > > > Report for file "wls-medrec-jdk9.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "wldf.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "stringdedup_enabled_jdk9.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "parallel-on-singlecpu.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "parallel-gc_cpu.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "flight_recording_hidden.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "crash_jdk9.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "allocation_10s_fixed.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report. > at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159) > at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyAllResults(TestRulesWithJfr.java:132) > <--8<--> > > Kind regards, > Marcus > Ah, sorry for that. Thanks for the notice. An updated patch is attached. The existing test cases do not fully exercise the rule - the exercised pathways are "events emitted but no Full GCs" and "no events emitted", so we are missing the path where Full GC events do occur (x2, for each collector). Is there a procedure or guideline for adding additional flight recordings which do capture this scenario and exercise the rules in this manner? -- Andrew Azores Software Engineer, OpenJDK Team Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: fullgcrule-02.patch Type: text/x-patch Size: 24374 bytes Desc: not available URL: From marcus at hirt.se Wed Dec 12 12:43:08 2018 From: marcus at hirt.se (Marcus Hirt) Date: Wed, 12 Dec 2018 13:43:08 +0100 Subject: SV: SV: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> Message-ID: <070301d49218$3c1e0de0$b45a29a0$@hirt.se> Hi Andrew, There are, sadly, no official guidelines for adding recordings. That said, try to: 1. Keep the recording small, e.g. make the recording as short as possible, use a template where some unrelated events are disabled (take care, some events are more or less expected, e.g. Flight Recorder meta events). 2. Look through the data to ensure it doesn't contain something you don't want to share. For example, it's all too easy to get a password or password hash in the environment variable or system property events. Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: Andrew Azores Skickat: den 11 december 2018 21:31 Till: Marcus Hirt ; jmc-dev at openjdk.java.net ?mne: Re: SV: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS On 2018-12-11 7:36 a.m., Marcus Hirt wrote: > Hi Andrew, > > Looks good, but please fix the associated tests first, then I'll take > a closer look. > > <--8<--> > [ERROR] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time > elapsed: 9.674 s <<< FAILURE! - in > org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr > [ERROR] verifyOneResult(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr) Time elapsed: 2.398 s <<< FAILURE! > java.lang.AssertionError: > > > Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report. > at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159) > at > org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyO > neResult(TestRulesWithJfr.java:126) > > [ERROR] verifyAllResults(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr) Time elapsed: 7.234 s <<< FAILURE! > java.lang.AssertionError: > > > Report for file "wls-medrec-jdk9.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "wldf.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "stringdedup_enabled_jdk9.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "parallel-on-singlecpu.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "parallel-gc_cpu.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "flight_recording_hidden.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "crash_jdk9.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "allocation_10s_fixed.jfr", rule result for "FullGc" could not be found in the other report. > > Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report. > at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159) > at > org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyA > llResults(TestRulesWithJfr.java:132) > <--8<--> > > Kind regards, > Marcus > Ah, sorry for that. Thanks for the notice. An updated patch is attached. The existing test cases do not fully exercise the rule - the exercised pathways are "events emitted but no Full GCs" and "no events emitted", so we are missing the path where Full GC events do occur (x2, for each collector). Is there a procedure or guideline for adding additional flight recordings which do capture this scenario and exercise the rules in this manner? -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From marcus at hirt.se Wed Dec 12 13:49:28 2018 From: marcus at hirt.se (Marcus Hirt) Date: Wed, 12 Dec 2018 14:49:28 +0100 Subject: RFR: JMC-5541: Updating JMC landing page with new coordinates and screenshots Message-ID: <071a01d49221$803e4e50$80baeaf0$@hirt.se> Hi all, Please review this fix to update the JMC update site landing page and images. Jira: https://bugs.openjdk.java.net/browse/JMC-5541 Patch: http://cr.openjdk.java.net/~hirt/JMC-5541/webrev.0/ Kind regards, Marcus From guru.hb at oracle.com Wed Dec 12 14:02:16 2018 From: guru.hb at oracle.com (Guru) Date: Wed, 12 Dec 2018 19:32:16 +0530 Subject: RFR: JMC-5541: Updating JMC landing page with new coordinates and screenshots In-Reply-To: <071a01d49221$803e4e50$80baeaf0$@hirt.se> References: <071a01d49221$803e4e50$80baeaf0$@hirt.se> Message-ID: +1 Looks good to me. Thanks, Guru > On 12-Dec-2018, at 7:19 PM, Marcus Hirt wrote: > > Hi all, > > Please review this fix to update the JMC update site landing page and > images. > > Jira: https://bugs.openjdk.java.net/browse/JMC-5541 > Patch: http://cr.openjdk.java.net/~hirt/JMC-5541/webrev.0/ > > Kind regards, > Marcus > > From marcus.hirt at oracle.com Wed Dec 12 14:11:20 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Wed, 12 Dec 2018 14:11:20 +0000 Subject: hg: jmc/jmc: JMC-5541: Updating JMC landing page with new coordinates and screenshots Message-ID: <201812121411.wBCEBKc5014411@aojmv0008.oracle.com> Changeset: efeb1e97bec3 Author: hirt Date: 2018-12-12 15:11 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/efeb1e97bec3 JMC-5541: Updating JMC landing page with new coordinates and screenshots Reviewed-by: ghb ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-01-small.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-01.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-02-small.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-02.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-03-small.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-03.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-04-small.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-04.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-05-small.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-05.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-06-small.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/images/step-06.png ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html From guru.hb at oracle.com Wed Dec 12 14:23:37 2018 From: guru.hb at oracle.com (Guru) Date: Wed, 12 Dec 2018 19:53:37 +0530 Subject: CFV: New jmc Committer: Joshua Matsuoka In-Reply-To: <584CA65A-FA24-4F6F-8D84-53371F32B977@oracle.com> References: <584CA65A-FA24-4F6F-8D84-53371F32B977@oracle.com> Message-ID: Vote: Yes > On 06-Dec-2018, at 1:53 AM, Marcus Hirt wrote: > > I hereby nominate Joshua Matsuoka to jmc Committer. > > Josh has been a prolific contributor to JDK Mission Control over the past > months, with 8 contributions already and 2 in the works. He has been a fast > learner, shown great initiative and an ability to work independently with very > little supervision. > > Votes are due by 2018-12-13, 17:00 CET. > > Only current jmc Committers (and Reviewers, of course) [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, > Marcus > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From marcus at hirt.se Wed Dec 12 20:56:14 2018 From: marcus at hirt.se (Marcus Hirt) Date: Wed, 12 Dec 2018 21:56:14 +0100 Subject: RFR: JMC-4467: Reducing roundtrips required for enablement checking Message-ID: <0ca901d4925d$1ea7e340$5bf7a9c0$@hirt.se> Hi all, Please review this fix to optimize the checks for JFR enablement, and to optimize the checks for commercial features enablement for JDK 11+. Jira: https://bugs.openjdk.java.net/browse/JMC-4467 Patch: http://cr.openjdk.java.net/~hirt/JMC-4467/webrev.0/ Kind regards, Marcus From almacdon at redhat.com Wed Dec 12 21:08:05 2018 From: almacdon at redhat.com (Alex Macdonald) Date: Wed, 12 Dec 2018 16:08:05 -0500 Subject: RFR: JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value Message-ID: Hi! This patch addresses JMC-6256 [0], in which MIN_VALUEs are displayed in their numeric form instead of being displayed as a N/A or missing value. For testing purposes, I have been using the memoryleak.jfr recording that is available as an attachment on JMC-6127 [1]. As per the comments in the bug report, there are 6 cases to consider for missing values in JMC [2]. Additionally, it may be nice to show the actual value in parenthesis in the tooltip [3]. Screenshots (album [4]): Before: https://imgur.com/aoGgzRn [5] After: https://imgur.com/DVnHQGZ [6] The culprit here seems to be the way the conditionals in the "getValueString()" [7][8] end up processing the value. There is a duplication of the "instanceof IDisplayable" in the JfrPropertySheet [7] and the TypeHandling [8], and the TypeHandling.getValueString() ends up being called anyways in the JfrPropertySheet.getValueString(). As a result, the conditional to see if it's an IDisplayable from the JfrPropertySheet happens before the conditional to see if it is a min value [9] (which is where we want to end up in this case). This patch removes the duplicated conditional from the JfrPropertySheet, because it is already correctly handled in TypeHandling. Additionally, a function "getNumericString" has been introduced for the display of the tooltip. If the value is an IQuantity then "getNumericString" will figure out which missing value type it is, and display it in the tooltip. If the value is an IQuantity but not a missing value, then it delegates to TypeHandling.getValueString(). I've also included a quick unit test to verify the behaviour of "getNumericString". Thoughts? Cheers, Alex [0] https://bugs.openjdk.java.net/browse/JMC-6256 [1] https://bugs.openjdk.java.net/browse/JMC-6127 [2] https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229297&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229297 [3] https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229296&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229296 [4] https://imgur.com/a/3BZNHnG [5] https://imgur.com/aoGgzRn [6] https://imgur.com/DVnHQGZ [7] http://hg.openjdk.java.net/jmc/jmc/file/a76a464b3764/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java#l307 [8] http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l171 [9] http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l167 -------------- next part -------------- A non-text attachment was scrubbed... Name: 6256-0.patch Type: text/x-patch Size: 9360 bytes Desc: not available URL: From kdobson at redhat.com Wed Dec 12 21:23:36 2018 From: kdobson at redhat.com (Ken Dobson) Date: Wed, 12 Dec 2018 16:23:36 -0500 Subject: JMC-6241: Leaking Context Menu items In-Reply-To: References: Message-ID: Hi all, Josh has reviewed this however this still requires one more review. If someone has the time to give it a quick review that'd be great. Thanks, Ken Dobson On Thu, Dec 6, 2018 at 11:43 AM Joshua Matsuoka wrote: > Hi Ken, > > I applied the patch and it works well. > > Looks good. > > Cheers, > > - Josh > > On Tue, Dec 4, 2018 at 3:45 PM Ken Dobson wrote: > >> Hi all, >> >> This patch does a couple things. >> 1. It fixes the leaking context menu items which resulted in the context >> menu having multiple sets of the same thread activity lanes listed. >> 2. It adds a context menu to the Garbage Collections Page legend as there >> already was one for the Java Application page. >> 3. Fixes a small bug that lead to the Thread Activity lane on the GC page >> only refreshing if it was turned off and then back on again. >> >> If someone could give it a review that would be great. >> >> https://bugs.openjdk.java.net/browse/JMC-6241 >> >> Thanks, >> >> Ken Dobson >> >> From marcus.hirt at oracle.com Wed Dec 12 21:33:38 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 12 Dec 2018 22:33:38 +0100 Subject: JMC-6241: Leaking Context Menu items In-Reply-To: <0A1C7C29-964B-4091-875E-65D6D1D1E680@redhat.com> References: <0A1C7C29-964B-4091-875E-65D6D1D1E680@redhat.com> Message-ID: Looks ok for 7.0.0! Kind regards, Marcus ?On 2018-12-12, 22:24, "jmc-dev on behalf of Ken Dobson" wrote: Hi all, Josh has reviewed this however this still requires one more review. If someone has the time to give it a quick review that'd be great. Thanks, Ken Dobson On Thu, Dec 6, 2018 at 11:43 AM Joshua Matsuoka wrote: > Hi Ken, > > I applied the patch and it works well. > > Looks good. > > Cheers, > > - Josh > > On Tue, Dec 4, 2018 at 3:45 PM Ken Dobson wrote: > >> Hi all, >> >> This patch does a couple things. >> 1. It fixes the leaking context menu items which resulted in the context >> menu having multiple sets of the same thread activity lanes listed. >> 2. It adds a context menu to the Garbage Collections Page legend as there >> already was one for the Java Application page. >> 3. Fixes a small bug that lead to the Thread Activity lane on the GC page >> only refreshing if it was turned off and then back on again. >> >> If someone could give it a review that would be great. >> >> https://bugs.openjdk.java.net/browse/JMC-6241 >> >> Thanks, >> >> Ken Dobson >> >> From marcus.hirt at oracle.com Wed Dec 12 21:46:04 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 12 Dec 2018 22:46:04 +0100 Subject: JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value In-Reply-To: <16B2B8A3-C8D8-4552-B2AF-8DCFACFBF50A@redhat.com> References: <16B2B8A3-C8D8-4552-B2AF-8DCFACFBF50A@redhat.com> Message-ID: <7E29012E-506C-469E-8371-6BB1FB2F384A@oracle.com> Hi Alex, Quick comment before going to bed: I don't believe we should externalize Integer.MIN_VALUE etc. They are defined in the java core libraries. One could argue for MISSING_VALUE and MISSING_VALUE_TOOLTIP to be externalized though. Kind regards, Marcus ?On 2018-12-12, 22:10, "jmc-dev on behalf of Alex Macdonald" wrote: Hi! This patch addresses JMC-6256 [0], in which MIN_VALUEs are displayed in their numeric form instead of being displayed as a N/A or missing value. For testing purposes, I have been using the memoryleak.jfr recording that is available as an attachment on JMC-6127 [1]. As per the comments in the bug report, there are 6 cases to consider for missing values in JMC [2]. Additionally, it may be nice to show the actual value in parenthesis in the tooltip [3]. Screenshots (album [4]): Before: https://imgur.com/aoGgzRn [5] After: https://imgur.com/DVnHQGZ [6] The culprit here seems to be the way the conditionals in the "getValueString()" [7][8] end up processing the value. There is a duplication of the "instanceof IDisplayable" in the JfrPropertySheet [7] and the TypeHandling [8], and the TypeHandling.getValueString() ends up being called anyways in the JfrPropertySheet.getValueString(). As a result, the conditional to see if it's an IDisplayable from the JfrPropertySheet happens before the conditional to see if it is a min value [9] (which is where we want to end up in this case). This patch removes the duplicated conditional from the JfrPropertySheet, because it is already correctly handled in TypeHandling. Additionally, a function "getNumericString" has been introduced for the display of the tooltip. If the value is an IQuantity then "getNumericString" will figure out which missing value type it is, and display it in the tooltip. If the value is an IQuantity but not a missing value, then it delegates to TypeHandling.getValueString(). I've also included a quick unit test to verify the behaviour of "getNumericString". Thoughts? Cheers, Alex [0] https://bugs.openjdk.java.net/browse/JMC-6256 [1] https://bugs.openjdk.java.net/browse/JMC-6127 [2] https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229297&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229297 [3] https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229296&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229296 [4] https://imgur.com/a/3BZNHnG [5] https://imgur.com/aoGgzRn [6] https://imgur.com/DVnHQGZ [7] http://hg.openjdk.java.net/jmc/jmc/file/a76a464b3764/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java#l307 [8] http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l171 [9] http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l167 From erik.gahlin at oracle.com Wed Dec 12 22:19:34 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 12 Dec 2018 23:19:34 +0100 Subject: RFR: JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value In-Reply-To: References: Message-ID: <5C118976.9050705@oracle.com> Nice work! We will add N/A values to ThreadPark and OldObjectSample event for JDK 12, so this will be great! Erik > Hi! > > This patch addresses JMC-6256 [0], in which MIN_VALUEs are displayed in > their numeric form instead of being displayed as a N/A or missing value. > For testing purposes, I have been using the memoryleak.jfr recording that > is available as an attachment on JMC-6127 [1]. > > As per the comments in the bug report, there are 6 cases to consider for > missing values in JMC [2]. Additionally, it may be nice to show the actual > value in parenthesis in the tooltip [3]. > > Screenshots (album [4]): > Before: https://imgur.com/aoGgzRn [5] > After: https://imgur.com/DVnHQGZ [6] > > The culprit here seems to be the way the conditionals in the > "getValueString()" [7][8] end up processing the value. There is a > duplication of the "instanceof IDisplayable" in the JfrPropertySheet [7] > and the TypeHandling [8], and the TypeHandling.getValueString() ends up > being called anyways in the JfrPropertySheet.getValueString(). As a result, > the conditional to see if it's an IDisplayable from the JfrPropertySheet > happens before the conditional to see if it is a min value [9] (which is > where we want to end up in this case). > > This patch removes the duplicated conditional from the JfrPropertySheet, > because it is already correctly handled in TypeHandling. Additionally, a > function "getNumericString" has been introduced for the display of the > tooltip. If the value is an IQuantity then "getNumericString" will figure > out which missing value type it is, and display it in the tooltip. If the > value is an IQuantity but not a missing value, then it delegates to > TypeHandling.getValueString(). I've also included a quick unit test to > verify the behaviour of "getNumericString". > > Thoughts? > > Cheers, > > Alex > > [0] https://bugs.openjdk.java.net/browse/JMC-6256 > [1] https://bugs.openjdk.java.net/browse/JMC-6127 > [2] > https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229297&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229297 > [3] > https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229296&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229296 > [4] https://imgur.com/a/3BZNHnG > [5] https://imgur.com/aoGgzRn > [6] https://imgur.com/DVnHQGZ > [7] > http://hg.openjdk.java.net/jmc/jmc/file/a76a464b3764/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java#l307 > [8] > http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l171 > [9] > http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l167 From miro.wengner at gmail.com Wed Dec 12 22:46:42 2018 From: miro.wengner at gmail.com (Miro Wengner) Date: Wed, 12 Dec 2018 23:46:42 +0100 Subject: RFR: JMC-4467: Reducing roundtrips required for enablement checking In-Reply-To: <0ca901d4925d$1ea7e340$5bf7a9c0$@hirt.se> References: <0ca901d4925d$1ea7e340$5bf7a9c0$@hirt.se> Message-ID: Hi Marcus, I?ve tested it but I didn?t received any log messages tested jdks: oracle1.8_191 and openjdk11 when I wanted to start jfr recording on any running project I got a error window I?m sending you some screen shots maybe someone other can test too ? Kind Regards, Miro > On Dec 12, 2018, at 9:56 PM, Marcus Hirt wrote: > > Hi all, > > Please review this fix to optimize the checks for JFR enablement, and to > optimize the checks for commercial features enablement for JDK 11+. > > Jira: https://bugs.openjdk.java.net/browse/JMC-4467 > Patch: http://cr.openjdk.java.net/~hirt/JMC-4467/webrev.0/ > > Kind regards, > Marcus > From guru.hb at oracle.com Thu Dec 13 08:08:42 2018 From: guru.hb at oracle.com (Guru) Date: Thu, 13 Dec 2018 13:38:42 +0530 Subject: RFR: JMC-4467: Reducing roundtrips required for enablement checking In-Reply-To: References: <0ca901d4925d$1ea7e340$5bf7a9c0$@hirt.se> Message-ID: +1 looks good to me. Verified with OpenJDK 11.0.2. Verified jfr recording and didn?t see any error window (as Miro encountered). Thanks, Guru > On 13-Dec-2018, at 4:16 AM, Miro Wengner wrote: > > Hi Marcus, > I?ve tested it but I didn?t received any log messages > tested jdks: oracle1.8_191 and openjdk11 > > when I wanted to start jfr recording on any running project I got a error window > I?m sending you some screen shots > > maybe someone other can test too ? > > Kind Regards, > Miro > > >> On Dec 12, 2018, at 9:56 PM, Marcus Hirt wrote: >> >> Hi all, >> >> Please review this fix to optimize the checks for JFR enablement, and to >> optimize the checks for commercial features enablement for JDK 11+. >> >> Jira: https://bugs.openjdk.java.net/browse/JMC-4467 >> Patch: http://cr.openjdk.java.net/~hirt/JMC-4467/webrev.0/ >> >> Kind regards, >> Marcus >> > From marcus.hirt at oracle.com Thu Dec 13 09:42:06 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 13 Dec 2018 10:42:06 +0100 Subject: Subject: Review request for JMC-6269: Adding Eclipse 2018-09 as optional platform Message-ID: <2CCC6F97-0509-4AF8-BB87-F271AF6C15EF@oracle.com> Hi all, Please review this change to add Eclipse 2018-09 as an optional platform. Run maven with -P2018-09 to try it out. Jira: https://bugs.openjdk.java.net/browse/JMC-6269 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6269/webrev.0/ Kind regards, Marcus From marcus.hirt at oracle.com Thu Dec 13 09:45:25 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 13 Dec 2018 10:45:25 +0100 Subject: New jmc Committer: Joshua Matsuoka In-Reply-To: <45363D88-F25C-4BCA-AC8B-89E1A42172F1@oracle.com> References: <45363D88-F25C-4BCA-AC8B-89E1A42172F1@oracle.com> Message-ID: <0D6172D3-C672-4EEC-9BC9-75678D07849A@oracle.com> Vote: yes ?On 2018-12-05, 21:24, "jmc-dev on behalf of Marcus Hirt" wrote: I hereby nominate Joshua Matsuoka to jmc Committer. Josh has been a prolific contributor to JDK Mission Control over the past months, with 8 contributions already and 2 in the works. He has been a fast learner, shown great initiative and an ability to work independently with very little supervision. Votes are due by 2018-12-13, 17:00 CET. Only current jmc Committers (and Reviewers, of course) [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, Marcus [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From aazores at redhat.com Wed Dec 12 20:30:51 2018 From: aazores at redhat.com (Andrew Azores) Date: Wed, 12 Dec 2018 15:30:51 -0500 Subject: SV: SV: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: <070301d49218$3c1e0de0$b45a29a0$@hirt.se> References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> <070301d49218$3c1e0de0$b45a29a0$@hirt.se> Message-ID: Hi Marcus, On 2018-12-12 7:43 a.m., Marcus Hirt wrote: > Hi Andrew, > > There are, sadly, no official guidelines for adding recordings. > > That said, try to: > > 1. Keep the recording small, e.g. make the recording as short as possible, > use a template where some unrelated events are disabled (take care, > some events are more or less expected, e.g. Flight Recorder meta events). > > 2. Look through the data to ensure it doesn't contain something you don't want > to share. For example, it's all too easy to get a password or password hash > in the environment variable or system property events. > > Kind regards, > Marcus > Thanks for the tips. I have attached another updated patch. This one now includes two flight recordings, exercising the "Full GCs occurred" paths for the rule for both G1 and CMS scenarios, as well as an updated test baseline for the expected result reports for these recordings. I disabled nearly all event types and ran the recording for as little time as I was easily able to get the reproducer applet I had prepared to produce full collections. If the recordings are still too large then I'm sure I can make my applet hungrier for memory and get the desired events to occur even sooner, which should cut down on the total number of events in the recording. -- Andrew Azores Software Engineer, OpenJDK Team Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: fullgcrule-03.patch Type: text/x-patch Size: 550481 bytes Desc: not available URL: From erik.gahlin at oracle.com Thu Dec 13 13:57:39 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 13 Dec 2018 14:57:39 +0100 Subject: Subject: Review request for JMC-6269: Adding Eclipse 2018-09 as optional platform In-Reply-To: <2CCC6F97-0509-4AF8-BB87-F271AF6C15EF@oracle.com> References: <2CCC6F97-0509-4AF8-BB87-F271AF6C15EF@oracle.com> Message-ID: <5C126553.9060901@oracle.com> Looks reasonable. Erik > Hi all, > > Please review this change to add Eclipse 2018-09 as an optional platform. > Run maven with -P2018-09 to try it out. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6269 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6269/webrev.0/ > > Kind regards, > Marcus > > From marcus.hirt at oracle.com Thu Dec 13 14:38:28 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Thu, 13 Dec 2018 14:38:28 +0000 Subject: hg: jmc/jmc: JMC-4467: Reducing roundtrips required for enablement checking Message-ID: <201812131438.wBDEcSIs007706@aojmv0008.oracle.com> Changeset: c64014c59a48 Author: hirt Date: 2018-12-13 15:38 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/c64014c59a48 JMC-4467: Reducing roundtrips required for enablement checking Reviewed-by: ghb ! application/org.openjdk.jmc.rjmx.services.jfr/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/FlightRecorderServiceV1.java ! application/org.openjdk.jmc.rjmx.services.jfr/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/FlightRecorderServiceV2.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/CommercialFeaturesServiceFactory.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/HotSpot24DiagnosticCommandService.java + application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/Jdk11CommercialFeaturesService.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/version/JavaVersion.java ! core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/version/JavaVersionTest.java From marcus.hirt at oracle.com Thu Dec 13 15:47:16 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Thu, 13 Dec 2018 15:47:16 +0000 Subject: hg: jmc/jmc: JMC-6269: Adding Eclipse 2018-09 as optional platform Message-ID: <201812131547.wBDFlGnh008845@aojmv0008.oracle.com> Changeset: 2abad98fa3fc Author: hirt Date: 2018-12-13 16:47 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/2abad98fa3fc JMC-6269: Adding Eclipse 2018-09 as optional platform Reviewed-by: egahlin ! pom.xml + releng/platform-definitions/platform-definition-2018-09/.project + releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target + releng/platform-definitions/platform-definition-2018-09/pom.xml ! releng/platform-definitions/pom.xml From aazores at redhat.com Thu Dec 13 17:32:08 2018 From: aazores at redhat.com (Andrew Azores) Date: Thu, 13 Dec 2018 12:32:08 -0500 Subject: SV: SV: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> <070301d49218$3c1e0de0$b45a29a0$@hirt.se> Message-ID: On 2018-12-12 3:30 p.m., Andrew Azores wrote: > Hi Marcus, > > On 2018-12-12 7:43 a.m., Marcus Hirt wrote: >> Hi Andrew, >> >> There are, sadly, no official guidelines for adding recordings. >> >> That said, try to: >> >> 1. Keep the recording small, e.g. make the recording as short as >> possible, >> ??? use a template where some unrelated events are disabled (take care, >> ??? some events are more or less expected, e.g. Flight Recorder meta >> events). >> >> 2. Look through the data to ensure it doesn't contain something you >> don't want >> ??? to share. For example, it's all too easy to get a password or >> password hash >> ??? in the environment variable or system property events. >> >> Kind regards, >> Marcus >> > Thanks for the tips. I have attached another updated patch. This one now > includes two flight recordings, exercising the "Full GCs occurred" paths > for the rule for both G1 and CMS scenarios, as well as an updated test > baseline for the expected result reports for these recordings. I > disabled nearly all event types and ran the recording for as little time > as I was easily able to get the reproducer applet I had prepared to > produce full collections. If the recordings are still too large then I'm > sure I can make my applet hungrier for memory and get the desired events > to occur even sooner, which should cut down on the total number of > events in the recording. > This got stuck in the moderation queue due to the large size of the patch, so with Mario's help I have uploaded the patch instead as a webrev. Available here: http://cr.openjdk.java.net/~neugens/JMC-5596/webrev.01/ -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From marcus.hirt at oracle.com Thu Dec 13 17:31:19 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 13 Dec 2018 18:31:19 +0100 Subject: Result: New jmc Committer: Joshua Matsuoka Message-ID: <9E276CB1-AA85-41AE-B99A-595884BB1942@oracle.com> Voting for Joshua Matsuoka [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Kind regards, Marcus [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2018-December/000556.html From marcus.hirt at oracle.com Thu Dec 13 18:00:53 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 13 Dec 2018 19:00:53 +0100 Subject: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> <070301d49218$3c1e0de0$b45a29a0$@hirt.se> Message-ID: Hi Andrew, Looks good! Thanks for the contribution! /M ?On 2018-12-13, 18:32, "jmc-dev on behalf of Andrew Azores" wrote: On 2018-12-12 3:30 p.m., Andrew Azores wrote: > Hi Marcus, > > On 2018-12-12 7:43 a.m., Marcus Hirt wrote: >> Hi Andrew, >> >> There are, sadly, no official guidelines for adding recordings. >> >> That said, try to: >> >> 1. Keep the recording small, e.g. make the recording as short as >> possible, >> use a template where some unrelated events are disabled (take care, >> some events are more or less expected, e.g. Flight Recorder meta >> events). >> >> 2. Look through the data to ensure it doesn't contain something you >> don't want >> to share. For example, it's all too easy to get a password or >> password hash >> in the environment variable or system property events. >> >> Kind regards, >> Marcus >> > Thanks for the tips. I have attached another updated patch. This one now > includes two flight recordings, exercising the "Full GCs occurred" paths > for the rule for both G1 and CMS scenarios, as well as an updated test > baseline for the expected result reports for these recordings. I > disabled nearly all event types and ran the recording for as little time > as I was easily able to get the reproducer applet I had prepared to > produce full collections. If the recordings are still too large then I'm > sure I can make my applet hungrier for memory and get the desired events > to occur even sooner, which should cut down on the total number of > events in the recording. > This got stuck in the moderation queue due to the large size of the patch, so with Mario's help I have uploaded the patch instead as a webrev. Available here: http://cr.openjdk.java.net/~neugens/JMC-5596/webrev.01/ -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From almacdon at redhat.com Thu Dec 13 21:15:26 2018 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 13 Dec 2018 16:15:26 -0500 Subject: JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value In-Reply-To: References: <16B2B8A3-C8D8-4552-B2AF-8DCFACFBF50A@redhat.com> <7E29012E-506C-469E-8371-6BB1FB2F384A@oracle.com> Message-ID: Whoops, just realized I hit reply instead of reply-all so this didn't get sent to list, please find attached an updated patch. On Thu, Dec 13, 2018 at 10:00 AM Alex Macdonald wrote: > Hi Marcus, > > Thanks for the review and suggestion, I've amended the patch to keep the > string constants inside TypeHandling. > > On Wed, Dec 12, 2018 at 4:48 PM Marcus Hirt > wrote: > >> Hi Alex, >> >> Quick comment before going to bed: >> >> I don't believe we should externalize Integer.MIN_VALUE etc. They are >> defined >> in the java core libraries. One could argue for MISSING_VALUE and >> MISSING_VALUE_TOOLTIP to be externalized though. >> >> Kind regards, >> Marcus >> >> >> ?On 2018-12-12, 22:10, "jmc-dev on behalf of Alex Macdonald" < >> jmc-dev-bounces at openjdk.java.net on behalf of almacdon at redhat.com> wrote: >> >> Hi! >> >> This patch addresses JMC-6256 [0], in which MIN_VALUEs are displayed >> in >> their numeric form instead of being displayed as a N/A or missing >> value. >> For testing purposes, I have been using the memoryleak.jfr recording >> that >> is available as an attachment on JMC-6127 [1]. >> >> As per the comments in the bug report, there are 6 cases to consider >> for >> missing values in JMC [2]. Additionally, it may be nice to show the >> actual >> value in parenthesis in the tooltip [3]. >> >> Screenshots (album [4]): >> Before: https://imgur.com/aoGgzRn [5] >> After: https://imgur.com/DVnHQGZ [6] >> >> The culprit here seems to be the way the conditionals in the >> "getValueString()" [7][8] end up processing the value. There is a >> duplication of the "instanceof IDisplayable" in the JfrPropertySheet >> [7] >> and the TypeHandling [8], and the TypeHandling.getValueString() ends >> up >> being called anyways in the JfrPropertySheet.getValueString(). As a >> result, >> the conditional to see if it's an IDisplayable from the >> JfrPropertySheet >> happens before the conditional to see if it is a min value [9] (which >> is >> where we want to end up in this case). >> >> This patch removes the duplicated conditional from the >> JfrPropertySheet, >> because it is already correctly handled in TypeHandling. >> Additionally, a >> function "getNumericString" has been introduced for the display of the >> tooltip. If the value is an IQuantity then "getNumericString" will >> figure >> out which missing value type it is, and display it in the tooltip. If >> the >> value is an IQuantity but not a missing value, then it delegates to >> TypeHandling.getValueString(). I've also included a quick unit test to >> verify the behaviour of "getNumericString". >> >> Thoughts? >> >> Cheers, >> >> Alex >> >> [0] https://bugs.openjdk.java.net/browse/JMC-6256 >> [1] https://bugs.openjdk.java.net/browse/JMC-6127 >> [2] >> >> https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229297&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229297 >> [3] >> >> https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229296&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229296 >> [4] https://imgur.com/a/3BZNHnG >> [5] https://imgur.com/aoGgzRn >> [6] https://imgur.com/DVnHQGZ >> [7] >> >> http://hg.openjdk.java.net/jmc/jmc/file/a76a464b3764/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java#l307 >> [8] >> >> http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l171 >> [9] >> >> http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l167 >> >> >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: 6256-1.patch Type: text/x-patch Size: 8827 bytes Desc: not available URL: From mark.reinhold at oracle.com Thu Dec 13 21:58:14 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 Dec 2018 13:58:14 -0800 Subject: Result: New jmc Committer: Joshua Matsuoka In-Reply-To: <9E276CB1-AA85-41AE-B99A-595884BB1942@oracle.com> References: <9E276CB1-AA85-41AE-B99A-595884BB1942@oracle.com> Message-ID: <20181213135814.997447934@eggemoggin.niobe.net> 2018/12/13 9:31:19 -0800, marcus.hirt at oracle.com: > Voting for Joshua Matsuoka [1] is now closed. > > Yes: 3 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. So recorded. - Mark From ebaron at redhat.com Mon Dec 17 20:20:47 2018 From: ebaron at redhat.com (Elliott Baron) Date: Mon, 17 Dec 2018 15:20:47 -0500 Subject: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: <1FF8AE2E-06D6-4518-A144-78C3B9EA1B3D@oracle.com> References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> <61e201d48dae$512126a0$f36373e0$@hirt.se> <1FF8AE2E-06D6-4518-A144-78C3B9EA1B3D@oracle.com> Message-ID: Hi, On 2018-12-11 1:16 p.m., Marcus Hirt wrote: > Yep! Good to go! > > Kind regards, > Marcus Excellent. Josh, would you mind committing this patch for me? I've attached a newly rebased exported changeset. Thanks, Elliott > > ?On 2018-12-11, 19:11, "Elliott Baron" wrote: > > Hi Marcus, > > On 2018-12-06 4:54 p.m., Marcus Hirt wrote: > > Quite frankly, we shouldn't need to, but I think we currently do > > this across all code. > > It looks like at least the UI tests don't use NON-NLS tags. This seems > to be intentional since the checked-in Eclipse settings are set to > ignore non-externalized string literals [1]: > > eclipse.preferences.version=1 > > org.eclipse.jdt.core.compiler.problem.nonExternalizedStringLiteral=ignore > > Should I add the tags to my test for this patch, or is the latest patch > good to go? > > Thanks, > Elliott > > [1] > http://hg.openjdk.java.net/jmc/jmc/file/abb4b7f54009/application/uitests/org.openjdk.jmc.browser.uitest/.settings/org.eclipse.jdt.core.prefs#l2 > > > > > Kind regards, > > Marcus > > > > -----Ursprungligt meddelande----- > > Fr?n: jmc-dev F?r Elliott Baron > > Skickat: den 6 december 2018 21:10 > > Till: Marcus Hirt ; jmc-dev at openjdk.java.net > > ?mne: Re: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables > > > > Hi Marcus, > > > > On 2018-12-06 1:34 p.m., Marcus Hirt wrote: > >> Hi Elliott, > >> > >> Just one nit - don't forget to put //$NON-NLS-1$ tags on string > >> constants that should not be localized, e.g.: > >> > >> private static final String FIXED_TEXT_FONT = > >> "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ > >> > >> Looks fine - don't need another review after fixing this. > >> > >> Thank you for your contribution! > >> > >> Kind regards, > >> Marcus > > > > Thanks for the review! > > > > I have added the missing NON-NLS tag (and set Eclipse to warn me in the future). Am I correct that these tags are not required for test classes? > > > > Thanks, > > Elliott > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: jmc-6180-v3.patch Type: text/x-patch Size: 10363 bytes Desc: not available URL: From jmatsuok at redhat.com Mon Dec 17 22:16:30 2018 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Mon, 17 Dec 2018 22:16:30 +0000 Subject: hg: jmc/jmc: JMC-6241: Leaking Context Menu Items Message-ID: <201812172216.wBHMGUw4015856@aojmv0008.oracle.com> Changeset: a5af2548522b Author: jmatsuoka Date: 2018-12-17 16:51 -0500 URL: http://hg.openjdk.java.net/jmc/jmc/rev/a5af2548522b JMC-6241: Leaking Context Menu Items Summary: Fix the leaking of thread activity context menu items Reviewd by: hirt, jmatsuoka Contributed-by: Ken Dobson ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ThreadGraphLanes.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/GarbageCollectionsPage.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/JavaApplicationPage.java ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java From jmatsuok at redhat.com Mon Dec 17 23:02:05 2018 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Mon, 17 Dec 2018 23:02:05 +0000 Subject: hg: jmc/jmc: JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables Message-ID: <201812172302.wBHN25Al004825@aojmv0008.oracle.com> Changeset: c4b6a87219c3 Author: jmatsuoka Date: 2018-12-17 17:33 -0500 URL: http://hg.openjdk.java.net/jmc/jmc/rev/c4b6a87219c3 JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables Summary: Editor font usage in tables/trees should use a font height consistent with other columns Reviewed-by: hirt Contributed-by: Elliott Baron ! application/org.openjdk.jmc.rjmx.ui/src/main/java/org/openjdk/jmc/rjmx/ui/attributes/ValueColumnLabelProvider.java ! application/uitests/org.openjdk.jmc.console.uitest/src/test/java/org/openjdk/jmc/console/uitest/MBeanBrowserTabTest.java ! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCTree.java From jmatsuok at redhat.com Mon Dec 17 23:03:48 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Mon, 17 Dec 2018 18:03:48 -0500 Subject: [PATCH] JMC-6180: Changing the Java source editor font changes the size of some values in the JMC tables In-Reply-To: References: <5484C93B-692E-4FD6-BF86-58245A46D6F9@redhat.com> <06313B53-E5F0-4B65-B70B-C6D96FE5E02A@oracle.com> <75136dce-e938-d221-ccfe-fd4c2c57f4f7@redhat.com> <61e201d48dae$512126a0$f36373e0$@hirt.se> <1FF8AE2E-06D6-4518-A144-78C3B9EA1B3D@oracle.com> Message-ID: Hi, Pushed: http://hg.openjdk.java.net/jmc/jmc/rev/c4b6a87219c3 Nice work! - Josh On Mon, Dec 17, 2018 at 3:20 PM Elliott Baron wrote: > Hi, > > On 2018-12-11 1:16 p.m., Marcus Hirt wrote: > > Yep! Good to go! > > > > Kind regards, > > Marcus > > Excellent. > > Josh, would you mind committing this patch for me? I've attached a newly > rebased exported changeset. > > Thanks, > Elliott > > > > > ?On 2018-12-11, 19:11, "Elliott Baron" wrote: > > > > Hi Marcus, > > > > On 2018-12-06 4:54 p.m., Marcus Hirt wrote: > > > Quite frankly, we shouldn't need to, but I think we currently do > > > this across all code. > > > > It looks like at least the UI tests don't use NON-NLS tags. This > seems > > to be intentional since the checked-in Eclipse settings are set to > > ignore non-externalized string literals [1]: > > > eclipse.preferences.version=1 > > > > org.eclipse.jdt.core.compiler.problem.nonExternalizedStringLiteral=ignore > > > > Should I add the tags to my test for this patch, or is the latest > patch > > good to go? > > > > Thanks, > > Elliott > > > > [1] > > > http://hg.openjdk.java.net/jmc/jmc/file/abb4b7f54009/application/uitests/org.openjdk.jmc.browser.uitest/.settings/org.eclipse.jdt.core.prefs#l2 > > > > > > > > Kind regards, > > > Marcus > > > > > > -----Ursprungligt meddelande----- > > > Fr?n: jmc-dev F?r Elliott > Baron > > > Skickat: den 6 december 2018 21:10 > > > Till: Marcus Hirt ; > jmc-dev at openjdk.java.net > > > ?mne: Re: [PATCH] JMC-6180: Changing the Java source editor font > changes the size of some values in the JMC tables > > > > > > Hi Marcus, > > > > > > On 2018-12-06 1:34 p.m., Marcus Hirt wrote: > > >> Hi Elliott, > > >> > > >> Just one nit - don't forget to put //$NON-NLS-1$ tags on string > > >> constants that should not be localized, e.g.: > > >> > > >> private static final String FIXED_TEXT_FONT = > > >> "org.openjdk.jmc.fixedtextfont"; //$NON-NLS-1$ > > >> > > >> Looks fine - don't need another review after fixing this. > > >> > > >> Thank you for your contribution! > > >> > > >> Kind regards, > > >> Marcus > > > > > > Thanks for the review! > > > > > > I have added the missing NON-NLS tag (and set Eclipse to warn me > in the future). Am I correct that these tags are not required for test > classes? > > > > > > Thanks, > > > Elliott > > > > > > > > > From kdobson at redhat.com Fri Dec 14 16:55:51 2018 From: kdobson at redhat.com (Ken Dobson) Date: Fri, 14 Dec 2018 11:55:51 -0500 Subject: Updating the Docs Message-ID: Hi all, This is a list of issues that I have come across while updating the docs. Please let me know the best way to handle them. Regarding Broken Links it would be good to know whether to delete it or whether we'd like that page to exist. I've attached the patch with changes I've made thus far so feel free to comment on any changes I've made to the docs if any of them aren't correct. Also if there's any questions that are received often that you would like added to the FAQs I can do that as well. Thanks, Ken Dobson Issues: 1. There is no doc for the Live Objects, should this be added? 2.* Accessibility in JDK Mission Control -> Accessibility Known Issues and Workarounds* - Unsure about when this document was written so these issues may no longer exist but there may be new ones 3.* About the JMX Console->Using the JMX Console->Working with Graphs* -The paragraphs near the beginning regarding converting graphs to a table to make them compatible with screen readers should probably be moved/copied to the Accessibility Issues and Workarounds page to make it easier to find 4. *Using the Flight Recorder Plugin->Viewing Recordings->Working with the Outline->Using the Java Application Page* -It appears we're able to modify the Method Profiling Rule in the Java Application Page configuration as well as the Method Profiling Page configuration. I think it should only exist in the Profiling configuration and we should remove it from the Java Application configuration as it doesn't really belong there given it has it's own page. Please let me know what you think about this. 5. *Using the Flight Recorder Plugin->Viewing Recordings->Working with the Outline->Using the JVM Internals Page -> Using the GC Configuration Page* -I've added definitions for a few of the terms that were missing them in the patch below however I'm unable to find a clear definition for TLAB Refill Waste Limit so if someone could send one to me so I could add it that would be great thanks. 6. *Using the Flight Recorder Plugin->Viewing Recordings->Working with the Outline->Using the JVM Internals Page -> Using the Compilations Page* -The Compilations ID is not currently enabled by default for the Compilations tab however it is for Failed Compilations. Generally the values defined in the docs have been those that are enabled by default so should it be enabled? This also leads to the question of should we also be defining values that aren't enabled by default? 7. *Using the Flight Recorder Plugin->Viewing Recordings->Working with the Outline->Using the JVM Internals Page -> Using the Code Cache Page* -Looking for a definition for Sweep Fraction Index 8. *Using the Flight Recorder Plugin->Viewing Recordings->Working with the Stacktrace* -There doesn't seem to be any reason to keep the Group Stacktraces From option that is accessible from the View Menu icon as the options for Grouping Stacktraces is available on the toolbar. I propose that we remove it from the menu. The same applies to the Layout Options as showing as a tree is already available from the toolbar. 9. *Using the Flight Recorder Plugin -> Frequently Asked Questions* -"Ensure that you are using the same version of the JVM that you want to monitor as is being used by the JVM running the JMC client." This is no longer true correct? I can run JMC on JDK 8 as long as the JVM I'd like to record is JDK11 and up. -I've removed the lines referring to using JAVA_HOME/bin/jmc to start JMC, is there anything we should replace this with? Broken Links: 10. *Using the Flight Recorder Plugin* This page states "For more information about enabling JFR, see *Enabling Flight Recorder*". *Enabling Flight Recorder* isn't a link but is clearly referring to a page, which in this case doesn't exist. It seems there shouldn't be any special steps to enabling JFR as it's available by default in JDK11 but there may be steps required for those that use the OracleJDK that I am unaware of. Should we create this page or remove this sentence? 11. *About the JVM Browser -> JDK Mission Control Communications* -*The Monitoring and Management using JMX Technology* hyperlink at the page is broken, it attempts to link to a JMC Help page that does not exist 12. *About the JMX Console->Using the JMX Console->Customizing JMX Console Settings->JMX Data Persistence Settings / About the JMX Console->Using the JMX Console->Using the Overview Tab->Graphs* -The *Working with Attributes* hyperlink is broken, topic not found. Links to an "unresolvable-reference.htm" -*Working with Attributes *is also referenced in *Using the Thread Tab* however is unlinked there. 13. *Using the Flight Recorder Plugin->Viewing Recordings* -References a *Flight Recorder Tab Reference* but is unlinked. I think we can comfortably remove this as all the tab help pages are nested underneath the *Viewing Recordings *page. 14. *About the JVM Browser -> Adding a Custom JVM Connection* *-**Storing Credentials in Settings File *is unlinked but refers to some page that doesn't exist. -------------- next part -------------- A non-text attachment was scrubbed... Name: docs.patch Type: text/x-patch Size: 62222 bytes Desc: not available URL: From marcus.hirt at oracle.com Tue Dec 18 08:48:41 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 18 Dec 2018 09:48:41 +0100 Subject: JMC 7.0.0 will release as originally planned Message-ID: Hi all, Just received word from release management that we will release JMC 7 as originally planned. We will branch ASAP and do final testing and rampdown. Please let me know if you have any low-risk changes out that you would like to get into the release, and the triage team will consider them on a case by case basis. Kind regards, Marcus From marcus.hirt at oracle.com Tue Dec 18 11:14:34 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 18 Dec 2018 12:14:34 +0100 Subject: JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value In-Reply-To: <7A1486A0-D7FD-4A44-A63B-7BEB5044C378@redhat.com> References: <16B2B8A3-C8D8-4552-B2AF-8DCFACFBF50A@redhat.com> <7E29012E-506C-469E-8371-6BB1FB2F384A@oracle.com> <7A1486A0-D7FD-4A44-A63B-7BEB5044C378@redhat.com> Message-ID: Looks good Alex! Please go ahead! Kind regards, Marcus From: Alex Macdonald Date: Thursday, 13 December 2018 at 22:16 To: Marcus Hirt , Subject: Re: JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value Whoops, just realized I hit reply instead of reply-all so this didn't get sent to list, please find attached an updated patch. On Thu, Dec 13, 2018 at 10:00 AM Alex Macdonald wrote: Hi Marcus, Thanks for the review and suggestion, I've amended the patch to keep the string constants inside TypeHandling. On Wed, Dec 12, 2018 at 4:48 PM Marcus Hirt wrote: Hi Alex, Quick comment before going to bed: I don't believe we should externalize Integer.MIN_VALUE etc. They are defined in the java core libraries. One could argue for MISSING_VALUE and MISSING_VALUE_TOOLTIP to be externalized though. Kind regards, Marcus ?On 2018-12-12, 22:10, "jmc-dev on behalf of Alex Macdonald" wrote: Hi! This patch addresses JMC-6256 [0], in which MIN_VALUEs are displayed in their numeric form instead of being displayed as a N/A or missing value. For testing purposes, I have been using the memoryleak.jfr recording that is available as an attachment on JMC-6127 [1]. As per the comments in the bug report, there are 6 cases to consider for missing values in JMC [2]. Additionally, it may be nice to show the actual value in parenthesis in the tooltip [3]. Screenshots (album [4]): Before: https://imgur.com/aoGgzRn [5] After: https://imgur.com/DVnHQGZ [6] The culprit here seems to be the way the conditionals in the "getValueString()" [7][8] end up processing the value. There is a duplication of the "instanceof IDisplayable" in the JfrPropertySheet [7] and the TypeHandling [8], and the TypeHandling.getValueString() ends up being called anyways in the JfrPropertySheet.getValueString(). As a result, the conditional to see if it's an IDisplayable from the JfrPropertySheet happens before the conditional to see if it is a min value [9] (which is where we want to end up in this case). This patch removes the duplicated conditional from the JfrPropertySheet, because it is already correctly handled in TypeHandling. Additionally, a function "getNumericString" has been introduced for the display of the tooltip. If the value is an IQuantity then "getNumericString" will figure out which missing value type it is, and display it in the tooltip. If the value is an IQuantity but not a missing value, then it delegates to TypeHandling.getValueString(). I've also included a quick unit test to verify the behaviour of "getNumericString". Thoughts? Cheers, Alex [0] https://bugs.openjdk.java.net/browse/JMC-6256 [1] https://bugs.openjdk.java.net/browse/JMC-6127 [2] https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229297&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229297 [3] https://bugs.openjdk.java.net/browse/JMC-6256?focusedCommentId=14229296&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14229296 [4] https://imgur.com/a/3BZNHnG [5] https://imgur.com/aoGgzRn [6] https://imgur.com/DVnHQGZ [7] http://hg.openjdk.java.net/jmc/jmc/file/a76a464b3764/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java#l307 [8] http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l171 [9] http://hg.openjdk.java.net/jmc/jmc/file/efeb1e97bec3/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java#l167 From neugens at redhat.com Tue Dec 18 12:39:14 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 18 Dec 2018 13:39:14 +0100 Subject: JMC 7.0.0 will release as originally planned In-Reply-To: References: Message-ID: <7977aae298214720ff6e2e19f99f9c9c977b0985.camel@redhat.com> On Tue, 2018-12-18 at 09:48 +0100, Marcus Hirt wrote: > Hi all, > > Just received word from release management that we will release JMC 7 > as > originally planned. We will branch ASAP and do final testing and > rampdown. > Please let me know if you have any low-risk changes out that you > would like to > get into the release, and the triage team will consider them on a > case by case > basis. Ok, sounds good to me. I think all our current work can be pushed just on the 7.1 repository when ready. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Tue Dec 18 12:49:46 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 18 Dec 2018 13:49:46 +0100 Subject: JMC 7.0.0 will release as originally planned In-Reply-To: <501BCA0E-CB6F-41FE-8A27-61D519A42785@redhat.com> References: <501BCA0E-CB6F-41FE-8A27-61D519A42785@redhat.com> Message-ID: Hi Mario, I think we can take JMC-6260 and JMC-6256. I'm asking around to see if someone at Oracle can get involved in JMC-6260 during next iteration. It would be great if you could push JMC-6256 ASAP. I will send out JMC-6245 for review later today. Kind regards, Marcus ?On 2018-12-18, 13:39, "Mario Torre" wrote: On Tue, 2018-12-18 at 09:48 +0100, Marcus Hirt wrote: > Hi all, > > Just received word from release management that we will release JMC 7 > as > originally planned. We will branch ASAP and do final testing and > rampdown. > Please let me know if you have any low-risk changes out that you > would like to > get into the release, and the triage team will consider them on a > case by case > basis. Ok, sounds good to me. I think all our current work can be pushed just on the 7.1 repository when ready. 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 Tue Dec 18 12:56:27 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 18 Dec 2018 13:56:27 +0100 Subject: JMC 7.0.0 will release as originally planned In-Reply-To: References: <501BCA0E-CB6F-41FE-8A27-61D519A42785@redhat.com> Message-ID: On Tue, Dec 18, 2018 at 1:50 PM Marcus Hirt wrote: > > Hi Mario, > > I think we can take JMC-6260 and JMC-6256. I'm asking around to see if > someone at Oracle can get involved in JMC-6260 during next iteration. > It would be great if you could push JMC-6256 ASAP. Makes sense. Ken sent a preliminary patch last Friday for JMC-6256, perhaps one of you can follow up? Alex has JMC-6256 reviewed, I think it just need to be pushed? I'll do so today in this case. Cheers, Mario > I will send out JMC-6245 for review later today. > > Kind regards, > Marcus > > ?On 2018-12-18, 13:39, "Mario Torre" wrote: > > On Tue, 2018-12-18 at 09:48 +0100, Marcus Hirt wrote: > > Hi all, > > > > Just received word from release management that we will release JMC 7 > > as > > originally planned. We will branch ASAP and do final testing and > > rampdown. > > Please let me know if you have any low-risk changes out that you > > would like to > > get into the release, and the triage team will consider them on a > > case by case > > basis. > > Ok, sounds good to me. > > I think all our current work can be pushed just on the 7.1 repository > when ready. > > Cheers, > Mario > -- > 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 oracle.com Tue Dec 18 13:25:41 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 18 Dec 2018 14:25:41 +0100 Subject: JMC 7.0.0 will release as originally planned In-Reply-To: References: <501BCA0E-CB6F-41FE-8A27-61D519A42785@redhat.com> Message-ID: Yep, JMC-6256 is reviewed. JMC-6260 I am trying to find someone for. /M ?On 2018-12-18, 13:57, "Mario Torre" wrote: On Tue, Dec 18, 2018 at 1:50 PM Marcus Hirt wrote: > > Hi Mario, > > I think we can take JMC-6260 and JMC-6256. I'm asking around to see if > someone at Oracle can get involved in JMC-6260 during next iteration. > It would be great if you could push JMC-6256 ASAP. Makes sense. Ken sent a preliminary patch last Friday for JMC-6256, perhaps one of you can follow up? Alex has JMC-6256 reviewed, I think it just need to be pushed? I'll do so today in this case. Cheers, Mario > I will send out JMC-6245 for review later today. > > Kind regards, > Marcus > > ?On 2018-12-18, 13:39, "Mario Torre" wrote: > > On Tue, 2018-12-18 at 09:48 +0100, Marcus Hirt wrote: > > Hi all, > > > > Just received word from release management that we will release JMC 7 > > as > > originally planned. We will branch ASAP and do final testing and > > rampdown. > > Please let me know if you have any low-risk changes out that you > > would like to > > get into the release, and the triage team will consider them on a > > case by case > > basis. > > Ok, sounds good to me. > > I think all our current work can be pushed just on the 7.1 repository > when ready. > > Cheers, > Mario > -- > 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.limasoftware at gmail.com Tue Dec 18 15:54:40 2018 From: neugens.limasoftware at gmail.com (neugens.limasoftware at gmail.com) Date: Tue, 18 Dec 2018 15:54:40 +0000 Subject: hg: jmc/jmc: JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value Message-ID: <201812181554.wBIFseLx011285@aojmv0008.oracle.com> Changeset: ef09a702e777 Author: aptmac Date: 2018-12-18 09:58 -0500 URL: http://hg.openjdk.java.net/jmc/jmc/rev/ef09a702e777 JMC-6256: JMC doesn't respect Long.MIN_VALUE as a missing value Reviewed-by: egahlin, hirt Contributed-by: Alex Macdonald ! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/messages/internal/Messages.java ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/TypeHandling.java ! core/org.openjdk.jmc.common/src/main/resources/org/openjdk/jmc/common/messages/internal/messages.properties + core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/util/TypeHandlingTest.java From marcus.hirt at oracle.com Tue Dec 18 17:42:29 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Tue, 18 Dec 2018 18:42:29 +0100 Subject: Review request for JMC-6245: JMC parser should not assume metadata event to be the last in chunk Message-ID: <8725A658-4562-4DA6-82CE-83FBF734AD73@oracle.com> Hi all, Please review this fix to make the parser stop expecting the metadata event to be the last one in the chunk. Jira: https://bugs.openjdk.java.net/browse/JMC-6245 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6245/webrev.01/ Kind regards, Marcus From erik.gahlin at oracle.com Tue Dec 18 20:47:05 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 18 Dec 2018 21:47:05 +0100 Subject: Review request for JMC-6245: JMC parser should not assume metadata event to be the last in chunk In-Reply-To: <8725A658-4562-4DA6-82CE-83FBF734AD73@oracle.com> References: <8725A658-4562-4DA6-82CE-83FBF734AD73@oracle.com> Message-ID: <59B46817-A4BB-427B-8424-461E06E154D3@oracle.com> Looks good! Erik Sent from my iPhone > On 18 Dec 2018, at 18:42, Marcus Hirt wrote: > > Hi all, > > Please review this fix to make the parser stop expecting the metadata event > to be the last one in the chunk. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6245 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6245/webrev.01/ > > Kind regards, > Marcus > > From marcus.hirt at oracle.com Tue Dec 18 20:56:30 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Tue, 18 Dec 2018 20:56:30 +0000 Subject: hg: jmc/jmc: JMC-6245: JMC parser should not assume metadata event to be the last in chunk Message-ID: <201812182056.wBIKuVR7017426@aojmv0008.oracle.com> Changeset: 455c15c6916f Author: hirt Date: 2018-12-18 21:55 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/455c15c6916f JMC-6245: JMC parser should not assume metadata event to be the last in chunk Reviewed-by: egahlin ! core/org.openjdk.jmc.flightrecorder/META-INF/MANIFEST.MF ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/ChunkLoaderV1.java ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/util/ChunkReader.java ! core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/test/TestToolkit.java + core/tests/org.openjdk.jmc.flightrecorder.test/src/test/java/org/openjdk/jmc/flightrecorder/test/MetadataEventLocationUpdateTest.java ! core/tests/org.openjdk.jmc.flightrecorder.test/src/test/java/org/openjdk/jmc/flightrecorder/test/util/RecordingToolkit.java + core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/recordings/flush_incremental_metadata.jfr + core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/recordings/flush_metadata.jfr + core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/recordings/metadata_control.jfr + core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/recordings/metadata_new.jfr From aazores at redhat.com Wed Dec 19 13:02:05 2018 From: aazores at redhat.com (Andrew Azores) Date: Wed, 19 Dec 2018 08:02:05 -0500 Subject: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> <070301d49218$3c1e0de0$b45a29a0$@hirt.se> Message-ID: Hi Marcus/all, On 2018-12-13 1:00 p.m., Marcus Hirt wrote: > Hi Andrew, > > Looks good! Thanks for the contribution! > > /M Thanks for the review! Glad to have contributed. I will need someone to push this on my behalf. Are we waiting until the 7.1 branch point to push this? > > ?On 2018-12-13, 18:32, "jmc-dev on behalf of Andrew Azores" wrote: > > On 2018-12-12 3:30 p.m., Andrew Azores wrote: > > Hi Marcus, > > > > On 2018-12-12 7:43 a.m., Marcus Hirt wrote: > >> Hi Andrew, > >> > >> There are, sadly, no official guidelines for adding recordings. > >> > >> That said, try to: > >> > >> 1. Keep the recording small, e.g. make the recording as short as > >> possible, > >> use a template where some unrelated events are disabled (take care, > >> some events are more or less expected, e.g. Flight Recorder meta > >> events). > >> > >> 2. Look through the data to ensure it doesn't contain something you > >> don't want > >> to share. For example, it's all too easy to get a password or > >> password hash > >> in the environment variable or system property events. > >> > >> Kind regards, > >> Marcus > >> > > Thanks for the tips. I have attached another updated patch. This one now > > includes two flight recordings, exercising the "Full GCs occurred" paths > > for the rule for both G1 and CMS scenarios, as well as an updated test > > baseline for the expected result reports for these recordings. I > > disabled nearly all event types and ran the recording for as little time > > as I was easily able to get the reproducer applet I had prepared to > > produce full collections. If the recordings are still too large then I'm > > sure I can make my applet hungrier for memory and get the desired events > > to occur even sooner, which should cut down on the total number of > > events in the recording. > > > > This got stuck in the moderation queue due to the large size of the > patch, so with Mario's help I have uploaded the patch instead as a > webrev. Available here: > > http://cr.openjdk.java.net/~neugens/JMC-5596/webrev.01/ > > -- > Andrew Azores > Software Engineer, OpenJDK Team > Red Hat > > > > -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From marcus.hirt at oracle.com Wed Dec 19 13:29:13 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 19 Dec 2018 14:29:13 +0100 Subject: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> <070301d49218$3c1e0de0$b45a29a0$@hirt.se> Message-ID: <7159ADBA-B9D0-41CA-85BB-0F151A4614FC@oracle.com> Hi Andrew, Either I or Mario can help you push this. It's fine to push this into the mainline if done promptly. Kind regards, Marcus ?On 2018-12-19, 14:02, "Andrew Azores" wrote: Hi Marcus/all, On 2018-12-13 1:00 p.m., Marcus Hirt wrote: > Hi Andrew, > > Looks good! Thanks for the contribution! > > /M Thanks for the review! Glad to have contributed. I will need someone to push this on my behalf. Are we waiting until the 7.1 branch point to push this? > > ?On 2018-12-13, 18:32, "jmc-dev on behalf of Andrew Azores" wrote: > > On 2018-12-12 3:30 p.m., Andrew Azores wrote: > > Hi Marcus, > > > > On 2018-12-12 7:43 a.m., Marcus Hirt wrote: > >> Hi Andrew, > >> > >> There are, sadly, no official guidelines for adding recordings. > >> > >> That said, try to: > >> > >> 1. Keep the recording small, e.g. make the recording as short as > >> possible, > >> use a template where some unrelated events are disabled (take care, > >> some events are more or less expected, e.g. Flight Recorder meta > >> events). > >> > >> 2. Look through the data to ensure it doesn't contain something you > >> don't want > >> to share. For example, it's all too easy to get a password or > >> password hash > >> in the environment variable or system property events. > >> > >> Kind regards, > >> Marcus > >> > > Thanks for the tips. I have attached another updated patch. This one now > > includes two flight recordings, exercising the "Full GCs occurred" paths > > for the rule for both G1 and CMS scenarios, as well as an updated test > > baseline for the expected result reports for these recordings. I > > disabled nearly all event types and ran the recording for as little time > > as I was easily able to get the reproducer applet I had prepared to > > produce full collections. If the recordings are still too large then I'm > > sure I can make my applet hungrier for memory and get the desired events > > to occur even sooner, which should cut down on the total number of > > events in the recording. > > > > This got stuck in the moderation queue due to the large size of the > patch, so with Mario's help I have uploaded the patch instead as a > webrev. Available here: > > http://cr.openjdk.java.net/~neugens/JMC-5596/webrev.01/ > > -- > Andrew Azores > Software Engineer, OpenJDK Team > Red Hat > > > > -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From marcus.hirt at oracle.com Wed Dec 19 15:26:58 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 19 Dec 2018 16:26:58 +0100 Subject: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> <070301d49218$3c1e0de0$b45a29a0$@hirt.se> Message-ID: <453FB609-6C89-47C2-AF15-4376D2EF7162@oracle.com> Or Josh! :) /M ?On 2018-12-19, 14:29, "Marcus Hirt" wrote: Hi Andrew, Either I or Mario can help you push this. It's fine to push this into the mainline if done promptly. Kind regards, Marcus ?On 2018-12-19, 14:02, "Andrew Azores" wrote: Hi Marcus/all, On 2018-12-13 1:00 p.m., Marcus Hirt wrote: > Hi Andrew, > > Looks good! Thanks for the contribution! > > /M Thanks for the review! Glad to have contributed. I will need someone to push this on my behalf. Are we waiting until the 7.1 branch point to push this? > > ?On 2018-12-13, 18:32, "jmc-dev on behalf of Andrew Azores" wrote: > > On 2018-12-12 3:30 p.m., Andrew Azores wrote: > > Hi Marcus, > > > > On 2018-12-12 7:43 a.m., Marcus Hirt wrote: > >> Hi Andrew, > >> > >> There are, sadly, no official guidelines for adding recordings. > >> > >> That said, try to: > >> > >> 1. Keep the recording small, e.g. make the recording as short as > >> possible, > >> use a template where some unrelated events are disabled (take care, > >> some events are more or less expected, e.g. Flight Recorder meta > >> events). > >> > >> 2. Look through the data to ensure it doesn't contain something you > >> don't want > >> to share. For example, it's all too easy to get a password or > >> password hash > >> in the environment variable or system property events. > >> > >> Kind regards, > >> Marcus > >> > > Thanks for the tips. I have attached another updated patch. This one now > > includes two flight recordings, exercising the "Full GCs occurred" paths > > for the rule for both G1 and CMS scenarios, as well as an updated test > > baseline for the expected result reports for these recordings. I > > disabled nearly all event types and ran the recording for as little time > > as I was easily able to get the reproducer applet I had prepared to > > produce full collections. If the recordings are still too large then I'm > > sure I can make my applet hungrier for memory and get the desired events > > to occur even sooner, which should cut down on the total number of > > events in the recording. > > > > This got stuck in the moderation queue due to the large size of the > patch, so with Mario's help I have uploaded the patch instead as a > webrev. Available here: > > http://cr.openjdk.java.net/~neugens/JMC-5596/webrev.01/ > > -- > Andrew Azores > Software Engineer, OpenJDK Team > Red Hat > > > > -- Andrew Azores Software Engineer, OpenJDK Team Red Hat From marcus.hirt at oracle.com Wed Dec 19 18:30:55 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 19 Dec 2018 19:30:55 +0100 Subject: Review request for JMC-6281: Removing forgotten hirt.se license text Message-ID: <2F20EBA2-8472-477D-85BA-9820A403E9CF@oracle.com> Hi all, Please review this fix to remove some hirt.se license text that we missed to remove when open sourcing jmc. Jira:???https://bugs.openjdk.java.net/browse/JMC-6281 Webrev:?http://cr.openjdk.java.net/~hirt/JMC-6281/webrev.01/ Kind regards, Marcus From guru.hb at oracle.com Wed Dec 19 18:34:47 2018 From: guru.hb at oracle.com (Guru) Date: Thu, 20 Dec 2018 00:04:47 +0530 Subject: Review request for JMC-6281: Removing forgotten hirt.se license text In-Reply-To: <2F20EBA2-8472-477D-85BA-9820A403E9CF@oracle.com> References: <2F20EBA2-8472-477D-85BA-9820A403E9CF@oracle.com> Message-ID: <4E8ABE95-362E-495E-BCC2-3A8420F40A5E@oracle.com> +1 Looks good to me. > On 20-Dec-2018, at 12:00 AM, Marcus Hirt wrote: > > Hi all, > > Please review this fix to remove some hirt.se license text that > we missed to remove when open sourcing jmc. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6281 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6281/webrev.01/ > > Kind regards, > Marcus > > > From marcus.hirt at oracle.com Wed Dec 19 18:37:09 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Wed, 19 Dec 2018 18:37:09 +0000 Subject: hg: jmc/jmc: JMC-6281: Removing forgotten hirt.se license text Message-ID: <201812191837.wBJIb990000418@aojmv0008.oracle.com> Changeset: 246d9bb1a89a Author: hirt Date: 2018-12-19 19:36 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/246d9bb1a89a JMC-6281: Removing forgotten hirt.se license text Reviewed-by: ghb - application/org.openjdk.jmc.greychart/license.txt - application/org.openjdk.jmc.greychart/readme.txt From almacdon at redhat.com Wed Dec 19 20:20:38 2018 From: almacdon at redhat.com (Alex Macdonald) Date: Wed, 19 Dec 2018 15:20:38 -0500 Subject: Review request for JMC-6281: Removing forgotten hirt.se license text In-Reply-To: <4E8ABE95-362E-495E-BCC2-3A8420F40A5E@oracle.com> References: <2F20EBA2-8472-477D-85BA-9820A403E9CF@oracle.com> <4E8ABE95-362E-495E-BCC2-3A8420F40A5E@oracle.com> Message-ID: I believe this change requires accompanying edits to the build.properties [0] file to remove the license.txt and readme.txt from the bin.includes section. Trying to build JMC currently results in an error: build.properties: bin.includes value(s) [license.txt, readme.txt] do not match any files Cheers, Alex [0] http://hg.openjdk.java.net/jmc/jmc/file/246d9bb1a89a/application/org.openjdk.jmc.greychart/build.properties#l38 On Wed, Dec 19, 2018 at 1:37 PM Guru wrote: > +1 Looks good to me. > > On 20-Dec-2018, at 12:00 AM, Marcus Hirt wrote: > > > > Hi all, > > > > Please review this fix to remove some hirt.se license text that > > we missed to remove when open sourcing jmc. > > > > Jira: https://bugs.openjdk.java.net/browse/JMC-6281 > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6281/webrev.01/ > > > > Kind regards, > > Marcus > > > > > > > > From marcus.hirt at oracle.com Wed Dec 19 20:41:01 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Wed, 19 Dec 2018 21:41:01 +0100 Subject: Review request for JMC-6281: Removing forgotten hirt.se license text In-Reply-To: <6455FB62-564A-43FE-B6E0-08ACFDA0A1FF@redhat.com> References: <2F20EBA2-8472-477D-85BA-9820A403E9CF@oracle.com> <4E8ABE95-362E-495E-BCC2-3A8420F40A5E@oracle.com> <6455FB62-564A-43FE-B6E0-08ACFDA0A1FF@redhat.com> Message-ID: <50AA67F2-87B4-4AF1-BF10-480EE3245352@oracle.com> Thanks Alex! Will follow up immediately with a check-in. Setting you as reviewer. ;) Kind regards, Marcus From: Alex Macdonald Date: Wednesday, 19 December 2018 at 21:21 To: Guru Cc: Marcus Hirt , "jmc-dev at openjdk.java.net" Subject: Re: Review request for JMC-6281: Removing forgotten hirt.se license text I believe this change requires accompanying edits to the build.properties [0] file to remove the license.txt and readme.txt from the bin.includes section. Trying to build JMC currently results in an error: build.properties: bin.includes value(s) [license.txt, readme.txt] do not match any files Cheers, Alex [0] http://hg.openjdk.java.net/jmc/jmc/file/246d9bb1a89a/application/org.openjdk.jmc.greychart/build.properties#l38 On Wed, Dec 19, 2018 at 1:37 PM Guru wrote: +1 Looks good to me. > On 20-Dec-2018, at 12:00 AM, Marcus Hirt wrote: > > Hi all, > > Please review this fix to remove some hirt.se license text that > we missed to remove when open sourcing jmc. > > Jira: https://bugs.openjdk.java.net/browse/JMC-6281 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6281/webrev.01/ > > Kind regards, > Marcus > > > From marcus.hirt at oracle.com Wed Dec 19 20:49:14 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Wed, 19 Dec 2018 20:49:14 +0000 Subject: hg: jmc/jmc: JMC-6281: Updating build properties to not include removed files Message-ID: <201812192049.wBJKnEDx029288@aojmv0008.oracle.com> Changeset: 9ae4473cea37 Author: hirt Date: 2018-12-19 21:49 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/9ae4473cea37 JMC-6281: Updating build properties to not include removed files Reviewed-by: Alex Macdonald ! application/org.openjdk.jmc.greychart/build.properties From prem.balakrishnan at oracle.com Thu Dec 20 09:11:33 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 20 Dec 2018 01:11:33 -0800 (PST) Subject: Review Request: JMC-6278 : Need to (temporarily) back out JMC-6127 Message-ID: <287945c5-b792-4d87-9bef-fffcd892b668@default> Hi All, Please review the fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JMC-6278"JMC-6278 Webrev: http://cr.openjdk.java.net/~pkbalakr/jmc/6278/webrev.00/ Since we do not (yet) have third-party approval, we are reverting the fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JMC-6217"JMC-6217 : Update mail.api and its dependencies. See HYPERLINK "https://bugs.openjdk.java.net/browse/JMC-6283"JMC-6283 for reintroducing it once we do have approval. Regards, Prem From marcus.hirt at oracle.com Thu Dec 20 09:15:19 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 10:15:19 +0100 Subject: Review Request: JMC-6278 : Need to (temporarily) back out JMC-6127 In-Reply-To: References: Message-ID: <8386FE6A-3433-46ED-BEDD-84C88EF2E7B7@oracle.com> Looks good Prem! Go ahead! /M From: Prem Balakrishnan on behalf of Prem Balakrishnan Date: Thursday, 20 December 2018 at 10:11 To: , Marcus Hirt , Guru Hb Subject: Review Request: JMC-6278 : Need to (temporarily) back out JMC-6127 Hi All, Please review the fix for JMC-6278 Webrev: http://cr.openjdk.java.net/~pkbalakr/jmc/6278/webrev.00/ Since we do not (yet) have third-party approval, we are reverting the fix of JMC-6217 : Update mail.api and its dependencies. See JMC-6283 for reintroducing it once we do have approval. Regards, Prem From guru.hb at oracle.com Thu Dec 20 09:41:37 2018 From: guru.hb at oracle.com (guru.hb at oracle.com) Date: Thu, 20 Dec 2018 09:41:37 +0000 Subject: hg: jmc/jmc: JMC-6278: Need to (temporarily) back out JMC-6127 Message-ID: <201812200941.wBK9fb3w022342@aojmv0008.oracle.com> Changeset: c9aade0a48ae Author: ghb Date: 2018-12-20 15:11 +0530 URL: http://hg.openjdk.java.net/jmc/jmc/rev/c9aade0a48ae JMC-6278: Need to (temporarily) back out JMC-6127 Reviewed-by: hirt Contributed-by: pkbalakr ! application/org.openjdk.jmc.feature.core/feature.xml ! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target ! releng/third-party/pom.xml From marcus.hirt at oracle.com Thu Dec 20 14:55:59 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 15:55:59 +0100 Subject: Review request for JMC-5879: Fixing wrong Eclipse version reference in update site Message-ID: Hi all, Please review this tiny fix for a wrong Eclipse version reference in the eclipse update site. Jira: https://bugs.openjdk.java.net/browse/JMC-5879 Patch: diff -r 9ae4473cea37 application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html --- a/application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html Wed Dec 19 21:49:00 2018 +0100 +++ b/application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html Thu Dec 20 15:44:44 2018 +0100 @@ -43,7 +43,7 @@

Step-by-Step Instructions

- Before starting, make sure that you have downloaded and installed Eclipse 4.5 or later. + Before starting, make sure that you have downloaded and installed Eclipse 4.7 or later. Kind regards, Marcus From hdafgard at gmail.com Thu Dec 20 15:00:27 2018 From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=) Date: Thu, 20 Dec 2018 16:00:27 +0100 Subject: Review request for JMC-5879: Fixing wrong Eclipse version reference in update site In-Reply-To: References: Message-ID: Looks good! Cheers, Henrik Dafg?rd On Thu, 20 Dec 2018 at 15:58, Marcus Hirt wrote: > Hi all, > > Please review this tiny fix for a wrong Eclipse version reference in the > eclipse update site. > > Jira: https://bugs.openjdk.java.net/browse/JMC-5879 > Patch: > diff -r 9ae4473cea37 > application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html > --- > a/application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html > Wed Dec 19 21:49:00 2018 +0100 > +++ > b/application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html > Thu Dec 20 15:44:44 2018 +0100 > @@ -43,7 +43,7 @@ > >

Step-by-Step Instructions

> > - Before starting, make sure that you have downloaded and > installed Eclipse 4.5 or later. > + Before starting, make sure that you have downloaded and > installed Eclipse 4.7 or later. > > > > Kind regards, > Marcus > > > From marcus.hirt at oracle.com Thu Dec 20 15:10:56 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Thu, 20 Dec 2018 15:10:56 +0000 Subject: hg: jmc/jmc: JMC-5879: Fixing wrong Eclipse version reference in update site Message-ID: <201812201510.wBKFAuoE008831@aojmv0008.oracle.com> Changeset: cca54669c688 Author: hirt Date: 2018-12-20 16:10 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/cca54669c688 JMC-5879: Fixing wrong Eclipse version reference in update site Reviewed-by: hdafgard ! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html From jmatsuok at redhat.com Thu Dec 20 15:51:03 2018 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Thu, 20 Dec 2018 15:51:03 +0000 Subject: hg: jmc/jmc: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS Message-ID: <201812201551.wBKFp3cG024761@aojmv0008.oracle.com> Changeset: 6aa457ef49ac Author: jmatsuoka Date: 2018-12-20 10:50 -0500 URL: http://hg.openjdk.java.net/jmc/jmc/rev/6aa457ef49ac JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS Summary: Add a rule to detect full garbage collections for G1 and CMS Reviewed-by: hirt Contributed-by: Andrew Azores ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/CollectorType.java + core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/FullGcRule.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GarbageCollectionsInfo.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/Messages.java ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/META-INF/services/org.openjdk.jmc.flightrecorder.rules.IRule ! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties ! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkFilters.java + core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/baseline/Generated_JfrRuleBaseline.xml ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml + core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/jfr/full_gc_cms.jfr + core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/jfr/full_gc_g1.jfr ! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/jfr/index.txt From jmatsuok at redhat.com Thu Dec 20 15:52:47 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Thu, 20 Dec 2018 10:52:47 -0500 Subject: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS In-Reply-To: <453FB609-6C89-47C2-AF15-4376D2EF7162@oracle.com> References: <012b01d4914e$17c39fc0$474adf40$@hirt.se> <070301d49218$3c1e0de0$b45a29a0$@hirt.se> <453FB609-6C89-47C2-AF15-4376D2EF7162@oracle.com> Message-ID: Hi Andrew, Marcus, pushed: http://hg.openjdk.java.net/jmc/jmc/rev/6aa457ef49ac Great work! Cheers, - Josh On Wed, Dec 19, 2018 at 10:28 AM Marcus Hirt wrote: > Or Josh! :) > > /M > > ?On 2018-12-19, 14:29, "Marcus Hirt" wrote: > > Hi Andrew, > > Either I or Mario can help you push this. It's fine > to push this into the mainline if done promptly. > > Kind regards, > Marcus > > ?On 2018-12-19, 14:02, "Andrew Azores" wrote: > > Hi Marcus/all, > > On 2018-12-13 1:00 p.m., Marcus Hirt wrote: > > Hi Andrew, > > > > Looks good! Thanks for the contribution! > > > > /M > > Thanks for the review! Glad to have contributed. > > I will need someone to push this on my behalf. Are we waiting > until the > 7.1 branch point to push this? > > > > > ?On 2018-12-13, 18:32, "jmc-dev on behalf of Andrew Azores" < > jmc-dev-bounces at openjdk.java.net on behalf of aazores at redhat.com> wrote: > > > > On 2018-12-12 3:30 p.m., Andrew Azores wrote: > > > Hi Marcus, > > > > > > On 2018-12-12 7:43 a.m., Marcus Hirt wrote: > > >> Hi Andrew, > > >> > > >> There are, sadly, no official guidelines for adding > recordings. > > >> > > >> That said, try to: > > >> > > >> 1. Keep the recording small, e.g. make the recording as > short as > > >> possible, > > >> use a template where some unrelated events are > disabled (take care, > > >> some events are more or less expected, e.g. Flight > Recorder meta > > >> events). > > >> > > >> 2. Look through the data to ensure it doesn't contain > something you > > >> don't want > > >> to share. For example, it's all too easy to get a > password or > > >> password hash > > >> in the environment variable or system property > events. > > >> > > >> Kind regards, > > >> Marcus > > >> > > > Thanks for the tips. I have attached another updated > patch. This one now > > > includes two flight recordings, exercising the "Full GCs > occurred" paths > > > for the rule for both G1 and CMS scenarios, as well as an > updated test > > > baseline for the expected result reports for these > recordings. I > > > disabled nearly all event types and ran the recording for > as little time > > > as I was easily able to get the reproducer applet I had > prepared to > > > produce full collections. If the recordings are still too > large then I'm > > > sure I can make my applet hungrier for memory and get the > desired events > > > to occur even sooner, which should cut down on the total > number of > > > events in the recording. > > > > > > > This got stuck in the moderation queue due to the large > size of the > > patch, so with Mario's help I have uploaded the patch > instead as a > > webrev. Available here: > > > > http://cr.openjdk.java.net/~neugens/JMC-5596/webrev.01/ > > > > -- > > Andrew Azores > > Software Engineer, OpenJDK Team > > Red Hat > > > > > > > > > > > -- > Andrew Azores > Software Engineer, OpenJDK Team > Red Hat > > > > > > From kdobson at redhat.com Thu Dec 20 16:31:43 2018 From: kdobson at redhat.com (Ken Dobson) Date: Thu, 20 Dec 2018 11:31:43 -0500 Subject: Small text issue in Recording Wizard Message-ID: Hi all, When you open the Recording Wizard you should see this written at the bottom of the first page: *Note: *Time fixed recordings will be automatically dumped and opened. This was bothering me so I had a look and it seems the eclipse setText function replaces all "&" with "&" so you're unable to use character references in the string you pass to it, only HTML tags. This tiny patch just removes the   as it currently does nothing and looks quite ugly. Thanks, Ken From marcus.hirt at oracle.com Thu Dec 20 16:35:23 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 17:35:23 +0100 Subject: Small text issue in Recording Wizard In-Reply-To: <82FFBCAD-9269-4032-9AE2-552B8239D003@redhat.com> References: <82FFBCAD-9269-4032-9AE2-552B8239D003@redhat.com> Message-ID: <02B1F3EC-1313-4044-BF1C-08FB33DDDD57@oracle.com> No patch attached, but agreed, please go ahead. Open a bug so that the fix can be verified. Sounds risk free, and redface. Kind regards, Marcus ?On 2018-12-20, 17:32, "jmc-dev on behalf of Ken Dobson" wrote: Hi all, When you open the Recording Wizard you should see this written at the bottom of the first page: *Note: *Time fixed recordings will be automatically dumped and opened. This was bothering me so I had a look and it seems the eclipse setText function replaces all "&" with "&" so you're unable to use character references in the string you pass to it, only HTML tags. This tiny patch just removes the   as it currently does nothing and looks quite ugly. Thanks, Ken From kdobson at redhat.com Thu Dec 20 16:37:11 2018 From: kdobson at redhat.com (Ken Dobson) Date: Thu, 20 Dec 2018 11:37:11 -0500 Subject: Small text issue in Recording Wizard In-Reply-To: References: Message-ID: Here is the patch in text form because I believe it was stripped. diff -r abb4b7f54009 application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties --- a/application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties Thu Dec 06 19:12:44 2018 +0100 +++ b/application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties Wed Dec 19 16:41:16 2018 -0500 @@ -184,8 +184,8 @@ RECORDING_WIZARD_PAGE_RECORDING_NAME_INVALID_CHARS=Name can't contain any of these characters: {0} RECORDING_WIZARD_PAGE_NO_TEMPLATE_SELECTED_ERROR_MSG=You need to select a configuration of events to include in the recording. RECORDING_WIZARD_PAGE_NO_TEMPLATES_IN_MANAGER_ERROR_MSG=You need to use the Template Manager to create or import a configuration of events to include in the recording. -RECORDING_WIZARD_PAGE_DURATION_NOTE=


Note: Time fixed recordings will be automatically dumped and opened.

-RECORDING_WIZARD_PAGE_CONTINUOUS_NOTE=


Note: Continuous recordings will need to be dumped to access the data. Right-click on the recording in the JVM Browser to open the Dump Recording dialog.

+RECORDING_WIZARD_PAGE_DURATION_NOTE=


Note: Time fixed recordings will be automatically dumped and opened.

+RECORDING_WIZARD_PAGE_CONTINUOUS_NOTE=


Note: Continuous recordings will need to be dumped to access the data. Right-click on the recording in the JVM Browser to open the Dump Recording dialog.

START_FLIGHT_RECORDING_JOB_MISSING_RECORDING=Unexpectedly lost connection to flight recording {0}, possibly closed by another client. FLIGHT_RECORDING_OPTIONS_PROBLEM_TITLE=Problems with the flight recording options On Thu, Dec 20, 2018 at 11:31 AM Ken Dobson wrote: > Hi all, > > When you open the Recording Wizard you should see this written at the > bottom of the first page: > > *Note: *Time fixed recordings will be automatically dumped and > opened. > > This was bothering me so I had a look and it seems the eclipse setText > function replaces all "&" with "&" so you're unable to use character > references in the string you pass to it, only HTML tags. This tiny patch > just removes the   as it currently does nothing and looks quite ugly. > > Thanks, > > Ken > From jmatsuok at redhat.com Thu Dec 20 16:40:53 2018 From: jmatsuok at redhat.com (Joshua Matsuoka) Date: Thu, 20 Dec 2018 11:40:53 -0500 Subject: Small text issue in Recording Wizard In-Reply-To: References: Message-ID: Hi, I'll open a bug and push this for you. Looks good. Cheers, - Josh On Thu, Dec 20, 2018 at 11:38 AM Ken Dobson wrote: > Here is the patch in text form because I believe it was stripped. > > diff -r abb4b7f54009 > > application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties > --- > > a/application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties > Thu Dec 06 19:12:44 2018 +0100 > +++ > > b/application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties > Wed Dec 19 16:41:16 2018 -0500 > @@ -184,8 +184,8 @@ > RECORDING_WIZARD_PAGE_RECORDING_NAME_INVALID_CHARS=Name can't contain any > of these characters: {0} > RECORDING_WIZARD_PAGE_NO_TEMPLATE_SELECTED_ERROR_MSG=You need to select a > configuration of events to include in the recording. > RECORDING_WIZARD_PAGE_NO_TEMPLATES_IN_MANAGER_ERROR_MSG=You need to use > the Template Manager to create or import a configuration of events to > include in the recording. > -RECORDING_WIZARD_PAGE_DURATION_NOTE=


Note: Time > fixed recordings will be automatically dumped and opened.

> > -RECORDING_WIZARD_PAGE_CONTINUOUS_NOTE=


Note: Continuous > recordings will need to be dumped to access the data. Right-click on the > recording in the JVM Browser to open the Dump Recording dialog.

> +RECORDING_WIZARD_PAGE_DURATION_NOTE=


Note: Time fixed > recordings will be automatically dumped and opened.

> +RECORDING_WIZARD_PAGE_CONTINUOUS_NOTE=


Note: > Continuous recordings will need to be dumped to access the data. > Right-click on the recording in the JVM Browser to open the Dump Recording > dialog.

> > START_FLIGHT_RECORDING_JOB_MISSING_RECORDING=Unexpectedly lost connection > to flight recording {0}, possibly closed by another client. > FLIGHT_RECORDING_OPTIONS_PROBLEM_TITLE=Problems with the flight recording > options > > > On Thu, Dec 20, 2018 at 11:31 AM Ken Dobson wrote: > > > Hi all, > > > > When you open the Recording Wizard you should see this written at the > > bottom of the first page: > > > > *Note: *Time fixed recordings will be automatically dumped and > > opened. > > > > This was bothering me so I had a look and it seems the eclipse setText > > function replaces all "&" with "&" so you're unable to use character > > references in the string you pass to it, only HTML tags. This tiny patch > > just removes the   as it currently does nothing and looks quite > ugly. > > > > Thanks, > > > > Ken > > > From neugens at redhat.com Thu Dec 20 16:46:13 2018 From: neugens at redhat.com (Mario Torre) Date: Thu, 20 Dec 2018 17:46:13 +0100 Subject: Java Mission Control Author request for: Ken Dobson Message-ID: I would like to propose Ken Dobson as author for Java Mission Control. Ken has been active on the JMC project helping out with various fixes, triaging some of the bugs in the issue tracker and participating in the general discussions about the project. Here is a list of Ken's contributions so far: Thread Activity Context Menu Leaking https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6241 Improving the output of the Duplicate Flags Rule https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5698 Important Column not shown by default in Diagnostic Commands https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4721 HighGCRule should report extra needed event types https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5703 Allowing multiple HPROF dumps rather than throwing an error if triggered multiple times, (duplicate of JMC-6100) https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 Fixed ugly values on the Y-axis when there are no events https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5359 Can't resolve event type names without Recording Settings event https://bugs.openjdk.java.net/projects/JMC/issues/JMC-5663 Fixed logging to file for the standalone eclipse https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6191 Plus the following under review Updating Documentation: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6260 http://mail.openjdk.java.net/pipermail/jmc-dev/2018-December/000605.html Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From marcus.hirt at oracle.com Thu Dec 20 16:46:17 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 17:46:17 +0100 Subject: Small text issue in Recording Wizard In-Reply-To: <9C27345E-C596-4898-AC4A-01BCCFC5F780@redhat.com> References: <9C27345E-C596-4898-AC4A-01BCCFC5F780@redhat.com> Message-ID: You're good to go! /M ?On 2018-12-20, 17:41, "jmc-dev on behalf of Joshua Matsuoka" wrote: Hi, I'll open a bug and push this for you. Looks good. Cheers, - Josh On Thu, Dec 20, 2018 at 11:38 AM Ken Dobson wrote: > Here is the patch in text form because I believe it was stripped. > > diff -r abb4b7f54009 > > application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties > --- > > a/application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties > Thu Dec 06 19:12:44 2018 +0100 > +++ > > b/application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties > Wed Dec 19 16:41:16 2018 -0500 > @@ -184,8 +184,8 @@ > RECORDING_WIZARD_PAGE_RECORDING_NAME_INVALID_CHARS=Name can't contain any > of these characters: {0} > RECORDING_WIZARD_PAGE_NO_TEMPLATE_SELECTED_ERROR_MSG=You need to select a > configuration of events to include in the recording. > RECORDING_WIZARD_PAGE_NO_TEMPLATES_IN_MANAGER_ERROR_MSG=You need to use > the Template Manager to create or import a configuration of events to > include in the recording. > -RECORDING_WIZARD_PAGE_DURATION_NOTE=


Note: Time > fixed recordings will be automatically dumped and opened.

> > -RECORDING_WIZARD_PAGE_CONTINUOUS_NOTE=


Note: Continuous > recordings will need to be dumped to access the data. Right-click on the > recording in the JVM Browser to open the Dump Recording dialog.

> +RECORDING_WIZARD_PAGE_DURATION_NOTE=


Note: Time fixed > recordings will be automatically dumped and opened.

> +RECORDING_WIZARD_PAGE_CONTINUOUS_NOTE=


Note: > Continuous recordings will need to be dumped to access the data. > Right-click on the recording in the JVM Browser to open the Dump Recording > dialog.

> > START_FLIGHT_RECORDING_JOB_MISSING_RECORDING=Unexpectedly lost connection > to flight recording {0}, possibly closed by another client. > FLIGHT_RECORDING_OPTIONS_PROBLEM_TITLE=Problems with the flight recording > options > > > On Thu, Dec 20, 2018 at 11:31 AM Ken Dobson wrote: > > > Hi all, > > > > When you open the Recording Wizard you should see this written at the > > bottom of the first page: > > > > *Note: *Time fixed recordings will be automatically dumped and > > opened. > > > > This was bothering me so I had a look and it seems the eclipse setText > > function replaces all "&" with "&" so you're unable to use character > > references in the string you pass to it, only HTML tags. This tiny patch > > just removes the   as it currently does nothing and looks quite > ugly. > > > > Thanks, > > > > Ken > > > From jmatsuok at redhat.com Thu Dec 20 17:18:09 2018 From: jmatsuok at redhat.com (jmatsuok at redhat.com) Date: Thu, 20 Dec 2018 17:18:09 +0000 Subject: hg: jmc/jmc: JMC-6285: Broken text on Flight Recording Wizard Message-ID: <201812201718.wBKHI9EI002278@aojmv0008.oracle.com> Changeset: 46d53f2351ac Author: jmatsuoka Date: 2018-12-20 12:17 -0500 URL: http://hg.openjdk.java.net/jmc/jmc/rev/46d53f2351ac JMC-6285: Broken text on Flight Recording Wizard Summary: Fixes a character reference for additional spacing to work with newer versions of eclipse. Reviewed-by: hirt, jmatsuoka Contributed-by: Ken Dobson ! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/resources/org/openjdk/jmc/flightrecorder/controlpanel/ui/messages/internal/messages.properties From guru.hb at oracle.com Thu Dec 20 18:13:41 2018 From: guru.hb at oracle.com (Guru) Date: Thu, 20 Dec 2018 23:43:41 +0530 Subject: Review request : JMC-6286 : Update L10N translation for JMC 7.0.0 Message-ID: Hi, Please review the fix for https://bugs.openjdk.java.net/browse/JMC-6286 Webrev : http://cr.openjdk.java.net/~ghb/JMC-6286/webrev.0/ Thanks, Guru From marcus.hirt at oracle.com Thu Dec 20 20:22:18 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 21:22:18 +0100 Subject: Happy Holidays (also, JMC 7 branched)! Message-ID: <47A9EC6C-F636-438F-9B72-4E2F3355AB86@oracle.com> Hi all, First of all I would like to wish you all happy holidays and a happy new year! My vacation starts tomorrow, but before then I thought I?d try to sum up a few thoughts around the last couple of months since JMC was open sourced. First of all I would like to thank everyone who has taken an active interest in JMC. There are now, at the time of writing, 14 contributors listed in the JMC project census[1], and there are more contributors in the pipe to be added. Most are backed by companies, like Oracle and Red Hat, but there are also people that spend their spare time contributing. Next I think we all deserve a pat on the back for almost being done with JMC 7. It is a release with many firsts: * First JMC release to be based on an open sourced Mission Control [2] * First JMC release to ship with its own embedded runtime[3] * First JMC release to use common open source build tools, like Maven/Tycho * First JMC release to ship the core bundles to Maven Central[4] * First JMC with contributions from outside of Oracle And probably a whole host of other firsts I cannot think of right now. And, as any release with many firsts, it has been challenging. We still have some work ahead of us before we can ship JMC 7, but I am pretty confident we can (barring any process hick-ups) get the release out on time. Finally I'd like to mention that JMC 7 have now been branched[5]. The mainline repo[6] is now the JMC 7.1 release. Happy Holidays and a Happy New Year! Kind regards, Marcus [1] http://openjdk.java.net/census#jmc [2] http://hirt.se/blog/?p=944 [3] https://blogs.oracle.com/java-platform-group/java-mission-control-now-serving-openjdk-binaries-too [4] https://oss.sonatype.org/content/repositories/snapshots/org/openjdk/jmc/ [5] http://hg.openjdk.java.net/jmc/jmc7/ [6] http://hg.openjdk.java.net/jmc/jmc/ From marcus.hirt at oracle.com Thu Dec 20 20:30:43 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 21:30:43 +0100 Subject: Review request : JMC-6286 : Update L10N translation for JMC 7.0.0 In-Reply-To: <1374EAF5-E2CD-4058-972B-2E13F271B2A3@oracle.com> References: <1374EAF5-E2CD-4058-972B-2E13F271B2A3@oracle.com> Message-ID: Some translations seem to be missing. I pinged Guru, and he's looking into this. /M ?On 2018-12-20, 19:14, "jmc-dev on behalf of Guru" wrote: Hi, Please review the fix for https://bugs.openjdk.java.net/browse/JMC-6286 Webrev : http://cr.openjdk.java.net/~ghb/JMC-6286/webrev.0/ Thanks, Guru From marcus.hirt at oracle.com Thu Dec 20 20:38:07 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 21:38:07 +0100 Subject: Please do not commit anything directly into the jmc7 branch! Message-ID: <37C4DF59-9B21-4903-9C6D-12248676272D@oracle.com> Please do not commit anything directly into the jmc7 repo. If there is anything we feel need to go into JMC 7.0.0, we will cherry-pick it from the mainline (jmc repo). Kind regards, Marcus From marcus.hirt at oracle.com Thu Dec 20 21:03:25 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 22:03:25 +0100 Subject: Review request for JMC-5888: Final splash screen for JMC 7.0.0 Message-ID: <70897C05-C0E7-489E-AB90-9A1E7322B51C@oracle.com> Hi all, Please review the final splash screen for JMC 7.0.0. Jira: https://bugs.openjdk.java.net/browse/JMC-5888 Webrev: http://cr.openjdk.java.net/~hirt/JMC-5888/webrev.01/ (Note that this one will be checked directly into the jmc7 repo.) Kind regards, Marcus From guru.hb at oracle.com Thu Dec 20 21:10:23 2018 From: guru.hb at oracle.com (Guru) Date: Fri, 21 Dec 2018 02:40:23 +0530 Subject: Review request for JMC-5888: Final splash screen for JMC 7.0.0 In-Reply-To: <70897C05-C0E7-489E-AB90-9A1E7322B51C@oracle.com> References: <70897C05-C0E7-489E-AB90-9A1E7322B51C@oracle.com> Message-ID: <75CEB866-F1AB-4A90-AC6B-BDE41A05962F@oracle.com> +1, Downloaded the raw file and its looks good to me. > On 21-Dec-2018, at 2:33 AM, Marcus Hirt wrote: > > Hi all, > > Please review the final splash screen for JMC 7.0.0. > > Jira: https://bugs.openjdk.java.net/browse/JMC-5888 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-5888/webrev.01/ > > (Note that this one will be checked directly into the jmc7 repo.) > > Kind regards, > Marcus > > From marcus.hirt at oracle.com Thu Dec 20 21:14:07 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 22:14:07 +0100 Subject: Review request for JMC-6250: Updated splash screen for the jmc repo Message-ID: <394C1CD5-8358-4126-9E0D-ECF3527F1F8A@oracle.com> Hi all, Please review the updated splash screen for the jmc repo (mainline). Jira: https://bugs.openjdk.java.net/browse/JMC-6250 Webrev: http://cr.openjdk.java.net/~hirt/JMC-6250/webrev.01/ Kind regards, Marcus From marcus.hirt at oracle.com Thu Dec 20 21:16:35 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Thu, 20 Dec 2018 21:16:35 +0000 Subject: hg: jmc/jmc7: JMC-5888: Final splash screen for JMC 7.0.0 Message-ID: <201812202116.wBKLGZMc018225@aojmv0008.oracle.com> Changeset: f18c3c60c9cc Author: hirt Date: 2018-12-20 22:15 +0100 URL: http://hg.openjdk.java.net/jmc/jmc7/rev/f18c3c60c9cc JMC-5888: Final splash screen for JMC 7.0.0 Reviewed-by: ghb ! application/org.openjdk.jmc.rcp.application/splash.bmp From guru.hb at oracle.com Thu Dec 20 21:18:56 2018 From: guru.hb at oracle.com (Guru) Date: Fri, 21 Dec 2018 02:48:56 +0530 Subject: Review request for JMC-6250: Updated splash screen for the jmc repo In-Reply-To: <394C1CD5-8358-4126-9E0D-ECF3527F1F8A@oracle.com> References: <394C1CD5-8358-4126-9E0D-ECF3527F1F8A@oracle.com> Message-ID: <89C80829-5CD8-4A95-AC70-7F42EBEC61F5@oracle.com> +1, Downloaded the raw file which has JMC 7.1 with ?Early access?. > On 21-Dec-2018, at 2:44 AM, Marcus Hirt wrote: > > Hi all, > > Please review the updated splash screen for the jmc repo (mainline). > > Jira: https://bugs.openjdk.java.net/browse/JMC-6250 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6250/webrev.01/ > > Kind regards, > Marcus > > From marcus.hirt at oracle.com Thu Dec 20 21:20:39 2018 From: marcus.hirt at oracle.com (marcus.hirt at oracle.com) Date: Thu, 20 Dec 2018 21:20:39 +0000 Subject: hg: jmc/jmc: JMC-6250: Updated splash for JMC 7.1 EA Message-ID: <201812202120.wBKLKdpq019501@aojmv0008.oracle.com> Changeset: 8504b6bb4899 Author: hirt Date: 2018-12-20 22:20 +0100 URL: http://hg.openjdk.java.net/jmc/jmc/rev/8504b6bb4899 JMC-6250: Updated splash for JMC 7.1 EA Reviewed-by: ghb ! application/org.openjdk.jmc.rcp.application/splash.bmp From marcus.hirt at oracle.com Thu Dec 20 21:26:31 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 22:26:31 +0100 Subject: Eclipse 2018-12 out! Message-ID: <4BC325A7-3ADD-40D5-81E7-F8738ED450DF@oracle.com> Hi all, Just a reminder that the latest release of Eclipse is out. With the latest release, there is no longer a need for the JDK 11 plug-in to get the OpenJDK 11 dev launchers to work. Kind regards, Marcus From neugens at redhat.com Thu Dec 20 21:31:58 2018 From: neugens at redhat.com (Mario Torre) Date: Thu, 20 Dec 2018 21:31:58 +0000 Subject: Happy Holidays (also, JMC 7 branched)! In-Reply-To: <47A9EC6C-F636-438F-9B72-4E2F3355AB86@oracle.com> References: <47A9EC6C-F636-438F-9B72-4E2F3355AB86@oracle.com> Message-ID: Awesome Marcus, Thanks for leading the project so well, it has been a pleasure those months, so cheers to the many more to come! Have a fantastic holiday and happy new year! Cheers, Mario ? Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 ________________________________ From: jmc-dev on behalf of Marcus Hirt Sent: Thursday, December 20, 2018 21:23 To: jmc-dev at openjdk.java.net Subject: Happy Holidays (also, JMC 7 branched)! Hi all, First of all I would like to wish you all happy holidays and a happy new year! My vacation starts tomorrow, but before then I thought I?d try to sum up a few thoughts around the last couple of months since JMC was open sourced. First of all I would like to thank everyone who has taken an active interest in JMC. There are now, at the time of writing, 14 contributors listed in the JMC project census[1], and there are more contributors in the pipe to be added. Most are backed by companies, like Oracle and Red Hat, but there are also people that spend their spare time contributing. Next I think we all deserve a pat on the back for almost being done with JMC 7. It is a release with many firsts: * First JMC release to be based on an open sourced Mission Control [2] * First JMC release to ship with its own embedded runtime[3] * First JMC release to use common open source build tools, like Maven/Tycho * First JMC release to ship the core bundles to Maven Central[4] * First JMC with contributions from outside of Oracle And probably a whole host of other firsts I cannot think of right now. And, as any release with many firsts, it has been challenging. We still have some work ahead of us before we can ship JMC 7, but I am pretty confident we can (barring any process hick-ups) get the release out on time. Finally I'd like to mention that JMC 7 have now been branched[5]. The mainline repo[6] is now the JMC 7.1 release. Happy Holidays and a Happy New Year! Kind regards, Marcus [1] http://openjdk.java.net/census#jmc [2] http://hirt.se/blog/?p=944 [3] https://blogs.oracle.com/java-platform-group/java-mission-control-now-serving-openjdk-binaries-too [4] https://oss.sonatype.org/content/repositories/snapshots/org/openjdk/jmc/ [5] http://hg.openjdk.java.net/jmc/jmc7/ [6] http://hg.openjdk.java.net/jmc/jmc/ From marcus.hirt at oracle.com Thu Dec 20 22:39:27 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 23:39:27 +0100 Subject: Review request for JMC-5888: Final splash screen for JMC 7.0.0 In-Reply-To: References: <70897C05-C0E7-489E-AB90-9A1E7322B51C@oracle.com> Message-ID: Guru, In (the rather likely) case the GA is built next year - here is one with 2019 as copyright year: http://cr.openjdk.java.net/~hirt/JMC-5888/webrev.02/ Kind regards, Marcus ?On 2018-12-20, 22:10, "Guru" wrote: +1, Downloaded the raw file and its looks good to me. > On 21-Dec-2018, at 2:33 AM, Marcus Hirt wrote: > > Hi all, > > Please review the final splash screen for JMC 7.0.0. > > Jira: https://bugs.openjdk.java.net/browse/JMC-5888 > Webrev: http://cr.openjdk.java.net/~hirt/JMC-5888/webrev.01/ > > (Note that this one will be checked directly into the jmc7 repo.) > > Kind regards, > Marcus > > From marcus.hirt at oracle.com Thu Dec 20 22:49:28 2018 From: marcus.hirt at oracle.com (Marcus Hirt) Date: Thu, 20 Dec 2018 23:49:28 +0100 Subject: Happy Holidays (also, JMC 7 branched)! In-Reply-To: <1F972C6B-A3F9-475E-A3F7-C4BD8E4A643A@redhat.com> References: <47A9EC6C-F636-438F-9B72-4E2F3355AB86@oracle.com> <1F972C6B-A3F9-475E-A3F7-C4BD8E4A643A@redhat.com> Message-ID: <75E1512B-1773-4D1C-83BC-91397E69FD92@oracle.com> Thanks Mario! :) (Also, note to self, never do cut and paste changes in e-mails, especially late at night.) /M From: Mario Torre Date: Thursday, 20 December 2018 at 22:32 To: Marcus Hirt , "jmc-dev at openjdk.java.net" Subject: Re: Happy Holidays (also, JMC 7 branched)! Awesome Marcus, Thanks for leading the project so well, it has been a pleasure those months, so cheers to the many more to come! Have a fantastic holiday and happy new year! Cheers, Mario ? Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From: jmc-dev on behalf of Marcus Hirt Sent: Thursday, December 20, 2018 21:23 To: jmc-dev at openjdk.java.net Subject: Happy Holidays (also, JMC 7 branched)! Hi all, First of all I would like to wish you all happy holidays and a happy new year! My vacation starts tomorrow, but before then I thought I?d try to sum up a few thoughts around the last couple of months since JMC was open sourced. First of all I would like to thank everyone who has taken an active interest in JMC. There are now, at the time of writing, 14 contributors listed in the JMC project census[1], and there are more contributors in the pipe to be added. Most are backed by companies, like Oracle and Red Hat, but there are also people that spend their spare time contributing. Next I think we all deserve a pat on the back for almost being done with JMC 7. It is a release with many firsts: * First JMC release to be based on an open sourced Mission Control [2] * First JMC release to ship with its own embedded runtime[3] * First JMC release to use common open source build tools, like Maven/Tycho * First JMC release to ship the core bundles to Maven Central[4] * First JMC with contributions from outside of Oracle And probably a whole host of other firsts I cannot think of right now. And, as any release with many firsts, it has been challenging. We still have some work ahead of us before we can ship JMC 7, but I am pretty confident we can (barring any process hick-ups) get the release out on time. Finally I'd like to mention that JMC 7 have now been branched[5]. The mainline repo[6] is now the JMC 7.1 release. Happy Holidays and a Happy New Year! Kind regards, Marcus [1] http://openjdk.java.net/census#jmc [2] http://hirt.se/blog/?p=944 [3] https://blogs.oracle.com/java-platform-group/java-mission-control-now-serving-openjdk-binaries-too [4] https://oss.sonatype.org/content/repositories/snapshots/org/openjdk/jmc/ [5] http://hg.openjdk.java.net/jmc/jmc7/ [6] http://hg.openjdk.java.net/jmc/jmc/ From miro.wengner at gmail.com Fri Dec 21 08:41:53 2018 From: miro.wengner at gmail.com (Miro Wengner) Date: Fri, 21 Dec 2018 09:41:53 +0100 Subject: Happy Holidays (also, JMC 7 branched)! In-Reply-To: References: <47A9EC6C-F636-438F-9B72-4E2F3355AB86@oracle.com> Message-ID: <49985B55-5F00-4192-8B72-C83D8C52A30F@gmail.com> Hi Marcus, it amazing news and like Mario said Thank you for leading this project so well! It is an great experience and big pleasure to be part of amazing project. I wish you all a fantastic holiday and Happy new year ! Cheers, Miro > On Dec 20, 2018, at 10:31 PM, Mario Torre wrote: > > Awesome Marcus, > > Thanks for leading the project so well, it has been a pleasure those months, so cheers to the many more to come! > > Have a fantastic holiday and happy new year! > > Cheers, > Mario > > ? > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > ________________________________ > From: jmc-dev on behalf of Marcus Hirt > Sent: Thursday, December 20, 2018 21:23 > To: jmc-dev at openjdk.java.net > Subject: Happy Holidays (also, JMC 7 branched)! > > Hi all, > > First of all I would like to wish you all happy holidays and a happy new year! > My vacation starts tomorrow, but before then I thought I?d try to sum up a few > thoughts around the last couple of months since JMC was open sourced. > > First of all I would like to thank everyone who has taken an active interest > in JMC. There are now, at the time of writing, 14 contributors listed in the > JMC project census[1], and there are more contributors in the pipe to be added. > Most are backed by companies, like Oracle and Red Hat, but there are also > people that spend their spare time contributing. > > Next I think we all deserve a pat on the back for almost being done with JMC 7. > It is a release with many firsts: > > * First JMC release to be based on an open sourced Mission Control [2] > * First JMC release to ship with its own embedded runtime[3] > * First JMC release to use common open source build tools, like Maven/Tycho > * First JMC release to ship the core bundles to Maven Central[4] > * First JMC with contributions from outside of Oracle > > And probably a whole host of other firsts I cannot think of right now. And, as > any release with many firsts, it has been challenging. We still have some work > ahead of us before we can ship JMC 7, but I am pretty confident we can (barring > any process hick-ups) get the release out on time. > > Finally I'd like to mention that JMC 7 have now been branched[5]. The mainline > repo[6] is now the JMC 7.1 release. > > Happy Holidays and a Happy New Year! > > Kind regards, > Marcus > > > [1] http://openjdk.java.net/census#jmc > [2] http://hirt.se/blog/?p=944 > [3] https://blogs.oracle.com/java-platform-group/java-mission-control-now-serving-openjdk-binaries-too > [4] https://oss.sonatype.org/content/repositories/snapshots/org/openjdk/jmc/ > [5] http://hg.openjdk.java.net/jmc/jmc7/ > [6] http://hg.openjdk.java.net/jmc/jmc/ > >