From mwengner at openjdk.java.net Tue Jun 2 15:32:04 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 2 Jun 2020 15:32:04 GMT Subject: RFR: 6542: Improve calls to render in the flame view Message-ID: stable flameview generation ------------- Commit messages: - 6542: naming correction, models container check - 6542: stacktrace model utils - 6542: model assignment fix - 6542: cleanup - 6542: clean up - 6542: partial commit, fixed flameview Changes: https://git.openjdk.java.net/jmc/pull/78/files Webrev: https://webrevs.openjdk.java.net/jmc/78/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6542 Stats: 145 lines in 3 files changed: 84 ins; 16 del; 45 mod Patch: https://git.openjdk.java.net/jmc/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/78/head:pull/78 PR: https://git.openjdk.java.net/jmc/pull/78 From mwengner at openjdk.java.net Tue Jun 2 15:38:04 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 2 Jun 2020 15:38:04 GMT Subject: [Rev 01] RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: > stable flameview generation Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6542: spotless needs ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/78/files - new: https://git.openjdk.java.net/jmc/pull/78/files/555ee400..f04acb80 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/78/webrev.01 - incr: https://webrevs.openjdk.java.net/jmc/78/webrev.00-01 Stats: 31 lines in 1 file changed: 0 ins; 5 del; 26 mod Patch: https://git.openjdk.java.net/jmc/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/78/head:pull/78 PR: https://git.openjdk.java.net/jmc/pull/78 From mwengner at openjdk.java.net Tue Jun 2 20:51:58 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 2 Jun 2020 20:51:58 GMT Subject: [Rev 02] RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: > stable flameview generation Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6542: spotless correction ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/78/files - new: https://git.openjdk.java.net/jmc/pull/78/files/f04acb80..ff0546b1 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/78/webrev.02 - incr: https://webrevs.openjdk.java.net/jmc/78/webrev.01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/78/head:pull/78 PR: https://git.openjdk.java.net/jmc/pull/78 From hirt at openjdk.java.net Wed Jun 3 09:07:32 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 3 Jun 2020 09:07:32 GMT Subject: [Rev 02] RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: <0Fv2LsQ_3-Am5DeG3mOKpdbGlyEISqhToLNuR1iLqLc=.549f2358-ad40-4dfc-877e-68f91ed57d58@github.com> On Tue, 2 Jun 2020 20:51:58 GMT, Miroslav Wengner wrote: >> stable flameview generation > > Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: > > 6542: spotless correction core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModelUtils.java line 9: > 8: */ > 9: public final class StacktraceModelUtils { > 10: This static method seems to be just fine belonging in StacktraceModel - I don't think creating a new class is warranted. ------------- PR: https://git.openjdk.java.net/jmc/pull/78 From hirt at openjdk.java.net Wed Jun 3 09:07:33 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 3 Jun 2020 09:07:33 GMT Subject: [Rev 02] RFR: 6542: Improve calls to render in the flame view In-Reply-To: <0Fv2LsQ_3-Am5DeG3mOKpdbGlyEISqhToLNuR1iLqLc=.549f2358-ad40-4dfc-877e-68f91ed57d58@github.com> References: <0Fv2LsQ_3-Am5DeG3mOKpdbGlyEISqhToLNuR1iLqLc=.549f2358-ad40-4dfc-877e-68f91ed57d58@github.com> Message-ID: On Wed, 3 Jun 2020 08:55:47 GMT, Marcus Hirt wrote: >> Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: >> >> 6542: spotless correction > > core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceModelUtils.java > line 9: >> 8: */ >> 9: public final class StacktraceModelUtils { >> 10: > > This static method seems to be just fine belonging in StacktraceModel - I don't think creating a new class is warranted. I.e. JMC-6787 is about moving out all (selection) state from the stack trace model and making it into two pieces - one stateless model that models the full tree, and another one which models the selection states in that model. They are currently one, since it's way more efficient that way. It may be the case that we should have two different models - the current one, and support selections and state in it, and another one which simply models the aggregated tree. That, however, is for another day. ------------- PR: https://git.openjdk.java.net/jmc/pull/78 From mwengner at openjdk.java.net Wed Jun 3 10:23:44 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Wed, 3 Jun 2020 10:23:44 GMT Subject: [Rev 03] RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: <8s6Clfxh1FS7u2NSxvIHZ9gUVI9V4RTPh0tX4mfygs0=.f546c46c-4995-4f60-8eb8-2a2a01554443@github.com> > stable flameview generation Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6542: cleaning code ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/78/files - new: https://git.openjdk.java.net/jmc/pull/78/files/ff0546b1..28abb117 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/78/webrev.03 - incr: https://webrevs.openjdk.java.net/jmc/78/webrev.02-03 Stats: 37 lines in 4 files changed: 12 ins; 23 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/78/head:pull/78 PR: https://git.openjdk.java.net/jmc/pull/78 From kxu at openjdk.java.net Wed Jun 3 16:39:06 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 3 Jun 2020 16:39:06 GMT Subject: RFR: 6819: Agent instrumentation causing stack map frame verification error Message-ID: <6nt-Xfv9SnVfHsL7J55LWxWFalRo24mvUHZdhaUYxE0=.4f82d590-ce1a-4db9-937d-61cfe8dc0adb@github.com> This pr fixes [JMC-6819: Agent instrumentation causing stack map frame verification error](https://bugs.openjdk.java.net/browse/JMC-6819). The issue is reproducible when the target function consists of multiple exit points, and a compressed stack map frame describing a jump target, followed by a function exit (eg. `*return` instructions). A simple example could be something like(, given `javac` writes a compressed frame instead of a new expanded frame): public int echo(int arg) { if (arg > 42) { return 42; } return arg; } When fixing [JMC-6532: Instrumentation fails for methods containing try-catch clauses](https://bugs.openjdk.java.net/browse/JMC-6532), compressed frames were [forcefully expanded](https://github.com/thegreystone/jmc-old/commit/e4acc9c93bfb21317caeead2d7646c7677c7a4a6#diff-af337d6e5f3fd3b585e66e0cebcb056fR132), but the method was faulty. It turns out the ASM lib supports expanding frames automatically, which this pr adopts. This pr comes with test cases generating bytecode for the example above. The generation is done by ASM lib manually to make sure various compressed frame types (`same_frame`, `chop_frame`, `append_frame`) are tested. ------------- Commit messages: - Handles compressed frames correctly Changes: https://git.openjdk.java.net/jmc/pull/79/files Webrev: https://webrevs.openjdk.java.net/jmc/79/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6819 Stats: 172 lines in 5 files changed: 158 ins; 12 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/79.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/79/head:pull/79 PR: https://git.openjdk.java.net/jmc/pull/79 From almacdon at redhat.com Wed Jun 3 19:56:01 2020 From: almacdon at redhat.com (Alex Macdonald) Date: Wed, 3 Jun 2020 15:56:01 -0400 Subject: [backport][7.1.1] RFR: JMC-6554 & JMC-6692 Message-ID: Hi everyone, Please consider these two webrevs [0][1] for backporting the following into JMC 7: JMC-6554: Support JFR in OpenJDK 8 [2] and JMC-6692: JMC is asking to unlock Commercial Features on JFR enabled OpenJDK8 [3]. These patches together allow for improved handling of Flight Recordings with OpenJDK 8. As far as the patches are concerned, JMC-6692 relies on the changes in 6554, so the patches need to be applied in the order of 6554 -> 6692. For reference, the original commits can be found at the following links: JMC-6554: https://github.com/openjdk/jmc/commit/4b315fe62adb44c5524b55cac2e286fa22324573 JMC-6692: https://github.com/openjdk/jmc/commit/efc952149024cfb3d92863bd910395946d0beffe Cheers, Alex [0] http://cr.openjdk.java.net/~aptmac/JMC-6554/webrev.01/ [1] http://cr.openjdk.java.net/~aptmac/JMC-6692/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JMC-6554 [3] https://bugs.openjdk.java.net/browse/JMC-6692 From marcus.hirt at datadoghq.com Thu Jun 4 10:59:10 2020 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 4 Jun 2020 12:59:10 +0200 Subject: [backport][7.1.1] RFR: JMC-6554 & JMC-6692 In-Reply-To: References: Message-ID: Hi Alex, LGTM! I pinged you about the minimum amount of testing I think should be done, but feel free to submit after the appropriate testing has been done! Kind regards, Marcus On Wed, Jun 3, 2020 at 9:57 PM Alex Macdonald wrote: > Hi everyone, > > Please consider these two webrevs [0][1] for backporting the following into > JMC 7: > > JMC-6554: Support JFR in OpenJDK 8 [2] > and > JMC-6692: JMC is asking to unlock Commercial Features on JFR enabled > OpenJDK8 [3]. > > These patches together allow for improved handling of Flight Recordings > with OpenJDK 8. As far as the patches are concerned, JMC-6692 relies on the > changes in 6554, so the patches need to be applied in the order of 6554 -> > 6692. > > For reference, the original commits can be found at the following links: > JMC-6554: > > https://github.com/openjdk/jmc/commit/4b315fe62adb44c5524b55cac2e286fa22324573 > JMC-6692 > > : > > https://github.com/openjdk/jmc/commit/efc952149024cfb3d92863bd910395946d0beffe > > Cheers, > > Alex > > [0] http://cr.openjdk.java.net/~aptmac/JMC-6554/webrev.01/ > [1] http://cr.openjdk.java.net/~aptmac/JMC-6692/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JMC-6554 > [3] https://bugs.openjdk.java.net/browse/JMC-6692 > From almacdon at redhat.com Thu Jun 4 20:02:46 2020 From: almacdon at redhat.com (Alex Macdonald) Date: Thu, 4 Jun 2020 16:02:46 -0400 Subject: [backport][7.1.1] RFR: JMC-6554 & JMC-6692 In-Reply-To: References: Message-ID: Hi Marcus, On Thu, Jun 4, 2020 at 6:59 AM Marcus Hirt wrote: > Hi Alex, > > LGTM! I pinged you about the minimum amount of testing I think should be > done, but feel free to submit after the appropriate testing has been done! > Thanks for the reply! I've gone and tested the patches, and attached some screenshots to the JIRA ticket for the backport of 6692: https://bugs.openjdk.java.net/browse/JMC-6822 I gave the functionality a quick run-through on both Fedora 31 and Windows 10, using: Oracle JDK 8, OpenJDK 8, OpenJDK8 with JFR, and OpenJDK 11. Both Windows and Fedora displayed the same behaviour when trying to start a flight recording, or trying to view current recordings by expanding the Flight Recorder tree item in the JVM Browser. 1. With Oracle JDK 8, expanding the Flight Recorder tree item results in the dialog explaining that JFR isn't enabled, and trying to start a recording results in the dialog prompting the user to enable commercial features. Fedora warning dialog: https://bugs.openjdk.java.net/secure/attachment/88568/linux-oracle8-1-warning.png Fedora enable commercial features: https://bugs.openjdk.java.net/secure/attachment/88569/linux-oracle8-2-enable.png Windows warning dialog: https://bugs.openjdk.java.net/secure/attachment/88575/windows-oracle8-1-warning.png Windows enable commercial features: https://bugs.openjdk.java.net/secure/attachment/88576/windows-oracle8-2-enable.png 2. With OpenJDK 8, the error message was updated to mention that Flight Recorder would work with an OpenJDK 8 with JFR enabled. Fedora warning dialog: https://bugs.openjdk.java.net/secure/attachment/88563/linux-ojdk8-1-warning.png Fedora cannot record: https://bugs.openjdk.java.net/secure/attachment/88564/linux-ojdk8-2-enable.png Windows warning dialog: https://bugs.openjdk.java.net/secure/attachment/88570/windows-ojdk8-1-warning.png Windows cannot record: https://bugs.openjdk.java.net/secure/attachment/88571/windows-ojdk8-2-enable.png 3. With OpenJDK 8 with JFR enabled, the wizard opens without warning and there wasn't any issue dumping and opening the recording. Fedora JFR wizard: https://bugs.openjdk.java.net/secure/attachment/88565/linux-ojdk8jfr-1-wizard.png Fedora recording dumped & opened: https://bugs.openjdk.java.net/secure/attachment/88566/linux-ojdk8jfr-2-dumped.png Windows JFR wizard: https://bugs.openjdk.java.net/secure/attachment/88572/windows-ojdk8jfr-1-wizard.png Windows recording dumped & opened: https://bugs.openjdk.java.net/secure/attachment/88573/windows-ojdk8jfr-2-dumped.png 4. With OpenJDK 11, the wizard opens without warning and there wasn't any issue dumping and opening the recording. Fedora: https://bugs.openjdk.java.net/secure/attachment/88567/linux-ojdk11.png Windows: https://bugs.openjdk.java.net/secure/attachment/88574/windows-ojdk11.png If there's anything else you'd like me to check while I have this setup, let me know. Cheers, Alex > Kind regards, > Marcus > > On Wed, Jun 3, 2020 at 9:57 PM Alex Macdonald wrote: > >> Hi everyone, >> >> Please consider these two webrevs [0][1] for backporting the following >> into >> JMC 7: >> >> JMC-6554: Support JFR in OpenJDK 8 [2] >> and >> JMC-6692: JMC is asking to unlock Commercial Features on JFR enabled >> OpenJDK8 [3]. >> >> These patches together allow for improved handling of Flight Recordings >> with OpenJDK 8. As far as the patches are concerned, JMC-6692 relies on >> the >> changes in 6554, so the patches need to be applied in the order of 6554 -> >> 6692. >> >> For reference, the original commits can be found at the following links: >> JMC-6554: >> >> https://github.com/openjdk/jmc/commit/4b315fe62adb44c5524b55cac2e286fa22324573 >> JMC-6692 >> >> : >> >> https://github.com/openjdk/jmc/commit/efc952149024cfb3d92863bd910395946d0beffe >> >> Cheers, >> >> Alex >> >> [0] http://cr.openjdk.java.net/~aptmac/JMC-6554/webrev.01/ >> [1] http://cr.openjdk.java.net/~aptmac/JMC-6692/webrev.01/ >> [2] https://bugs.openjdk.java.net/browse/JMC-6554 >> [3] https://bugs.openjdk.java.net/browse/JMC-6692 >> > From marcus at hirt.se Thu Jun 4 20:15:22 2020 From: marcus at hirt.se (Marcus Hirt) Date: Thu, 4 Jun 2020 22:15:22 +0200 Subject: Sv: [backport][7.1.1] RFR: JMC-6554 & JMC-6692 In-Reply-To: References: Message-ID: <0ad801d63aac$e0824cf0$a186e6d0$@hirt.se> Excellent! Thanks Alex! Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Alex Macdonald Skickat: den 4 juni 2020 22:03 Till: Marcus Hirt Kopia: jmc-dev at openjdk.java.net ?mne: Re: [backport][7.1.1] RFR: JMC-6554 & JMC-6692 Hi Marcus, On Thu, Jun 4, 2020 at 6:59 AM Marcus Hirt wrote: > Hi Alex, > > LGTM! I pinged you about the minimum amount of testing I think should > be done, but feel free to submit after the appropriate testing has been done! > Thanks for the reply! I've gone and tested the patches, and attached some screenshots to the JIRA ticket for the backport of 6692: https://bugs.openjdk.java.net/browse/JMC-6822 I gave the functionality a quick run-through on both Fedora 31 and Windows 10, using: Oracle JDK 8, OpenJDK 8, OpenJDK8 with JFR, and OpenJDK 11. Both Windows and Fedora displayed the same behaviour when trying to start a flight recording, or trying to view current recordings by expanding the Flight Recorder tree item in the JVM Browser. 1. With Oracle JDK 8, expanding the Flight Recorder tree item results in the dialog explaining that JFR isn't enabled, and trying to start a recording results in the dialog prompting the user to enable commercial features. Fedora warning dialog: https://bugs.openjdk.java.net/secure/attachment/88568/linux-oracle8-1-warning.png Fedora enable commercial features: https://bugs.openjdk.java.net/secure/attachment/88569/linux-oracle8-2-enable.png Windows warning dialog: https://bugs.openjdk.java.net/secure/attachment/88575/windows-oracle8-1-warning.png Windows enable commercial features: https://bugs.openjdk.java.net/secure/attachment/88576/windows-oracle8-2-enable.png 2. With OpenJDK 8, the error message was updated to mention that Flight Recorder would work with an OpenJDK 8 with JFR enabled. Fedora warning dialog: https://bugs.openjdk.java.net/secure/attachment/88563/linux-ojdk8-1-warning.png Fedora cannot record: https://bugs.openjdk.java.net/secure/attachment/88564/linux-ojdk8-2-enable.png Windows warning dialog: https://bugs.openjdk.java.net/secure/attachment/88570/windows-ojdk8-1-warning.png Windows cannot record: https://bugs.openjdk.java.net/secure/attachment/88571/windows-ojdk8-2-enable.png 3. With OpenJDK 8 with JFR enabled, the wizard opens without warning and there wasn't any issue dumping and opening the recording. Fedora JFR wizard: https://bugs.openjdk.java.net/secure/attachment/88565/linux-ojdk8jfr-1-wizard.png Fedora recording dumped & opened: https://bugs.openjdk.java.net/secure/attachment/88566/linux-ojdk8jfr-2-dumped.png Windows JFR wizard: https://bugs.openjdk.java.net/secure/attachment/88572/windows-ojdk8jfr-1-wizard.png Windows recording dumped & opened: https://bugs.openjdk.java.net/secure/attachment/88573/windows-ojdk8jfr-2-dumped.png 4. With OpenJDK 11, the wizard opens without warning and there wasn't any issue dumping and opening the recording. Fedora: https://bugs.openjdk.java.net/secure/attachment/88567/linux-ojdk11.png Windows: https://bugs.openjdk.java.net/secure/attachment/88574/windows-ojdk11.png If there's anything else you'd like me to check while I have this setup, let me know. Cheers, Alex > Kind regards, > Marcus > > On Wed, Jun 3, 2020 at 9:57 PM Alex Macdonald wrote: > >> Hi everyone, >> >> Please consider these two webrevs [0][1] for backporting the >> following into JMC 7: >> >> JMC-6554: Support JFR in OpenJDK 8 [2] and >> JMC-6692: JMC is asking to unlock Commercial Features on JFR enabled >> OpenJDK8 [3]. >> >> These patches together allow for improved handling of Flight >> Recordings with OpenJDK 8. As far as the patches are concerned, >> JMC-6692 relies on the changes in 6554, so the patches need to be >> applied in the order of 6554 -> 6692. >> >> For reference, the original commits can be found at the following links: >> JMC-6554: >> >> https://github.com/openjdk/jmc/commit/4b315fe62adb44c5524b55cac2e286f >> a22324573 >> JMC-6692 >> > fa22324573JMC-6692> >> : >> >> https://github.com/openjdk/jmc/commit/efc952149024cfb3d92863bd9103959 >> 46d0beffe >> >> Cheers, >> >> Alex >> >> [0] http://cr.openjdk.java.net/~aptmac/JMC-6554/webrev.01/ >> [1] http://cr.openjdk.java.net/~aptmac/JMC-6692/webrev.01/ >> [2] https://bugs.openjdk.java.net/browse/JMC-6554 >> [3] https://bugs.openjdk.java.net/browse/JMC-6692 >> > From hirt at openjdk.java.net Fri Jun 5 12:31:22 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 5 Jun 2020 12:31:22 GMT Subject: RFR: 6531: Make the flame chart view render labels on windows In-Reply-To: References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com> <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com> <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com> Message-ID: On Wed, 27 May 2020 16:40:43 GMT, Thomas May wrote: >>> As soon as the Eclipse changes are in, in any form and shape, we should switch. >> >> Agreed, it would be very limiting to continue on this way. >> >> This PR required some rebasing after the latest flamegraph commits to include colour highlighting. I had to include an >> additional commit here that allows for the colouring to work with IE, because some syntax and functions are too >> advanced for ES2015. About the `flameviewColoring.js`, I made the changes in the file to make it compatible with IE, >> but would it be worthwhile to go the route of making a `flameviewColoring-ie.js` so that if/when Chromium functionality >> is introduced instead of refactoring the colouring script we could just drop the `-ie` version? Let me know your >> thoughts on this one. Here's an example screenshot of it working in Windows with text highlighting: >> ![windows-highlighting](https://user-images.githubusercontent.com/10425301/75188682-92177b00-571a-11ea-9a3f-e8bd7b91d3b9.png) > > Dumb question, but would a shorter path be to run babel against d3 (Or have that as part of the build?) > > That would eliminate the need to maintain your own version and make updating a lot easier. Hi Alex! I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585 is getting closer to release. Any chance you could see if that works as a drop-in replacement? ------------- PR: https://git.openjdk.java.net/jmc/pull/41 From hirt at openjdk.java.net Fri Jun 5 14:37:35 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 5 Jun 2020 14:37:35 GMT Subject: RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 15:25:53 GMT, Miroslav Wengner wrote: > stable flameview generation Sadly I can still make it go out of whack with these changes: ![image](https://user-images.githubusercontent.com/16906077/83888656-71fc4c80-a74a-11ea-9c03-1cfa0c28569e.png) ------------- PR: https://git.openjdk.java.net/jmc/pull/78 From jescolem at openjdk.java.net Fri Jun 5 17:10:34 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Fri, 5 Jun 2020 17:10:34 GMT Subject: RFR: 6825: JMX defineEventProbes fails when no events in XMLDescriptor Message-ID: This patch makes the agent JMX operation 'defineEventProbes' accept an xmlDecsription with no event tags. Previously, the only way you could clear all current transforms was to supply the operation with an empty or null xmlDescription. Now a file with the following structure will also clear all current transforms: `` ------------- Commit messages: - Make defineEventProbes accept a descriptor with no events Changes: https://git.openjdk.java.net/jmc/pull/80/files Webrev: https://webrevs.openjdk.java.net/jmc/80/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6825 Stats: 50 lines in 1 file changed: 27 ins; 16 del; 7 mod Patch: https://git.openjdk.java.net/jmc/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/80/head:pull/80 PR: https://git.openjdk.java.net/jmc/pull/80 From hirt at openjdk.java.net Sat Jun 6 13:29:53 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sat, 6 Jun 2020 13:29:53 GMT Subject: RFR: 6825: JMX defineEventProbes fails when no events in XMLDescriptor In-Reply-To: References: Message-ID: On Fri, 5 Jun 2020 17:01:28 GMT, Jessye Coleman-Shapiro wrote: > This patch makes the agent JMX operation 'defineEventProbes' accept an xmlDecsription with no event tags. Previously, > the only way you could clear all current transforms was to supply the operation with an empty or null xmlDescription. > Now a file with the following structure will also clear all current transforms: > `` agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentController.java line 83: > 82: private Class[] revertAllTransforms() { > 83: HashSet> classesToRetransform = new HashSet>(); > 84: List classNames = registry.clearAllTransformData(); Style: Set> classesToRetransform = new HashSet>(); agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentController.java line 97: > 96: private Class[] defineSpecificTransforms(List descriptors) { > 97: HashSet> classesToRetransform = new HashSet>(); > 98: for (TransformDescriptor descriptor : descriptors) { Style: Set> classesToRetransform = new HashSet>(); ------------- PR: https://git.openjdk.java.net/jmc/pull/80 From jescolem at openjdk.java.net Mon Jun 8 14:10:50 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Mon, 8 Jun 2020 14:10:50 GMT Subject: [Rev 01] RFR: 6825: JMX defineEventProbes fails when no events in XMLDescriptor In-Reply-To: References: Message-ID: > This patch makes the agent JMX operation 'defineEventProbes' accept an xmlDecsription with no event tags. Previously, > the only way you could clear all current transforms was to supply the operation with an empty or null xmlDescription. > Now a file with the following structure will also clear all current transforms: > `` Jessye Coleman-Shapiro has updated the pull request incrementally with one additional commit since the last revision: Fix style issue ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/80/files - new: https://git.openjdk.java.net/jmc/pull/80/files/657db252..fc53d1c7 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/80/webrev.01 - incr: https://webrevs.openjdk.java.net/jmc/80/webrev.00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/80/head:pull/80 PR: https://git.openjdk.java.net/jmc/pull/80 From jescolem at openjdk.java.net Mon Jun 8 14:10:52 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Mon, 8 Jun 2020 14:10:52 GMT Subject: [Rev 01] RFR: 6825: JMX defineEventProbes fails when no events in XMLDescriptor In-Reply-To: References: Message-ID: On Sat, 6 Jun 2020 13:27:49 GMT, Marcus Hirt wrote: >> Jessye Coleman-Shapiro has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix style issue > > agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentController.java line 97: > >> 96: private Class[] defineSpecificTransforms(List descriptors) { >> 97: HashSet> classesToRetransform = new HashSet>(); >> 98: for (TransformDescriptor descriptor : descriptors) { > > Style: Set> classesToRetransform = new HashSet>(); Fixed in https://github.com/openjdk/jmc/pull/80/commits/fc53d1c790a85a8e29a527a662832c61473cd08b > agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentController.java line 83: > >> 82: private Class[] revertAllTransforms() { >> 83: HashSet> classesToRetransform = new HashSet>(); >> 84: List classNames = registry.clearAllTransformData(); > > Style: Set> classesToRetransform = new HashSet>(); fixed in https://github.com/openjdk/jmc/pull/80/commits/fc53d1c790a85a8e29a527a662832c61473cd08b ------------- PR: https://git.openjdk.java.net/jmc/pull/80 From almacdon at redhat.com Mon Jun 8 16:43:43 2020 From: almacdon at redhat.com (almacdon at redhat.com) Date: Mon, 08 Jun 2020 16:43:43 +0000 Subject: hg: jmc/jmc7: 2 new changesets Message-ID: <202006081643.058Ghh24006103@aojmv0008.oracle.com> Changeset: 399deb5ae377 Author: aptmac Date: 2020-06-08 12:23 -0400 URL: https://hg.openjdk.java.net/jmc/jmc7/rev/399deb5ae377 JMC-6821: Support JFR in OpenJDK 8 Reviewed-by: hirt ! application/org.openjdk.jmc.browser.attach/src/main/java/org/openjdk/jmc/browser/attach/LocalJVMToolkit.java ! application/org.openjdk.jmc.browser.jdp/src/main/java/org/openjdk/jmc/browser/jdp/JDPDescriptorProvider.java ! application/org.openjdk.jmc.rjmx.services.jfr/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/FlightRecorderServiceV2.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/ConnectionToolkit.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/JVMSupportToolkit.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/ICommercialFeaturesService.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/CommercialFeaturesServiceFactory.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/HotSpot23CommercialFeaturesService.java - application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/Jdk11CommercialFeaturesService.java + application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/NoCommercialFeaturesService.java ! application/org.openjdk.jmc.ui.common/src/main/java/org/openjdk/jmc/ui/common/jvm/JVMDescriptor.java ! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java ! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/services/CommercialFeaturesServiceTest.java ! configuration/spotbugs/spotbugs-exclude.xml Changeset: 63ec7d0ee8d9 Author: aptmac Date: 2020-06-08 12:37 -0400 URL: https://hg.openjdk.java.net/jmc/jmc7/rev/63ec7d0ee8d9 JMC-6822: JMC is asking to unlock Commercial Features on JFR enabled OpenJDK8 Reviewed-by: hirt ! application/org.openjdk.jmc.browser.attach/src/main/java/org/openjdk/jmc/browser/attach/LocalJVMToolkit.java ! application/org.openjdk.jmc.browser.jdp/src/main/java/org/openjdk/jmc/browser/jdp/JDPDescriptorProvider.java ! application/org.openjdk.jmc.rjmx.services.jfr/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/FlightRecorderServiceV1.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/ConnectionToolkit.java ! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/JVMSupportToolkit.java ! application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties ! application/org.openjdk.jmc.ui.common/src/main/java/org/openjdk/jmc/ui/common/jvm/JVMDescriptor.java ! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java From hirt at openjdk.java.net Mon Jun 8 18:10:00 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 8 Jun 2020 18:10:00 GMT Subject: [Rev 01] RFR: 6825: JMX defineEventProbes fails when no events in XMLDescriptor In-Reply-To: References: Message-ID: On Mon, 8 Jun 2020 14:10:50 GMT, Jessye Coleman-Shapiro wrote: >> This patch makes the agent JMX operation 'defineEventProbes' accept an xmlDecsription with no event tags. Previously, >> the only way you could clear all current transforms was to supply the operation with an empty or null xmlDescription. >> Now a file with the following structure will also clear all current transforms: >> `` > > Jessye Coleman-Shapiro has updated the pull request incrementally with one additional commit since the last revision: > > Fix style issue Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/80 From hirt at openjdk.java.net Mon Jun 8 18:11:41 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 8 Jun 2020 18:11:41 GMT Subject: RFR: 6819: Agent instrumentation causing stack map frame verification error In-Reply-To: <6nt-Xfv9SnVfHsL7J55LWxWFalRo24mvUHZdhaUYxE0=.4f82d590-ce1a-4db9-937d-61cfe8dc0adb@github.com> References: <6nt-Xfv9SnVfHsL7J55LWxWFalRo24mvUHZdhaUYxE0=.4f82d590-ce1a-4db9-937d-61cfe8dc0adb@github.com> Message-ID: <6LfTbYp6PLATEOmqoDhZibNCiT9Mf_tuA70Nq-P50p0=.ea888d8c-4359-492c-9872-e2479f9c5cf2@github.com> On Wed, 3 Jun 2020 16:27:58 GMT, Kangcheng Xu wrote: > This pr fixes [JMC-6819: Agent instrumentation causing stack map frame verification > error](https://bugs.openjdk.java.net/browse/JMC-6819). > The issue is reproducible when the target function consists of multiple exit points, and a compressed stack map frame > describing a jump target, followed by a function exit (eg. `*return` instructions). A simple example could be something > like(, given `javac` writes a compressed frame instead of a new expanded frame): public int echo(int arg) { > if (arg > 42) { > return 42; > } > return arg; > } > > When fixing [JMC-6532: Instrumentation fails for methods containing try-catch > clauses](https://bugs.openjdk.java.net/browse/JMC-6532), compressed frames were [forcefully > expanded](https://github.com/thegreystone/jmc-old/commit/e4acc9c93bfb21317caeead2d7646c7677c7a4a6#diff-af337d6e5f3fd3b585e66e0cebcb056fR132), > but the method was faulty. It turns out the ASM lib supports expanding frames automatically, which this pr adopts. > This pr comes with test cases generating bytecode for the example above. The generation is done by ASM lib manually to > make sure various compressed frame types (`same_frame`, `chop_frame`, `append_frame`) are tested. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/79 From aptmac at openjdk.java.net Mon Jun 8 20:29:59 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Mon, 8 Jun 2020 20:29:59 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow In-Reply-To: References: Message-ID: On Wed, 27 May 2020 19:26:42 GMT, Kangcheng Xu wrote: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Hi! I'm slowly getting through the code so bear with me here. My first impressions are that the UI looks nice and the controls work as you described. The transision between views is quick and the breadcrumbs work well. I'm writing now to describe a NPE I'm seeing which happens when enabling the treemap view while a heap dump is currently open and the JOverflow page is being viewed. This error can happen two ways (seems to be the same problem): 1. if a JOverflow page is currently being viewed while the treepmap view is added, the error "Failed to create the part's controls" is displayed. ![treemap-npe](https://user-images.githubusercontent.com/10425301/84072469-32796e80-a99d-11ea-88e8-7c0fe4c266a7.gif) 2. if a JOverflow page is opened in a different tab (i.e, the user is looking at something else like a JFR page) and the treepmap view is added, the view is created with the expected with the "No JOverflow editor selected". However, when going back and viewing the JOverflow page that was opened prior to the treemap view, a NPE is displayed in a dialog. ![treemap-opens-npe-on-old-1](https://user-images.githubusercontent.com/10425301/84072697-97cd5f80-a99d-11ea-8484-28f79bb40a96.gif) Having said that, it just seems to be a problem with the already opened heap dump; opening another `*.hprof` file will display the treemap view as expected (this is a continuation of the previous gif): ![treemap-opens-npe-on-old-2](https://user-images.githubusercontent.com/10425301/84073283-7c168900-a99e-11ea-8f65-de4281523929.gif) Error output: java.lang.NullPointerException at org.openjdk.jmc.joverflow.ext.treemap.TreemapPage.bindTreemapActions(TreemapPage.java:224) at org.openjdk.jmc.joverflow.ext.treemap.TreemapPage.allIncluded(TreemapPage.java:220) at org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:173) at org.openjdk.jmc.joverflow.ui.JOverflowUi.addModelListener(JOverflowUi.java:190) at org.openjdk.jmc.joverflow.ext.treemap.TreemapPageBookView.lambda$0(TreemapPageBookView.java:72) at org.openjdk.jmc.joverflow.ui.JOverflowEditor.addUiLoadedListener(JOverflowEditor.java:281) at org.openjdk.jmc.joverflow.ext.treemap.TreemapPageBookView.doCreatePage(TreemapPageBookView.java:72) at org.eclipse.ui.part.PageBookView.createPage(PageBookView.java:369) [...] ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From hdafgard at openjdk.java.net Tue Jun 9 14:46:57 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Tue, 9 Jun 2020 14:46:57 GMT Subject: RFR: 6831: Add chunk ranges to IItemCollection Message-ID: This PR adds the timeranges for all chunks that make up an IItemCollection, thus allowing downstream consumers, rules and the JMC UI (with plugins) to make accurate inferences with regards to the timespans when events could possibly have been emitted. ------------- Commit messages: - Add chunk ranges to IItemCollection Changes: https://git.openjdk.java.net/jmc/pull/81/files Webrev: https://webrevs.openjdk.java.net/jmc/81/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6831 Stats: 163 lines in 16 files changed: 124 ins; 0 del; 39 mod Patch: https://git.openjdk.java.net/jmc/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/81/head:pull/81 PR: https://git.openjdk.java.net/jmc/pull/81 From kxu at openjdk.java.net Tue Jun 9 15:16:27 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Tue, 9 Jun 2020 15:16:27 GMT Subject: [Rev 02] RFR: 6810: Create treemap viewer for JOverflow In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: fixed failing to create the part's controls due to NPE ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/cfb67837..2278edc7 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.02 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Tue Jun 9 15:57:49 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Tue, 9 Jun 2020 15:57:49 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow In-Reply-To: References: Message-ID: On Mon, 8 Jun 2020 20:27:53 GMT, Alex Macdonald wrote: >> This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It >> adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like >> JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. >> ![screen-shot](https://i.imgur.com/hTeNLtw.png) >> The treemap is not included in the building by default, therefore you'll need to manually enable the >> `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened >> in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. >> --- >> >> The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three >> components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes >> active. >> >> ### Toolbar actions: >> >> ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) >> >> Buttons are enabled and disabled automatically according to the state of the treemap. >> >> - Zoom-in button: zoom-in to the selected node of the treemap >> - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap >> - Zoom-off button: display the root node (ie. "[ROOT]" node) >> >> ### Breadcrumb >> >> ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) >> >> The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries >> are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. >> - Left mouse click: navigate to desired zooming level. >> >> ### Treemap >> >> ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) >> >> The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The >> larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with >> different background colours. User interactions on the treemap also updates the breadcrumb. >> - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. >> - Middle mouse click: display the root node (ie. "[ROOT]" node) >> - Right mouse click: zoom-out to the parent node of the currently expanded node >> - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) >> - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable >> format. >> >> --- >> >> Let me know what you think about the design and functionality. :) > > Hi! I'm slowly getting through the code so bear with me here. My first impressions are that the UI looks nice and the > controls work as you described. The transision between views is quick and the breadcrumbs work well. > I'm writing now to describe a NPE I'm seeing which happens when enabling the treemap view while a heap dump is > currently open and the JOverflow page is being viewed. > This error can happen two ways (seems to be the same problem): > > 1. if a JOverflow page is currently being viewed while the treepmap view is added, the error "Failed to create the > part's controls" is displayed. > ![treemap-npe](https://user-images.githubusercontent.com/10425301/84072469-32796e80-a99d-11ea-88e8-7c0fe4c266a7.gif) > 2. if a JOverflow page is opened in a different tab (i.e, the user is looking at something else like a JFR page) and > the treepmap view is added, the view is created with the expected with the "No JOverflow editor selected". However, > when going back and viewing the JOverflow page that was opened prior to the treemap view, a NPE is displayed in a > dialog. > ![treemap-opens-npe-on-old-1](https://user-images.githubusercontent.com/10425301/84072697-97cd5f80-a99d-11ea-8484-28f79bb40a96.gif) > Having said that, it just seems to be a problem with the already opened heap dump; opening another `*.hprof` file will > display the treemap view as expected (this is a continuation of the previous gif): > ![treemap-opens-npe-on-old-2](https://user-images.githubusercontent.com/10425301/84073283-7c168900-a99e-11ea-8f65-de4281523929.gif) > Error output: java.lang.NullPointerException at > org.openjdk.jmc.joverflow.ext.treemap.TreemapPage.bindTreemapActions(TreemapPage.java:224) at > org.openjdk.jmc.joverflow.ext.treemap.TreemapPage.allIncluded(TreemapPage.java:220) at > org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:173) at > org.openjdk.jmc.joverflow.ui.JOverflowUi.addModelListener(JOverflowUi.java:190) at > org.openjdk.jmc.joverflow.ext.treemap.TreemapPageBookView.lambda$0(TreemapPageBookView.java:72) at > org.openjdk.jmc.joverflow.ui.JOverflowEditor.addUiLoadedListener(JOverflowEditor.java:281) at > org.openjdk.jmc.joverflow.ext.treemap.TreemapPageBookView.doCreatePage(TreemapPageBookView.java:72) at > org.eclipse.ui.part.PageBookView.createPage(PageBookView.java:369) [...] Hi @aptmac! > I'm slowly getting through the code so bear with me here. Don't worry! Thank you very much for reviewing! The process understandably takes time. > I'm writing now to describe a NPE I'm seeing which happens when enabling the treemap view while a heap dump is > currently open and the JOverflow page is being viewed. I was able to reproduce the problem described. Sorry for not testing thoroughly. Such NPE is caused when the mouse click listener binding for the toolbar buttons happens before the actual view composites get created. I've added a null check to prevent this. Please verify the problem is resolved as for 2278edc. Thanks! ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From hirt at openjdk.java.net Tue Jun 9 17:05:50 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 9 Jun 2020 17:05:50 GMT Subject: RFR: 6831: Add chunk ranges to IItemCollection In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 14:38:03 GMT, Henrik Dafg?rd wrote: > This PR adds the timeranges for all chunks that make up an IItemCollection, thus allowing downstream consumers, rules > and the JMC UI (with plugins) to make accurate inferences with regards to the timespans when events could possibly have > been emitted. IItemCollection was meant to be general enough to eventually apply to other parts of JMC, for example the JMX console. Can we come up with a better name and definition than chunkRange? ------------- PR: https://git.openjdk.java.net/jmc/pull/81 From mwengner at openjdk.java.net Tue Jun 9 20:19:07 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 9 Jun 2020 20:19:07 GMT Subject: [Rev 04] RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: > stable flameview generation Miroslav Wengner has updated the pull request incrementally with one additional commit since the last revision: 6542: flameview cancelling ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/78/files - new: https://git.openjdk.java.net/jmc/pull/78/files/28abb117..5371fc05 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/78/webrev.04 - incr: https://webrevs.openjdk.java.net/jmc/78/webrev.03-04 Stats: 100 lines in 3 files changed: 71 ins; 2 del; 27 mod Patch: https://git.openjdk.java.net/jmc/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/78/head:pull/78 PR: https://git.openjdk.java.net/jmc/pull/78 From jescolem at openjdk.java.net Tue Jun 9 21:08:09 2020 From: jescolem at openjdk.java.net (Jessye Coleman-Shapiro) Date: Tue, 9 Jun 2020 21:08:09 GMT Subject: [Integrated] RFR: 6825: JMX defineEventProbes fails when no events in XMLDescriptor In-Reply-To: References: Message-ID: On Fri, 5 Jun 2020 17:01:28 GMT, Jessye Coleman-Shapiro wrote: > This patch makes the agent JMX operation 'defineEventProbes' accept an xmlDecsription with no event tags. Previously, > the only way you could clear all current transforms was to supply the operation with an empty or null xmlDescription. > Now a file with the following structure will also clear all current transforms: > `` This pull request has now been integrated. Changeset: 811c4d62 Author: Jessye Coleman-Shapiro Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/811c4d62 Stats: 50 lines in 1 file changed: 16 ins; 27 del; 7 mod 6825: JMX defineEventProbes fails when no events in XMLDescriptor Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/80 From kxu at openjdk.java.net Tue Jun 9 21:09:04 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Tue, 9 Jun 2020 21:09:04 GMT Subject: [Integrated] RFR: 6819: Agent instrumentation causing stack map frame verification error In-Reply-To: <6nt-Xfv9SnVfHsL7J55LWxWFalRo24mvUHZdhaUYxE0=.4f82d590-ce1a-4db9-937d-61cfe8dc0adb@github.com> References: <6nt-Xfv9SnVfHsL7J55LWxWFalRo24mvUHZdhaUYxE0=.4f82d590-ce1a-4db9-937d-61cfe8dc0adb@github.com> Message-ID: On Wed, 3 Jun 2020 16:27:58 GMT, Kangcheng Xu wrote: > This pr fixes [JMC-6819: Agent instrumentation causing stack map frame verification > error](https://bugs.openjdk.java.net/browse/JMC-6819). > The issue is reproducible when the target function consists of multiple exit points, and a compressed stack map frame > describing a jump target, followed by a function exit (eg. `*return` instructions). A simple example could be something > like(, given `javac` writes a compressed frame instead of a new expanded frame): public int echo(int arg) { > if (arg > 42) { > return 42; > } > return arg; > } > > When fixing [JMC-6532: Instrumentation fails for methods containing try-catch > clauses](https://bugs.openjdk.java.net/browse/JMC-6532), compressed frames were [forcefully > expanded](https://github.com/thegreystone/jmc-old/commit/e4acc9c93bfb21317caeead2d7646c7677c7a4a6#diff-af337d6e5f3fd3b585e66e0cebcb056fR132), > but the method was faulty. It turns out the ASM lib supports expanding frames automatically, which this pr adopts. > This pr comes with test cases generating bytecode for the example above. The generation is done by ASM lib manually to > make sure various compressed frame types (`same_frame`, `chop_frame`, `append_frame`) are tested. This pull request has now been integrated. Changeset: 75c14e13 Author: Kangcheng Xu Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/75c14e13 Stats: 172 lines in 5 files changed: 12 ins; 158 del; 2 mod 6819: Agent instrumentation causing stack map frame verification error Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/79 From mwengner at openjdk.java.net Tue Jun 9 22:11:56 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 9 Jun 2020 22:11:56 GMT Subject: [Rev 05] RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: > stable flameview generation 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 14 additional commits since the last revision: - Merge branch 'master' into feature/6542_Improve_calls_to_render_in_the_flame_view - 6542: correction spotless - 6542: clean up, correction - 6542: partial update - 6542: flameview cancelling - 6542: cleaning code - 6542: spotless correction - 6542: spotless needs - 6542: naming correction, models container check - 6542: stacktrace model utils - ... and 4 more: https://git.openjdk.java.net/jmc/compare/45acabcf...1b2b014e ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/78/files - new: https://git.openjdk.java.net/jmc/pull/78/files/5371fc05..1b2b014e Webrevs: - full: https://webrevs.openjdk.java.net/jmc/78/webrev.05 - incr: https://webrevs.openjdk.java.net/jmc/78/webrev.04-05 Stats: 299 lines in 9 files changed: 214 ins; 48 del; 37 mod Patch: https://git.openjdk.java.net/jmc/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/78/head:pull/78 PR: https://git.openjdk.java.net/jmc/pull/78 From mwengner at openjdk.java.net Tue Jun 9 22:11:57 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 9 Jun 2020 22:11:57 GMT Subject: RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: On Fri, 5 Jun 2020 14:35:20 GMT, Marcus Hirt wrote: >> stable flameview generation > > Sadly I can still make it go out of whack with these changes: > ![image](https://user-images.githubusercontent.com/16906077/83888656-71fc4c80-a74a-11ea-9c03-1cfa0c28569e.png) I've add a fix. ------------- PR: https://git.openjdk.java.net/jmc/pull/78 From mwengner at openjdk.java.net Tue Jun 9 22:12:09 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 9 Jun 2020 22:12:09 GMT Subject: RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 21:57:13 GMT, Miroslav Wengner wrote: >> Sadly I can still make it go out of whack with these changes: >> ![image](https://user-images.githubusercontent.com/16906077/83888656-71fc4c80-a74a-11ea-9c03-1cfa0c28569e.png) > > I've add a fix. maybe we can increase the Executor treads in FlameView, I've observed improvements. But calculating the model is still expensive. ------------- PR: https://git.openjdk.java.net/jmc/pull/78 From hdafgard at openjdk.java.net Wed Jun 10 14:33:31 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 10 Jun 2020 14:33:31 GMT Subject: [Rev 01] RFR: 6831: Add chunk ranges to IItemCollection In-Reply-To: References: Message-ID: <3h-CQCk5EQEftGyqT4aYAgDi0voRphOfPbGIKyG5TcI=.9074d72c-39a4-4e05-b9f5-3ee2636c9404@github.com> > This PR adds the timeranges for all chunks that make up an IItemCollection, thus allowing downstream consumers, rules > and the JMC UI (with plugins) to make accurate inferences with regards to the timespans when events could possibly have > been emitted. Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: Rename getChunkRanges to getTimeRanges ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/81/files - new: https://git.openjdk.java.net/jmc/pull/81/files/577e5be3..65e509ba Webrevs: - full: https://webrevs.openjdk.java.net/jmc/81/webrev.01 - incr: https://webrevs.openjdk.java.net/jmc/81/webrev.00-01 Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jmc/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/81/head:pull/81 PR: https://git.openjdk.java.net/jmc/pull/81 From aptmac at openjdk.java.net Wed Jun 10 15:37:08 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 10 Jun 2020 15:37:08 GMT Subject: RFR: 6531: Make the flame chart view render labels on windows In-Reply-To: References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com> <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com> <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com> Message-ID: On Wed, 27 May 2020 16:40:43 GMT, Thomas May wrote: > Dumb question, but would a shorter path be to run babel against d3 (Or have that as part of the build?) > > That would eliminate the need to maintain your own version and make updating a lot easier. Not a dumb question! I've given this a look, but I don't think Babel is able to help us out here. Specifically I'm finding a bunch of resources on the internet mixing up terminology.. Babel seems to be able to covert back to ECMA2015, which is ES6. Internet Explorer here requires ES5 (or "ECMA2009"), which is outside the realm of Babel's capabilities. > Hi Alex! > > I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585 is getting closer to release. Any chance you could see if > that works as a drop-in replacement? I've checked out the gerrit patch and managed to get it to build (it looks like there's still more work to be done to get tests to pass), but it doesn't seem to be working. I'm _mostly_ sure I added the relevant parts in the relevant places, but the new property `-Dorg.eclipse.swt.browser.DefaultType=chromium` doesn't seem to be having any effect. I'll keep an eye on this bug as it updates. ------------- PR: https://git.openjdk.java.net/jmc/pull/41 From hirt at openjdk.java.net Wed Jun 10 15:43:24 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 10 Jun 2020 15:43:24 GMT Subject: RFR: 6531: Make the flame chart view render labels on windows In-Reply-To: References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com> <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com> <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com> Message-ID: On Wed, 10 Jun 2020 15:34:54 GMT, Alex Macdonald wrote: >> Dumb question, but would a shorter path be to run babel against d3 (Or have that as part of the build?) >> >> That would eliminate the need to maintain your own version and make updating a lot easier. > >> Dumb question, but would a shorter path be to run babel against d3 (Or have that as part of the build?) >> >> That would eliminate the need to maintain your own version and make updating a lot easier. > > Not a dumb question! I've given this a look, but I don't think Babel is able to help us out here. Specifically I'm > finding a bunch of resources on the internet mixing up terminology.. > Babel seems to be able to covert back to ECMA2015, which is ES6. Internet Explorer here requires ES5 (or "ECMA2009"), > which is outside the realm of Babel's capabilities. >> Hi Alex! >> >> I think https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585 is getting closer to release. Any chance you could see if >> that works as a drop-in replacement? > > I've checked out the gerrit patch and managed to get it to build (it looks like there's still more work to be done to > get tests to pass), but it doesn't seem to be working. I'm _mostly_ sure I added the relevant parts in the relevant > places, but the new property `-Dorg.eclipse.swt.browser.DefaultType=chromium` doesn't seem to be having any effect. > I'll keep an eye on this bug as it updates. :'( ------------- PR: https://git.openjdk.java.net/jmc/pull/41 From hirt at openjdk.java.net Wed Jun 10 15:52:32 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 10 Jun 2020 15:52:32 GMT Subject: [Rev 01] RFR: 6831: Add chunk ranges to IItemCollection In-Reply-To: <3h-CQCk5EQEftGyqT4aYAgDi0voRphOfPbGIKyG5TcI=.9074d72c-39a4-4e05-b9f5-3ee2636c9404@github.com> References: <3h-CQCk5EQEftGyqT4aYAgDi0voRphOfPbGIKyG5TcI=.9074d72c-39a4-4e05-b9f5-3ee2636c9404@github.com> Message-ID: On Wed, 10 Jun 2020 14:33:31 GMT, Henrik Dafg?rd wrote: >> This PR adds the timeranges for all chunks that make up an IItemCollection, thus allowing downstream consumers, rules >> and the JMC UI (with plugins) to make accurate inferences with regards to the timespans when events could possibly have >> been emitted. > > Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: > > Rename getChunkRanges to getTimeRanges Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/81 From aptmac at openjdk.java.net Wed Jun 10 16:07:31 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 10 Jun 2020 16:07:31 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow In-Reply-To: References: Message-ID: <-4xPHD85ayfZQDPeu76K7fRQyn0Y-E7xkt_-dOMlph4=.71608500-9e79-480a-bca4-314260635dd3@github.com> On Tue, 9 Jun 2020 15:55:32 GMT, Kangcheng Xu wrote: >> Hi! I'm slowly getting through the code so bear with me here. My first impressions are that the UI looks nice and the >> controls work as you described. The transision between views is quick and the breadcrumbs work well. >> I'm writing now to describe a NPE I'm seeing which happens when enabling the treemap view while a heap dump is >> currently open and the JOverflow page is being viewed. >> This error can happen two ways (seems to be the same problem): >> >> 1. if a JOverflow page is currently being viewed while the treepmap view is added, the error "Failed to create the >> part's controls" is displayed. >> ![treemap-npe](https://user-images.githubusercontent.com/10425301/84072469-32796e80-a99d-11ea-88e8-7c0fe4c266a7.gif) >> 2. if a JOverflow page is opened in a different tab (i.e, the user is looking at something else like a JFR page) and >> the treepmap view is added, the view is created with the expected with the "No JOverflow editor selected". However, >> when going back and viewing the JOverflow page that was opened prior to the treemap view, a NPE is displayed in a >> dialog. >> ![treemap-opens-npe-on-old-1](https://user-images.githubusercontent.com/10425301/84072697-97cd5f80-a99d-11ea-8484-28f79bb40a96.gif) >> Having said that, it just seems to be a problem with the already opened heap dump; opening another `*.hprof` file will >> display the treemap view as expected (this is a continuation of the previous gif): >> ![treemap-opens-npe-on-old-2](https://user-images.githubusercontent.com/10425301/84073283-7c168900-a99e-11ea-8f65-de4281523929.gif) >> Error output: java.lang.NullPointerException at >> org.openjdk.jmc.joverflow.ext.treemap.TreemapPage.bindTreemapActions(TreemapPage.java:224) at >> org.openjdk.jmc.joverflow.ext.treemap.TreemapPage.allIncluded(TreemapPage.java:220) at >> org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:173) at >> org.openjdk.jmc.joverflow.ui.JOverflowUi.addModelListener(JOverflowUi.java:190) at >> org.openjdk.jmc.joverflow.ext.treemap.TreemapPageBookView.lambda$0(TreemapPageBookView.java:72) at >> org.openjdk.jmc.joverflow.ui.JOverflowEditor.addUiLoadedListener(JOverflowEditor.java:281) at >> org.openjdk.jmc.joverflow.ext.treemap.TreemapPageBookView.doCreatePage(TreemapPageBookView.java:72) at >> org.eclipse.ui.part.PageBookView.createPage(PageBookView.java:369) [...] > > Hi @aptmac! > >> I'm slowly getting through the code so bear with me here. > > Don't worry! Thank you very much for reviewing! The process understandably takes time. > >> I'm writing now to describe a NPE I'm seeing which happens when enabling the treemap view while a heap dump is >> currently open and the JOverflow page is being viewed. > > I was able to reproduce the problem described. Sorry for not testing thoroughly. Such NPE is caused when the mouse > click listener binding for the toolbar buttons happens before the actual view composites get created. I've added a null > check to prevent this. Please verify the problem is resolved as for 2278edc. Thanks! > I was able to reproduce the problem described. Sorry for not testing thoroughly. Such NPE is caused when the mouse > click listener binding for the toolbar buttons happens before the actual view composites get created. I've added a null > check to prevent this. Please verify the problem is resolved as for > [2278edc](https://github.com/openjdk/jmc/commit/2278edc7f8ae2908f15575bc905a4c1903fd68b5). Thanks! Thanks for checking out so quickly, yes the error doesn't happen anymore. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From hirt at openjdk.java.net Wed Jun 10 20:20:00 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 10 Jun 2020 20:20:00 GMT Subject: RFR: 6835: Adding developer guide for getting started with development Message-ID: This PR adds a short developer guide, to help newcomers getting started setting up the development environment. ------------- Commit messages: - Adding some line breaks - 6835: link from project readme - 6835: Devguide - first draft Changes: https://git.openjdk.java.net/jmc/pull/82/files Webrev: https://webrevs.openjdk.java.net/jmc/82/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6835 Stats: 100 lines in 14 files changed: 84 ins; 14 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/82/head:pull/82 PR: https://git.openjdk.java.net/jmc/pull/82 From github.com+348973+cimi at openjdk.java.net Fri Jun 12 09:37:02 2020 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Fri, 12 Jun 2020 09:37:02 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 09:33:47 GMT, Alex Ciminian wrote: >> This PR adds a short developer guide, to help newcomers getting started setting up the development environment. > > docs/devguide/README.md line 65: > >> 64: >> 65: Next select File | Import? and select Maven / Existing Maven Project again, but this time from the root. >> 66: > > I've been able to successfully follow the steps up to this point, but here I got an error: > > Screenshot 2020-06-10 at 23 04 34 src="https://user-images.githubusercontent.com/348973/84486996-0e1bdb80-ac96-11ea-8ae0-5ace8308fd7d.png"> > After importing the Maven projects from the jmc root directory I see compilation errors because of a missing jface > `ResourceLocator` path: > Screenshot 2020-06-11 at 00 31 22 src="https://user-images.githubusercontent.com/348973/84487139-39062f80-ac96-11ea-823b-f15f4f4b00a2.png"> > The jar is there but it looks like an old version: `org.eclipse.jface_3.14.0.v20180423-0714.jar`. I've tried manually > upgrading this jar and I've tried upgrading the plugin development environment but it didn't work - I don't know much > about eclipse, I need to dig into this a bit more. I'm running: Eclipse IDE for Eclipse Committers Version: 2020-03 (4.15.0) Build id: 20200313-1211 ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From github.com+348973+cimi at openjdk.java.net Fri Jun 12 09:37:02 2020 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Fri, 12 Jun 2020 09:37:02 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 20:08:38 GMT, Marcus Hirt wrote: > This PR adds a short developer guide, to help newcomers getting started setting up the development environment. docs/devguide/README.md line 65: > 64: > 65: Next select File | Import? and select Maven / Existing Maven Project again, but this time from the root. > 66: I've been able to successfully follow the steps up to this point, but here I got an error: Screenshot 2020-06-10 at 23 04 34 After importing the Maven projects from the jmc root directory I see compilation errors because of a missing jface `ResourceLocator` path: Screenshot 2020-06-11 at 00 31 22 The jar is there but it looks like an old version: `org.eclipse.jface_3.14.0.v20180423-0714.jar`. I've tried manually upgrading this jar and I've tried upgrading the plugin development environment but it didn't work - I don't know much about eclipse, I need to dig into this a bit more. ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From hirt at openjdk.java.net Fri Jun 12 12:33:31 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 12 Jun 2020 12:33:31 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 20:08:38 GMT, Marcus Hirt wrote: > This PR adds a short developer guide, to help newcomers getting started setting up the development environment. Hmm. Interesting. And you did set the active platform properly? ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From github.com+348973+cimi at openjdk.java.net Fri Jun 12 13:36:41 2020 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Fri, 12 Jun 2020 13:36:41 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 12:31:08 GMT, Marcus Hirt wrote: >> This PR adds a short developer guide, to help newcomers getting started setting up the development environment. > > Hmm. Interesting. And you did set the active platform properly? I have the active platform set to this: ![Screenshot 2020-06-12 at 13 55 18](https://user-images.githubusercontent.com/348973/84505203-39fa8980-acb5-11ea-8815-cfd4663d0805.png) I can build `core` without problems so I guess that's fine? I've also tried the 2020-03 configuration but that was yielding many more errors, so I switched back to this. ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From hirt at openjdk.java.net Fri Jun 12 14:00:55 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 12 Jun 2020 14:00:55 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 13:32:40 GMT, Alex Ciminian wrote: >> Hmm. Interesting. And you did set the active platform properly? > > I have the active platform set to this: > > ![Screenshot 2020-06-12 at 13 55 > 18](https://user-images.githubusercontent.com/348973/84505203-39fa8980-acb5-11ea-8815-cfd4663d0805.png) > I can build `core` without problems so I guess that's fine? > > I've also tried the 2020-03 configuration but that was yielding many more errors, so I switched back to this. Hmm, you should not have any problems with 2020-03. Photon is in queue for getting dropped eventually. ![image](https://user-images.githubusercontent.com/16906077/84510354-51da0980-acc5-11ea-964f-865a22eb6dd3.png) ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From hirt at openjdk.java.net Fri Jun 12 14:00:55 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 12 Jun 2020 14:00:55 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 13:57:04 GMT, Marcus Hirt wrote: >> I have the active platform set to this: >> >> ![Screenshot 2020-06-12 at 13 55 >> 18](https://user-images.githubusercontent.com/348973/84505203-39fa8980-acb5-11ea-8815-cfd4663d0805.png) >> I can build `core` without problems so I guess that's fine? >> >> I've also tried the 2020-03 configuration but that was yielding many more errors, so I switched back to this. > > Hmm, you should not have any problems with 2020-03. Photon is in queue for getting dropped eventually. > > ![image](https://user-images.githubusercontent.com/16906077/84510354-51da0980-acc5-11ea-964f-865a22eb6dd3.png) Try opening the platform file for 2020-03, let if find and resolve everything, and then click set as active platform. ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From hdafgard at openjdk.java.net Fri Jun 12 15:04:19 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Fri, 12 Jun 2020 15:04:19 GMT Subject: [Integrated] RFR: 6831: Add chunk ranges to IItemCollection In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 14:38:03 GMT, Henrik Dafg?rd wrote: > This PR adds the timeranges for all chunks that make up an IItemCollection, thus allowing downstream consumers, rules > and the JMC UI (with plugins) to make accurate inferences with regards to the timespans when events could possibly have > been emitted. This pull request has now been integrated. Changeset: 439f3211 Author: Henrik Dafg?rd URL: https://git.openjdk.java.net/jmc/commit/439f3211 Stats: 163 lines in 16 files changed: 0 ins; 124 del; 39 mod 6831: Add chunk ranges to IItemCollection Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/81 From github.com+348973+cimi at openjdk.java.net Fri Jun 12 17:43:44 2020 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Fri, 12 Jun 2020 17:43:44 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 13:58:43 GMT, Marcus Hirt wrote: >> Hmm, you should not have any problems with 2020-03. Photon is in queue for getting dropped eventually. >> >> ![image](https://user-images.githubusercontent.com/16906077/84510354-51da0980-acc5-11ea-964f-865a22eb6dd3.png) > > Try opening the platform file for 2020-03, let if find and resolve everything, and then click set as active platform. ?? This solved my problem. I was using eclipse-photon as the target platform instead of `jmc-target-2020-03`, after changing this the build succeeded. I was able to complete all the steps successfully with a fresh install of Eclipse. ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From aptmac at openjdk.java.net Mon Jun 15 19:28:55 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Mon, 15 Jun 2020 19:28:55 GMT Subject: [Rev 02] RFR: 6810: Create treemap viewer for JOverflow In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 15:16:27 GMT, Kangcheng Xu wrote: >> This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It >> adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like >> JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. >> ![screen-shot](https://i.imgur.com/hTeNLtw.png) >> The treemap is not included in the building by default, therefore you'll need to manually enable the >> `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened >> in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. >> --- >> >> The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three >> components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes >> active. >> >> ### Toolbar actions: >> >> ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) >> >> Buttons are enabled and disabled automatically according to the state of the treemap. >> >> - Zoom-in button: zoom-in to the selected node of the treemap >> - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap >> - Zoom-off button: display the root node (ie. "[ROOT]" node) >> >> ### Breadcrumb >> >> ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) >> >> The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries >> are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. >> - Left mouse click: navigate to desired zooming level. >> >> ### Treemap >> >> ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) >> >> The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The >> larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with >> different background colours. User interactions on the treemap also updates the breadcrumb. >> - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. >> - Middle mouse click: display the root node (ie. "[ROOT]" node) >> - Right mouse click: zoom-out to the parent node of the currently expanded node >> - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) >> - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable >> format. >> >> --- >> >> Let me know what you think about the design and functionality. :) > > Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: > > fixed failing to create the part's controls due to NPE Hi Arvin, I've given this a look through, and it looks good, just have some minor nits that I've added as review comments. application/org.openjdk.jmc.feature.joverflow.ext.treemap/feature.properties line 37: > 36: copyright=Copyright \u00A9 2020, Oracle and/or its affiliates. All rights reserved. > 37: description=This feature adds a treemap view to JOverflow visualizing memory usage by packages/classes. > 38: descriptionUrl=http://www.oracle.com/missioncontrol Perhaps there should be a 'for' in between JOverflow and visualizing: "This feature adds a treemap view to JOverflow _for_ visualizing memory usage by packages/classes." application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/TreemapAction.java line 41: > 40: > 41: /* package-private */ class TreemapAction extends Action { > 42: private final TreemapActionType actionType; I guess this comment kind of applies across the whole patch; I'm not against having a package private comment (it's kind of nice for the methods at least IMO), however if kept I'd prefer if they followed a similar standard. For example, here it's placed before the class, however elsewhere like `Treemap.checkNull()` it's on the previous line. application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/TreemapAction.java line 67: > 66: enum TreemapActionType { > 67: ZOOM_IN(Messages.TreemapAction_ZOOM_IN_DESCRIPTION, IAction.AS_PUSH_BUTTON, CoreImages.ZOOM_IN), // > 68: ZOOM_OUT(Messages.TreemapAction_ZOOM_OUT_DESCRIPTION, IAction.AS_PUSH_BUTTON, CoreImages.ZOOM_OUT), // More of a note, but I'm in favor the the `//` usage for formatting and making it look cleaner.. without them it seems spotless will re-format these lines. application/org.openjdk.jmc.feature.joverflow.ext.treemap/feature.xml line 56: > 55: > 56: 57: id="org.openjdk.jmc.joverflow.ext.treemap" indented a tab here instead of spaces application/org.openjdk.jmc.joverflow.ext.treemap/plugin.xml line 39: > 38: > 39: > 40: 69: /* package-private */ class TreemapPage extends Page implements ModelListener { > 70: private static final Color[] COLORS = {new Color(Display.getCurrent(), 250, 206, 210), // red > 71: new Color(Display.getCurrent(), 185, 214, 255), // blue Note: I thought this line looked a bit "off" with the color directly proceeding the `{`, but this seems to be the way spotless wants it to be formatted. Just a heads up to anyone else checking this out... application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/TreemapAction.java line 69: > 68: ZOOM_OUT(Messages.TreemapAction_ZOOM_OUT_DESCRIPTION, IAction.AS_PUSH_BUTTON, CoreImages.ZOOM_OUT), // > 69: ZOOM_OFF(Messages.TreemapAction_ZOOM_OFF_DESCRIPTION, IAction.AS_PUSH_BUTTON, CoreImages.ZOOM_OFF); > 70: For the zoom off action, I feel like the icon should closer represent something to a "reset" icon, maybe like the one JOverflow uses? Otherwise it's not immediately obvious what the button does without reading it's tooltip. application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/TreemapPageBookView.java line 114: > 113: new TreemapAction(TreemapAction.TreemapActionType.ZOOM_OUT), // > 114: new TreemapAction(TreemapAction.TreemapActionType.ZOOM_OFF), // > 115: }; trailing comma application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/swt/TreemapToolTip.java line 55: > 54: protected Composite createToolTipContentArea(Event event, Composite parent) { > 55: Composite ret = new Composite(parent, SWT.NONE); > 56: minor nit regarding variable name choice, is ret supposed to be rect? application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/swt/Breadcrumb.java line 350: > 349: */ > 350: public BreadcrumbItem getSelection() { > 351: checkWidget(); does this get called anywhere? ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From mwengner at openjdk.java.net Tue Jun 16 09:08:36 2020 From: mwengner at openjdk.java.net (Miroslav Wengner) Date: Tue, 16 Jun 2020 09:08:36 GMT Subject: [Rev 06] RFR: 6542: Improve calls to render in the flame view In-Reply-To: References: Message-ID: > stable flameview generation 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 17 additional commits since the last revision: - 6542: cleanup - 6542: partial commit stable - Merge branch 'master' of https://github.com/openjdk/jmc into feature/6542_Improve_calls_to_render_in_the_flame_view - Merge branch 'master' into feature/6542_Improve_calls_to_render_in_the_flame_view - 6542: correction spotless - 6542: clean up, correction - 6542: partial update - 6542: flameview cancelling - 6542: cleaning code - 6542: spotless correction - ... and 7 more: https://git.openjdk.java.net/jmc/compare/32c2f3ab...bf84149c ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/78/files - new: https://git.openjdk.java.net/jmc/pull/78/files/1b2b014e..bf84149c Webrevs: - full: https://webrevs.openjdk.java.net/jmc/78/webrev.06 - incr: https://webrevs.openjdk.java.net/jmc/78/webrev.05-06 Stats: 169 lines in 17 files changed: 127 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jmc/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/78/head:pull/78 PR: https://git.openjdk.java.net/jmc/pull/78 From kxu at openjdk.java.net Wed Jun 17 19:03:00 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 17 Jun 2020 19:03:00 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v4] In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: fixed up minor nits in code style ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/2278edc7..fbb90fbc Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.03 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.02-03 Stats: 30 lines in 9 files changed: 1 ins; 4 del; 25 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Wed Jun 17 19:03:02 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 17 Jun 2020 19:03:02 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 18:47:45 GMT, Alex Macdonald wrote: >> Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed failing to create the part's controls due to NPE > > application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/swt/Breadcrumb.java > line 350: >> 349: */ >> 350: public BreadcrumbItem getSelection() { >> 351: checkWidget(); > > does this get called anywhere? No, it doesn't, but it makes sense to have this public method to an SWT viewer, just like `Tree` and `List`. I believe this allows potential new features in the future to work together with a `Breadcrumb`. > application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/swt/TreemapToolTip.java > line 55: >> 54: protected Composite createToolTipContentArea(Event event, Composite parent) { >> 55: Composite ret = new Composite(parent, SWT.NONE); >> 56: > > minor nit regarding variable name choice, is ret supposed to be rect? It actually means "return" (value). Bad naming here. I've changed this to `container` instead. > application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/TreemapPage.java > line 70: >> 69: /* package-private */ class TreemapPage extends Page implements ModelListener { >> 70: private static final Color[] COLORS = {new Color(Display.getCurrent(), 250, 206, 210), // red >> 71: new Color(Display.getCurrent(), 185, 214, 255), // blue > > Note: I thought this line looked a bit "off" with the color directly proceeding the `{`, but this seems to be the way > spotless wants it to be formatted. Just a heads up to anyone else checking this out... I've added a `//` to make spotless happy with starting the array content on a new line. > application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/TreemapAction.java > line 41: >> 40: >> 41: /* package-private */ class TreemapAction extends Action { >> 42: private final TreemapActionType actionType; > > I guess this comment kind of applies across the whole patch; I'm not against having a package private comment (it's > kind of nice for the methods at least IMO), however if kept I'd prefer if they followed a similar standard. > For example, here it's placed before the class, however elsewhere like `Treemap.checkNull()` it's on the previous line. `/* package-private */` comments are now consistently placed on the same lines as the function/class it's referring to. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Wed Jun 17 19:29:23 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 17 Jun 2020 19:29:23 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v5] In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: replaced the reset icon to something more obvious ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/fbb90fbc..4d5e64c7 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.04 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.03-04 Stats: 87 lines in 8 files changed: 82 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Wed Jun 17 19:29:23 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 17 Jun 2020 19:29:23 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 20:34:03 GMT, Alex Macdonald wrote: >> Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed failing to create the part's controls due to NPE > > application/org.openjdk.jmc.joverflow.ext.treemap/src/main/java/org/openjdk/jmc/joverflow/ext/treemap/TreemapAction.java > line 69: >> 68: ZOOM_OUT(Messages.TreemapAction_ZOOM_OUT_DESCRIPTION, IAction.AS_PUSH_BUTTON, CoreImages.ZOOM_OUT), // >> 69: ZOOM_OFF(Messages.TreemapAction_ZOOM_OFF_DESCRIPTION, IAction.AS_PUSH_BUTTON, CoreImages.ZOOM_OFF); >> 70: > > For the zoom off action, I feel like the icon should closer represent something to a "reset" icon, maybe like the one > JOverflow uses? Otherwise it's not immediately obvious what the button does without reading it's tooltip. Icon replaced with the one JOverflow uses. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Wed Jun 17 19:43:03 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 17 Jun 2020 19:43:03 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v6] In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: made spotless happy ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/4d5e64c7..268de328 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.05 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From github.com+803621+bric3 at openjdk.java.net Wed Jun 17 20:24:20 2020 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Wed, 17 Jun 2020 20:24:20 GMT Subject: RFR: 6364: Improvements to the Thread Graph In-Reply-To: References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com> <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com> Message-ID: <1rFwH_fS08Lr6VT09rAPl5aOjeoDyyfAK1l1DaktMB8=.e94b0d05-4244-46b2-848e-c83f7aa3917a@github.com> On Wed, 29 Apr 2020 14:00:43 GMT, Alex Macdonald wrote: >> Hi @aptmac - could you update this PR, please? Thinking of taking a closer look at it during the jmc dev hangout >> tonight. :) > > Hi @thegreystone, I rebased the branch yesterday to be on top of master, and included a new commit based on the > feedback that makes the dropdown lane filter act like the Edit Lanes Dialog (screenshot below). Does the outdated tag > automatically remove itself what some criteria is met? Edit: I also see that the checks failed, it looks like there's > something wrong with the builds at the moment, I've been seeing similar errors on my travis builds as well > ![2020-04-27-171139_1177x829_scrot](https://user-images.githubusercontent.com/10425301/80604806-301c1000-8a00-11ea-82ce-88e55cc5d744.png) Hi just for the record how this is handled when there's a lot of threads to deal with. ![image](https://user-images.githubusercontent.com/803621/84946230-a8da4700-b0e8-11ea-9058-54a51490fd5a.png) ------------- PR: https://git.openjdk.java.net/jmc/pull/27 From aptmac at openjdk.java.net Wed Jun 17 20:35:10 2020 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Wed, 17 Jun 2020 20:35:10 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v6] In-Reply-To: References: Message-ID: <093cAkZ2f8n-HkXiVR2r971C_AopxPUu10v1o4S_vXA=.cef4611a-92a6-4379-a1ec-269849ab66c0@github.com> On Wed, 17 Jun 2020 19:43:03 GMT, Kangcheng Xu wrote: >> This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It >> adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like >> JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. >> ![screen-shot](https://i.imgur.com/hTeNLtw.png) >> The treemap is not included in the building by default, therefore you'll need to manually enable the >> `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened >> in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. >> --- >> >> The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three >> components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes >> active. >> >> ### Toolbar actions: >> >> ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) >> >> Buttons are enabled and disabled automatically according to the state of the treemap. >> >> - Zoom-in button: zoom-in to the selected node of the treemap >> - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap >> - Zoom-off button: display the root node (ie. "[ROOT]" node) >> >> ### Breadcrumb >> >> ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) >> >> The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries >> are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. >> - Left mouse click: navigate to desired zooming level. >> >> ### Treemap >> >> ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) >> >> The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The >> larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with >> different background colours. User interactions on the treemap also updates the breadcrumb. >> - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. >> - Middle mouse click: display the root node (ie. "[ROOT]" node) >> - Right mouse click: zoom-out to the parent node of the currently expanded node >> - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) >> - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable >> format. >> >> --- >> >> Let me know what you think about the design and functionality. :) > > Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: > > made spotless happy Looks good to me, thanks for making the changes. I'll open a new bug for this (or take a look if one exists already ..) because it's outside of the scope of this patch, but it would be nice if newly added views automatically updated in response what's currently being viewed on screen. For example, if I had a JOverflow page open first and then I add the Treemap view, the treemap view has to wait for me to make a selection. Whereas if I had the Treemap view already open and then I opened an hprof file then the treemap view draws the default selection. This isn't a problem specific to the treemap view; it's easy to recreate with other optional views like the flameview for example. ------------- Marked as reviewed by aptmac (Committer). PR: https://git.openjdk.java.net/jmc/pull/77 From erik.gahlin at oracle.com Fri Jun 19 12:57:09 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 19 Jun 2020 14:57:09 +0200 Subject: Change to crash recordings Message-ID: <27A94C48-BB83-44A7-A8FF-5A5F11C94722@oracle.com> Hi, I am thinking of making a change to JFR that will impact how crash recordings are written. This could could impact the JMC parser. When an event is registered, which typically happens when an event class is loaded, we build the binary form of the metadata event in Java and push it into the JVM in a binary form (a byte array). The reason we do this with every event registration is so we always have the latest metadata ready to write in case of a JVM crash, in which case we can?t execute Java code. With Event Streaming, we changed how JFR works and we now flush data once every second and if an event has been registered during that period, we emit a new metadata event. This means the data in the repository is guaranteed to have proper metadata up until the last second. Previously we only wrote the metadata event at the end of a chunk, which could potentially take a very long time before it was finished (depending on the configuration). This made it more important to have an updated version of the metadata in case of a crash. What I want to do is stop building the metadata event with every registration. This is especially problematic if you have many events you want to register. The drawback is that a parser can?t understand how parse an event that has been registered in the last second from a crash recording. The way the JDK parser handles this is to skip the event if it is an unknown event type. In the beginning of every event the size is written, so it is very easy to skip. We also log that an unknown event type was found. I think it would be good if the JMC parser could do the same, if it isn?t already? I looked at source code briefly and it seemed this was not the case, but I?m not sure. Since the size of the metadata byte array grows with the number of events, the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes. With the change, the time to register and emit 50 events drops from about 350 ms to 50 ms. Since the size of the metadata byte array grows with the number of events the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes with the current implementation. See. https://bugs.openjdk.java.net/browse/JDK-8242593 I?m not planning to bump the file format version. Crash recordings are always a best effort. There is no guarantee that they will succeed, with or without this change. Erik From marcus at hirt.se Fri Jun 19 13:15:23 2020 From: marcus at hirt.se (Marcus Hirt) Date: Fri, 19 Jun 2020 15:15:23 +0200 Subject: Sv: Change to crash recordings In-Reply-To: <27A94C48-BB83-44A7-A8FF-5A5F11C94722@oracle.com> References: <27A94C48-BB83-44A7-A8FF-5A5F11C94722@oracle.com> Message-ID: <02d301d6463b$b0a338b0$11e9aa10$@hirt.se> Hi Erik, We'd be happy to update the parser! It would be a great help if you could attach a small recording where this occurs here: https://bugs.openjdk.java.net/browse/JMC-6846 Kind regards, Marcus -----Ursprungligt meddelande----- Fr?n: jmc-dev F?r Erik Gahlin Skickat: den 19 juni 2020 14:57 Till: jmc-dev at openjdk.java.net ?mne: Change to crash recordings Hi, I am thinking of making a change to JFR that will impact how crash recordings are written. This could could impact the JMC parser. When an event is registered, which typically happens when an event class is loaded, we build the binary form of the metadata event in Java and push it into the JVM in a binary form (a byte array). The reason we do this with every event registration is so we always have the latest metadata ready to write in case of a JVM crash, in which case we can?t execute Java code. With Event Streaming, we changed how JFR works and we now flush data once every second and if an event has been registered during that period, we emit a new metadata event. This means the data in the repository is guaranteed to have proper metadata up until the last second. Previously we only wrote the metadata event at the end of a chunk, which could potentially take a very long time before it was finished (depending on the configuration). This made it more important to have an updated version of the metadata in case of a crash. What I want to do is stop building the metadata event with every registration. This is especially problematic if you have many events you want to register. The drawback is that a parser can?t understand how parse an event that has been registered in the last second from a crash recording. The way the JDK parser handles this is to skip the event if it is an unknown event type. In the beginning of every event the size is written, so it is very easy to skip. We also log that an unknown event type was found. I think it would be good if the JMC parser could do the same, if it isn?t already? I looked at source code briefly and it seemed this was not the case, but I?m not sure. Since the size of the metadata byte array grows with the number of events, the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes. With the change, the time to register and emit 50 events drops from about 350 ms to 50 ms. Since the size of the metadata byte array grows with the number of events the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes with the current implementation. See. https://bugs.openjdk.java.net/browse/JDK-8242593 I?m not planning to bump the file format version. Crash recordings are always a best effort. There is no guarantee that they will succeed, with or without this change. Erik From ghb at openjdk.java.net Fri Jun 19 14:26:58 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 19 Jun 2020 14:26:58 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 20:08:38 GMT, Marcus Hirt wrote: > This PR adds a short developer guide, to help newcomers getting started setting up the development environment. Would it be helpful to have image with prefix ? (looks better for user to go by order). docs/devguide/README.md line 15: > 14: > 15: ![Workspace Selection](images/workspace.png) > 16: [nit] Pre-fixing image name like 01-workspace.png , 02-setinstalledjre.png... 10-formattersettings.png . would help a bit if the user wants to view these settings in order in there Folder (Explorer / Finder). ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From hirt at openjdk.java.net Fri Jun 19 20:23:53 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 19 Jun 2020 20:23:53 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Fri, 19 Jun 2020 14:23:44 GMT, Guru Hb wrote: >> This PR adds a short developer guide, to help newcomers getting started setting up the development environment. > > docs/devguide/README.md line 15: > >> 14: >> 15: ![Workspace Selection](images/workspace.png) >> 16: > > [nit] Pre-fixing image name like 01-workspace.png , 02-setinstalledjre.png...12-formattersettings.png . would help a > bit if the user wants to view these settings in order in there Folder (Explorer / Finder). > ![image](https://user-images.githubusercontent.com/1955702/85143630-9cc8c380-b267-11ea-951d-828f7f3da11e.png) I'd like to keep it as it is. Partly because I'm lazy, but also because if we extend or change the devguide, we'd have to potentially change the names of a lot of files and the README in a corresponding number of places. ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From ghb at openjdk.java.net Fri Jun 19 23:51:12 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Fri, 19 Jun 2020 23:51:12 GMT Subject: RFR: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 20:08:38 GMT, Marcus Hirt wrote: > This PR adds a short developer guide, to help newcomers getting started setting up the development environment. Marked as reviewed by ghb (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From erik.gahlin at oracle.com Sat Jun 20 11:47:23 2020 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sat, 20 Jun 2020 13:47:23 +0200 Subject: Change to crash recordings In-Reply-To: <02d301d6463b$b0a338b0$11e9aa10$@hirt.se> References: <27A94C48-BB83-44A7-A8FF-5A5F11C94722@oracle.com> <02d301d6463b$b0a338b0$11e9aa10$@hirt.se> Message-ID: Great! Added a recording to the bug. Erik > On 19 Jun 2020, at 15:15, Marcus Hirt wrote: > > Hi Erik, > > We'd be happy to update the parser! It would be a great help if you could attach a small recording where this occurs here: > https://bugs.openjdk.java.net/browse/JMC-6846 > > Kind regards, > Marcus > > -----Ursprungligt meddelande----- > Fr?n: jmc-dev F?r Erik Gahlin > Skickat: den 19 juni 2020 14:57 > Till: jmc-dev at openjdk.java.net > ?mne: Change to crash recordings > > Hi, > > I am thinking of making a change to JFR that will impact how crash recordings are written. > > This could could impact the JMC parser. > > When an event is registered, which typically happens when an event class is loaded, we build the binary form of the metadata event in Java and push it into the JVM in a binary form (a byte array). The reason we do this with every event registration is so we always have the latest metadata ready to write in case of a JVM crash, in which case we can?t execute Java code. > > With Event Streaming, we changed how JFR works and we now flush data once every second and if an event has been registered during that period, we emit a new metadata event. This means the data in the repository is guaranteed to have proper metadata up until the last second. Previously we only wrote the metadata event at the end of a chunk, which could potentially take a very long time before it was finished (depending on the configuration). This made it more important to have an updated version of the metadata in case of a crash. > > What I want to do is stop building the metadata event with every registration. This is especially problematic if you have many events you want to register. > > The drawback is that a parser can?t understand how parse an event that has been registered in the last second from a crash recording. The way the JDK parser handles this is to skip the event if it is an unknown event type. In the beginning of every event the size is written, so it is very easy to skip. We also log that an unknown event type was found. > > I think it would be good if the JMC parser could do the same, if it isn?t already? I looked at source code briefly and it seemed this was not the case, but I?m not sure. > > Since the size of the metadata byte array grows with the number of events, the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes. With the change, the time to register and emit 50 events drops from about 350 ms to 50 ms. Since the size of the metadata byte array grows with the number of events the complexity becomes O(n^2), so if you want to register a large number of events, it can take minutes with the current implementation. See. > https://bugs.openjdk.java.net/browse/JDK-8242593 > > I?m not planning to bump the file format version. Crash recordings are always a best effort. There is no guarantee that they will succeed, with or without this change. > > Erik > From hirt at openjdk.java.net Sun Jun 21 13:04:21 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sun, 21 Jun 2020 13:04:21 GMT Subject: Integrated: 6835: Adding developer guide for getting started with development In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 20:08:38 GMT, Marcus Hirt wrote: > This PR adds a short developer guide, to help newcomers getting started setting up the development environment. This pull request has now been integrated. Changeset: 2edae364 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/2edae364 Stats: 100 lines in 14 files changed: 14 ins; 84 del; 2 mod 6835: Adding developer guide for getting started with development Reviewed-by: ghb ------------- PR: https://git.openjdk.java.net/jmc/pull/82 From hirt at openjdk.java.net Mon Jun 22 18:48:06 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 22 Jun 2020 18:48:06 GMT Subject: RFR: 6847: Upgrading to the Eclipse 2020-06 platform Message-ID: Note that this one should probably go in after we get JMC-6838 in. That said, we can review it and get it ready for show-time. ------------- Commit messages: - 6847: Upgrading to the Eclipse 2020-06 platform Changes: https://git.openjdk.java.net/jmc/pull/85/files Webrev: https://webrevs.openjdk.java.net/jmc/85/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6847 Stats: 157 lines in 5 files changed: 154 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/85/head:pull/85 PR: https://git.openjdk.java.net/jmc/pull/85 From hirt at openjdk.java.net Mon Jun 22 19:05:43 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 22 Jun 2020 19:05:43 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v6] In-Reply-To: <093cAkZ2f8n-HkXiVR2r971C_AopxPUu10v1o4S_vXA=.cef4611a-92a6-4379-a1ec-269849ab66c0@github.com> References: <093cAkZ2f8n-HkXiVR2r971C_AopxPUu10v1o4S_vXA=.cef4611a-92a6-4379-a1ec-269849ab66c0@github.com> Message-ID: On Wed, 17 Jun 2020 20:33:01 GMT, Alex Macdonald wrote: >> Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: >> >> made spotless happy > > Looks good to me, thanks for making the changes. > > I'll open a new bug for this (or take a look if one exists already ..) because it's outside of the scope of this patch, > but it would be nice if newly added views automatically updated in response what's currently being viewed on screen. > For example, if I had a JOverflow page open first and then I add the Treemap view, the treemap view has to wait for me > to make a selection. Whereas if I had the Treemap view already open and then I opened an hprof file then the treemap > view draws the default selection. This isn't a problem specific to the treemap view; it's easy to recreate with other > optional views like the flameview for example. What is the intended distribution model? Should this be something from the update site, or delivered as part of the standard offering? ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From hirt at openjdk.java.net Mon Jun 22 19:05:43 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 22 Jun 2020 19:05:43 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v6] In-Reply-To: References: <093cAkZ2f8n-HkXiVR2r971C_AopxPUu10v1o4S_vXA=.cef4611a-92a6-4379-a1ec-269849ab66c0@github.com> Message-ID: On Mon, 22 Jun 2020 19:01:54 GMT, Marcus Hirt wrote: >> Looks good to me, thanks for making the changes. >> >> I'll open a new bug for this (or take a look if one exists already ..) because it's outside of the scope of this patch, >> but it would be nice if newly added views automatically updated in response what's currently being viewed on screen. >> For example, if I had a JOverflow page open first and then I add the Treemap view, the treemap view has to wait for me >> to make a selection. Whereas if I had the Treemap view already open and then I opened an hprof file then the treemap >> view draws the default selection. This isn't a problem specific to the treemap view; it's easy to recreate with other >> optional views like the flameview for example. > > What is the intended distribution model? Should this be something from the update site, or delivered as part of the > standard offering? If part of standard JOverflow, then you might as well put it in the JOverflow bundle. It can still be optional to open the view. If you want this to be an optional bundle from the update sites, then you need to add them to the update sites. Personally I think this might as well be part of JOverflow directly. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From neugens at redhat.com Tue Jun 23 15:02:46 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 23 Jun 2020 17:02:46 +0200 Subject: Call for Discussion: New Project: Hamburg Message-ID: Hello OpenJDK developers. [I apologise, this is a long email, but I thought sharing more details would be useful for the discussion.] I would like to start a discussion for a new Project, Project Hamburg [1], whose primary goal is to address the issue of exposing and organising JFR recordings within a container setup, where direct access to the target JVM is not possible. The recent discussion about the tentative backport of the Streaming API for JFR to 11u and 8u has highlighted the desire to have a standardised way to easily obtain the JFR recordings not only for (quasi) real time monitoring but also as a mean of accessing event metrics from OpenJDKs within remote installations, like those in servers deployments and specifically from within containers - for example Kubernetes/OpenShift-managed cloud. In the last few months, some of us have been working on a project that aims to make it easier to use JFR and JDK Mission Control in those contexts, and I would like to start a discussion about potentially promoting our code as an official OpenJDK Project, where it may be useful for a larger community of developers. At the current state, Project Hamburg lives in a github repository under the name ?Container-JFR?, and has several components designed to work together at various [optional] levels of integration, the proposed Project will maintain overall the same layout. [Container JFR - https://github.com/rh-jmc-team/container-jfr] A containerized web service that communicates with JVMs in the same Kubernetes namespace. This communication involves invoking JFR operations over remote JMX, which is made available by the VMs' corresponding Kubernetes Services, and does not need to be exposed to the external world. Instead, clients can interact with Container JFR via a WebSocket command-based interface. These commands include operations like starting and stopping recordings with given options, listing in-memory recordings, listing event types, and saving a recording to persistent storage, etc... This web service also serves raw JFR files for download and analysis with JMC, and generates HTML reports identical to JMC's automated analysis. [Container JFR Core - https://github.com/rh-jmc-team/container-jfr-core] This project is a dependency of Container JFR. It contains interfaces and utilities for calling JMC code to establish remote JMX connections and communicate with JFR. The JMC dependencies are abstracted so we can replace this module without requiring access to the JMC API (although since JMC is also an OpenJDK Project we think this is not a problem). [Container JFR Web - https://github.com/rh-jmc-team/container-jfr-web] A front-end to graphically communicate with Container JFR via web browser. It allows the user to connect to a JVM from a drop down list of available JVMs. Once connected, Container JFR Web displays a table of available event types and their options. Users can then use a wizard to create a recording, and see a list of recordings present in that JVM. For each recording, the user can see the automated analysis results provided by JMC code, save the recording to persistent in-cluster storage, download the recording to local disk, or view compatible metrics in a Grafana dashboard. This mimics some of the functionality of JMC to provide an overview of the target JVM and offers the option to download the JFR file further analysis in JMC. [JFR Datasource - https://github.com/rh-jmc-team/jfr-datasource] This project parses a provided JFR file and serves it as a Grafana SimpleJson datasource in order to populate a Grafana dashboard with metrics from the JFR file. [Container JFR Operator - https://github.com/rh-jmc-team/container-jfr-operator] A Kubernetes operator that deploys and manages all of the above projects with a Kubernetes/OpenShift cluster. At this stage, this project is built using Operator SDK. In addition to the standard deployment of all Project Hamburg components along with Grafana, the operator also supports a "minimal" option. This deploys only Container JFR, and no web front-end or Grafana components. The operator also provides a Kubernetes API for JFR using Custom Resource Definitions. This API consists of FlightRecorder objects created by the operator for each compatible Kubernetes Service in its namespace. These objects contain information like JFR event types for the target JVM. A consumer of the API can create Recording objects for a FlightRecorder object and view the status of them via kubectl/oc. The operator reconciles these objects with Container JFR to retrieve information and manage JFR recordings. Furthermore, we plan to incorporate over time API to deploy and control the JMC Agent [2], to allow existing applications to be instrumented without the need to specifically write Events in the application code. Not all the components need to be used together, for example one can easily change the Web part for direct integration into their own framework management consoles or skip the Operator completely, but my hope is that this Project will help in two key aspects: provide a stable and standardised API to access Flight Recordings without exposing the underlying JMX connections and offer a cross platform functionality similar to that of the JFR Streaming that works cross platform also for older releases. The Project will live as a separate entity from OpenJDK, and we don't expect changes to the OpenJDK code base to be necessary, although the experience gathered may of course lead to fixes, additional APIs and JFR Events to support a container aware OpenJDK over time; if this happens to be the case, such changes will be discussed as usual on the proper development mailing list and, when necessary, be addressed via JEPs. I propose to lead this Project with me and Elliott Baron as the initial reviewers. Any comments and feedback is welcomed! Cheers, Mario [1] The project is formerly known as container-jfr, and is of course meant to bridge the worlds of containers with the world of JFR. Hamburg is a bridge city, it?s probably the city with the highest number of bridges in the World - or certainly in Europe. It?s also one of the homes for the largest container ship in the World, the HMM Algeciras, so I thought this name would be perfectly fitting! [2] https://wiki.openjdk.java.net/display/jmc/The+JMC+Agent -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Wed Jun 24 11:31:35 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 24 Jun 2020 13:31:35 +0200 Subject: Call for Discussion: New Project: Hamburg In-Reply-To: References: Message-ID: Thanks Martijn! We will also need to find a sponsoring home for this project, so any idea is welcomed ;) Cheers, Mario On Wed, Jun 24, 2020 at 12:30 PM Martijn Verburg wrote: > > Hi Mario, > > Thanks for posting this. Our group (Microsoft Java Engineering) is going to take a look at all the links and info and revert our thoughts back here. It's the end of the quarter for us, so it might be sometime next week in case you're wondering why the silence :-) > > Cheers, > Martijn > > > On Tue, 23 Jun 2020 at 16:09, Mario Torre wrote: >> >> Hello OpenJDK developers. >> >> [I apologise, this is a long email, but I thought sharing more details >> would be useful for the discussion.] >> >> I would like to start a discussion for a new Project, Project Hamburg >> [1], whose primary goal is to address the issue of exposing and >> organising JFR recordings within a container setup, where direct >> access to the target JVM is not possible. >> >> The recent discussion about the tentative backport of the Streaming >> API for JFR to 11u and 8u has highlighted the desire to have a >> standardised way to easily obtain the JFR recordings not only for >> (quasi) real time monitoring but also as a mean of accessing event >> metrics from OpenJDKs within remote installations, like those in >> servers deployments and specifically from within containers - for >> example Kubernetes/OpenShift-managed cloud. >> >> In the last few months, some of us have been working on a project that >> aims to make it easier to use JFR and JDK Mission Control in those >> contexts, and I would like to start a discussion about potentially >> promoting our code as an official OpenJDK Project, where it may be >> useful for a larger community of developers. >> >> At the current state, Project Hamburg lives in a github repository >> under the name ?Container-JFR?, and has several components designed to >> work together at various [optional] levels of integration, the >> proposed Project will maintain overall the same layout. >> >> [Container JFR - https://github.com/rh-jmc-team/container-jfr] >> >> A containerized web service that communicates with JVMs in the same >> Kubernetes namespace. This communication involves invoking JFR >> operations over remote JMX, which is made available by the VMs' >> corresponding Kubernetes Services, and does not need to be exposed to >> the external world. Instead, clients can interact with Container JFR >> via a WebSocket command-based interface. These commands include >> operations like starting and stopping recordings with given options, >> listing in-memory recordings, listing event types, and saving a >> recording to persistent storage, etc... >> >> This web service also serves raw JFR files for download and analysis >> with JMC, and generates HTML reports identical to JMC's automated >> analysis. >> >> [Container JFR Core - https://github.com/rh-jmc-team/container-jfr-core] >> >> This project is a dependency of Container JFR. It contains interfaces >> and utilities for calling JMC code to establish remote JMX connections >> and communicate with JFR. The JMC dependencies are abstracted so we >> can replace this module without requiring access to the JMC API >> (although since JMC is also an OpenJDK Project we think this is not a >> problem). >> >> [Container JFR Web - https://github.com/rh-jmc-team/container-jfr-web] >> >> A front-end to graphically communicate with Container JFR via web >> browser. It allows the user to connect to a JVM from a drop down list >> of available JVMs. Once connected, Container JFR Web displays a table >> of available event types and their options. Users can then use a >> wizard to create a recording, and see a list of recordings present in >> that JVM. For each recording, the user can see the automated analysis >> results provided by JMC code, save the recording to persistent >> in-cluster storage, download the recording to local disk, or view >> compatible metrics in a Grafana dashboard. This mimics some of the >> functionality of JMC to provide an overview of the target JVM and >> offers the option to download the JFR file further analysis in JMC. >> >> [JFR Datasource - https://github.com/rh-jmc-team/jfr-datasource] >> >> This project parses a provided JFR file and serves it as a Grafana >> SimpleJson datasource in order to populate a Grafana dashboard with >> metrics from the JFR file. >> >> [Container JFR Operator - https://github.com/rh-jmc-team/container-jfr-operator] >> >> A Kubernetes operator that deploys and manages all of the above >> projects with a Kubernetes/OpenShift cluster. At this stage, this >> project is built using Operator SDK. >> >> In addition to the standard deployment of all Project Hamburg >> components along with Grafana, the operator also supports a "minimal" >> option. This deploys only Container JFR, and no web front-end or >> Grafana components. >> >> The operator also provides a Kubernetes API for JFR using Custom >> Resource Definitions. This API consists of FlightRecorder objects >> created by the operator for each compatible Kubernetes Service in its >> namespace. These objects contain information like JFR event types for >> the target JVM. A consumer of the API can create Recording objects for >> a FlightRecorder object and view the status of them via kubectl/oc. >> >> The operator reconciles these objects with Container JFR to retrieve >> information and manage JFR recordings. >> >> Furthermore, we plan to incorporate over time API to deploy and >> control the JMC Agent [2], to allow existing applications to be >> instrumented without the need to specifically write Events in the >> application code. >> >> Not all the components need to be used together, for example one can >> easily change the Web part for direct integration into their own >> framework management consoles or skip the Operator completely, but my >> hope is that this Project will help in two key aspects: provide a >> stable and standardised API to access Flight Recordings without >> exposing the underlying JMX connections and offer a cross platform >> functionality similar to that of the JFR Streaming that works cross >> platform also for older releases. >> >> The Project will live as a separate entity from OpenJDK, and we don't >> expect changes to the OpenJDK code base to be necessary, although the >> experience gathered may of course lead to fixes, additional APIs and >> JFR Events to support a container aware OpenJDK over time; if this >> happens to be the case, such changes will be discussed as usual on the >> proper development mailing list and, when necessary, be addressed via >> JEPs. >> >> I propose to lead this Project with me and Elliott Baron as the >> initial reviewers. >> >> Any comments and feedback is welcomed! >> >> Cheers, >> Mario >> >> [1] The project is formerly known as container-jfr, and is of course >> meant to bridge the worlds of containers with the world of JFR. >> Hamburg is a bridge city, it?s probably the city with the highest >> number of bridges in the World - or certainly in Europe. It?s also one >> of the homes for the largest container ship in the World, the HMM >> Algeciras, so I thought this name would be perfectly fitting! >> >> [2] https://wiki.openjdk.java.net/display/jmc/The+JMC+Agent >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 >> -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From github.com+348973+cimi at openjdk.java.net Wed Jun 24 17:19:57 2020 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Wed, 24 Jun 2020 17:19:57 GMT Subject: RFR: 6833: Tolerate exceptions when loading images Message-ID: This PR fixes the crash reported in [6833](https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6833?filter=allopenissues) by returning null in case there's an error reading UI images. During manual testing I noticed that the icon for Method Profiling can't be loaded on my system and this was causing the application to crash. I didn't find other resources with this problem. ------------- Commit messages: - 6833: Tolerate exceptions when loading images Changes: https://git.openjdk.java.net/jmc/pull/86/files Webrev: https://webrevs.openjdk.java.net/jmc/86/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6833 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/86/head:pull/86 PR: https://git.openjdk.java.net/jmc/pull/86 From hirt at openjdk.java.net Wed Jun 24 17:28:20 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 24 Jun 2020 17:28:20 GMT Subject: RFR: 6833: Tolerate exceptions when loading images In-Reply-To: References: Message-ID: On Tue, 23 Jun 2020 09:47:31 GMT, Alex Ciminian wrote: > This PR fixes the crash reported in > [6833](https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6833?filter=allopenissues) by returning null in case > there's an error reading UI images. During manual testing I noticed that the icon for Method Profiling can't be > loaded on my system and this was causing the application to crash. I didn't find other resources with this problem. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/86 From github.com+348973+cimi at openjdk.java.net Wed Jun 24 17:31:36 2020 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Wed, 24 Jun 2020 17:31:36 GMT Subject: Integrated: 6833: Tolerate exceptions when loading images In-Reply-To: References: Message-ID: <24uJYiDpUjW8pmGksW9Z2N-2IOdETmt5IE7zdKFzz2s=.d53919cb-bc0e-4d3f-aa6f-0a6cb38c5e80@github.com> On Tue, 23 Jun 2020 09:47:31 GMT, Alex Ciminian wrote: > This PR fixes the crash reported in > [6833](https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6833?filter=allopenissues) by returning null in case > there's an error reading UI images. During manual testing I noticed that the icon for Method Profiling can't be > loaded on my system and this was causing the application to crash. I didn't find other resources with this problem. This pull request has now been integrated. Changeset: 77d4b13a Author: Alex Ciminian Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/77d4b13a Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod 6833: Tolerate exceptions when loading images Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/86 From hdafgard at openjdk.java.net Wed Jun 24 18:53:07 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 24 Jun 2020 18:53:07 GMT Subject: RFR: 6847: Upgrading to the Eclipse 2020-06 platform In-Reply-To: References: Message-ID: On Mon, 22 Jun 2020 18:40:05 GMT, Marcus Hirt wrote: > Note that this one should probably go in after we get JMC-6838 in. That said, we can review it and get it ready for > show-time. Marked as reviewed by hdafgard (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/85 From hirt at openjdk.java.net Wed Jun 24 18:58:20 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 24 Jun 2020 18:58:20 GMT Subject: Integrated: 6847: Upgrading to the Eclipse 2020-06 platform In-Reply-To: References: Message-ID: On Mon, 22 Jun 2020 18:40:05 GMT, Marcus Hirt wrote: > Note that this one should probably go in after we get JMC-6838 in. That said, we can review it and get it ready for > show-time. This pull request has now been integrated. Changeset: 0a1c4b38 Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/0a1c4b38 Stats: 157 lines in 5 files changed: 3 ins; 154 del; 0 mod 6847: Upgrading to the Eclipse 2020-06 platform Reviewed-by: hdafgard ------------- PR: https://git.openjdk.java.net/jmc/pull/85 From kxu at openjdk.java.net Wed Jun 24 19:12:19 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 24 Jun 2020 19:12:19 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v7] In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: move treemap into JOverflow module directly ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/268de328..014d0154 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.06 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.05-06 Stats: 2128 lines in 38 files changed: 824 ins; 1296 del; 8 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Wed Jun 24 19:23:41 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 24 Jun 2020 19:23:41 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v8] In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: revert api exporting changes ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/014d0154..d1f4b03c Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.07 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.06-07 Stats: 15 lines in 5 files changed: 0 ins; 4 del; 11 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Wed Jun 24 19:35:56 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 24 Jun 2020 19:35:56 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v9] In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: make spotless happy ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/d1f4b03c..5f481538 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.08 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Wed Jun 24 19:40:39 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Wed, 24 Jun 2020 19:40:39 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v6] In-Reply-To: References: <093cAkZ2f8n-HkXiVR2r971C_AopxPUu10v1o4S_vXA=.cef4611a-92a6-4379-a1ec-269849ab66c0@github.com> Message-ID: On Mon, 22 Jun 2020 19:03:37 GMT, Marcus Hirt wrote: >> What is the intended distribution model? Should this be something from the update site, or delivered as part of the >> standard offering? > > If part of standard JOverflow, then you might as well put it in the JOverflow bundle. It can still be optional to open > the view. If you want this to be an optional bundle from the update sites, then you need to add them to the update > sites. Personally I think this might as well be part of JOverflow directly. @thegreystone I think it makes more sense to be part of JOverflow directly. I've made changes to relocate treemap files and to remove the ext.treemap module. Please give it a quick look. Thanks! ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From reinhapa at openjdk.java.net Wed Jun 24 20:04:41 2020 From: reinhapa at openjdk.java.net (Patrick Reinhart) Date: Wed, 24 Jun 2020 20:04:41 GMT Subject: RFR: 6852: Extracted layout for the JMC RCP binaries look not the same for Linux/Windows Message-ID: Signed-off-by: Patrick Reinhart ------------- Commit messages: - 6852: Adds missing root folders for Windows/Linux Changes: https://git.openjdk.java.net/jmc/pull/87/files Webrev: https://webrevs.openjdk.java.net/jmc/87/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6852 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/87/head:pull/87 PR: https://git.openjdk.java.net/jmc/pull/87 From hirt at openjdk.java.net Wed Jun 24 20:10:04 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 24 Jun 2020 20:10:04 GMT Subject: RFR: 6699: Remove the photon platform Message-ID: <4UYvizvxTL7QLClsvyR7ZRoFr_e-3aCu8ISfyzg9VaA=.9027abfe-e984-44a8-ab4f-1b46fa73f278@github.com> Exactly what it sounds like. :) ------------- Commit messages: - 6699: Remove the photon platform Changes: https://git.openjdk.java.net/jmc/pull/88/files Webrev: https://webrevs.openjdk.java.net/jmc/88/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6699 Stats: 149 lines in 5 files changed: 0 ins; 149 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/88/head:pull/88 PR: https://git.openjdk.java.net/jmc/pull/88 From hirt at openjdk.java.net Thu Jun 25 11:01:33 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 25 Jun 2020 11:01:33 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v9] In-Reply-To: References: Message-ID: On Wed, 24 Jun 2020 19:35:56 GMT, Kangcheng Xu wrote: >> This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It >> adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like >> JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. >> ![screen-shot](https://i.imgur.com/hTeNLtw.png) >> The treemap is not included in the building by default, therefore you'll need to manually enable the >> `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened >> in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. >> --- >> >> The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three >> components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes >> active. >> >> ### Toolbar actions: >> >> ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) >> >> Buttons are enabled and disabled automatically according to the state of the treemap. >> >> - Zoom-in button: zoom-in to the selected node of the treemap >> - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap >> - Zoom-off button: display the root node (ie. "[ROOT]" node) >> >> ### Breadcrumb >> >> ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) >> >> The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries >> are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. >> - Left mouse click: navigate to desired zooming level. >> >> ### Treemap >> >> ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) >> >> The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The >> larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with >> different background colours. User interactions on the treemap also updates the breadcrumb. >> - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. >> - Middle mouse click: display the root node (ie. "[ROOT]" node) >> - Right mouse click: zoom-out to the parent node of the currently expanded node >> - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) >> - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable >> format. >> >> --- >> >> Let me know what you think about the design and functionality. :) > > Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: > > make spotless happy application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/swt/BreadcrumbItem.java line 134: > 133: > 134: /* package-private */ Point getDimension(GC gc) { > 135: Font font = gc.getFont(); Nit: We usually don't call out things as being package private in comments. The Java language (and the IDE) does that for you. If you want to call out a design decision, explaining the decision in the comment may be more helpful. This is not a blocker - I'm okay with it, if you find it helpful. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Thu Jun 25 17:04:11 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Thu, 25 Jun 2020 17:04:11 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v9] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 10:59:17 GMT, Marcus Hirt wrote: >> Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: >> >> make spotless happy > > application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/swt/BreadcrumbItem.java line 134: > >> 133: >> 134: /* package-private */ Point getDimension(GC gc) { >> 135: Font font = gc.getFont(); > > Nit: We usually don't call out things as being package private in comments. The Java language (and the IDE) does that > for you. If you want to call out a design decision, explaining the decision in the comment may be more helpful. This is > not a blocker - I'm okay with it, if you find it helpful. I saw this practice when studying the Eclipse SWT source. There is no important reason for explicitly calling out these methods/classes being`/* package-private */`. I thought it was more like a good-to-have sort of things. I'll refrain from doing this in the future. Please let me know if you prefer removing these comments throughout this patch. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From hirt at openjdk.java.net Thu Jun 25 18:29:11 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 25 Jun 2020 18:29:11 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v9] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 17:01:53 GMT, Kangcheng Xu wrote: >> application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/swt/BreadcrumbItem.java line 134: >> >>> 133: >>> 134: /* package-private */ Point getDimension(GC gc) { >>> 135: Font font = gc.getFont(); >> >> Nit: We usually don't call out things as being package private in comments. The Java language (and the IDE) does that >> for you. If you want to call out a design decision, explaining the decision in the comment may be more helpful. This is >> not a blocker - I'm okay with it, if you find it helpful. > > I saw this practice when studying the Eclipse SWT source. There is no important reason for explicitly calling out these > methods/classes being`/* package-private */`. I thought it was more like a good-to-have sort of things. > I'll refrain from doing this in the future. Please let me know if you prefer removing these comments throughout this > patch. Personally I'd prefer to have them removed. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From hirt at openjdk.java.net Thu Jun 25 18:32:28 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 25 Jun 2020 18:32:28 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v9] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 18:27:02 GMT, Marcus Hirt wrote: >> I saw this practice when studying the Eclipse SWT source. There is no important reason for explicitly calling out these >> methods/classes being`/* package-private */`. I thought it was more like a good-to-have sort of things. >> I'll refrain from doing this in the future. Please let me know if you prefer removing these comments throughout this >> patch. > > Personally I'd prefer to have them removed. Or added as a proper comment with the reasoning for them being package private... /* * This method is package private since ClassX needs to access the internal state without having to do a defensive copy every time, but we don't want to have it exposed in the public API since blahblahblah. */ ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Thu Jun 25 18:56:54 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Thu, 25 Jun 2020 18:56:54 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v10] In-Reply-To: References: Message-ID: > This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It > adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like > JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow. > ![screen-shot](https://i.imgur.com/hTeNLtw.png) > The treemap is not included in the building by default, therefore you'll need to manually enable the > `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened > in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*. > --- > > The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three > components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes > active. > > ### Toolbar actions: > > ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png) > > Buttons are enabled and disabled automatically according to the state of the treemap. > > - Zoom-in button: zoom-in to the selected node of the treemap > - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap > - Zoom-off button: display the root node (ie. "[ROOT]" node) > > ### Breadcrumb > > ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png) > > The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries > are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap. > - Left mouse click: navigate to desired zooming level. > > ### Treemap > > ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png) > > The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The > larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with > different background colours. User interactions on the treemap also updates the breadcrumb. > - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button. > - Middle mouse click: display the root node (ie. "[ROOT]" node) > - Right mouse click: zoom-out to the parent node of the currently expanded node > - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf) > - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable > format. > > --- > > Let me know what you think about the design and functionality. :) Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision: remove package-private comments ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/77/files - new: https://git.openjdk.java.net/jmc/pull/77/files/5f481538..aaaab0bb Webrevs: - full: https://webrevs.openjdk.java.net/jmc/77/webrev.09 - incr: https://webrevs.openjdk.java.net/jmc/77/webrev.08-09 Stats: 12 lines in 8 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jmc/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77 PR: https://git.openjdk.java.net/jmc/pull/77 From kxu at openjdk.java.net Thu Jun 25 19:06:01 2020 From: kxu at openjdk.java.net (Kangcheng Xu) Date: Thu, 25 Jun 2020 19:06:01 GMT Subject: RFR: 6810: Create treemap viewer for JOverflow [v9] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 18:30:20 GMT, Marcus Hirt wrote: >> Personally I'd prefer to have them removed. > > Or added as a proper comment with the reasoning for them being package private... > > /* > * This method is package private since ClassX needs to access the internal state without having to do a defensive copy > every time, but we don't want to have it exposed in the public API since blahblahblah. > */ > Personally I'd prefer to have them removed. All `/* package-private */` comments are removed in commit aaaab0b. ------------- PR: https://git.openjdk.java.net/jmc/pull/77 From github.com+52708588+hdafgard at openjdk.java.net Fri Jun 26 16:11:28 2020 From: github.com+52708588+hdafgard at openjdk.java.net (hdafgard) Date: Fri, 26 Jun 2020 16:11:28 GMT Subject: RFR: 6699: Remove the photon platform In-Reply-To: <4UYvizvxTL7QLClsvyR7ZRoFr_e-3aCu8ISfyzg9VaA=.9027abfe-e984-44a8-ab4f-1b46fa73f278@github.com> References: <4UYvizvxTL7QLClsvyR7ZRoFr_e-3aCu8ISfyzg9VaA=.9027abfe-e984-44a8-ab4f-1b46fa73f278@github.com> Message-ID: On Wed, 24 Jun 2020 20:00:54 GMT, Marcus Hirt wrote: > Exactly what it sounds like. :) Marked as reviewed by hdafgard at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jmc/pull/88 From hdafgard at openjdk.java.net Fri Jun 26 16:13:18 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Fri, 26 Jun 2020 16:13:18 GMT Subject: RFR: 6710: Add rule to detect if an old version of Lucene is in use Message-ID: JMC has a few hard coded checks to exclude LookaheadSuccess Error instances, we should instead point out to users if they're using an older version of Lucene (or Solr/ElasticSearch) before they started re-using the same Error instance. ------------- Commit messages: - Add rule to check for old versions of Lucene Changes: https://git.openjdk.java.net/jmc/pull/89/files Webrev: https://webrevs.openjdk.java.net/jmc/89/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6710 Stats: 145 lines in 3 files changed: 145 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/89/head:pull/89 PR: https://git.openjdk.java.net/jmc/pull/89 From hdafgard at openjdk.java.net Fri Jun 26 16:11:28 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Fri, 26 Jun 2020 16:11:28 GMT Subject: RFR: 6699: Remove the photon platform In-Reply-To: <4UYvizvxTL7QLClsvyR7ZRoFr_e-3aCu8ISfyzg9VaA=.9027abfe-e984-44a8-ab4f-1b46fa73f278@github.com> References: <4UYvizvxTL7QLClsvyR7ZRoFr_e-3aCu8ISfyzg9VaA=.9027abfe-e984-44a8-ab4f-1b46fa73f278@github.com> Message-ID: <9-YcNAf8mNTSSyvUxGEzokrJ8Sw5eTvJX9bybUF5kRM=.6ff59b1b-dd75-402f-b0bf-bb20c00ab1e3@github.com> On Wed, 24 Jun 2020 20:00:54 GMT, Marcus Hirt wrote: > Exactly what it sounds like. :) Marked as reviewed by hdafgard (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/88 From hirt at openjdk.java.net Fri Jun 26 16:25:48 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 26 Jun 2020 16:25:48 GMT Subject: RFR: 6710: Add rule to detect if an old version of Lucene is in use [v2] In-Reply-To: <6dZ_0Ll73Fg3AqqG-Fi3fNoXrlLxubt2Oa4uAgIgp_U=.cd020dd8-4bf4-4dcb-9475-4d008f2d71e4@github.com> References: <6dZ_0Ll73Fg3AqqG-Fi3fNoXrlLxubt2Oa4uAgIgp_U=.cd020dd8-4bf4-4dcb-9475-4d008f2d71e4@github.com> Message-ID: On Fri, 26 Jun 2020 16:07:41 GMT, Henrik Dafg?rd wrote: >> JMC has a few hard coded checks to exclude LookaheadSuccess Error instances, we should instead point out to users if >> they're using an older version of Lucene (or Solr/ElasticSearch) before they started re-using the same Error instance. > > Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting LGTM! ------------- Marked as reviewed by hirt (Lead). PR: https://git.openjdk.java.net/jmc/pull/89 From hdafgard at openjdk.java.net Fri Jun 26 16:25:48 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Fri, 26 Jun 2020 16:25:48 GMT Subject: RFR: 6710: Add rule to detect if an old version of Lucene is in use [v2] In-Reply-To: References: Message-ID: <6dZ_0Ll73Fg3AqqG-Fi3fNoXrlLxubt2Oa4uAgIgp_U=.cd020dd8-4bf4-4dcb-9475-4d008f2d71e4@github.com> > JMC has a few hard coded checks to exclude LookaheadSuccess Error instances, we should instead point out to users if > they're using an older version of Lucene (or Solr/ElasticSearch) before they started re-using the same Error instance. Henrik Dafg?rd has updated the pull request incrementally with one additional commit since the last revision: Fix formatting ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/89/files - new: https://git.openjdk.java.net/jmc/pull/89/files/e211880f..9504b166 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/89/webrev.01 - incr: https://webrevs.openjdk.java.net/jmc/89/webrev.00-01 Stats: 12 lines in 1 file changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jmc/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/89/head:pull/89 PR: https://git.openjdk.java.net/jmc/pull/89 From hdafgard at openjdk.java.net Fri Jun 26 17:26:24 2020 From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Fri, 26 Jun 2020 17:26:24 GMT Subject: Integrated: 6710: Add rule to detect if an old version of Lucene is in use In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 16:02:13 GMT, Henrik Dafg?rd wrote: > JMC has a few hard coded checks to exclude LookaheadSuccess Error instances, we should instead point out to users if > they're using an older version of Lucene (or Solr/ElasticSearch) before they started re-using the same Error instance. This pull request has now been integrated. Changeset: 28b16572 Author: Henrik Dafg?rd URL: https://git.openjdk.java.net/jmc/commit/28b16572 Stats: 147 lines in 3 files changed: 0 ins; 147 del; 0 mod 6710: Add rule to detect if an old version of Lucene is in use Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/89 From hirt at openjdk.java.net Fri Jun 26 17:33:46 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Fri, 26 Jun 2020 17:33:46 GMT Subject: Integrated: 6699: Remove the photon platform In-Reply-To: <4UYvizvxTL7QLClsvyR7ZRoFr_e-3aCu8ISfyzg9VaA=.9027abfe-e984-44a8-ab4f-1b46fa73f278@github.com> References: <4UYvizvxTL7QLClsvyR7ZRoFr_e-3aCu8ISfyzg9VaA=.9027abfe-e984-44a8-ab4f-1b46fa73f278@github.com> Message-ID: On Wed, 24 Jun 2020 20:00:54 GMT, Marcus Hirt wrote: > Exactly what it sounds like. :) This pull request has now been integrated. Changeset: 20462f2f Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/20462f2f Stats: 149 lines in 5 files changed: 149 ins; 0 del; 0 mod 6699: Remove the photon platform Reviewed-by: hdafgard ------------- PR: https://git.openjdk.java.net/jmc/pull/88 From ghb at openjdk.java.net Sat Jun 27 03:35:44 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Sat, 27 Jun 2020 03:35:44 GMT Subject: RFR: 6852: Extracted layout for the JMC RCP binaries look not the same for Linux/Windows In-Reply-To: References: Message-ID: On Wed, 24 Jun 2020 19:53:48 GMT, Patrick Reinhart wrote: > Signed-off-by: Patrick Reinhart Changes looks good to me, Please note : Windows and linux are not so user friendly with directory containing spaces when user tries to navigate in Terminal / cmd prompt. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jmc/pull/87 From hirt at openjdk.java.net Sat Jun 27 12:57:40 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Sat, 27 Jun 2020 12:57:40 GMT Subject: RFR: 6852: Extracted layout for the JMC RCP binaries look not the same for Linux/Windows In-Reply-To: References: Message-ID: <88qczHyZoH4qSI7n8qxGSmE7RS3_CtJ91dqhJgBU3nQ=.421caae8-f993-46d9-8fe4-7db6f619f0c8@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Sat, 27 Jun 2020 03:33:37 GMT, Guru Hb wrote: >> Signed-off-by: Patrick Reinhart > > Changes looks good to me, Please note : Windows and linux are not so user friendly with directory containing spaces > when user tries to navigate in Terminal / cmd prompt. I'd like for another vendor to take a look as this may affect packaging. Mario said he'll take a look on Monday. ------------- PR: https://git.openjdk.java.net/jmc/pull/87 From hirt at openjdk.java.net Mon Jun 29 12:09:40 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 29 Jun 2020 12:09:40 GMT Subject: RFR: 6855: Should add information about where to get builds to README Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Adding binary download info and cleaning up a bit ------------- Commit messages: - 6855: Adding binary download info and cleaning up a bit Changes: https://git.openjdk.java.net/jmc/pull/91/files Webrev: https://webrevs.openjdk.java.net/jmc/91/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6855 Stats: 46 lines in 1 file changed: 38 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jmc/pull/91.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/91/head:pull/91 PR: https://git.openjdk.java.net/jmc/pull/91 From hirt at openjdk.java.net Mon Jun 29 13:45:23 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 29 Jun 2020 13:45:23 GMT Subject: RFR: 6855: Should add information about where to get builds to README [v2] In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- > Adding binary download info and cleaning up a bit Marcus Hirt has updated the pull request incrementally with two additional commits since the last revision: - Fixing misunderstanding - More Red Hat related info ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/91/files - new: https://git.openjdk.java.net/jmc/pull/91/files/7b9a05bc..29c8578d Webrevs: - full: https://webrevs.openjdk.java.net/jmc/91/webrev.01 - incr: https://webrevs.openjdk.java.net/jmc/91/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/91.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/91/head:pull/91 PR: https://git.openjdk.java.net/jmc/pull/91 From jmatsuoka at openjdk.java.net Mon Jun 29 22:52:18 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Mon, 29 Jun 2020 22:52:18 GMT Subject: RFR: 6805: Event emission only on exceptions Message-ID: This PR implements [JMC-6805](https://bugs.openjdk.java.net/browse/JMC-6805) allowing the agent to optionally only emit events when exceptions are thrown by the instrumented method. This is configurable via an added xml option that when set to true will only emit the event in the catch of the injected try-catch block. ------------- Commit messages: - Remove unused label - Clean up implementation and extraneous printlns - Add Lisence headers, cleanup - WIP Implementation of JMC-6805 - 3 - WIP Implementation of JMC-6805 - Merge remote-tracking branch 'upstream/master' - WIP Implementation of JMC-6805 Changes: https://git.openjdk.java.net/jmc/pull/92/files Webrev: https://webrevs.openjdk.java.net/jmc/92/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6805 Stats: 225 lines in 9 files changed: 218 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jmc/pull/92.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/92/head:pull/92 PR: https://git.openjdk.java.net/jmc/pull/92 From schaturvedi at openjdk.java.net Tue Jun 30 05:43:44 2020 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 30 Jun 2020 05:43:44 GMT Subject: RFR: 6858: Thread dump does not show complete call stack based for all threads (grouped by time) Message-ID: <-G5Vj01NmG1rCZS7TCq_u4zkYbuCfB2PsP_20_YhqT0=.e9152b17-2527-44ea-bcb5-bd34eed7f0f6@github.com> Thread dump does not show complete call stack based on all threads (grouped by time) in first shot. The user need to click on each sub sections of the sub-tree to see the corresponding thread dumps. But the user wanted to see full thread dump in one shot as soon as they click on timestamp mentioned. Attached the screenshots of the functionality before and after fix. Before fix JMC_6170 After fix JMC_6170_Fixed ------------- Commit messages: - 6858: Thread dump does not show complete call stack based for all threads (grouped by time) Changes: https://git.openjdk.java.net/jmc/pull/90/files Webrev: https://webrevs.openjdk.java.net/jmc/90/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JMC-6858 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmc/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/90/head:pull/90 PR: https://git.openjdk.java.net/jmc/pull/90 From ghb at openjdk.java.net Tue Jun 30 05:49:05 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Tue, 30 Jun 2020 05:49:05 GMT Subject: RFR: 6858: Thread dump does not show complete call stack based for all threads (grouped by time) In-Reply-To: <-G5Vj01NmG1rCZS7TCq_u4zkYbuCfB2PsP_20_YhqT0=.e9152b17-2527-44ea-bcb5-bd34eed7f0f6@github.com> References: <-G5Vj01NmG1rCZS7TCq_u4zkYbuCfB2PsP_20_YhqT0=.e9152b17-2527-44ea-bcb5-bd34eed7f0f6@github.com> Message-ID: On Mon, 29 Jun 2020 11:11:51 GMT, Suchita Chaturvedi wrote: > Thread dump does not show complete call stack based on all threads (grouped by time) in first shot. > > The user need to click on each sub sections of the sub-tree to see the corresponding thread dumps. But the user wanted > to see full thread dump in one shot as soon as they click on timestamp mentioned. Attached the screenshots of the > functionality before and after fix. > Before fix > > > JMC_6170 src="https://user-images.githubusercontent.com/11155712/85997486-2bd39980-ba27-11ea-824c-958c3adc0c96.png"> > After fix > > JMC_6170_Fixed src="https://user-images.githubusercontent.com/11155712/85997520-35f59800-ba27-11ea-9cd5-73efe83a7102.png"> Marked as reviewed by ghb (Reviewer). ------------- PR: https://git.openjdk.java.net/jmc/pull/90 From neugens at redhat.com Tue Jun 30 14:30:05 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Jun 2020 16:30:05 +0200 Subject: RFR: 6852: Extracted layout for the JMC RCP binaries look not the same for Linux/Windows In-Reply-To: <88qczHyZoH4qSI7n8qxGSmE7RS3_CtJ91dqhJgBU3nQ=.421caae8-f993-46d9-8fe4-7db6f619f0c8@github.com> References: <88qczHyZoH4qSI7n8qxGSmE7RS3_CtJ91dqhJgBU3nQ=.421caae8-f993-46d9-8fe4-7db6f619f0c8@github.com> Message-ID: <05731285b396849a389dce63569662def91c1206.camel@redhat.com> On Sat, 2020-06-27 at 12:57 +0000, Marcus Hirt wrote: > The message from this sender included one or more files > which could not be scanned for virus detection; do not > open these files unless you are certain of the sender's intent. > > ------------------------------------------------------------------- > --- > On Sat, 27 Jun 2020 03:33:37 GMT, Guru Hb wrote: > > > > Signed-off-by: Patrick Reinhart > > > > Changes looks good to me, Please note : Windows and linux are not > > so user friendly with directory containing spaces > > when user tries to navigate in Terminal / cmd prompt. > > I'd like for another vendor to take a look as this may affect > packaging. Mario said he'll take a look on Monday. > > ------------- > > PR: https://git.openjdk.java.net/jmc/pull/87 > Hi Marcus, I also replied on the bug, the changes required for RPM from our side are minimal, so the patch looks good to me for 8.0.0. I can't speak for other distributors obviously, however. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From hirt at openjdk.java.net Tue Jun 30 14:43:50 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 30 Jun 2020 14:43:50 GMT Subject: RFR: 6858: Thread dump does not show complete call stack based for all threads (grouped by time) In-Reply-To: References: <-G5Vj01NmG1rCZS7TCq_u4zkYbuCfB2PsP_20_YhqT0=.e9152b17-2527-44ea-bcb5-bd34eed7f0f6@github.com> Message-ID: On Tue, 30 Jun 2020 05:47:01 GMT, Guru Hb wrote: >> Thread dump does not show complete call stack based on all threads (grouped by time) in first shot. >> >> The user need to click on each sub sections of the sub-tree to see the corresponding thread dumps. But the user wanted >> to see full thread dump in one shot as soon as they click on timestamp mentioned. Attached the screenshots of the >> functionality before and after fix. >> Before fix >> >> >> JMC_6170> src="https://user-images.githubusercontent.com/11155712/85997486-2bd39980-ba27-11ea-824c-958c3adc0c96.png"> >> After fix >> >> JMC_6170_Fixed> src="https://user-images.githubusercontent.com/11155712/85997520-35f59800-ba27-11ea-9cd5-73efe83a7102.png"> > > Marked as reviewed by ghb (Reviewer). Hi there! Did you try this out with some massive thread stack dumps? ------------- PR: https://git.openjdk.java.net/jmc/pull/90 From marcus.hirt at datadoghq.com Tue Jun 30 14:43:53 2020 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Tue, 30 Jun 2020 16:43:53 +0200 Subject: RFR: 6852: Extracted layout for the JMC RCP binaries look not the same for Linux/Windows In-Reply-To: <05731285b396849a389dce63569662def91c1206.camel@redhat.com> References: <88qczHyZoH4qSI7n8qxGSmE7RS3_CtJ91dqhJgBU3nQ=.421caae8-f993-46d9-8fe4-7db6f619f0c8@github.com> <05731285b396849a389dce63569662def91c1206.camel@redhat.com> Message-ID: Excellent! Can you please mark the PR as reviewed by you? Kind regards, Marcus On Tue, Jun 30, 2020 at 4:35 PM Mario Torre wrote: > On Sat, 2020-06-27 at 12:57 +0000, Marcus Hirt wrote: > > The message from this sender included one or more files > > which could not be scanned for virus detection; do not > > open these files unless you are certain of the sender's intent. > > > > ------------------------------------------------------------------- > > --- > > On Sat, 27 Jun 2020 03:33:37 GMT, Guru Hb wrote: > > > > > > Signed-off-by: Patrick Reinhart > > > > > > Changes looks good to me, Please note : Windows and linux are not > > > so user friendly with directory containing spaces > > > when user tries to navigate in Terminal / cmd prompt. > > > > I'd like for another vendor to take a look as this may affect > > packaging. Mario said he'll take a look on Monday. > > > > ------------- > > > > PR: https://git.openjdk.java.net/jmc/pull/87 > > > > Hi Marcus, > > I also replied on the bug, the changes required for RPM from our side > are minimal, so the patch looks good to me for 8.0.0. > > I can't speak for other distributors obviously, however. > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From neugens at openjdk.java.net Tue Jun 30 15:35:35 2020 From: neugens at openjdk.java.net (Mario Torre) Date: Tue, 30 Jun 2020 15:35:35 GMT Subject: RFR: 6852: Extracted layout for the JMC RCP binaries look not the same for Linux/Windows In-Reply-To: References: Message-ID: On Wed, 24 Jun 2020 19:53:48 GMT, Patrick Reinhart wrote: > Signed-off-by: Patrick Reinhart As mentioned earlier, the changes are ok for me! ------------- Marked as reviewed by neugens (Committer). PR: https://git.openjdk.java.net/jmc/pull/87 From hirt at openjdk.java.net Tue Jun 30 18:52:27 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 30 Jun 2020 18:52:27 GMT Subject: RFR: 6805: Event emission only on exceptions In-Reply-To: References: Message-ID: On Mon, 29 Jun 2020 22:37:17 GMT, Joshua Matsuoka wrote: > This PR implements [JMC-6805](https://bugs.openjdk.java.net/browse/JMC-6805) allowing the agent to optionally only emit > events when exceptions are thrown by the instrumented method. This is configurable via an added xml option that when > set to true will only emit the event in the catch of the injected try-catch block. agent/src/test/java/org/openjdk/jmc/agent/test/TestEmitOnlyOnException.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2020, Red Hat Inc. All rights reserved. Nit: I think it's fine to set copyright to only 2020. agent/src/test/java/org/openjdk/jmc/agent/test/TestDummy.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2020, Red Hat Inc. All rights reserved. New file - copyright 2020 only. ------------- PR: https://git.openjdk.java.net/jmc/pull/92 From hirt at openjdk.java.net Tue Jun 30 18:54:48 2020 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 30 Jun 2020 18:54:48 GMT Subject: RFR: 6805: Event emission only on exceptions In-Reply-To: References: Message-ID: On Mon, 29 Jun 2020 22:37:17 GMT, Joshua Matsuoka wrote: > This PR implements [JMC-6805](https://bugs.openjdk.java.net/browse/JMC-6805) allowing the agent to optionally only emit > events when exceptions are thrown by the instrumented method. This is configurable via an added xml option that when > set to true will only emit the event in the catch of the injected try-catch block. Looks good to me - good to go after the copyright year fixes. ------------- Marked as reviewed by hirt (Lead). PR: https://git.openjdk.java.net/jmc/pull/92 From jmatsuoka at openjdk.java.net Tue Jun 30 19:21:07 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Tue, 30 Jun 2020 19:21:07 GMT Subject: RFR: 6805: Event emission only on exceptions [v2] In-Reply-To: References: Message-ID: > This PR implements [JMC-6805](https://bugs.openjdk.java.net/browse/JMC-6805) allowing the agent to optionally only emit > events when exceptions are thrown by the instrumented method. This is configurable via an added xml option that when > set to true will only emit the event in the catch of the injected try-catch block. Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision: Fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/92/files - new: https://git.openjdk.java.net/jmc/pull/92/files/1a9c4677..25049897 Webrevs: - full: https://webrevs.openjdk.java.net/jmc/92/webrev.01 - incr: https://webrevs.openjdk.java.net/jmc/92/webrev.00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jmc/pull/92.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/92/head:pull/92 PR: https://git.openjdk.java.net/jmc/pull/92 From jmatsuoka at openjdk.java.net Tue Jun 30 19:21:08 2020 From: jmatsuoka at openjdk.java.net (Joshua Matsuoka) Date: Tue, 30 Jun 2020 19:21:08 GMT Subject: RFR: 6805: Event emission only on exceptions [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 18:49:36 GMT, Marcus Hirt wrote: >> Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright year > > agent/src/test/java/org/openjdk/jmc/agent/test/TestEmitOnlyOnException.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2019, 2020, Red Hat Inc. All rights reserved. > > Nit: I think it's fine to set copyright to only 2020. Fixed, thanks! > agent/src/test/java/org/openjdk/jmc/agent/test/TestDummy.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2019, 2020, Red Hat Inc. All rights reserved. > > New file - copyright 2020 only. Fixed, thanks! ------------- PR: https://git.openjdk.java.net/jmc/pull/92 From schaturvedi at openjdk.java.net Tue Jun 30 20:19:37 2020 From: schaturvedi at openjdk.java.net (Suchita Chaturvedi) Date: Tue, 30 Jun 2020 20:19:37 GMT Subject: RFR: 6858: Thread dump does not show complete call stack based for all threads (grouped by time) In-Reply-To: References: <-G5Vj01NmG1rCZS7TCq_u4zkYbuCfB2PsP_20_YhqT0=.e9152b17-2527-44ea-bcb5-bd34eed7f0f6@github.com> Message-ID: On Tue, 30 Jun 2020 14:41:36 GMT, Marcus Hirt wrote: > Hi there! Did you try this out with some massive thread stack dumps? Hi Marcus! Yes I have tested it with a JFR from SQE team which is basically a sample data for wls. If you have some particular jfr for which this fix should be tested, please provide the same. I would be happy to verify the same. ------------- PR: https://git.openjdk.java.net/jmc/pull/90