From marcus at hirt.se  Wed May  1 09:28:59 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 1 May 2019 11:28:59 +0200
Subject: SV: Review request for JMC-6460: Simple mechanism for building JMC
 under docker.
In-Reply-To: <CAEBeOcpvA0HBXTw1BOaNJuZ0j6EtgJUFWR4m1ov8PVe-aQYxOA@mail.gmail.com>
References: <003301d4ff91$c781cb60$56856220$@hirt.se>
 <CAEBeOcpvA0HBXTw1BOaNJuZ0j6EtgJUFWR4m1ov8PVe-aQYxOA@mail.gmail.com>
Message-ID: <00b501d50000$4ecc4eb0$ec64ec10$@hirt.se>

Hi Jie,

Agreed - that would be a great upgrade! :) We should actually be building
core with JDK 7 and the rest with JDK 8 (for now).

Regarding the copy statements, that is true. I added the license folder.

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: Jie Kang <jkang at redhat.com> 
Skickat: den 30 april 2019 23:11
Till: Marcus Hirt <marcus at hirt.se>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: Review request for JMC-6460: Simple mechanism for building JMC under docker.

Oh this looks neat!

Maybe this can be a further patch, but what are your thoughts on also separating the builds of jmc and jmc-core into two containers? This way we can easily create composes that build jmc via container without necessarily building jmc core and vice versa. As well if we ever want a different build jdk for jmc versus jmc-core, maybe 8 for core and
11+ for jmc, it will be quite easily done by changing the base image
for whichever (though I am not sure if this would ever happen)

--- old/./README.md 2019-04-30 22:09:38.547931000 +0200
+++ new/./README.md 2019-04-30 22:09:38.433931200 +0200
@@ -276,6 +276,15 @@
[...]
+## Building using docker and docker-compose
+
+```
+docker-compose -f docker/docker-compose.yml run jmc ```
+
+Once build has finished the results will be in the `target` directory

For the README entry, would it be worthwhile to expand on "supported"
versions for Docker and Docker-Compose? Any version that isn't years old would be okay to start with.

--- /dev/null 2019-04-30 21:08:09.544941500 +0200
+++ new/docker/Dockerfile-jmc 2019-04-30 22:09:39.145930700 +0200
@@ -0,0 +1,14 @@
[...]
+WORKDIR /jmc
+COPY core core/
+COPY application application/
+COPY configuration configuration/
+COPY releng releng/
+COPY pom.xml ./

I found the COPY statements of each individual folder under jmc to be curious. It looks like the license folder is excluded but I would have expected files under it to be used in the build process. Is it not needed?


Regards,


On Tue, Apr 30, 2019 at 4:18 PM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi all,
>
> Please review this patch from Will Thames to provide a simple 
> mechanism for building JMC under docker.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6460
> Patch:  http://cr.openjdk.java.net/~hirt/JMC-6460/webrev.0/
>
> Kind regards,
> Marcus
>


From ebaron at redhat.com  Wed May  1 17:00:27 2019
From: ebaron at redhat.com (Elliott Baron)
Date: Wed, 1 May 2019 13:00:27 -0400
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
Message-ID: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>

Hi,

Please review this patch which adds additional IO duration statistics 
using HdrHistogram [1]. One of the nice features of HdrHistogram is its 
ability to generate percentile distributions of data, while using 
limited space. For latency measurements, this can be a useful tool to 
draw attention to outliers where latency is particularly bad.

These statistics are displayed in a new table within the File and Socket 
IO pages. This table shows the read/write duration at predetermined 
percentiles (0, 90, 99, 99.9, 99.99, 99.999, and 100), and the total 
number of items <= that duration. I originally planned to show this 
information in a chart, but ran into difficulties expressing a 
non-linear percentile axis with JMC's charting API. After discussions 
with Marcus, I opted to display this information using a table alongside 
the existing chart.

I included some UI tests that verify the values in each of these 
HdrHistogram tables using a new (gzipped) JFR recording. I tried to keep 
this recording as small as possible, while still getting somewhat 
interesting results in the tables.

HdrHistogram itself is already bundled on Maven Central, I simply added 
it to our third-party p2 repository and target platforms. The included 
translations for the word "percentile" are the result of consulting 
online dictionaries, there may be better terms.

Bug: https://bugs.openjdk.java.net/browse/JMC-5327
Webrev: http://cr.openjdk.java.net/~aptmac/JMC-5327/webrev.00/
Preview: https://imgur.com/a/MlA2C7y

Thanks,
Elliott

[1] http://hdrhistogram.org/

From marcus at hirt.se  Wed May  1 19:36:34 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 1 May 2019 21:36:34 +0200
Subject: SV: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
Message-ID: <027f01d50055$2f51fc60$8df5f520$@hirt.se>

Nicely done Elliot!

I will take a look at this tomorrow. Thanks for doing this!

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Elliott Baron
Skickat: den 1 maj 2019 19:00
Till: jmc-dev at openjdk.java.net
?mne: RFR: JMC-5327: Using HdrHistograms to visualize latencies

Hi,

Please review this patch which adds additional IO duration statistics using HdrHistogram [1]. One of the nice features of HdrHistogram is its ability to generate percentile distributions of data, while using limited space. For latency measurements, this can be a useful tool to draw attention to outliers where latency is particularly bad.

These statistics are displayed in a new table within the File and Socket IO pages. This table shows the read/write duration at predetermined percentiles (0, 90, 99, 99.9, 99.99, 99.999, and 100), and the total number of items <= that duration. I originally planned to show this information in a chart, but ran into difficulties expressing a non-linear percentile axis with JMC's charting API. After discussions with Marcus, I opted to display this information using a table alongside the existing chart.

I included some UI tests that verify the values in each of these HdrHistogram tables using a new (gzipped) JFR recording. I tried to keep this recording as small as possible, while still getting somewhat interesting results in the tables.

HdrHistogram itself is already bundled on Maven Central, I simply added it to our third-party p2 repository and target platforms. The included translations for the word "percentile" are the result of consulting online dictionaries, there may be better terms.

Bug: https://bugs.openjdk.java.net/browse/JMC-5327
Webrev: http://cr.openjdk.java.net/~aptmac/JMC-5327/webrev.00/
Preview: https://imgur.com/a/MlA2C7y

Thanks,
Elliott

[1] http://hdrhistogram.org/


From marcus at hirt.se  Wed May  1 19:45:55 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Wed, 01 May 2019 19:45:55 +0000
Subject: hg: jmc/jmc: JMC-6460: Provide simple mechanism for building JMC
 under Docker
Message-ID: <201905011945.x41Jjt0n029638@aojmv0008.oracle.com>

Changeset: a16fe51679ca
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-01 21:45 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/a16fe51679ca

JMC-6460: Provide simple mechanism for building JMC under Docker
Reviewed-by: klward,hirt,Jie Kang <jkang at redhat.com>
Contributed-by: Will Thames <will at thames.id.au>

! .gitignore
! .hgignore
! README.md
+ docker/Dockerfile-jmc
+ docker/Dockerfile-p2
+ docker/docker-compose.yml


From almacdon at redhat.com  Wed May  1 23:22:33 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Wed, 1 May 2019 19:22:33 -0400
Subject: hg: jmc/jmc: JMC-6274: Add Eclipse 2018-12 and 2019-03 target
 platforms
In-Reply-To: <201904292036.x3TKaMnU004478@aojmv0008.oracle.com>
References: <201904292036.x3TKaMnU004478@aojmv0008.oracle.com>
Message-ID: <CAOsn=kqUpof796GrjR9cokBXsW7xt3t9T0L902nnVTtDc4Pcsg@mail.gmail.com>

Hi,

This commit appears to have introduced a source of failure when running
uitests. To verify I had Travis run UI tests on the changeset before [0]
and after [1] the application of this patch.

The error occurs when the PluginTest [2] tries to retrieve the tab folders
for the Installation Dialog - which occurs in MCInstallation [3]. A commit
to Platform UI [4] changed the type of tabbed folders from TabFolder to
CTabFolder, which causes a NPE because Jemmy tries to lookup the TabFolder
[3]. I've put together a quick patch (
http://cr.openjdk.java.net/~aptmac/JMC-6274/webrev.00/) [5] that updates
MCInstallation to look for CTabFolder. To confirm, I've applied the patch
to a branch and had Travis run uitests on it [6].

On Mon, Apr 29, 2019 at 4:36 PM <marcus at hirt.se> wrote:

> Changeset: 0339c57d510c
> Author:    hirt <marcus.hirt at oracle.com>
> Date:      2019-04-29 22:36 +0200
> URL:       http://hg.openjdk.java.net/jmc/jmc/rev/0339c57d510c
>
> JMC-6274: Add Eclipse 2018-12 and 2019-03 target platforms
> Reviewed-by: ghb, Jie Kang <jkang at redhat.com>
>
> !
> application/org.openjdk.jmc.browser.attach/.settings/org.eclipse.pde.prefs
> ! application/org.openjdk.jmc.feature.rcp/feature.xml
> ! application/org.openjdk.jmc.osgi.extension/.project
> ! application/org.openjdk.jmc.rcp.application/META-INF/MANIFEST.MF
> ! application/org.openjdk.jmc.rcp.product/jmc.product
> ! pom.xml
> + releng/platform-definitions/platform-definition-2018-12/.project
> +
> releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target
> + releng/platform-definitions/platform-definition-2018-12/pom.xml
> + releng/platform-definitions/platform-definition-2019-03/.project
> +
> releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target
> + releng/platform-definitions/platform-definition-2019-03/pom.xml
> - releng/platform-definitions/platform-definition-oxygen/.project
> -
> releng/platform-definitions/platform-definition-oxygen/platform-definition-oxygen.target
> - releng/platform-definitions/platform-definition-oxygen/pom.xml
> ! releng/platform-definitions/platform-definition-photon/.project
> ! releng/platform-definitions/pom.xml
>

Thoughts?

Cheers,

Alex

[0] https://travis-ci.org/aptmac/jmc-qa/builds/527043208
[1] https://travis-ci.org/aptmac/jmc-qa/builds/527043396
[2]
http://hg.openjdk.java.net/jmc/jmc/file/a16fe51679ca/application/uitests/org.openjdk.jmc.rcp.application.uitest/src/test/java/org/openjdk/jmc/rcp/application/uitest/PluginTest.java#l67
[3]
http://hg.openjdk.java.net/jmc/jmc/file/a16fe51679ca/application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCInstallation.java#l216
[4]
https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=43433b7ddf3d8d43e86a28cbd122178e8beca2ff
[5] http://cr.openjdk.java.net/~aptmac/JMC-6274/webrev.00/
[6] https://travis-ci.org/aptmac/jmc-qa/builds/527066207

From jmatsuok at redhat.com  Thu May  2 13:44:27 2019
From: jmatsuok at redhat.com (jmatsuok at redhat.com)
Date: Thu, 02 May 2019 13:44:27 +0000
Subject: hg: jmc/jmc: JMC-6274: Fix PluginTest uitest failure after 2019-03
 target platform addition
Message-ID: <201905021344.x42DiR9Y001077@aojmv0008.oracle.com>

Changeset: 2ecf88bb5f34
Author:    aptmac <almacdon at redhat.com>
Date:      2019-05-02 08:56 -0400
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/2ecf88bb5f34

JMC-6274: Fix PluginTest uitest failure after 2019-03 target platform addition
Summary: Platform UI introduced a change in the Installation Dialog to use CTabFolder instead of TabFolder. This caused a NPE when Jemmy tried to retrieve a TabFolder for testing.
Reviewed-by: hirt

! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCInstallation.java


From jmatsuok at redhat.com  Thu May  2 15:40:27 2019
From: jmatsuok at redhat.com (jmatsuok at redhat.com)
Date: Thu, 02 May 2019 15:40:27 +0000
Subject: hg: jmc/jmc: 2 new changesets
Message-ID: <201905021540.x42FeRUO011315@aojmv0008.oracle.com>

Changeset: 4f77e6262cb3
Author:    kdobson
Date:      2019-05-02 11:06 -0400
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/4f77e6262cb3

JMC-4645:Size distribution chart for File/Socket I/O pages
Summary:Adds a chart that shows the distribution of I/O events by size
Reviewed By: hirt, almac

! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/DataPageToolkit.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/FileIOPage.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/SocketIOPage.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java

Changeset: a9bcccbbf05a
Author:    kdobson
Date:      2019-05-02 11:03 -0400
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/a9bcccbbf05a

JMC-4469:Adding a page from properties view
Summary:Create a page from selected events by right clicking the properties view
Reviewed By: Hirt, almac

! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/DataPageToolkit.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/EventBrowserPage.java


From almacdon at redhat.com  Thu May  2 16:55:28 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Thu, 2 May 2019 12:55:28 -0400
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
Message-ID: <CAOsn=krdr6nP5BqMCSC6NM2iKFB9f4GkdCYJvuNUMtEuy5NsTQ@mail.gmail.com>

Hi Elliott,

Overall this patch looks good to me. I've had Travis give it a build and it
looks good [2].

A handful of minor formatting nits:

- Messages.properties (x3)
- - the DurationPercentileTable_PERCENTILE_COL_NAME should come after
DUMP_RECORDING_* for alphabetical order I believe

- There are some cases of extra whitespace, I went through hg diff and
counted the following number of occurrences:
- - DurationHdrHistogram (8)
- - DurationPercentileTable (38)
- - FileIOPage (5)
- - SocketIOPage (6)
- - IOPageTest (5)
- - IOPageTestBase (4)
- - SocketIOPageTest(5)

I noticed that when resizing the page, the durations table stays static
whereas the other tables seems to adjust (gif) [3]. This only seems to
cause an issue when my JMC window gets resized to just under 50% on my
monitor width, and the chart will get hidden. In the gif my JMC window is
around half my monitor width (of 1920), and with the JVM Browser/Outline
window open then I don't have much more room to shrink the application
before the chart disappears. I was just curious if the table could adjust
to resizing like the other tables.

Also not caused by this patch (but thought it'd be interesting to share),
I'm seeing a bug where my chart text gets really large [4] when I run JMC
locally and not as an RCP application (I recall seeing a JIRA bug for this
before, but cannot find it), and my durations tab will only show the table
(and not even the whole thing) [5].

On Wed, May 1, 2019 at 1:01 PM Elliott Baron <ebaron at redhat.com> wrote:

> Hi,
>
> Please review this patch which adds additional IO duration statistics
> using HdrHistogram [1]. One of the nice features of HdrHistogram is its
> ability to generate percentile distributions of data, while using
> limited space. For latency measurements, this can be a useful tool to
> draw attention to outliers where latency is particularly bad.
>
> These statistics are displayed in a new table within the File and Socket
> IO pages. This table shows the read/write duration at predetermined
> percentiles (0, 90, 99, 99.9, 99.99, 99.999, and 100), and the total
> number of items <= that duration. I originally planned to show this
> information in a chart, but ran into difficulties expressing a
> non-linear percentile axis with JMC's charting API. After discussions
> with Marcus, I opted to display this information using a table alongside
> the existing chart.
>
> I included some UI tests that verify the values in each of these
> HdrHistogram tables using a new (gzipped) JFR recording. I tried to keep
> this recording as small as possible, while still getting somewhat
> interesting results in the tables.
>
> HdrHistogram itself is already bundled on Maven Central, I simply added
> it to our third-party p2 repository and target platforms. The included
> translations for the word "percentile" are the result of consulting
> online dictionaries, there may be better terms.
>
> Bug: https://bugs.openjdk.java.net/browse/JMC-5327
> Webrev: http://cr.openjdk.java.net/~aptmac/JMC-5327/webrev.00/
> Preview: https://imgur.com/a/MlA2C7y
>
> Thanks,
> Elliott
>
> [1] http://hdrhistogram.org/


Cheers,

Alex

[2] https://travis-ci.org/aptmac/jmc-qa/builds/527337343
[3] https://imgur.com/XfkFqkI
[4] https://imgur.com/Zii9nzw
[5] https://imgur.com/Wyh6nbs

From gerard.ziemski at oracle.com  Thu May  2 17:13:57 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 2 May 2019 12:13:57 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <16c2e23d-0c69-40bc-40d0-75cad1630e4d@oracle.com>
References: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
 <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>
 <5CA4F10F.2010805@oracle.com>
 <b5a611ee-c72f-d7ab-c01f-c833ee94f2ce@oracle.com>
 <5CAD05AF.1090700@oracle.com>
 <2404c7a6-b701-bba9-a2d2-a0b3232cde7e@oracle.com>
 <7002f66b-49af-b38d-8d97-8642e684e998@oracle.com>
 <b56d39a3-9bd7-4eb1-0208-199c9fbaa49f@oracle.com>
 <5CB0CEBE.5000400@oracle.com>
 <72c5aeb5-d65c-33d0-fc95-5e469316478f@oracle.com>
 <5CB6980F.2050800@oracle.com>
 <16c2e23d-0c69-40bc-40d0-75cad1630e4d@oracle.com>
Message-ID: <4e6ec8e2-3ff9-aa74-a75e-655f18cf4bf0@oracle.com>

hi all,

Please review this, hopefully final, fix. After some offline discussion, 
we agreed to:

#1 Keep the rate attributes (can't synthesize otherwise because we don't 
track additions/deletions on their own)

#2 Use data from last event if we can't lock a table (fulfills JFR 
contract in which we need to deliver event at specified period)

Bug:???? https://bugs.openjdk.java.net/browse/JDK-8185525
Webrev:? http://cr.openjdk.java.net/~gziemski/8185525_rev9
Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)

cheers

From marcus.hirt at datadoghq.com  Thu May  2 17:47:14 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 2 May 2019 19:47:14 +0200
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <CAOsn=krdr6nP5BqMCSC6NM2iKFB9f4GkdCYJvuNUMtEuy5NsTQ@mail.gmail.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOsn=krdr6nP5BqMCSC6NM2iKFB9f4GkdCYJvuNUMtEuy5NsTQ@mail.gmail.com>
Message-ID: <CAOpWGx08GDMoOCmN2Z41Gn9eULs79kszjh_Z_0VOuhupJN+QnQ@mail.gmail.com>

We really should automate the verification of formatting, line ending
whitespaces and possibly allow the application of formatting from the
command line too. I'll look into adding spotless or something similar.

/M

On Thu, May 2, 2019 at 6:56 PM Alex Macdonald <almacdon at redhat.com> wrote:

> Hi Elliott,
>
> Overall this patch looks good to me. I've had Travis give it a build and it
> looks good [2].
>
> A handful of minor formatting nits:
>
> - Messages.properties (x3)
> - - the DurationPercentileTable_PERCENTILE_COL_NAME should come after
> DUMP_RECORDING_* for alphabetical order I believe
>
> - There are some cases of extra whitespace, I went through hg diff and
> counted the following number of occurrences:
> - - DurationHdrHistogram (8)
> - - DurationPercentileTable (38)
> - - FileIOPage (5)
> - - SocketIOPage (6)
> - - IOPageTest (5)
> - - IOPageTestBase (4)
> - - SocketIOPageTest(5)
>
> I noticed that when resizing the page, the durations table stays static
> whereas the other tables seems to adjust (gif) [3]. This only seems to
> cause an issue when my JMC window gets resized to just under 50% on my
> monitor width, and the chart will get hidden. In the gif my JMC window is
> around half my monitor width (of 1920), and with the JVM Browser/Outline
> window open then I don't have much more room to shrink the application
> before the chart disappears. I was just curious if the table could adjust
> to resizing like the other tables.
>
> Also not caused by this patch (but thought it'd be interesting to share),
> I'm seeing a bug where my chart text gets really large [4] when I run JMC
> locally and not as an RCP application (I recall seeing a JIRA bug for this
> before, but cannot find it), and my durations tab will only show the table
> (and not even the whole thing) [5].
>
> On Wed, May 1, 2019 at 1:01 PM Elliott Baron <ebaron at redhat.com> wrote:
>
> > Hi,
> >
> > Please review this patch which adds additional IO duration statistics
> > using HdrHistogram [1]. One of the nice features of HdrHistogram is its
> > ability to generate percentile distributions of data, while using
> > limited space. For latency measurements, this can be a useful tool to
> > draw attention to outliers where latency is particularly bad.
> >
> > These statistics are displayed in a new table within the File and Socket
> > IO pages. This table shows the read/write duration at predetermined
> > percentiles (0, 90, 99, 99.9, 99.99, 99.999, and 100), and the total
> > number of items <= that duration. I originally planned to show this
> > information in a chart, but ran into difficulties expressing a
> > non-linear percentile axis with JMC's charting API. After discussions
> > with Marcus, I opted to display this information using a table alongside
> > the existing chart.
> >
> > I included some UI tests that verify the values in each of these
> > HdrHistogram tables using a new (gzipped) JFR recording. I tried to keep
> > this recording as small as possible, while still getting somewhat
> > interesting results in the tables.
> >
> > HdrHistogram itself is already bundled on Maven Central, I simply added
> > it to our third-party p2 repository and target platforms. The included
> > translations for the word "percentile" are the result of consulting
> > online dictionaries, there may be better terms.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JMC-5327
> > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-5327/webrev.00/
> > Preview: https://imgur.com/a/MlA2C7y
> >
> > Thanks,
> > Elliott
> >
> > [1] http://hdrhistogram.org/
>
>
> Cheers,
>
> Alex
>
> [2] https://travis-ci.org/aptmac/jmc-qa/builds/527337343
> [3] https://imgur.com/XfkFqkI
> [4] https://imgur.com/Zii9nzw
> [5] https://imgur.com/Wyh6nbs
>

From erik.gahlin at oracle.com  Thu May  2 17:47:18 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 2 May 2019 19:47:18 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <4e6ec8e2-3ff9-aa74-a75e-655f18cf4bf0@oracle.com>
References: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
 <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>
 <5CA4F10F.2010805@oracle.com>
 <b5a611ee-c72f-d7ab-c01f-c833ee94f2ce@oracle.com>
 <5CAD05AF.1090700@oracle.com>
 <2404c7a6-b701-bba9-a2d2-a0b3232cde7e@oracle.com>
 <7002f66b-49af-b38d-8d97-8642e684e998@oracle.com>
 <b56d39a3-9bd7-4eb1-0208-199c9fbaa49f@oracle.com>
 <5CB0CEBE.5000400@oracle.com>
 <72c5aeb5-d65c-33d0-fc95-5e469316478f@oracle.com>
 <5CB6980F.2050800@oracle.com>
 <16c2e23d-0c69-40bc-40d0-75cad1630e4d@oracle.com>
 <4e6ec8e2-3ff9-aa74-a75e-655f18cf4bf0@oracle.com>
Message-ID: <5CCB2D26.1010408@oracle.com>

Looks good.

Since the tracing framework has been replaced with JFR and there is a 
JIRA tag for "jfr-event-request", we could perhaps remove "[Event 
Request]" and replace "tracing" with "JFR" in the bug title.

Thanks
Erik

> hi all,
>
> Please review this, hopefully final, fix. After some offline 
> discussion, we agreed to:
>
> #1 Keep the rate attributes (can't synthesize otherwise because we 
> don't track additions/deletions on their own)
>
> #2 Use data from last event if we can't lock a table (fulfills JFR 
> contract in which we need to deliver event at specified period)
>
> Bug:     https://bugs.openjdk.java.net/browse/JDK-8185525
> Webrev:  http://cr.openjdk.java.net/~gziemski/8185525_rev9
> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)
>
> cheers


From gerard.ziemski at oracle.com  Thu May  2 18:27:14 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 2 May 2019 13:27:14 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CCB2D26.1010408@oracle.com>
References: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
 <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>
 <5CA4F10F.2010805@oracle.com>
 <b5a611ee-c72f-d7ab-c01f-c833ee94f2ce@oracle.com>
 <5CAD05AF.1090700@oracle.com>
 <2404c7a6-b701-bba9-a2d2-a0b3232cde7e@oracle.com>
 <7002f66b-49af-b38d-8d97-8642e684e998@oracle.com>
 <b56d39a3-9bd7-4eb1-0208-199c9fbaa49f@oracle.com>
 <5CB0CEBE.5000400@oracle.com>
 <72c5aeb5-d65c-33d0-fc95-5e469316478f@oracle.com>
 <5CB6980F.2050800@oracle.com>
 <16c2e23d-0c69-40bc-40d0-75cad1630e4d@oracle.com>
 <4e6ec8e2-3ff9-aa74-a75e-655f18cf4bf0@oracle.com>
 <5CCB2D26.1010408@oracle.com>
Message-ID: <03e84439-ef9f-e343-618c-5f58269220a8@oracle.com>

Thank you Erik!

I changed the bug title (as well as my other JFR event bug title)


cheers

On 5/2/19 12:47 PM, Erik Gahlin wrote:
> Looks good.
>
> Since the tracing framework has been replaced with JFR and there is a 
> JIRA tag for "jfr-event-request", we could perhaps remove "[Event 
> Request]" and replace "tracing" with "JFR" in the bug title.
>
> Thanks
> Erik
>
>> hi all,
>>
>> Please review this, hopefully final, fix. After some offline 
>> discussion, we agreed to:
>>
>> #1 Keep the rate attributes (can't synthesize otherwise because we 
>> don't track additions/deletions on their own)
>>
>> #2 Use data from last event if we can't lock a table (fulfills JFR 
>> contract in which we need to deliver event at specified period)
>>
>> Bug:???? https://bugs.openjdk.java.net/browse/JDK-8185525
>> Webrev:? http://cr.openjdk.java.net/~gziemski/8185525_rev9
>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)
>>
>> cheers
>
>


From kdobson at redhat.com  Fri May  3 14:44:38 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Fri, 3 May 2019 10:44:38 -0400
Subject: RFR 8221507: Implement JFR Events for Shenandoah
Message-ID: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>

Hi all,

Please review this patch that adds support for two new JFR events
ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.

Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/

The Shenandoah team has also reviewed this patch and approved it from their
end.

Thanks,

Ken Dobson

From marcus.hirt at datadoghq.com  Fri May  3 15:07:56 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 3 May 2019 17:07:56 +0200
Subject: Switch to Eclipse RCP 4.11 (2019-03) for JMC 7 GA.
Message-ID: <CAOpWGx2=39U7oOePknvMCi_wF7o0k4wWzxenMcwrsinEOTp8hw@mail.gmail.com>

Hi all,

The release of JMC 7 has been delayed enough that third party
approvals are starting to become an issue (i.e. they are too old). I
therefore propose the following two things:

1. We upgrade the third party dependencies accordingly for the jmc7 repo.
2. To ensure that this does not happen again, there is now a hard
limit on when the source release of JMC 7.0.0 will happen. After the
upcoming three-week iteration I will declare JMC 7 done. I expect
companies preparing to release binary builds of JMC 7 will test the
last few checkins for the jmc7 repo during this time thoroughly, as
they come in.

Kind regards,
Marcus

From sgehwolf at redhat.com  Fri May  3 15:56:52 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 03 May 2019 17:56:52 +0200
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
Message-ID: <9b790032b583039880db3a7da35f5ebe8ea61e2d.camel@redhat.com>

cc'ing hotspot-gc-dev as this also touches GC code (shenandoah).

On Fri, 2019-05-03 at 10:44 -0400, Ken Dobson wrote:
> Hi all,
> 
> Please review this patch that adds support for two new JFR events
> ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
> 
> The Shenandoah team has also reviewed this patch and approved it from their
> end.
> 
> Thanks,
> 
> Ken Dobson


From almacdon at redhat.com  Fri May  3 20:24:40 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Fri, 3 May 2019 16:24:40 -0400
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context
 menu
In-Reply-To: <CAOsn=krz=eY4S+ESvRDeTAbzcYKVy961HWoqDKf3KC7iv=B-XQ@mail.gmail.com>
References: <CAOsn=kqQOObGc=O8D7ewN0ydj=2R0EGgxSawwKQO=t+ggyGV7Q@mail.gmail.com>
 <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com>
 <CAOsn=krTXy1L3-k8MXAWQPu_tRtm+km3ux43W+ihadtzojc6Jw@mail.gmail.com>
 <A4102A46-3E4E-4C9C-B71B-E3A329BE70DB@oracle.com>
 <CAOsn=krz=eY4S+ESvRDeTAbzcYKVy961HWoqDKf3KC7iv=B-XQ@mail.gmail.com>
Message-ID: <CAOsn=kpXBmCnUovdSPf38DR=oNpKWJKsf4sc_hp03YGYkAG68w@mail.gmail.com>

Hi,

On Wed, Apr 17, 2019 at 12:33 PM Alex Macdonald <almacdon at redhat.com> wrote:

