From hirt at openjdk.java.net Fri Jan 1 15:55:04 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 1 Jan 2021 15:55:04 GMT Subject: RFR: 7078: Update the p2-maven-plugin to 1.5.0 Message-ID: Also cleaning up a bit. ------------- Commit messages: - 7078: Update the p2-maven-plugin to 1.5.0 Changes: https://git.openjdk.java.net/jmc/pull/188/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=188&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7078 Stats: 23 lines in 1 file changed: 11 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jmc/pull/188.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/188/head:pull/188 PR: https://git.openjdk.java.net/jmc/pull/188 From github.com+28612+gunnarmorling at openjdk.java.net Fri Jan 1 17:17:52 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Fri, 1 Jan 2021 17:17:52 GMT Subject: RFR: 7078: Update the p2-maven-plugin to 1.5.0 In-Reply-To: References: Message-ID: On Fri, 1 Jan 2021 15:51:48 GMT, Marcus Hirt wrote: > Also cleaning up a bit. LGTM. ------------- Marked as reviewed by gunnarmorling at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jmc/pull/188 From github.com+28612+gunnarmorling at openjdk.java.net Mon Jan 4 16:40:03 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Mon, 4 Jan 2021 16:40:03 GMT Subject: RFR: 7033: Allow overriding the id (name) of the event type [v2] In-Reply-To: References: Message-ID: > @thegreystone et al., this PR proposes two changes to the names of generated event types and their fields: > > * An explicit event type name is derived from the name given in the configuration, instead of using the class name; this is nicer to work with e.g. when enabling/disabling event types for recordings > * the "field" prefix is removed from event type field names; when examining e.g. `RecordedEvent` instances, names are nicer to look at that way IMO > > Could you log an issue for this change if you agree it's desirable? Thanks! I ran into these issues while using JMC Agent for [tracking SQL statements](https://twitter.com/gunnarmorling/status/1333152245463064579); note the odd "fieldSQLQuery" name marked on the left; the event type name is already adjusted in this screenshot as per this PR here. Gunnar Morling has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 7033: Nicer names for event types and fields ------------- Changes: https://git.openjdk.java.net/jmc/pull/170/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=170&range=01 Stats: 25 lines in 2 files changed: 13 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jmc/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/170/head:pull/170 PR: https://git.openjdk.java.net/jmc/pull/170 From github.com+28612+gunnarmorling at openjdk.java.net Mon Jan 4 16:40:03 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Mon, 4 Jan 2021 16:40:03 GMT Subject: RFR: 7033: Allow overriding the id (name) of the event type In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 12:33:53 GMT, Marcus Hirt wrote: >> Ok, cool. I'll update this PR along those lines then. > > Hi @gunnarmorling - if you're low on time, I'd be happy to fix this. @thegreystone Just rebased and applied this one. ------------- PR: https://git.openjdk.java.net/jmc/pull/170 From github.com+28612+gunnarmorling at openjdk.java.net Mon Jan 4 16:40:56 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Mon, 4 Jan 2021 16:40:56 GMT Subject: RFR: 7036: Invoke converters/stringify for event fields and return values In-Reply-To: References: <2rEheFYULjvVUdQ80vSI8SqWdkJIjsLXkpgsXBMbQno=.8dfd6aaa-e206-42f3-b3df-36550a8fb085@github.com> <7zcnvQh51WvCPORT9fME7ipQiCcnCBsG3srR0xeZQs0=.3edaab68-01d3-4fbe-8ecd-2985d23f9192@github.com> Message-ID: On Sat, 5 Dec 2020 20:04:01 GMT, Marcus Hirt wrote: > You can check my converter commit to see how. @thegreystone Which commit do you mean exactly? Can you share its SHA? Or are you working on this already? Sorry for the delay btw. :( ------------- PR: https://git.openjdk.java.net/jmc/pull/174 From github.com+28612+gunnarmorling at openjdk.java.net Mon Jan 4 17:43:15 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Mon, 4 Jan 2021 17:43:15 GMT Subject: RFR: 7036: Invoke converters/stringify for event fields and return values In-Reply-To: References: <2rEheFYULjvVUdQ80vSI8SqWdkJIjsLXkpgsXBMbQno=.8dfd6aaa-e206-42f3-b3df-36550a8fb085@github.com> <7zcnvQh51WvCPORT9fME7ipQiCcnCBsG3srR0xeZQs0=.3edaab68-01d3-4fbe-8ecd-2985d23f9192@github.com> Message-ID: <-eHxdnNmtS8G261sa35ttNeffeNzORsNOlFrFLYWMIc=.a27aed1f-6bf2-4e6c-a935-7748873a5a62@github.com> On Mon, 4 Jan 2021 16:53:38 GMT, Marcus Hirt wrote: >>> You can check my converter commit to see how. >> >> @thegreystone Which commit do you mean exactly? Can you share its SHA? Or are you working on this already? Sorry for the delay btw. :( > > I can take it. NP! :) Ok, thanks. Appreciating it! ------------- PR: https://git.openjdk.java.net/jmc/pull/174 From hirt at openjdk.java.net Mon Jan 4 17:43:13 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 4 Jan 2021 17:43:13 GMT Subject: RFR: 7036: Invoke converters/stringify for event fields and return values In-Reply-To: References: <2rEheFYULjvVUdQ80vSI8SqWdkJIjsLXkpgsXBMbQno=.8dfd6aaa-e206-42f3-b3df-36550a8fb085@github.com> <7zcnvQh51WvCPORT9fME7ipQiCcnCBsG3srR0xeZQs0=.3edaab68-01d3-4fbe-8ecd-2985d23f9192@github.com> Message-ID: On Mon, 4 Jan 2021 16:38:11 GMT, Gunnar Morling wrote: >> It should at least test that the instrumentation doesn't generate invalid bytecode. Please add a few probes (and test methods), verifying that converters added to fields and return values doesn't break. You can check my converter commit to see how. > >> You can check my converter commit to see how. > > @thegreystone Which commit do you mean exactly? Can you share its SHA? Or are you working on this already? Sorry for the delay btw. :( I can take it. NP! :) ------------- PR: https://git.openjdk.java.net/jmc/pull/174 From hirt at openjdk.java.net Mon Jan 4 19:41:57 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 4 Jan 2021 19:41:57 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v8] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 22:20:08 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6946: correction build.sh line 88: > 86: printf " \t%s\t%s\n" "--clean" "to run maven clean" > 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" > 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent Example once it was packaged" Any chance you could also add --runAgentConverterExample? :) Basically: --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -XX:+FlightRecorder -javaagent:${resource_loc:/org.openjdk.jmc.agent/target/org.openjdk.jmc.agent-1.0.0-SNAPSHOT.jar}=${resource_loc:/org.openjdk.jmc.agent/src/test/resources/org/openjdk/jmc/agent/converters/test/jfrprobes_template.xml} ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Tue Jan 5 09:30:53 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 5 Jan 2021 09:30:53 GMT Subject: RFR: 7073: Exceptions in FlameGraph In-Reply-To: <0TlKg4wViB7hwLvweMMYLef3S7K3BLoAFJitSMzDog8=.1c9d1042-b5a2-4f12-a12f-19081bee342c@github.com> References: <0TlKg4wViB7hwLvweMMYLef3S7K3BLoAFJitSMzDog8=.1c9d1042-b5a2-4f12-a12f-19081bee342c@github.com> Message-ID: <5n4I_cumACk9QuP7chgvsSScbxWNVIbo_kL97FJdx8c=.38258acb-81c9-4f81-8906-7c44192e08c8@github.com> On Mon, 21 Dec 2020 17:22:56 GMT, Alex Ciminian wrote: > This PR fixes the error reported in the ticket: > > Exception in thread "FlameGraphModelCalculation-1" java.lang.ClassCastException: > class org.openjdk.jmc.flightrecorder.internal.parser.v1.StructTypes$JfrThread cannot be cast > to class org.openjdk.jmc.common.IMCStackTrace > > We remove the use of the deprecated `ItemToolkit.accessor` method and resolve the stacktrace accessor independently for every `IItemIterable`. > > I saw that `accessor` was using `CachingAccessor` internally. I'm not sure if this change has any performance implications but I assume this is a better way to do it since the old way is deprecated. > > The output in the ticket shows that the graph view has a similar problem: > > Exception in thread "GraphModelCalculation-2" java.lang.ClassCastException: > class java.lang.String cannot be cast to class org.openjdk.jmc.common.IMCStackTrace > > We do the same change in `StacktraceGraphModel` where we skip over iterables that don't have a stacktrace accessor. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/187 From ghb at openjdk.java.net Tue Jan 5 13:23:53 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 5 Jan 2021 13:23:53 GMT Subject: RFR: 7078: Update the p2-maven-plugin to 1.5.0 In-Reply-To: References: Message-ID: On Fri, 1 Jan 2021 15:51:48 GMT, Marcus Hirt wrote: > Also cleaning up a bit. Verified fix on Mac OS, Looks good to me. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jmc/pull/188 From hirt at openjdk.java.net Tue Jan 5 14:09:53 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 5 Jan 2021 14:09:53 GMT Subject: Integrated: 7078: Update the p2-maven-plugin to 1.5.0 In-Reply-To: References: Message-ID: On Fri, 1 Jan 2021 15:51:48 GMT, Marcus Hirt wrote: > Also cleaning up a bit. This pull request has now been integrated. Changeset: 44d7dc8e Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/44d7dc8e Stats: 23 lines in 1 file changed: 11 ins; 0 del; 12 mod 7078: Update the p2-maven-plugin to 1.5.0 Reviewed-by: ghb ------------- PR: https://git.openjdk.java.net/jmc/pull/188 From github.com+348973+cimi at openjdk.java.net Tue Jan 5 14:10:58 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 5 Jan 2021 14:10:58 GMT Subject: Integrated: 7073: Exceptions in FlameGraph In-Reply-To: <0TlKg4wViB7hwLvweMMYLef3S7K3BLoAFJitSMzDog8=.1c9d1042-b5a2-4f12-a12f-19081bee342c@github.com> References: <0TlKg4wViB7hwLvweMMYLef3S7K3BLoAFJitSMzDog8=.1c9d1042-b5a2-4f12-a12f-19081bee342c@github.com> Message-ID: On Mon, 21 Dec 2020 17:22:56 GMT, Alex Ciminian wrote: > This PR fixes the error reported in the ticket: > > Exception in thread "FlameGraphModelCalculation-1" java.lang.ClassCastException: > class org.openjdk.jmc.flightrecorder.internal.parser.v1.StructTypes$JfrThread cannot be cast > to class org.openjdk.jmc.common.IMCStackTrace > > We remove the use of the deprecated `ItemToolkit.accessor` method and resolve the stacktrace accessor independently for every `IItemIterable`. > > I saw that `accessor` was using `CachingAccessor` internally. I'm not sure if this change has any performance implications but I assume this is a better way to do it since the old way is deprecated. > > The output in the ticket shows that the graph view has a similar problem: > > Exception in thread "GraphModelCalculation-2" java.lang.ClassCastException: > class java.lang.String cannot be cast to class org.openjdk.jmc.common.IMCStackTrace > > We do the same change in `StacktraceGraphModel` where we skip over iterables that don't have a stacktrace accessor. This pull request has now been integrated. Changeset: eeddd1e6 Author: Alex Ciminian Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/eeddd1e6 Stats: 46 lines in 2 files changed: 12 ins; 17 del; 17 mod 7073: Exceptions in FlameGraph Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/187 From hirt at openjdk.java.net Tue Jan 5 23:15:59 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 5 Jan 2021 23:15:59 GMT Subject: RFR: 7033: Allow overriding the id (name) of the event type [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 16:40:03 GMT, Gunnar Morling wrote: >> @thegreystone et al., this PR proposes two changes to the names of generated event types and their fields: >> >> * An explicit event type name is derived from the name given in the configuration, instead of using the class name; this is nicer to work with e.g. when enabling/disabling event types for recordings >> * the "field" prefix is removed from event type field names; when examining e.g. `RecordedEvent` instances, names are nicer to look at that way IMO >> >> Could you log an issue for this change if you agree it's desirable? Thanks! I ran into these issues while using JMC Agent for [tracking SQL statements](https://twitter.com/gunnarmorling/status/1333152245463064579); note the odd "fieldSQLQuery" name marked on the left; the event type name is already adjusted in this screenshot as per this PR here. > > Gunnar Morling has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 7033: Nicer names for event types and fields Marked as reviewed by hirt (Lead). agent/src/main/java/org/openjdk/jmc/agent/jfrnext/impl/JFRNextEventClassGenerator.java line 235: > 233: > 234: // Name > 235: av = cw.visitAnnotation("Ljdk/jfr/Name;", true); I'd be careful here. The event name is basically the event id. I'd certainly not add Event to the end, or derive it from the event name - the event names for OpenJDK events are typically things like jdk.ClassLoaderStatistics. If anything, it's the id attribute in the templates that should be put in here. That said, I think defaulting to class is fine. To better correspond to JFR 2.0, we may want to rename "name" to "label" to avoid confusion. I'll do that in a separate PR. ------------- PR: https://git.openjdk.java.net/jmc/pull/170 From hirt at openjdk.java.net Tue Jan 5 23:28:53 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 5 Jan 2021 23:28:53 GMT Subject: RFR: 7036: Invoke converters/stringify for event fields and return values [v2] In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 17:40:22 GMT, Gunnar Morling wrote: >> @thegreystone, ran into this left-over from the converter change: no converters/stringify was invoked for field attributes. I've attributed it to the same issue you worked on. > > Gunnar Morling has updated the pull request incrementally with one additional commit since the last revision: > > 6996: Invoking converters/stringify for return value Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/174 From hirt at openjdk.java.net Tue Jan 5 23:28:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 5 Jan 2021 23:28:54 GMT Subject: RFR: 7036: Invoke converters/stringify for event fields and return values In-Reply-To: <-eHxdnNmtS8G261sa35ttNeffeNzORsNOlFrFLYWMIc=.a27aed1f-6bf2-4e6c-a935-7748873a5a62@github.com> References: <2rEheFYULjvVUdQ80vSI8SqWdkJIjsLXkpgsXBMbQno=.8dfd6aaa-e206-42f3-b3df-36550a8fb085@github.com> <7zcnvQh51WvCPORT9fME7ipQiCcnCBsG3srR0xeZQs0=.3edaab68-01d3-4fbe-8ecd-2985d23f9192@github.com> <-eHxdnNmtS8G261sa35ttNeffeNzORsNOlFrFLYWMIc=.a27aed1f-6bf2-4e6c-a935-7748873a5a62@github.com> Message-ID: On Mon, 4 Jan 2021 17:30:33 GMT, Gunnar Morling wrote: >> I can take it. NP! :) > > Ok, thanks. Appreciating it! Will take this as is, and fix it as part of 7008. ------------- PR: https://git.openjdk.java.net/jmc/pull/174 From hirt at openjdk.java.net Tue Jan 5 23:30:00 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 5 Jan 2021 23:30:00 GMT Subject: RFR: 6973: New Method Profiling Page for JMC [v2] In-Reply-To: References: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> Message-ID: On Mon, 14 Dec 2020 16:15:04 GMT, Jean-Philippe Bempel wrote: >> Tabs for Predecessors and Successors instead of Packages/Classes >> >> ![JMC_MethodProfiling_Pred](https://user-images.githubusercontent.com/4610701/100017066-a1774200-2dda-11eb-80c1-9113478a307b.png) >> >> ![JMC_MethodProfiling_Suc](https://user-images.githubusercontent.com/4610701/100017088-aa681380-2dda-11eb-8374-f2e30c8d2b22.png) > > Jean-Philippe Bempel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Fix Successor tree > > Add method formatter context menu > - 6973: New Method Profiling Page for JMC > > Tabs for Predecessors and Successors instead of Packages/Classes Changes requested by hirt (Lead). application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/MethodProfilingPage.java line 36: > 34: > 35: import java.util.Arrays; > 36: import java.util.HashMap; Don't forget to update the copyright year. ------------- PR: https://git.openjdk.java.net/jmc/pull/165 From reinhapa at openjdk.java.net Wed Jan 6 08:20:56 2021 From: reinhapa at openjdk.java.net (Patrick Reinhart) Date: Wed, 6 Jan 2021 08:20:56 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v8] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 19:39:23 GMT, Marcus Hirt wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6946: correction > > build.sh line 88: > >> 86: printf " \t%s\t%s\n" "--clean" "to run maven clean" >> 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" >> 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent Example once it was packaged" > > Any chance you could also add --runAgentConverterExample? :) > > Basically: > --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -XX:+FlightRecorder -javaagent:${resource_loc:/org.openjdk.jmc.agent/target/org.openjdk.jmc.agent-1.0.0-SNAPSHOT.jar}=${resource_loc:/org.openjdk.jmc.agent/src/test/resources/org/openjdk/jmc/agent/converters/test/jfrprobes_template.xml} Although I'm not an reviewer ?? it seems that the `build.cmd` is missing the `--runAgentExample` additon mentioned by @thegreystone. Anything else looks ok. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From github.com+4610701+jpbempel at openjdk.java.net Wed Jan 6 09:06:07 2021 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Wed, 6 Jan 2021 09:06:07 GMT Subject: RFR: 6973: New Method Profiling Page for JMC [v3] In-Reply-To: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> References: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> Message-ID: > Tabs for Predecessors and Successors instead of Packages/Classes > > ![JMC_MethodProfiling_Pred](https://user-images.githubusercontent.com/4610701/100017066-a1774200-2dda-11eb-80c1-9113478a307b.png) > > ![JMC_MethodProfiling_Suc](https://user-images.githubusercontent.com/4610701/100017088-aa681380-2dda-11eb-8374-f2e30c8d2b22.png) Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: fix year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/165/files - new: https://git.openjdk.java.net/jmc/pull/165/files/a1eb59f2..d38f8bd3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=165&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=165&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/165/head:pull/165 PR: https://git.openjdk.java.net/jmc/pull/165 From mwengner at openjdk.java.net Wed Jan 6 12:07:08 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 6 Jan 2021 12:07:08 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v9] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jmc into feature/6946_There_should_be_an_option_to_build_the_agent_in_the_build_script - 6946: correction - 6946: scripts correction - 6946: cleanup - 6946: win script update - 6946: add installCore option - Merge branch 'master' of https://github.com/openjdk/jmc into feature/6946_There_should_be_an_option_to_build_the_agent_in_the_build_script - 6946: windows script update - 6946: typo correction - 6946: cleanup - ... and 1 more: https://git.openjdk.java.net/jmc/compare/2a8c18b7...364a8b44 ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/c44053b7..364a8b44 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=07-08 Stats: 200 lines in 20 files changed: 69 ins; 55 del; 76 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 6 12:14:55 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 6 Jan 2021 12:14:55 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v8] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 08:18:22 GMT, Patrick Reinhart wrote: >> build.sh line 88: >> >>> 86: printf " \t%s\t%s\n" "--clean" "to run maven clean" >>> 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" >>> 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent Example once it was packaged" >> >> Any chance you could also add --runAgentConverterExample? :) >> >> Basically: >> --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -XX:+FlightRecorder -javaagent:${resource_loc:/org.openjdk.jmc.agent/target/org.openjdk.jmc.agent-1.0.0-SNAPSHOT.jar}=${resource_loc:/org.openjdk.jmc.agent/src/test/resources/org/openjdk/jmc/agent/converters/test/jfrprobes_template.xml} > > Although I'm not an reviewer ?? it seems that the `build.cmd` is missing the `--runAgentExample` additon mentioned by @thegreystone. Anything else looks ok. the reason of missing --runAgentExample option is the proper java version detection. I've not found quite nice way hot to do it. Maybe you have some proposal @reinhapa ? ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 6 15:02:08 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 6 Jan 2021 15:02:08 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v10] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: - 6946: typo correction - 6946: runAgentByClass improvements ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/364a8b44..e791794e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=08-09 Stats: 16 lines in 1 file changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From hdafgard at openjdk.java.net Wed Jan 6 17:03:00 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 6 Jan 2021 17:03:00 GMT Subject: RFR: 7076: Rules and Analysis code has exceptions during uitests Message-ID: Fixes exceptions encountered during uitests due to empty grouping arrays. ------------- Commit messages: - Fix exceptions thrown in allocation rules Changes: https://git.openjdk.java.net/jmc/pull/189/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=189&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7076 Stats: 34 lines in 2 files changed: 6 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jmc/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/189/head:pull/189 PR: https://git.openjdk.java.net/jmc/pull/189 From hdafgard at openjdk.java.net Wed Jan 6 17:07:08 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 6 Jan 2021 17:07:08 GMT Subject: RFR: 7076: Rules and Analysis code has exceptions during uitests [v2] In-Reply-To: References: Message-ID: > Fixes exceptions encountered during uitests due to empty grouping arrays. Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/189/files - new: https://git.openjdk.java.net/jmc/pull/189/files/ea6cf8e9..5c35cbf6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=189&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=189&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/189/head:pull/189 PR: https://git.openjdk.java.net/jmc/pull/189 From schaturvedi at openjdk.java.net Wed Jan 6 18:24:15 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Wed, 6 Jan 2021 18:24:15 GMT Subject: RFR: 7032: The banner is missing from help page [v3] In-Reply-To: References: Message-ID: > This change fix the issue of missing banner in help page. > > Please review the change. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Removed the thin white line below banner and modified the alt text ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/173/files - new: https://git.openjdk.java.net/jmc/pull/173/files/4b166896..060abc3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=173&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=173&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/173/head:pull/173 PR: https://git.openjdk.java.net/jmc/pull/173 From aptmac at openjdk.java.net Wed Jan 6 19:16:58 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 6 Jan 2021 19:16:58 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v10] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 15:02:08 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: > > - 6946: typo correction > - 6946: runAgentByClass improvements build.sh line 150: > 148: > 149: if [[ "${OSTYPE}" =~ "linux"* ]] || [[ "${OSTYPE}" =~ "darwin"* ]]; then > 150: printf "%s\n" "You can nor run agent by calling \"${PROGNAME} --runAgentExample\"" s/nor/now/ build.sh line 295: > 293: > 294: function checkJava() { > 295: if ! command -v java &> /dev/null ; then maven looks up JAVA_HOME instead of system java installations, should it look up the env variable instead for verification of java? build.sh line 314: > 312: } > 313: > 314: checkPreconditions Thinking about it now, should checkPreconditions happen here, or would it be better to have it before valid arguments in `parseArgs`? My reasoning being if I just wanted to just see the help menu, the script has to first check for java & maven, and then prints the menu. It's not a particularly long delay, but there is a delay while it verifies. I also noticed this because I had JAVA_HOME unset so the script failed without any output even though I just wanted to read the options. build.sh line 214: > 212: local agentExampleClass=$1 > 213: if [[ -z "${agentExampleClass}" ]]; then > 214: err_log "emtpy class" s/emtpy/empty/ build.sh line 89: > 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" > 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent Example once it was packaged" > 89: printf " \t%s\t%s\n" "--runAgentCustomExample --class:'org.openjdk.jmc.agent.test.InstrumentMe'" "to run custom agent class, once Agent was packaged" This line is really long and causes multi-lines at small widths; it's difficult to read the menu. Does this line do anything at the moment? It doesn't have a match in `parseArgs` ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From github.com+28612+gunnarmorling at openjdk.java.net Wed Jan 6 19:58:57 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Wed, 6 Jan 2021 19:58:57 GMT Subject: RFR: 7036: Invoke converters/stringify for event fields and return values [v2] In-Reply-To: References: Message-ID: <2QYCwZnuJFM829RKl9f4mK52QOVUgfMBYLmmcenlQKU=.0f33a36c-fc45-4453-9018-695da1a748d5@github.com> On Tue, 5 Jan 2021 23:25:57 GMT, Marcus Hirt wrote: >> Gunnar Morling has updated the pull request incrementally with one additional commit since the last revision: >> >> 6996: Invoking converters/stringify for return value > > Marked as reviewed by hirt (Lead). @thegreystone to be sure, you're going to push another commit to wrap this one up, correct? ------------- PR: https://git.openjdk.java.net/jmc/pull/174 From github.com+28612+gunnarmorling at openjdk.java.net Wed Jan 6 20:03:53 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Wed, 6 Jan 2021 20:03:53 GMT Subject: RFR: 7033: Allow overriding the id (name) of the event type [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 09:59:11 GMT, Marcus Hirt wrote: > If anything, it's the id attribute in the templates that should be put in here. But that's what's happening, no? I'm not quite following your comment. ------------- PR: https://git.openjdk.java.net/jmc/pull/170 From github.com+28612+gunnarmorling at openjdk.java.net Wed Jan 6 20:13:55 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Wed, 6 Jan 2021 20:13:55 GMT Subject: Integrated: 7036: Invoke converters/stringify for event fields and return values In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 21:45:29 GMT, Gunnar Morling wrote: > @thegreystone, ran into this left-over from the converter change: no converters/stringify was invoked for field attributes. I've attributed it to the same issue you worked on. This pull request has now been integrated. Changeset: 88731ed9 Author: Gunnar Morling Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/88731ed9 Stats: 42 lines in 1 file changed: 33 ins; 0 del; 9 mod 7036: Invoke converters/stringify for event fields and return values Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/174 From github.com+28612+gunnarmorling at openjdk.java.net Wed Jan 6 20:13:53 2021 From: github.com+28612+gunnarmorling at openjdk.java.net (Gunnar Morling) Date: Wed, 6 Jan 2021 20:13:53 GMT Subject: Integrated: 7033: Allow overriding the id (name) of the event type In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 19:51:23 GMT, Gunnar Morling wrote: > @thegreystone et al., this PR proposes two changes to the names of generated event types and their fields: > > * An explicit event type name is derived from the name given in the configuration, instead of using the class name; this is nicer to work with e.g. when enabling/disabling event types for recordings > * the "field" prefix is removed from event type field names; when examining e.g. `RecordedEvent` instances, names are nicer to look at that way IMO > > Could you log an issue for this change if you agree it's desirable? Thanks! I ran into these issues while using JMC Agent for [tracking SQL statements](https://twitter.com/gunnarmorling/status/1333152245463064579); note the odd "fieldSQLQuery" name marked on the left; the event type name is already adjusted in this screenshot as per this PR here. This pull request has now been integrated. Changeset: 319ad868 Author: Gunnar Morling Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/319ad868 Stats: 25 lines in 2 files changed: 13 ins; 5 del; 7 mod 7033: Allow overriding the id (name) of the event type Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/170 From ghb at openjdk.java.net Thu Jan 7 04:43:04 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 7 Jan 2021 04:43:04 GMT Subject: RFR: 7081: Update Copyright year to 2021 Message-ID: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Updated Copyright year to 2021 for below 1. License show in "About" dialog 2. Copyright year in License file 3. Update site landing page 4. added a helper script which can be used to update copyright year for modified git files. ------------- Commit messages: - 7081: Update Copyright year to 2021 Changes: https://git.openjdk.java.net/jmc/pull/190/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=190&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7081 Stats: 881 lines in 313 files changed: 24 ins; 0 del; 857 mod Patch: https://git.openjdk.java.net/jmc/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/190/head:pull/190 PR: https://git.openjdk.java.net/jmc/pull/190 From ghb at openjdk.java.net Thu Jan 7 04:54:16 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 7 Jan 2021 04:54:16 GMT Subject: RFR: 7081: Update Copyright year to 2021 [v2] In-Reply-To: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: > Updated Copyright year to 2021 for below > 1. License show in "About" dialog > 2. Copyright year in License file > 3. Update site landing page > 4. added a helper script which can be used to update copyright year for modified git files. Guru Hb has updated the pull request incrementally with one additional commit since the last revision: Removing non existed module ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/190/files - new: https://git.openjdk.java.net/jmc/pull/190/files/7811dd0b..f6229e37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=190&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=190&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/190/head:pull/190 PR: https://git.openjdk.java.net/jmc/pull/190 From ghb at openjdk.java.net Fri Jan 8 06:37:54 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 8 Jan 2021 06:37:54 GMT Subject: RFR: 6973: New Method Profiling Page for JMC [v3] In-Reply-To: References: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> Message-ID: <5Ccp04qgsfG6GWKKx8rnezmdoIQGiiLGnGLX9caemhY=.f81dbdaa-9409-4c10-9e83-de0148280a46@github.com> On Wed, 6 Jan 2021 09:06:07 GMT, Jean-Philippe Bempel wrote: >> Tabs for Predecessors and Successors instead of Packages/Classes >> >> ![JMC_MethodProfiling_Pred](https://user-images.githubusercontent.com/4610701/100017066-a1774200-2dda-11eb-80c1-9113478a307b.png) >> >> ![JMC_MethodProfiling_Suc](https://user-images.githubusercontent.com/4610701/100017088-aa681380-2dda-11eb-8374-f2e30c8d2b22.png) > > Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: > > fix year Before integrating, Do update the copyright year to 2021. Tested on Windows , Changes looks good to me ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jmc/pull/165 From hirt at openjdk.java.net Fri Jan 8 11:40:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 8 Jan 2021 11:40:54 GMT Subject: RFR: 7032: The banner is missing from help page [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 18:24:15 GMT, Suchita Chaturvedi wrote: >> This change fix the issue of missing banner in help page. >> >> Please review the change. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Removed the thin white line below banner and modified the alt text Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/173 From mwengner at openjdk.java.net Fri Jan 8 13:27:07 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Fri, 8 Jan 2021 13:27:07 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v11] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jmc into feature/6946_There_should_be_an_option_to_build_the_agent_in_the_build_script - 6946: add custom agent option - 6946: typo correction - 6946: runAgentByClass improvements - Merge branch 'master' of https://github.com/openjdk/jmc into feature/6946_There_should_be_an_option_to_build_the_agent_in_the_build_script - 6946: correction - 6946: scripts correction - 6946: cleanup - 6946: win script update - 6946: add installCore option - ... and 5 more: https://git.openjdk.java.net/jmc/compare/6be8d5b6...45d494ad ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/e791794e..45d494ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=09-10 Stats: 76 lines in 4 files changed: 51 ins; 5 del; 20 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Fri Jan 8 14:01:55 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Fri, 8 Jan 2021 14:01:55 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v8] In-Reply-To: References: Message-ID: <9f35MSrcFejD-SbV-jt5DqfyC4DTh4boypeGnlO5pE8=.329a50e7-68c2-47f8-acf5-62dc2a2c25b5@github.com> On Mon, 4 Jan 2021 19:39:23 GMT, Marcus Hirt wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6946: correction > > build.sh line 88: > >> 86: printf " \t%s\t%s\n" "--clean" "to run maven clean" >> 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" >> 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent Example once it was packaged" > > Any chance you could also add --runAgentConverterExample? :) > > Basically: > --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -XX:+FlightRecorder -javaagent:${resource_loc:/org.openjdk.jmc.agent/target/org.openjdk.jmc.agent-1.0.0-SNAPSHOT.jar}=${resource_loc:/org.openjdk.jmc.agent/src/test/resources/org/openjdk/jmc/agent/converters/test/jfrprobes_template.xml} I've add an option --runAgentCustomExample '' => --runAgentCustomExample 'org.openjdk.jmc.agent.test.InstrumentMe' , what do you think ? @thegreystone ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Fri Jan 8 14:10:57 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Fri, 8 Jan 2021 14:10:57 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v10] In-Reply-To: References: Message-ID: <4UQUkdlI22dr5aBuqYPBtFmazucQ-jgOq38cDuJJFhw=.50189ca9-0019-4fd8-b03e-a07858efb2f0@github.com> On Wed, 6 Jan 2021 19:13:52 GMT, Alex Macdonald wrote: >> Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: >> >> - 6946: typo correction >> - 6946: runAgentByClass improvements > > build.sh line 89: > >> 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" >> 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent Example once it was packaged" >> 89: printf " \t%s\t%s\n" "--runAgentCustomExample --class:'org.openjdk.jmc.agent.test.InstrumentMe'" "to run custom agent class, once Agent was packaged" > > This line is really long and causes multi-lines at small widths; it's difficult to read the menu. > > Does this line do anything at the moment? It doesn't have a match in `parseArgs` yeah it does, @aptmac I've update the repo now, maybe I'd remove the Example or just merge them together,--runAgent* is the terminal option, it returns the error code. what do you think ? ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From github.com+4610701+jpbempel at openjdk.java.net Fri Jan 8 14:14:14 2021 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Fri, 8 Jan 2021 14:14:14 GMT Subject: RFR: 6973: New Method Profiling Page for JMC [v4] In-Reply-To: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> References: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> Message-ID: > Tabs for Predecessors and Successors instead of Packages/Classes > > ![JMC_MethodProfiling_Pred](https://user-images.githubusercontent.com/4610701/100017066-a1774200-2dda-11eb-80c1-9113478a307b.png) > > ![JMC_MethodProfiling_Suc](https://user-images.githubusercontent.com/4610701/100017088-aa681380-2dda-11eb-8374-f2e30c8d2b22.png) Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: update year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/165/files - new: https://git.openjdk.java.net/jmc/pull/165/files/d38f8bd3..8d301d90 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=165&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=165&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/165/head:pull/165 PR: https://git.openjdk.java.net/jmc/pull/165 From hirt at openjdk.java.net Fri Jan 8 15:11:55 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 8 Jan 2021 15:11:55 GMT Subject: RFR: 6973: New Method Profiling Page for JMC [v4] In-Reply-To: References: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> Message-ID: On Fri, 8 Jan 2021 14:14:14 GMT, Jean-Philippe Bempel wrote: >> Tabs for Predecessors and Successors instead of Packages/Classes >> >> ![JMC_MethodProfiling_Pred](https://user-images.githubusercontent.com/4610701/100017066-a1774200-2dda-11eb-80c1-9113478a307b.png) >> >> ![JMC_MethodProfiling_Suc](https://user-images.githubusercontent.com/4610701/100017088-aa681380-2dda-11eb-8374-f2e30c8d2b22.png) > > Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: > > update year Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/165 From jbachorik at openjdk.java.net Fri Jan 8 16:16:16 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 8 Jan 2021 16:16:16 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v4] In-Reply-To: References: Message-ID: > This is an initial implementation of JFR binary format writer in Java. > The writer can write valid JFR files according to what is expected by the JMC JFR format reader. > The writer is not complete in terms of performance and event settings support but in spite of that it is fairly usable. > > The typical flow is: > > 1. Obtain a new instance of Recording > java > Recording r = new Recording() > 2. Register custom types for that recording > java > r.registerType(name, structure) > 3. Get a new Chunk instance > java > Chunk c = r.newChunk() > 4. Write event values > java > c.writeEvent(eventValue) > 5. Finish the chunk and get the binary data > java > byte[] data = c.finish() > > > For more complex usage check [ChunkComplexTest.java](https://github.com/openjdk/jmc/blob/4c2dd1407f462feae40b795d3a4c6d75544b4e82/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java). Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Lombok cleanup ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/84/files - new: https://git.openjdk.java.net/jmc/pull/84/files/a2178829..69e1e028 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=02-03 Stats: 225 lines in 17 files changed: 145 ins; 73 del; 7 mod Patch: https://git.openjdk.java.net/jmc/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/84/head:pull/84 PR: https://git.openjdk.java.net/jmc/pull/84 From hirt at openjdk.java.net Fri Jan 8 16:23:55 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 8 Jan 2021 16:23:55 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v8] In-Reply-To: <9f35MSrcFejD-SbV-jt5DqfyC4DTh4boypeGnlO5pE8=.329a50e7-68c2-47f8-acf5-62dc2a2c25b5@github.com> References: <9f35MSrcFejD-SbV-jt5DqfyC4DTh4boypeGnlO5pE8=.329a50e7-68c2-47f8-acf5-62dc2a2c25b5@github.com> Message-ID: <4fPBn1DzRgaPfcQT_Ur2r3qlllhDicVvZG8UGuW3W9A=.979d60ca-47d3-4fde-af2c-4a771fbbb946@github.com> On Fri, 8 Jan 2021 13:59:08 GMT, Miroslav Wengner wrote: >> build.sh line 88: >> >>> 86: printf " \t%s\t%s\n" "--clean" "to run maven clean" >>> 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" >>> 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent Example once it was packaged" >> >> Any chance you could also add --runAgentConverterExample? :) >> >> Basically: >> --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -XX:+FlightRecorder -javaagent:${resource_loc:/org.openjdk.jmc.agent/target/org.openjdk.jmc.agent-1.0.0-SNAPSHOT.jar}=${resource_loc:/org.openjdk.jmc.agent/src/test/resources/org/openjdk/jmc/agent/converters/test/jfrprobes_template.xml} > > I've add an option --runAgentCustomExample '' => --runAgentCustomExample 'org.openjdk.jmc.agent.test.InstrumentMe' , what do you think ? @thegreystone For me, the buildscript is all about making it easier to do common things. The --runAgentConvertExample option makes it easy to run one of the two examples one might want to run to test things from JMC. If I need to do something custom, I might as well just put the built agent jar on the command line and do whatever I want to do. Since the classpath won't be set to anything else, there won't be that many main classes to pick from other than the standard example and the converter example. I would suggest just having --runAgentExample and --runAgentConverterExample. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From github.com+4610701+jpbempel at openjdk.java.net Sat Jan 9 00:45:52 2021 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Sat, 9 Jan 2021 00:45:52 GMT Subject: Integrated: 6973: New Method Profiling Page for JMC In-Reply-To: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> References: <5JtLeMi4opKYmuoYDPClZ1I5CVQCd6rVUJMfpG6rQuU=.4683d025-c3b9-430c-ac6d-ea6de1fb1212@github.com> Message-ID: On Mon, 23 Nov 2020 21:24:45 GMT, Jean-Philippe Bempel wrote: > Tabs for Predecessors and Successors instead of Packages/Classes > > ![JMC_MethodProfiling_Pred](https://user-images.githubusercontent.com/4610701/100017066-a1774200-2dda-11eb-80c1-9113478a307b.png) > > ![JMC_MethodProfiling_Suc](https://user-images.githubusercontent.com/4610701/100017088-aa681380-2dda-11eb-8374-f2e30c8d2b22.png) This pull request has now been integrated. Changeset: 8d34bbb1 Author: Jean-Philippe Bempel Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/8d34bbb1 Stats: 662 lines in 5 files changed: 574 ins; 21 del; 67 mod 6973: New Method Profiling Page for JMC Reviewed-by: hirt, ghb ------------- PR: https://git.openjdk.java.net/jmc/pull/165 From hdafgard at openjdk.java.net Sat Jan 9 18:27:06 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Sat, 9 Jan 2021 18:27:06 GMT Subject: RFR: 7079: Numeric values in automated analysis summary is not resolved Message-ID: JFX Pulse Duration rule does not register result attributes properly, this causes templating to fail. ------------- Commit messages: - Register result attributes Changes: https://git.openjdk.java.net/jmc/pull/191/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=191&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7079 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/191.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/191/head:pull/191 PR: https://git.openjdk.java.net/jmc/pull/191 From hirt at openjdk.java.net Sun Jan 10 01:09:59 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 01:09:59 GMT Subject: RFR: 7079: Numeric values in automated analysis summary is not resolved In-Reply-To: References: Message-ID: On Sat, 9 Jan 2021 18:22:46 GMT, Henrik Dafg?rd wrote: > JFX Pulse Duration rule does not register result attributes properly, this causes templating to fail. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/191 From hirt at openjdk.java.net Sun Jan 10 01:10:09 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 01:10:09 GMT Subject: RFR: 7008: Agent should properly support Class and Thread Message-ID: <94c0trvCPPx5Cwo__uJJ_uX_SFGmJy3JF4xVX8njSHU=.5dd45dc1-5daa-4d94-8e57-0535002e2d7d@github.com> Also fixes various issues and tests. ------------- Commit messages: - Formatting - Temporary pre-merge commit Changes: https://git.openjdk.java.net/jmc/pull/192/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=192&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7008 Stats: 476 lines in 14 files changed: 342 ins; 53 del; 81 mod Patch: https://git.openjdk.java.net/jmc/pull/192.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/192/head:pull/192 PR: https://git.openjdk.java.net/jmc/pull/192 From hirt at openjdk.java.net Sun Jan 10 01:10:56 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 01:10:56 GMT Subject: RFR: 7076: Rules and Analysis code has exceptions during uitests [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 17:07:08 GMT, Henrik Dafg?rd wrote: >> Fixes exceptions encountered during uitests due to empty grouping arrays. > > Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/189 From hirt at openjdk.java.net Sun Jan 10 01:15:53 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 01:15:53 GMT Subject: RFR: 7079: Numeric values in automated analysis summary is not resolved In-Reply-To: References: Message-ID: <3OuXjHuFGnaiuP_Gpn9P2wfhjZrU2VANFkIeBv7GDKI=.494cb6aa-5e84-41c5-92a6-95eb528629b8@github.com> On Sun, 10 Jan 2021 01:07:22 GMT, Marcus Hirt wrote: >> JFX Pulse Duration rule does not register result attributes properly, this causes templating to fail. > > Marked as reviewed by hirt (Lead). Don't forget to update the copyright to 2021. Otherwise good! ------------- PR: https://git.openjdk.java.net/jmc/pull/191 From hirt at openjdk.java.net Sun Jan 10 01:16:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 01:16:54 GMT Subject: RFR: 7076: Rules and Analysis code has exceptions during uitests [v2] In-Reply-To: References: Message-ID: <-16fKyDOFsnO3Ln6s0jnPtpQuUlTIbRe1BYC0V7NykE=.b8cc6943-b34b-449c-bc14-cf5659854409@github.com> On Sun, 10 Jan 2021 01:08:12 GMT, Marcus Hirt wrote: >> Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix whitespace > > Marked as reviewed by hirt (Lead). Don't forget to update the copyrights to 2021, otherwise good! ------------- PR: https://git.openjdk.java.net/jmc/pull/189 From schaturvedi at openjdk.java.net Sun Jan 10 15:06:54 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Sun, 10 Jan 2021 15:06:54 GMT Subject: Integrated: 7032: The banner is missing from help page In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 21:55:48 GMT, Suchita Chaturvedi wrote: > This change fix the issue of missing banner in help page. > > Please review the change. This pull request has now been integrated. Changeset: a21771c4 Author: Suchita Chaturvedi URL: https://git.openjdk.java.net/jmc/commit/a21771c4 Stats: 15 lines in 3 files changed: 14 ins; 0 del; 1 mod 7032: The banner is missing from help page Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/173 From hdafgard at openjdk.java.net Sun Jan 10 15:19:07 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Sun, 10 Jan 2021 15:19:07 GMT Subject: RFR: 7079: Numeric values in automated analysis summary is not resolved [v2] In-Reply-To: References: Message-ID: > JFX Pulse Duration rule does not register result attributes properly, this causes templating to fail. Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/191/files - new: https://git.openjdk.java.net/jmc/pull/191/files/1e458ae8..ee2025e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=191&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=191&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/191.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/191/head:pull/191 PR: https://git.openjdk.java.net/jmc/pull/191 From hdafgard at openjdk.java.net Sun Jan 10 15:21:10 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Sun, 10 Jan 2021 15:21:10 GMT Subject: RFR: 7076: Rules and Analysis code has exceptions during uitests [v3] In-Reply-To: References: Message-ID: > Fixes exceptions encountered during uitests due to empty grouping arrays. Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/189/files - new: https://git.openjdk.java.net/jmc/pull/189/files/5c35cbf6..3180bba8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=189&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=189&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/189/head:pull/189 PR: https://git.openjdk.java.net/jmc/pull/189 From hirt at openjdk.java.net Sun Jan 10 15:45:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 15:45:54 GMT Subject: RFR: 7076: Rules and Analysis code has exceptions during uitests [v3] In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 15:21:10 GMT, Henrik Dafg?rd wrote: >> Fixes exceptions encountered during uitests due to empty grouping arrays. > > Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/189 From hirt at openjdk.java.net Sun Jan 10 15:46:53 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 15:46:53 GMT Subject: RFR: 7079: Numeric values in automated analysis summary is not resolved [v2] In-Reply-To: References: Message-ID: <-2t0bC-UogTG6OyRCY6klLxFetQLINZ-ru3IMyjY3FI=.df372303-6686-4a4c-9c7e-d0697b444f20@github.com> On Sun, 10 Jan 2021 15:19:07 GMT, Henrik Dafg?rd wrote: >> JFX Pulse Duration rule does not register result attributes properly, this causes templating to fail. > > Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/191 From hirt at openjdk.java.net Sun Jan 10 18:15:12 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 10 Jan 2021 18:15:12 GMT Subject: RFR: 7008: Agent should properly support Class and Thread [v2] In-Reply-To: <94c0trvCPPx5Cwo__uJJ_uX_SFGmJy3JF4xVX8njSHU=.5dd45dc1-5daa-4d94-8e57-0535002e2d7d@github.com> References: <94c0trvCPPx5Cwo__uJJ_uX_SFGmJy3JF4xVX8njSHU=.5dd45dc1-5daa-4d94-8e57-0535002e2d7d@github.com> Message-ID: > Also fixes various issues and tests. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Removing temporary workaround ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/192/files - new: https://git.openjdk.java.net/jmc/pull/192/files/9a2fc3f6..d48e1486 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=192&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=192&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/192.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/192/head:pull/192 PR: https://git.openjdk.java.net/jmc/pull/192 From hirt at openjdk.java.net Mon Jan 11 14:22:03 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 11 Jan 2021 14:22:03 GMT Subject: RFR: 6588: Move JMC core to JDK 8 Message-ID: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> WIP. Now that core requires JDK 8, we can make it a little bit more easygoing when using streams. I'm thinking it would be nice to remove the need for the StreamModel altogether as well. ------------- Commit messages: - Adding values() - Supporting streaming in IItemIterable - Additional cleanup - Inlining stream - First move - 6588: Initial cleanup Changes: https://git.openjdk.java.net/jmc/pull/194/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-6588 Stats: 961 lines in 71 files changed: 488 ins; 411 del; 62 mod Patch: https://git.openjdk.java.net/jmc/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/194/head:pull/194 PR: https://git.openjdk.java.net/jmc/pull/194 From mwengner at openjdk.java.net Mon Jan 11 16:32:10 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 16:32:10 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v12] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: add agent converter example and precoditions checks ordering ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/45d494ad..e47c9dd6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=10-11 Stats: 15 lines in 1 file changed: 6 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 16:32:10 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 16:32:10 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v8] In-Reply-To: <4fPBn1DzRgaPfcQT_Ur2r3qlllhDicVvZG8UGuW3W9A=.979d60ca-47d3-4fde-af2c-4a771fbbb946@github.com> References: <9f35MSrcFejD-SbV-jt5DqfyC4DTh4boypeGnlO5pE8=.329a50e7-68c2-47f8-acf5-62dc2a2c25b5@github.com> <4fPBn1DzRgaPfcQT_Ur2r3qlllhDicVvZG8UGuW3W9A=.979d60ca-47d3-4fde-af2c-4a771fbbb946@github.com> Message-ID: On Fri, 8 Jan 2021 16:20:55 GMT, Marcus Hirt wrote: >> I've add an option --runAgentCustomExample '' => --runAgentCustomExample 'org.openjdk.jmc.agent.test.InstrumentMe' , what do you think ? @thegreystone > > For me, the buildscript is all about making it easier to do common things. The --runAgentConvertExample option makes it easy to run one of the two examples one might want to run to test things from JMC. If I need to do something custom, I might as well just put the built agent jar on the command line and do whatever I want to do. Since the classpath won't be set to anything else, there won't be that many main classes to pick from other than the standard example and the converter example. > > I would suggest just having --runAgentExample and --runAgentConverterExample. agree, updated 2 options: --runAgentExample and --runAgentConverterExample. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 16:36:03 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 16:36:03 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v10] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 18:53:02 GMT, Alex Macdonald wrote: >> Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: >> >> - 6946: typo correction >> - 6946: runAgentByClass improvements > > build.sh line 295: > >> 293: >> 294: function checkJava() { >> 295: if ! command -v java &> /dev/null ; then > > maven looks up JAVA_HOME instead of system java installations, should it look up the env variable instead for verification of java? i've changed the commands order inside the 'checkPredcoditions' method. 1st check is JAVA_HOME. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 16:43:11 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 16:43:11 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v13] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: typo correction ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/e47c9dd6..95780d8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 16:43:13 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 16:43:13 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v10] In-Reply-To: References: Message-ID: <4E-c-nDcPkKdLclHWfvX48S2-hZY9LH7b_59qx65mQo=.2d4da41c-c90c-42d4-a3dd-2bd3e696d506@github.com> On Wed, 6 Jan 2021 18:49:23 GMT, Alex Macdonald wrote: >> Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: >> >> - 6946: typo correction >> - 6946: runAgentByClass improvements > > build.sh line 150: > >> 148: >> 149: if [[ "${OSTYPE}" =~ "linux"* ]] || [[ "${OSTYPE}" =~ "darwin"* ]]; then >> 150: printf "%s\n" "You can nor run agent by calling \"${PROGNAME} --runAgentExample\"" > > s/nor/now/ corrected > build.sh line 314: > >> 312: } >> 313: >> 314: checkPreconditions > > Thinking about it now, should checkPreconditions happen here, or would it be better to have it before valid arguments in `parseArgs`? > > My reasoning being if I just wanted to just see the help menu, the script has to first check for java & maven, and then prints the menu. It's not a particularly long delay, but there is a delay while it verifies. I also noticed this because I had JAVA_HOME unset so the script failed without any output even though I just wanted to read the options. I've changed the checks order, JAVA_HOME is 1st now. Nice catch ! ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 16:47:17 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 16:47:17 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v14] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: type correction, and error message improvement ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/95780d8f..89852e9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 16:47:18 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 16:47:18 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v10] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 19:10:32 GMT, Alex Macdonald wrote: >> Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: >> >> - 6946: typo correction >> - 6946: runAgentByClass improvements > > build.sh line 214: > >> 212: local agentExampleClass=$1 >> 213: if [[ -z "${agentExampleClass}" ]]; then >> 214: err_log "emtpy class" > > s/emtpy/empty/ corrected ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Mon Jan 11 19:14:00 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 11 Jan 2021 19:14:00 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v14] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 16:47:17 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6946: type correction, and error message improvement Changes requested by hirt (Lead). build.sh line 89: > 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" > 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent 'InstrumentMe' example once it was packaged" > 89: printf " \t%s\t%s\n" "--runAgentConverterExample" "to run Agent Converter 'InstrumentMeConverter' example, once Agent was packaged" Skip converter and the comma, to keep with the pattern for the other "run"-> "--runAgentConverterExample" "to run Agent 'InstrumentMeConverter' example once it was packaged" build.bat line 44: > 42: if "%1" == "--packageJmc" goto packageJmc > 43: if "%1" == "--packageAgent" goto packageAgent > 44: if "%1" == "--clean" goto clean Lacks the --runAgentExample and the --runAgentConverterExample. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 19:47:13 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 19:47:13 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v15] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: help correction ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/89852e9e..f7cc211e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=13-14 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Mon Jan 11 19:56:59 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Mon, 11 Jan 2021 19:56:59 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v14] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 19:10:49 GMT, Marcus Hirt wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6946: type correction, and error message improvement > > build.bat line 44: > >> 42: if "%1" == "--packageJmc" goto packageJmc >> 43: if "%1" == "--packageAgent" goto packageAgent >> 44: if "%1" == "--clean" goto clean > > Lacks the --runAgentExample and the --runAgentConverterExample. because as I've mentioned above, maybe here can help someone with win machine. to parse properly the java version and base on that execute the agents. I bet the only parsing java version will be separate bat script. I'm not sure wether such option is worth to the effort. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From aptmac at openjdk.java.net Mon Jan 11 21:10:07 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Mon, 11 Jan 2021 21:10:07 GMT Subject: RFR: 7063: JfrThreadsPageTest (UI-test) fails Message-ID: Hi! This PR addresses JMC-7063 [[0]](https://bugs.openjdk.java.net/browse/JMC-7063), in which there are test failures when running uitests on the threads page. This test failure has also been brought up in JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077), which encompasses the larger problem of uitest failures in JMC 8. The problem here was the hardcoded time strings (do'h!). I had originally thought the problem was Jemmy being unable to find the time filter text boxes due to screen size limitations, but in reality Jemmy couldn't find the text boxes because we had hardcoded the time strings in the test class for verification purposes. A big thanks to Bipin for posting a video clip of the test failure to the JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077) issue report, I was able to see that Jemmy was struggling to find the text box with "08:06:19:489" because it was not the right time in his timezone! To address this, Jemmy will now lookup the text boxes using a "name" that is assigned to them when they are created. The unit tests will now use a simple date formatter to apply a time offset to the start and end times to verify behaviour in the UI instead of checking against a (probably) incorrect hardcoded time string. For quicker testing and reviewing, I've attached a patch diff (in txt format) that can be applied on top of this commit if you wish to only test the JfrThreadsPageTest. It simply prevents the non-flightrecorder.ui uitest modules from running, and gets rid of all other test classes: [only-jfrthreadspagetest.txt](https://github.com/openjdk/jmc/files/5797935/only-jfrthreadspagetest.txt) [0] https://bugs.openjdk.java.net/browse/JMC-7063 [1] https://bugs.openjdk.java.net/browse/JMC-7077 ------------- Commit messages: - 7063: JfrThreadsPageTest (UI-test) fails Changes: https://git.openjdk.java.net/jmc/pull/195/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=195&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7063 Stats: 57 lines in 2 files changed: 27 ins; 5 del; 25 mod Patch: https://git.openjdk.java.net/jmc/pull/195.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/195/head:pull/195 PR: https://git.openjdk.java.net/jmc/pull/195 From hirt at openjdk.java.net Mon Jan 11 21:11:11 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 11 Jan 2021 21:11:11 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v2] In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: > WIP. Now that core requires JDK 8, we can make it a little bit more easygoing when using streams. I'm thinking it would be nice to remove the need for the StreamModel altogether as well. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Formatting ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/194/files - new: https://git.openjdk.java.net/jmc/pull/194/files/819564a6..ac0c6316 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/194/head:pull/194 PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Mon Jan 11 21:14:53 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 11 Jan 2021 21:14:53 GMT Subject: RFR: 7063: JfrThreadsPageTest (UI-test) fails In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 21:05:42 GMT, Alex Macdonald wrote: > Hi! This PR addresses JMC-7063 [[0]](https://bugs.openjdk.java.net/browse/JMC-7063), in which there are test failures when running uitests on the threads page. This test failure has also been brought up in JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077), which encompasses the larger problem of uitest failures in JMC 8. > > The problem here was the hardcoded time strings (do'h!). I had originally thought the problem was Jemmy being unable to find the time filter text boxes due to screen size limitations, but in reality Jemmy couldn't find the text boxes because we had hardcoded the time strings in the test class for verification purposes. A big thanks to Bipin for posting a video clip of the test failure to the JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077) issue report, I was able to see that Jemmy was struggling to find the text box with "08:06:19:489" because it was not the right time in his timezone! > > To address this, Jemmy will now lookup the text boxes using a "name" that is assigned to them when they are created. The unit tests will now use a simple date formatter to apply a time offset to the start and end times to verify behaviour in the UI instead of checking against a (probably) incorrect hardcoded time string. > > For quicker testing and reviewing, I've attached a patch diff (in txt format) that can be applied on top of this commit if you wish to only test the JfrThreadsPageTest. It simply prevents the non-flightrecorder.ui uitest modules from running, and gets rid of all other test classes: [only-jfrthreadspagetest.txt](https://github.com/openjdk/jmc/files/5797935/only-jfrthreadspagetest.txt) > > [0] https://bugs.openjdk.java.net/browse/JMC-7063 > [1] https://bugs.openjdk.java.net/browse/JMC-7077 Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/195 From ghb at openjdk.java.net Tue Jan 12 06:44:11 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 12 Jan 2021 06:44:11 GMT Subject: RFR: 7081: Update Copyright year to 2021, Validate and update license attributes [v3] In-Reply-To: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: > Updated Copyright year to 2021 for below > 1. License show in "About" dialog > 2. Copyright year in License file > 3. Update site landing page > 4. added a helper script which can be used to update copyright year for modified git files. Guru Hb has updated the pull request incrementally with one additional commit since the last revision: Updated Copyright attributes for Eclipse 4.16, Babel, D3, d3-flame-graph, d3-graphviz, removed html5-shiv ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/190/files - new: https://git.openjdk.java.net/jmc/pull/190/files/f6229e37..96901546 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=190&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=190&range=01-02 Stats: 2898 lines in 1 file changed: 1722 ins; 1074 del; 102 mod Patch: https://git.openjdk.java.net/jmc/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/190/head:pull/190 PR: https://git.openjdk.java.net/jmc/pull/190 From hirt at openjdk.java.net Tue Jan 12 09:16:01 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 09:16:01 GMT Subject: RFR: 7081: Update Copyright year to 2021, Validate and update license attributes [v3] In-Reply-To: References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: <1HtDBoFEs860gCvHpMEG0Oru2Zx3qMpA6VQYG6AIuIQ=.85c7ae3b-c794-4eb9-93d5-40f582c7e217@github.com> On Tue, 12 Jan 2021 06:44:11 GMT, Guru Hb wrote: >> Updated Copyright year to 2021 for below >> 1. License show in "About" dialog >> 2. Copyright year in License file >> 3. Update site landing page >> 4. added a helper script which can be used to update copyright year for modified git files. > > Guru Hb has updated the pull request incrementally with one additional commit since the last revision: > > Updated Copyright attributes for Eclipse 4.16, Babel, D3, d3-flame-graph, d3-graphviz, removed html5-shiv Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/190 From mwengner at openjdk.java.net Tue Jan 12 10:17:09 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 12 Jan 2021 10:17:09 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: References: Message-ID: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: win os update ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/f7cc211e..88bac6ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=14-15 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Tue Jan 12 10:23:55 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 12 Jan 2021 10:23:55 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v14] In-Reply-To: References: Message-ID: <1vfEq_Jz1l9fhIW-ggkO1mX32azFUZlNFaLgu2Fwn2c=.7349f604-69fb-4eee-9f94-80dd912417b1@github.com> On Mon, 11 Jan 2021 19:54:08 GMT, Miroslav Wengner wrote: >> build.bat line 44: >> >>> 42: if "%1" == "--packageJmc" goto packageJmc >>> 43: if "%1" == "--packageAgent" goto packageAgent >>> 44: if "%1" == "--clean" goto clean >> >> Lacks the --runAgentExample and the --runAgentConverterExample. > > because as I've mentioned above, maybe here can help someone with win machine. to parse properly the java version and base on that execute the agents. I bet the only parsing java version will be separate bat script. I'm not sure wether such option is worth to the effort. I've add one for java 11, i think it should be fine as you've said. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From github.com+348973+cimi at openjdk.java.net Tue Jan 12 11:35:03 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 12 Jan 2021 11:35:03 GMT Subject: RFR: 7002: Too large graphs will freeze JMC Message-ID: This PR adds a control to limit the maximum number of nodes that can be rendered in the JMC graph view. At the moment, rendering very large graphs makes the application unresponsive so we want to guard against this by setting a limit on the maximum number of nodes that will be rendered. When this limit is exceeded, we don't try to render our `StacktraceGraphModel` into a graphiz dot string and instead we generate a simple dot string with one node and a message informing the user that they are trying to render too many nodes. I spent a couple of hours fighting with SWT to get the basic dropdown functionality working in the component toolbar. I took some inspiration from the FlameView component's toolbar actions and I found some (not great) examples with Google. I'm happy to use other components - this seemed to be the simplest from what I found. Please let me know if there's anything better. ?? --- ![Screenshot 2021-01-10 at 18 14 39](https://user-images.githubusercontent.com/348973/104131749-4987a100-5370-11eb-8ae1-b9ee8064921f.png) ![Screenshot 2021-01-10 at 18 15 00](https://user-images.githubusercontent.com/348973/104131756-5c01da80-5370-11eb-9fe3-67e357d0fa00.png) We will also display a similar message when the graph model has no information (no nodes): ![Screenshot 2021-01-10 at 18 14 20](https://user-images.githubusercontent.com/348973/104131741-3c6ab200-5370-11eb-8d6f-1901371ab21f.png) --- Other things we've considered: - ~add an icon instead of the text in the toolbar~ - we'll leave the text label for now - ~create text labels instead of the hardcoded strings I'm using now~ - we decided not to do localisation while this view is experimental - I was on the fence about adding a 'no limit' option in the dropdown and decided against it. I guess it's useful in development when trying out pruning strategies, but it might surprise people unfamiliar with how it works and freeze their apps. In development, we can just remove the limit when we want to try things out. ------------- Commit messages: - 7002: update max graph nodes dropdown values - 7002: change max nodes graph view dropdown label - 7002: fix spotbugs format string warning - 7002: change display for no data in graph view - 7002: configure max nodes from toolbar dropdown - 7002: display message when graph is empty or too large Changes: https://git.openjdk.java.net/jmc/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=193&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7002 Stats: 125 lines in 2 files changed: 114 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jmc/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/193/head:pull/193 PR: https://git.openjdk.java.net/jmc/pull/193 From hirt at openjdk.java.net Tue Jan 12 11:35:04 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 11:35:04 GMT Subject: RFR: 7002: Too large graphs will freeze JMC In-Reply-To: References: Message-ID: <9kq8qS3YjI7OPYaqW4X-rWfq5jjGxWyWU31xw5vvTo8=.0dc34cce-0e74-447a-b4d9-a8ddba131596@github.com> On Sun, 10 Jan 2021 18:17:42 GMT, Alex Ciminian wrote: > This PR adds a control to limit the maximum number of nodes that can be rendered in the JMC graph view. > > At the moment, rendering very large graphs makes the application unresponsive so we want to guard against this by setting a limit on the maximum number of nodes that will be rendered. When this limit is exceeded, we don't try to render our `StacktraceGraphModel` into a graphiz dot string and instead we generate a simple dot string with one node and a message informing the user that they are trying to render too many nodes. > > I spent a couple of hours fighting with SWT to get the basic dropdown functionality working in the component toolbar. I took some inspiration from the FlameView component's toolbar actions and I found some (not great) examples with Google. I'm happy to use other components - this seemed to be the simplest from what I found. Please let me know if there's anything better. ?? > > --- > > ![Screenshot 2021-01-10 at 18 14 39](https://user-images.githubusercontent.com/348973/104131749-4987a100-5370-11eb-8ae1-b9ee8064921f.png) > > ![Screenshot 2021-01-10 at 18 15 00](https://user-images.githubusercontent.com/348973/104131756-5c01da80-5370-11eb-9fe3-67e357d0fa00.png) > > We will also display a similar message when the graph model has no information (no nodes): > > ![Screenshot 2021-01-10 at 18 14 20](https://user-images.githubusercontent.com/348973/104131741-3c6ab200-5370-11eb-8d6f-1901371ab21f.png) > > --- > > Other things we've considered: > > - ~add an icon instead of the text in the toolbar~ - we'll leave the text label for now > - ~create text labels instead of the hardcoded strings I'm using now~ - we decided not to do localisation while this view is experimental > - I was on the fence about adding a 'no limit' option in the dropdown and decided against it. I guess it's useful in development when trying out pruning strategies, but it might surprise people unfamiliar with how it works and freeze their apps. In development, we can just remove the limit when we want to try things out. Looks good to me. I can try my hand at an icon. :) ------------- PR: https://git.openjdk.java.net/jmc/pull/193 From hirt at openjdk.java.net Tue Jan 12 11:35:04 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 11:35:04 GMT Subject: RFR: 7002: Too large graphs will freeze JMC In-Reply-To: <9kq8qS3YjI7OPYaqW4X-rWfq5jjGxWyWU31xw5vvTo8=.0dc34cce-0e74-447a-b4d9-a8ddba131596@github.com> References: <9kq8qS3YjI7OPYaqW4X-rWfq5jjGxWyWU31xw5vvTo8=.0dc34cce-0e74-447a-b4d9-a8ddba131596@github.com> Message-ID: On Sun, 10 Jan 2021 18:41:52 GMT, Marcus Hirt wrote: >> This PR adds a control to limit the maximum number of nodes that can be rendered in the JMC graph view. >> >> At the moment, rendering very large graphs makes the application unresponsive so we want to guard against this by setting a limit on the maximum number of nodes that will be rendered. When this limit is exceeded, we don't try to render our `StacktraceGraphModel` into a graphiz dot string and instead we generate a simple dot string with one node and a message informing the user that they are trying to render too many nodes. >> >> I spent a couple of hours fighting with SWT to get the basic dropdown functionality working in the component toolbar. I took some inspiration from the FlameView component's toolbar actions and I found some (not great) examples with Google. I'm happy to use other components - this seemed to be the simplest from what I found. Please let me know if there's anything better. ?? >> >> --- >> >> ![Screenshot 2021-01-10 at 18 14 39](https://user-images.githubusercontent.com/348973/104131749-4987a100-5370-11eb-8ae1-b9ee8064921f.png) >> >> ![Screenshot 2021-01-10 at 18 15 00](https://user-images.githubusercontent.com/348973/104131756-5c01da80-5370-11eb-9fe3-67e357d0fa00.png) >> >> We will also display a similar message when the graph model has no information (no nodes): >> >> ![Screenshot 2021-01-10 at 18 14 20](https://user-images.githubusercontent.com/348973/104131741-3c6ab200-5370-11eb-8d6f-1901371ab21f.png) >> >> --- >> >> Other things we've considered: >> >> - ~add an icon instead of the text in the toolbar~ - we'll leave the text label for now >> - ~create text labels instead of the hardcoded strings I'm using now~ - we decided not to do localisation while this view is experimental >> - I was on the fence about adding a 'no limit' option in the dropdown and decided against it. I guess it's useful in development when trying out pruning strategies, but it might surprise people unfamiliar with how it works and freeze their apps. In development, we can just remove the limit when we want to try things out. > > Looks good to me. I can try my hand at an icon. :) I think, perhaps a less on-the-nose-message for when there is no data would be nice. :) ------------- PR: https://git.openjdk.java.net/jmc/pull/193 From github.com+348973+cimi at openjdk.java.net Tue Jan 12 11:35:04 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 12 Jan 2021 11:35:04 GMT Subject: RFR: 7002: Too large graphs will freeze JMC In-Reply-To: References: <9kq8qS3YjI7OPYaqW4X-rWfq5jjGxWyWU31xw5vvTo8=.0dc34cce-0e74-447a-b4d9-a8ddba131596@github.com> Message-ID: <2qClZP74PiUunjT-mslAHCZTnaAMpu8L2MiYngwGxAI=.6ab17488-04c1-49f3-be37-de5156bec587@github.com> On Sun, 10 Jan 2021 18:43:47 GMT, Marcus Hirt wrote: >> Looks good to me. I can try my hand at an icon. :) > > I think, perhaps a less on-the-nose-message for when there is no data would be nice. :) I've changed the empty graph display to a simple label with a small font size. It seems to work ok and doesn't require other changes to the html or javascript ?? With this method, it could become very small if the graph view window size is small. Nevertheless, I prefer this way since hacking html/css without touching the javascript is complicated: the SVG fills the page even when we have empty graphs, so I can't just overlay the graph over the text. It looks like this now: Screenshot 2021-01-10 at 20 10 26 ------------- PR: https://git.openjdk.java.net/jmc/pull/193 From hirt at openjdk.java.net Tue Jan 12 14:53:57 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 14:53:57 GMT Subject: RFR: 7081: Update Copyright year to 2021, Validate and update license attributes In-Reply-To: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: On Thu, 7 Jan 2021 04:39:06 GMT, Guru Hb wrote: > Updated Copyright year to 2021 for below > 1. License show in "About" dialog > 2. Copyright year in License file > 3. Update site landing page > 4. added a helper script which can be used to update copyright year for modified git files. Pinged @guruhb about not hardcoding the from year in the copyright updating script - he'll said he'll fix before pushing. ------------- PR: https://git.openjdk.java.net/jmc/pull/190 From schaturvedi at openjdk.java.net Tue Jan 12 15:36:02 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 12 Jan 2021 15:36:02 GMT Subject: RFR: 6859: Correction in JMC welcome page Message-ID: Updated titles on update sites pages. ------------- Commit messages: - 6859: Correction in JMC welcome page Changes: https://git.openjdk.java.net/jmc/pull/196/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=196&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-6859 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jmc/pull/196.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/196/head:pull/196 PR: https://git.openjdk.java.net/jmc/pull/196 From hdafgard at openjdk.java.net Tue Jan 12 15:34:00 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Tue, 12 Jan 2021 15:34:00 GMT Subject: Integrated: 7076: Rules and Analysis code has exceptions during uitests In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 16:58:58 GMT, Henrik Dafg?rd wrote: > Fixes exceptions encountered during uitests due to empty grouping arrays. This pull request has now been integrated. Changeset: 1e7cd870 Author: Henrik Dafg?rd URL: https://git.openjdk.java.net/jmc/commit/1e7cd870 Stats: 36 lines in 2 files changed: 6 ins; 0 del; 30 mod 7076: Rules and Analysis code has exceptions during uitests Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/189 From hdafgard at openjdk.java.net Tue Jan 12 15:35:57 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Tue, 12 Jan 2021 15:35:57 GMT Subject: Integrated: 7079: Numeric values in automated analysis summary is not resolved In-Reply-To: References: Message-ID: On Sat, 9 Jan 2021 18:22:46 GMT, Henrik Dafg?rd wrote: > JFX Pulse Duration rule does not register result attributes properly, this causes templating to fail. This pull request has now been integrated. Changeset: 549cba0d Author: Henrik Dafg?rd URL: https://git.openjdk.java.net/jmc/commit/549cba0d Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 7079: Numeric values in automated analysis summary is not resolved Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/191 From hirt at openjdk.java.net Tue Jan 12 15:38:55 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 15:38:55 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v14] In-Reply-To: References: Message-ID: <6HwDK00rYviwezWP5SrmX57ZGdZPWO0PYin4DnOJgvU=.fa0efc0a-3125-4382-b28a-c3a74297d151@github.com> On Mon, 11 Jan 2021 19:10:55 GMT, Marcus Hirt wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6946: type correction, and error message improvement > > Changes requested by hirt (Lead). Perhaps the text when the agent has been built should be: Agent library build complete. You can now run an example with the agent using --runAgentExample, or use the agent with your own applications. See agent/README.md for more information. (Is currently: You can run the agent, see agent/README.md) ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Tue Jan 12 15:50:00 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 15:50:00 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v14] In-Reply-To: <6HwDK00rYviwezWP5SrmX57ZGdZPWO0PYin4DnOJgvU=.fa0efc0a-3125-4382-b28a-c3a74297d151@github.com> References: <6HwDK00rYviwezWP5SrmX57ZGdZPWO0PYin4DnOJgvU=.fa0efc0a-3125-4382-b28a-c3a74297d151@github.com> Message-ID: On Tue, 12 Jan 2021 15:36:38 GMT, Marcus Hirt wrote: >> Changes requested by hirt (Lead). > > Perhaps the text when the agent has been built should be: > Agent library build complete. You can now run an example with the agent using --runAgentExample, or use the agent with your own applications. See agent/README.md for more information. > > (Is currently: You can run the agent, see agent/README.md) In the windows batch file, the variables should probably be declared in terms of each other: set PATH_TO_AGENT_JAR=%cd%\agent\target\org.openjdk.jmc.agent-1.0.0-SNAPSHOT.jar set PATH_TO_AGENT_TARGET_DIR=%cd%\agent\target Also, cp is wrong (using = instead of cp delimiter), and path delimiter is wrong for file specifications. Should probably be: call java --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -XX:+FlightRecorder -javaagent:"%PATH_TO_AGENT_JAR%"="%PATH_TO_AGENT_TARGET_DIR%"/test-classes/org/openjdk/jmc/agent/test/jfrprobes_template.xml -cp "%PATH_TO_AGENT_JAR%"="%PATH_TO_AGENT_TARGET_DIR%"/test-classes/ org.openjdk.jmc.agent.converters.test.InstrumentMeConverter ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Tue Jan 12 15:49:58 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 15:49:58 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> References: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> Message-ID: <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> On Tue, 12 Jan 2021 10:17:09 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6946: win os update See previous comments. ------------- Changes requested by hirt (Lead). PR: https://git.openjdk.java.net/jmc/pull/183 From schaturvedi at openjdk.java.net Tue Jan 12 15:51:55 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 12 Jan 2021 15:51:55 GMT Subject: Withdrawn: 6859: Correction in JMC welcome page In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 15:31:39 GMT, Suchita Chaturvedi wrote: > Updated titles on update sites pages. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jmc/pull/196 From hirt at openjdk.java.net Tue Jan 12 15:58:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 15:58:54 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> References: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> Message-ID: On Tue, 12 Jan 2021 15:47:19 GMT, Marcus Hirt wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6946: win os update > > See previous comments. I get the following when running the script on Mac when using _JAVA_OPTIONS: try to execute an agent example ./build.sh: line 231: printf: Picked up _JAVA_OPTIONS: : invalid number Java Version:0 Perhaps just default to whatever can be found without validation if it fails to parse the version? ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From schaturvedi at openjdk.java.net Tue Jan 12 16:22:03 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 12 Jan 2021 16:22:03 GMT Subject: RFR: 6859: Correction in JMC welcome page Message-ID: Updated some titles for update sites and made it specific to Open source. ------------- Commit messages: - 6859: Correction in JMC welcome page Changes: https://git.openjdk.java.net/jmc/pull/197/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=197&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-6859 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jmc/pull/197.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/197/head:pull/197 PR: https://git.openjdk.java.net/jmc/pull/197 From mwengner at openjdk.java.net Tue Jan 12 16:57:12 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 12 Jan 2021 16:57:12 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v17] In-Reply-To: References: Message-ID: <4JZcnW8lXpsgQGLIdBVwoPxCYBum9VjVrUtqC49xdGI=.11800610-1a33-4a1b-91d4-466dc4d1312d@github.com> > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: text update ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/88bac6ea..01220b39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=15-16 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Tue Jan 12 17:03:14 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 12 Jan 2021 17:03:14 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v18] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: win correction ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/01220b39..4c7d1603 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=16-17 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From ghb at openjdk.java.net Tue Jan 12 17:10:19 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 12 Jan 2021 17:10:19 GMT Subject: RFR: 7081: Update Copyright year to 2021, Validate and update license attributes [v4] In-Reply-To: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: > Updated Copyright year to 2021 for below > 1. License show in "About" dialog > 2. Copyright year in License file > 3. Update site landing page > 4. added a helper script which can be used to update copyright year for modified git files. Guru Hb has updated the pull request incrementally with one additional commit since the last revision: Removed hardcoded year value ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/190/files - new: https://git.openjdk.java.net/jmc/pull/190/files/96901546..b5a9536c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=190&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=190&range=02-03 Stats: 16 lines in 1 file changed: 13 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/190/head:pull/190 PR: https://git.openjdk.java.net/jmc/pull/190 From hirt at openjdk.java.net Tue Jan 12 17:13:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 17:13:54 GMT Subject: RFR: 6859: Correction in JMC welcome page In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 16:13:24 GMT, Suchita Chaturvedi wrote: > Updated some titles for update sites and made it specific to Open source. application/org.openjdk.jmc.updatesite.ide/src/main/resources/index.html line 9: > 7: > 8: > 9: Eclipse: OpenJDK Plug-ins for JDK Mission Control The plug-ins is really the Eclipse plug-ins for running JDK Mission Control in Eclipse + optional extra plug-ins. So, the most important quality of the plug-ins, is that it's JDK Mission Control for Eclipse. The second most important one is that it contains optional plug-ins for the plug-in version of JDK Mission Control. If you want to capture both, I guess saying "JDK Mission Control plug-ins for Eclipse" would kinda capture both. I understand that you want to separate the Oracle plug-ins from the OpenJDK ones, but since OpenJDK is assumed as the default, I don't think that has to be stated. ------------- PR: https://git.openjdk.java.net/jmc/pull/197 From ghb at openjdk.java.net Tue Jan 12 17:10:19 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 12 Jan 2021 17:10:19 GMT Subject: RFR: 7081: Update Copyright year to 2021, Validate and update license attributes In-Reply-To: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: <5Uh7UZE6zUjzrZOKVvgU2wD-5rIi_HKE-qKe3YfpN8c=.1c04bd49-1b05-4dbc-bf27-61b45194f4dd@github.com> On Thu, 7 Jan 2021 04:39:06 GMT, Guru Hb wrote: > Updated Copyright year to 2021 for below > 1. License show in "About" dialog > 2. Copyright year in License file > 3. Update site landing page > 4. added a helper script which can be used to update copyright year for modified git files. > Pinged @guruhb about not hardcoding the from year in the copyright updating script - he'll said he'll fix before pushing. Modified the script + also fixed to work with bash and Non Mac terminal. ------------- PR: https://git.openjdk.java.net/jmc/pull/190 From hirt at openjdk.java.net Tue Jan 12 17:17:58 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 17:17:58 GMT Subject: RFR: 7081: Update Copyright year to 2021, Validate and update license attributes [v4] In-Reply-To: References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: On Tue, 12 Jan 2021 17:10:19 GMT, Guru Hb wrote: >> Updated Copyright year to 2021 for below >> 1. License show in "About" dialog >> 2. Copyright year in License file >> 3. Update site landing page >> 4. added a helper script which can be used to update copyright year for modified git files. > > Guru Hb has updated the pull request incrementally with one additional commit since the last revision: > > Removed hardcoded year value Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/190 From jbachorik at openjdk.java.net Tue Jan 12 17:22:24 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 12 Jan 2021 17:22:24 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v5] In-Reply-To: References: Message-ID: > This is an initial implementation of JFR binary format writer in Java. > The writer can write valid JFR files according to what is expected by the JMC JFR format reader. > The writer is not complete in terms of performance and event settings support but in spite of that it is fairly usable. > > The typical flow is: > > 1. Obtain a new instance of Recording > java > Recording r = new Recording() > 2. Register custom types for that recording > java > r.registerType(name, structure) > 3. Get a new Chunk instance > java > Chunk c = r.newChunk() > 4. Write event values > java > c.writeEvent(eventValue) > 5. Finish the chunk and get the binary data > java > byte[] data = c.finish() > > > For more complex usage check [ChunkComplexTest.java](https://github.com/openjdk/jmc/blob/4c2dd1407f462feae40b795d3a4c6d75544b4e82/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java). Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/84/files - new: https://git.openjdk.java.net/jmc/pull/84/files/69e1e028..bf689bad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=03-04 Stats: 35 lines in 23 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jmc/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/84/head:pull/84 PR: https://git.openjdk.java.net/jmc/pull/84 From ghb at openjdk.java.net Tue Jan 12 17:34:54 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 12 Jan 2021 17:34:54 GMT Subject: Integrated: 7081: Update Copyright year to 2021, Validate and update license attributes In-Reply-To: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> References: <_BHUAqcxNcx5ImlZcxxjXO91NDFf3M6uZXW6Mkb9Jx8=.eb002c1a-0104-4793-9408-6b39002d122e@github.com> Message-ID: <2M_Kb7x-Dr_aSoXHjuK5tyfpIxOlLROcrOVZ-VwayFw=.f2f3a263-86f9-4007-895c-be34ef7eca60@github.com> On Thu, 7 Jan 2021 04:39:06 GMT, Guru Hb wrote: > Updated Copyright year to 2021 for below > 1. License show in "About" dialog > 2. Copyright year in License file > 3. Update site landing page > 4. added a helper script which can be used to update copyright year for modified git files. This pull request has now been integrated. Changeset: deb32e78 Author: Guru Hb URL: https://git.openjdk.java.net/jmc/commit/deb32e78 Stats: 3790 lines in 314 files changed: 1757 ins; 1074 del; 959 mod 7081: Update Copyright year to 2021, Validate and update license attributes Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/190 From schaturvedi at openjdk.java.net Tue Jan 12 18:54:00 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 12 Jan 2021 18:54:00 GMT Subject: RFR: 6859: Correction in JMC welcome page In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 17:10:45 GMT, Marcus Hirt wrote: >> Updated some titles for update sites and made it specific to Open source. > > application/org.openjdk.jmc.updatesite.ide/src/main/resources/index.html line 9: > >> 7: >> 8: >> 9: Eclipse: OpenJDK Plug-ins for JDK Mission Control > > The plug-ins is really the Eclipse plug-ins for running JDK Mission Control in Eclipse + optional extra plug-ins. So, the most important quality of the plug-ins, is that it's JDK Mission Control for Eclipse. The second most important one is that it contains optional plug-ins for the plug-in version of JDK Mission Control. If you want to capture both, I guess saying "JDK Mission Control plug-ins for Eclipse" would kinda capture both. > > I understand that you want to separate the Oracle plug-ins from the OpenJDK ones, but since OpenJDK is assumed as the default, I don't think that has to be stated. Do you suggest any other title Or should I keep it as it is? Yes you are right the intent is to differentiate Oracle specific update sites. ------------- PR: https://git.openjdk.java.net/jmc/pull/197 From mwengner at openjdk.java.net Tue Jan 12 18:59:54 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 12 Jan 2021 18:59:54 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: References: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> Message-ID: On Tue, 12 Jan 2021 15:56:25 GMT, Marcus Hirt wrote: >> See previous comments. > > I get the following when running the script on Mac when using _JAVA_OPTIONS: > try to execute an agent example > ./build.sh: line 231: printf: Picked up _JAVA_OPTIONS: : invalid number > Java Version:0 > > Perhaps just default to whatever can be found without validation if it fails to parse the version? this is good question about "java:0", but which kind of version you will choose, arguments valid for 13 and higher ? ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Tue Jan 12 19:12:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 19:12:54 GMT Subject: RFR: 6859: Correction in JMC welcome page In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 18:51:27 GMT, Suchita Chaturvedi wrote: >> application/org.openjdk.jmc.updatesite.ide/src/main/resources/index.html line 9: >> >>> 7: >>> 8: >>> 9: Eclipse: OpenJDK Plug-ins for JDK Mission Control >> >> The plug-ins is really the Eclipse plug-ins for running JDK Mission Control in Eclipse + optional extra plug-ins. So, the most important quality of the plug-ins, is that it's JDK Mission Control for Eclipse. The second most important one is that it contains optional plug-ins for the plug-in version of JDK Mission Control. If you want to capture both, I guess saying "JDK Mission Control plug-ins for Eclipse" would kinda capture both. >> >> I understand that you want to separate the Oracle plug-ins from the OpenJDK ones, but since OpenJDK is assumed as the default, I don't think that has to be stated. > > Do you suggest any other title Or should I keep it as it is? > > Yes you are right the intent is to differentiate Oracle specific update sites. Then I think "JDK Mission Control Plug-ins for Eclipse". These are the default plug-ins, and don't need to be qualified. The Oracle ones would differ by stating that they are the Oracle ones. :) ------------- PR: https://git.openjdk.java.net/jmc/pull/197 From hirt at openjdk.java.net Tue Jan 12 20:01:57 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 20:01:57 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: References: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> Message-ID: On Tue, 12 Jan 2021 18:57:11 GMT, Miroslav Wengner wrote: >> I get the following when running the script on Mac when using _JAVA_OPTIONS: >> try to execute an agent example >> ./build.sh: line 231: printf: Picked up _JAVA_OPTIONS: : invalid number >> Java Version:0 >> >> Perhaps just default to whatever can be found without validation if it fails to parse the version? > > this is good question about "java:0", but which kind of version you will choose, arguments valid for 13 and higher ? java:0 is simply because the parser assumes there will be nothing before the version output. But people use things like _JAVA_OPTIONS, which may cause other output in between. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Tue Jan 12 20:01:58 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 20:01:58 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: References: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> Message-ID: On Tue, 12 Jan 2021 19:57:37 GMT, Marcus Hirt wrote: >> this is good question about "java:0", but which kind of version you will choose, arguments valid for 13 and higher ? > > java:0 is simply because the parser assumes there will be nothing before the version output. But people use things like _JAVA_OPTIONS, which may cause other output in between. So, I guess the solution is to either not bother with version checks, or to accept that sometimes the version can't be parsed properly, detect it, possibly warn, and then attempt everything no-matter what. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From schaturvedi at openjdk.java.net Tue Jan 12 20:03:16 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 12 Jan 2021 20:03:16 GMT Subject: RFR: 6859: Correction in JMC welcome page [v2] In-Reply-To: References: Message-ID: > Updated some titles for update sites and made it specific to Open source. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Updated title as per review comments ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/197/files - new: https://git.openjdk.java.net/jmc/pull/197/files/0113da6b..56bcab95 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=197&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=197&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/197.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/197/head:pull/197 PR: https://git.openjdk.java.net/jmc/pull/197 From hirt at openjdk.java.net Tue Jan 12 20:04:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 12 Jan 2021 20:04:54 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: References: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> Message-ID: On Tue, 12 Jan 2021 19:59:27 GMT, Marcus Hirt wrote: >> java:0 is simply because the parser assumes there will be nothing before the version output. But people use things like _JAVA_OPTIONS, which may cause other output in between. > > So, I guess the solution is to either not bother with version checks, or to accept that sometimes the version can't be parsed properly, detect it, possibly warn, and then attempt everything no-matter what. Try this: >export _JAVA_OPTIONS= >./build.sh --runAgentExample ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Tue Jan 12 21:58:34 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 12 Jan 2021 21:58:34 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v19] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: java version not recognized ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/4c7d1603..3e73f809 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=17-18 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Tue Jan 12 21:58:34 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 12 Jan 2021 21:58:34 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v16] In-Reply-To: References: <6QAKqE-wmXPe3JtcFcNF3oCkBMVTqoGKu8FJ-4K4Y48=.4c4e71d0-8435-4b80-9fe9-b16dd97bb7f9@github.com> <3vVlcilnrublNj9LrNM2Y5jyV69Mlzouz55UM7bIO2Q=.176a98b2-3d0e-436b-b0f4-9d4484ea8d51@github.com> Message-ID: On Tue, 12 Jan 2021 20:02:03 GMT, Marcus Hirt wrote: >> So, I guess the solution is to either not bother with version checks, or to accept that sometimes the version can't be parsed properly, detect it, possibly warn, and then attempt everything no-matter what. > > Try this: >>export _JAVA_OPTIONS= >>./build.sh --runAgentExample I've corrected unrecognized java version ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Wed Jan 13 12:59:14 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 13 Jan 2021 12:59:14 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v19] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 21:58:34 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6946: java version not recognized Changes requested by hirt (Lead). build.sh line 215: > 213: local agentExampleClass=$1 > 214: if [[ -z "${agentExampleClass}" ]]; then > 215: err_log "error: try to run undefiend agent class, empty class" typo undefiend -> undefined. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 13 15:02:16 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 13 Jan 2021 15:02:16 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v20] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: corrected typo ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/3e73f809..97c3951d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From hirt at openjdk.java.net Wed Jan 13 16:16:03 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 13 Jan 2021 16:16:03 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v5] In-Reply-To: References: Message-ID: <_nRxAh0owvhQ9n3uMa9yxBMCStBPCdxnjbx1S5YP4jE=.7dc3a021-4240-4865-8a6c-a5fc8d2f1d64@github.com> On Tue, 1 Dec 2020 17:20:56 GMT, Marcus Hirt wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > Changes requested by hirt (Lead). The files now need 2021 added to the copyright notices. ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From hirt at openjdk.java.net Wed Jan 13 16:24:03 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 13 Jan 2021 16:24:03 GMT Subject: RFR: 7002: Too large graphs will freeze JMC In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 18:17:42 GMT, Alex Ciminian wrote: > This PR adds a control to limit the maximum number of nodes that can be rendered in the JMC graph view. > > At the moment, rendering very large graphs makes the application unresponsive so we want to guard against this by setting a limit on the maximum number of nodes that will be rendered. When this limit is exceeded, we don't try to render our `StacktraceGraphModel` into a graphiz dot string and instead we generate a simple dot string with one node and a message informing the user that they are trying to render too many nodes. > > I spent a couple of hours fighting with SWT to get the basic dropdown functionality working in the component toolbar. I took some inspiration from the FlameView component's toolbar actions and I found some (not great) examples with Google. I'm happy to use other components - this seemed to be the simplest from what I found. Please let me know if there's anything better. ?? > > --- > > ![Screenshot 2021-01-10 at 18 14 39](https://user-images.githubusercontent.com/348973/104131749-4987a100-5370-11eb-8ae1-b9ee8064921f.png) > > ![Screenshot 2021-01-10 at 18 15 00](https://user-images.githubusercontent.com/348973/104131756-5c01da80-5370-11eb-9fe3-67e357d0fa00.png) > > We will also display a similar message when the graph model has no information (no nodes): > > ![Screenshot 2021-01-10 at 18 14 20](https://user-images.githubusercontent.com/348973/104131741-3c6ab200-5370-11eb-8d6f-1901371ab21f.png) > > --- > > Other things we've considered: > > - ~add an icon instead of the text in the toolbar~ - we'll leave the text label for now > - ~create text labels instead of the hardcoded strings I'm using now~ - we decided not to do localisation while this view is experimental > - I was on the fence about adding a 'no limit' option in the dropdown and decided against it. I guess it's useful in development when trying out pruning strategies, but it might surprise people unfamiliar with how it works and freeze their apps. In development, we can just remove the limit when we want to try things out. Marked as reviewed by hirt (Lead). application/org.openjdk.jmc.flightrecorder.graphview/src/main/java/org/openjdk/jmc/flightrecorder/ext/graphview/graph/DotGenerator.java line 269: > 267: String graphName = getConf(configuration, ConfigurationKey.Name, DEFAULT_NAME); > 268: builder.append(String.format("digraph \"%s\" {%n", graphName)); > 269: int nodeCount = model.getNodes().size(); I'm not sure I like the idea of special messages like this being passed as a "special" di-graph. I'd prefer this special check to be done outside of the toDot serializer, but I think it's okay since the graph view is sort of early access. It's certainly not worth holding up the release for. ------------- PR: https://git.openjdk.java.net/jmc/pull/193 From aptmac at openjdk.java.net Wed Jan 13 16:48:09 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 13 Jan 2021 16:48:09 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v20] In-Reply-To: References: Message-ID: <_xoIPWga3xACihhw_yS_QoMkxiTyvtEGxtactHaCW8o=.51540698-aaa8-4517-b1d4-957b207468b5@github.com> On Wed, 13 Jan 2021 15:02:16 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6946: corrected typo Just a couple of minor nits, the functionality seems fine to me. build.sh line 83: > 81: printf " \t%s\t%s\n" "--test" "to run the tests" > 82: printf " \t%s\t%s\n" "--testUi" "to run the tests including UI tests" > 83: printf " \t%s\t%s\n" "--installCore" "install JMC core" If trying to keep consistency, the `--installCore` is missing the "to" in it's description; it has it in the .bat file though build.sh line 88: > 86: printf " \t%s\t%s\n" "--clean" "to run maven clean" > 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" > 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent 'InstrumentMe' example, once it was packaged" For `--run`, `--runAgentExample`, and `--runAgentConverterExample`, I think it reads better for the description to say "once it _is_ packaged" rather than "was" ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 13 17:16:17 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 13 Jan 2021 17:16:17 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v21] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: - 6946: missing letter - 6946: text improvements ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/97c3951d..a4027714 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=19-20 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 13 17:16:19 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 13 Jan 2021 17:16:19 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v20] In-Reply-To: <_xoIPWga3xACihhw_yS_QoMkxiTyvtEGxtactHaCW8o=.51540698-aaa8-4517-b1d4-957b207468b5@github.com> References: <_xoIPWga3xACihhw_yS_QoMkxiTyvtEGxtactHaCW8o=.51540698-aaa8-4517-b1d4-957b207468b5@github.com> Message-ID: On Wed, 13 Jan 2021 16:44:38 GMT, Alex Macdonald wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6946: corrected typo > > build.sh line 88: > >> 86: printf " \t%s\t%s\n" "--clean" "to run maven clean" >> 87: printf " \t%s\t%s\n" "--run" "to run JMC once it was packaged" >> 88: printf " \t%s\t%s\n" "--runAgentExample" "to run Agent 'InstrumentMe' example, once it was packaged" > > For `--run`, `--runAgentExample`, and `--runAgentConverterExample`, I think it reads better for the description to say "once it _is_ packaged" rather than "was" ok, corrected > build.sh line 83: > >> 81: printf " \t%s\t%s\n" "--test" "to run the tests" >> 82: printf " \t%s\t%s\n" "--testUi" "to run the tests including UI tests" >> 83: printf " \t%s\t%s\n" "--installCore" "install JMC core" > > If trying to keep consistency, the `--installCore` is missing the "to" in it's description; it has it in the .bat file though corrected ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From jbachorik at openjdk.java.net Wed Jan 13 17:47:25 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 13 Jan 2021 17:47:25 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v6] In-Reply-To: References: Message-ID: > This is an initial implementation of JFR binary format writer in Java. > The writer can write valid JFR files according to what is expected by the JMC JFR format reader. > The writer is not complete in terms of performance and event settings support but in spite of that it is fairly usable. > > The typical flow is: > > 1. Obtain a new instance of Recording > java > Recording r = new Recording() > 2. Register custom types for that recording > java > r.registerType(name, structure) > 3. Get a new Chunk instance > java > Chunk c = r.newChunk() > 4. Write event values > java > c.writeEvent(eventValue) > 5. Finish the chunk and get the binary data > java > byte[] data = c.finish() > > > For more complex usage check [ChunkComplexTest.java](https://github.com/openjdk/jmc/blob/4c2dd1407f462feae40b795d3a4c6d75544b4e82/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java). Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/84/files - new: https://git.openjdk.java.net/jmc/pull/84/files/bf689bad..931cac11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=04-05 Stats: 125 lines in 63 files changed: 0 ins; 0 del; 125 mod Patch: https://git.openjdk.java.net/jmc/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/84/head:pull/84 PR: https://git.openjdk.java.net/jmc/pull/84 From jbachorik at openjdk.java.net Wed Jan 13 17:47:25 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 13 Jan 2021 17:47:25 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v6] In-Reply-To: <_nRxAh0owvhQ9n3uMa9yxBMCStBPCdxnjbx1S5YP4jE=.7dc3a021-4240-4865-8a6c-a5fc8d2f1d64@github.com> References: <_nRxAh0owvhQ9n3uMa9yxBMCStBPCdxnjbx1S5YP4jE=.7dc3a021-4240-4865-8a6c-a5fc8d2f1d64@github.com> Message-ID: <_TSxL_EZgTrLsPogFfGMZXBQa2O84GTcGvyw7dTC-Xc=.b41f5b39-21ee-4cff-943d-9d8556a166e2@github.com> On Wed, 13 Jan 2021 16:12:55 GMT, Marcus Hirt wrote: >> Changes requested by hirt (Lead). > > The files now need 2021 added to the copyright notices. All affected files should have the copyright updated now ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From github.com+348973+cimi at openjdk.java.net Wed Jan 13 18:03:04 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Wed, 13 Jan 2021 18:03:04 GMT Subject: RFR: 7002: Too large graphs will freeze JMC In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 16:21:21 GMT, Marcus Hirt wrote: >> This PR adds a control to limit the maximum number of nodes that can be rendered in the JMC graph view. >> >> At the moment, rendering very large graphs makes the application unresponsive so we want to guard against this by setting a limit on the maximum number of nodes that will be rendered. When this limit is exceeded, we don't try to render our `StacktraceGraphModel` into a graphiz dot string and instead we generate a simple dot string with one node and a message informing the user that they are trying to render too many nodes. >> >> I spent a couple of hours fighting with SWT to get the basic dropdown functionality working in the component toolbar. I took some inspiration from the FlameView component's toolbar actions and I found some (not great) examples with Google. I'm happy to use other components - this seemed to be the simplest from what I found. Please let me know if there's anything better. ?? >> >> --- >> >> ![Screenshot 2021-01-10 at 18 14 39](https://user-images.githubusercontent.com/348973/104131749-4987a100-5370-11eb-8ae1-b9ee8064921f.png) >> >> ![Screenshot 2021-01-10 at 18 15 00](https://user-images.githubusercontent.com/348973/104131756-5c01da80-5370-11eb-9fe3-67e357d0fa00.png) >> >> We will also display a similar message when the graph model has no information (no nodes): >> >> ![Screenshot 2021-01-10 at 18 14 20](https://user-images.githubusercontent.com/348973/104131741-3c6ab200-5370-11eb-8d6f-1901371ab21f.png) >> >> --- >> >> Other things we've considered: >> >> - ~add an icon instead of the text in the toolbar~ - we'll leave the text label for now >> - ~create text labels instead of the hardcoded strings I'm using now~ - we decided not to do localisation while this view is experimental >> - I was on the fence about adding a 'no limit' option in the dropdown and decided against it. I guess it's useful in development when trying out pruning strategies, but it might surprise people unfamiliar with how it works and freeze their apps. In development, we can just remove the limit when we want to try things out. > > application/org.openjdk.jmc.flightrecorder.graphview/src/main/java/org/openjdk/jmc/flightrecorder/ext/graphview/graph/DotGenerator.java line 269: > >> 267: String graphName = getConf(configuration, ConfigurationKey.Name, DEFAULT_NAME); >> 268: builder.append(String.format("digraph \"%s\" {%n", graphName)); >> 269: int nodeCount = model.getNodes().size(); > > I'm not sure I like the idea of special messages like this being passed as a "special" di-graph. I'd prefer this special check to be done outside of the toDot serializer, but I think it's okay since the graph view is sort of early access. It's certainly not worth holding up the release for. Agreed, this is a slight abuse of the serialiser ?? but having it this way keeps the code simpler. We won't need to have special conditions before serialisation (we'd want to avoid if there are too many nodes), avoids adding extra behaviour in Java for passing messages and avoids adding functionality in the JS to do the toggle between displaying messages and showing the graph. Doing all this is not too difficult, but this way is simpler and doesn't introduce any new components. We also do a similar thing for the flame graph: we display 'No stacktrace information available' as a flame graph with one root frame. Related, doing the toggle with pure CSS (i.e. no JS) is not straightforward because graphviz resizes to cover the entire area. It might be possible to hack something in CSS that produces different display depending on the structure of the SVG generated - but given the state of the browser running inside our application, I don't think this is a good idea even if we get it working. ------------- PR: https://git.openjdk.java.net/jmc/pull/193 From aptmac at openjdk.java.net Wed Jan 13 20:11:03 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 13 Jan 2021 20:11:03 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v21] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 17:16:17 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: > > - 6946: missing letter > - 6946: text improvements I found a nifty dictionary vscode extension that pointed out a couple last ones, should be good after this. build.sh line 226: > 224: printf "%s\n" "try to execute an agent example" > 225: else > 226: err_log "unknown OS type: \"${OSTYPE}\". Please coheck package ${JMC_DIR}/agent README.MD" Almost there, on re-reading I found this one: "coheck" should probably be "check" build.sh line 153: > 151: printf "%s\n" "See agent/README.md for more information" > 152: else > 153: err_log "unknown OS type: \"${OSTYPE}\". Please coheck package in \"${JMC_DIR}/agent/target\"" "coheck" here as well should be "check" ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 13 20:31:20 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 13 Jan 2021 20:31:20 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v22] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6946: update ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/a4027714..cf9a0690 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=20-21 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 13 20:31:20 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 13 Jan 2021 20:31:20 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v21] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 20:07:54 GMT, Alex Macdonald wrote: >> Miroslav Wengner has updated the pull request incrementally with two additional commits since the last revision: >> >> - 6946: missing letter >> - 6946: text improvements > > I found a nifty dictionary vscode extension that pointed out a couple last ones, should be good after this. hopefully all typos corrected ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From jmatsuoka at openjdk.java.net Wed Jan 13 20:39:01 2021 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Wed, 13 Jan 2021 20:39:01 GMT Subject: RFR: 7008: Agent should properly support Class and Thread [v2] In-Reply-To: References: <94c0trvCPPx5Cwo__uJJ_uX_SFGmJy3JF4xVX8njSHU=.5dd45dc1-5daa-4d94-8e57-0535002e2d7d@github.com> Message-ID: On Sun, 10 Jan 2021 18:15:12 GMT, Marcus Hirt wrote: >> Also fixes various issues and tests. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Removing temporary workaround Looks good to me. ------------- Marked as reviewed by jmatsuoka (Committer). PR: https://git.openjdk.java.net/jmc/pull/192 From aptmac at openjdk.java.net Wed Jan 13 21:15:07 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 13 Jan 2021 21:15:07 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v22] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 20:31:20 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6946: update build.sh line 102: > 100: local timestamp=$1 > 101: startJetty $timestamp > 102: echo "$${timestamp} running tests" Ok, I think this should be the last thing (it wasn't a spelling typo so my dictionary didn't help me out here..), sorry for making you go back and forth here. There's an extra `$` before the timestamp. This results in something like: 16:00:37 jetty server up and running on pid 595959 595716{timestamp} running tests instead of something like: 16:01:20 jetty server up and running on pid 596437 20210113160105 running tests ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 13 21:27:17 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 13 Jan 2021 21:27:17 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v23] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6949: typo ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/183/files - new: https://git.openjdk.java.net/jmc/pull/183/files/cf9a0690..aa8263ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=183&range=21-22 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/183.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/183/head:pull/183 PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Wed Jan 13 21:27:18 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 13 Jan 2021 21:27:18 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v22] In-Reply-To: References: Message-ID: <3eSFhh4fWuV6LkjSwmTez5w75M8kqlIcba6NZF-USiU=.c3d3028f-8380-4bb4-86b9-cc154bf05704@github.com> On Wed, 13 Jan 2021 21:11:59 GMT, Alex Macdonald wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6946: update > > build.sh line 102: > >> 100: local timestamp=$1 >> 101: startJetty $timestamp >> 102: echo "$${timestamp} running tests" > > Ok, I think this should be the last thing (it wasn't a spelling typo so my dictionary didn't help me out here..), sorry for making you go back and forth here. > > There's an extra `$` before the timestamp. This results in something like: > > 16:00:37 jetty server up and running on pid 595959 > 595716{timestamp} running tests > instead of something like: > 16:01:20 jetty server up and running on pid 596437 > 20210113160105 running tests very nice!, I've not noticed it, corrected ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From github.com+348973+cimi at openjdk.java.net Wed Jan 13 22:02:04 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Wed, 13 Jan 2021 22:02:04 GMT Subject: Integrated: 7002: Too large graphs will freeze JMC In-Reply-To: References: Message-ID: On Sun, 10 Jan 2021 18:17:42 GMT, Alex Ciminian wrote: > This PR adds a control to limit the maximum number of nodes that can be rendered in the JMC graph view. > > At the moment, rendering very large graphs makes the application unresponsive so we want to guard against this by setting a limit on the maximum number of nodes that will be rendered. When this limit is exceeded, we don't try to render our `StacktraceGraphModel` into a graphiz dot string and instead we generate a simple dot string with one node and a message informing the user that they are trying to render too many nodes. > > I spent a couple of hours fighting with SWT to get the basic dropdown functionality working in the component toolbar. I took some inspiration from the FlameView component's toolbar actions and I found some (not great) examples with Google. I'm happy to use other components - this seemed to be the simplest from what I found. Please let me know if there's anything better. ?? > > --- > > ![Screenshot 2021-01-10 at 18 14 39](https://user-images.githubusercontent.com/348973/104131749-4987a100-5370-11eb-8ae1-b9ee8064921f.png) > > ![Screenshot 2021-01-10 at 18 15 00](https://user-images.githubusercontent.com/348973/104131756-5c01da80-5370-11eb-9fe3-67e357d0fa00.png) > > We will also display a similar message when the graph model has no information (no nodes): > > ![Screenshot 2021-01-10 at 18 14 20](https://user-images.githubusercontent.com/348973/104131741-3c6ab200-5370-11eb-8d6f-1901371ab21f.png) > > --- > > Other things we've considered: > > - ~add an icon instead of the text in the toolbar~ - we'll leave the text label for now > - ~create text labels instead of the hardcoded strings I'm using now~ - we decided not to do localisation while this view is experimental > - I was on the fence about adding a 'no limit' option in the dropdown and decided against it. I guess it's useful in development when trying out pruning strategies, but it might surprise people unfamiliar with how it works and freeze their apps. In development, we can just remove the limit when we want to try things out. This pull request has now been integrated. Changeset: b6fe7cac Author: Alex Ciminian Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/b6fe7cac Stats: 125 lines in 2 files changed: 114 ins; 0 del; 11 mod 7002: Too large graphs will freeze JMC Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/193 From hirt at openjdk.java.net Wed Jan 13 22:05:03 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 13 Jan 2021 22:05:03 GMT Subject: RFR: 7063: JfrThreadsPageTest (UI-test) fails In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 21:05:42 GMT, Alex Macdonald wrote: > Hi! This PR addresses JMC-7063 [[0]](https://bugs.openjdk.java.net/browse/JMC-7063), in which there are test failures when running uitests on the threads page. This test failure has also been brought up in JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077), which encompasses the larger problem of uitest failures in JMC 8. > > The problem here was the hardcoded time strings (do'h!). I had originally thought the problem was Jemmy being unable to find the time filter text boxes due to screen size limitations, but in reality Jemmy couldn't find the text boxes because we had hardcoded the time strings in the test class for verification purposes. A big thanks to Bipin for posting a video clip of the test failure to the JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077) issue report, I was able to see that Jemmy was struggling to find the text box with "08:06:19:489" because it was not the right time in his timezone! > > To address this, Jemmy will now lookup the text boxes using a "name" that is assigned to them when they are created. The unit tests will now use a simple date formatter to apply a time offset to the start and end times to verify behaviour in the UI instead of checking against a (probably) incorrect hardcoded time string. > > For quicker testing and reviewing, I've attached a patch diff (in txt format) that can be applied on top of this commit if you wish to only test the JfrThreadsPageTest. It simply prevents the non-flightrecorder.ui uitest modules from running, and gets rid of all other test classes: [only-jfrthreadspagetest.txt](https://github.com/openjdk/jmc/files/5797935/only-jfrthreadspagetest.txt) > > [0] https://bugs.openjdk.java.net/browse/JMC-7063 > [1] https://bugs.openjdk.java.net/browse/JMC-7077 You're good to go @aptmac. :) ------------- PR: https://git.openjdk.java.net/jmc/pull/195 From hirt at openjdk.java.net Wed Jan 13 22:08:04 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 13 Jan 2021 22:08:04 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v23] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:27:17 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6949: typo Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From aptmac at openjdk.java.net Wed Jan 13 22:14:05 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 13 Jan 2021 22:14:05 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script [v23] In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 21:27:17 GMT, Miroslav Wengner wrote: >> https://bugs.openjdk.java.net/browse/JMC-6946 >> added: >> - build.sh --packageAgent >> - build.sh --runAgentExample > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6949: typo lgtm, thanks for making the changes ------------- Marked as reviewed by aptmac (Committer). PR: https://git.openjdk.java.net/jmc/pull/183 From aptmac at openjdk.java.net Wed Jan 13 22:15:07 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 13 Jan 2021 22:15:07 GMT Subject: Integrated: 7063: JfrThreadsPageTest (UI-test) fails In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 21:05:42 GMT, Alex Macdonald wrote: > Hi! This PR addresses JMC-7063 [[0]](https://bugs.openjdk.java.net/browse/JMC-7063), in which there are test failures when running uitests on the threads page. This test failure has also been brought up in JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077), which encompasses the larger problem of uitest failures in JMC 8. > > The problem here was the hardcoded time strings (do'h!). I had originally thought the problem was Jemmy being unable to find the time filter text boxes due to screen size limitations, but in reality Jemmy couldn't find the text boxes because we had hardcoded the time strings in the test class for verification purposes. A big thanks to Bipin for posting a video clip of the test failure to the JMC-7077 [[1]](https://bugs.openjdk.java.net/browse/JMC-7077) issue report, I was able to see that Jemmy was struggling to find the text box with "08:06:19:489" because it was not the right time in his timezone! > > To address this, Jemmy will now lookup the text boxes using a "name" that is assigned to them when they are created. The unit tests will now use a simple date formatter to apply a time offset to the start and end times to verify behaviour in the UI instead of checking against a (probably) incorrect hardcoded time string. > > For quicker testing and reviewing, I've attached a patch diff (in txt format) that can be applied on top of this commit if you wish to only test the JfrThreadsPageTest. It simply prevents the non-flightrecorder.ui uitest modules from running, and gets rid of all other test classes: [only-jfrthreadspagetest.txt](https://github.com/openjdk/jmc/files/5797935/only-jfrthreadspagetest.txt) > > [0] https://bugs.openjdk.java.net/browse/JMC-7063 > [1] https://bugs.openjdk.java.net/browse/JMC-7077 This pull request has now been integrated. Changeset: 8d6fb1b7 Author: Alex Macdonald URL: https://git.openjdk.java.net/jmc/commit/8d6fb1b7 Stats: 57 lines in 2 files changed: 27 ins; 5 del; 25 mod 7063: JfrThreadsPageTest (UI-test) fails Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/195 From hirt at openjdk.java.net Thu Jan 14 00:05:07 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 14 Jan 2021 00:05:07 GMT Subject: RFR: 6946: There should be an option to build the agent in the build script In-Reply-To: References: Message-ID: <2bEea4JqKR8NDsZ_8-NZINsESBYak0tc32gkhDsHgAM=.0912a0c1-e3ce-461a-bac2-b20a5ba93bbd@github.com> On Mon, 14 Dec 2020 21:16:56 GMT, Miroslav Wengner wrote: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample You're good to go @mirage22. ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From mwengner at openjdk.java.net Thu Jan 14 07:22:04 2021 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Thu, 14 Jan 2021 07:22:04 GMT Subject: Integrated: 6946: There should be an option to build the agent in the build script In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 21:16:56 GMT, Miroslav Wengner wrote: > https://bugs.openjdk.java.net/browse/JMC-6946 > added: > - build.sh --packageAgent > - build.sh --runAgentExample This pull request has now been integrated. Changeset: 33e684b2 Author: Miroslav Wengner URL: https://git.openjdk.java.net/jmc/commit/33e684b2 Stats: 219 lines in 2 files changed: 187 ins; 15 del; 17 mod 6946: There should be an option to build the agent in the build script Reviewed-by: hirt, aptmac ------------- PR: https://git.openjdk.java.net/jmc/pull/183 From github.com+13893590+alexvangogen at openjdk.java.net Thu Jan 14 16:51:04 2021 From: github.com+13893590+alexvangogen at openjdk.java.net (Alexander Kuznetsov) Date: Thu, 14 Jan 2021 16:51:04 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v6] In-Reply-To: <_TSxL_EZgTrLsPogFfGMZXBQa2O84GTcGvyw7dTC-Xc=.b41f5b39-21ee-4cff-943d-9d8556a166e2@github.com> References: <_nRxAh0owvhQ9n3uMa9yxBMCStBPCdxnjbx1S5YP4jE=.7dc3a021-4240-4865-8a6c-a5fc8d2f1d64@github.com> <_TSxL_EZgTrLsPogFfGMZXBQa2O84GTcGvyw7dTC-Xc=.b41f5b39-21ee-4cff-943d-9d8556a166e2@github.com> Message-ID: On Wed, 13 Jan 2021 17:44:41 GMT, Jaroslav Bachorik wrote: >> The files now need 2021 added to the copyright notices. > > All affected files should have the copyright updated now Hi! We at JetBrains tried to use this writer to make tests for our JMC fork support. It works fine, however, it seems that almost every type is assumed to have constant pool (`org.openjdk.jmc.flightrecorder.writer.ConstantPool#writeValueType`). But that?s not always true; for example, async-profiler and JFR write `jdk.types.StackFrame` as-is, not referring to constant pool. It may lead to false-positive/negative outcomes when generated recordings are parsed well while the real ones make parser fail, or vice versa. Is it worth to extend API to control which types must have constant pool and which must not? What do you think? ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From hirt at openjdk.java.net Thu Jan 14 17:25:05 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 14 Jan 2021 17:25:05 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v6] In-Reply-To: References: <_nRxAh0owvhQ9n3uMa9yxBMCStBPCdxnjbx1S5YP4jE=.7dc3a021-4240-4865-8a6c-a5fc8d2f1d64@github.com> <_TSxL_EZgTrLsPogFfGMZXBQa2O84GTcGvyw7dTC-Xc=.b41f5b39-21ee-4cff-943d-9d8556a166e2@github.com> Message-ID: On Thu, 14 Jan 2021 16:48:38 GMT, Alexander Kuznetsov wrote: >> All affected files should have the copyright updated now > > Hi! We at JetBrains tried to use this writer to make tests for our JMC fork support. It works fine, however, it seems that almost every type is assumed to have constant pool (`org.openjdk.jmc.flightrecorder.writer.ConstantPool#writeValueType`). But that?s not always true; for example, async-profiler and JFR write `jdk.types.StackFrame` as-is, not referring to constant pool. It may lead to false-positive/negative outcomes when generated recordings are parsed well while the real ones make parser fail, or vice versa. > Is it worth to extend API to control which types must have constant pool and which must not? What do you think? Hi @AlexVanGogen! I think that is a great idea - that said, we're very close to the next source release. I was just about to approve this. How would you like the API to look/work? ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From hirt at openjdk.java.net Thu Jan 14 18:27:08 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 14 Jan 2021 18:27:08 GMT Subject: RFR: 6859: Correction in JMC welcome page [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 20:03:16 GMT, Suchita Chaturvedi wrote: >> Updated some titles for update sites and made it specific to Open source. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Updated title as per review comments Changes requested by hirt (Lead). application/org.openjdk.jmc.updatesite.rcp/src/main/resources/index.html line 7: > 5: > 6: > 7: JDK Mission Control: OpenJDK Plug-ins I think this change should be reverted. application/org.openjdk.jmc.updatesite.rcp/src/main/resources/index.html line 87: > 85: > 86: > 87:
JDK Mission Control: OpenJDK Plug-ins

I think this change should be reverted. ------------- PR: https://git.openjdk.java.net/jmc/pull/197 From schaturvedi at openjdk.java.net Thu Jan 14 20:55:20 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Thu, 14 Jan 2021 20:55:20 GMT Subject: RFR: 6859: Correction in JMC welcome page [v3] In-Reply-To: References: Message-ID: > Updated some titles for update sites and made it specific to Open source. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/197/files - new: https://git.openjdk.java.net/jmc/pull/197/files/56bcab95..7c7eed56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=197&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=197&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/197.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/197/head:pull/197 PR: https://git.openjdk.java.net/jmc/pull/197 From github.com+4610701+jpbempel at openjdk.java.net Fri Jan 15 10:18:10 2021 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Fri, 15 Jan 2021 10:18:10 GMT Subject: RFR: 4167: "Copy Column Headers" in stack trace view has no effect Message-ID: Add explicitly header column names as ILabelProvider does not provide this information ------------- Commit messages: - 4167: "Copy Column Headers" in stack trace view has no effect Changes: https://git.openjdk.java.net/jmc/pull/198/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=198&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-4167 Stats: 21 lines in 2 files changed: 16 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jmc/pull/198.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/198/head:pull/198 PR: https://git.openjdk.java.net/jmc/pull/198 From github.com+13893590+alexvangogen at openjdk.java.net Fri Jan 15 11:06:00 2021 From: github.com+13893590+alexvangogen at openjdk.java.net (Alexander Kuznetsov) Date: Fri, 15 Jan 2021 11:06:00 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v6] In-Reply-To: References: <_nRxAh0owvhQ9n3uMa9yxBMCStBPCdxnjbx1S5YP4jE=.7dc3a021-4240-4865-8a6c-a5fc8d2f1d64@github.com> <_TSxL_EZgTrLsPogFfGMZXBQa2O84GTcGvyw7dTC-Xc=.b41f5b39-21ee-4cff-943d-9d8556a166e2@github.com> Message-ID: On Thu, 14 Jan 2021 17:22:40 GMT, Marcus Hirt wrote: >> Hi! We at JetBrains tried to use this writer to make tests for our JMC fork support. It works fine, however, it seems that almost every type is assumed to have constant pool (`org.openjdk.jmc.flightrecorder.writer.ConstantPool#writeValueType`). But that?s not always true; for example, async-profiler and JFR write `jdk.types.StackFrame` as-is, not referring to constant pool. It may lead to false-positive/negative outcomes when generated recordings are parsed well while the real ones make parser fail, or vice versa. >> Is it worth to extend API to control which types must have constant pool and which must not? What do you think? > > Hi @AlexVanGogen! I think that is a great idea - that said, we're very close to the next source release. I was just about to approve this. How would you like the API to look/work? Since this PR is ready for approval, and what I've proposed is not critical, maybe it will be better to create a separate issue for that? What about API ? I don't know what is the best way to tell we want this type (not) to have a constant pool; currently investigating. Internally, I believe there are two places responsible ? `org.openjdk.jmc.flightrecorder.writer.MetadataImpl#createCustomType` (will the type have a constant pool) and aforementioned `org.openjdk.jmc.flightrecorder.writer.ConstantPool#writeValueType` (will the value be written as a reference to a constant pool). ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From jbachorik at openjdk.java.net Fri Jan 15 14:08:30 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 15 Jan 2021 14:08:30 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v7] In-Reply-To: References: Message-ID: > This is an initial implementation of JFR binary format writer in Java. > The writer can write valid JFR files according to what is expected by the JMC JFR format reader. > The writer is not complete in terms of performance and event settings support but in spite of that it is fairly usable. > > The typical flow is: > > 1. Obtain a new instance of Recording > java > Recording r = new Recording() > 2. Register custom types for that recording > java > r.registerType(name, structure) > 3. Get a new Chunk instance > java > Chunk c = r.newChunk() > 4. Write event values > java > c.writeEvent(eventValue) > 5. Finish the chunk and get the binary data > java > byte[] data = c.finish() > > > For more complex usage check [ChunkComplexTest.java](https://github.com/openjdk/jmc/blob/4c2dd1407f462feae40b795d3a4c6d75544b4e82/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java). Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Prevent lost writes due to delayed queue processing ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/84/files - new: https://git.openjdk.java.net/jmc/pull/84/files/931cac11..5cc91ce9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=84&range=05-06 Stats: 39 lines in 2 files changed: 27 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/84/head:pull/84 PR: https://git.openjdk.java.net/jmc/pull/84 From hirt at openjdk.java.net Fri Jan 15 15:05:11 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 15 Jan 2021 15:05:11 GMT Subject: RFR: 6859: Correction in JMC welcome page [v3] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 20:55:20 GMT, Suchita Chaturvedi wrote: >> Updated some titles for update sites and made it specific to Open source. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/197 From hirt at openjdk.java.net Fri Jan 15 15:11:05 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 15 Jan 2021 15:11:05 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v7] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 14:08:30 GMT, Jaroslav Bachorik wrote: >> This is an initial implementation of JFR binary format writer in Java. >> The writer can write valid JFR files according to what is expected by the JMC JFR format reader. >> The writer is not complete in terms of performance and event settings support but in spite of that it is fairly usable. >> >> The typical flow is: >> >> 1. Obtain a new instance of Recording >> java >> Recording r = new Recording() >> 2. Register custom types for that recording >> java >> r.registerType(name, structure) >> 3. Get a new Chunk instance >> java >> Chunk c = r.newChunk() >> 4. Write event values >> java >> c.writeEvent(eventValue) >> 5. Finish the chunk and get the binary data >> java >> byte[] data = c.finish() >> >> >> For more complex usage check [ChunkComplexTest.java](https://github.com/openjdk/jmc/blob/4c2dd1407f462feae40b795d3a4c6d75544b4e82/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java). > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Prevent lost writes due to delayed queue processing Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From jbachorik at openjdk.java.net Fri Jan 15 16:51:05 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 15 Jan 2021 16:51:05 GMT Subject: RFR: 6988: Initial implementation of JFR binary format writer [v7] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 15:08:03 GMT, Marcus Hirt wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Prevent lost writes due to delayed queue processing > > Marked as reviewed by hirt (Lead). Hi @AlexVanGogen - https://bugs.openjdk.java.net/browse/JMC-7090 ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From jbachorik at openjdk.java.net Fri Jan 15 17:54:07 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 15 Jan 2021 17:54:07 GMT Subject: Integrated: 6988: Initial implementation of JFR binary format writer In-Reply-To: References: Message-ID: On Fri, 19 Jun 2020 10:22:41 GMT, Jaroslav Bachorik wrote: > This is an initial implementation of JFR binary format writer in Java. > The writer can write valid JFR files according to what is expected by the JMC JFR format reader. > The writer is not complete in terms of performance and event settings support but in spite of that it is fairly usable. > > The typical flow is: > > 1. Obtain a new instance of Recording > java > Recording r = new Recording() > 2. Register custom types for that recording > java > r.registerType(name, structure) > 3. Get a new Chunk instance > java > Chunk c = r.newChunk() > 4. Write event values > java > c.writeEvent(eventValue) > 5. Finish the chunk and get the binary data > java > byte[] data = c.finish() > > > For more complex usage check [ChunkComplexTest.java](https://github.com/openjdk/jmc/blob/4c2dd1407f462feae40b795d3a4c6d75544b4e82/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java). This pull request has now been integrated. Changeset: 21239bc4 Author: Jaroslav Bachorik Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/21239bc4 Stats: 9738 lines in 91 files changed: 9703 ins; 0 del; 35 mod 6988: Initial implementation of JFR binary format writer Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/84 From hirt at openjdk.java.net Fri Jan 15 17:57:06 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 15 Jan 2021 17:57:06 GMT Subject: RFR: 4167: "Copy Column Headers" in stack trace view has no effect In-Reply-To: References: Message-ID: <1NRvU3hXwY6x_u93VKB87Xb0TplKD0-CWqt6ZnPRph8=.bb59ff4e-c723-4cc9-b814-4d7343580625@github.com> On Fri, 15 Jan 2021 10:13:25 GMT, Jean-Philippe Bempel wrote: > Add explicitly header column names as ILabelProvider does not provide this information Changes requested by hirt (Lead). application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2020, 2021, Oracle and/or its affiliates. All rights reserved. Copyright notices are ranges, but comma delimited, in Oracle copyright headers. "Copyright (c) 2018, 2021, ..." would be the appropriate header update. application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/misc/FormatToolkit.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. Yep! :) ------------- PR: https://git.openjdk.java.net/jmc/pull/198 From github.com+4610701+jpbempel at openjdk.java.net Fri Jan 15 19:06:17 2021 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Fri, 15 Jan 2021 19:06:17 GMT Subject: RFR: 4167: "Copy Column Headers" in stack trace view has no effect [v2] In-Reply-To: References: Message-ID: > Add explicitly header column names as ILabelProvider does not provide this information Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: Range the copyright year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/198/files - new: https://git.openjdk.java.net/jmc/pull/198/files/7f728af8..8483e1a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=198&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=198&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/198.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/198/head:pull/198 PR: https://git.openjdk.java.net/jmc/pull/198 From hirt at openjdk.java.net Sat Jan 16 02:08:09 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sat, 16 Jan 2021 02:08:09 GMT Subject: RFR: 4167: "Copy Column Headers" in stack trace view has no effect [v2] In-Reply-To: References: Message-ID: <9rOtrdJvq756p3y3_MsrcGYz4rEfiY7QXc27u5c91c0=.d0bb24b8-b6d0-4dcd-956c-d36ea57e614d@github.com> On Fri, 15 Jan 2021 19:06:17 GMT, Jean-Philippe Bempel wrote: >> Add explicitly header column names as ILabelProvider does not provide this information > > Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: > > Range the copyright year Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/198 From github.com+4610701+jpbempel at openjdk.java.net Sun Jan 17 22:36:37 2021 From: github.com+4610701+jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Sun, 17 Jan 2021 22:36:37 GMT Subject: Integrated: 4167: "Copy Column Headers" in stack trace view has no effect In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 10:13:25 GMT, Jean-Philippe Bempel wrote: > Add explicitly header column names as ILabelProvider does not provide this information This pull request has now been integrated. Changeset: ed123469 Author: Jean-Philippe Bempel Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/ed123469 Stats: 21 lines in 2 files changed: 16 ins; 1 del; 4 mod 4167: "Copy Column Headers" in stack trace view has no effect Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/198 From schaturvedi at openjdk.java.net Mon Jan 18 03:44:37 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Mon, 18 Jan 2021 03:44:37 GMT Subject: Integrated: 6859: Correction in JMC welcome page In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 16:13:24 GMT, Suchita Chaturvedi wrote: > Updated some titles for update sites and made it specific to Open source. This pull request has now been integrated. Changeset: 0b8055a7 Author: Suchita Chaturvedi URL: https://git.openjdk.java.net/jmc/commit/0b8055a7 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 6859: Correction in JMC welcome page Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/197 From ghb at openjdk.java.net Mon Jan 18 06:11:37 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Mon, 18 Jan 2021 06:11:37 GMT Subject: RFR: 7008: Agent should properly support Class and Thread [v2] In-Reply-To: References: <94c0trvCPPx5Cwo__uJJ_uX_SFGmJy3JF4xVX8njSHU=.5dd45dc1-5daa-4d94-8e57-0535002e2d7d@github.com> Message-ID: <2645hMt4jXh__iIYkCwLAaVxNm1yBnBsQGX2CkJG8N8=.ba62efec-8d94-44e9-aeda-165e91c858ae@github.com> On Sun, 10 Jan 2021 18:15:12 GMT, Marcus Hirt wrote: >> Also fixes various issues and tests. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Removing temporary workaround Changes looks good to me .. Please update Copyright year for below file before integrating agent/src/main/java/org/openjdk/jmc/agent/Agent.java agent/src/main/java/org/openjdk/jmc/agent/jfr/JFRTransformDescriptor.java agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFREventClassGenerator.java agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFRMethodAdvisor.java agent/src/main/java/org/openjdk/jmc/agent/jfrlegacy/impl/JFRLegacyMethodAdvisor.java agent/src/main/java/org/openjdk/jmc/agent/util/TypeUtils.java agent/src/test/java/org/openjdk/jmc/agent/converters/test/InstrumentMeConverter.java agent/src/test/java/org/openjdk/jmc/agent/converters/test/ObjectConverterClass.java agent/src/test/resources/org/openjdk/jmc/agent/converters/test/jfrprobes_template.xml ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jmc/pull/192 From hirt at openjdk.java.net Mon Jan 18 12:40:41 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 18 Jan 2021 12:40:41 GMT Subject: Integrated: 7008: Agent should properly support Class and Thread In-Reply-To: <94c0trvCPPx5Cwo__uJJ_uX_SFGmJy3JF4xVX8njSHU=.5dd45dc1-5daa-4d94-8e57-0535002e2d7d@github.com> References: <94c0trvCPPx5Cwo__uJJ_uX_SFGmJy3JF4xVX8njSHU=.5dd45dc1-5daa-4d94-8e57-0535002e2d7d@github.com> Message-ID: On Sun, 10 Jan 2021 01:04:32 GMT, Marcus Hirt wrote: > Also fixes various issues and tests. This pull request has now been integrated. Changeset: 2b1af414 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/2b1af414 Stats: 473 lines in 13 files changed: 339 ins; 53 del; 81 mod 7008: Agent should properly support Class and Thread Reviewed-by: jmatsuoka, ghb ------------- PR: https://git.openjdk.java.net/jmc/pull/192 From hirt at openjdk.java.net Mon Jan 18 13:27:47 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 18 Jan 2021 13:27:47 GMT Subject: RFR: 7093: Wrong copyright year Message-ID: Missed gurus comment in the last PR. ------------- Commit messages: - 7093: Wrong copyright year Changes: https://git.openjdk.java.net/jmc/pull/199/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=199&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7093 Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jmc/pull/199.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/199/head:pull/199 PR: https://git.openjdk.java.net/jmc/pull/199 From jbachorik at openjdk.java.net Mon Jan 18 15:17:53 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 18 Jan 2021 15:17:53 GMT Subject: RFR: JMC-7090: Make constant pool optional when registering a new type Message-ID: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> JMC-7090: Make constant pool optional when registering a new type ------------- Commit messages: - Spotless! - Allow providing directly the recording output stream in addition to File and Path - JMC-7090: Allow specifying whether a custom type has a constant pool associated with it Changes: https://git.openjdk.java.net/jmc/pull/200/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7090 Stats: 186 lines in 7 files changed: 158 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jmc/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/200/head:pull/200 PR: https://git.openjdk.java.net/jmc/pull/200 From hirt at openjdk.java.net Mon Jan 18 16:01:39 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 18 Jan 2021 16:01:39 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: On Mon, 18 Jan 2021 15:02:02 GMT, Jaroslav Bachorik wrote: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type Looks fine to me, but let's check with our first user. ;) @AlexVanGogen - is something like this ok? ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From jkang at openjdk.java.net Mon Jan 18 18:42:43 2021 From: jkang at openjdk.java.net (Jie Kang) Date: Mon, 18 Jan 2021 18:42:43 GMT Subject: RFR: 7093: Wrong copyright year In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:23:46 GMT, Marcus Hirt wrote: > Missed gurus comment in the last PR. Changes look fine to me. ------------- Marked as reviewed by jkang (Author). PR: https://git.openjdk.java.net/jmc/pull/199 From hirt at openjdk.java.net Mon Jan 18 19:57:50 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 18 Jan 2021 19:57:50 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v3] In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: > WIP. Now that core requires JDK 8, we can make it a little bit more easygoing when using streams. I'm thinking it would be nice to remove the need for the StreamModel altogether as well. Marcus Hirt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into 6588-core-jdk8-cleanup - Formatting - Adding values() - Supporting streaming in IItemIterable - Additional cleanup - Inlining stream - First move - 6588: Initial cleanup ------------- Changes: https://git.openjdk.java.net/jmc/pull/194/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=02 Stats: 964 lines in 71 files changed: 488 ins; 414 del; 62 mod Patch: https://git.openjdk.java.net/jmc/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/194/head:pull/194 PR: https://git.openjdk.java.net/jmc/pull/194 From github.com+13893590+alexvangogen at openjdk.java.net Mon Jan 18 20:33:40 2021 From: github.com+13893590+alexvangogen at openjdk.java.net (Alexander Kuznetsov) Date: Mon, 18 Jan 2021 20:33:40 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: <1sDmfD3IgqSIKFJxO1H3szx9R268zBSC4H-hx60hbpw=.118474f1-9d64-46ed-a5c1-1e65a3b8f198@github.com> On Mon, 18 Jan 2021 15:02:02 GMT, Jaroslav Bachorik wrote: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type @jbachorik Thanks for this contribution! One additional thought: wouldn?t it be simpler to just add something like `TypeStructureBuilder#withConstantPool()` instead of extending API with additional flag parameter? core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/TypesImpl.java line 151: > 149: @Override > 150: public TypeImpl getOrAdd(Predefined type, Consumer builderCallback) { > 151: return getOrAdd(type.getTypeName(), false, builderCallback); Just curious, why `withConstantPool` is `false` by default? It alters the previous solution where every jdk type except `jdk.types.Event` was considered to have constant pool, thus causing `ChunkComplexTest` to fail here: https://github.com/openjdk/jmc/blob/2b1af4140b207411a08fde5467b94d86333c1f4a/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java#L130 Without falling to constant pool, stack traces and stack frames are written in-place, and since `classLoader` is not specified in test, NPE is thrown: https://github.com/openjdk/jmc/blob/2b1af4140b207411a08fde5467b94d86333c1f4a/core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/TypedValueImpl.java#L133 core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/TypesImpl.java line 161: > 159: @Override > 160: public TypeImpl getOrAdd(Predefined type, String supertype, Consumer builderCallback) { > 161: return getOrAdd(type.getTypeName(), supertype, false, builderCallback); Same question as above ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From ghb at openjdk.java.net Tue Jan 19 04:46:40 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 19 Jan 2021 04:46:40 GMT Subject: RFR: 7093: Wrong copyright year In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:23:46 GMT, Marcus Hirt wrote: > Missed gurus comment in the last PR. Marked as reviewed by ghb (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/199 From jbachorik at openjdk.java.net Tue Jan 19 10:12:55 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 10:12:55 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v2] In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Use correct default value for predefined types ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/200/files - new: https://git.openjdk.java.net/jmc/pull/200/files/950e0d30..a2e106c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/200/head:pull/200 PR: https://git.openjdk.java.net/jmc/pull/200 From jbachorik at openjdk.java.net Tue Jan 19 10:54:59 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 10:54:59 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type In-Reply-To: <1sDmfD3IgqSIKFJxO1H3szx9R268zBSC4H-hx60hbpw=.118474f1-9d64-46ed-a5c1-1e65a3b8f198@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> <1sDmfD3IgqSIKFJxO1H3szx9R268zBSC4H-hx60hbpw=.118474f1-9d64-46ed-a5c1-1e65a3b8f198@github.com> Message-ID: On Mon, 18 Jan 2021 20:31:02 GMT, Alexander Kuznetsov wrote: >> JMC-7090: [JFR Writer] Make constant pool optional when registering a new type > > @jbachorik Thanks for this contribution! > One additional thought: wouldn?t it be simpler to just add something like `TypeStructureBuilder#withConstantPool()` instead of extending API with additional flag parameter? I was thinking about using the builder - but the problem is that the builder is just for the type structure and you are allowed to use the same structure to actually register multiple types and each of them can have a different constant pool policy. And that was the reason for using the flag instead. ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From jbachorik at openjdk.java.net Tue Jan 19 10:54:58 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 10:54:58 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v3] In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Actually run the flightrecorder.writer tests ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/200/files - new: https://git.openjdk.java.net/jmc/pull/200/files/a2e106c9..f342cb6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=01-02 Stats: 44 lines in 2 files changed: 42 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/200/head:pull/200 PR: https://git.openjdk.java.net/jmc/pull/200 From jbachorik at openjdk.java.net Tue Jan 19 10:55:00 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 10:55:00 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v3] In-Reply-To: <1sDmfD3IgqSIKFJxO1H3szx9R268zBSC4H-hx60hbpw=.118474f1-9d64-46ed-a5c1-1e65a3b8f198@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> <1sDmfD3IgqSIKFJxO1H3szx9R268zBSC4H-hx60hbpw=.118474f1-9d64-46ed-a5c1-1e65a3b8f198@github.com> Message-ID: On Mon, 18 Jan 2021 20:29:44 GMT, Alexander Kuznetsov wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Actually run the flightrecorder.writer tests > > core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/TypesImpl.java line 151: > >> 149: @Override >> 150: public TypeImpl getOrAdd(Predefined type, Consumer builderCallback) { >> 151: return getOrAdd(type.getTypeName(), false, builderCallback); > > Just curious, why `withConstantPool` is `false` by default? It alters the previous solution where every jdk type except `jdk.types.Event` was considered to have constant pool, thus causing `ChunkComplexTest` to fail here: https://github.com/openjdk/jmc/blob/2b1af4140b207411a08fde5467b94d86333c1f4a/core/org.openjdk.jmc.flightrecorder.writer/src/test/java/org/openjdk/jmc/flightrecorder/writer/ChunkComplexTest.java#L130 > Without falling to constant pool, stack traces and stack frames are written in-place, and since `classLoader` is not specified in test, NPE is thrown: > https://github.com/openjdk/jmc/blob/2b1af4140b207411a08fde5467b94d86333c1f4a/core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/TypedValueImpl.java#L133 @AlexVanGogen Thanks for catching that. I didn't realize the tests were not running because of JUnit 5. I have fixed the tests as well as the invalid default value. ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From jbachorik at openjdk.java.net Tue Jan 19 11:27:00 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 11:27:00 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v4] In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Fix test failing on windows ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/200/files - new: https://git.openjdk.java.net/jmc/pull/200/files/f342cb6d..ce9d4197 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/200/head:pull/200 PR: https://git.openjdk.java.net/jmc/pull/200 From hirt at openjdk.java.net Tue Jan 19 11:58:45 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 19 Jan 2021 11:58:45 GMT Subject: Integrated: 7093: Wrong copyright year In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:23:46 GMT, Marcus Hirt wrote: > Missed gurus comment in the last PR. This pull request has now been integrated. Changeset: d4cfbd24 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/d4cfbd24 Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod 7093: Wrong copyright year Reviewed-by: jkang, ghb ------------- PR: https://git.openjdk.java.net/jmc/pull/199 From hirt at openjdk.java.net Tue Jan 19 11:57:48 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 19 Jan 2021 11:57:48 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v4] In-Reply-To: References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: On Tue, 19 Jan 2021 11:27:00 GMT, Jaroslav Bachorik wrote: >> JMC-7090: [JFR Writer] Make constant pool optional when registering a new type > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Fix test failing on windows Changes requested by hirt (Lead). core/org.openjdk.jmc.flightrecorder.writer/pom.xml line 48: > 46: 8 > 47: > 48: I guess the copyright should be 2021 for both Oracle and Datadog in this new file. ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From github.com+13893590+alexvangogen at openjdk.java.net Tue Jan 19 12:24:43 2021 From: github.com+13893590+alexvangogen at openjdk.java.net (Alexander Kuznetsov) Date: Tue, 19 Jan 2021 12:24:43 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v4] In-Reply-To: References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: On Tue, 19 Jan 2021 11:54:33 GMT, Marcus Hirt wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test failing on windows > > Changes requested by hirt (Lead). OK, thanks for the explanation! One more thing: looks like this assumption can be violated now, since types may not fall to constant pool: https://github.com/openjdk/jmc/blob/d4cfbd2486cce3bb56b45a9d6993df2d4b4d6a9c/core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/ConstantPool.java#L107-L120 Shouldn't `true` as argument to `writeValueType` here be replaced? Let's say, by something like `TypedValueImpl#getType#hasConstantPool`? ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From hirt at openjdk.java.net Tue Jan 19 12:25:44 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 19 Jan 2021 12:25:44 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v3] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Mon, 18 Jan 2021 19:57:50 GMT, Marcus Hirt wrote: >> WIP. Now that core requires JDK 8, we can make it a little bit more easygoing when using streams. I'm thinking it would be nice to remove the need for the StreamModel altogether as well. > > Marcus Hirt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into 6588-core-jdk8-cleanup > - Formatting > - Adding values() > - Supporting streaming in IItemIterable > - Additional cleanup > - Inlining stream > - First move > - 6588: Initial cleanup application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/AggregationGrid.java line 222: > 220: // It seems Eclipse 4.5 has trouble inferring the correct type of this function ... > 221: Function getMemberFunc = accessor::getMember; > 222: return is.stream().collect(KeyedStream.collector(getMemberFunc)); Just noticed that this should be parallelStream. Will fix. application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/BucketBuilder.java line 102: > 100: > 101: private List collectItems(IItemIterable is) { > 102: return is.stream().collect(collector(is.getType())); And here. application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/PairBucketBuilder.java line 108: > 106: > 107: private List> collectItems(IItemIterable is) { > 108: return is.stream().collect(collector(is.getType())); And here. ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From jbachorik at openjdk.java.net Tue Jan 19 12:44:56 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 12:44:56 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v4] In-Reply-To: References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: On Tue, 19 Jan 2021 11:53:39 GMT, Marcus Hirt wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test failing on windows > > core/org.openjdk.jmc.flightrecorder.writer/pom.xml line 48: > >> 46: 8 >> 47: >> 48: > > I guess the copyright should be 2021 for both Oracle and Datadog in this new file. done ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From jbachorik at openjdk.java.net Tue Jan 19 12:44:55 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 12:44:55 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v5] In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision: - Use constant pool refs only for types with associated constant pool - Update copyright ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/200/files - new: https://git.openjdk.java.net/jmc/pull/200/files/ce9d4197..51581133 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=03-04 Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jmc/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/200/head:pull/200 PR: https://git.openjdk.java.net/jmc/pull/200 From hirt at openjdk.java.net Tue Jan 19 12:43:59 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 19 Jan 2021 12:43:59 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v4] In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: > WIP. Now that core requires JDK 8, we can make it a little bit more easygoing when using streams. I'm thinking it would be nice to remove the need for the StreamModel altogether as well. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Fixing omitted parallel streams ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/194/files - new: https://git.openjdk.java.net/jmc/pull/194/files/9807e94d..55440403 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/194/head:pull/194 PR: https://git.openjdk.java.net/jmc/pull/194 From jbachorik at openjdk.java.net Tue Jan 19 15:26:56 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 19 Jan 2021 15:26:56 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v6] In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Fix handling 'null' for primitive values (use defaults) ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/200/files - new: https://git.openjdk.java.net/jmc/pull/200/files/51581133..378608ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=200&range=04-05 Stats: 17 lines in 1 file changed: 1 ins; 7 del; 9 mod Patch: https://git.openjdk.java.net/jmc/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/200/head:pull/200 PR: https://git.openjdk.java.net/jmc/pull/200 From hdafgard at openjdk.java.net Tue Jan 19 15:40:46 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Tue, 19 Jan 2021 15:40:46 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v4] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Tue, 19 Jan 2021 12:43:59 GMT, Marcus Hirt wrote: >> WIP. Now that core requires JDK 8, we can make it a little bit more easygoing when using streams. I'm thinking it would be nice to remove the need for the StreamModel altogether as well. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Fixing omitted parallel streams I think this mostly looks fine to merge. core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/messages/internal/Messages.java line 58: > 56: public static final String ItemAggregate_VARIANCE = "ItemAggregate_VARIANCE"; //$NON-NLS-1$ > 57: public static final String ItemAggregate_VARIANCEP = "ItemAggregate_VARIANCEP"; //$NON-NLS-1$ > 58: public static final String ITEM_COLLECTION_DESC = "ITEM_COLLECTION_DESC"; Is this still relevant? I think the key in the properties file was removed? core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/test/item/StreamTest.java line 2: > 1: /* > 2: * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. Year? ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Tue Jan 19 19:16:58 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 19 Jan 2021 19:16:58 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v5] In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: > WIP. Now that core requires JDK 8, we can make it a little bit more easygoing when using streams. I'm thinking it would be nice to remove the need for the StreamModel altogether as well. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Fixing message and updating copyright ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/194/files - new: https://git.openjdk.java.net/jmc/pull/194/files/55440403..37616c85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=03-04 Stats: 7 lines in 3 files changed: 4 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/194/head:pull/194 PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Tue Jan 19 19:17:00 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 19 Jan 2021 19:17:00 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v4] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Tue, 19 Jan 2021 15:34:05 GMT, Henrik Dafg?rd wrote: >> Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing omitted parallel streams > > core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/messages/internal/Messages.java line 58: > >> 56: public static final String ItemAggregate_VARIANCE = "ItemAggregate_VARIANCE"; //$NON-NLS-1$ >> 57: public static final String ItemAggregate_VARIANCEP = "ItemAggregate_VARIANCEP"; //$NON-NLS-1$ >> 58: public static final String ITEM_COLLECTION_DESC = "ITEM_COLLECTION_DESC"; > > Is this still relevant? I think the key in the properties file was removed? Good catch, forgot moving the properties file entry. > core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/test/item/StreamTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > > Year? Yup. ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Tue Jan 19 19:20:43 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 19 Jan 2021 19:20:43 GMT Subject: RFR: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type [v6] In-Reply-To: References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: <9lGT1DydeOKL3yEyM3AlNXk5uLCdYrIKUJCupg6Vxw0=.439efd21-cce1-40e5-a37e-6116fdca222d@github.com> On Tue, 19 Jan 2021 15:26:56 GMT, Jaroslav Bachorik wrote: >> JMC-7090: [JFR Writer] Make constant pool optional when registering a new type > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Fix handling 'null' for primitive values (use defaults) Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From jkang at openjdk.java.net Tue Jan 19 21:39:39 2021 From: jkang at openjdk.java.net (Jie Kang) Date: Tue, 19 Jan 2021 21:39:39 GMT Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Mon, 11 Jan 2021 12:37:10 GMT, Marcus Hirt wrote: > Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. @thegreystone Hi Marcus! The changes I've seen so far are to make use of JDK 8 language features where the overall functionality/result is the same. Are there any parts of the code where functionality is changed that might need a closer look? ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From schaturvedi at openjdk.java.net Tue Jan 19 22:02:52 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 19 Jan 2021 22:02:52 GMT Subject: RFR: 7039: Timestamp granularity too coarse Message-ID: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> As part of this enhancement request, user can see the timestamps down to fraction of a second. This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. For ex: If the End Time of Event is listed as below, the difference is clearly visible ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) ------------- Commit messages: - 7039: Timestamp granularity too coarse Changes: https://git.openjdk.java.net/jmc/pull/201/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7039 Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jmc/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/201/head:pull/201 PR: https://git.openjdk.java.net/jmc/pull/201 From hirt at openjdk.java.net Wed Jan 20 01:04:44 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 01:04:44 GMT Subject: RFR: 7039: Timestamp granularity too coarse In-Reply-To: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: On Tue, 19 Jan 2021 21:58:44 GMT, Suchita Chaturvedi wrote: > As part of this enhancement request, user can see the timestamps down to fraction of a second. > This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. > > For ex: If the End Time of Event is listed as below, the difference is clearly visible > ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) Changes requested by hirt (Lead). core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampKind.java line 143: > 141: > 142: static { > 143: DateFormat df = new SimpleDateFormat("MM/dd/yyyy h:mm:ss:SSS a"); This change is forcing US formatting on everyone... ------------- PR: https://git.openjdk.java.net/jmc/pull/201 From schaturvedi at openjdk.java.net Wed Jan 20 04:12:40 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Wed, 20 Jan 2021 04:12:40 GMT Subject: RFR: 7039: Timestamp granularity too coarse In-Reply-To: References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: On Wed, 20 Jan 2021 01:00:20 GMT, Marcus Hirt wrote: >> As part of this enhancement request, user can see the timestamps down to fraction of a second. >> This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. >> >> For ex: If the End Time of Event is listed as below, the difference is clearly visible >> ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) > > core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampKind.java line 143: > >> 141: >> 142: static { >> 143: DateFormat df = new SimpleDateFormat("MM/dd/yyyy h:mm:ss:SSS a"); > > This change is forcing US formatting on everyone... @thegreystone Can you please suggest a better way to make it generic for every user and still have the timestamp showing the ms part i.e. SSS? ------------- PR: https://git.openjdk.java.net/jmc/pull/201 From jbachorik at openjdk.java.net Wed Jan 20 12:12:46 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 20 Jan 2021 12:12:46 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v5] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Tue, 19 Jan 2021 19:16:58 GMT, Marcus Hirt wrote: >> Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Fixing message and updating copyright core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemCollection.java line 95: > 93: // * @return an item collection matching the range and filter. > 94: // */ > 95: // IItemCollection getItems(IRange range, IItemFilter filter); Should this be removed? core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/test/item/StreamTest.java line 3: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Should this also include DataDog copyright? ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Wed Jan 20 13:37:49 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 13:37:49 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v5] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Wed, 20 Jan 2021 12:03:14 GMT, Jaroslav Bachorik wrote: >> Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing message and updating copyright > > core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/IItemCollection.java line 95: > >> 93: // * @return an item collection matching the range and filter. >> 94: // */ >> 95: // IItemCollection getItems(IRange range, IItemFilter filter); > > Should this be removed? Yep, saving that for later. :) > core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/test/item/StreamTest.java line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. >> 3: * > > Should this also include DataDog copyright? Indeed! Thanks! ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Wed Jan 20 13:40:59 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 13:40:59 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v6] In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: <4Sg_n82X6FSQd5a8W5H9SSF-3mVCiH6qklkFqmKJjto=.03f1ee69-e096-4929-9235-1b4474f4c5be@github.com> > Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Various minor fixes and removing unnecessary API ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/194/files - new: https://git.openjdk.java.net/jmc/pull/194/files/37616c85..a4a3d223 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=04-05 Stats: 22 lines in 2 files changed: 1 ins; 20 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/194/head:pull/194 PR: https://git.openjdk.java.net/jmc/pull/194 From jbachorik at openjdk.java.net Wed Jan 20 13:42:44 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 20 Jan 2021 13:42:44 GMT Subject: Integrated: JMC-7090: [JFR Writer] Make constant pool optional when registering a new type In-Reply-To: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> References: <-YIFBCGdKtDhrAoDQBWG-TgZSAg5UyIEhiALZ-c_Gaw=.70208d42-465b-4daf-a126-372599234fb3@github.com> Message-ID: <1ujUFIW6kMtN3uqKJg1nQvruQ4J3T1eJlpYyj6XYt0c=.23a46d11-8c4e-483a-9774-aa04742332cc@github.com> On Mon, 18 Jan 2021 15:02:02 GMT, Jaroslav Bachorik wrote: > JMC-7090: [JFR Writer] Make constant pool optional when registering a new type This pull request has now been integrated. Changeset: a080481e Author: Jaroslav Bachorik Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/a080481e Stats: 260 lines in 10 files changed: 207 ins; 8 del; 45 mod 7090: [JFR Writer] Make constant pool optional when registering a new type Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/200 From hirt at openjdk.java.net Wed Jan 20 14:04:56 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 14:04:56 GMT Subject: [jmc-graphics] RFR: 7102: Add new splash to graphics project Message-ID: Adding the new JMC 8 splash. ------------- Commit messages: - 7102: Add new splash for 8 Changes: https://git.openjdk.java.net/jmc-graphics/pull/2/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc-graphics&pr=2&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7102 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc-graphics/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jmc-graphics pull/2/head:pull/2 PR: https://git.openjdk.java.net/jmc-graphics/pull/2 From hirt at openjdk.java.net Wed Jan 20 14:20:44 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 14:20:44 GMT Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Tue, 19 Jan 2021 21:37:06 GMT, Jie Kang wrote: >> Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. > > @thegreystone Hi Marcus! The changes I've seen so far are to make use of JDK 8 language features where the overall functionality/result is the same. Are there any parts of the code where functionality is changed that might need a closer look? @jiekang - this is mostly a first step to make IItemCollection and friends more streaming friendly for consumers of core. There is also an API name change getTimeRanges -> getAvailableTimeRanges (for API introduced in 8, so should be OK). I'm thinking we might be able to perhaps find a better name there. It's all of the available time ranges in the recording, not necessarily only for the filtered collection. getOriginalTimeRanges? ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From neugens at redhat.com Wed Jan 20 14:31:05 2021 From: neugens at redhat.com (Mario Torre) Date: Wed, 20 Jan 2021 15:31:05 +0100 Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Wed, Jan 20, 2021 at 3:21 PM Marcus Hirt wrote: > > On Tue, 19 Jan 2021 21:37:06 GMT, Jie Kang wrote: > > >> Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. > > > > @thegreystone Hi Marcus! The changes I've seen so far are to make use of JDK 8 language features where the overall functionality/result is the same. Are there any parts of the code where functionality is changed that might need a closer look? > > @jiekang - this is mostly a first step to make IItemCollection and friends more streaming friendly for consumers of core. There is also an API name change getTimeRanges -> getAvailableTimeRanges (for API introduced in 8, so should be OK). I'm thinking we might be able to perhaps find a better name there. It's all of the available time ranges in the recording, not necessarily only for the filtered collection. getOriginalTimeRanges? getRecordingTimeRanges? Do you think that "Available" really adds meaning here? I would also remove "Ranges" since it's already returning a set of ranges (Set>) so that's implicit for me (however, that would bring us close to getRecordingTimes which is probably ambiguous in this context, so we would need a better name, but this may be getAvailableTimes at this point). Cheers, Mario -- Mario Torre Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hirt at openjdk.java.net Wed Jan 20 15:35:48 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 15:35:48 GMT Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: <_ZoVeaRJtcbr5Bzjd1NikQQIlhtqXKOrmPIac1qghPA=.47bbf9ff-dad0-4666-a7ba-b324c69d35e4@github.com> On Wed, 20 Jan 2021 14:18:14 GMT, Marcus Hirt wrote: >> @thegreystone Hi Marcus! The changes I've seen so far are to make use of JDK 8 language features where the overall functionality/result is the same. Are there any parts of the code where functionality is changed that might need a closer look? > > @jiekang - this is mostly a first step to make IItemCollection and friends more streaming friendly for consumers of core. There is also an API name change getTimeRanges -> getAvailableTimeRanges (for API introduced in 8, so should be OK). I'm thinking we might be able to perhaps find a better name there. It's all of the available time ranges in the recording, not necessarily only for the filtered collection. getOriginalTimeRanges? Recording is not good, since IItemCollections can be used outside of JFR in the future. ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Wed Jan 20 15:39:43 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 15:39:43 GMT Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: <_ZoVeaRJtcbr5Bzjd1NikQQIlhtqXKOrmPIac1qghPA=.47bbf9ff-dad0-4666-a7ba-b324c69d35e4@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> <_ZoVeaRJtcbr5Bzjd1NikQQIlhtqXKOrmPIac1qghPA=.47bbf9ff-dad0-4666-a7ba-b324c69d35e4@github.com> Message-ID: On Wed, 20 Jan 2021 15:32:38 GMT, Marcus Hirt wrote: >> @jiekang - this is mostly a first step to make IItemCollection and friends more streaming friendly for consumers of core. There is also an API name change getTimeRanges -> getAvailableTimeRanges (for API introduced in 8, so should be OK). I'm thinking we might be able to perhaps find a better name there. It's all of the available time ranges in the recording, not necessarily only for the filtered collection. getOriginalTimeRanges? > > Recording is not good, since IItemCollections can be used outside of JFR in the future. getPreFilteringTimeRanges? ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hdafgard at openjdk.java.net Wed Jan 20 15:43:46 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 20 Jan 2021 15:43:46 GMT Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> <_ZoVeaRJtcbr5Bzjd1NikQQIlhtqXKOrmPIac1qghPA=.47bbf9ff-dad0-4666-a7ba-b324c69d35e4@github.com> Message-ID: <50cOPreeCJUnlg-6n1KGGbC3Y5uCMHO2Xmj8rCHdhZ4=.4ced3218-325d-4a74-98c3-4847a728e337@github.com> On Wed, 20 Jan 2021 15:37:01 GMT, Marcus Hirt wrote: >> Recording is not good, since IItemCollections can be used outside of JFR in the future. > > getPreFilteringTimeRanges? getRawTimeRanges? getTimeBoundaries? getTimeBounds? ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From jkang at openjdk.java.net Wed Jan 20 15:53:42 2021 From: jkang at openjdk.java.net (Jie Kang) Date: Wed, 20 Jan 2021 15:53:42 GMT Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Tue, 19 Jan 2021 21:37:06 GMT, Jie Kang wrote: >> Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. > > @thegreystone Hi Marcus! The changes I've seen so far are to make use of JDK 8 language features where the overall functionality/result is the same. Are there any parts of the code where functionality is changed that might need a closer look? > @jiekang - this is mostly a first step to make IItemCollection and friends more streaming friendly for consumers of core. There is also an API name change getTimeRanges -> getAvailableTimeRanges (for API introduced in 8, so should be OK). I'm thinking we might be able to perhaps find a better name there. It's all of the available time ranges in the recording, not necessarily only for the filtered collection. getOriginalTimeRanges? Original sounds fine, or maybe Unfiltered? I think the changes generally look fine otherwise. ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Wed Jan 20 16:16:42 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 16:16:42 GMT Subject: RFR: 6588: Move JMC core to JDK 8 In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Wed, 20 Jan 2021 15:50:39 GMT, Jie Kang wrote: >> @thegreystone Hi Marcus! The changes I've seen so far are to make use of JDK 8 language features where the overall functionality/result is the same. Are there any parts of the code where functionality is changed that might need a closer look? > >> @jiekang - this is mostly a first step to make IItemCollection and friends more streaming friendly for consumers of core. There is also an API name change getTimeRanges -> getAvailableTimeRanges (for API introduced in 8, so should be OK). I'm thinking we might be able to perhaps find a better name there. It's all of the available time ranges in the recording, not necessarily only for the filtered collection. getOriginalTimeRanges? > > Original sounds fine, or maybe Unfiltered? I think the changes generally look fine otherwise. Jaroslav had a good comment. This method is behaving differently, and perhaps it would be better to have an events.unfiltered method which returns the unfiltered collection, and have a getTimeRanges method that actually does what is expected on the collection, unfiltered or not. I suggest going with getUnfilteredTimeRanges() and marking it as deprecated for the 8.0.0 release. ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Wed Jan 20 16:36:00 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 16:36:00 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v7] In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: > Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Adding deprecation and link to issue ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/194/files - new: https://git.openjdk.java.net/jmc/pull/194/files/a4a3d223..233f835c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=194&range=05-06 Stats: 11 lines in 7 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jmc/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/194/head:pull/194 PR: https://git.openjdk.java.net/jmc/pull/194 From jbachorik at openjdk.java.net Wed Jan 20 17:21:42 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 20 Jan 2021 17:21:42 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v7] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Wed, 20 Jan 2021 16:36:00 GMT, Marcus Hirt wrote: >> Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Adding deprecation and link to issue Marked as reviewed by jbachorik (no project role). ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hdafgard at openjdk.java.net Wed Jan 20 17:30:53 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 20 Jan 2021 17:30:53 GMT Subject: RFR: 7104: The PDE wizard does not work with Rules 2.0 Message-ID: Updates the simple rule template to conform to the breaking API changes in JMC 8.0.0. ------------- Commit messages: - Update simple rule template to Rules 2.0 Changes: https://git.openjdk.java.net/jmc/pull/202/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=202&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7104 Stats: 50 lines in 1 file changed: 41 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jmc/pull/202.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/202/head:pull/202 PR: https://git.openjdk.java.net/jmc/pull/202 From hdafgard at openjdk.java.net Wed Jan 20 17:32:47 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 20 Jan 2021 17:32:47 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v7] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Wed, 20 Jan 2021 16:36:00 GMT, Marcus Hirt wrote: >> Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Adding deprecation and link to issue Marked as reviewed by hdafgard (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Wed Jan 20 17:50:40 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 17:50:40 GMT Subject: RFR: 7104: The PDE wizard does not work with Rules 2.0 In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 17:26:18 GMT, Henrik Dafg?rd wrote: > Updates the simple rule template to conform to the breaking API changes in JMC 8.0.0. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/202 From hdafgard at openjdk.java.net Wed Jan 20 17:55:39 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 20 Jan 2021 17:55:39 GMT Subject: Integrated: 7104: The PDE wizard does not work with Rules 2.0 In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 17:26:18 GMT, Henrik Dafg?rd wrote: > Updates the simple rule template to conform to the breaking API changes in JMC 8.0.0. This pull request has now been integrated. Changeset: a8e02f56 Author: Henrik Dafg?rd URL: https://git.openjdk.java.net/jmc/commit/a8e02f56 Stats: 50 lines in 1 file changed: 41 ins; 0 del; 9 mod 7104: The PDE wizard does not work with Rules 2.0 Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/202 From aptmac at openjdk.java.net Wed Jan 20 19:28:43 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 20 Jan 2021 19:28:43 GMT Subject: RFR: 6588: Move JMC core to JDK 8 [v7] In-Reply-To: References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Wed, 20 Jan 2021 16:36:00 GMT, Marcus Hirt wrote: >> Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Adding deprecation and link to issue Marked as reviewed by aptmac (Committer). ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From hirt at openjdk.java.net Wed Jan 20 19:49:43 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 19:49:43 GMT Subject: Integrated: 6588: Move JMC core to JDK 8 In-Reply-To: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> References: <6Gyfm1-fqFADwM6GChC0Klnvrbs3TPNzktvv5Nk6dks=.3a6518ae-6744-464b-a539-9b23ddad746f@github.com> Message-ID: On Mon, 11 Jan 2021 12:37:10 GMT, Marcus Hirt wrote: > Compromise that might be enough to make JMC 8 more enjoyable for people streaming. The grand end goal will be to get rid of StreamModel, but there is no time left for JMC 8. Might want to mark the toolkits as deprecated, and kill them off in a later release. This pull request has now been integrated. Changeset: 50d81c92 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/50d81c92 Stats: 952 lines in 73 files changed: 475 ins; 416 del; 61 mod 6588: Move JMC core to JDK 8 Reviewed-by: hdafgard, jbachorik, aptmac ------------- PR: https://git.openjdk.java.net/jmc/pull/194 From marcus.hirt at datadoghq.com Wed Jan 20 20:39:30 2021 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Wed, 20 Jan 2021 21:39:30 +0100 Subject: Getting the jmc7 repo into the jmc repo as a branch. In-Reply-To: References: <5C4416A5-83E9-4253-BA59-93EB837D542A@oracle.com> Message-ID: Just to remind everyone, we decided the branch name will be jmc8 back in October. :) Kind regards, Marcus On Thu, Oct 15, 2020 at 12:31 PM Marcus Hirt wrote: > I did a quick poll in the JMC slack - everyone there wanted > "jmc", e.g. "jmc7", to be the branch naming convention. If you > disagree, please let me know or go to the slack and vote on the poll! > > Kind regards, > Marcus > > On Wed, Oct 14, 2020 at 4:28 PM Marcus Hirt > wrote: > >> Personally I'd go with branching for major development branches and >> tagging for releases. The name for the branch could be either just version, >> so e.g. "7" or "8", or jmc plus version, so e.g. "jmc7" or "jmc8". I'm >> perfectly fine with either, and have no strong feeling either way. >> >> Please let me know what you think. >> >> Kind regards, >> Marcus >> >> On Wed, Oct 14, 2020 at 3:50 PM Guru wrote: >> >>> Option 1 : Not to pollute the branch name : >>> jmc8 (Branch for Major versions + tags for minor) >>> jmc-8.0.0 >>> jmc-8.y.z >>> ... >>> jmc-8.z.z >>> jmc9 (Branch) >>> >>> Option 2 : Only Branch name, no tags >>> jmc-8.0.0 >>> jmc-8.0.1 >>> ? >>> jmc-8.x.y >>> >>> Will wait for other?s opinion. >>> >>> Thanks, >>> Guru >>> > On 14-Oct-2020, at 6:47 PM, Marcus Hirt >>> wrote: >>> > >>> > Hi all, >>> > >>> > Seems most people would rather have major release versions as branches >>> than >>> > separate repos. Now, what should the branches be called? Just the major >>> > version number? Or jmc followed by the major version number? Something >>> > entirely different? >>> > >>> > Kind regards, >>> > Marcus >>> >>> From hirt at openjdk.java.net Wed Jan 20 22:22:46 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 22:22:46 GMT Subject: RFR: 7106: Update to the release splash screen for JMC 8 Message-ID: <6l9cm0ro8kAtqbOJKD3S2Fe98H1eXILREXzgBsjkTDY=.7ce3f8b2-abd9-480b-b587-4454b0f129b6@github.com> Splash with updated copyright year and "Early Access" removed. ------------- Commit messages: - 7106: Update to the release splash screen for JMC 8 Changes: https://git.openjdk.java.net/jmc/pull/203/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=203&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7106 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/203.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/203/head:pull/203 PR: https://git.openjdk.java.net/jmc/pull/203 From hirt at openjdk.java.net Wed Jan 20 22:28:49 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 22:28:49 GMT Subject: RFR: 7107: Update to the early access 8.1 splash in master Message-ID: <1fgS9LpnNoCGS0pTXuKyBc1LqDtOuTzD7wXCu_Z9h9k=.1b119fc3-5b12-4e1d-942b-a17f19b8b2ae@github.com> Master is now JMC 8.1. ------------- Commit messages: - 7107: Update to the early access 8.1 splash in master Changes: https://git.openjdk.java.net/jmc/pull/204/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=204&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7107 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/204.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/204/head:pull/204 PR: https://git.openjdk.java.net/jmc/pull/204 From hirt at openjdk.java.net Wed Jan 20 22:37:52 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 22:37:52 GMT Subject: RFR: 7106: Update to the release splash screen for JMC 8 Message-ID: <8avVis7App1-zP1U1lE3WFSecxSqLtbhqUCGJ_oyg1M=.01e30b5e-1214-46a0-affb-d8ac9d04f476@github.com> Updated copyright year. No "Early Access". ------------- Commit messages: - 7106: Release splash Changes: https://git.openjdk.java.net/jmc/pull/205/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=205&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7106 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/205.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/205/head:pull/205 PR: https://git.openjdk.java.net/jmc/pull/205 From hirt at openjdk.java.net Wed Jan 20 23:28:57 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 23:28:57 GMT Subject: RFR: 7106: Update to the release splash screen for JMC 8 [v2] In-Reply-To: <6l9cm0ro8kAtqbOJKD3S2Fe98H1eXILREXzgBsjkTDY=.7ce3f8b2-abd9-480b-b587-4454b0f129b6@github.com> References: <6l9cm0ro8kAtqbOJKD3S2Fe98H1eXILREXzgBsjkTDY=.7ce3f8b2-abd9-480b-b587-4454b0f129b6@github.com> Message-ID: > Splash with updated copyright year and "Early Access" removed. Marcus Hirt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/203/files - new: https://git.openjdk.java.net/jmc/pull/203/files/d9f29f35..50d81c92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=203&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=203&range=00-01 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/203.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/203/head:pull/203 PR: https://git.openjdk.java.net/jmc/pull/203 From hirt at openjdk.java.net Wed Jan 20 23:28:57 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 20 Jan 2021 23:28:57 GMT Subject: Integrated: 7106: Update to the release splash screen for JMC 8 In-Reply-To: <6l9cm0ro8kAtqbOJKD3S2Fe98H1eXILREXzgBsjkTDY=.7ce3f8b2-abd9-480b-b587-4454b0f129b6@github.com> References: <6l9cm0ro8kAtqbOJKD3S2Fe98H1eXILREXzgBsjkTDY=.7ce3f8b2-abd9-480b-b587-4454b0f129b6@github.com> Message-ID: On Wed, 20 Jan 2021 22:18:40 GMT, Marcus Hirt wrote: > Splash with updated copyright year and "Early Access" removed. This pull request has now been integrated. Changeset: 50d81c92 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/50d81c92 Stats: 952 lines in 73 files changed: 475 ins; 416 del; 61 mod 6588: Move JMC core to JDK 8 Reviewed-by: hdafgard, jbachorik, aptmac ------------- PR: https://git.openjdk.java.net/jmc/pull/203 From neugens at redhat.com Thu Jan 21 08:23:05 2021 From: neugens at redhat.com (Mario Torre) Date: Thu, 21 Jan 2021 09:23:05 +0100 Subject: Getting the jmc7 repo into the jmc repo as a branch. In-Reply-To: References: <5C4416A5-83E9-4253-BA59-93EB837D542A@oracle.com> Message-ID: I think we discussed this already back in September or so, but I don?t recall the decision... Anyway, I think we need to branch off every release to give chance to add release specific fixes. If you think they are too many we can have a release branch and a dev branch like OpenJDK does (but then there?s a price to pay to maintain both). I?m still of the opinion that branches should have their personal repository and not being in tree but I digress ;) Cheers, Mario On Wednesday, October 14, 2020, Marcus Hirt wrote: > Personally I'd go with branching for major development branches and tagging > for releases. The name for the branch could be either just version, so e.g. > "7" or "8", or jmc plus version, so e.g. "jmc7" or "jmc8". I'm perfectly > fine with either, and have no strong feeling either way. > > Please let me know what you think. > > Kind regards, > Marcus > > On Wed, Oct 14, 2020 at 3:50 PM Guru wrote: > > > Option 1 : Not to pollute the branch name : > > jmc8 (Branch for Major versions + tags for minor) > > jmc-8.0.0 > > jmc-8.y.z > > ... > > jmc-8.z.z > > jmc9 (Branch) > > > > Option 2 : Only Branch name, no tags > > jmc-8.0.0 > > jmc-8.0.1 > > ? > > jmc-8.x.y > > > > Will wait for other?s opinion. > > > > Thanks, > > Guru > > > On 14-Oct-2020, at 6:47 PM, Marcus Hirt > > wrote: > > > > > > Hi all, > > > > > > Seems most people would rather have major release versions as branches > > than > > > separate repos. Now, what should the branches be called? Just the major > > > version number? Or jmc followed by the major version number? Something > > > entirely different? > > > > > > Kind regards, > > > Marcus > > > > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hdafgard at openjdk.java.net Thu Jan 21 15:41:10 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Thu, 21 Jan 2021 15:41:10 GMT Subject: RFR: 7107: Update to the early access 8.1 splash in master In-Reply-To: <1fgS9LpnNoCGS0pTXuKyBc1LqDtOuTzD7wXCu_Z9h9k=.1b119fc3-5b12-4e1d-942b-a17f19b8b2ae@github.com> References: <1fgS9LpnNoCGS0pTXuKyBc1LqDtOuTzD7wXCu_Z9h9k=.1b119fc3-5b12-4e1d-942b-a17f19b8b2ae@github.com> Message-ID: On Wed, 20 Jan 2021 22:24:19 GMT, Marcus Hirt wrote: > Master is now JMC 8.1. Marked as reviewed by hdafgard (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/204 From hirt at openjdk.java.net Thu Jan 21 15:41:11 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 21 Jan 2021 15:41:11 GMT Subject: Integrated: 7107: Update to the early access 8.1 splash in master In-Reply-To: <1fgS9LpnNoCGS0pTXuKyBc1LqDtOuTzD7wXCu_Z9h9k=.1b119fc3-5b12-4e1d-942b-a17f19b8b2ae@github.com> References: <1fgS9LpnNoCGS0pTXuKyBc1LqDtOuTzD7wXCu_Z9h9k=.1b119fc3-5b12-4e1d-942b-a17f19b8b2ae@github.com> Message-ID: <-gniC7iQQN2NxKOOO0PE7Y-11xMP7P1wxxgQqBEDsL8=.58cb075a-737d-4715-a318-7281fe8ada30@github.com> On Wed, 20 Jan 2021 22:24:19 GMT, Marcus Hirt wrote: > Master is now JMC 8.1. This pull request has now been integrated. Changeset: 33ea98b7 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/33ea98b7 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 7107: Update to the early access 8.1 splash in master Reviewed-by: hdafgard ------------- PR: https://git.openjdk.java.net/jmc/pull/204 From hdafgard at openjdk.java.net Thu Jan 21 15:41:54 2021 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Thu, 21 Jan 2021 15:41:54 GMT Subject: RFR: 7106: Update to the release splash screen for JMC 8 In-Reply-To: <8avVis7App1-zP1U1lE3WFSecxSqLtbhqUCGJ_oyg1M=.01e30b5e-1214-46a0-affb-d8ac9d04f476@github.com> References: <8avVis7App1-zP1U1lE3WFSecxSqLtbhqUCGJ_oyg1M=.01e30b5e-1214-46a0-affb-d8ac9d04f476@github.com> Message-ID: On Wed, 20 Jan 2021 22:34:00 GMT, Marcus Hirt wrote: > Updated copyright year. No "Early Access". Marked as reviewed by hdafgard (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/205 From hirt at openjdk.java.net Thu Jan 21 15:41:55 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 21 Jan 2021 15:41:55 GMT Subject: Integrated: 7106: Update to the release splash screen for JMC 8 In-Reply-To: <8avVis7App1-zP1U1lE3WFSecxSqLtbhqUCGJ_oyg1M=.01e30b5e-1214-46a0-affb-d8ac9d04f476@github.com> References: <8avVis7App1-zP1U1lE3WFSecxSqLtbhqUCGJ_oyg1M=.01e30b5e-1214-46a0-affb-d8ac9d04f476@github.com> Message-ID: On Wed, 20 Jan 2021 22:34:00 GMT, Marcus Hirt wrote: > Updated copyright year. No "Early Access". This pull request has now been integrated. Changeset: 50bb5874 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/50bb5874 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 7106: Update to the release splash screen for JMC 8 Reviewed-by: hdafgard ------------- PR: https://git.openjdk.java.net/jmc/pull/205 From hirt at openjdk.java.net Fri Jan 22 17:08:54 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 22 Jan 2021 17:08:54 GMT Subject: RFR: 7116: Updating to 8.1.0 Message-ID: Funnily enough, the revision pattern doesn't work on core, since the pom in the .m2 repo for the core components will contain the unexpanded revision variable. Didn't have time to figure out why or a workaround. This PR at least improves matters a little bit. ------------- Commit messages: - 7116: Updating to 8.1.0 Changes: https://git.openjdk.java.net/jmc/pull/206/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7116 Stats: 435 lines in 290 files changed: 34 ins; 30 del; 371 mod Patch: https://git.openjdk.java.net/jmc/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/206/head:pull/206 PR: https://git.openjdk.java.net/jmc/pull/206 From ghb at openjdk.java.net Fri Jan 22 17:35:49 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 22 Jan 2021 17:35:49 GMT Subject: RFR: 7117: JMC with Eclipse 2020-06 fails to launch in simplified Chinese language Message-ID: Jmc fails to launch with Eclipse 2020-06 SDK in "zh_CN" (simplified Chinese Language). Note: This defect is only for Eclipse 2020-06 and not with Eclipse 2020-09 or later . Solution : Using the latest version of babel which has the fix as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=565976?(Fixed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=565380?) ? ------------- Commit messages: - 7117: JMC with Eclipse 2020-06 fails to launch in simplified Chinese language Changes: https://git.openjdk.java.net/jmc/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=207&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7117 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/207/head:pull/207 PR: https://git.openjdk.java.net/jmc/pull/207 From hirt at openjdk.java.net Fri Jan 22 18:20:07 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 22 Jan 2021 18:20:07 GMT Subject: RFR: 7116: Updating to 8.1.0 [v2] In-Reply-To: References: Message-ID: > Funnily enough, the revision pattern doesn't work on core, since the pom in the .m2 repo for the core components will contain the unexpanded revision variable. Didn't have time to figure out why or a workaround. This PR at least improves matters a little bit. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Adding changelist variable ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/206/files - new: https://git.openjdk.java.net/jmc/pull/206/files/37cb72ab..9cc9d02f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=00-01 Stats: 158 lines in 144 files changed: 1 ins; 0 del; 157 mod Patch: https://git.openjdk.java.net/jmc/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/206/head:pull/206 PR: https://git.openjdk.java.net/jmc/pull/206 From hirt at openjdk.java.net Fri Jan 22 18:30:41 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 22 Jan 2021 18:30:41 GMT Subject: RFR: 7117: JMC with Eclipse 2020-06 fails to launch in simplified Chinese language In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:31:48 GMT, Guru Hb wrote: > Jmc fails to launch with Eclipse 2020-06 SDK in "zh_CN" (simplified Chinese Language). > Note: This defect is only for Eclipse 2020-06 and not with Eclipse 2020-09 or later . > > Solution : Using the latest version of babel which has the fix as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=565976?(Fixed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=565380?) > > ? Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/207 From jkang at openjdk.java.net Fri Jan 22 20:45:40 2021 From: jkang at openjdk.java.net (Jie Kang) Date: Fri, 22 Jan 2021 20:45:40 GMT Subject: RFR: 7116: Updating to 8.1.0 In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:04:59 GMT, Marcus Hirt wrote: > Funnily enough, the revision pattern doesn't work on core, since the pom in the .m2 repo for the core components will contain the unexpanded revision variable. Didn't have time to figure out why or a workaround. This PR at least improves matters a little bit. Hello! Changes look good; I have two requests below: Can `application/uitests/pom.xml` use `project.version` instead of defining its own `jmc.version` for its dependencies? Regarding the deployed/installed jmc-core, the maven guide [1] states that the `flatten-maven-plugin` must be used to deal with this (with example). I would like to request this actually be done for jmc too as there is a project that uses jmc maven dependencies from the m2 repo. Without it, the project would break similar to the jmc & jmc-core relationship. [1] https://maven.apache.org/maven-ci-friendly.html#install-deploy ------------- PR: https://git.openjdk.java.net/jmc/pull/206 From hirt at openjdk.java.net Fri Jan 22 22:36:57 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 22 Jan 2021 22:36:57 GMT Subject: RFR: 7116: Updating to 8.1.0 [v3] In-Reply-To: References: Message-ID: > Funnily enough, the revision pattern doesn't work on core, since the pom in the .m2 repo for the core components will contain the unexpanded revision variable. Didn't have time to figure out why or a workaround. This PR at least improves matters a little bit. Marcus Hirt has updated the pull request incrementally with two additional commits since the last revision: - Ignoring flattened poms - Flattening poms ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/206/files - new: https://git.openjdk.java.net/jmc/pull/206/files/9cc9d02f..15cf33eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=01-02 Stats: 90 lines in 17 files changed: 28 ins; 0 del; 62 mod Patch: https://git.openjdk.java.net/jmc/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/206/head:pull/206 PR: https://git.openjdk.java.net/jmc/pull/206 From ghb at openjdk.java.net Sat Jan 23 05:23:43 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Sat, 23 Jan 2021 05:23:43 GMT Subject: Integrated: 7117: JMC with Eclipse 2020-06 fails to launch in simplified Chinese language In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:31:48 GMT, Guru Hb wrote: > Jmc fails to launch with Eclipse 2020-06 SDK in "zh_CN" (simplified Chinese Language). > Note: This defect is only for Eclipse 2020-06 and not with Eclipse 2020-09 or later . > > Solution : Using the latest version of babel which has the fix as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=565976?(Fixed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=565380?) > > ? This pull request has now been integrated. Changeset: ef0d4574 Author: Guru Hb URL: https://git.openjdk.java.net/jmc/commit/ef0d4574 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 7117: JMC with Eclipse 2020-06 fails to launch in simplified Chinese language Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/207 From ghb at openjdk.java.net Sat Jan 23 07:28:38 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Sat, 23 Jan 2021 07:28:38 GMT Subject: RFR: 7116: Updating to 8.1.0 [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 22:36:57 GMT, Marcus Hirt wrote: >> Funnily enough, the revision pattern doesn't work on core, since the pom in the .m2 repo for the core components will contain the unexpanded revision variable. Didn't have time to figure out why or a workaround. This PR at least improves matters a little bit. > > Marcus Hirt has updated the pull request incrementally with two additional commits since the last revision: > > - Ignoring flattened poms > - Flattening poms changes looks good to me. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jmc/pull/206 From schaturvedi at openjdk.java.net Sun Jan 24 12:28:56 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Sun, 24 Jan 2021 12:28:56 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v2] In-Reply-To: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: > As part of this enhancement request, user can see the timestamps down to fraction of a second. > This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. > > For ex: If the End Time of Event is listed as below, the difference is clearly visible > ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Removed time format hard coding ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/201/files - new: https://git.openjdk.java.net/jmc/pull/201/files/7092398a..808b9f82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=00-01 Stats: 17 lines in 2 files changed: 10 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jmc/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/201/head:pull/201 PR: https://git.openjdk.java.net/jmc/pull/201 From jkang at openjdk.java.net Mon Jan 25 15:19:45 2021 From: jkang at openjdk.java.net (Jie Kang) Date: Mon, 25 Jan 2021 15:19:45 GMT Subject: RFR: 7116: Update version to 8.1.0 in master [v3] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 22:36:57 GMT, Marcus Hirt wrote: >> Also cleaning up the maven versioning. > > Marcus Hirt has updated the pull request incrementally with two additional commits since the last revision: > > - Ignoring flattened poms > - Flattening poms core/pom.xml line 274: > 272: > 273: org.codehaus.mojo > 274: flatten-maven-plugin @thegreystone Can the flatten-maven-plugin also be used for jmc too? The artifacts produced for jmc-core look good now, but the ones produced for jmc have m2 pom files with ${revision}${changelist}. ------------- PR: https://git.openjdk.java.net/jmc/pull/206 From hirt at openjdk.java.net Mon Jan 25 15:38:58 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 25 Jan 2021 15:38:58 GMT Subject: RFR: 7116: Update version to 8.1.0 in master [v4] In-Reply-To: References: Message-ID: > Also cleaning up the maven versioning. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Using the flattening plug-in in the application as well ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/206/files - new: https://git.openjdk.java.net/jmc/pull/206/files/15cf33eb..3e30c869 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=02-03 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/206/head:pull/206 PR: https://git.openjdk.java.net/jmc/pull/206 From hirt at openjdk.java.net Mon Jan 25 15:38:59 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 25 Jan 2021 15:38:59 GMT Subject: RFR: 7116: Update version to 8.1.0 in master [v4] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 15:17:27 GMT, Jie Kang wrote: >> Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: >> >> Using the flattening plug-in in the application as well > > core/pom.xml line 274: > >> 272: >> 273: org.codehaus.mojo >> 274: flatten-maven-plugin > > @thegreystone > Can the flatten-maven-plugin also be used for jmc too? The artifacts produced for jmc-core look good now, but the ones produced for jmc have m2 pom files with ${revision}${changelist}. Yes, certainly. Added. Let me know if it works the way you want. ------------- PR: https://git.openjdk.java.net/jmc/pull/206 From jkang at openjdk.java.net Mon Jan 25 15:51:43 2021 From: jkang at openjdk.java.net (Jie Kang) Date: Mon, 25 Jan 2021 15:51:43 GMT Subject: RFR: 7116: Update version to 8.1.0 in master [v4] In-Reply-To: References: Message-ID: <42qg511X8RycuzLQcvtrfKFLSl-kPHiw16GmCm-1i8E=.bb407393-ab01-4270-a42f-8ff770dacad7@github.com> On Mon, 25 Jan 2021 15:36:25 GMT, Marcus Hirt wrote: >> core/pom.xml line 274: >> >>> 272: >>> 273: org.codehaus.mojo >>> 274: flatten-maven-plugin >> >> @thegreystone >> Can the flatten-maven-plugin also be used for jmc too? The artifacts produced for jmc-core look good now, but the ones produced for jmc have m2 pom files with ${revision}${changelist}. > > Yes, certainly. Added. Let me know if it works the way you want. This was added to the `pluginManagement` section so it will configure plugins for projects down the tree but not actually be active. I think it should be moved to the `plugins` section one level up within `build`. ------------- PR: https://git.openjdk.java.net/jmc/pull/206 From hirt at openjdk.java.net Mon Jan 25 22:05:58 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 25 Jan 2021 22:05:58 GMT Subject: RFR: 7116: Update version to 8.1.0 in master [v5] In-Reply-To: References: Message-ID: > Also cleaning up the maven versioning. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Moving the plug-in xml ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/206/files - new: https://git.openjdk.java.net/jmc/pull/206/files/3e30c869..ba212246 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=206&range=03-04 Stats: 50 lines in 1 file changed: 25 ins; 25 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/206.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/206/head:pull/206 PR: https://git.openjdk.java.net/jmc/pull/206 From jkang at openjdk.java.net Mon Jan 25 22:18:43 2021 From: jkang at openjdk.java.net (Jie Kang) Date: Mon, 25 Jan 2021 22:18:43 GMT Subject: RFR: 7116: Update version to 8.1.0 in master [v5] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:05:58 GMT, Marcus Hirt wrote: >> Also cleaning up the maven versioning. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Moving the plug-in xml Marked as reviewed by jkang (Author). ------------- PR: https://git.openjdk.java.net/jmc/pull/206 From hirt at openjdk.java.net Tue Jan 26 00:36:45 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 26 Jan 2021 00:36:45 GMT Subject: Integrated: 7116: Update version to 8.1.0 in master In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:04:59 GMT, Marcus Hirt wrote: > Also cleaning up the maven versioning. This pull request has now been integrated. Changeset: 2bcb03ee Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/2bcb03ee Stats: 528 lines in 291 files changed: 88 ins; 30 del; 410 mod 7116: Update version to 8.1.0 in master Reviewed-by: ghb, jkang ------------- PR: https://git.openjdk.java.net/jmc/pull/206 From schaturvedi at openjdk.java.net Thu Jan 28 06:55:59 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Thu, 28 Jan 2021 06:55:59 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v3] In-Reply-To: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: > As part of this enhancement request, user can see the timestamps down to fraction of a second. > This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. > > For ex: If the End Time of Event is listed as below, the difference is clearly visible > ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Fixed test failures due to change in timestamp format ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/201/files - new: https://git.openjdk.java.net/jmc/pull/201/files/808b9f82..6fb15c97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/201/head:pull/201 PR: https://git.openjdk.java.net/jmc/pull/201 From schaturvedi at openjdk.java.net Thu Jan 28 07:28:58 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Thu, 28 Jan 2021 07:28:58 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v4] In-Reply-To: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: > As part of this enhancement request, user can see the timestamps down to fraction of a second. > This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. > > For ex: If the End Time of Event is listed as below, the difference is clearly visible > ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Fix spotless check failure ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/201/files - new: https://git.openjdk.java.net/jmc/pull/201/files/6fb15c97..864d9c6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/201/head:pull/201 PR: https://git.openjdk.java.net/jmc/pull/201 From hirt at openjdk.java.net Thu Jan 28 11:56:42 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 28 Jan 2021 11:56:42 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v4] In-Reply-To: References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: On Thu, 28 Jan 2021 07:28:58 GMT, Suchita Chaturvedi wrote: >> As part of this enhancement request, user can see the timestamps down to fraction of a second. >> This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. >> >> For ex: If the End Time of Event is listed as below, the difference is clearly visible >> ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Fix spotless check failure Changes requested by hirt (Lead). core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/UnitLookup.java line 520: > 518: SimpleDateFormat sdf = (SimpleDateFormat) df; > 519: String pattern = sdf.toPattern(); > 520: String newPattern = pattern.replaceFirst("s{2,4}", "ss:SSS"); //$NON-NLS-1$ //$NON-NLS-2$ I think normally a dot is used for the ms part. ------------- PR: https://git.openjdk.java.net/jmc/pull/201 From schaturvedi at openjdk.java.net Thu Jan 28 15:09:56 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Thu, 28 Jan 2021 15:09:56 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v5] In-Reply-To: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: > As part of this enhancement request, user can see the timestamps down to fraction of a second. > This will solve the problem for all views, including Event Browser, Properties where most of the records are differentiated by fraction of seconds but since the timestamp shown is only till second, the difference is not visible on UI. > > For ex: If the End Time of Event is listed as below, the difference is clearly visible > ![image](https://user-images.githubusercontent.com/11155712/105097851-465a8680-5acf-11eb-8a5c-f01ecb3390ce.png) Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Replaced colon with dot as per review comment ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/201/files - new: https://git.openjdk.java.net/jmc/pull/201/files/864d9c6f..da675503 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=201&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/201/head:pull/201 PR: https://git.openjdk.java.net/jmc/pull/201 From hirt at openjdk.java.net Fri Jan 29 12:28:42 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 29 Jan 2021 12:28:42 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v4] In-Reply-To: References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: On Thu, 28 Jan 2021 11:54:16 GMT, Marcus Hirt wrote: >> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix spotless check failure > > Changes requested by hirt (Lead). Did you run all the tests? I'm getting test failures when running the UI-tests. ------------- PR: https://git.openjdk.java.net/jmc/pull/201 From schaturvedi at openjdk.java.net Fri Jan 29 15:18:41 2021 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Fri, 29 Jan 2021 15:18:41 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v4] In-Reply-To: References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: On Fri, 29 Jan 2021 12:25:43 GMT, Marcus Hirt wrote: > Did you run all the tests? I'm getting test failures when running the UI-tests. I ran JUnits and there were failures too which I fixed as part of this PR request itself. Didn't run UI-tests though. Should I run that as well and fix failures as part of this PR only or that can be taken up separately as a new task (JIRA)? ------------- PR: https://git.openjdk.java.net/jmc/pull/201 From hirt at openjdk.java.net Fri Jan 29 17:56:39 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 29 Jan 2021 17:56:39 GMT Subject: RFR: 7039: Timestamp granularity too coarse [v4] In-Reply-To: References: <7X1f0Qi20HPDWpgs2vk1irZ6WtFAqNYX13ABXaG-hKQ=.32b6df02-fa9b-4121-a849-592a571de8be@github.com> Message-ID: <2LVYo7_R6yVXTZptxlAN00pG-7NG4q14IxRSgcZltEc=.dd45123e-0eec-47cb-a081-39ff91c4e305@github.com> On Fri, 29 Jan 2021 15:15:57 GMT, Suchita Chaturvedi wrote: >> Did you run all the tests? I'm getting test failures when running the UI-tests. > >> Did you run all the tests? I'm getting test failures when running the UI-tests. > > I ran JUnits and there were failures too which I fixed as part of this PR request itself. Didn't run UI-tests though. Should I run that as well and fix failures as part of this PR only or that can be taken up separately as a new task (JIRA)? I'd prefer if they were fixed with this PR, if there are failures related to the changes in this PR. If the failures are unrelated, i.e. master already fails in the same ways, it can be a separate PR. ------------- PR: https://git.openjdk.java.net/jmc/pull/201