> Hi Guru,
>
> On Fri, Apr 12, 2019 at 2:04 PM Guru <guru.hb at oracle.com> wrote:
>
>> Hi Alex,
>>
>> I have tested your patch (Works as expected) and Looks good (except for
>> Mario?s Comment for which you are addressing the same).
>>
>> +nit :
>> Most of the places the some of the declaration is in alphabetical order
>> and for some reason over the time its not. Wish we could spend little more
>> time to keep the uniformity going ahead.
>> Please re-arange the lines accordingly. Find the same example for one of
>> the file and few more which needs to be taken care of.
>> + Messages.java :
>>  492         public static String ThreadsPage_HIDE_THREAD_ACTION;
>>  493         public static String
>> ThreadsPage_RESET_CHART_TO_SELECTION_ACTION;
>>  494         public static String ThreadsPage_EDIT_LANES;
>>
>> Could have been like below
>>  491         public static String ThreadDumpsPage_PAGE_NAME;
>>  492         public static String ThreadsPage_EDIT_LANES;
>>  493         public static String ThreadsPage_HIDE_THREAD_ACTION;
>>  494         public static String ThreadsPage_LANE_TOOLTIP_TITLE;
>>  495         public static String ThreadsPage_NAME;
>>  496         public static String
>> ThreadsPage_RESET_CHART_TO_SELECTION_ACTION;
>>  497         public static String TlabPage_PAGE_NAME;
>>
>> Few more below which can be also re-aligned
>>
>> + flightrecorder/ui/messages/internal/messages.properties
>> + ui/charts/messages.properties
>> + MCJemmyBase.java
>> 77 import org.jemmy.interfaces.Mouse.MouseButtons;
>>
>> + ThreadsPage.java:
>>  comment "Adds the hide thread and reset chart actions to the context
>> menu"
>>  Please update some thing like or a better one.
>>  "Context menu will be udpated with thread which needs to be hiden as
>> well as resets the chart action."
>>
>> "the point at which to right-click and open the context menu" --> origin
>> point of context (right-click)
>>
>> ChartCanvas.java :
>> Please change the order of getter/setters followed by reset i.e
>> (1) getActiveScopeName, (2) setActiveScopeName and (3)
>> resetActiveScopeName instead of (1), (3) and (2).
>>
>
> Great, thank you for the review! I've addressed the formatting issues and
> have an updated webrev for this patch.
>
> Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ [6]
>
> Previously I used string equivalence to determine which thread lane to
> hide, however as Mario pointed out this would not work in the cases where
> multiple threads share the same name. The rendered row on the chart does
> not contain information regarding the source material (other than it's
> name), so I've added an attribute that will hold the IMCThread information
> so when the lane is hovered the IMCThread objects can be checked for
> equivalence instead. Let me know what you think about this approach.
>

I've updated the patch to add a couple more assertions to one of the unit
tests. Please let me know what you think.

Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ [7]
Travis CI Build: https://travis-ci.org/aptmac/jmc-qa/builds/527928758 [8]


>
>
>>
>> Thanks,
>> Guru
>>
>> On 12-Apr-2019, at 7:58 PM, Alex Macdonald <almacdon at redhat.com> wrote:
>>
>> On Fri, Apr 12, 2019 at 10:19 AM Mario Torre <neugens at redhat.com> wrote:
>>
>> On Fri, 2019-04-05 at 13:28 -0400, Alex Macdonald wrote:
>>
>> Hi,
>>
>> The following webrev [0] addresses issue JMC-4466 [1], in which the
>> user
>> should be able to hide threads from the thread chart using context
>> menu
>> actions.
>>
>> This patch adds functionality to the context menu to hide threads
>> from the
>> chart. Additionally, I thought there should be an option to restore
>> the
>> chart to the current selection to "unhide" the threads, so I've also
>> included a menu item that does such that. I've included a GIF [2] to
>> demonstrate how the actions work (note the gif was made before I
>> touched up
>> some of the strings, so some of the wording may be off).
>>
>> The "hide thread" action is only enabled while there are threads that
>> can
>> be hidden, and the "reset chart" option is only enabled while the
>> chart has
>> been modified (i.e., has thread(s) hidden) [3][4]. I've also included
>> uitests that perform the new actions on the chart, and verify the
>> results
>> based on the enablement values of the menu items.
>>
>> Lastly, I've tested these tests and changes locally on my machine and
>> using
>> Travis [5], but these are both Linux environments and it would be
>> nice to
>> make sure there are no issues on Windows / Mac.
>>
>> Thoughts?
>>
>> Cheers,
>>
>> Alex
>>
>> [0] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/
>> [1] https://bugs.openjdk.java.net/browse/JMC-4466
>> [2] https://imgur.com/BkeXkVX
>> [3] https://imgur.com/dhuTmkE
>> [4] https://imgur.com/W7NzOj7
>> [5] https://travis-ci.org/aptmac/jmc-qa/builds/516268811
>>
>>
>> Hi Alex,
>>
>> The patch looks generally good, the only question I have is regarding
>> the thread selection by name:
>>
>> + private int indexOfThreadName(String name) {
>> +   for (int i = 0; i < this.threadRows.size() && name != null; i++) {
>> +     if (this.threadRows.get(i) instanceof QuantitySpanRenderer) {
>> +       if (name.equals(((QuantitySpanRenderer)
>> +           this.threadRows.get(i)).getName())) {
>> +             return i;
>> +       }
>> +     }
>> +   }
>> +  return -1;
>> + }
>>
>> What happens when two threads have the same name? This will make
>> disappear the very fist one with this name encountered, not necessarily
>> the one the user clicked on, isn't it?
>>
>>
>> Ah good call, I hadn't thought about that case. I'll come back with a
>> revised webrev.
>>
>>
>>
>> Cheers,
>> Mario
>> --
>> Mario Torre
>> Associate Manager, Software Engineering
>> Red Hat GmbH <https://www.redhat.com>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>
>>
>> Thanks,
>>
>> Alex
>>
>>
>>
> Cheers,
>
> Alex
>
> [6] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/
>

Cheers,

Alex

[7] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/
[8] https://travis-ci.org/aptmac/jmc-qa/builds/527928758

From coleen.phillimore at oracle.com  Fri May  3 20:54:14 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 3 May 2019 16:54:14 -0400
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <03e84439-ef9f-e343-618c-5f58269220a8@oracle.com>
References: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
 <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>
 <5CA4F10F.2010805@oracle.com>
 <b5a611ee-c72f-d7ab-c01f-c833ee94f2ce@oracle.com>
 <5CAD05AF.1090700@oracle.com>
 <2404c7a6-b701-bba9-a2d2-a0b3232cde7e@oracle.com>
 <7002f66b-49af-b38d-8d97-8642e684e998@oracle.com>
 <b56d39a3-9bd7-4eb1-0208-199c9fbaa49f@oracle.com>
 <5CB0CEBE.5000400@oracle.com>
 <72c5aeb5-d65c-33d0-fc95-5e469316478f@oracle.com>
 <5CB6980F.2050800@oracle.com>
 <16c2e23d-0c69-40bc-40d0-75cad1630e4d@oracle.com>
 <4e6ec8e2-3ff9-aa74-a75e-655f18cf4bf0@oracle.com>
 <5CCB2D26.1010408@oracle.com>
 <03e84439-ef9f-e343-618c-5f58269220a8@oracle.com>
Message-ID: <b4b346a2-01a2-8a7e-40e4-7d15cb79f30f@oracle.com>


Looks like another change has leaked in:

http://cr.openjdk.java.net/~gziemski/8185525_rev9/src/java.base/share/native/libjava/jdk_util.c.udiff.html

Needs @bug 8185525

in test: 
http://cr.openjdk.java.net/~gziemski/8185525_rev9/test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java.html

Otherwise looks good to me.? I don't need to see another webrev for 
this.? Thank you for finding a creative solution to the try_lock problem.

Thanks,
Coleen

On 5/2/19 2:27 PM, gerard ziemski wrote:
> Thank you Erik!
>
> I changed the bug title (as well as my other JFR event bug title)
>
>
> cheers
>
> On 5/2/19 12:47 PM, Erik Gahlin wrote:
>> Looks good.
>>
>> Since the tracing framework has been replaced with JFR and there is a 
>> JIRA tag for "jfr-event-request", we could perhaps remove "[Event 
>> Request]" and replace "tracing" with "JFR" in the bug title.
>>
>> Thanks
>> Erik
>>
>>> hi all,
>>>
>>> Please review this, hopefully final, fix. After some offline 
>>> discussion, we agreed to:
>>>
>>> #1 Keep the rate attributes (can't synthesize otherwise because we 
>>> don't track additions/deletions on their own)
>>>
>>> #2 Use data from last event if we can't lock a table (fulfills JFR 
>>> contract in which we need to deliver event at specified period)
>>>
>>> Bug:???? https://bugs.openjdk.java.net/browse/JDK-8185525
>>> Webrev:? http://cr.openjdk.java.net/~gziemski/8185525_rev9
>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)
>>>
>>> cheers
>>
>>
>


From mikhailo.seledtsov at oracle.com  Fri May  3 22:19:58 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Fri, 3 May 2019 15:19:58 -0700
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
Message-ID: <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>

Hi,

 ? If possible and feasible, could you please implement tests for new 
events?

Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps create 
a "shenandoah" subfolder.

If the events are too hard to test or not feasible, please add the event 
names to test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, 
to the hardToTestEvents set. Consider commenting why it is too hard to test.

Also, please make sure to run all jfr tests under test/jdk/jdk/jfr/ 
prior to integration.


Best regards,

Misha



On 5/3/19 7:44 AM, Ken Dobson wrote:
> Hi all,
>
> Please review this patch that adds support for two new JFR events
> ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
>
> The Shenandoah team has also reviewed this patch and approved it from their
> end.
>
> Thanks,
>
> Ken Dobson


From erik.gahlin at oracle.com  Sat May  4 20:43:27 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Sat, 4 May 2019 22:43:27 +0200
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
Message-ID: <5CCDF96F.8070701@oracle.com>

Hi Ken,

Nice to see some Shenandoah specific events.

- You need to update the configuration files for the events (default.jfc 
and profile.jfc) located in src/jdk.jfr/share/conf/jfr.

- I think you need to put INCLUDE_SHENANDOAHGC inside the TRACE_FUNCTION 
in jfrPeriodic.cpp. A call to the TRACE_FUNCTION will happen regardless 
if it is built with Shenandoah or not, since the dispatch mechanism is 
generated from metadata.xml.

- If Shenandoah is still an experimental feature(?), the Event element 
in metadata.xml should have the experimental="true" attribute set [1].

- It would be nice if you could move the Type element in metadata.xml 
for ShenandoahHeapRegionState below the events so they are next to the 
other Type elements.

Thanks
Erik

[1] The experimental attribute was created so that JVM developers could 
add events more freely to HotSpot without the burden to write unit tests 
or commit to a particular event design. Experimental events are not 
shown in JMC by default, but can be made visible in the Preference 
dialog. See the following picture. 
http://cr.openjdk.java.net/~egahlin/8213966/experimental.png 
<http://cr.openjdk.java.net/%7Eegahlin/8213966/experimental.png>


> Hi all,
>
> Please review this patch that adds support for two new JFR events
> ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
>
> The Shenandoah team has also reviewed this patch and approved it from their
> end.
>
> Thanks,
>
> Ken Dobson


From erik.gahlin at oracle.com  Sat May  4 21:16:00 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Sat, 4 May 2019 23:16:00 +0200
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
 <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>
Message-ID: <5CCE0110.7070908@oracle.com>

On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com wrote:
> Hi,
>
>   If possible and feasible, could you please implement tests for new 
> events?
>
> Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps 
> create a "shenandoah" subfolder.
>
> If the events are too hard to test or not feasible, please add the 
> event names to 
> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, to the 
> hardToTestEvents set. Consider commenting why it is too hard to test.

If events are are marked experimental, tests are ignored by 
TestLookForUntestedEvents. java, so we should not  add them to the 
hardToTestEvents set. That may help them pass under the radar once the 
experimental attribute is removed.

That said, tests never hurts, even if they are experimental. I think 
test/jdk/jdk/jfr/event/gc/detailed would be a good place

Erik

>
> Also, please make sure to run all jfr tests under test/jdk/jdk/jfr/ 
> prior to integration.
>
>
> Best regards,
>
> Misha
>
>
>
> On 5/3/19 7:44 AM, Ken Dobson wrote:
>> Hi all,
>>
>> Please review this patch that adds support for two new JFR events
>> ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
>>
>> The Shenandoah team has also reviewed this patch and approved it from 
>> their
>> end.
>>
>> Thanks,
>>
>> Ken Dobson
>


From guru.hb at oracle.com  Mon May  6 05:34:20 2019
From: guru.hb at oracle.com (Guru)
Date: Mon, 6 May 2019 11:04:20 +0530
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context
 menu
In-Reply-To: <CAOsn=kpXBmCnUovdSPf38DR=oNpKWJKsf4sc_hp03YGYkAG68w@mail.gmail.com>
References: <CAOsn=kqQOObGc=O8D7ewN0ydj=2R0EGgxSawwKQO=t+ggyGV7Q@mail.gmail.com>
 <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com>
 <CAOsn=krTXy1L3-k8MXAWQPu_tRtm+km3ux43W+ihadtzojc6Jw@mail.gmail.com>
 <A4102A46-3E4E-4C9C-B71B-E3A329BE70DB@oracle.com>
 <CAOsn=krz=eY4S+ESvRDeTAbzcYKVy961HWoqDKf3KC7iv=B-XQ@mail.gmail.com>
 <CAOsn=kpXBmCnUovdSPf38DR=oNpKWJKsf4sc_hp03YGYkAG68w@mail.gmail.com>
Message-ID: <D3B09BFA-5A2D-48D8-BA47-1B4E97E8FD55@oracle.com>

+1, Looks good to me. 

Thanks
Guru
> On 04-May-2019, at 1:54 AM, Alex Macdonald <almacdon at redhat.com> wrote:
> 
> Hi,
> 
> On Wed, Apr 17, 2019 at 12:33 PM Alex Macdonald <almacdon at redhat.com <mailto:almacdon at redhat.com>> wrote:
> Hi Guru,
> 
> On Fri, Apr 12, 2019 at 2:04 PM Guru <guru.hb at oracle.com <mailto:guru.hb at oracle.com>> wrote:
> Hi Alex,
> 
> I have tested your patch (Works as expected) and Looks good (except for Mario?s Comment for which you are addressing the same). 
> 
> +nit : 
> Most of the places the some of the declaration is in alphabetical order and for some reason over the time its not. Wish we could spend little more time to keep the uniformity going ahead. 
> Please re-arange the lines accordingly. Find the same example for one of the file and few more which needs to be taken care of. 
> + Messages.java : 
>  492         public static String ThreadsPage_HIDE_THREAD_ACTION;
>  493         public static String ThreadsPage_RESET_CHART_TO_SELECTION_ACTION;
>  494         public static String ThreadsPage_EDIT_LANES;
> 
> Could have been like below 
>  491         public static String ThreadDumpsPage_PAGE_NAME;
>  492         public static String ThreadsPage_EDIT_LANES; 
>  493         public static String ThreadsPage_HIDE_THREAD_ACTION;
>  494         public static String ThreadsPage_LANE_TOOLTIP_TITLE;
>  495         public static String ThreadsPage_NAME;
>  496         public static String ThreadsPage_RESET_CHART_TO_SELECTION_ACTION;
>  497         public static String TlabPage_PAGE_NAME;
> 
> Few more below which can be also re-aligned
> 
> + flightrecorder/ui/messages/internal/messages.properties 
> + ui/charts/messages.properties
> + MCJemmyBase.java
> 	77 import org.jemmy.interfaces.Mouse.MouseButtons;
> 
> + ThreadsPage.java: 
>  comment "Adds the hide thread and reset chart actions to the context menu"
>  Please update some thing like or a better one.
>  "Context menu will be udpated with thread which needs to be hiden as well as resets the chart action." 
>  
> "the point at which to right-click and open the context menu" --> origin point of context (right-click) 
> 
> ChartCanvas.java : 
> Please change the order of getter/setters followed by reset i.e 
> (1) getActiveScopeName, (2) setActiveScopeName and (3) resetActiveScopeName instead of (1), (3) and (2).
> 
> Great, thank you for the review! I've addressed the formatting issues and have an updated webrev for this patch.
> 
> Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/> [6]
> 
> Previously I used string equivalence to determine which thread lane to hide, however as Mario pointed out this would not work in the cases where multiple threads share the same name. The rendered row on the chart does not contain information regarding the source material (other than it's name), so I've added an attribute that will hold the IMCThread information so when the lane is hovered the IMCThread objects can be checked for equivalence instead. Let me know what you think about this approach.
> 
> I've updated the patch to add a couple more assertions to one of the unit tests. Please let me know what you think.
> 
> Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/> [7]
> Travis CI Build: https://travis-ci.org/aptmac/jmc-qa/builds/527928758 <https://travis-ci.org/aptmac/jmc-qa/builds/527928758> [8]
>  
>  
> 
> Thanks,
> Guru
> 
>> On 12-Apr-2019, at 7:58 PM, Alex Macdonald <almacdon at redhat.com <mailto:almacdon at redhat.com>> wrote:
>> 
>> On Fri, Apr 12, 2019 at 10:19 AM Mario Torre <neugens at redhat.com <mailto:neugens at redhat.com>> wrote:
>> 
>>> On Fri, 2019-04-05 at 13:28 -0400, Alex Macdonald wrote:
>>>> Hi,
>>>> 
>>>> The following webrev [0] addresses issue JMC-4466 [1], in which the
>>>> user
>>>> should be able to hide threads from the thread chart using context
>>>> menu
>>>> actions.
>>>> 
>>>> This patch adds functionality to the context menu to hide threads
>>>> from the
>>>> chart. Additionally, I thought there should be an option to restore
>>>> the
>>>> chart to the current selection to "unhide" the threads, so I've also
>>>> included a menu item that does such that. I've included a GIF [2] to
>>>> demonstrate how the actions work (note the gif was made before I
>>>> touched up
>>>> some of the strings, so some of the wording may be off).
>>>> 
>>>> The "hide thread" action is only enabled while there are threads that
>>>> can
>>>> be hidden, and the "reset chart" option is only enabled while the
>>>> chart has
>>>> been modified (i.e., has thread(s) hidden) [3][4]. I've also included
>>>> uitests that perform the new actions on the chart, and verify the
>>>> results
>>>> based on the enablement values of the menu items.
>>>> 
>>>> Lastly, I've tested these tests and changes locally on my machine and
>>>> using
>>>> Travis [5], but these are both Linux environments and it would be
>>>> nice to
>>>> make sure there are no issues on Windows / Mac.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Cheers,
>>>> 
>>>> Alex
>>>> 
>>>> [0] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/>
>>>> [1] https://bugs.openjdk.java.net/browse/JMC-4466 <https://bugs.openjdk.java.net/browse/JMC-4466>
>>>> [2] https://imgur.com/BkeXkVX <https://imgur.com/BkeXkVX>
>>>> [3] https://imgur.com/dhuTmkE <https://imgur.com/dhuTmkE>
>>>> [4] https://imgur.com/W7NzOj7 <https://imgur.com/W7NzOj7>
>>>> [5] https://travis-ci.org/aptmac/jmc-qa/builds/516268811 <https://travis-ci.org/aptmac/jmc-qa/builds/516268811>
>>> 
>>> Hi Alex,
>>> 
>>> The patch looks generally good, the only question I have is regarding
>>> the thread selection by name:
>>> 
>>> + private int indexOfThreadName(String name) {
>>> +   for (int i = 0; i < this.threadRows.size() && name != null; i++) {
>>> +     if (this.threadRows.get(i) instanceof QuantitySpanRenderer) {
>>> +       if (name.equals(((QuantitySpanRenderer)
>>> +           this.threadRows.get(i)).getName())) {
>>> +             return i;
>>> +       }
>>> +     }
>>> +   }
>>> +  return -1;
>>> + }
>>> 
>>> What happens when two threads have the same name? This will make
>>> disappear the very fist one with this name encountered, not necessarily
>>> the one the user clicked on, isn't it?
>>> 
>> 
>> Ah good call, I hadn't thought about that case. I'll come back with a
>> revised webrev.
>> 
>> 
>>> 
>>> Cheers,
>>> Mario
>>> --
>>> Mario Torre
>>> Associate Manager, Software Engineering
>>> Red Hat GmbH <https://www.redhat.com <https://www.redhat.com/>>
>>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>> 
>> 
>> Thanks,
>> 
>> Alex
> 
> 
> Cheers,
> 
> Alex
> 
> [6] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/>
> 
> Cheers,
> 
> Alex
> 
> [7] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/>
> [8] https://travis-ci.org/aptmac/jmc-qa/builds/527928758 <https://travis-ci.org/aptmac/jmc-qa/builds/527928758>

From klara at kth.se  Mon May  6 12:00:56 2019
From: klara at kth.se (Klara Ward)
Date: Mon, 6 May 2019 14:00:56 +0200
Subject: CFV: New JMC Reviewer: Guru Hb
In-Reply-To: <CAOpWGx2QULx2=ZTNQHvocFifOvvzRcuTGgpvU+wKdey=OMf-yw@mail.gmail.com>
References: <CAOpWGx2QULx2=ZTNQHvocFifOvvzRcuTGgpvU+wKdey=OMf-yw@mail.gmail.com>
Message-ID: <9ad8d540-a001-27bc-482c-e4f8b619d0af@kth.se>

Vote: yes

// Klara


On 2019-04-12 21:26, Marcus Hirt wrote:
> Hi all,
>
> I hereby nominate Guru Hb to JMC Reviewer.
>
> Guru Hb has been working as a very prolific JMC developer
> for some time now, and is responsible for the entire JMC
> build infrastructure at Oracle. Guru has contributed fixes
> all over, even before JMC was open sourced.
>
> Votes are due by the 29th of April.
>
> Only current JMC Reviewers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [2].
>
> Kind regards,
> Marcus
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#reviewer-vote


From marcus.hirt at datadoghq.com  Mon May  6 12:08:38 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 6 May 2019 14:08:38 +0200
Subject: Result: New JMC Reviewer: Guru Hb
Message-ID: <CAOpWGx3UV8MaLBfY8EcbH24n02ph5UsXACUk6gqOOQXThOkxDQ@mail.gmail.com>

Voting for Guru Hb (ghb) [1] is now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is
sufficient to approve the nomination.

Thanks,
Marcus

[1] https://mail.openjdk.java.net/pipermail/jmc-dev/2019-April/000945.html

From mikhailo.seledtsov at oracle.com  Mon May  6 15:38:08 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Mon, 6 May 2019 08:38:08 -0700
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <5CCE0110.7070908@oracle.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
 <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>
 <5CCE0110.7070908@oracle.com>
Message-ID: <2055f245-c722-c61b-2f85-406341cb6668@oracle.com>



On 5/4/19 2:16 PM, Erik Gahlin wrote:
> On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com wrote:
>> Hi,
>>
>> ? If possible and feasible, could you please implement tests for new 
>> events?
>>
>> Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps 
>> create a "shenandoah" subfolder.
>>
>> If the events are too hard to test or not feasible, please add the 
>> event names to 
>> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, to 
>> the hardToTestEvents set. Consider commenting why it is too hard to 
>> test.
>
> If events are are marked experimental, tests are ignored by 
> TestLookForUntestedEvents. java, so we should not? add them to the 
> hardToTestEvents set. That may help them pass under the radar once the 
> experimental attribute is removed.
Thank you. If the events are "experimental" this approach makes sense. 
Once the experimental status is removed, the 
TestLookForUntestedEvents.java should be able to notice if the event is 
not covered by tests.
> That said, tests never hurts, even if they are experimental. I think 
> test/jdk/jdk/jfr/event/gc/detailed would be a good place
+1

Thank you,
Misha
>
> Erik
>
>>
>> Also, please make sure to run all jfr tests under test/jdk/jdk/jfr/ 
>> prior to integration.
>>
>>
>> Best regards,
>>
>> Misha
>>
>>
>>
>> On 5/3/19 7:44 AM, Ken Dobson wrote:
>>> Hi all,
>>>
>>> Please review this patch that adds support for two new JFR events
>>> ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
>>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
>>>
>>> The Shenandoah team has also reviewed this patch and approved it 
>>> from their
>>> end.
>>>
>>> Thanks,
>>>
>>> Ken Dobson
>>
>


From neugens at redhat.com  Mon May  6 17:51:56 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 6 May 2019 19:51:56 +0200
Subject: Java Mission Control Author request for: Elliott Baron
Message-ID: <CAJwKKmbDeUeaJQBFJ=wGi1Y+Wyi+v3i9VrSHREeUY7h18cFSJQ@mail.gmail.com>

Hello Marcus,

I would like to propose Elliott Baron <ebaron at redhat.com> as author
for JDK Mission Control project.

Elliott has been active on the JMC project with already some
fixes[1][2][3] and is working now on porting the HDR Histogram
work[4]:

[1] JMC-6180: http://hg.openjdk.java.net/jmc/jmc/rev/c4b6a87219c3
[2] JMC-5768: http://hg.openjdk.java.net/jmc/jmc/rev/e290828d0636
[3] JMC-6211: http://hg.openjdk.java.net/jmc/jmc/rev/5b9d72265772

[4] https://bugs.openjdk.java.net/browse/JMC-5327

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus.hirt at datadoghq.com  Mon May  6 18:35:51 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 6 May 2019 20:35:51 +0200
Subject: Java Mission Control Author request for: Elliott Baron
In-Reply-To: <CAJwKKmbDeUeaJQBFJ=wGi1Y+Wyi+v3i9VrSHREeUY7h18cFSJQ@mail.gmail.com>
References: <CAJwKKmbDeUeaJQBFJ=wGi1Y+Wyi+v3i9VrSHREeUY7h18cFSJQ@mail.gmail.com>
Message-ID: <CAOpWGx3c5t01+_0H_G1ZiiUKYWyDkxwb6SNCaJiPPqFn2gJm9w@mail.gmail.com>

Hi Mario,

Agreed. I have posted the request to the registrar.

Kind regards,
Marcus

On Mon, May 6, 2019 at 7:52 PM Mario Torre <neugens at redhat.com> wrote:
>
> Hello Marcus,
>
> I would like to propose Elliott Baron <ebaron at redhat.com> as author
> for JDK Mission Control project.
>
> Elliott has been active on the JMC project with already some
> fixes[1][2][3] and is working now on porting the HDR Histogram
> work[4]:
>
> [1] JMC-6180: http://hg.openjdk.java.net/jmc/jmc/rev/c4b6a87219c3
> [2] JMC-5768: http://hg.openjdk.java.net/jmc/jmc/rev/e290828d0636
> [3] JMC-6211: http://hg.openjdk.java.net/jmc/jmc/rev/5b9d72265772
>
> [4] https://bugs.openjdk.java.net/browse/JMC-5327
>
> Cheers,
> Mario
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From neugens at redhat.com  Tue May  7 10:08:17 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 7 May 2019 12:08:17 +0200
Subject: Java Mission Control Author request for: Elliott Baron
In-Reply-To: <CAOpWGx3c5t01+_0H_G1ZiiUKYWyDkxwb6SNCaJiPPqFn2gJm9w@mail.gmail.com>
References: <CAJwKKmbDeUeaJQBFJ=wGi1Y+Wyi+v3i9VrSHREeUY7h18cFSJQ@mail.gmail.com>
 <CAOpWGx3c5t01+_0H_G1ZiiUKYWyDkxwb6SNCaJiPPqFn2gJm9w@mail.gmail.com>
Message-ID: <CAJwKKmYe_vxMZS_MJ=rAaDF0W_bngri1bSidN9Hwm5J=-f1gkg@mail.gmail.com>

Thanks!

Cheers,
Mario

On Mon, May 6, 2019 at 8:36 PM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>
> Hi Mario,
>
> Agreed. I have posted the request to the registrar.
>
> Kind regards,
> Marcus
>
> On Mon, May 6, 2019 at 7:52 PM Mario Torre <neugens at redhat.com> wrote:
> >
> > Hello Marcus,
> >
> > I would like to propose Elliott Baron <ebaron at redhat.com> as author
> > for JDK Mission Control project.
> >
> > Elliott has been active on the JMC project with already some
> > fixes[1][2][3] and is working now on porting the HDR Histogram
> > work[4]:
> >
> > [1] JMC-6180: http://hg.openjdk.java.net/jmc/jmc/rev/c4b6a87219c3
> > [2] JMC-5768: http://hg.openjdk.java.net/jmc/jmc/rev/e290828d0636
> > [3] JMC-6211: http://hg.openjdk.java.net/jmc/jmc/rev/5b9d72265772
> >
> > [4] https://bugs.openjdk.java.net/browse/JMC-5327
> >
> > Cheers,
> > Mario
> >
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From carusso at redhat.com  Tue May  7 08:35:29 2019
From: carusso at redhat.com (Carmine Vincenzo Russo)
Date: Tue, 7 May 2019 10:35:29 +0200
Subject: RFC: JMC-5657: Code coverage with Jacoco
Message-ID: <CAA6KdKcBcyHmPU4hoky8D=qMV9yO8UWWgbKcKTuBv2S_CqRHRw@mail.gmail.com>

Hello everyone,

This patch adds Jacoco coverage over unit test in JMC.
The module covered in particular are: /core/tests and /application/tests.

The patch addresses the issue JMC-5657[0], but as noted by Klara Ward[1],
instead of adding Jcov, it's better to add Jacoco.

For the time being, each test group had a new module, report, where an
aggregate-report can be found.
You need to run 'mvn verify' in jmc root for /application/tests and in
/core for /core/tests to have the coverage report.

There are also some aspects that concern me, so: Is this what we are
looking for?
The report for /core[2] looks good and clean. The report for
/application/tests[3][4] has good results, although there are some 0%, and
that is ok, but also some N/A. Should we keep the modules in the report
with only N/A?

There are also some changes in /application/uitests when reading the patch,
they are not yet applied but I would like to add them to the next patch.
This brings me to my second concern: should the tests and uitests in
/application have a unique report or should I keep them separate?

Lastly, do we want coverage with every verify build or do we want a maven
profile/flag to have the coverage only in some occasions?

Overall, how does the patch look like? Do you think there are some more
modules that need to be covered? And do you have any suggestions on how to
improve what I've done?

Thanks,
Carmine

[0] https://bugs.openjdk.java.net/browse/JMC-5657
[1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-March/000882.html
[2] https://imgur.com/hPyyLsQ
[3] https://imgur.com/fqdzGvH
[4] https://imgur.com/ozqNcAB

-- 
Carmine Vincenzo Russo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5657-0.patch
Type: text/x-patch
Size: 28850 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190507/8d4917f1/5657-0-0001.patch>

From guru.hb at oracle.com  Tue May  7 16:37:41 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 7 May 2019 22:07:41 +0530
Subject: RFC: JMC-5657: Code coverage with Jacoco
In-Reply-To: <CAA6KdKcBcyHmPU4hoky8D=qMV9yO8UWWgbKcKTuBv2S_CqRHRw@mail.gmail.com>
References: <CAA6KdKcBcyHmPU4hoky8D=qMV9yO8UWWgbKcKTuBv2S_CqRHRw@mail.gmail.com>
Message-ID: <B17AB67E-5845-47B1-9B3D-4415642A7957@oracle.com>

Hi Carmine, 

Please check my comments inline.

Thanks,
Guru
> On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo <carusso at redhat.com> wrote:
> 
> Hello everyone,
> 
> This patch adds Jacoco coverage over unit test in JMC.
> The module covered in particular are: /core/tests and /application/tests.
> 
> The patch addresses the issue JMC-5657[0], but as noted by Klara Ward[1],
> instead of adding Jcov, it's better to add Jacoco.
> 
> For the time being, each test group had a new module, report, where an
> aggregate-report can be found.
> You need to run 'mvn verify' in jmc root for /application/tests and in
> /core for /core/tests to have the coverage report.
Logically there are three build step 
1. For releng 
2. Core modules 
3. Jmc product (i.e Application) 
Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for step 3). Unless there is restriction on defining Jacoco in root of ~/jmc/core/pom.xml and ~/jmc/pom.xml. 
> 
> There are also some aspects that concern me, so: Is this what we are
> looking for?
> The report for /core[2] looks good and clean. The report for
> /application/tests[3][4] has good results, although there are some 0%, and
> that is ok, but also some N/A. Should we keep the modules in the report
> with only N/A?
> 
> There are also some changes in /application/uitests when reading the patch,
> they are not yet applied but I would like to add them to the next patch.
Please file a follow on new JBS and link with old one (relates to JMC-5667). 
> This brings me to my second concern: should the tests and uitests in
> /application have a unique report or should I keep them separate?
Good to have Unique rather than separate. 
> 
> Lastly, do we want coverage with every verify build or do we want a maven
> profile/flag to have the coverage only in some occasions?
This could be based on how much time Jacoco Code coverage takes. If its negligible then good to have on every verify build or with a profile/flag. 
> 
> Overall, how does the patch look like? Do you think there are some more
> modules that need to be covered? And do you have any suggestions on how to
> improve what I've done?
If possible, please update the patch to ~/jmc/core/pom.xml and ~/jmc/pom.xml. 
> 
> Thanks,
> Carmine
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-5657
> [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-March/000882.html
> [2] https://imgur.com/hPyyLsQ
> [3] https://imgur.com/fqdzGvH
> [4] https://imgur.com/ozqNcAB
> 
> -- 
> Carmine Vincenzo Russo
> <5657-0.patch>


From marcus at hirt.se  Wed May  8 12:07:39 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 8 May 2019 14:07:39 +0200
Subject: JMC-6461: Cleaner versioning information when not embedding a JDK
Message-ID: <00d601d50596$a20900f0$e61b02d0$@hirt.se>

Hi all,

Please review this change to clean up the about box versioning
information when not embedding a JDK (seems to be the path that 
most vendors have chosen).

Jira:   https://bugs.openjdk.java.net/browse/JMC-6461
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6461/webrev.0/

Kind regards,
Marcus


From guru.hb at oracle.com  Wed May  8 12:18:20 2019
From: guru.hb at oracle.com (Guru)
Date: Wed, 8 May 2019 17:48:20 +0530
Subject: JMC-6461: Cleaner versioning information when not embedding a JDK
In-Reply-To: <00d601d50596$a20900f0$e61b02d0$@hirt.se>
References: <00d601d50596$a20900f0$e61b02d0$@hirt.se>
Message-ID: <2776CF93-D96E-4ED2-8773-AA2A4835AD27@oracle.com>

+1, Tested on Mac OS X. 

Thanks,
Guru
> On 08-May-2019, at 5:37 PM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi all,
> 
> Please review this change to clean up the about box versioning
> information when not embedding a JDK (seems to be the path that 
> most vendors have chosen).
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6461
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6461/webrev.0/
> 
> Kind regards,
> Marcus
> 


From marcus at hirt.se  Wed May  8 18:30:12 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Wed, 08 May 2019 18:30:12 +0000
Subject: hg: jmc/jmc: JMC-6461: Cleaner versioning information when not
 embedding a JDK
Message-ID: <201905081830.x48IUCUY029026@aojmv0008.oracle.com>

Changeset: f927bf19d4f0
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-08 20:30 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/f927bf19d4f0

JMC-6461: Cleaner versioning information when not embedding a JDK
Reviewed-by: ghb

! application/l10n/org.openjdk.jmc.rcp.application.ja/plugin_ja.properties
! application/l10n/org.openjdk.jmc.rcp.application.zh_CN/plugin_zh_CN.properties
! application/org.openjdk.jmc.rcp.application/plugin.properties
! pom.xml


From neugens at redhat.com  Thu May  9 15:32:01 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 9 May 2019 17:32:01 +0200
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context
 menu
In-Reply-To: <D3B09BFA-5A2D-48D8-BA47-1B4E97E8FD55@oracle.com>
References: <CAOsn=kqQOObGc=O8D7ewN0ydj=2R0EGgxSawwKQO=t+ggyGV7Q@mail.gmail.com>
 <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com>
 <CAOsn=krTXy1L3-k8MXAWQPu_tRtm+km3ux43W+ihadtzojc6Jw@mail.gmail.com>
 <A4102A46-3E4E-4C9C-B71B-E3A329BE70DB@oracle.com>
 <CAOsn=krz=eY4S+ESvRDeTAbzcYKVy961HWoqDKf3KC7iv=B-XQ@mail.gmail.com>
 <CAOsn=kpXBmCnUovdSPf38DR=oNpKWJKsf4sc_hp03YGYkAG68w@mail.gmail.com>
 <D3B09BFA-5A2D-48D8-BA47-1B4E97E8FD55@oracle.com>
Message-ID: <CAJwKKma8T3QnwieVV5eG+o4V_UtLiPFZsVho1t6_f_Y3xtsEAQ@mail.gmail.com>

Likewise!

Cheers,
Mario

On Mon, May 6, 2019 at 7:34 AM Guru <guru.hb at oracle.com> wrote:
>
> +1, Looks good to me.
>
> Thanks
> Guru
> > On 04-May-2019, at 1:54 AM, Alex Macdonald <almacdon at redhat.com> wrote:
> >
> > Hi,
> >
> > On Wed, Apr 17, 2019 at 12:33 PM Alex Macdonald <almacdon at redhat.com <mailto:almacdon at redhat.com>> wrote:
> > Hi Guru,
> >
> > On Fri, Apr 12, 2019 at 2:04 PM Guru <guru.hb at oracle.com <mailto:guru.hb at oracle.com>> wrote:
> > Hi Alex,
> >
> > I have tested your patch (Works as expected) and Looks good (except for Mario?s Comment for which you are addressing the same).
> >
> > +nit :
> > Most of the places the some of the declaration is in alphabetical order and for some reason over the time its not. Wish we could spend little more time to keep the uniformity going ahead.
> > Please re-arange the lines accordingly. Find the same example for one of the file and few more which needs to be taken care of.
> > + Messages.java :
> >  492         public static String ThreadsPage_HIDE_THREAD_ACTION;
> >  493         public static String ThreadsPage_RESET_CHART_TO_SELECTION_ACTION;
> >  494         public static String ThreadsPage_EDIT_LANES;
> >
> > Could have been like below
> >  491         public static String ThreadDumpsPage_PAGE_NAME;
> >  492         public static String ThreadsPage_EDIT_LANES;
> >  493         public static String ThreadsPage_HIDE_THREAD_ACTION;
> >  494         public static String ThreadsPage_LANE_TOOLTIP_TITLE;
> >  495         public static String ThreadsPage_NAME;
> >  496         public static String ThreadsPage_RESET_CHART_TO_SELECTION_ACTION;
> >  497         public static String TlabPage_PAGE_NAME;
> >
> > Few more below which can be also re-aligned
> >
> > + flightrecorder/ui/messages/internal/messages.properties
> > + ui/charts/messages.properties
> > + MCJemmyBase.java
> >       77 import org.jemmy.interfaces.Mouse.MouseButtons;
> >
> > + ThreadsPage.java:
> >  comment "Adds the hide thread and reset chart actions to the context menu"
> >  Please update some thing like or a better one.
> >  "Context menu will be udpated with thread which needs to be hiden as well as resets the chart action."
> >
> > "the point at which to right-click and open the context menu" --> origin point of context (right-click)
> >
> > ChartCanvas.java :
> > Please change the order of getter/setters followed by reset i.e
> > (1) getActiveScopeName, (2) setActiveScopeName and (3) resetActiveScopeName instead of (1), (3) and (2).
> >
> > Great, thank you for the review! I've addressed the formatting issues and have an updated webrev for this patch.
> >
> > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/> [6]
> >
> > Previously I used string equivalence to determine which thread lane to hide, however as Mario pointed out this would not work in the cases where multiple threads share the same name. The rendered row on the chart does not contain information regarding the source material (other than it's name), so I've added an attribute that will hold the IMCThread information so when the lane is hovered the IMCThread objects can be checked for equivalence instead. Let me know what you think about this approach.
> >
> > I've updated the patch to add a couple more assertions to one of the unit tests. Please let me know what you think.
> >
> > Webrev: http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/> [7]
> > Travis CI Build: https://travis-ci.org/aptmac/jmc-qa/builds/527928758 <https://travis-ci.org/aptmac/jmc-qa/builds/527928758> [8]
> >
> >
> >
> > Thanks,
> > Guru
> >
> >> On 12-Apr-2019, at 7:58 PM, Alex Macdonald <almacdon at redhat.com <mailto:almacdon at redhat.com>> wrote:
> >>
> >> On Fri, Apr 12, 2019 at 10:19 AM Mario Torre <neugens at redhat.com <mailto:neugens at redhat.com>> wrote:
> >>
> >>> On Fri, 2019-04-05 at 13:28 -0400, Alex Macdonald wrote:
> >>>> Hi,
> >>>>
> >>>> The following webrev [0] addresses issue JMC-4466 [1], in which the
> >>>> user
> >>>> should be able to hide threads from the thread chart using context
> >>>> menu
> >>>> actions.
> >>>>
> >>>> This patch adds functionality to the context menu to hide threads
> >>>> from the
> >>>> chart. Additionally, I thought there should be an option to restore
> >>>> the
> >>>> chart to the current selection to "unhide" the threads, so I've also
> >>>> included a menu item that does such that. I've included a GIF [2] to
> >>>> demonstrate how the actions work (note the gif was made before I
> >>>> touched up
> >>>> some of the strings, so some of the wording may be off).
> >>>>
> >>>> The "hide thread" action is only enabled while there are threads that
> >>>> can
> >>>> be hidden, and the "reset chart" option is only enabled while the
> >>>> chart has
> >>>> been modified (i.e., has thread(s) hidden) [3][4]. I've also included
> >>>> uitests that perform the new actions on the chart, and verify the
> >>>> results
> >>>> based on the enablement values of the menu items.
> >>>>
> >>>> Lastly, I've tested these tests and changes locally on my machine and
> >>>> using
> >>>> Travis [5], but these are both Linux environments and it would be
> >>>> nice to
> >>>> make sure there are no issues on Windows / Mac.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Alex
> >>>>
> >>>> [0] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.00/>
> >>>> [1] https://bugs.openjdk.java.net/browse/JMC-4466 <https://bugs.openjdk.java.net/browse/JMC-4466>
> >>>> [2] https://imgur.com/BkeXkVX <https://imgur.com/BkeXkVX>
> >>>> [3] https://imgur.com/dhuTmkE <https://imgur.com/dhuTmkE>
> >>>> [4] https://imgur.com/W7NzOj7 <https://imgur.com/W7NzOj7>
> >>>> [5] https://travis-ci.org/aptmac/jmc-qa/builds/516268811 <https://travis-ci.org/aptmac/jmc-qa/builds/516268811>
> >>>
> >>> Hi Alex,
> >>>
> >>> The patch looks generally good, the only question I have is regarding
> >>> the thread selection by name:
> >>>
> >>> + private int indexOfThreadName(String name) {
> >>> +   for (int i = 0; i < this.threadRows.size() && name != null; i++) {
> >>> +     if (this.threadRows.get(i) instanceof QuantitySpanRenderer) {
> >>> +       if (name.equals(((QuantitySpanRenderer)
> >>> +           this.threadRows.get(i)).getName())) {
> >>> +             return i;
> >>> +       }
> >>> +     }
> >>> +   }
> >>> +  return -1;
> >>> + }
> >>>
> >>> What happens when two threads have the same name? This will make
> >>> disappear the very fist one with this name encountered, not necessarily
> >>> the one the user clicked on, isn't it?
> >>>
> >>
> >> Ah good call, I hadn't thought about that case. I'll come back with a
> >> revised webrev.
> >>
> >>
> >>>
> >>> Cheers,
> >>> Mario
> >>> --
> >>> Mario Torre
> >>> Associate Manager, Software Engineering
> >>> Red Hat GmbH <https://www.redhat.com <https://www.redhat.com/>>
> >>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >>>
> >>
> >> Thanks,
> >>
> >> Alex
> >
> >
> > Cheers,
> >
> > Alex
> >
> > [6] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.01/>
> >
> > Cheers,
> >
> > Alex
> >
> > [7] http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/ <http://cr.openjdk.java.net/~aptmac/JMC-4466/webrev.02/>
> > [8] https://travis-ci.org/aptmac/jmc-qa/builds/527928758 <https://travis-ci.org/aptmac/jmc-qa/builds/527928758>



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From almacdon at redhat.com  Thu May  9 16:39:45 2019
From: almacdon at redhat.com (almacdon at redhat.com)
Date: Thu, 09 May 2019 16:39:45 +0000
Subject: hg: jmc/jmc: JMC-4466: Hide thread directly from Thread graph context
 menu
Message-ID: <201905091639.x49Gdjp6029188@aojmv0008.oracle.com>

Changeset: e3ea3697d0b3
Author:    aptmac <almacdon at redhat.com>
Date:      2019-05-09 11:48 -0400
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/e3ea3697d0b3

JMC-4466: Hide thread directly from Thread graph context menu
Summary: Add functionality to the context menu to hide threads from the JFR Threads page graph, and reset the graph to display the current selection of Threads
Reviewed-by: ghb, neugens

! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ChartToolTipProvider.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ThreadGraphLanes.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/ThreadsPage.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/charts/IChartInfoVisitor.java
! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/charts/Messages.java
! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/charts/QuantitySpanRenderer.java
! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/charts/RendererToolkit.java
! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/misc/ChartCanvas.java
! application/org.openjdk.jmc.ui/src/main/resources/org/openjdk/jmc/ui/charts/messages.properties
+ application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/JfrThreadsPageTest.java
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/base/wrappers/MCJemmyBase.java
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrUi.java
+ application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCChartCanvas.java
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCTable.java


From kdobson at redhat.com  Fri May 10 16:58:00 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Fri, 10 May 2019 12:58:00 -0400
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <2055f245-c722-c61b-2f85-406341cb6668@oracle.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
 <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>
 <5CCE0110.7070908@oracle.com>
 <2055f245-c722-c61b-2f85-406341cb6668@oracle.com>
Message-ID: <CADPaBqk9QiKV7F=qMtLt8Zp7Ew35YU6937t93a2UF6YK7_rFZQ@mail.gmail.com>

Thanks everyone for their reviews. I've added tests similar to the tests
for the G1 events as well as addressed the changes that Erik recommended.

Here is the new webrev:
http://cr.openjdk.java.net/~kdobson/shenandoaheventswithtests/webrev/

Please let me know if there's anything else that should be addressed.

Thanks,

Ken Dobson

On Mon, May 6, 2019 at 11:38 AM <mikhailo.seledtsov at oracle.com> wrote:

>
>
> On 5/4/19 2:16 PM, Erik Gahlin wrote:
> > On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com wrote:
> >> Hi,
> >>
> >>   If possible and feasible, could you please implement tests for new
> >> events?
> >>
> >> Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps
> >> create a "shenandoah" subfolder.
> >>
> >> If the events are too hard to test or not feasible, please add the
> >> event names to
> >> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, to
> >> the hardToTestEvents set. Consider commenting why it is too hard to
> >> test.
> >
> > If events are are marked experimental, tests are ignored by
> > TestLookForUntestedEvents. java, so we should not  add them to the
> > hardToTestEvents set. That may help them pass under the radar once the
> > experimental attribute is removed.
> Thank you. If the events are "experimental" this approach makes sense.
> Once the experimental status is removed, the
> TestLookForUntestedEvents.java should be able to notice if the event is
> not covered by tests.
> > That said, tests never hurts, even if they are experimental. I think
> > test/jdk/jdk/jfr/event/gc/detailed would be a good place
> +1
>
> Thank you,
> Misha
> >
> > Erik
> >
> >>
> >> Also, please make sure to run all jfr tests under test/jdk/jdk/jfr/
> >> prior to integration.
> >>
> >>
> >> Best regards,
> >>
> >> Misha
> >>
> >>
> >>
> >> On 5/3/19 7:44 AM, Ken Dobson wrote:
> >>> Hi all,
> >>>
> >>> Please review this patch that adds support for two new JFR events
> >>> ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.
> >>>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
> >>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
> >>>
> >>> The Shenandoah team has also reviewed this patch and approved it
> >>> from their
> >>> end.
> >>>
> >>> Thanks,
> >>>
> >>> Ken Dobson
> >>
> >
>
>

From almacdon at redhat.com  Fri May 10 18:16:22 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Fri, 10 May 2019 14:16:22 -0400
Subject: RFR: JMC-6368: Foldable threads table in the Threads page
Message-ID: <CAOsn=kpNVXFoVKbp5kwFRs3Be2Yyqt8n2611E3mv_oKtB=Q-EA@mail.gmail.com>

Hi,

The following webrev [0] addresses issue JMC-6368 [1], in which the user
should be able to fold away the table and graph on the Threads page to
reclaim screen real-estate.

I had previously attached two proof-of-concept gifs to the JIRA issue [1],
and after discussion on Slack it looked like taking the route of POC2
(adding toolbar actions along side existing page controls) was the short
term win, and that POC1 (UI components collapsing into a vertical bar of
some sort) should be investigated as it's own issue and potentially
implemented across the UI. This patch introduces two selectable items to
the toolbar which allow the user to expand either the table or graph to
fill the screen, and then fold away the other component. In a way to
prevent both components from being folded away (and viewing nothing) there
are controls to disable toolbar items when only 1 component is visible (one
is already folded), and enable them when both are visible (and one can be
folded away).

I've included a couple of screen shots that display the page with:
- both the table and graph visible [2]
- the table folded and the graph visible [3]
- the graph folded and the table visible [4]

and a couple of gifs to show
- the general flow of the controls [5]
- the folds persisting a reload of the jfr file [6]

I wrote a couple of uitests that verify some behaviour by interacting with
the toolbar items and verifying the weights of the SashForm; passing Travis
build available [7]

Thoughts?

Cheers,

Alex

[0] http://cr.openjdk.java.net/~aptmac/JMC-6368/webrev.00/
[1] https://bugs.openjdk.java.net/browse/JMC-6368
[2] https://imgur.com/XW99H5L
[3] https://imgur.com/d0d7Wln
[4] https://imgur.com/ibPgaWw
[5] https://imgur.com/QZzZZUN
[6] https://imgur.com/gUNfpTX
[7] https://travis-ci.org/aptmac/jmc-qa/builds/530418716

From carusso at redhat.com  Fri May 10 18:26:12 2019
From: carusso at redhat.com (Carmine Vincenzo Russo)
Date: Fri, 10 May 2019 20:26:12 +0200
Subject: RFC: JMC-5657: Code coverage with Jacoco
In-Reply-To: <B17AB67E-5845-47B1-9B3D-4415642A7957@oracle.com>
References: <CAA6KdKcBcyHmPU4hoky8D=qMV9yO8UWWgbKcKTuBv2S_CqRHRw@mail.gmail.com>
 <B17AB67E-5845-47B1-9B3D-4415642A7957@oracle.com>
Message-ID: <CAA6KdKdQRBkY_2dxVNO45=6oCzNbqs_GXEkmR5ZOA4ZxEtuvJA@mail.gmail.com>

Hi Guru,

thanks for your reply.

On Tue, May 7, 2019 at 6:38 PM Guru <guru.hb at oracle.com> wrote:

> Hi Carmine,
>
> Please check my comments inline.
>
> Thanks,
> Guru
> > On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo <carusso at redhat.com>
> wrote:
> >
> > Hello everyone,
> >
> > This patch adds Jacoco coverage over unit test in JMC.
> > The module covered in particular are: /core/tests and /application/tests.
> >
> > The patch addresses the issue JMC-5657[0], but as noted by Klara Ward[1],
> > instead of adding Jcov, it's better to add Jacoco.
> >
> > For the time being, each test group had a new module, report, where an
> > aggregate-report can be found.
> > You need to run 'mvn verify' in jmc root for /application/tests and in
> > /core for /core/tests to have the coverage report.
> Logically there are three build step
> 1. For releng
> 2. Core modules
> 3. Jmc product (i.e Application)
> Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for step
> 3).


Obviously all the 3 steps are needed, I also checked, the 'mvn verify' for
~/jmc/core is automatically done while building the core modules on step 2.
For jmc product you still need to run 'mvn verify -P uitests' separately
after building the project since you need the test to be executed.

Unless there is restriction on defining Jacoco in root of
> ~/jmc/core/pom.xml and ~/jmc/pom.xml.
>

I explain this at the end.


> > There are also some aspects that concern me, so: Is this what we are
> > looking for?
> > The report for /core[2] looks good and clean. The report for
> > /application/tests[3][4] has good results, although there are some 0%,
> and
> > that is ok, but also some N/A. Should we keep the modules in the report
> > with only N/A?
> >
> > There are also some changes in /application/uitests when reading the
> patch,
> > they are not yet applied but I would like to add them to the next patch.
> Please file a follow on new JBS and link with old one (relates to
> JMC-5667).
>

With 'next patch' I just meant the updated patch after the RFC, basically
what I have done now, just wanted to have your opinions before going
forward with the ~/uitests coverage. If a follow up issue is needed, I'll
ask Alex to open it.


> > This brings me to my second concern: should the tests and uitests in
> > /application have a unique report or should I keep them separate?
> Good to have Unique rather than separate.
>

In the new patch attached ~/jmc/application/tests and
~/jmc/applciation/uitests have a unique coverage in
~/jmc/application/coverage.


> > Lastly, do we want coverage with every verify build or do we want a maven
> > profile/flag to have the coverage only in some occasions?
> This could be based on how much time Jacoco Code coverage takes. If its
> negligible then good to have on every verify build or with a profile/flag.
>

In all my tests and attempts the module itself never took more than 10s,
while the build doesn't seem to be affected. So basically I don't think
it's a problem to have always the coverage in every build.


> > Overall, how does the patch look like? Do you think there are some more
> > modules that need to be covered? And do you have any suggestions on how
> to
> > improve what I've done?
> If possible, please update the patch to ~/jmc/core/pom.xml and
> ~/jmc/pom.xml.
>

As far as my knowledge goes, to have the report, we need a separate pom.xml
for the report, this because the report-aggregate[0] relies on <dependency>
and not on <module>, even the JaCoCo examples for this have their own
report module[1]. The best way, I think, is the current situation in which
we have ~/jmc/core/coverage/pom.xml and ~/jmc/application/coverage/pom.xml,
these generate and contains the coverage report, while in
~/jmc/core/pom.xml and ~/jmc/application/pom.xml we have the JaCoCo agent
that makes the coverage possible. If we try to move everything in
~/jmc/application/pom.xml and ~/jmc/core/pom.xml the reports will be
segregated in their own modules. Or if we try to move part of it in
~/jmc/pom.xml we stiil need to have both the agent configuration in
~/jmc/application/pom.xml and ~/jmc/core/pom.xml and the coverage as
separate modules.

All the changes and the new addition can be found here:
http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.01/

Regards,
Carmine

[0] https://www.jacoco.org/jacoco/trunk/doc/report-aggregate-mojo.html
[1]
https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate

> Thanks,
> > Carmine
> >
> > [0] https://bugs.openjdk.java.net/browse/JMC-5657
> > [1]
> http://mail.openjdk.java.net/pipermail/jmc-dev/2019-March/000882.html
> > [2] https://imgur.com/hPyyLsQ
> > [3] https://imgur.com/fqdzGvH
> > [4] https://imgur.com/ozqNcAB
> >
> > --
> > Carmine Vincenzo Russo
> > <5657-0.patch>
>
>

-- 
Carmine Vincenzo Russo

From erik.gahlin at oracle.com  Mon May 13 00:27:49 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 13 May 2019 02:27:49 +0200
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <CADPaBqk9QiKV7F=qMtLt8Zp7Ew35YU6937t93a2UF6YK7_rFZQ@mail.gmail.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
 <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>
 <5CCE0110.7070908@oracle.com>
 <2055f245-c722-c61b-2f85-406341cb6668@oracle.com>
 <CADPaBqk9QiKV7F=qMtLt8Zp7Ew35YU6937t93a2UF6YK7_rFZQ@mail.gmail.com>
Message-ID: <5CD8BA05.5050809@oracle.com>

Thanks for fixing!

Product code looks good, but I think tests could be improved.

There is no need to call dump in a final clause.

Events.fromRecording(...) will dump the file into the jtreg scratch 
directory ( "recording-1-pid-xxx.jfr")  by default. I think this is 
sufficient since there is only one recording per test.  If you think the 
name is cryptic, consider adding another method to Event.fromRecording 
that takes an additional parameter that becomes a suffix, i.e 
"recording-1-pid-xxx-test-heap-region-info.jfr"

try (Recording r = new recording()) {
   r.enable(EVENT_NAME);
   r.start();
   r.stop()
   List<RecordedEvent> events = Events.fromRecording(r);
   Events.hasEvents(events);
   for (RecordedEvent event : events) {
     Events.assertField(event, "index").notEqual(-1);
     Events.assertField(event, "used").atMost(1024*1024L);
     String state = Events.assertField(event, "state").getValue();
     GCHelper.assertShenandoahHeapRegionState(state));
}

The name of the field in metadata.xml is "state", but the tests looks 
for "type". That seems incorrect.

GCHelper:

public static assertShenandoahHeapRegionState(String state) {
  if (!shenandoahHeapRegionStates.contains(state)) {
     throw new AssertionError("Unknown state '"+ state +"', valid heap 
region states are " + shenandoahHeapRegionStates);
}

I assume you don't use Set.of("Empty Uncommitted" , ... , "Trash") 
because you want to backport to JDK 8.

Thanks
Erik

> Thanks everyone for their reviews. I've added tests similar to the 
> tests for the G1 events as well as addressed the changes that Erik 
> recommended.
>
> Here is the new webrev: 
> http://cr.openjdk.java.net/~kdobson/shenandoaheventswithtests/webrev/ 
> <http://cr.openjdk.java.net/%7Ekdobson/shenandoaheventswithtests/webrev/>
>
> Please let me know if there's anything else that should be addressed.
>
> Thanks,
>
> Ken Dobson
>
> On Mon, May 6, 2019 at 11:38 AM <mikhailo.seledtsov at oracle.com 
> <mailto:mikhailo.seledtsov at oracle.com>> wrote:
>
>
>
>     On 5/4/19 2:16 PM, Erik Gahlin wrote:
>     > On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com
>     <mailto:mikhailo.seledtsov at oracle.com> wrote:
>     >> Hi,
>     >>
>     >>   If possible and feasible, could you please implement tests
>     for new
>     >> events?
>     >>
>     >> Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps
>     >> create a "shenandoah" subfolder.
>     >>
>     >> If the events are too hard to test or not feasible, please add the
>     >> event names to
>     >> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, to
>     >> the hardToTestEvents set. Consider commenting why it is too
>     hard to
>     >> test.
>     >
>     > If events are are marked experimental, tests are ignored by
>     > TestLookForUntestedEvents. java, so we should not  add them to the
>     > hardToTestEvents set. That may help them pass under the radar
>     once the
>     > experimental attribute is removed.
>     Thank you. If the events are "experimental" this approach makes
>     sense.
>     Once the experimental status is removed, the
>     TestLookForUntestedEvents.java should be able to notice if the
>     event is
>     not covered by tests.
>     > That said, tests never hurts, even if they are experimental. I
>     think
>     > test/jdk/jdk/jfr/event/gc/detailed would be a good place
>     +1
>
>     Thank you,
>     Misha
>     >
>     > Erik
>     >
>     >>
>     >> Also, please make sure to run all jfr tests under
>     test/jdk/jdk/jfr/
>     >> prior to integration.
>     >>
>     >>
>     >> Best regards,
>     >>
>     >> Misha
>     >>
>     >>
>     >>
>     >> On 5/3/19 7:44 AM, Ken Dobson wrote:
>     >>> Hi all,
>     >>>
>     >>> Please review this patch that adds support for two new JFR events
>     >>> ShenandoahHeapRegionStateChange and
>     ShenandoahHeapRegionInformation.
>     >>>
>     >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
>     >>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
>     <http://cr.openjdk.java.net/%7Ekdobson/53476/webrev/>
>     >>>
>     >>> The Shenandoah team has also reviewed this patch and approved it
>     >>> from their
>     >>> end.
>     >>>
>     >>> Thanks,
>     >>>
>     >>> Ken Dobson
>     >>
>     >
>


From kdobson at redhat.com  Tue May 14 21:19:19 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Tue, 14 May 2019 17:19:19 -0400
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <5CD8BA05.5050809@oracle.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
 <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>
 <5CCE0110.7070908@oracle.com>
 <2055f245-c722-c61b-2f85-406341cb6668@oracle.com>
 <CADPaBqk9QiKV7F=qMtLt8Zp7Ew35YU6937t93a2UF6YK7_rFZQ@mail.gmail.com>
 <5CD8BA05.5050809@oracle.com>
Message-ID: <CADPaBqkLDy4YYFYP+dM9Wn9fDNvywy9PpV8vmZgZ8-hN8Svq5g@mail.gmail.com>

Thank you for the review again.

Yes, not sure regarding backporting plans but I imagine it will be in the
future so seemed best to avoid anything that cause issues such as Set.of().

I also think the naming of the jfr's is fine as it's stored in a folder
named after the test which was easily found now that I'm aware that the
jfrs are already dumped.

I believe I've addressed the rest of your recommended changes to the tests,
let me know if I've covered everything.

http://cr.openjdk.java.net/~kdobson/eventswithtests/webrev/

Thanks,

Ken Dobson

On Sun, May 12, 2019 at 8:28 PM Erik Gahlin <erik.gahlin at oracle.com> wrote:

> Thanks for fixing!
>
> Product code looks good, but I think tests could be improved.
>
> There is no need to call dump in a final clause.
>
> Events.fromRecording(...) will dump the file into the jtreg scratch
> directory ( "recording-1-pid-xxx.jfr")  by default. I think this is
> sufficient since there is only one recording per test.  If you think the
> name is cryptic, consider adding another method to Event.fromRecording that
> takes an additional parameter that becomes a suffix, i.e
> "recording-1-pid-xxx-test-heap-region-info.jfr"
>
> try (Recording r = new recording()) {
>   r.enable(EVENT_NAME);
>   r.start();
>   r.stop()
>   List<RecordedEvent> events = Events.fromRecording(r);
>   Events.hasEvents(events);
>   for (RecordedEvent event : events) {
>     Events.assertField(event, "index").notEqual(-1);
>     Events.assertField(event, "used").atMost(1024*1024L);
>     String state = Events.assertField(event, "state").getValue();
>     GCHelper.assertShenandoahHeapRegionState(state));
> }
>
> The name of the field in metadata.xml is "state", but the tests looks for
> "type". That seems incorrect.
>
> GCHelper:
>
> public static assertShenandoahHeapRegionState(String state) {
>  if (!shenandoahHeapRegionStates.contains(state)) {
>     throw new AssertionError("Unknown state '"+ state +"', valid heap
> region states are " + shenandoahHeapRegionStates);
> }
>
> I assume you don't use Set.of("Empty Uncommitted" , ... , "Trash")
> because you want to backport to JDK 8.
>
> Thanks
> Erik
>
> Thanks everyone for their reviews. I've added tests similar to the tests
> for the G1 events as well as addressed the changes that Erik recommended.
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~kdobson/shenandoaheventswithtests/webrev/
>
> Please let me know if there's anything else that should be addressed.
>
> Thanks,
>
> Ken Dobson
>
> On Mon, May 6, 2019 at 11:38 AM <mikhailo.seledtsov at oracle.com> wrote:
>
>>
>>
>> On 5/4/19 2:16 PM, Erik Gahlin wrote:
>> > On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com wrote:
>> >> Hi,
>> >>
>> >>   If possible and feasible, could you please implement tests for new
>> >> events?
>> >>
>> >> Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps
>> >> create a "shenandoah" subfolder.
>> >>
>> >> If the events are too hard to test or not feasible, please add the
>> >> event names to
>> >> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, to
>> >> the hardToTestEvents set. Consider commenting why it is too hard to
>> >> test.
>> >
>> > If events are are marked experimental, tests are ignored by
>> > TestLookForUntestedEvents. java, so we should not  add them to the
>> > hardToTestEvents set. That may help them pass under the radar once the
>> > experimental attribute is removed.
>> Thank you. If the events are "experimental" this approach makes sense.
>> Once the experimental status is removed, the
>> TestLookForUntestedEvents.java should be able to notice if the event is
>> not covered by tests.
>> > That said, tests never hurts, even if they are experimental. I think
>> > test/jdk/jdk/jfr/event/gc/detailed would be a good place
>> +1
>>
>> Thank you,
>> Misha
>> >
>> > Erik
>> >
>> >>
>> >> Also, please make sure to run all jfr tests under test/jdk/jdk/jfr/
>> >> prior to integration.
>> >>
>> >>
>> >> Best regards,
>> >>
>> >> Misha
>> >>
>> >>
>> >>
>> >> On 5/3/19 7:44 AM, Ken Dobson wrote:
>> >>> Hi all,
>> >>>
>> >>> Please review this patch that adds support for two new JFR events
>> >>> ShenandoahHeapRegionStateChange and ShenandoahHeapRegionInformation.
>> >>>
>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
>> >>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
>> >>>
>> >>> The Shenandoah team has also reviewed this patch and approved it
>> >>> from their
>> >>> end.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Ken Dobson
>> >>
>> >
>>
>>
>

From marcus at hirt.se  Tue May 14 21:28:46 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 14 May 2019 23:28:46 +0200
Subject: Review request for JMC-6468: Rule for detecting unsupported JDK
 version
Message-ID: <166a01d50a9c$0327e5e0$0977b1a0$@hirt.se>

Hi all,

Please review this enhancement for warning when an unsupported JDK version 
is being used (such as when an old non-LTS release is in use, or a very 
old no longer supported version, or an early access release).

There are various ways this could be done, but the rule will currently 
be fine with actively supported releases (JDK 8, JDK 11), or the latest 
non-LTS release (currently JDK 12). It will be a little bit grumpy about 
JDK 7 (still supported by some vendors), and decidedly unhappy about 
earlier releases and non-LTS releases not being the latest.

Note that given the update cycle of this rule, and the multitude of vendors
releasing and supporting OpenJDK based JVMs, this rule does not attempt to 
discover if an old interim/update of a supported release is in use. It is 
only complaining about the feature release in use.

See also: http://openjdk.java.net/jeps/322

Jira:   https://bugs.openjdk.java.net/browse/JMC-6468
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6468/webrev.2/

Kind regards,
Marcus


From erik.gahlin at oracle.com  Tue May 14 21:37:44 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 14 May 2019 23:37:44 +0200
Subject: RFR 8221507: Implement JFR Events for Shenandoah
In-Reply-To: <CADPaBqkLDy4YYFYP+dM9Wn9fDNvywy9PpV8vmZgZ8-hN8Svq5g@mail.gmail.com>
References: <CADPaBqmoQCk_ZxiA6eknK2byESD2thMJd2nbtaH8t5OfzdAPkw@mail.gmail.com>
 <db7dd975-13c5-894c-104e-c1f735b651a2@oracle.com>
 <5CCE0110.7070908@oracle.com>
 <2055f245-c722-c61b-2f85-406341cb6668@oracle.com>
 <CADPaBqk9QiKV7F=qMtLt8Zp7Ew35YU6937t93a2UF6YK7_rFZQ@mail.gmail.com>
 <5CD8BA05.5050809@oracle.com>
 <CADPaBqkLDy4YYFYP+dM9Wn9fDNvywy9PpV8vmZgZ8-hN8Svq5g@mail.gmail.com>
Message-ID: <5CDB3528.1050200@oracle.com>

Looks good.

In the tests, you could avoid the null check on the recording and just 
use try-with-resources.  It will close the recording automatically when 
it runs out of scope. No need to post updated webrev.

Thanks
Erik

> Thank you for the review again.
>
> Yes, not sure regarding backporting plans but I imagine it will be in 
> the future so seemed best to avoid anything that cause issues such as 
> Set.of().
>
> I also think the naming of the jfr's is fine as it's stored in a 
> folder named after the test which was easily found now that I'm aware 
> that the jfrs are already dumped.
>
> I believe I've addressed the rest of your recommended changes to the 
> tests, let me know if I've covered everything.
>
> http://cr.openjdk.java.net/~kdobson/eventswithtests/webrev/ 
> <http://cr.openjdk.java.net/%7Ekdobson/eventswithtests/webrev/>
>
> Thanks,
>
> Ken Dobson
>
> On Sun, May 12, 2019 at 8:28 PM Erik Gahlin <erik.gahlin at oracle.com 
> <mailto:erik.gahlin at oracle.com>> wrote:
>
>     Thanks for fixing!
>
>     Product code looks good, but I think tests could be improved.
>
>     There is no need to call dump in a final clause.
>
>     Events.fromRecording(...) will dump the file into the jtreg
>     scratch directory ( "recording-1-pid-xxx.jfr")  by default. I
>     think this is sufficient since there is only one recording per
>     test.  If you think the name is cryptic, consider adding another
>     method to Event.fromRecording that takes an additional parameter
>     that becomes a suffix, i.e
>     "recording-1-pid-xxx-test-heap-region-info.jfr"
>
>     try (Recording r = new recording()) {
>       r.enable(EVENT_NAME);
>       r.start();
>       r.stop()
>       List<RecordedEvent> events = Events.fromRecording(r);
>       Events.hasEvents(events);
>       for (RecordedEvent event : events) {
>         Events.assertField(event, "index").notEqual(-1);
>         Events.assertField(event, "used").atMost(1024*1024L);
>         String state = Events.assertField(event, "state").getValue();
>         GCHelper.assertShenandoahHeapRegionState(state));
>     }
>
>     The name of the field in metadata.xml is "state", but the tests
>     looks for "type". That seems incorrect.
>
>     GCHelper:
>
>     public static assertShenandoahHeapRegionState(String state) {
>      if (!shenandoahHeapRegionStates.contains(state)) {
>         throw new AssertionError("Unknown state '"+ state +"', valid
>     heap region states are " + shenandoahHeapRegionStates);
>     }
>
>     I assume you don't use Set.of("Empty Uncommitted" , ... , "Trash")
>     because you want to backport to JDK 8.
>
>     Thanks
>     Erik
>
>>     Thanks everyone for their reviews. I've added tests similar to
>>     the tests for the G1 events as well as addressed the changes that
>>     Erik recommended.
>>
>>     Here is the new webrev:
>>     http://cr.openjdk.java.net/~kdobson/shenandoaheventswithtests/webrev/
>>     <http://cr.openjdk.java.net/%7Ekdobson/shenandoaheventswithtests/webrev/>
>>
>>     Please let me know if there's anything else that should be addressed.
>>
>>     Thanks,
>>
>>     Ken Dobson
>>
>>     On Mon, May 6, 2019 at 11:38 AM <mikhailo.seledtsov at oracle.com
>>     <mailto:mikhailo.seledtsov at oracle.com>> wrote:
>>
>>
>>
>>         On 5/4/19 2:16 PM, Erik Gahlin wrote:
>>         > On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com
>>         <mailto:mikhailo.seledtsov at oracle.com> wrote:
>>         >> Hi,
>>         >>
>>         >>   If possible and feasible, could you please implement
>>         tests for new
>>         >> events?
>>         >>
>>         >> Please place the tests under test/jdk/jdk/jfr/event/gc/.
>>         Perhaps
>>         >> create a "shenandoah" subfolder.
>>         >>
>>         >> If the events are too hard to test or not feasible, please
>>         add the
>>         >> event names to
>>         >>
>>         test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java,
>>         to
>>         >> the hardToTestEvents set. Consider commenting why it is
>>         too hard to
>>         >> test.
>>         >
>>         > If events are are marked experimental, tests are ignored by
>>         > TestLookForUntestedEvents. java, so we should not  add them
>>         to the
>>         > hardToTestEvents set. That may help them pass under the
>>         radar once the
>>         > experimental attribute is removed.
>>         Thank you. If the events are "experimental" this approach
>>         makes sense.
>>         Once the experimental status is removed, the
>>         TestLookForUntestedEvents.java should be able to notice if
>>         the event is
>>         not covered by tests.
>>         > That said, tests never hurts, even if they are
>>         experimental. I think
>>         > test/jdk/jdk/jfr/event/gc/detailed would be a good place
>>         +1
>>
>>         Thank you,
>>         Misha
>>         >
>>         > Erik
>>         >
>>         >>
>>         >> Also, please make sure to run all jfr tests under
>>         test/jdk/jdk/jfr/
>>         >> prior to integration.
>>         >>
>>         >>
>>         >> Best regards,
>>         >>
>>         >> Misha
>>         >>
>>         >>
>>         >>
>>         >> On 5/3/19 7:44 AM, Ken Dobson wrote:
>>         >>> Hi all,
>>         >>>
>>         >>> Please review this patch that adds support for two new
>>         JFR events
>>         >>> ShenandoahHeapRegionStateChange and
>>         ShenandoahHeapRegionInformation.
>>         >>>
>>         >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507
>>         >>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/
>>         <http://cr.openjdk.java.net/%7Ekdobson/53476/webrev/>
>>         >>>
>>         >>> The Shenandoah team has also reviewed this patch and
>>         approved it
>>         >>> from their
>>         >>> end.
>>         >>>
>>         >>> Thanks,
>>         >>>
>>         >>> Ken Dobson
>>         >>
>>         >
>>
>


From guru.hb at oracle.com  Wed May 15 16:41:14 2019
From: guru.hb at oracle.com (Guru)
Date: Wed, 15 May 2019 22:11:14 +0530
Subject: Review request for JMC-6468: Rule for detecting unsupported JDK
 version
In-Reply-To: <166a01d50a9c$0327e5e0$0977b1a0$@hirt.se>
References: <166a01d50a9c$0327e5e0$0977b1a0$@hirt.se>
Message-ID: <DAA1DF70-BA18-407A-BB0E-60C3F7972CD7@oracle.com>

+1 for http://cr.openjdk.java.net/~hirt/JMC-6468/webrev.3/ <http://cr.openjdk.java.net/~hirt/JMC-6468/webrev.3/> 

Tested with OpenJDK {9.0.1, 10.0.1, 11.0.0} and also with JDK 8.

Thanks,
Guru
> On 15-May-2019, at 2:58 AM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi all,
> 
> Please review this enhancement for warning when an unsupported JDK version 
> is being used (such as when an old non-LTS release is in use, or a very 
> old no longer supported version, or an early access release).
> 
> There are various ways this could be done, but the rule will currently 
> be fine with actively supported releases (JDK 8, JDK 11), or the latest 
> non-LTS release (currently JDK 12). It will be a little bit grumpy about 
> JDK 7 (still supported by some vendors), and decidedly unhappy about 
> earlier releases and non-LTS releases not being the latest.
> 
> Note that given the update cycle of this rule, and the multitude of vendors
> releasing and supporting OpenJDK based JVMs, this rule does not attempt to 
> discover if an old interim/update of a supported release is in use. It is 
> only complaining about the feature release in use.
> 
> See also: http://openjdk.java.net/jeps/322
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6468
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6468/webrev.2/
> 
> Kind regards,
> Marcus
> 


From marcus at hirt.se  Thu May 16 10:33:36 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Thu, 16 May 2019 10:33:36 +0000
Subject: hg: jmc/jmc: JMC-6468: Rule for detecting unsupported JDK version
Message-ID: <201905161033.x4GAXaOH006100@aojmv0008.oracle.com>

Changeset: 183487546804
Author:    hirt <marcus.hirt at datadoghq.com>
Date:      2019-05-16 12:33 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/183487546804

JMC-6468: Rule for detecting unsupported JDK version
Reviewed-by: ghb

! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/version/JavaVersionSupport.java
+ core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/UnsupportedJdkVersionRule.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/Messages.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/META-INF/services/org.openjdk.jmc.flightrecorder.rules.IRule
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties
- core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/baseline/Generated_JfrRuleBaseline.xml
! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml


From carusso at redhat.com  Fri May 17 13:26:16 2019
From: carusso at redhat.com (Carmine Vincenzo Russo)
Date: Fri, 17 May 2019 15:26:16 +0200
Subject: JMC - 6173: feedback
Message-ID: <CAA6KdKcL+6yGDBU8F8of-U+nUKM6LT46s2Mwvc=K7HZLJma-xA@mail.gmail.com>

Hi,

I was looking at the issue JMC-6173[0].
In the comments section, Erik talks of file changes between JMC 4 and JMC
5.5 (OpenFile in rcp.application plugin), is it possible to see those
changes anywhere? Just to get a better sense of what has changed and how
this issue can be resolved.
If you have any feedback or suggestion I would much appreciate it.

Thanks,
Carmine

[0] https://bugs.openjdk.java.net/browse/JMC-6173

-- 
Carmine Vincenzo Russo

From jkang at redhat.com  Fri May 17 14:03:29 2019
From: jkang at redhat.com (Jie Kang)
Date: Fri, 17 May 2019 10:03:29 -0400
Subject: JMC - 6173: feedback
In-Reply-To: <CAA6KdKcL+6yGDBU8F8of-U+nUKM6LT46s2Mwvc=K7HZLJma-xA@mail.gmail.com>
References: <CAA6KdKcL+6yGDBU8F8of-U+nUKM6LT46s2Mwvc=K7HZLJma-xA@mail.gmail.com>
Message-ID: <CAEBeOcpvY7M4FWUVXSmEH10UneGTRrtN+EUQN1Q4e8bYg1+R1Q@mail.gmail.com>

On Fri, May 17, 2019 at 9:27 AM Carmine Vincenzo Russo
<carusso at redhat.com> wrote:
>
> Hi,
>
> I was looking at the issue JMC-6173[0].
> In the comments section, Erik talks of file changes between JMC 4 and JMC
> 5.5 (OpenFile in rcp.application plugin), is it possible to see those
> changes anywhere? Just to get a better sense of what has changed and how
> this issue can be resolved.
> If you have any feedback or suggestion I would much appreciate it.

I think those are both proprietary versions so it's unlikely the code
and commit history will be available. Can JMC-6173 be reproduced with
current upstream? I remember reading something likes this before but
it wasn't an issue anymore.


Regards,

>
> Thanks,
> Carmine
>
> [0] https://bugs.openjdk.java.net/browse/JMC-6173
>
> --
> Carmine Vincenzo Russo

From marcus at hirt.se  Fri May 17 14:22:02 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 17 May 2019 16:22:02 +0200
Subject: JMC - 6173: feedback
In-Reply-To: <CAA6KdKcL+6yGDBU8F8of-U+nUKM6LT46s2Mwvc=K7HZLJma-xA@mail.gmail.com>
References: <CAA6KdKcL+6yGDBU8F8of-U+nUKM6LT46s2Mwvc=K7HZLJma-xA@mail.gmail.com>
Message-ID: <9B380292-B271-4321-839D-D301D0E5555F@hirt.se>

Hi Carmine,

JMC 5.5 was released before the open sourcing of JMC, so that code sits in a repo 
at Oracle. That said, I think in this case it would be better to look at the existing code
anyways and try to make it work for local paths and the current working directory.

Kind regards,
Marcus


> On May 17, 2019, at 3:26 PM, Carmine Vincenzo Russo <carusso at redhat.com> wrote:
> 
> Hi,
> 
> I was looking at the issue JMC-6173[0].
> In the comments section, Erik talks of file changes between JMC 4 and JMC
> 5.5 (OpenFile in rcp.application plugin), is it possible to see those
> changes anywhere? Just to get a better sense of what has changed and how
> this issue can be resolved.
> If you have any feedback or suggestion I would much appreciate it.
> 
> Thanks,
> Carmine
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-6173
> 
> -- 
> Carmine Vincenzo Russo


From marcus at hirt.se  Sat May 18 15:11:42 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Sat, 18 May 2019 17:11:42 +0200
Subject: Review request for JMC-6470: Use the JVM on the path by default for
 the RCP version of JMC on all platforms
Message-ID: <009101d50d8c$00618030$01248090$@hirt.se>

Hi all,

Please review this fix to use the JVM on the path by default for
the RCP version of JMC on all platforms.

Jira:   https://bugs.openjdk.java.net/browse/JMC-6470
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6470/webrev.0/

Kind regards,
Marcus


From guru.hb at oracle.com  Sat May 18 16:23:47 2019
From: guru.hb at oracle.com (Guru)
Date: Sat, 18 May 2019 21:53:47 +0530
Subject: Review request for JMC-6470: Use the JVM on the path by default
 for the RCP version of JMC on all platforms
In-Reply-To: <009101d50d8c$00618030$01248090$@hirt.se>
References: <009101d50d8c$00618030$01248090$@hirt.se>
Message-ID: <AFDFD22E-ACC6-4E4F-8790-178712C834D0@oracle.com>

+1 Looks good to me. 
?-vm ~/PathToJDK/bin not exist in ?jmc.ini? in all three platform build.

Thanks
Guru
> On 18-May-2019, at 8:41 PM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi all,
> 
> Please review this fix to use the JVM on the path by default for
> the RCP version of JMC on all platforms.
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6470
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6470/webrev.0/
> 
> Kind regards,
> Marcus
> 


From marcus at hirt.se  Mon May 20 10:36:05 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Mon, 20 May 2019 10:36:05 +0000
Subject: hg: jmc/jmc: JMC-6470: Use the JVM on the path by default for the RCP
 version of JMC on all platforms
Message-ID: <201905201036.x4KAa53g000722@aojmv0008.oracle.com>

Changeset: 270ac3859d2f
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-20 12:35 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/270ac3859d2f

JMC-6470: Use the JVM on the path by default for the RCP version of JMC on all platforms
Reviewed-by: ghb

! README.md
! application/org.openjdk.jmc.rcp.product/jmc.product


From marcus at hirt.se  Mon May 20 12:06:31 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Mon, 20 May 2019 14:06:31 +0200
Subject: Review request for JMC-6473: Upgrading to OWASP Encoder 1.2.2.
Message-ID: <000d01d50f04$765b2bf0$631183d0$@hirt.se>

Hi all,

Please review this update to OWASP Encoder 1.2.2.

Jira:   https://bugs.openjdk.java.net/browse/JMC-6473
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6473/webrev.0/

Kind regards,
Marcus


From erik.gahlin at oracle.com  Mon May 20 12:10:01 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 20 May 2019 14:10:01 +0200
Subject: Review request for JMC-6473: Upgrading to OWASP Encoder 1.2.2.
In-Reply-To: <000d01d50f04$765b2bf0$631183d0$@hirt.se>
References: <000d01d50f04$765b2bf0$631183d0$@hirt.se>
Message-ID: <5CE29919.8020708@oracle.com>

Looks reasonable

Erik

> Hi all,
>
> Please review this update to OWASP Encoder 1.2.2.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6473
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6473/webrev.0/
>
> Kind regards,
> Marcus
>


From erik.gahlin at oracle.com  Mon May 20 17:46:57 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 20 May 2019 19:46:57 +0200
Subject: RFR: 8216283: Allow shorter method sampling interval than 10 ms
Message-ID: <5CE2E811.4060904@oracle.com>

Hi,

Could I please have a review of a fix that allows method sampling to 
happen at a higher rate. The current limit of 10 ms exists because 
method sampling used to occur in the VM period task. Method sampling now 
happens in a separate thread. This was changed in JDK 9.

The minimum accepted interval is lowered from 10 ms to 1 ms for both 
native and Java samples, but configuration files have been changed so 
native sampling interval can not be set lower than 20 ms using JMC 
Recording Wizard controls. Manual edit of the event setting allows 1 ms.

The reason for this is to avoid excessive number native sample events. 
Purpose of native sampling is to detect "stuck threads". That is, 
threads that have called into native, but not returned. Most of the 
native samples will however be threads waiting in native, for example on 
a socket. Going below 20 ms adds little value, since a stuck thread is 
typically in native for a longer period of time.

Method sampling in Java on the other hand can be set to 1 ms in a new 
"mode" called "Extreme". To avoid confusion, I didn't want to use 
"Maximum" since it means 10 ms in earlier releases.

Webrev:
http://cr.openjdk.java.net/~egahlin/8216283/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8216283

Testing:
Tried to set the interval in the JMC Recording Wizard and verified that 
the correct interval was set in JVM using:
$ jcmd <pid> JFR.check verbose=true

Thanks
Erik

From guru.hb at oracle.com  Tue May 21 06:42:09 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 21 May 2019 12:12:09 +0530
Subject: Review request for JMC-6473: Upgrading to OWASP Encoder 1.2.2.
In-Reply-To: <5CE29919.8020708@oracle.com>
References: <000d01d50f04$765b2bf0$631183d0$@hirt.se>
 <5CE29919.8020708@oracle.com>
Message-ID: <2A587565-6C33-49BD-8828-AD4B65C83F67@oracle.com>

+1, Looks good to me. 

Tested on Mac OS X. 
> On 20-May-2019, at 5:40 PM, Erik Gahlin <erik.gahlin at oracle.com> wrote:
> 
> Looks reasonable
> 
> Erik
> 
>> Hi all,
>> 
>> Please review this update to OWASP Encoder 1.2.2.
>> 
>> Jira:   https://bugs.openjdk.java.net/browse/JMC-6473
>> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6473/webrev.0/
>> 
>> Kind regards,
>> Marcus
>> 
> 


From marcus at hirt.se  Tue May 21 11:00:56 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Tue, 21 May 2019 11:00:56 +0000
Subject: hg: jmc/jmc: JMC-6473: Upgrading to OWASP encoder 1.2.2
Message-ID: <201905211100.x4LB0vc4004084@aojmv0008.oracle.com>

Changeset: 12cd4d1b437a
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-21 13:00 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/12cd4d1b437a

JMC-6473: Upgrading to OWASP encoder 1.2.2
Reviewed-by: egahlin,ghb

! core/org.openjdk.jmc.flightrecorder.rules/pom.xml
! license/THIRDPARTYREADME.txt
! releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target
! releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target
! releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target
! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target
! releng/third-party/pom.xml


From marcus at hirt.se  Tue May 21 11:25:47 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 21 May 2019 13:25:47 +0200
Subject: Review request for JMC-6472: Upgrading to Twitter4J 4.0.7.
Message-ID: <011801d50fc7$f0217250$d06456f0$@hirt.se>

Hi all,

Please review this upgrade to Twitter4J 4.0.7.

Jira:   https://bugs.openjdk.java.net/browse/JMC-6472
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6472/webrev.0/

Kind regards,
Marcus



From guru.hb at oracle.com  Tue May 21 11:52:48 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 21 May 2019 17:22:48 +0530
Subject: Review request for JMC-6472: Upgrading to Twitter4J 4.0.7.
In-Reply-To: <011801d50fc7$f0217250$d06456f0$@hirt.se>
References: <011801d50fc7$f0217250$d06456f0$@hirt.se>
Message-ID: <2EDE52A4-C768-4A6D-B099-178625810814@oracle.com>

+1, 
Tested on OS X.

Thanks,
Guru
> On 21-May-2019, at 4:55 PM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi all,
> 
> Please review this upgrade to Twitter4J 4.0.7.
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6472
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6472/webrev.0/
> 
> Kind regards,
> Marcus
> 
> 


From marcus at hirt.se  Tue May 21 12:16:07 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Tue, 21 May 2019 12:16:07 +0000
Subject: hg: jmc/jmc: JMC-6472: Upgrading to Twitter4J 4.0.7
Message-ID: <201905211216.x4LCG7WE025779@aojmv0008.oracle.com>

Changeset: ac9de042360a
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-21 14:15 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/ac9de042360a

JMC-6472: Upgrading to Twitter4J 4.0.7
Reviewed-by: ghb

! license/THIRDPARTYREADME.txt
! releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target
! releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target
! releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target
! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target
! releng/third-party/pom.xml


From guru.hb at oracle.com  Tue May 21 14:36:42 2019
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Tue, 21 May 2019 14:36:42 +0000
Subject: hg: jmc/jmc7: JMC-6470: Use the JVM on the path by default for the
 RCP version of JMC on all platforms
Message-ID: <201905211436.x4LEag3B028824@aojmv0008.oracle.com>

Changeset: b47d0ccb4559
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-20 12:35 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/b47d0ccb4559

JMC-6470: Use the JVM on the path by default for the RCP version of JMC on all platforms
Reviewed-by: ghb

! README.md
! application/org.openjdk.jmc.rcp.product/jmc.product


From guru.hb at oracle.com  Tue May 21 14:42:22 2019
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Tue, 21 May 2019 14:42:22 +0000
Subject: hg: jmc/jmc7: 2 new changesets
Message-ID: <201905211442.x4LEgMY4005122@aojmv0008.oracle.com>

Changeset: 53480fed8bd2
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-21 13:00 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/53480fed8bd2

JMC-6473: Upgrading to OWASP encoder 1.2.2
Reviewed-by: egahlin,ghb

! core/org.openjdk.jmc.flightrecorder.rules/pom.xml
! license/THIRDPARTYREADME.txt
! releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target
+ releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target
+ releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target
! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target
! releng/third-party/pom.xml

Changeset: 56026637f9c5
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-21 14:15 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/56026637f9c5

JMC-6472: Upgrading to Twitter4J 4.0.7
Reviewed-by: ghb

! license/THIRDPARTYREADME.txt
! releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target
! releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target
! releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target
! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target
! releng/third-party/pom.xml


From marcus at hirt.se  Tue May 21 21:08:36 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 21 May 2019 23:08:36 +0200
Subject: Review request for JMC-6480: Fixing the GC Locker rule.
Message-ID: <02a501d51019$5ae4d270$10ae7750$@hirt.se>

Hi all,

Please review this fix for the GC Locker rule.

Jira:   https://bugs.openjdk.java.net/browse/JMC-6480
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6480/webrev.0/

Kind regards,
Marcus


From guru.hb at oracle.com  Wed May 22 05:06:35 2019
From: guru.hb at oracle.com (Guru)
Date: Wed, 22 May 2019 10:36:35 +0530
Subject: [7.0.0 only] Review request : JMC-6482: jmc7 fails to start jetty
 local server
Message-ID: <DED1F68E-F59F-433A-A6D9-E53AE3F6C073@oracle.com>

Hi,

Please review the fix for 
JBS: https://bugs.openjdk.java.net/browse/JMC-6482 <https://bugs.openjdk.java.net/browse/JMC-6482>
webrev : http://cr.openjdk.java.net/~ghb/JMC-6482/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6482/webrev.0/>

Root cause : While back porting from jmc (dev) branch, ?httpConnector? tag was placed in a ?webapp' tag (nested).

Note: This fix will only be committed to  "http://hg.openjdk.java.net/jmc/jmc7 <http://hg.openjdk.java.net/jmc/jmc7>? branch. 

Thanks,
Guru

From christoph.langer at sap.com  Wed May 22 06:56:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 22 May 2019 06:56:39 +0000
Subject: [7.0.0 only] Review request : JMC-6482: jmc7 fails to start jetty
 local server
In-Reply-To: <DED1F68E-F59F-433A-A6D9-E53AE3F6C073@oracle.com>
References: <DED1F68E-F59F-433A-A6D9-E53AE3F6C073@oracle.com>
Message-ID: <DB7PR02MB5193FE2886AF67E3D09F9C138A000@DB7PR02MB5193.eurprd02.prod.outlook.com>

Hi Guru,

looks good and trivial. Not a JMC reviewer though...

Best regards
Christoph

> -----Original Message-----
> From: jmc-dev <jmc-dev-bounces at openjdk.java.net> On Behalf Of Guru
> Sent: Mittwoch, 22. Mai 2019 07:07
> To: jmc-dev at openjdk.java.net
> Subject: [7.0.0 only] Review request : JMC-6482: jmc7 fails to start jetty local
> server
> 
> Hi,
> 
> Please review the fix for
> JBS: https://bugs.openjdk.java.net/browse/JMC-6482
> <https://bugs.openjdk.java.net/browse/JMC-6482>
> webrev : http://cr.openjdk.java.net/~ghb/JMC-6482/webrev.0/
> <http://cr.openjdk.java.net/~ghb/JMC-6482/webrev.0/>
> 
> Root cause : While back porting from jmc (dev) branch, ?httpConnector? tag
> was placed in a ?webapp' tag (nested).
> 
> Note: This fix will only be committed to
> "http://hg.openjdk.java.net/jmc/jmc7
> <http://hg.openjdk.java.net/jmc/jmc7>? branch.
> 
> Thanks,
> Guru

From jkang at redhat.com  Wed May 22 13:00:30 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 22 May 2019 09:00:30 -0400
Subject: Review request for JMC-6480: Fixing the GC Locker rule.
In-Reply-To: <02a501d51019$5ae4d270$10ae7750$@hirt.se>
References: <02a501d51019$5ae4d270$10ae7750$@hirt.se>
Message-ID: <CAEBeOco_BXMhwHEG_2MGs1TdQVdrcsQfSVMxBmiLGxG_C7C0Sw@mail.gmail.com>

Hi Marcus,

Looks mostly good to me though I think the tests will need to be
adjusted for the new text:
[ERROR]   TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159

As well, I would like to suggest rephrasing of a portion of
GcLockerRuleFactory_TEXT_INFO_LONG

s/will need for the object/will need the object/


Regards,


On Tue, May 21, 2019 at 5:09 PM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi all,
>
> Please review this fix for the GC Locker rule.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6480
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6480/webrev.0/
>
> Kind regards,
> Marcus
>

From marcus.hirt at datadoghq.com  Wed May 22 14:00:49 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Wed, 22 May 2019 16:00:49 +0200
Subject: [7.0.0 only] Review request : JMC-6482: jmc7 fails to start jetty
 local server
In-Reply-To: <DED1F68E-F59F-433A-A6D9-E53AE3F6C073@oracle.com>
References: <DED1F68E-F59F-433A-A6D9-E53AE3F6C073@oracle.com>
Message-ID: <CAOpWGx3xjb2GBY2E0hWy0eF6Kp8Mxca8bL=eteOmykDMMsFWDQ@mail.gmail.com>

Looks good Guru!

/M

On Wed, May 22, 2019 at 7:07 AM Guru <guru.hb at oracle.com> wrote:

> Hi,
>
> Please review the fix for
> JBS: https://bugs.openjdk.java.net/browse/JMC-6482 <
> https://bugs.openjdk.java.net/browse/JMC-6482>
> webrev : http://cr.openjdk.java.net/~ghb/JMC-6482/webrev.0/ <
> http://cr.openjdk.java.net/~ghb/JMC-6482/webrev.0/>
>
> Root cause : While back porting from jmc (dev) branch, ?httpConnector? tag
> was placed in a ?webapp' tag (nested).
>
> Note: This fix will only be committed to  "
> http://hg.openjdk.java.net/jmc/jmc7 <http://hg.openjdk.java.net/jmc/jmc7>?
> branch.
>
> Thanks,
> Guru

From almacdon at redhat.com  Wed May 22 14:43:40 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Wed, 22 May 2019 10:43:40 -0400
Subject: RFC: JMC-5657: Code coverage with Jacoco
In-Reply-To: <CAA6KdKdQRBkY_2dxVNO45=6oCzNbqs_GXEkmR5ZOA4ZxEtuvJA@mail.gmail.com>
References: <CAA6KdKcBcyHmPU4hoky8D=qMV9yO8UWWgbKcKTuBv2S_CqRHRw@mail.gmail.com>
 <B17AB67E-5845-47B1-9B3D-4415642A7957@oracle.com>
 <CAA6KdKdQRBkY_2dxVNO45=6oCzNbqs_GXEkmR5ZOA4ZxEtuvJA@mail.gmail.com>
Message-ID: <CAOsn=kr2MBUobCMy4jVJA+Lger4kNec3R=wN_dufRHxq-nShuQ@mail.gmail.com>

Hi Carmine,

On Fri, May 10, 2019 at 2:27 PM Carmine Vincenzo Russo <carusso at redhat.com>
wrote:

> Hi Guru,
>
> thanks for your reply.
>
> On Tue, May 7, 2019 at 6:38 PM Guru <guru.hb at oracle.com> wrote:
>
> > Hi Carmine,
> >
> > Please check my comments inline.
> >
> > Thanks,
> > Guru
> > > On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo <carusso at redhat.com
> >
> > wrote:
> > >
> > > Hello everyone,
> > >
> > > This patch adds Jacoco coverage over unit test in JMC.
> > > The module covered in particular are: /core/tests and
> /application/tests.
> > >
> > > The patch addresses the issue JMC-5657[0], but as noted by Klara
> Ward[1],
> > > instead of adding Jcov, it's better to add Jacoco.
> > >
> > > For the time being, each test group had a new module, report, where an
> > > aggregate-report can be found.
> > > You need to run 'mvn verify' in jmc root for /application/tests and in
> > > /core for /core/tests to have the coverage report.
> > Logically there are three build step
> > 1. For releng
> > 2. Core modules
> > 3. Jmc product (i.e Application)
> > Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for
> step
> > 3).
>
>
> Obviously all the 3 steps are needed, I also checked, the 'mvn verify' for
> ~/jmc/core is automatically done while building the core modules on step 2.
> For jmc product you still need to run 'mvn verify -P uitests' separately
> after building the project since you need the test to be executed.
>
> Unless there is restriction on defining Jacoco in root of
> > ~/jmc/core/pom.xml and ~/jmc/pom.xml.
> >
>
> I explain this at the end.
>
>
> > > There are also some aspects that concern me, so: Is this what we are
> > > looking for?
> > > The report for /core[2] looks good and clean. The report for
> > > /application/tests[3][4] has good results, although there are some 0%,
> > and
> > > that is ok, but also some N/A. Should we keep the modules in the report
> > > with only N/A?
> > >
> > > There are also some changes in /application/uitests when reading the
> > patch,
> > > they are not yet applied but I would like to add them to the next
> patch.
> > Please file a follow on new JBS and link with old one (relates to
> > JMC-5667).
> >
>
> With 'next patch' I just meant the updated patch after the RFC, basically
> what I have done now, just wanted to have your opinions before going
> forward with the ~/uitests coverage. If a follow up issue is needed, I'll
> ask Alex to open it.
>
>
> > > This brings me to my second concern: should the tests and uitests in
> > > /application have a unique report or should I keep them separate?
> > Good to have Unique rather than separate.
> >
>
> In the new patch attached ~/jmc/application/tests and
> ~/jmc/applciation/uitests have a unique coverage in
> ~/jmc/application/coverage.
>
>
> > > Lastly, do we want coverage with every verify build or do we want a
> maven
> > > profile/flag to have the coverage only in some occasions?
> > This could be based on how much time Jacoco Code coverage takes. If its
> > negligible then good to have on every verify build or with a
> profile/flag.
> >
>
> In all my tests and attempts the module itself never took more than 10s,
> while the build doesn't seem to be affected. So basically I don't think
> it's a problem to have always the coverage in every build.
>

I took a quick look into this and ran `mvn verify` locally with and without
the coverage patch, I saw:

With Coverage:
core - 1 minute 17 seconds
jmc - 8 minutes 51 seconds

Without Coverage:
core - 1 minute 3 seconds
jmc - 8 minutes 23 seconds


>
> > > Overall, how does the patch look like? Do you think there are some more
> > > modules that need to be covered? And do you have any suggestions on how
> > to
> > > improve what I've done?
> > If possible, please update the patch to ~/jmc/core/pom.xml and
> > ~/jmc/pom.xml.
> >
>
> As far as my knowledge goes, to have the report, we need a separate pom.xml
> for the report, this because the report-aggregate[0] relies on <dependency>
> and not on <module>, even the JaCoCo examples for this have their own
> report module[1]. The best way, I think, is the current situation in which
> we have ~/jmc/core/coverage/pom.xml and ~/jmc/application/coverage/pom.xml,
> these generate and contains the coverage report, while in
> ~/jmc/core/pom.xml and ~/jmc/application/pom.xml we have the JaCoCo agent
> that makes the coverage possible. If we try to move everything in
> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml the reports will be
> segregated in their own modules. Or if we try to move part of it in
> ~/jmc/pom.xml we stiil need to have both the agent configuration in
> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml and the coverage as
> separate modules.
>

The aggregation of the coverage reports looks like it will require it's own
pom.xml, as exemplified in a sample demo from the JaCoCo github.
https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate


>
> All the changes and the new addition can be found here:
> http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.01/
>

core/tests/pom.xml
- <module>report</module> is commented out

Overall I think the patch looks good. I would however like to see the
.hgignore and .gitignore updated to exclude the coverage reports; there are
a lot of files generated in */coverage/coverage-report/*.

Regards,
> Carmine
>
> [0] https://www.jacoco.org/jacoco/trunk/doc/report-aggregate-mojo.html
> [1]
>
> https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate
>
> > Thanks,
> > > Carmine
> > >
> > > [0] https://bugs.openjdk.java.net/browse/JMC-5657
> > > [1]
> > http://mail.openjdk.java.net/pipermail/jmc-dev/2019-March/000882.html
> > > [2] https://imgur.com/hPyyLsQ
> > > [3] https://imgur.com/fqdzGvH
> > > [4] https://imgur.com/ozqNcAB
> > >
> > > --
> > > Carmine Vincenzo Russo
> > > <5657-0.patch>
> >
> >
>
> --
> Carmine Vincenzo Russo
>

From almacdon at redhat.com  Wed May 22 14:58:43 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Wed, 22 May 2019 10:58:43 -0400
Subject: RFC: JMC-5657: Code coverage with Jacoco
In-Reply-To: <CAOsn=kr2MBUobCMy4jVJA+Lger4kNec3R=wN_dufRHxq-nShuQ@mail.gmail.com>
References: <CAA6KdKcBcyHmPU4hoky8D=qMV9yO8UWWgbKcKTuBv2S_CqRHRw@mail.gmail.com>
 <B17AB67E-5845-47B1-9B3D-4415642A7957@oracle.com>
 <CAA6KdKdQRBkY_2dxVNO45=6oCzNbqs_GXEkmR5ZOA4ZxEtuvJA@mail.gmail.com>
 <CAOsn=kr2MBUobCMy4jVJA+Lger4kNec3R=wN_dufRHxq-nShuQ@mail.gmail.com>
Message-ID: <CAOsn=koFf-sN22Ma_JFNS7Z1y=cHgV_8V-CqCn8x5OEdFjh5Og@mail.gmail.com>

On Wed, May 22, 2019 at 10:43 AM Alex Macdonald <almacdon at redhat.com> wrote:

> Hi Carmine,
>
> On Fri, May 10, 2019 at 2:27 PM Carmine Vincenzo Russo <carusso at redhat.com>
> wrote:
>
>> Hi Guru,
>>
>> thanks for your reply.
>>
>> On Tue, May 7, 2019 at 6:38 PM Guru <guru.hb at oracle.com> wrote:
>>
>> > Hi Carmine,
>> >
>> > Please check my comments inline.
>> >
>> > Thanks,
>> > Guru
>> > > On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo <
>> carusso at redhat.com>
>> > wrote:
>> > >
>> > > Hello everyone,
>> > >
>> > > This patch adds Jacoco coverage over unit test in JMC.
>> > > The module covered in particular are: /core/tests and
>> /application/tests.
>> > >
>> > > The patch addresses the issue JMC-5657[0], but as noted by Klara
>> Ward[1],
>> > > instead of adding Jcov, it's better to add Jacoco.
>> > >
>> > > For the time being, each test group had a new module, report, where an
>> > > aggregate-report can be found.
>> > > You need to run 'mvn verify' in jmc root for /application/tests and in
>> > > /core for /core/tests to have the coverage report.
>> > Logically there are three build step
>> > 1. For releng
>> > 2. Core modules
>> > 3. Jmc product (i.e Application)
>> > Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for
>> step
>> > 3).
>>
>>
>> Obviously all the 3 steps are needed, I also checked, the 'mvn verify' for
>> ~/jmc/core is automatically done while building the core modules on step
>> 2.
>> For jmc product you still need to run 'mvn verify -P uitests' separately
>> after building the project since you need the test to be executed.
>>
>> Unless there is restriction on defining Jacoco in root of
>> > ~/jmc/core/pom.xml and ~/jmc/pom.xml.
>> >
>>
>> I explain this at the end.
>>
>>
>> > > There are also some aspects that concern me, so: Is this what we are
>> > > looking for?
>> > > The report for /core[2] looks good and clean. The report for
>> > > /application/tests[3][4] has good results, although there are some 0%,
>> > and
>> > > that is ok, but also some N/A. Should we keep the modules in the
>> report
>> > > with only N/A?
>> > >
>> > > There are also some changes in /application/uitests when reading the
>> > patch,
>> > > they are not yet applied but I would like to add them to the next
>> patch.
>> > Please file a follow on new JBS and link with old one (relates to
>> > JMC-5667).
>> >
>>
>> With 'next patch' I just meant the updated patch after the RFC, basically
>> what I have done now, just wanted to have your opinions before going
>> forward with the ~/uitests coverage. If a follow up issue is needed, I'll
>> ask Alex to open it.
>>
>>
>> > > This brings me to my second concern: should the tests and uitests in
>> > > /application have a unique report or should I keep them separate?
>> > Good to have Unique rather than separate.
>> >
>>
>> In the new patch attached ~/jmc/application/tests and
>> ~/jmc/applciation/uitests have a unique coverage in
>> ~/jmc/application/coverage.
>>
>>
>> > > Lastly, do we want coverage with every verify build or do we want a
>> maven
>> > > profile/flag to have the coverage only in some occasions?
>> > This could be based on how much time Jacoco Code coverage takes. If its
>> > negligible then good to have on every verify build or with a
>> profile/flag.
>> >
>>
>> In all my tests and attempts the module itself never took more than 10s,
>> while the build doesn't seem to be affected. So basically I don't think
>> it's a problem to have always the coverage in every build.
>>
>
> I took a quick look into this and ran `mvn verify` locally with and
> without the coverage patch, I saw:
>
> With Coverage:
> core - 1 minute 17 seconds
> jmc - 8 minutes 51 seconds
>
> Without Coverage:
> core - 1 minute 3 seconds
> jmc - 8 minutes 23 seconds
>
>
>>
>> > > Overall, how does the patch look like? Do you think there are some
>> more
>> > > modules that need to be covered? And do you have any suggestions on
>> how
>> > to
>> > > improve what I've done?
>> > If possible, please update the patch to ~/jmc/core/pom.xml and
>> > ~/jmc/pom.xml.
>> >
>>
>> As far as my knowledge goes, to have the report, we need a separate
>> pom.xml
>> for the report, this because the report-aggregate[0] relies on
>> <dependency>
>> and not on <module>, even the JaCoCo examples for this have their own
>> report module[1]. The best way, I think, is the current situation in which
>> we have ~/jmc/core/coverage/pom.xml and
>> ~/jmc/application/coverage/pom.xml,
>> these generate and contains the coverage report, while in
>> ~/jmc/core/pom.xml and ~/jmc/application/pom.xml we have the JaCoCo agent
>> that makes the coverage possible. If we try to move everything in
>> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml the reports will be
>> segregated in their own modules. Or if we try to move part of it in
>> ~/jmc/pom.xml we stiil need to have both the agent configuration in
>> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml and the coverage as
>> separate modules.
>>
>
> The aggregation of the coverage reports looks like it will require it's
> own pom.xml, as exemplified in a sample demo from the JaCoCo github.
>
> https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate
>
>
>>
>> All the changes and the new addition can be found here:
>> http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.01/
>>
>
> core/tests/pom.xml
> - <module>report</module> is commented out
>
> Overall I think the patch looks good. I would however like to see the
> .hgignore and .gitignore updated to exclude the coverage reports; there are
> a lot of files generated in */coverage/coverage-report/*.
>

Whoops, spoke a tad too soon.

It's having difficulties at the moment when running uitests.
https://travis-ci.org/aptmac/jmc-qa/builds/535820411

There's also comments in the application/coverage/pom.xml for the update
sites and RCP product.


Regards,
> Carmine
>
> [0] https://www.jacoco.org/jacoco/trunk/doc/report-aggregate-mojo.html
> [1]
>
> https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate
>
> > Thanks,
> > > Carmine
> > >
> > > [0] https://bugs.openjdk.java.net/browse/JMC-5657
> > > [1]
> > http://mail.openjdk.java.net/pipermail/jmc-dev/2019-March/000882.html
> > > [2] https://imgur.com/hPyyLsQ
> > > [3] https://imgur.com/fqdzGvH
> > > [4] https://imgur.com/ozqNcAB
> > >
> > > --
> > > Carmine Vincenzo Russo
> > > <5657-0.patch>
> >
> >
>
> --
> Carmine Vincenzo Russo
>

From kxu at redhat.com  Wed May 22 15:09:17 2019
From: kxu at redhat.com (Kangcheng Xu)
Date: Wed, 22 May 2019 11:09:17 -0400
Subject: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup
Message-ID: <CA+tA26t1d_vo7uuqmFc-TPOXpSoGLwL44hzAbcxFbD=YVOWWtQ@mail.gmail.com>

Hello,

This patch fixes JMC-6484 "Recent Files" sub-menu not populated on
startup [0]. It is a simple fix and only one line is changed to mark
MCPathEditorInput persistable, and therefore, is written to persistent
storage by a memento.

Please see the attached patch. Thank you very much!

[0]
https://bugs.openjdk.java.net/browse/JMC-6484
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmc-6484.patch
Type: text/x-patch
Size: 960 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190522/f68985b6/jmc-6484.patch>

From guru.hb at oracle.com  Wed May 22 15:58:16 2019
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Wed, 22 May 2019 15:58:16 +0000
Subject: hg: jmc/jmc7: JMC-6482: jmc7 fails to start jetty local server
Message-ID: <201905221558.x4MFwGh7016159@aojmv0008.oracle.com>

Changeset: 99c21d7aaf28
Author:    ghb <guru.hb at oracle.com>
Date:      2019-05-22 21:28 +0530
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/99c21d7aaf28

JMC-6482: jmc7 fails to start jetty local server
Reviewed-by: hirt <marcus.hirt at oracle.com>

! releng/third-party/pom.xml


From almacdon at redhat.com  Wed May 22 18:18:27 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Wed, 22 May 2019 14:18:27 -0400
Subject: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup
In-Reply-To: <CA+tA26t1d_vo7uuqmFc-TPOXpSoGLwL44hzAbcxFbD=YVOWWtQ@mail.gmail.com>
References: <CA+tA26t1d_vo7uuqmFc-TPOXpSoGLwL44hzAbcxFbD=YVOWWtQ@mail.gmail.com>
Message-ID: <CAOsn=kqJpMcfqSMQsRuTeJ19LAMuwruqMOGmWKoSv8k0sZKbyw@mail.gmail.com>

Hi,

On Wed, May 22, 2019 at 11:09 AM Kangcheng Xu <kxu at redhat.com> wrote:

> Hello,
>
> This patch fixes JMC-6484 "Recent Files" sub-menu not populated on
> startup [0]. It is a simple fix and only one line is changed to mark
> MCPathEditorInput persistable, and therefore, is written to persistent
> storage by a memento.
>

Passes build & uitests on my side of things and works as described, LGTM.


>
> Please see the attached patch. Thank you very much!
>
> [0]
> https://bugs.openjdk.java.net/browse/JMC-6484


Cheers,

Alex

From marcus at hirt.se  Wed May 22 19:59:36 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 22 May 2019 21:59:36 +0200
Subject: Sv: Review request for JMC-6480: Fixing the GC Locker rule.
In-Reply-To: <CAEBeOco_BXMhwHEG_2MGs1TdQVdrcsQfSVMxBmiLGxG_C7C0Sw@mail.gmail.com>
References: <02a501d51019$5ae4d270$10ae7750$@hirt.se>
 <CAEBeOco_BXMhwHEG_2MGs1TdQVdrcsQfSVMxBmiLGxG_C7C0Sw@mail.gmail.com>
Message-ID: <045701d510d8$e222ced0$a6686c70$@hirt.se>

Thanks Jie!

Here is an updated version:
cr.openjdk.java.net/~hirt/JMC-6480/webrev.1/

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: Jie Kang <jkang at redhat.com> 
Skickat: den 22 maj 2019 15:01
Till: Marcus Hirt <marcus at hirt.se>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: Review request for JMC-6480: Fixing the GC Locker rule.

Hi Marcus,

Looks mostly good to me though I think the tests will need to be adjusted for the new text:
[ERROR]   TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159

As well, I would like to suggest rephrasing of a portion of GcLockerRuleFactory_TEXT_INFO_LONG

s/will need for the object/will need the object/


Regards,


On Tue, May 21, 2019 at 5:09 PM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi all,
>
> Please review this fix for the GC Locker rule.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6480
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6480/webrev.0/
>
> Kind regards,
> Marcus
>


From jkang at redhat.com  Wed May 22 20:09:28 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 22 May 2019 16:09:28 -0400
Subject: Review request for JMC-6480: Fixing the GC Locker rule.
In-Reply-To: <045701d510d8$e222ced0$a6686c70$@hirt.se>
References: <02a501d51019$5ae4d270$10ae7750$@hirt.se>
 <CAEBeOco_BXMhwHEG_2MGs1TdQVdrcsQfSVMxBmiLGxG_C7C0Sw@mail.gmail.com>
 <045701d510d8$e222ced0$a6686c70$@hirt.se>
Message-ID: <CAEBeOcqAbNLzACGWPD4572iH7Dhc7CHt2O9aH3gzexdSmQo8Ww@mail.gmail.com>

Hey Marcus,

For

--- a/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml
+++ b/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml

it looks like the line endings of the whole file have been changed
(from \n to \r\n); is that intentional?

The patch looks good to me otherwise. Thanks for addressing my suggestions!


Cheers,

On Wed, May 22, 2019 at 3:59 PM Marcus Hirt <marcus at hirt.se> wrote:
>
> Thanks Jie!
>
> Here is an updated version:
> cr.openjdk.java.net/~hirt/JMC-6480/webrev.1/
>
> Kind regards,
> Marcus
>
> -----Ursprungligt meddelande-----
> Fr?n: Jie Kang <jkang at redhat.com>
> Skickat: den 22 maj 2019 15:01
> Till: Marcus Hirt <marcus at hirt.se>
> Kopia: jmc-dev at openjdk.java.net
> ?mne: Re: Review request for JMC-6480: Fixing the GC Locker rule.
>
> Hi Marcus,
>
> Looks mostly good to me though I think the tests will need to be adjusted for the new text:
> [ERROR]   TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159
>
> As well, I would like to suggest rephrasing of a portion of GcLockerRuleFactory_TEXT_INFO_LONG
>
> s/will need for the object/will need the object/
>
>
> Regards,
>
>
> On Tue, May 21, 2019 at 5:09 PM Marcus Hirt <marcus at hirt.se> wrote:
> >
> > Hi all,
> >
> > Please review this fix for the GC Locker rule.
> >
> > Jira:   https://bugs.openjdk.java.net/browse/JMC-6480
> > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6480/webrev.0/
> >
> > Kind regards,
> > Marcus
> >
>

From marcus.hirt at datadoghq.com  Wed May 22 20:18:38 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Wed, 22 May 2019 22:18:38 +0200
Subject: Review request for JMC-6480: Fixing the GC Locker rule.
In-Reply-To: <CAEBeOcqAbNLzACGWPD4572iH7Dhc7CHt2O9aH3gzexdSmQo8Ww@mail.gmail.com>
References: <02a501d51019$5ae4d270$10ae7750$@hirt.se>
 <CAEBeOco_BXMhwHEG_2MGs1TdQVdrcsQfSVMxBmiLGxG_C7C0Sw@mail.gmail.com>
 <045701d510d8$e222ced0$a6686c70$@hirt.se>
 <CAEBeOcqAbNLzACGWPD4572iH7Dhc7CHt2O9aH3gzexdSmQo8Ww@mail.gmail.com>
Message-ID: <CAOpWGx2wdtLm7jLpRhcx5Om_tu0GCHTGps+k6mvTkzfDHPzBTw@mail.gmail.com>

I think that is probably a result from the baseline being generated on
Windows this time. At some point we should make sure that it is done in a
platform independent manner.

Kind regards,
Marcus

On Wed, May 22, 2019 at 10:09 PM Jie Kang <jkang at redhat.com> wrote:

> Hey Marcus,
>
> For
>
> ---
> a/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml
> +++
> b/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml
>
> it looks like the line endings of the whole file have been changed
> (from \n to \r\n); is that intentional?
>
> The patch looks good to me otherwise. Thanks for addressing my suggestions!
>
>
> Cheers,
>
> On Wed, May 22, 2019 at 3:59 PM Marcus Hirt <marcus at hirt.se> wrote:
> >
> > Thanks Jie!
> >
> > Here is an updated version:
> > cr.openjdk.java.net/~hirt/JMC-6480/webrev.1/
> >
> > Kind regards,
> > Marcus
> >
> > -----Ursprungligt meddelande-----
> > Fr?n: Jie Kang <jkang at redhat.com>
> > Skickat: den 22 maj 2019 15:01
> > Till: Marcus Hirt <marcus at hirt.se>
> > Kopia: jmc-dev at openjdk.java.net
> > ?mne: Re: Review request for JMC-6480: Fixing the GC Locker rule.
> >
> > Hi Marcus,
> >
> > Looks mostly good to me though I think the tests will need to be
> adjusted for the new text:
> > [ERROR]   TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159
> >
> > As well, I would like to suggest rephrasing of a portion of
> GcLockerRuleFactory_TEXT_INFO_LONG
> >
> > s/will need for the object/will need the object/
> >
> >
> > Regards,
> >
> >
> > On Tue, May 21, 2019 at 5:09 PM Marcus Hirt <marcus at hirt.se> wrote:
> > >
> > > Hi all,
> > >
> > > Please review this fix for the GC Locker rule.
> > >
> > > Jira:   https://bugs.openjdk.java.net/browse/JMC-6480
> > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6480/webrev.0/
> > >
> > > Kind regards,
> > > Marcus
> > >
> >
>

From neugens at redhat.com  Thu May 23 14:41:51 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 23 May 2019 16:41:51 +0200
Subject: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup
In-Reply-To: <CAOsn=kqJpMcfqSMQsRuTeJ19LAMuwruqMOGmWKoSv8k0sZKbyw@mail.gmail.com>
References: <CA+tA26t1d_vo7uuqmFc-TPOXpSoGLwL44hzAbcxFbD=YVOWWtQ@mail.gmail.com>
 <CAOsn=kqJpMcfqSMQsRuTeJ19LAMuwruqMOGmWKoSv8k0sZKbyw@mail.gmail.com>
Message-ID: <CAJwKKmbPVMVgcFfDeuWg7dSQHwMiaFrO8wskCTkgiGHkKsrLTw@mail.gmail.com>

Would it be possible to have a small unit test for this?

Cheers,
Mario

On Wed, May 22, 2019 at 8:19 PM Alex Macdonald <almacdon at redhat.com> wrote:
>
> Hi,
>
> On Wed, May 22, 2019 at 11:09 AM Kangcheng Xu <kxu at redhat.com> wrote:
>
> > Hello,
> >
> > This patch fixes JMC-6484 "Recent Files" sub-menu not populated on
> > startup [0]. It is a simple fix and only one line is changed to mark
> > MCPathEditorInput persistable, and therefore, is written to persistent
> > storage by a memento.
> >
>
> Passes build & uitests on my side of things and works as described, LGTM.
>
>
> >
> > Please see the attached patch. Thank you very much!
> >
> > [0]
> > https://bugs.openjdk.java.net/browse/JMC-6484
>
>
> Cheers,
>
> Alex



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From jescolem at redhat.com  Thu May 23 16:10:41 2019
From: jescolem at redhat.com (Jessye Coleman Shapiro)
Date: Thu, 23 May 2019 12:10:41 -0400
Subject: [PATCH] JMC-6485 *.jfc" file extension set as default on Open File
Message-ID: <CAMBWjtnvL9nvUMwovVxRPk+nLyAyEQSCLVetoLKvCHb+uX9sfQ@mail.gmail.com>

Hello,

This patch fixes the JMC-6485 bug where file extensions in the Open File
pop-up were being set to ".jfc" instead of "*"  by default [0].  This was
an eclipse FileDialog bug and was fixed in the Eclipse 4.10 release in
December 2018 [1].  This patch reverts the JMC-6151 workaround [2] that was
created for this FileDialog bug and was mentioned in JMC-6171 [3].

See the attached patch bellow.

Thank you!

[0] https://bugs.openjdk.java.net/browse/JMC-6485
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540164
[2] https://bugs.openjdk.java.net/browse/JMC-6151
[3] https://bugs.openjdk.java.net/browse/JMC-6171
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmc-6485.patch
Type: text/x-patch
Size: 1520 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190523/90e42fce/jmc-6485.patch>

From jescolem at redhat.com  Thu May 23 17:57:31 2019
From: jescolem at redhat.com (Jessye Coleman Shapiro)
Date: Thu, 23 May 2019 13:57:31 -0400
Subject: [PATCH] JMC-6485 *.jfc" file extension set as default on Open File
In-Reply-To: <CAMBWjtnvL9nvUMwovVxRPk+nLyAyEQSCLVetoLKvCHb+uX9sfQ@mail.gmail.com>
References: <CAMBWjtnvL9nvUMwovVxRPk+nLyAyEQSCLVetoLKvCHb+uX9sfQ@mail.gmail.com>
Message-ID: <CAMBWjtmy76kZ0A-kvhfoBPvdczyZMsJTo4uoY51qF5Wo75Bu0w@mail.gmail.com>

On Thu, May 23, 2019 at 12:10 PM Jessye Coleman Shapiro <jescolem at redhat.com>
wrote:

> Hello,
>
> This patch fixes the JMC-6485 bug where file extensions in the Open File
> pop-up were being set to ".jfc" instead of "*"  by default [0].  This was
> an eclipse FileDialog bug and was fixed in the Eclipse 4.10 release in
> December 2018 [1].  This patch reverts the JMC-6151 workaround [2] that was
> created for this FileDialog bug and was mentioned in JMC-6171 [3].
>
> See the attached patch bellow.
>
> Thank you!
>
> [0] https://bugs.openjdk.java.net/browse/JMC-6485
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540164
> [2] https://bugs.openjdk.java.net/browse/JMC-6151
> [3] https://bugs.openjdk.java.net/browse/JMC-6171
>
>
>
To clarify, this patch addresses JMC-6171 with comment to revert JMC-6151
and it does not fix JMC-6485, though it is related.

Sorry if there was any confusion.

Jessye

From ebaron at redhat.com  Thu May 23 23:06:40 2019
From: ebaron at redhat.com (Elliott Baron)
Date: Thu, 23 May 2019 19:06:40 -0400
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
Message-ID: <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>

Hi,

Sorry for the delay. Thank you both for your reviews!

On 2019-05-02 12:55 p.m., Alex Macdonald wrote:
> A handful of minor formatting nits:
> 
> - Messages.properties (x3)
> - - the DurationPercentileTable_PERCENTILE_COL_NAME should come after 
> DUMP_RECORDING_* for alphabetical order I believe

Should be fixed now. I took this into account for the new keys added in 
this revision too.

> - There are some cases of extra whitespace, I went through hg diff and 
> counted the following number of occurrences:
> - - DurationHdrHistogram (8)
> - - DurationPercentileTable (38)
> - - FileIOPage (5)
> - - SocketIOPage (6)
> - - IOPageTest (5)
> - - IOPageTestBase (4)
> - - SocketIOPageTest(5)

This revised patch should not have any trailing whitespace.

> I noticed that when resizing the page, the durations table stays static 
> whereas the other tables seems to adjust (gif) [3]. This only seems to 
> cause an issue when my JMC window gets resized to just under 50% on my 
> monitor width, and the chart will get hidden. In the gif my JMC window 
> is around half my monitor width (of 1920), and with the JVM 
> Browser/Outline window open then I don't have much more room to shrink 
> the application before the chart disappears. I was just curious if the 
> table could adjust to resizing like the other tables.

This was a bit tricky due to the table sitting side-by-side with the 
chart. I used the (unused?) SimpleLayout class within JMC to define 
weights to keep the percentage of the width occupied by the chart and 
table constant, even while resizing.

> Also not caused by this patch (but thought it'd be interesting to 
> share), I'm seeing a bug where my chart text gets really large [4] when 
> I run JMC locally and not as an RCP application (I recall seeing a JIRA 
> bug for this before, but cannot find it), and my durations tab will only 
> show the table (and not even the whole thing) [5].
I am still seeing this as well.

On 2019-05-02 3:02 p.m., Marcus Hirt wrote:
> This is a great start! Aside from the comments already provided by Alex, 
> here is some feedback:
> 
> * It would be great to be able to select a percentile and be able to do 
> set as focused selection, and add the events for that percentile to the 
> focused selection.

This should be working now. When setting a table row as the focused 
selection, all events with duration at least as long as the percentile 
values in that row will be selected.

e.g. Setting the 99th percentile row as the focused selection, with read 
duration of 10ms and write duration of 50ms, will only show read events 
 >= 10ms and write events >= 50ms.

> * The current UI splits read and writes in two different lanes, perhaps 
> that would make sense here too, also for selection purposes. And just as 
> with the lanes, only show when there is available data.

With this revised patch, when there are no matching read or write 
events, the corresponding columns will not be shown. There is a slight 
issue when columns are hidden and then reappear, the last column is too 
large and needs be resized manually. I can reproduce this in other 
tables by hiding two columns, and restoring them. I'm not sure of the cause.

> * Perhaps the counts shown should be the number of events in the 
> percentile or above, as those would be the number of events selected - 
> i.e. if you select events in the 99.9 percentile, you probably don't 
> want all of the events up to and including the ones in the 99.9th 
> percentile, but rather the outliers, the ones in 99.9 and above.

Makes sense to me, the event counts now show events with duration 
greater or equal to the value in that row.

> * It would be cool to add a normalized backdrop in the tables to get a 
> rough visual representation of how many of the events are actually in 
> the different buckets.

I have added this as well.

Here is a revised webrev that should address all of the feedback 
received so far.

Bug: https://bugs.openjdk.java.net/browse/JMC-5327
Webrev: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.0/
Preview: https://imgur.com/a/oqX0fai

Thanks,
Elliott

From hdafgard at gmail.com  Fri May 24 10:57:29 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Fri, 24 May 2019 12:57:29 +0200
Subject: Review request for JMC-6480: Fixing the GC Locker rule.
In-Reply-To: <CAOpWGx2wdtLm7jLpRhcx5Om_tu0GCHTGps+k6mvTkzfDHPzBTw@mail.gmail.com>
References: <02a501d51019$5ae4d270$10ae7750$@hirt.se>
 <CAEBeOco_BXMhwHEG_2MGs1TdQVdrcsQfSVMxBmiLGxG_C7C0Sw@mail.gmail.com>
 <045701d510d8$e222ced0$a6686c70$@hirt.se>
 <CAEBeOcqAbNLzACGWPD4572iH7Dhc7CHt2O9aH3gzexdSmQo8Ww@mail.gmail.com>
 <CAOpWGx2wdtLm7jLpRhcx5Om_tu0GCHTGps+k6mvTkzfDHPzBTw@mail.gmail.com>
Message-ID: <CADFkdVQw3RFKxvABr40-mjzwxTN9VUZodKbm_+jh+Zp-1SwcJQ@mail.gmail.com>

This change looks good to me! I agree with the discussion on the
JfrRuleBaseline, but that is probably for a later time.


Regards,
Henrik Dafg?rd


On Wed, 22 May 2019 at 22:19, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:

> I think that is probably a result from the baseline being generated on
> Windows this time. At some point we should make sure that it is done in a
> platform independent manner.
>
> Kind regards,
> Marcus
>
> On Wed, May 22, 2019 at 10:09 PM Jie Kang <jkang at redhat.com> wrote:
>
> > Hey Marcus,
> >
> > For
> >
> > ---
> >
> a/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml
> > +++
> >
> b/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml
> >
> > it looks like the line endings of the whole file have been changed
> > (from \n to \r\n); is that intentional?
> >
> > The patch looks good to me otherwise. Thanks for addressing my
> suggestions!
> >
> >
> > Cheers,
> >
> > On Wed, May 22, 2019 at 3:59 PM Marcus Hirt <marcus at hirt.se> wrote:
> > >
> > > Thanks Jie!
> > >
> > > Here is an updated version:
> > > cr.openjdk.java.net/~hirt/JMC-6480/webrev.1/
> > >
> > > Kind regards,
> > > Marcus
> > >
> > > -----Ursprungligt meddelande-----
> > > Fr?n: Jie Kang <jkang at redhat.com>
> > > Skickat: den 22 maj 2019 15:01
> > > Till: Marcus Hirt <marcus at hirt.se>
> > > Kopia: jmc-dev at openjdk.java.net
> > > ?mne: Re: Review request for JMC-6480: Fixing the GC Locker rule.
> > >
> > > Hi Marcus,
> > >
> > > Looks mostly good to me though I think the tests will need to be
> > adjusted for the new text:
> > > [ERROR]   TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159
> > >
> > > As well, I would like to suggest rephrasing of a portion of
> > GcLockerRuleFactory_TEXT_INFO_LONG
> > >
> > > s/will need for the object/will need the object/
> > >
> > >
> > > Regards,
> > >
> > >
> > > On Tue, May 21, 2019 at 5:09 PM Marcus Hirt <marcus at hirt.se> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Please review this fix for the GC Locker rule.
> > > >
> > > > Jira:   https://bugs.openjdk.java.net/browse/JMC-6480
> > > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6480/webrev.0/
> > > >
> > > > Kind regards,
> > > > Marcus
> > > >
> > >
> >
>

From marcus at hirt.se  Fri May 24 11:05:17 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Fri, 24 May 2019 11:05:17 +0000
Subject: hg: jmc/jmc: JMC-6480: Fixing the GC Locker rule
Message-ID: <201905241105.x4OB5HN9027007@aojmv0008.oracle.com>

Changeset: 4c9efa5eb5b8
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-24 13:05 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/4c9efa5eb5b8

JMC-6480: Fixing the GC Locker rule
Reviewed-by: hdafgard, Jie Kang <jkang at redhat.com>

! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GarbageCollectionsInfo.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties
! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml


From marcus.hirt at datadoghq.com  Fri May 24 11:07:16 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 24 May 2019 13:07:16 +0200
Subject: Review request for JMC-6480: Fixing the GC Locker rule.
In-Reply-To: <CADFkdVQw3RFKxvABr40-mjzwxTN9VUZodKbm_+jh+Zp-1SwcJQ@mail.gmail.com>
References: <02a501d51019$5ae4d270$10ae7750$@hirt.se>
 <CAEBeOco_BXMhwHEG_2MGs1TdQVdrcsQfSVMxBmiLGxG_C7C0Sw@mail.gmail.com>
 <045701d510d8$e222ced0$a6686c70$@hirt.se>
 <CAEBeOcqAbNLzACGWPD4572iH7Dhc7CHt2O9aH3gzexdSmQo8Ww@mail.gmail.com>
 <CAOpWGx2wdtLm7jLpRhcx5Om_tu0GCHTGps+k6mvTkzfDHPzBTw@mail.gmail.com>
 <CADFkdVQw3RFKxvABr40-mjzwxTN9VUZodKbm_+jh+Zp-1SwcJQ@mail.gmail.com>
Message-ID: <CAOpWGx31-_2vm1yy2jskzL3k1v89Nu9XTnFT1v34ApN1H99cCg@mail.gmail.com>

Thanks Jie and Henrik for reviewing!

Kind regards,
Marcus

On Fri, May 24, 2019 at 12:57 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:

> This change looks good to me! I agree with the discussion on the
> JfrRuleBaseline, but that is probably for a later time.
>
>
> Regards,
> Henrik Dafg?rd
>
>
> On Wed, 22 May 2019 at 22:19, Marcus Hirt <marcus.hirt at datadoghq.com>
> wrote:
>
>> I think that is probably a result from the baseline being generated on
>> Windows this time. At some point we should make sure that it is done in a
>> platform independent manner.
>>
>> Kind regards,
>> Marcus
>>
>> On Wed, May 22, 2019 at 10:09 PM Jie Kang <jkang at redhat.com> wrote:
>>
>> > Hey Marcus,
>> >
>> > For
>> >
>> > ---
>> >
>> a/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml
>> > +++
>> >
>> b/core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/resources/baseline/JfrRuleBaseline.xml
>> >
>> > it looks like the line endings of the whole file have been changed
>> > (from \n to \r\n); is that intentional?
>> >
>> > The patch looks good to me otherwise. Thanks for addressing my
>> suggestions!
>> >
>> >
>> > Cheers,
>> >
>> > On Wed, May 22, 2019 at 3:59 PM Marcus Hirt <marcus at hirt.se> wrote:
>> > >
>> > > Thanks Jie!
>> > >
>> > > Here is an updated version:
>> > > cr.openjdk.java.net/~hirt/JMC-6480/webrev.1/
>> > >
>> > > Kind regards,
>> > > Marcus
>> > >
>> > > -----Ursprungligt meddelande-----
>> > > Fr?n: Jie Kang <jkang at redhat.com>
>> > > Skickat: den 22 maj 2019 15:01
>> > > Till: Marcus Hirt <marcus at hirt.se>
>> > > Kopia: jmc-dev at openjdk.java.net
>> > > ?mne: Re: Review request for JMC-6480: Fixing the GC Locker rule.
>> > >
>> > > Hi Marcus,
>> > >
>> > > Looks mostly good to me though I think the tests will need to be
>> > adjusted for the new text:
>> > > [ERROR]   TestRulesWithJfr.verifyAllResults:132->verifyRuleResults:159
>> > >
>> > > As well, I would like to suggest rephrasing of a portion of
>> > GcLockerRuleFactory_TEXT_INFO_LONG
>> > >
>> > > s/will need for the object/will need the object/
>> > >
>> > >
>> > > Regards,
>> > >
>> > >
>> > > On Tue, May 21, 2019 at 5:09 PM Marcus Hirt <marcus at hirt.se> wrote:
>> > > >
>> > > > Hi all,
>> > > >
>> > > > Please review this fix for the GC Locker rule.
>> > > >
>> > > > Jira:   https://bugs.openjdk.java.net/browse/JMC-6480
>> > > > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6480/webrev.0/
>> > > >
>> > > > Kind regards,
>> > > > Marcus
>> > > >
>> > >
>> >
>>
>

From almacdon at redhat.com  Fri May 24 18:25:41 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Fri, 24 May 2019 14:25:41 -0400
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
 <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
Message-ID: <CAOsn=kqKYiFApr91LOpGqa0nNGUAB5uYv7i0kZzKb7ZQDpJTFA@mail.gmail.com>

On Thu, May 23, 2019 at 7:06 PM Elliott Baron <ebaron at redhat.com> wrote:

> Hi,
>
> Sorry for the delay. Thank you both for your reviews!
>
> On 2019-05-02 12:55 p.m., Alex Macdonald wrote:
> > A handful of minor formatting nits:
> >
> > - Messages.properties (x3)
> > - - the DurationPercentileTable_PERCENTILE_COL_NAME should come after
> > DUMP_RECORDING_* for alphabetical order I believe
>
> Should be fixed now. I took this into account for the new keys added in
> this revision too.
>
> > - There are some cases of extra whitespace, I went through hg diff and
> > counted the following number of occurrences:
> > - - DurationHdrHistogram (8)
> > - - DurationPercentileTable (38)
> > - - FileIOPage (5)
> > - - SocketIOPage (6)
> > - - IOPageTest (5)
> > - - IOPageTestBase (4)
> > - - SocketIOPageTest(5)
>
> This revised patch should not have any trailing whitespace.
>
> > I noticed that when resizing the page, the durations table stays static
> > whereas the other tables seems to adjust (gif) [3]. This only seems to
> > cause an issue when my JMC window gets resized to just under 50% on my
> > monitor width, and the chart will get hidden. In the gif my JMC window
> > is around half my monitor width (of 1920), and with the JVM
> > Browser/Outline window open then I don't have much more room to shrink
> > the application before the chart disappears. I was just curious if the
> > table could adjust to resizing like the other tables.
>
> This was a bit tricky due to the table sitting side-by-side with the
> chart. I used the (unused?) SimpleLayout class within JMC to define
> weights to keep the percentage of the width occupied by the chart and
> table constant, even while resizing.
>

Thanks for taking a look into this! All of my comments have been addressed.


>
> > Also not caused by this patch (but thought it'd be interesting to
> > share), I'm seeing a bug where my chart text gets really large [4] when
> > I run JMC locally and not as an RCP application (I recall seeing a JIRA
> > bug for this before, but cannot find it), and my durations tab will only
> > show the table (and not even the whole thing) [5].
> I am still seeing this as well.
>
> On 2019-05-02 3:02 p.m., Marcus Hirt wrote:
> > This is a great start! Aside from the comments already provided by Alex,
> > here is some feedback:
> >
> > * It would be great to be able to select a percentile and be able to do
> > set as focused selection, and add the events for that percentile to the
> > focused selection.
>
> This should be working now. When setting a table row as the focused
> selection, all events with duration at least as long as the percentile
> values in that row will be selected.
>
> e.g. Setting the 99th percentile row as the focused selection, with read
> duration of 10ms and write duration of 50ms, will only show read events
>  >= 10ms and write events >= 50ms.
>
> > * The current UI splits read and writes in two different lanes, perhaps
> > that would make sense here too, also for selection purposes. And just as
> > with the lanes, only show when there is available data.
>
> With this revised patch, when there are no matching read or write
> events, the corresponding columns will not be shown. There is a slight
> issue when columns are hidden and then reappear, the last column is too
> large and needs be resized manually. I can reproduce this in other
> tables by hiding two columns, and restoring them. I'm not sure of the
> cause.
>
> > * Perhaps the counts shown should be the number of events in the
> > percentile or above, as those would be the number of events selected -
> > i.e. if you select events in the 99.9 percentile, you probably don't
> > want all of the events up to and including the ones in the 99.9th
> > percentile, but rather the outliers, the ones in 99.9 and above.
>
> Makes sense to me, the event counts now show events with duration
> greater or equal to the value in that row.
>
> > * It would be cool to add a normalized backdrop in the tables to get a
> > rough visual representation of how many of the events are actually in
> > the different buckets.
>
> I have added this as well.
>
> Here is a revised webrev that should address all of the feedback
> received so far.
>
> Bug: https://bugs.openjdk.java.net/browse/JMC-5327
> Webrev: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.0/
> Preview: https://imgur.com/a/oqX0fai
>
> Thanks,
> Elliott
>

From marcus.hirt at datadoghq.com  Fri May 24 19:13:25 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 24 May 2019 21:13:25 +0200
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
 <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
Message-ID: <CAOpWGx1JnM65WQ-wwGaGFUH7xVoc=9o_+u-PiJCqp1CmUMx2Hg@mail.gmail.com>

Very nice Elliot! This looks great! How sure are you of the Japanese and
Chinese translations? Would you want for someone to take a look at them?

Kind regards,
Marcus

On Fri, May 24, 2019 at 1:06 AM Elliott Baron <ebaron at redhat.com> wrote:

> Hi,
>
> Sorry for the delay. Thank you both for your reviews!
>
> On 2019-05-02 12:55 p.m., Alex Macdonald wrote:
> > A handful of minor formatting nits:
> >
> > - Messages.properties (x3)
> > - - the DurationPercentileTable_PERCENTILE_COL_NAME should come after
> > DUMP_RECORDING_* for alphabetical order I believe
>
> Should be fixed now. I took this into account for the new keys added in
> this revision too.
>
> > - There are some cases of extra whitespace, I went through hg diff and
> > counted the following number of occurrences:
> > - - DurationHdrHistogram (8)
> > - - DurationPercentileTable (38)
> > - - FileIOPage (5)
> > - - SocketIOPage (6)
> > - - IOPageTest (5)
> > - - IOPageTestBase (4)
> > - - SocketIOPageTest(5)
>
> This revised patch should not have any trailing whitespace.
>
> > I noticed that when resizing the page, the durations table stays static
> > whereas the other tables seems to adjust (gif) [3]. This only seems to
> > cause an issue when my JMC window gets resized to just under 50% on my
> > monitor width, and the chart will get hidden. In the gif my JMC window
> > is around half my monitor width (of 1920), and with the JVM
> > Browser/Outline window open then I don't have much more room to shrink
> > the application before the chart disappears. I was just curious if the
> > table could adjust to resizing like the other tables.
>
> This was a bit tricky due to the table sitting side-by-side with the
> chart. I used the (unused?) SimpleLayout class within JMC to define
> weights to keep the percentage of the width occupied by the chart and
> table constant, even while resizing.
>
> > Also not caused by this patch (but thought it'd be interesting to
> > share), I'm seeing a bug where my chart text gets really large [4] when
> > I run JMC locally and not as an RCP application (I recall seeing a JIRA
> > bug for this before, but cannot find it), and my durations tab will only
> > show the table (and not even the whole thing) [5].
> I am still seeing this as well.
>
> On 2019-05-02 3:02 p.m., Marcus Hirt wrote:
> > This is a great start! Aside from the comments already provided by Alex,
> > here is some feedback:
> >
> > * It would be great to be able to select a percentile and be able to do
> > set as focused selection, and add the events for that percentile to the
> > focused selection.
>
> This should be working now. When setting a table row as the focused
> selection, all events with duration at least as long as the percentile
> values in that row will be selected.
>
> e.g. Setting the 99th percentile row as the focused selection, with read
> duration of 10ms and write duration of 50ms, will only show read events
>  >= 10ms and write events >= 50ms.
>
> > * The current UI splits read and writes in two different lanes, perhaps
> > that would make sense here too, also for selection purposes. And just as
> > with the lanes, only show when there is available data.
>
> With this revised patch, when there are no matching read or write
> events, the corresponding columns will not be shown. There is a slight
> issue when columns are hidden and then reappear, the last column is too
> large and needs be resized manually. I can reproduce this in other
> tables by hiding two columns, and restoring them. I'm not sure of the
> cause.
>
> > * Perhaps the counts shown should be the number of events in the
> > percentile or above, as those would be the number of events selected -
> > i.e. if you select events in the 99.9 percentile, you probably don't
> > want all of the events up to and including the ones in the 99.9th
> > percentile, but rather the outliers, the ones in 99.9 and above.
>
> Makes sense to me, the event counts now show events with duration
> greater or equal to the value in that row.
>
> > * It would be cool to add a normalized backdrop in the tables to get a
> > rough visual representation of how many of the events are actually in
> > the different buckets.
>
> I have added this as well.
>
> Here is a revised webrev that should address all of the feedback
> received so far.
>
> Bug: https://bugs.openjdk.java.net/browse/JMC-5327
> Webrev: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.0/
> Preview: https://imgur.com/a/oqX0fai
>
> Thanks,
> Elliott
>

From marcus at hirt.se  Fri May 24 23:37:36 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Sat, 25 May 2019 01:37:36 +0200
Subject: Review request for JMC-3338: Visualization of loaded libraries.
Message-ID: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>

Hi all,

Please review this fix to add simple visualization of loaded native libraries.

Also fixes some other annoyances:
. Environment variables should be sorted on key by default.
. System properties should be sorted on key by default.
. It should be okay to have a query with both attributes and aggregators to
fuel 
  the DistinctItemsPage.
. Some unused imports.

Jira:   https://bugs.openjdk.java.net/browse/JMC-3338
Webrev: http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.0/

Kind regards,
Marcus



From marcus at hirt.se  Sat May 25 00:02:33 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Sat, 25 May 2019 02:02:33 +0200
Subject: Sv: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup
In-Reply-To: <CA+tA26t1d_vo7uuqmFc-TPOXpSoGLwL44hzAbcxFbD=YVOWWtQ@mail.gmail.com>
References: <CA+tA26t1d_vo7uuqmFc-TPOXpSoGLwL44hzAbcxFbD=YVOWWtQ@mail.gmail.com>
Message-ID: <0a2801d5128d$27491f90$75db5eb0$@hirt.se>

Hi there!

There seem to be other users of that class that use the 
default constructor presumably because they do not want 
to persist their opening of files, such as trigger
actions. One could argue that maybe they should end up 
in the recently opened list too, but I believe this is 
at least the reason for the current behavior.

A slightly more defensive solution could be to instead:

diff -r 4c9efa5eb5b8 application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java
--- a/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java     Fri May 24 13:05:05 2019 +0200
+++ b/application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/application/actions/OpenFileAction.java     Sat May 25 01:59:12 2019 +0200
@@ -161,7 +161,7 @@
                        for (String name : names) {
                                final File file = new File(filterPath + File.separator + name);
                                if (file.exists()) {
-                                       WorkbenchToolkit.openEditor(inWindow, new MCPathEditorInput(file));
+                                       WorkbenchToolkit.openEditor(inWindow, new MCPathEditorInput(file, true));
                                } else {
                                        if (++numberOfFilesNotFound > 1) {
                                                notFound.append('\n'); 

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Kangcheng Xu
Skickat: den 22 maj 2019 17:09
Till: jmc-dev at openjdk.java.net
?mne: [PATCH] JMC-6484 "Recent Files" sub-menu not populated on startup

Hello,

This patch fixes JMC-6484 "Recent Files" sub-menu not populated on startup [0]. It is a simple fix and only one line is changed to mark MCPathEditorInput persistable, and therefore, is written to persistent storage by a memento.

Please see the attached patch. Thank you very much!

[0]
https://bugs.openjdk.java.net/browse/JMC-6484


From marcus.hirt at datadoghq.com  Mon May 27 07:47:55 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 27 May 2019 09:47:55 +0200
Subject: Review request for JMC-6458: Backporting the upgrade to Eclipse
 2019-03.
Message-ID: <CAOpWGx2sgd10cfAe=Y0r14MmyACmiZohuGfvxWyTMbAnbuy9Bw@mail.gmail.com>

Hi all,

Please review this request for back-porting the upgrade to Eclipse 2019-03
(with related changes) to JMC 7.0.0 (the jmc7 repo).

Jira:   https://bugs.openjdk.java.net/browse/JMC-6458
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6458/webrev.2/

Kind regards,
Marcus

From guru.hb at oracle.com  Mon May 27 09:38:15 2019
From: guru.hb at oracle.com (Guru)
Date: Mon, 27 May 2019 15:08:15 +0530
Subject: Review request for JMC-6458: Backporting the upgrade to Eclipse
 2019-03.
In-Reply-To: <CAOpWGx2sgd10cfAe=Y0r14MmyACmiZohuGfvxWyTMbAnbuy9Bw@mail.gmail.com>
References: <CAOpWGx2sgd10cfAe=Y0r14MmyACmiZohuGfvxWyTMbAnbuy9Bw@mail.gmail.com>
Message-ID: <02C07351-CD45-4758-947F-06D04D43A6CA@oracle.com>

+1, 

Tested on Mac OS X and Windows.

Thanks,
Guru
> On 27-May-2019, at 1:17 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> 
> Hi all,
> 
> Please review this request for back-porting the upgrade to Eclipse 2019-03
> (with related changes) to JMC 7.0.0 (the jmc7 repo).
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6458
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6458/webrev.2/
> 
> Kind regards,
> Marcus


From hdafgard at gmail.com  Mon May 27 09:54:33 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Mon, 27 May 2019 11:54:33 +0200
Subject: Review request for JMC-3338: Visualization of loaded libraries.
In-Reply-To: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>
References: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>
Message-ID: <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>

Hi Marcus,

I think the proposed change looks good, even though there are a few
formatting/whitespace changes in there as well. The JdkFilters file also
seems to be included without any changes somehow?


Regards,
Henrik Dafg?rd


On Sat, 25 May 2019 at 01:38, Marcus Hirt <marcus at hirt.se> wrote:

> Hi all,
>
> Please review this fix to add simple visualization of loaded native
> libraries.
>
> Also fixes some other annoyances:
> . Environment variables should be sorted on key by default.
> . System properties should be sorted on key by default.
> . It should be okay to have a query with both attributes and aggregators to
> fuel
>   the DistinctItemsPage.
> . Some unused imports.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-3338
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.0/
>
> Kind regards,
> Marcus
>
>
>

From ebaron at redhat.com  Mon May 27 16:09:51 2019
From: ebaron at redhat.com (Elliott Baron)
Date: Mon, 27 May 2019 12:09:51 -0400
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <CAOpWGx1JnM65WQ-wwGaGFUH7xVoc=9o_+u-PiJCqp1CmUMx2Hg@mail.gmail.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
 <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
 <CAOpWGx1JnM65WQ-wwGaGFUH7xVoc=9o_+u-PiJCqp1CmUMx2Hg@mail.gmail.com>
Message-ID: <ab7b4523-479b-86b5-fe90-3c9930bbb5e4@redhat.com>

Hi Marcus,

On 2019-05-24 3:13 p.m., Marcus Hirt wrote:
> Very nice Elliot! This looks great!

Glad to hear it, thanks!

> How sure are you of the Japanese and 
> Chinese translations? Would you want for someone to take a look at them?

These come from substituting the word for "percentile" (found online) 
into existing localized strings with the same sort of desired phrasing 
(e.g. File I/O Histogram Selection). If there is someone who could 
verify/improve the translations, I would appreciate it.

Thanks,
Elliott

> 
> Kind regards,
> Marcus
> 
> On Fri, May 24, 2019 at 1:06 AM Elliott Baron <ebaron at redhat.com 
> <mailto:ebaron at redhat.com>> wrote:
> 
>     Hi,
> 
>     Sorry for the delay. Thank you both for your reviews!
> 
>     On 2019-05-02 12:55 p.m., Alex Macdonald wrote:
>      > A handful of minor formatting nits:
>      >
>      > - Messages.properties (x3)
>      > - - the DurationPercentileTable_PERCENTILE_COL_NAME should come
>     after
>      > DUMP_RECORDING_* for alphabetical order I believe
> 
>     Should be fixed now. I took this into account for the new keys added in
>     this revision too.
> 
>      > - There are some cases of extra whitespace, I went through hg
>     diff and
>      > counted the following number of occurrences:
>      > - - DurationHdrHistogram (8)
>      > - - DurationPercentileTable (38)
>      > - - FileIOPage (5)
>      > - - SocketIOPage (6)
>      > - - IOPageTest (5)
>      > - - IOPageTestBase (4)
>      > - - SocketIOPageTest(5)
> 
>     This revised patch should not have any trailing whitespace.
> 
>      > I noticed that when resizing the page, the durations table stays
>     static
>      > whereas the other tables seems to adjust (gif) [3]. This only
>     seems to
>      > cause an issue when my JMC window gets resized to just under 50%
>     on my
>      > monitor width, and the chart will get hidden. In the gif my JMC
>     window
>      > is around half my monitor width (of 1920), and with the JVM
>      > Browser/Outline window open then I don't have much more room to
>     shrink
>      > the application before the chart disappears. I was just curious
>     if the
>      > table could adjust to resizing like the other tables.
> 
>     This was a bit tricky due to the table sitting side-by-side with the
>     chart. I used the (unused?) SimpleLayout class within JMC to define
>     weights to keep the percentage of the width occupied by the chart and
>     table constant, even while resizing.
> 
>      > Also not caused by this patch (but thought it'd be interesting to
>      > share), I'm seeing a bug where my chart text gets really large
>     [4] when
>      > I run JMC locally and not as an RCP application (I recall seeing
>     a JIRA
>      > bug for this before, but cannot find it), and my durations tab
>     will only
>      > show the table (and not even the whole thing) [5].
>     I am still seeing this as well.
> 
>     On 2019-05-02 3:02 p.m., Marcus Hirt wrote:
>      > This is a great start! Aside from the comments already provided
>     by Alex,
>      > here is some feedback:
>      >
>      > * It would be great to be able to select a percentile and be able
>     to do
>      > set as focused selection, and add the events for that percentile
>     to the
>      > focused selection.
> 
>     This should be working now. When setting a table row as the focused
>     selection, all events with duration at least as long as the percentile
>     values in that row will be selected.
> 
>     e.g. Setting the 99th percentile row as the focused selection, with
>     read
>     duration of 10ms and write duration of 50ms, will only show read events
>      ?>= 10ms and write events >= 50ms.
> 
>      > * The current UI splits read and writes in two different lanes,
>     perhaps
>      > that would make sense here too, also for selection purposes. And
>     just as
>      > with the lanes, only show when there is available data.
> 
>     With this revised patch, when there are no matching read or write
>     events, the corresponding columns will not be shown. There is a slight
>     issue when columns are hidden and then reappear, the last column is too
>     large and needs be resized manually. I can reproduce this in other
>     tables by hiding two columns, and restoring them. I'm not sure of
>     the cause.
> 
>      > * Perhaps the counts shown should be the number of events in the
>      > percentile or above, as those would be the number of events
>     selected -
>      > i.e. if you select events in the 99.9 percentile, you probably don't
>      > want all of the events up to and including the ones in the 99.9th
>      > percentile, but rather the outliers, the ones in 99.9 and above.
> 
>     Makes sense to me, the event counts now show events with duration
>     greater or equal to the value in that row.
> 
>      > * It would be cool to add a normalized backdrop in the tables to
>     get a
>      > rough visual representation of how many of the events are
>     actually in
>      > the different buckets.
> 
>     I have added this as well.
> 
>     Here is a revised webrev that should address all of the feedback
>     received so far.
> 
>     Bug: https://bugs.openjdk.java.net/browse/JMC-5327
>     Webrev: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.0/
>     Preview: https://imgur.com/a/oqX0fai
> 
>     Thanks,
>     Elliott
> 

From marcus.hirt at datadoghq.com  Mon May 27 18:00:11 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 27 May 2019 20:00:11 +0200
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <ab7b4523-479b-86b5-fe90-3c9930bbb5e4@redhat.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
 <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
 <CAOpWGx1JnM65WQ-wwGaGFUH7xVoc=9o_+u-PiJCqp1CmUMx2Hg@mail.gmail.com>
 <ab7b4523-479b-86b5-fe90-3c9930bbb5e4@redhat.com>
Message-ID: <CAOpWGx0EiG4fwAe16m-jkv+9t0HiYv1n4YXPLQgu2jmo3nsZaw@mail.gmail.com>

Hi David!

Can you help verify the Japanese translation?

Kind regards,
Marcus

On Mon, May 27, 2019 at 6:09 PM Elliott Baron <ebaron at redhat.com> wrote:
>
> Hi Marcus,
>
> On 2019-05-24 3:13 p.m., Marcus Hirt wrote:
> > Very nice Elliot! This looks great!
>
> Glad to hear it, thanks!
>
> > How sure are you of the Japanese and
> > Chinese translations? Would you want for someone to take a look at them?
>
> These come from substituting the word for "percentile" (found online)
> into existing localized strings with the same sort of desired phrasing
> (e.g. File I/O Histogram Selection). If there is someone who could
> verify/improve the translations, I would appreciate it.
>
> Thanks,
> Elliott
>
> >
> > Kind regards,
> > Marcus
> >
> > On Fri, May 24, 2019 at 1:06 AM Elliott Baron <ebaron at redhat.com
> > <mailto:ebaron at redhat.com>> wrote:
> >
> >     Hi,
> >
> >     Sorry for the delay. Thank you both for your reviews!
> >
> >     On 2019-05-02 12:55 p.m., Alex Macdonald wrote:
> >      > A handful of minor formatting nits:
> >      >
> >      > - Messages.properties (x3)
> >      > - - the DurationPercentileTable_PERCENTILE_COL_NAME should come
> >     after
> >      > DUMP_RECORDING_* for alphabetical order I believe
> >
> >     Should be fixed now. I took this into account for the new keys added in
> >     this revision too.
> >
> >      > - There are some cases of extra whitespace, I went through hg
> >     diff and
> >      > counted the following number of occurrences:
> >      > - - DurationHdrHistogram (8)
> >      > - - DurationPercentileTable (38)
> >      > - - FileIOPage (5)
> >      > - - SocketIOPage (6)
> >      > - - IOPageTest (5)
> >      > - - IOPageTestBase (4)
> >      > - - SocketIOPageTest(5)
> >
> >     This revised patch should not have any trailing whitespace.
> >
> >      > I noticed that when resizing the page, the durations table stays
> >     static
> >      > whereas the other tables seems to adjust (gif) [3]. This only
> >     seems to
> >      > cause an issue when my JMC window gets resized to just under 50%
> >     on my
> >      > monitor width, and the chart will get hidden. In the gif my JMC
> >     window
> >      > is around half my monitor width (of 1920), and with the JVM
> >      > Browser/Outline window open then I don't have much more room to
> >     shrink
> >      > the application before the chart disappears. I was just curious
> >     if the
> >      > table could adjust to resizing like the other tables.
> >
> >     This was a bit tricky due to the table sitting side-by-side with the
> >     chart. I used the (unused?) SimpleLayout class within JMC to define
> >     weights to keep the percentage of the width occupied by the chart and
> >     table constant, even while resizing.
> >
> >      > Also not caused by this patch (but thought it'd be interesting to
> >      > share), I'm seeing a bug where my chart text gets really large
> >     [4] when
> >      > I run JMC locally and not as an RCP application (I recall seeing
> >     a JIRA
> >      > bug for this before, but cannot find it), and my durations tab
> >     will only
> >      > show the table (and not even the whole thing) [5].
> >     I am still seeing this as well.
> >
> >     On 2019-05-02 3:02 p.m., Marcus Hirt wrote:
> >      > This is a great start! Aside from the comments already provided
> >     by Alex,
> >      > here is some feedback:
> >      >
> >      > * It would be great to be able to select a percentile and be able
> >     to do
> >      > set as focused selection, and add the events for that percentile
> >     to the
> >      > focused selection.
> >
> >     This should be working now. When setting a table row as the focused
> >     selection, all events with duration at least as long as the percentile
> >     values in that row will be selected.
> >
> >     e.g. Setting the 99th percentile row as the focused selection, with
> >     read
> >     duration of 10ms and write duration of 50ms, will only show read events
> >       >= 10ms and write events >= 50ms.
> >
> >      > * The current UI splits read and writes in two different lanes,
> >     perhaps
> >      > that would make sense here too, also for selection purposes. And
> >     just as
> >      > with the lanes, only show when there is available data.
> >
> >     With this revised patch, when there are no matching read or write
> >     events, the corresponding columns will not be shown. There is a slight
> >     issue when columns are hidden and then reappear, the last column is too
> >     large and needs be resized manually. I can reproduce this in other
> >     tables by hiding two columns, and restoring them. I'm not sure of
> >     the cause.
> >
> >      > * Perhaps the counts shown should be the number of events in the
> >      > percentile or above, as those would be the number of events
> >     selected -
> >      > i.e. if you select events in the 99.9 percentile, you probably don't
> >      > want all of the events up to and including the ones in the 99.9th
> >      > percentile, but rather the outliers, the ones in 99.9 and above.
> >
> >     Makes sense to me, the event counts now show events with duration
> >     greater or equal to the value in that row.
> >
> >      > * It would be cool to add a normalized backdrop in the tables to
> >     get a
> >      > rough visual representation of how many of the events are
> >     actually in
> >      > the different buckets.
> >
> >     I have added this as well.
> >
> >     Here is a revised webrev that should address all of the feedback
> >     received so far.
> >
> >     Bug: https://bugs.openjdk.java.net/browse/JMC-5327
> >     Webrev: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.0/
> >     Preview: https://imgur.com/a/oqX0fai
> >
> >     Thanks,
> >     Elliott
> >

From marcus.hirt at datadoghq.com  Mon May 27 18:07:15 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 27 May 2019 20:07:15 +0200
Subject: Review request for JMC-3338: Visualization of loaded libraries.
In-Reply-To: <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>
References: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>
 <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>
Message-ID: <CAOpWGx3ErPvv+qU_cn=ZXNO=X2-cqP7u26u4DxEN=StF5vaohA@mail.gmail.com>

Hi Henrik,


Yep, ran the auto-formatter with the JMC settings. Seems we have some
files which haven't been properly formatted. Will take a look at the
JdkFilters file when I get back to my computer in Switzerland. :)

Kind regards,
Marcus

On Mon, May 27, 2019 at 11:55 AM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>
> Hi Marcus,
>
> I think the proposed change looks good, even though there are a few
> formatting/whitespace changes in there as well. The JdkFilters file also
> seems to be included without any changes somehow?
>
>
> Regards,
> Henrik Dafg?rd
>
>
> On Sat, 25 May 2019 at 01:38, Marcus Hirt <marcus at hirt.se> wrote:
>
> > Hi all,
> >
> > Please review this fix to add simple visualization of loaded native
> > libraries.
> >
> > Also fixes some other annoyances:
> > . Environment variables should be sorted on key by default.
> > . System properties should be sorted on key by default.
> > . It should be okay to have a query with both attributes and aggregators to
> > fuel
> >   the DistinctItemsPage.
> > . Some unused imports.
> >
> > Jira:   https://bugs.openjdk.java.net/browse/JMC-3338
> > Webrev: http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.0/
> >
> > Kind regards,
> > Marcus
> >
> >
> >

From marcus at hirt.se  Tue May 28 09:07:44 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Tue, 28 May 2019 09:07:44 +0000
Subject: hg: jmc/jmc7: JMC-6458: Backporting the upgrade to Eclipse 2019-03
Message-ID: <201905280907.x4S97iFI012003@aojmv0008.oracle.com>

Changeset: 9871e02a9e40
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-28 11:05 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/9871e02a9e40

JMC-6458: Backporting the upgrade to Eclipse 2019-03
Reviewed-by: ghb

! application/org.openjdk.jmc.feature.rcp/feature.xml
! application/org.openjdk.jmc.rcp.application/META-INF/MANIFEST.MF
! application/org.openjdk.jmc.rcp.product/jmc.product
! application/uitests/org.openjdk.jmc.browser.uitest/pom.xml
! application/uitests/org.openjdk.jmc.test.jemmy/pom.xml
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/MCInstallation.java
! application/uitests/pom.xml
! pom.xml
+ releng/platform-definitions/platform-definition-2018-12/pom.xml
+ releng/platform-definitions/platform-definition-2019-03/pom.xml
- releng/platform-definitions/platform-definition-oxygen/.project
- releng/platform-definitions/platform-definition-oxygen/platform-definition-oxygen.target
- releng/platform-definitions/platform-definition-oxygen/pom.xml
! releng/platform-definitions/platform-definition-photon/.project
! releng/platform-definitions/pom.xml
! releng/third-party/pom.xml


From marcus at hirt.se  Tue May 28 09:18:56 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 28 May 2019 11:18:56 +0200
Subject: JMC 7.0.0 final testing.
Message-ID: <001501d51536$60605180$2120f480$@hirt.se>

Hi all,

The last changes just went into JMC 7 and final testing is now underway.
Unless something unexpected pops up, what is currently in the jmc7 repo 
(at changeset 128:9871e02a9e40) is what will be tagged as 7.0.0-ga for
the JMC 7.0.0 source release. 

Kind regards,
Marcus


From marcus at hirt.se  Tue May 28 13:42:09 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 28 May 2019 15:42:09 +0200
Subject: Sv: Review request for JMC-3338: Visualization of loaded libraries.
In-Reply-To: <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>
References: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>
 <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>
Message-ID: <003601d5155b$25f18490$71d48db0$@hirt.se>

Hi Henrik,

Reverted the accidental whitespace-change to JdkFilters:
http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.1/ 

Kind regards,

Marcus

 

Fr?n: Henrik Dafg?rd <hdafgard at gmail.com> 
Skickat: den 27 maj 2019 11:55
Till: Marcus Hirt <marcus at hirt.se>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: Review request for JMC-3338: Visualization of loaded libraries.

 

Hi Marcus,

 

I think the proposed change looks good, even though there are a few formatting/whitespace changes in there as well. The JdkFilters file also seems to be included without any changes somehow?

 




Regards,

Henrik Dafg?rd

 

 

On Sat, 25 May 2019 at 01:38, Marcus Hirt <marcus at hirt.se <mailto:marcus at hirt.se> > wrote:

Hi all,

Please review this fix to add simple visualization of loaded native libraries.

Also fixes some other annoyances:
. Environment variables should be sorted on key by default.
. System properties should be sorted on key by default.
. It should be okay to have a query with both attributes and aggregators to
fuel 
  the DistinctItemsPage.
. Some unused imports.

Jira:   https://bugs.openjdk.java.net/browse/JMC-3338
Webrev: http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.0/

Kind regards,
Marcus




From carusso at redhat.com  Tue May 28 14:14:50 2019
From: carusso at redhat.com (Carmine Vincenzo Russo)
Date: Tue, 28 May 2019 16:14:50 +0200
Subject: RFC: JMC-5657: Code coverage with Jacoco
In-Reply-To: <CAOsn=koFf-sN22Ma_JFNS7Z1y=cHgV_8V-CqCn8x5OEdFjh5Og@mail.gmail.com>
References: <CAA6KdKcBcyHmPU4hoky8D=qMV9yO8UWWgbKcKTuBv2S_CqRHRw@mail.gmail.com>
 <B17AB67E-5845-47B1-9B3D-4415642A7957@oracle.com>
 <CAA6KdKdQRBkY_2dxVNO45=6oCzNbqs_GXEkmR5ZOA4ZxEtuvJA@mail.gmail.com>
 <CAOsn=kr2MBUobCMy4jVJA+Lger4kNec3R=wN_dufRHxq-nShuQ@mail.gmail.com>
 <CAOsn=koFf-sN22Ma_JFNS7Z1y=cHgV_8V-CqCn8x5OEdFjh5Og@mail.gmail.com>
Message-ID: <CAA6KdKdW1++=5-xn_LgPBEgCCMReMZMEK_TtV0Oi498WYaxbHw@mail.gmail.com>

Hi everyone,

I took sometimes to fix all the issues, here is the update patch:
http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.02/

I  have made some comments inline, but for a easier reading here's a
summarized version of everything in the patch:
- Two new pom.xml: ~/jmc/core/coverage/pom.xml and
~/jmc/application/coverage/pom.xml
- ~/jmc/core/coverage/pom.xml gets executed during the *mvn clean install*
step to build JMC itself
- ~/jmc/application/coverage/pom.xml gets executed both with *mvn verify*
and *mvn verify -P uitests*
- If you run just *mvn verify* the coverage will only show the percentage
for ~/jmc/application/tests, while if you run *mvn verify -P uitests *the
coverage will show both the percentage in ~/jmc/application/tests and
~/jmc/application/uitests in the same report.
- All the modules in ~/jmc/applicatin/tests and ~/jmc/application/uitests
are dependencies in ~/jmc/application/coverage/pom.xml
- To make sure that everything works fine, the profile *uitests* is also in
~/jmc/application/coverage/pom.xml, this way the modules from
~/jmc/application/uitests get loaded only when the profile uitests is
executed
- Both .gitignore and .hgignore got updated to avoid
~/jmc/*/coverage/coverage-report
- In ~/jmc/application/pom.xml all the modules are uncommented and working
now
- Every unrelated and useless comment has been removed


>>> On Tue, May 7, 2019 at 6:38 PM Guru <guru.hb at oracle.com> wrote:
>>>
>>> > Hi Carmine,
>>> >
>>> > Please check my comments inline.
>>> >
>>> > Thanks,
>>> > Guru
>>> > > On 07-May-2019, at 2:05 PM, Carmine Vincenzo Russo <
>>> carusso at redhat.com>
>>> > wrote:
>>> > >
>>> > > Hello everyone,
>>> > >
>>> > > This patch adds Jacoco coverage over unit test in JMC.
>>> > > The module covered in particular are: /core/tests and
>>> /application/tests.
>>> > >
>>> > > The patch addresses the issue JMC-5657[0], but as noted by Klara
>>> Ward[1],
>>> > > instead of adding Jcov, it's better to add Jacoco.
>>> > >
>>> > > For the time being, each test group had a new module, report, where
>>> an
>>> > > aggregate-report can be found.
>>> > > You need to run 'mvn verify' in jmc root for /application/tests and
>>> in
>>> > > /core for /core/tests to have the coverage report.
>>> > Logically there are three build step
>>> > 1. For releng
>>> > 2. Core modules
>>> > 3. Jmc product (i.e Application)
>>> > Ideally `mvn verify` is run on ~/jmc/core (for step 2) and ~/jmc (for
>>> step
>>> > 3).
>>>
>>>
>>> Obviously all the 3 steps are needed, I also checked, the 'mvn verify'
>>> for
>>> ~/jmc/core is automatically done while building the core modules on step
>>> 2.
>>> For jmc product you still need to run 'mvn verify -P uitests' separately
>>> after building the project since you need the test to be executed.
>>>
>>> Unless there is restriction on defining Jacoco in root of
>>> > ~/jmc/core/pom.xml and ~/jmc/pom.xml.
>>> >
>>>
>>> I explain this at the end.
>>>
>>>
>>> > > There are also some aspects that concern me, so: Is this what we are
>>> > > looking for?
>>> > > The report for /core[2] looks good and clean. The report for
>>> > > /application/tests[3][4] has good results, although there are some
>>> 0%,
>>> > and
>>> > > that is ok, but also some N/A. Should we keep the modules in the
>>> report
>>> > > with only N/A?
>>> > >
>>> > > There are also some changes in /application/uitests when reading the
>>> > patch,
>>> > > they are not yet applied but I would like to add them to the next
>>> patch.
>>> > Please file a follow on new JBS and link with old one (relates to
>>> > JMC-5667).
>>> >
>>>
>>> With 'next patch' I just meant the updated patch after the RFC, basically
>>> what I have done now, just wanted to have your opinions before going
>>> forward with the ~/uitests coverage. If a follow up issue is needed, I'll
>>> ask Alex to open it.
>>>
>>>
>>> > > This brings me to my second concern: should the tests and uitests in
>>> > > /application have a unique report or should I keep them separate?
>>> > Good to have Unique rather than separate.
>>> >
>>>
>>> In the new patch attached ~/jmc/application/tests and
>>> ~/jmc/applciation/uitests have a unique coverage in
>>> ~/jmc/application/coverage.
>>>
>>
With Alex's help, I found out there was a problem with having directly a
unique coverage report for both ~/jmc/application/tests and
~/jmc/application/uitests.
Because of this now we still have a unique report generated with
~/jmc/application/coverage/pom.xml but inside there is a profile *uitests*.
This way all the dependencies needed for the uitests are only considered
when the uitests are executed. Meanwhile with a simple *mvn verify* you get
the coverage only for ~/jmc/application/tests.


> > > Lastly, do we want coverage with every verify build or do we want a
>>> maven
>>> > > profile/flag to have the coverage only in some occasions?
>>> > This could be based on how much time Jacoco Code coverage takes. If its
>>> > negligible then good to have on every verify build or with a
>>> profile/flag.
>>> >
>>>
>>> In all my tests and attempts the module itself never took more than 10s,
>>> while the build doesn't seem to be affected. So basically I don't think
>>> it's a problem to have always the coverage in every build.
>>>
>>
>> I took a quick look into this and ran `mvn verify` locally with and
>> without the coverage patch, I saw:
>>
>> With Coverage:
>> core - 1 minute 17 seconds
>> jmc - 8 minutes 51 seconds
>>
>> Without Coverage:
>> core - 1 minute 3 seconds
>> jmc - 8 minutes 23 seconds
>>
>>
>>>
>>> > > Overall, how does the patch look like? Do you think there are some
>>> more
>>> > > modules that need to be covered? And do you have any suggestions on
>>> how
>>> > to
>>> > > improve what I've done?
>>> > If possible, please update the patch to ~/jmc/core/pom.xml and
>>> > ~/jmc/pom.xml.
>>> >
>>>
>>> As far as my knowledge goes, to have the report, we need a separate
>>> pom.xml
>>> for the report, this because the report-aggregate[0] relies on
>>> <dependency>
>>> and not on <module>, even the JaCoCo examples for this have their own
>>> report module[1]. The best way, I think, is the current situation in
>>> which
>>> we have ~/jmc/core/coverage/pom.xml and
>>> ~/jmc/application/coverage/pom.xml,
>>> these generate and contains the coverage report, while in
>>> ~/jmc/core/pom.xml and ~/jmc/application/pom.xml we have the JaCoCo agent
>>> that makes the coverage possible. If we try to move everything in
>>> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml the reports will be
>>> segregated in their own modules. Or if we try to move part of it in
>>> ~/jmc/pom.xml we stiil need to have both the agent configuration in
>>> ~/jmc/application/pom.xml and ~/jmc/core/pom.xml and the coverage as
>>> separate modules.
>>>
>>
>> The aggregation of the coverage reports looks like it will require it's
>> own pom.xml, as exemplified in a sample demo from the JaCoCo github.
>>
>> https://github.com/jacoco/jacoco/tree/v0.7.8/jacoco-maven-plugin.test/it/it-report-aggregate
>>
>>
>>>
>>> All the changes and the new addition can be found here:
>>> http://cr.openjdk.java.net/~aptmac/JMC-5657/webrev.01/
>>>
>>
>> core/tests/pom.xml
>> - <module>report</module> is commented out
>>
>
All useless and unrelated comment have been removed or fixed to make
everything works.


>
>> Overall I think the patch looks good. I would however like to see the
>> .hgignore and .gitignore updated to exclude the coverage reports; there are
>> a lot of files generated in */coverage/coverage-report/*.
>>
>
Both .gitignore and .hgignore got updated to ignore
~/jmc/*/coverage/coverage-report/


>
> Whoops, spoke a tad too soon.
>
> It's having difficulties at the moment when running uitests.
> https://travis-ci.org/aptmac/jmc-qa/builds/535820411
>

Apparently this was because of some reference to the old name *uireport*
still around that I didn't notice, it's been taken care of now.


> There's also comments in the application/coverage/pom.xml for the update
> sites and RCP product.
>

All the modules now are uncommented and working, for these three an
additional tag was needed because those repositories only have pom files
and not jar files.


Thanks,
Carmine


-- 
Carmine Vincenzo Russo

From jkang at redhat.com  Tue May 28 17:19:39 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 28 May 2019 13:19:39 -0400
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <ab7b4523-479b-86b5-fe90-3c9930bbb5e4@redhat.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
 <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
 <CAOpWGx1JnM65WQ-wwGaGFUH7xVoc=9o_+u-PiJCqp1CmUMx2Hg@mail.gmail.com>
 <ab7b4523-479b-86b5-fe90-3c9930bbb5e4@redhat.com>
Message-ID: <CAEBeOcq7=XMifUMN0hqbNDeTcL7bA-7B1gTS1fkaYPZJrX732w@mail.gmail.com>

On Mon, May 27, 2019 at 12:10 PM Elliott Baron <ebaron at redhat.com> wrote:
>
> Hi Marcus,
>
> On 2019-05-24 3:13 p.m., Marcus Hirt wrote:
> > Very nice Elliot! This looks great!
>
> Glad to hear it, thanks!
>
> > How sure are you of the Japanese and
> > Chinese translations? Would you want for someone to take a look at them?
>
> These come from substituting the word for "percentile" (found online)
> into existing localized strings with the same sort of desired phrasing
> (e.g. File I/O Histogram Selection). If there is someone who could
> verify/improve the translations, I would appreciate it.

Hi Elliott,

For what it's worth, I asked a native Chinese speaker to look at the
Chinese translations without knowledge of the English ones and he says
they make sense and was also able to translate them to what was
written in English.


Regards,


>
> Thanks,
> Elliott
>
> >
> > Kind regards,
> > Marcus
> >
> > On Fri, May 24, 2019 at 1:06 AM Elliott Baron <ebaron at redhat.com
> > <mailto:ebaron at redhat.com>> wrote:
> >
> >     Hi,
> >
> >     Sorry for the delay. Thank you both for your reviews!
> >
> >     On 2019-05-02 12:55 p.m., Alex Macdonald wrote:
> >      > A handful of minor formatting nits:
> >      >
> >      > - Messages.properties (x3)
> >      > - - the DurationPercentileTable_PERCENTILE_COL_NAME should come
> >     after
> >      > DUMP_RECORDING_* for alphabetical order I believe
> >
> >     Should be fixed now. I took this into account for the new keys added in
> >     this revision too.
> >
> >      > - There are some cases of extra whitespace, I went through hg
> >     diff and
> >      > counted the following number of occurrences:
> >      > - - DurationHdrHistogram (8)
> >      > - - DurationPercentileTable (38)
> >      > - - FileIOPage (5)
> >      > - - SocketIOPage (6)
> >      > - - IOPageTest (5)
> >      > - - IOPageTestBase (4)
> >      > - - SocketIOPageTest(5)
> >
> >     This revised patch should not have any trailing whitespace.
> >
> >      > I noticed that when resizing the page, the durations table stays
> >     static
> >      > whereas the other tables seems to adjust (gif) [3]. This only
> >     seems to
> >      > cause an issue when my JMC window gets resized to just under 50%
> >     on my
> >      > monitor width, and the chart will get hidden. In the gif my JMC
> >     window
> >      > is around half my monitor width (of 1920), and with the JVM
> >      > Browser/Outline window open then I don't have much more room to
> >     shrink
> >      > the application before the chart disappears. I was just curious
> >     if the
> >      > table could adjust to resizing like the other tables.
> >
> >     This was a bit tricky due to the table sitting side-by-side with the
> >     chart. I used the (unused?) SimpleLayout class within JMC to define
> >     weights to keep the percentage of the width occupied by the chart and
> >     table constant, even while resizing.
> >
> >      > Also not caused by this patch (but thought it'd be interesting to
> >      > share), I'm seeing a bug where my chart text gets really large
> >     [4] when
> >      > I run JMC locally and not as an RCP application (I recall seeing
> >     a JIRA
> >      > bug for this before, but cannot find it), and my durations tab
> >     will only
> >      > show the table (and not even the whole thing) [5].
> >     I am still seeing this as well.
> >
> >     On 2019-05-02 3:02 p.m., Marcus Hirt wrote:
> >      > This is a great start! Aside from the comments already provided
> >     by Alex,
> >      > here is some feedback:
> >      >
> >      > * It would be great to be able to select a percentile and be able
> >     to do
> >      > set as focused selection, and add the events for that percentile
> >     to the
> >      > focused selection.
> >
> >     This should be working now. When setting a table row as the focused
> >     selection, all events with duration at least as long as the percentile
> >     values in that row will be selected.
> >
> >     e.g. Setting the 99th percentile row as the focused selection, with
> >     read
> >     duration of 10ms and write duration of 50ms, will only show read events
> >       >= 10ms and write events >= 50ms.
> >
> >      > * The current UI splits read and writes in two different lanes,
> >     perhaps
> >      > that would make sense here too, also for selection purposes. And
> >     just as
> >      > with the lanes, only show when there is available data.
> >
> >     With this revised patch, when there are no matching read or write
> >     events, the corresponding columns will not be shown. There is a slight
> >     issue when columns are hidden and then reappear, the last column is too
> >     large and needs be resized manually. I can reproduce this in other
> >     tables by hiding two columns, and restoring them. I'm not sure of
> >     the cause.
> >
> >      > * Perhaps the counts shown should be the number of events in the
> >      > percentile or above, as those would be the number of events
> >     selected -
> >      > i.e. if you select events in the 99.9 percentile, you probably don't
> >      > want all of the events up to and including the ones in the 99.9th
> >      > percentile, but rather the outliers, the ones in 99.9 and above.
> >
> >     Makes sense to me, the event counts now show events with duration
> >     greater or equal to the value in that row.
> >
> >      > * It would be cool to add a normalized backdrop in the tables to
> >     get a
> >      > rough visual representation of how many of the events are
> >     actually in
> >      > the different buckets.
> >
> >     I have added this as well.
> >
> >     Here is a revised webrev that should address all of the feedback
> >     received so far.
> >
> >     Bug: https://bugs.openjdk.java.net/browse/JMC-5327
> >     Webrev: http://cr.openjdk.java.net/~ebaron/JMC-5327/webrev.0/
> >     Preview: https://imgur.com/a/oqX0fai
> >
> >     Thanks,
> >     Elliott
> >

From jkang at redhat.com  Tue May 28 18:28:40 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 28 May 2019 14:28:40 -0400
Subject: Review request for JMC-3338: Visualization of loaded libraries.
In-Reply-To: <003601d5155b$25f18490$71d48db0$@hirt.se>
References: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>
 <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>
 <003601d5155b$25f18490$71d48db0$@hirt.se>
Message-ID: <CAEBeOcp3DkUvKuX7ci444QWQgr-g1WPTwVu=830tHkJ5Q-=j7g@mail.gmail.com>

Hi Marcus,

The changes look okay to me and also worked for me on Fedora. Though
the code is very straightforward, I was wondering what the standard is
for testing functionality like this? Do any of the UI tests cover this
page or the other pages?


Regards,

On Tue, May 28, 2019 at 9:42 AM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi Henrik,
>
> Reverted the accidental whitespace-change to JdkFilters:
> http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.1/
>
> Kind regards,
>
> Marcus
>
>
>
> Fr?n: Henrik Dafg?rd <hdafgard at gmail.com>
> Skickat: den 27 maj 2019 11:55
> Till: Marcus Hirt <marcus at hirt.se>
> Kopia: jmc-dev at openjdk.java.net
> ?mne: Re: Review request for JMC-3338: Visualization of loaded libraries.
>
>
>
> Hi Marcus,
>
>
>
> I think the proposed change looks good, even though there are a few formatting/whitespace changes in there as well. The JdkFilters file also seems to be included without any changes somehow?
>
>
>
>
>
>
> Regards,
>
> Henrik Dafg?rd
>
>
>
>
>
> On Sat, 25 May 2019 at 01:38, Marcus Hirt <marcus at hirt.se <mailto:marcus at hirt.se> > wrote:
>
> Hi all,
>
> Please review this fix to add simple visualization of loaded native libraries.
>
> Also fixes some other annoyances:
> . Environment variables should be sorted on key by default.
> . System properties should be sorted on key by default.
> . It should be okay to have a query with both attributes and aggregators to
> fuel
>   the DistinctItemsPage.
> . Some unused imports.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-3338
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.0/
>
> Kind regards,
> Marcus
>
>
>

From kxu at redhat.com  Tue May 28 20:02:37 2019
From: kxu at redhat.com (Kangcheng Xu)
Date: Tue, 28 May 2019 16:02:37 -0400
Subject: [PATCH] JMC-6252 Method profiling rules loading forever
Message-ID: <CA+tA26unXEPCMLdU3XCmQBu3LxCOoD0k0NfqOdjCT_FYxWnwTQ@mail.gmail.com>

Hello,

This patch fixes JMC-6252 Method Profiling rule appears to be taking
forever to evaluate in Ubuntu 18.04 [0]. (Please note this issue is
general and appears on all platforms.)

This patch addresses two problems found in the source code:
1. The order of JavaScript command execution to update HTML-based UI
could be stochastic if fired before DOM loaded. Commands executed as
ProgressListener callbacks could be out-of-order. The solution is to
store commands in a queue and execute in a FIFO fashion after DOM is
loaded.
2. resultEventQueue.isEmpty() and resultEventQueue.add() together is
not an atomic operation and could be interrupted in rare cases, which
leads to resultEventQueue not being completely consumed.

Please see the attached patch. Any thoughts on this fix? Thanks very much!

Arvin Kangcheng Xu

[0]
https://bugs.openjdk.java.net/browse/JMC-6252
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmc-6252.patch
Type: text/x-patch
Size: 7206 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190528/8fc59a98/jmc-6252-0001.patch>

From ebaron at redhat.com  Tue May 28 20:44:02 2019
From: ebaron at redhat.com (Elliott Baron)
Date: Tue, 28 May 2019 16:44:02 -0400
Subject: RFR: JMC-5327: Using HdrHistograms to visualize latencies
In-Reply-To: <CAEBeOcq7=XMifUMN0hqbNDeTcL7bA-7B1gTS1fkaYPZJrX732w@mail.gmail.com>
References: <15cbce67-a4d4-9ce5-9265-3a10ef4566fa@redhat.com>
 <CAOpWGx3gs4=gEBw6tWDeUpPNMFn=_=iLSOkUuZYjF0JmX=k8mA@mail.gmail.com>
 <1fe8954a-3ad2-4896-1423-bd8eeab4c529@redhat.com>
 <CAOpWGx1JnM65WQ-wwGaGFUH7xVoc=9o_+u-PiJCqp1CmUMx2Hg@mail.gmail.com>
 <ab7b4523-479b-86b5-fe90-3c9930bbb5e4@redhat.com>
 <CAEBeOcq7=XMifUMN0hqbNDeTcL7bA-7B1gTS1fkaYPZJrX732w@mail.gmail.com>
Message-ID: <9b21f326-e917-29b9-125e-05ebd9591e92@redhat.com>

Hi Jie,

On 2019-05-28 1:19 p.m., Jie Kang wrote:
> On Mon, May 27, 2019 at 12:10 PM Elliott Baron <ebaron at redhat.com> wrote:
>>
>> Hi Marcus,
>>
>> On 2019-05-24 3:13 p.m., Marcus Hirt wrote:
>>> Very nice Elliot! This looks great!
>>
>> Glad to hear it, thanks!
>>
>>> How sure are you of the Japanese and
>>> Chinese translations? Would you want for someone to take a look at them?
>>
>> These come from substituting the word for "percentile" (found online)
>> into existing localized strings with the same sort of desired phrasing
>> (e.g. File I/O Histogram Selection). If there is someone who could
>> verify/improve the translations, I would appreciate it.
> 
> Hi Elliott,
> 
> For what it's worth, I asked a native Chinese speaker to look at the
> Chinese translations without knowledge of the English ones and he says
> they make sense and was also able to translate them to what was
> written in English.
> 

That's good to hear. Thanks for your help!

Elliott

From hdafgard at gmail.com  Wed May 29 13:06:51 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Wed, 29 May 2019 15:06:51 +0200
Subject: [PATCH] JMC-6252 Method profiling rules loading forever
In-Reply-To: <CA+tA26unXEPCMLdU3XCmQBu3LxCOoD0k0NfqOdjCT_FYxWnwTQ@mail.gmail.com>
References: <CA+tA26unXEPCMLdU3XCmQBu3LxCOoD0k0NfqOdjCT_FYxWnwTQ@mail.gmail.com>
Message-ID: <CADFkdVQatn+fFYvCuzTb75F_cPREPocJN5ZSs4z18SJObji8yg@mail.gmail.com>

Hi,

The patch looks great and solves a long-standing and annoying issue!

However, since the check for whether or not the browser widget was disposed
has been removed there will be exceptions thrown if the user navigates away
while updates are being applied. This could be solved by e.g. checking
whether or not the browser is disposed inside of the catch clause in the
cmdExecRunnable lambda. We might also consider changing the inner catch
clause to no longer catch all exceptions (or at least avoid catching any
RuntimeException thrown).


Regards,
Henrik Dafg?rd


On Tue, 28 May 2019 at 22:03, Kangcheng Xu <kxu at redhat.com> wrote:

> Hello,
>
> This patch fixes JMC-6252 Method Profiling rule appears to be taking
> forever to evaluate in Ubuntu 18.04 [0]. (Please note this issue is
> general and appears on all platforms.)
>
> This patch addresses two problems found in the source code:
> 1. The order of JavaScript command execution to update HTML-based UI
> could be stochastic if fired before DOM loaded. Commands executed as
> ProgressListener callbacks could be out-of-order. The solution is to
> store commands in a queue and execute in a FIFO fashion after DOM is
> loaded.
> 2. resultEventQueue.isEmpty() and resultEventQueue.add() together is
> not an atomic operation and could be interrupted in rare cases, which
> leads to resultEventQueue not being completely consumed.
>
> Please see the attached patch. Any thoughts on this fix? Thanks very much!
>
> Arvin Kangcheng Xu
>
> [0]
> https://bugs.openjdk.java.net/browse/JMC-6252
>

From jkang at redhat.com  Wed May 29 13:36:05 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 29 May 2019 09:36:05 -0400
Subject: Review request for JMC-6492: Add unit support for jdk.jfr.Frequency
Message-ID: <CAEBeOcqkOn7HsTLWhQfCr1c3ZrdjJzDsODrFXzk7t7BTrnuVNw@mail.gmail.com>

Hi,

The attached patch adds a case for contentType "hertz",  annotation
"jdk.jfr.Frequency" used in JFR events like CPUTimeStampCounter, to
use the Hertz unit introduced in JMC-5768.

The following is a before and after image for the event browser for
CPUTimeStampCounter
https://imgur.com/a/cSVlmOM

How does it look?


Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmc-6492.patch
Type: text/x-patch
Size: 1377 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190529/7a6a6b06/jmc-6492.patch>

From hdafgard at gmail.com  Wed May 29 14:10:48 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Wed, 29 May 2019 16:10:48 +0200
Subject: [PATCH] JMC-6252 Method profiling rules loading forever
In-Reply-To: <CA+tA26vvMsruSR66VM6Dd-w-zaiMBGGrmGx0JFCSiNXa1-=RVQ@mail.gmail.com>
References: <CA+tA26unXEPCMLdU3XCmQBu3LxCOoD0k0NfqOdjCT_FYxWnwTQ@mail.gmail.com>
 <CADFkdVQatn+fFYvCuzTb75F_cPREPocJN5ZSs4z18SJObji8yg@mail.gmail.com>
 <CA+tA26vvMsruSR66VM6Dd-w-zaiMBGGrmGx0JFCSiNXa1-=RVQ@mail.gmail.com>
Message-ID: <CADFkdVRsvZBSLwB05eMdiST0OAX7VBXRvRCOzO=SCBvNsyV69g@mail.gmail.com>

No worries, that's what the review process is there for! I think this looks
good and is ready to ship.


Regards,
Henrik Dafg?rd


On Wed, 29 May 2019 at 15:47, Kangcheng Xu <kxu at redhat.com> wrote:

> Hi Henrik,
>
> Thanks for the suggestions.
>
> On Wed, May 29, 2019 at 9:07 AM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
> >
> > Hi,
> >
> > The patch looks great and solves a long-standing and annoying issue!
> >
> > However, since the check for whether or not the browser widget was
> disposed has been removed there will be exceptions thrown if the user
> navigates away while updates are being applied. This could be solved by
> e.g. checking whether or not the browser is disposed inside of the catch
> clause in the cmdExecRunnable lambda.
>
> The cmdExecRunnabe lambda has been updated to include a check for
> browser.isDisposed(). Sorry for making such an obvious mistake.
>
> > We might also consider changing the inner catch clause to no longer
> catch all exceptions (or at least avoid catching any RuntimeException
> thrown).
>
> The original code catches generic exceptions, so I didn't change this
> is. However, I do agree with you, the inner catch-clause now only
> catches IOException.
>
> >
> >
> > Regards,
> > Henrik Dafg?rd
>
> Thank you! Please see the updated patch attached.
>
> Arvin Kangcheng Xu
>
> >
> > On Tue, 28 May 2019 at 22:03, Kangcheng Xu <kxu at redhat.com> wrote:
> >>
> >> Hello,
> >>
> >> This patch fixes JMC-6252 Method Profiling rule appears to be taking
> >> forever to evaluate in Ubuntu 18.04 [0]. (Please note this issue is
> >> general and appears on all platforms.)
> >>
> >> This patch addresses two problems found in the source code:
> >> 1. The order of JavaScript command execution to update HTML-based UI
> >> could be stochastic if fired before DOM loaded. Commands executed as
> >> ProgressListener callbacks could be out-of-order. The solution is to
> >> store commands in a queue and execute in a FIFO fashion after DOM is
> >> loaded.
> >> 2. resultEventQueue.isEmpty() and resultEventQueue.add() together is
> >> not an atomic operation and could be interrupted in rare cases, which
> >> leads to resultEventQueue not being completely consumed.
> >>
> >> Please see the attached patch. Any thoughts on this fix? Thanks very
> much!
> >>
> >> Arvin Kangcheng Xu
> >>
> >> [0]
> >> https://bugs.openjdk.java.net/browse/JMC-6252
>

From marcus at hirt.se  Wed May 29 19:57:46 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Wed, 29 May 2019 19:57:46 +0000
Subject: hg: jmc/jmc7: Added tag 7.0.0-gac for changeset 9871e02a9e40
Message-ID: <201905291957.x4TJvk2o014684@aojmv0008.oracle.com>

Changeset: dc75a2634a25
Author:    hirt <marcus.hirt at datadoghq.com>
Date:      2019-05-29 21:55 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/dc75a2634a25

Added tag 7.0.0-gac for changeset 9871e02a9e40

+ .hgtags


From marcus at hirt.se  Thu May 30 00:59:22 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Thu, 30 May 2019 02:59:22 +0200
Subject: Sv: Review request for JMC-3338: Visualization of loaded libraries.
In-Reply-To: <CAEBeOcp3DkUvKuX7ci444QWQgr-g1WPTwVu=830tHkJ5Q-=j7g@mail.gmail.com>
References: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>
 <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>
 <003601d5155b$25f18490$71d48db0$@hirt.se>
 <CAEBeOcp3DkUvKuX7ci444QWQgr-g1WPTwVu=830tHkJ5Q-=j7g@mail.gmail.com>
Message-ID: <058201d51682$eb5603a0$c2020ae0$@hirt.se>

Hi Jie,

UI testing for individual JFR pages is a bit lacking. 
Some of the more complex ones do have UI-tests, and
some of the more central views, such as the stack trace
view and controlling recordings. The UI tests also walk 
through the pages repeatedly to see if there is
any memory leak.

I've updated the JfrUi class so that it will at least 
load and show the page as part of the memory leak hunt. 

http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.2/

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: Jie Kang <jkang at redhat.com> 
Skickat: den 28 maj 2019 20:29
Till: Marcus Hirt <marcus at hirt.se>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: Review request for JMC-3338: Visualization of loaded libraries.

Hi Marcus,

The changes look okay to me and also worked for me on Fedora. Though the code is very straightforward, I was wondering what the standard is for testing functionality like this? Do any of the UI tests cover this page or the other pages?


Regards,

On Tue, May 28, 2019 at 9:42 AM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi Henrik,
>
> Reverted the accidental whitespace-change to JdkFilters:
> http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.1/
>
> Kind regards,
>
> Marcus
>
>
>
> Fr?n: Henrik Dafg?rd <hdafgard at gmail.com>
> Skickat: den 27 maj 2019 11:55
> Till: Marcus Hirt <marcus at hirt.se>
> Kopia: jmc-dev at openjdk.java.net
> ?mne: Re: Review request for JMC-3338: Visualization of loaded libraries.
>
>
>
> Hi Marcus,
>
>
>
> I think the proposed change looks good, even though there are a few formatting/whitespace changes in there as well. The JdkFilters file also seems to be included without any changes somehow?
>
>
>
>
>
>
> Regards,
>
> Henrik Dafg?rd
>
>
>
>
>
> On Sat, 25 May 2019 at 01:38, Marcus Hirt <marcus at hirt.se <mailto:marcus at hirt.se> > wrote:
>
> Hi all,
>
> Please review this fix to add simple visualization of loaded native libraries.
>
> Also fixes some other annoyances:
> . Environment variables should be sorted on key by default.
> . System properties should be sorted on key by default.
> . It should be okay to have a query with both attributes and 
> aggregators to fuel
>   the DistinctItemsPage.
> . Some unused imports.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-3338
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.0/
>
> Kind regards,
> Marcus
>
>
>


From jkang at redhat.com  Thu May 30 15:37:21 2019
From: jkang at redhat.com (Jie Kang)
Date: Thu, 30 May 2019 11:37:21 -0400
Subject: Review request for JMC-3338: Visualization of loaded libraries.
In-Reply-To: <058201d51682$eb5603a0$c2020ae0$@hirt.se>
References: <0a1b01d51289$aaffad80$00ff0880$@hirt.se>
 <CADFkdVQgELe5OJxgCgPCM4R3BB8bH9SctqrSSJ39u9NA+VNmSA@mail.gmail.com>
 <003601d5155b$25f18490$71d48db0$@hirt.se>
 <CAEBeOcp3DkUvKuX7ci444QWQgr-g1WPTwVu=830tHkJ5Q-=j7g@mail.gmail.com>
 <058201d51682$eb5603a0$c2020ae0$@hirt.se>
Message-ID: <CAEBeOconmW1zvhcu7tpT_w6u__i1kLxtg1O3spHYaDfnT=PQXA@mail.gmail.com>

On Wed, May 29, 2019 at 9:07 PM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi Jie,
>
> UI testing for individual JFR pages is a bit lacking.
> Some of the more complex ones do have UI-tests, and
> some of the more central views, such as the stack trace
> view and controlling recordings. The UI tests also walk
> through the pages repeatedly to see if there is
> any memory leak.
>
> I've updated the JfrUi class so that it will at least
> load and show the page as part of the memory leak hunt.
>
> http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.2/

Neat, thanks! This looks fine to me.


Regards,

>
> Kind regards,
> Marcus
>
> -----Ursprungligt meddelande-----
> Fr?n: Jie Kang <jkang at redhat.com>
> Skickat: den 28 maj 2019 20:29
> Till: Marcus Hirt <marcus at hirt.se>
> Kopia: jmc-dev at openjdk.java.net
> ?mne: Re: Review request for JMC-3338: Visualization of loaded libraries.
>
> Hi Marcus,
>
> The changes look okay to me and also worked for me on Fedora. Though the code is very straightforward, I was wondering what the standard is for testing functionality like this? Do any of the UI tests cover this page or the other pages?
>
>
> Regards,
>
> On Tue, May 28, 2019 at 9:42 AM Marcus Hirt <marcus at hirt.se> wrote:
> >
> > Hi Henrik,
> >
> > Reverted the accidental whitespace-change to JdkFilters:
> > http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.1/
> >
> > Kind regards,
> >
> > Marcus
> >
> >
> >
> > Fr?n: Henrik Dafg?rd <hdafgard at gmail.com>
> > Skickat: den 27 maj 2019 11:55
> > Till: Marcus Hirt <marcus at hirt.se>
> > Kopia: jmc-dev at openjdk.java.net
> > ?mne: Re: Review request for JMC-3338: Visualization of loaded libraries.
> >
> >
> >
> > Hi Marcus,
> >
> >
> >
> > I think the proposed change looks good, even though there are a few formatting/whitespace changes in there as well. The JdkFilters file also seems to be included without any changes somehow?
> >
> >
> >
> >
> >
> >
> > Regards,
> >
> > Henrik Dafg?rd
> >
> >
> >
> >
> >
> > On Sat, 25 May 2019 at 01:38, Marcus Hirt <marcus at hirt.se <mailto:marcus at hirt.se> > wrote:
> >
> > Hi all,
> >
> > Please review this fix to add simple visualization of loaded native libraries.
> >
> > Also fixes some other annoyances:
> > . Environment variables should be sorted on key by default.
> > . System properties should be sorted on key by default.
> > . It should be okay to have a query with both attributes and
> > aggregators to fuel
> >   the DistinctItemsPage.
> > . Some unused imports.
> >
> > Jira:   https://bugs.openjdk.java.net/browse/JMC-3338
> > Webrev: http://cr.openjdk.java.net/~hirt/JMC-3338/webrev.0/
> >
> > Kind regards,
> > Marcus
> >
> >
> >
>

From jkang at redhat.com  Fri May 31 20:26:31 2019
From: jkang at redhat.com (Jie Kang)
Date: Fri, 31 May 2019 16:26:31 -0400
Subject: JMC 7.0.0 final testing.
In-Reply-To: <001501d51536$60605180$2120f480$@hirt.se>
References: <001501d51536$60605180$2120f480$@hirt.se>
Message-ID: <CAEBeOco-mewhbkajGUTTfPbA5aiJUdJ4nXMCE2EuWkm9DmRsNg@mail.gmail.com>

Hi Marcus,

Thanks for the notice; this looks fine for the packages in Fedora and RHEL.


Regards,


On Tue, May 28, 2019 at 5:19 AM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi all,
>
> The last changes just went into JMC 7 and final testing is now underway.
> Unless something unexpected pops up, what is currently in the jmc7 repo
> (at changeset 128:9871e02a9e40) is what will be tagged as 7.0.0-ga for
> the JMC 7.0.0 source release.
>
> Kind regards,
> Marcus
>

From marcus at hirt.se  Fri May 31 21:26:47 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Fri, 31 May 2019 21:26:47 +0000
Subject: hg: jmc/jmc: JMC-3338: Adds simple visualization of loaded native
 libraries
Message-ID: <201905312126.x4VLQlXj028497@aojmv0008.oracle.com>

Changeset: 9a214341f795
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-05-31 23:26 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/9a214341f795

JMC-3338: Adds simple visualization of loaded native libraries
Summary: Also fixes some other annoyances, like environment variables should be sorted on key by default, system properties should be sorted on key by default, it should be okay to have a quary with both attributes and aggregators to fuel the DistinctItemsPage and removal of some unused imports
Reviewed-by: hdafgard, Jie Kang <jkang at redhat.com>

! application/org.openjdk.jmc.flightrecorder.ui/defaultPages.xml
+ application/org.openjdk.jmc.flightrecorder.ui/icons/pages/nativelibraries.png
+ application/org.openjdk.jmc.flightrecorder.ui/icons/pages/nativelibraries at 2x.png
! application/org.openjdk.jmc.flightrecorder.ui/plugin.xml
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/DataPageToolkit.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ImageConstants.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/EventBrowserPage.java
+ application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/NativeLibraryPage.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrUi.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/BiasedLockingRevocationRule.java
! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/JfrRuleTopics.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkQueries.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkTypeIDs.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/messages/internal/Messages.java
! core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/jdk/messages/internal/messages.properties


From marcus at hirt.se  Fri May 31 21:34:00 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 31 May 2019 23:34:00 +0200
Subject: Sv: JMC 7.0.0 final testing.
In-Reply-To: <CAEBeOco-mewhbkajGUTTfPbA5aiJUdJ4nXMCE2EuWkm9DmRsNg@mail.gmail.com>
References: <001501d51536$60605180$2120f480$@hirt.se>
 <CAEBeOco-mewhbkajGUTTfPbA5aiJUdJ4nXMCE2EuWkm9DmRsNg@mail.gmail.com>
Message-ID: <000e01d517f8$8f8b3190$aea194b0$@hirt.se>

Thank you for the feedback Jie!

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: Jie Kang <jkang at redhat.com> 
Skickat: den 31 maj 2019 22:27
Till: Marcus Hirt <marcus at hirt.se>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: JMC 7.0.0 final testing.

Hi Marcus,

Thanks for the notice; this looks fine for the packages in Fedora and RHEL.


Regards,


On Tue, May 28, 2019 at 5:19 AM Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi all,
>
> The last changes just went into JMC 7 and final testing is now underway.
> Unless something unexpected pops up, what is currently in the jmc7 
> repo (at changeset 128:9871e02a9e40) is what will be tagged as 
> 7.0.0-ga for the JMC 7.0.0 source release.
>
> Kind regards,
> Marcus
>