From kdobson at redhat.com  Mon Apr  1 23:13:12 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Mon, 1 Apr 2019 19:13:12 -0400
Subject: Review Request for JMC-4469: Adding a page from the properties view
Message-ID: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>

Hi all,
please review this patch for JMC-4469 to allow for adding a page with the
events selected in the property view.

bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4469
webrev: http://cr.openjdk.java.net/~kdobson/addpagefromproperties/webrev/

Thanks,

Ken Dobson

From marcus.hirt at datadoghq.com  Tue Apr  2 01:43:47 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 1 Apr 2019 21:43:47 -0400
Subject: Review Request for JMC-4469: Adding a page from the properties
 view
In-Reply-To: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>
References: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>
Message-ID: <CAOpWGx3u0p-SwNevwHXcMrKj=KFRixSV1cLE35XNEkotHuSBkQ@mail.gmail.com>

Hi Ken!

There are some trailing spaces that should be removed, but other than that
it looks good!

Kind regards,
Marcus

On Mon, Apr 1, 2019 at 7:14 PM Ken Dobson <kdobson at redhat.com> wrote:

> Hi all,
> please review this patch for JMC-4469 to allow for adding a page with the
> events selected in the property view.
>
> bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4469
> webrev: http://cr.openjdk.java.net/~kdobson/addpagefromproperties/webrev/
>
> Thanks,
>
> Ken Dobson
>

From marcus.hirt at datadoghq.com  Tue Apr  2 01:53:37 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 1 Apr 2019 21:53:37 -0400
Subject: [PATCH] fix-info-plist-maven-plugin now available on Maven Central
In-Reply-To: <0f6fb2693a5074089c4e898703066df1234e9726.camel@unportant.info>
References: <0f6fb2693a5074089c4e898703066df1234e9726.camel@unportant.info>
Message-ID: <CAOpWGx0QXfpCrah9JMWPeUKD2XARvK8M8sftd+B2-KLeQ4gjGw@mail.gmail.com>

A good point!

I'll open a bug and send out a review request!

/M

On Mon, Apr 1, 2019 at 9:37 PM Cl?ment MATHIEU <clement at unportant.info>
wrote:

> Hi,
>
> fix-info-plist-maven-plugin was published on a custom maven repo,
> http://buchen.github.io/maven-repo, requiring to configure a proxy in
> corporate environments (local Maven proxy likely doesn't track this
> repo).
>
> Plugin author just published latest rev on Maven central, see
> https://github.com/buchen/fix-info-plist-maven-plugin/issues/3. I gave
> it a shot and it seems to work. This should make building jmc a bit
> easier. What do you think?
>
>
> Regards,
> Cl?ment MATHIEU
>

From marcus.hirt at datadoghq.com  Tue Apr  2 02:02:08 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 1 Apr 2019 22:02:08 -0400
Subject: Review Request for JMC-6444: Switch to fix-info-plist-maven-plugin 1.5
Message-ID: <CAOpWGx01zvzV_L+AJYLpBYG2DWtDcVxuknNjEqdSv50LgVkd8w@mail.gmail.com>

Hi all,

Please review this fix to switch to fix-info-plist-maven-plugin 1.5

Jira:   https://bugs.openjdk.java.net/browse/JMC-6444
Patch:
diff -r 5b9d72265772 application/org.openjdk.jmc.rcp.product/pom.xml
--- a/application/org.openjdk.jmc.rcp.product/pom.xml   Tue Mar 26 14:11:58
2019 -0400
+++ b/application/org.openjdk.jmc.rcp.product/pom.xml   Mon Apr 01 21:52:34
2019 -0400
@@ -93,7 +93,7 @@
                        <plugin>
                                <groupId>name.abuchen</groupId>

<artifactId>fix-info-plist-maven-plugin</artifactId>
-                               <version>1.2</version>
+                               <version>1.5</version>
                                <executions>
                                        <execution>
                                                <id>fix-info-plist</id>

Kind regards,
Marcus

From guru.hb at oracle.com  Tue Apr  2 05:02:54 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 2 Apr 2019 10:32:54 +0530
Subject: Review Request for JMC-6444: Switch to
 fix-info-plist-maven-plugin 1.5
In-Reply-To: <CAOpWGx01zvzV_L+AJYLpBYG2DWtDcVxuknNjEqdSv50LgVkd8w@mail.gmail.com>
References: <CAOpWGx01zvzV_L+AJYLpBYG2DWtDcVxuknNjEqdSv50LgVkd8w@mail.gmail.com>
Message-ID: <BEDA68A1-AE11-4BD0-9872-FD2689C7F792@oracle.com>

+1, Changes looks good to me, 

Please Wait for the Third party approval to push the changes. 

Thanks,
Guru
> On 02-Apr-2019, at 7:32 AM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> 
> Hi all,
> 
> Please review this fix to switch to fix-info-plist-maven-plugin 1.5
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6444
> Patch:
> diff -r 5b9d72265772 application/org.openjdk.jmc.rcp.product/pom.xml
> --- a/application/org.openjdk.jmc.rcp.product/pom.xml   Tue Mar 26 14:11:58
> 2019 -0400
> +++ b/application/org.openjdk.jmc.rcp.product/pom.xml   Mon Apr 01 21:52:34
> 2019 -0400
> @@ -93,7 +93,7 @@
>                        <plugin>
>                                <groupId>name.abuchen</groupId>
> 
> <artifactId>fix-info-plist-maven-plugin</artifactId>
> -                               <version>1.2</version>
> +                               <version>1.5</version>
>                                <executions>
>                                        <execution>
>                                                <id>fix-info-plist</id>
> 
> Kind regards,
> Marcus


From guru.hb at oracle.com  Tue Apr  2 17:28:59 2019
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Tue, 02 Apr 2019 17:28:59 +0000
Subject: hg: jmc/jmc7: 2 new changesets
Message-ID: <201904021728.x32HSx12019384@aojmv0008.oracle.com>

Changeset: 790fc44e6093
Author:    ghb <guru.hb at oracle.com>
Date:      2019-03-20 23:53 +0530
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/790fc44e6093

JMC-6434: common.test fails with error Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter
Reviewed-by: hirt

! core/tests/pom.xml

Changeset: 3ef38880af76
Author:    ghb <guru.hb at oracle.com>
Date:      2019-03-22 02:10 +0530
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/3ef38880af76

JMC-6422: Update JMC7.0 THIRDPARTYREADME with latest javamail 1.6.3 version and JavaBeans Activation Framework 1.2.1
Reviewed-by: hirt <marcus at hirt.se>, Jie Kang <jkang at redhat.com>

! license/THIRDPARTYREADME.txt


From kdobson at redhat.com  Tue Apr  2 20:02:32 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Tue, 2 Apr 2019 16:02:32 -0400
Subject: Review Request for JMC-4469: Adding a page from the properties
 view
In-Reply-To: <CAOpWGx3u0p-SwNevwHXcMrKj=KFRixSV1cLE35XNEkotHuSBkQ@mail.gmail.com>
References: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>
 <CAOpWGx3u0p-SwNevwHXcMrKj=KFRixSV1cLE35XNEkotHuSBkQ@mail.gmail.com>
Message-ID: <CADPaBqnpDAqKbc4Skd0rq5=dOgcmAS0TztrYYwN0_U1aWTNsQw@mail.gmail.com>

Thanks for the review, here's the webrev with trailing spaces removed.

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

Thanks,

Ken Dobson

On Mon, Apr 1, 2019 at 9:44 PM Marcus Hirt <marcus.hirt at datadoghq.com>
wrote:

> Hi Ken!
>
> There are some trailing spaces that should be removed, but other than that
> it looks good!
>
> Kind regards,
> Marcus
>
> On Mon, Apr 1, 2019 at 7:14 PM Ken Dobson <kdobson at redhat.com> wrote:
>
>> Hi all,
>> please review this patch for JMC-4469 to allow for adding a page with the
>> events selected in the property view.
>>
>> bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4469
>> webrev: http://cr.openjdk.java.net/~kdobson/addpagefromproperties/webrev/
>>
>> Thanks,
>>
>> Ken Dobson
>>
>

From marcus.hirt at datadoghq.com  Tue Apr  2 20:37:42 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 2 Apr 2019 16:37:42 -0400
Subject: Review Request for JMC-6444: Switch to fix-info-plist-maven-plugin
 1.5
In-Reply-To: <BEDA68A1-AE11-4BD0-9872-FD2689C7F792@oracle.com>
References: <CAOpWGx01zvzV_L+AJYLpBYG2DWtDcVxuknNjEqdSv50LgVkd8w@mail.gmail.com>
 <BEDA68A1-AE11-4BD0-9872-FD2689C7F792@oracle.com>
Message-ID: <CAOpWGx1dJ-socwKduFmYeC==ki+j3iG12oTaoPQ_Dip7fDFj5w@mail.gmail.com>

Ok. Please ping me when the TPA comes along. ;)

Kind regards,
Marcus

On Tue, Apr 2, 2019 at 1:03 AM Guru <guru.hb at oracle.com> wrote:

> +1, Changes looks good to me,
>
> Please Wait for the Third party approval to push the changes.
>
> Thanks,
> Guru
> > On 02-Apr-2019, at 7:32 AM, Marcus Hirt <marcus.hirt at datadoghq.com>
> wrote:
> >
> > Hi all,
> >
> > Please review this fix to switch to fix-info-plist-maven-plugin 1.5
> >
> > Jira:   https://bugs.openjdk.java.net/browse/JMC-6444
> > Patch:
> > diff -r 5b9d72265772 application/org.openjdk.jmc.rcp.product/pom.xml
> > --- a/application/org.openjdk.jmc.rcp.product/pom.xml   Tue Mar 26
> 14:11:58
> > 2019 -0400
> > +++ b/application/org.openjdk.jmc.rcp.product/pom.xml   Mon Apr 01
> 21:52:34
> > 2019 -0400
> > @@ -93,7 +93,7 @@
> >                        <plugin>
> >                                <groupId>name.abuchen</groupId>
> >
> > <artifactId>fix-info-plist-maven-plugin</artifactId>
> > -                               <version>1.2</version>
> > +                               <version>1.5</version>
> >                                <executions>
> >                                        <execution>
> >                                                <id>fix-info-plist</id>
> >
> > Kind regards,
> > Marcus
>
>

From marcus.hirt at datadoghq.com  Wed Apr  3 03:01:55 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 2 Apr 2019 23:01:55 -0400
Subject: Review Request for JMC-4469: Adding a page from the properties
 view
In-Reply-To: <CADPaBqnpDAqKbc4Skd0rq5=dOgcmAS0TztrYYwN0_U1aWTNsQw@mail.gmail.com>
References: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>
 <CAOpWGx3u0p-SwNevwHXcMrKj=KFRixSV1cLE35XNEkotHuSBkQ@mail.gmail.com>
 <CADPaBqnpDAqKbc4Skd0rq5=dOgcmAS0TztrYYwN0_U1aWTNsQw@mail.gmail.com>
Message-ID: <CAOpWGx2QhJ2czwXmHW79fmJOGYFPBw7Vo7MiWWekK4H_R4hSWA@mail.gmail.com>

Hi Ken,

Thanks for the updated review!

There is a System.out.println that you probably didn't intend to leave in
there:
http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java.cdiff.html

Also, I still see funky whitespace in line endings JfrPropertySheet @@
-330,7 +342,19 @@.

Kind regards,
Marcus

On Tue, Apr 2, 2019 at 4:02 PM Ken Dobson <kdobson at redhat.com> wrote:

> Thanks for the review, here's the webrev with trailing spaces removed.
>
> http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/
>
> Thanks,
>
> Ken Dobson
>
> On Mon, Apr 1, 2019 at 9:44 PM Marcus Hirt <marcus.hirt at datadoghq.com>
> wrote:
>
>> Hi Ken!
>>
>> There are some trailing spaces that should be removed, but other than
>> that it looks good!
>>
>> Kind regards,
>> Marcus
>>
>> On Mon, Apr 1, 2019 at 7:14 PM Ken Dobson <kdobson at redhat.com> wrote:
>>
>>> Hi all,
>>> please review this patch for JMC-4469 to allow for adding a page with the
>>> events selected in the property view.
>>>
>>> bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4469
>>> webrev:
>>> http://cr.openjdk.java.net/~kdobson/addpagefromproperties/webrev/
>>>
>>> Thanks,
>>>
>>> Ken Dobson
>>>
>>

From kdobson at redhat.com  Wed Apr  3 14:32:28 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Wed, 3 Apr 2019 10:32:28 -0400
Subject: Review Request for JMC-4469: Adding a page from the properties
 view
In-Reply-To: <CAOpWGx2QhJ2czwXmHW79fmJOGYFPBw7Vo7MiWWekK4H_R4hSWA@mail.gmail.com>
References: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>
 <CAOpWGx3u0p-SwNevwHXcMrKj=KFRixSV1cLE35XNEkotHuSBkQ@mail.gmail.com>
 <CADPaBqnpDAqKbc4Skd0rq5=dOgcmAS0TztrYYwN0_U1aWTNsQw@mail.gmail.com>
 <CAOpWGx2QhJ2czwXmHW79fmJOGYFPBw7Vo7MiWWekK4H_R4hSWA@mail.gmail.com>
Message-ID: <CADPaBqkQC2voHrGWVWjP5gPRt=6G_ioyiuhZtY6APz_Zm9xzqg@mail.gmail.com>

Oops good catch not sure how I missed that. I think I've caught them all
now.

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

Ken Dobson

On Tue, Apr 2, 2019 at 11:02 PM Marcus Hirt <marcus.hirt at datadoghq.com>
wrote:

> Hi Ken,
>
> Thanks for the updated review!
>
> There is a System.out.println that you probably didn't intend to leave in
> there:
>
> http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java.cdiff.html
>
> Also, I still see funky whitespace in line endings JfrPropertySheet @@
> -330,7 +342,19 @@.
>
> Kind regards,
> Marcus
>
> On Tue, Apr 2, 2019 at 4:02 PM Ken Dobson <kdobson at redhat.com> wrote:
>
>> Thanks for the review, here's the webrev with trailing spaces removed.
>>
>> http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/
>>
>> Thanks,
>>
>> Ken Dobson
>>
>> On Mon, Apr 1, 2019 at 9:44 PM Marcus Hirt <marcus.hirt at datadoghq.com>
>> wrote:
>>
>>> Hi Ken!
>>>
>>> There are some trailing spaces that should be removed, but other than
>>> that it looks good!
>>>
>>> Kind regards,
>>> Marcus
>>>
>>> On Mon, Apr 1, 2019 at 7:14 PM Ken Dobson <kdobson at redhat.com> wrote:
>>>
>>>> Hi all,
>>>> please review this patch for JMC-4469 to allow for adding a page with
>>>> the
>>>> events selected in the property view.
>>>>
>>>> bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4469
>>>> webrev:
>>>> http://cr.openjdk.java.net/~kdobson/addpagefromproperties/webrev/
>>>>
>>>> Thanks,
>>>>
>>>> Ken Dobson
>>>>
>>>

From gerard.ziemski at oracle.com  Wed Apr  3 15:24:49 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Wed, 3 Apr 2019 10:24:49 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for DictionarySizes
In-Reply-To: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
References: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
Message-ID: <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>

Hi all,

Please review this feature, which adds tracing events for the internal 
hash tables.

The following attributes are implemented:

<Field type="ulong" name="numberOfBuckets" label="Number of buckets" 
description="Number of buckets" />
<Field type="ulong" name="numberOfEntries" label="Number of entries" 
description="Number of all entries" />
<Field type="ulong" contentType="bytes" name="totalFootprint" 
label="Total footprint" description="Total memory footprint (the table 
itself plus all of the entries)" />
<Field type="ulong" name="maximumBucketSize" label="Maximum bucket size" 
description="The maximum bucket length (entries in a single bucket)" />
<Field type="double" name="averageBucketSize" label="Average bucket 
size" description="The average bucket length (entries in a bucket)" /> 
<Field type="double" name="varianceOfBucketSize" label="Variance of 
bucket sizes" description="How far bucket lengths are spread out from 
their average value" />
<Field type="double" name="stdDevOfBucketSize" label="Standard deviation 
of bucket sizes" description="How far bucket lengths are spread out from 
their mean (expected) value" />
<Field type="double" name="addRate" label="Rate of addition" 
description="How many items were added since last event (per second)" />
<Field type="double" name="removeRate" label="Rate of removal" 
description="How many items were removed since last event (per second)" />

This event was implemented for the following system tables:

SymbolTable
StringTable
Placeholder Table
LoaderConstraints Table
ProtectionDomainCache Table

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


Cheers


From erik.gahlin at oracle.com  Wed Apr  3 17:44:47 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 3 Apr 2019 19:44:47 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>
References: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
 <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>
Message-ID: <5CA4F10F.2010805@oracle.com>

Hi Gerard,

Here are some comments about the metadata (to make it consistent with 
other events).

The events should not be in the "Java Application" category since they 
are JVM events. You could perhaps put them in "Java Virtual Machine, 
Runtime, Tables". Some comments about the names and labels of fields.

- Label: Number of buckets => Bucket Count
- Label: Number of entries => Entry Count
- Label: Total footprint => Total Footprint

Could you remove descriptions that are exactly the same as the label.

- Label: Maximum bucket size => Maximum Bucket Size
- Label: Average bucket size => Average Bucket Size
- Label: Variance of bucket  size => Bucket Size Variance
- Name: stdDevOfBucketSize => bucketSizeStandardDeviation
- Label: Standard deviation of bucket size => Bucket Size Standard 
Deviation"

Instead of using the word "size", it may make more sense to use the word 
"count" here as well, i.e "Average Bucket Count", or maybe I'm missing 
something? Is there a difference?

I wonder how useful standard deviation and variance is? If support 
engineers are looking at a recording, or JMC adds a rule for the events, 
what would a good or bad value be? Is it possible to use the information 
for troubleshooting?

- Name: addRate => insertionRate
- Label: Rate of addition =>  Insertation Rate
- Name: removeRate => removalRate
- Label: Rate of removal => Removal Rate

I'm missing unit tests for the events. Could you please add in 
/test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
average not exceeding max, no negative values etc.

Thanks!
Erik

> Hi all,
>
> Please review this feature, which adds tracing events for the internal 
> hash tables.
>
> The following attributes are implemented:
>
> <Field type="ulong" name="numberOfBuckets" label="Number of buckets" 
> description="Number of buckets" />
> <Field type="ulong" name="numberOfEntries" label="Number of entries" 
> description="Number of all entries" />
> <Field type="ulong" contentType="bytes" name="totalFootprint" 
> label="Total footprint" description="Total memory footprint (the table 
> itself plus all of the entries)" />
> <Field type="ulong" name="maximumBucketSize" label="Maximum bucket 
> size" description="The maximum bucket length (entries in a single 
> bucket)" />
> <Field type="double" name="averageBucketSize" label="Average bucket 
> size" description="The average bucket length (entries in a bucket)" /> 
> <Field type="double" name="varianceOfBucketSize" label="Variance of 
> bucket sizes" description="How far bucket lengths are spread out from 
> their average value" />
> <Field type="double" name="stdDevOfBucketSize" label="Standard 
> deviation of bucket sizes" description="How far bucket lengths are 
> spread out from their mean (expected) value" />
> <Field type="double" name="addRate" label="Rate of addition" 
> description="How many items were added since last event (per second)" />
> <Field type="double" name="removeRate" label="Rate of removal" 
> description="How many items were removed since last event (per 
> second)" />
>
> This event was implemented for the following system tables:
>
> SymbolTable
> StringTable
> Placeholder Table
> LoaderConstraints Table
> ProtectionDomainCache Table
>
> Webrev:  http://cr.openjdk.java.net/~gziemski/8185525_rev1/
> Bug:     https://bugs.openjdk.java.net/browse/JDK-8185525
> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)
>
>
> Cheers
>


From gerard.ziemski at oracle.com  Thu Apr  4 15:39:11 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 4 Apr 2019 10:39:11 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CA4F10F.2010805@oracle.com>
References: <E9E72BC1-793C-40DD-880D-A642440803B2@me.com>
 <1573e3e8-ace5-ee34-1269-96b4ef2fbe78@oracle.com>
 <5CA4F10F.2010805@oracle.com>
Message-ID: <b5a611ee-c72f-d7ab-c01f-c833ee94f2ce@oracle.com>

hi Erik,


On 4/3/19 12:44 PM, Erik Gahlin wrote:
> Hi Gerard,
>
> Here are some comments about the metadata (to make it consistent with 
> other events).
>
> The events should not be in the "Java Application" category since they 
> are JVM events. You could perhaps put them in "Java Virtual Machine, 
> Runtime, Tables". Some comments about the names and labels of fields.
>
> - Label: Number of buckets => Bucket Count
> - Label: Number of entries => Entry Count
> - Label: Total footprint => Total Footprint
>
> Could you remove descriptions that are exactly the same as the label.
>
> - Label: Maximum bucket size => Maximum Bucket Size
> - Label: Average bucket size => Average Bucket Size
> - Label: Variance of bucket? size => Bucket Size Variance
> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
> - Label: Standard deviation of bucket size => Bucket Size Standard 
> Deviation"
>
> Instead of using the word "size", it may make more sense to use the 
> word "count" here as well, i.e "Average Bucket Count", or maybe I'm 
> missing something? Is there a difference?
>
> I wonder how useful standard deviation and variance is? If support 
> engineers are looking at a recording, or JMC adds a rule for the 
> events, what would a good or bad value be? Is it possible to use the 
> information for troubleshooting?

While I'm working on all the above changes you suggested, we can discuss 
the standard devation and variance.

I added them because they are part of the jcmd "VM.symboltable -verbose" 
command, so we are consistent.

Now, regarding how useful they are, I always understood them as a sign 
of imbalanced table distribution, and without a proper histogram, this 
is the best description of the histogram shape. In reality, however, I 
think that if they identify an issue, then we might have a very curious 
distribution (some sort of hash table attack), or we have an issue with 
our hash function for the particular usage case.

Still, I'd personally elect to keep them.

Let me ask you a different question though, Is it expensive to have 2 
doubles as part of an event (5 events per second)? And if so, is there 
currently (or planned) granularity for controlling not just which events 
to record, but also which attributes?

>
> - Name: addRate => insertionRate
> - Label: Rate of addition =>? Insertation Rate
> - Name: removeRate => removalRate
> - Label: Rate of removal => Removal Rate

Will do.

>
> I'm missing unit tests for the events. Could you please add in 
> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
> average not exceeding max, no negative values etc.

Working on it, do we need separate test per each event (table), or just 
one table will suffice (ex. StringTable)?

Thank you for the feedback!


cheers
>
> Thanks!
> Erik
>
>> Hi all,
>>
>> Please review this feature, which adds tracing events for the 
>> internal hash tables.
>>
>> The following attributes are implemented:
>>
>> <Field type="ulong" name="numberOfBuckets" label="Number of buckets" 
>> description="Number of buckets" />
>> <Field type="ulong" name="numberOfEntries" label="Number of entries" 
>> description="Number of all entries" />
>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>> label="Total footprint" description="Total memory footprint (the 
>> table itself plus all of the entries)" />
>> <Field type="ulong" name="maximumBucketSize" label="Maximum bucket 
>> size" description="The maximum bucket length (entries in a single 
>> bucket)" />
>> <Field type="double" name="averageBucketSize" label="Average bucket 
>> size" description="The average bucket length (entries in a bucket)" 
>> /> <Field type="double" name="varianceOfBucketSize" label="Variance 
>> of bucket sizes" description="How far bucket lengths are spread out 
>> from their average value" />
>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>> deviation of bucket sizes" description="How far bucket lengths are 
>> spread out from their mean (expected) value" />
>> <Field type="double" name="addRate" label="Rate of addition" 
>> description="How many items were added since last event (per second)" />
>> <Field type="double" name="removeRate" label="Rate of removal" 
>> description="How many items were removed since last event (per 
>> second)" />
>>
>> This event was implemented for the following system tables:
>>
>> SymbolTable
>> StringTable
>> Placeholder Table
>> LoaderConstraints Table
>> ProtectionDomainCache Table
>>
>> Webrev:? http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>> Bug:???? https://bugs.openjdk.java.net/browse/JDK-8185525
>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)
>>
>>
>> Cheers
>>
>
>


From erik.gahlin at oracle.com  Thu Apr  4 18:16:30 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 4 Apr 2019 20:16:30 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <b5a611ee-c72f-d7ab-c01f-c833ee94f2ce@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>
Message-ID: <5CA649FE.9070904@oracle.com>

On 2019-04-04 17:39, gerard ziemski wrote:
> hi Erik,
>
>
> On 4/3/19 12:44 PM, Erik Gahlin wrote:
>> Hi Gerard,
>>
>> Here are some comments about the metadata (to make it consistent with 
>> other events).
>>
>> The events should not be in the "Java Application" category since 
>> they are JVM events. You could perhaps put them in "Java Virtual 
>> Machine, Runtime, Tables". Some comments about the names and labels 
>> of fields.
>>
>> - Label: Number of buckets => Bucket Count
>> - Label: Number of entries => Entry Count
>> - Label: Total footprint => Total Footprint
>>
>> Could you remove descriptions that are exactly the same as the label.
>>
>> - Label: Maximum bucket size => Maximum Bucket Size
>> - Label: Average bucket size => Average Bucket Size
>> - Label: Variance of bucket  size => Bucket Size Variance
>> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
>> - Label: Standard deviation of bucket size => Bucket Size Standard 
>> Deviation"
>>
>> Instead of using the word "size", it may make more sense to use the 
>> word "count" here as well, i.e "Average Bucket Count", or maybe I'm 
>> missing something? Is there a difference?
>>
>> I wonder how useful standard deviation and variance is? If support 
>> engineers are looking at a recording, or JMC adds a rule for the 
>> events, what would a good or bad value be? Is it possible to use the 
>> information for troubleshooting?
>
> While I'm working on all the above changes you suggested, we can 
> discuss the standard devation and variance.
>
> I added them because they are part of the jcmd "VM.symboltable 
> -verbose" command, so we are consistent.
OK
>
> Now, regarding how useful they are, I always understood them as a sign 
> of imbalanced table distribution, and without a proper histogram, this 
> is the best description of the histogram shape. In reality, however, I 
> think that if they identify an issue, then we might have a very 
> curious distribution (some sort of hash table attack), or we have an 
> issue with our hash function for the particular usage case.
>
> Still, I'd personally elect to keep them.
>
> Let me ask you a different question though, Is it expensive to have 2 
> doubles as part of an event (5 events per second)? 
Doubles can't be compressed so each value will take 8 bytes. I don't 
think the precision of a double is needed, so you could change it into a 
float and save a few bytes.

Most user will not care about JVM internals and a lower rate than once 
per second is probably sufficient for support engineers to spot that 
something is wrong.

The Thread Context Switch Rate event is emitted once every ten seconds. 
I think the same rate could be used here.

> And if so, is there currently (or planned) granularity for controlling 
> not just which events to record, but also which attributes?
>
No.

If overhead becomes an issues, it's usually better to emit all the 
information, but at a lower rate.  That way, users can find out that the 
information exists, and increase the rate if a higher resolution is 
needed to solve their specific issue.

>>
>> - Name: addRate => insertionRate
>> - Label: Rate of addition =>  Insertation Rate
>> - Name: removeRate => removalRate
>> - Label: Rate of removal => Removal Rate
>
> Will do.
>
>>
>> I'm missing unit tests for the events. Could you please add in 
>> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
>> average not exceeding max, no negative values etc.
>
> Working on it, do we need separate test per each event (table), or 
> just one table will suffice (ex. StringTable)?
They are kind of similar, so I think one test file is sufficient, but we 
should sanity check data for all events.

Thanks
Erik

>
> Thank you for the feedback!
>
>
> cheers
>>
>> Thanks!
>> Erik
>>
>>> Hi all,
>>>
>>> Please review this feature, which adds tracing events for the 
>>> internal hash tables.
>>>
>>> The following attributes are implemented:
>>>
>>> <Field type="ulong" name="numberOfBuckets" label="Number of buckets" 
>>> description="Number of buckets" />
>>> <Field type="ulong" name="numberOfEntries" label="Number of entries" 
>>> description="Number of all entries" />
>>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>>> label="Total footprint" description="Total memory footprint (the 
>>> table itself plus all of the entries)" />
>>> <Field type="ulong" name="maximumBucketSize" label="Maximum bucket 
>>> size" description="The maximum bucket length (entries in a single 
>>> bucket)" />
>>> <Field type="double" name="averageBucketSize" label="Average bucket 
>>> size" description="The average bucket length (entries in a bucket)" 
>>> /> <Field type="double" name="varianceOfBucketSize" label="Variance 
>>> of bucket sizes" description="How far bucket lengths are spread out 
>>> from their average value" />
>>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>>> deviation of bucket sizes" description="How far bucket lengths are 
>>> spread out from their mean (expected) value" />
>>> <Field type="double" name="addRate" label="Rate of addition" 
>>> description="How many items were added since last event (per 
>>> second)" />
>>> <Field type="double" name="removeRate" label="Rate of removal" 
>>> description="How many items were removed since last event (per 
>>> second)" />
>>>
>>> This event was implemented for the following system tables:
>>>
>>> SymbolTable
>>> StringTable
>>> Placeholder Table
>>> LoaderConstraints Table
>>> ProtectionDomainCache Table
>>>
>>> Webrev:  http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>>> Bug:     https://bugs.openjdk.java.net/browse/JDK-8185525
>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)
>>>
>>>
>>> Cheers
>>>
>>
>>
>


From gerard.ziemski at oracle.com  Thu Apr  4 19:52:53 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 4 Apr 2019 14:52:53 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CA649FE.9070904@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>
 <5CA649FE.9070904@oracle.com>
Message-ID: <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>

Thank you Erik for clarifications.

I have implemented all your suggestions, which you can find here 
http://cr.openjdk.java.net/~gziemski/8185525_rev2

I started Mach5 tier1-6 test to test the changes ...


cheers

On 4/4/19 1:16 PM, Erik Gahlin wrote:
> On 2019-04-04 17:39, gerard ziemski wrote:
>> hi Erik,
>>
>>
>> On 4/3/19 12:44 PM, Erik Gahlin wrote:
>>> Hi Gerard,
>>>
>>> Here are some comments about the metadata (to make it consistent 
>>> with other events).
>>>
>>> The events should not be in the "Java Application" category since 
>>> they are JVM events. You could perhaps put them in "Java Virtual 
>>> Machine, Runtime, Tables". Some comments about the names and labels 
>>> of fields.
>>>
>>> - Label: Number of buckets => Bucket Count
>>> - Label: Number of entries => Entry Count
>>> - Label: Total footprint => Total Footprint
>>>
>>> Could you remove descriptions that are exactly the same as the label.
>>>
>>> - Label: Maximum bucket size => Maximum Bucket Size
>>> - Label: Average bucket size => Average Bucket Size
>>> - Label: Variance of bucket? size => Bucket Size Variance
>>> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
>>> - Label: Standard deviation of bucket size => Bucket Size Standard 
>>> Deviation"
>>>
>>> Instead of using the word "size", it may make more sense to use the 
>>> word "count" here as well, i.e "Average Bucket Count", or maybe I'm 
>>> missing something? Is there a difference?
>>>
>>> I wonder how useful standard deviation and variance is? If support 
>>> engineers are looking at a recording, or JMC adds a rule for the 
>>> events, what would a good or bad value be? Is it possible to use the 
>>> information for troubleshooting?
>>
>> While I'm working on all the above changes you suggested, we can 
>> discuss the standard devation and variance.
>>
>> I added them because they are part of the jcmd "VM.symboltable 
>> -verbose" command, so we are consistent.
> OK
>>
>> Now, regarding how useful they are, I always understood them as a 
>> sign of imbalanced table distribution, and without a proper 
>> histogram, this is the best description of the histogram shape. In 
>> reality, however, I think that if they identify an issue, then we 
>> might have a very curious distribution (some sort of hash table 
>> attack), or we have an issue with our hash function for the 
>> particular usage case.
>>
>> Still, I'd personally elect to keep them.
>>
>> Let me ask you a different question though, Is it expensive to have 2 
>> doubles as part of an event (5 events per second)? 
> Doubles can't be compressed so each value will take 8 bytes. I don't 
> think the precision of a double is needed, so you could change it into 
> a float and save a few bytes.
>
> Most user will not care about JVM internals and a lower rate than once 
> per second is probably sufficient for support engineers to spot that 
> something is wrong.
>
> The Thread Context Switch Rate event is emitted once every ten 
> seconds. I think the same rate could be used here.
>
>> And if so, is there currently (or planned) granularity for 
>> controlling not just which events to record, but also which attributes?
>>
> No.
>
> If overhead becomes an issues, it's usually better to emit all the 
> information, but at a lower rate.? That way, users can find out that 
> the information exists, and increase the rate if a higher resolution 
> is needed to solve their specific issue.
>
>>>
>>> - Name: addRate => insertionRate
>>> - Label: Rate of addition =>? Insertation Rate
>>> - Name: removeRate => removalRate
>>> - Label: Rate of removal => Removal Rate
>>
>> Will do.
>>
>>>
>>> I'm missing unit tests for the events. Could you please add in 
>>> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
>>> average not exceeding max, no negative values etc.
>>
>> Working on it, do we need separate test per each event (table), or 
>> just one table will suffice (ex. StringTable)?
> They are kind of similar, so I think one test file is sufficient, but 
> we should sanity check data for all events.
>
> Thanks
> Erik
>
>>
>> Thank you for the feedback!
>>
>>
>> cheers
>>>
>>> Thanks!
>>> Erik
>>>
>>>> Hi all,
>>>>
>>>> Please review this feature, which adds tracing events for the 
>>>> internal hash tables.
>>>>
>>>> The following attributes are implemented:
>>>>
>>>> <Field type="ulong" name="numberOfBuckets" label="Number of 
>>>> buckets" description="Number of buckets" />
>>>> <Field type="ulong" name="numberOfEntries" label="Number of 
>>>> entries" description="Number of all entries" />
>>>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>>>> label="Total footprint" description="Total memory footprint (the 
>>>> table itself plus all of the entries)" />
>>>> <Field type="ulong" name="maximumBucketSize" label="Maximum bucket 
>>>> size" description="The maximum bucket length (entries in a single 
>>>> bucket)" />
>>>> <Field type="double" name="averageBucketSize" label="Average bucket 
>>>> size" description="The average bucket length (entries in a bucket)" 
>>>> /> <Field type="double" name="varianceOfBucketSize" label="Variance 
>>>> of bucket sizes" description="How far bucket lengths are spread out 
>>>> from their average value" />
>>>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>>>> deviation of bucket sizes" description="How far bucket lengths are 
>>>> spread out from their mean (expected) value" />
>>>> <Field type="double" name="addRate" label="Rate of addition" 
>>>> description="How many items were added since last event (per 
>>>> second)" />
>>>> <Field type="double" name="removeRate" label="Rate of removal" 
>>>> description="How many items were removed since last event (per 
>>>> second)" />
>>>>
>>>> This event was implemented for the following system tables:
>>>>
>>>> SymbolTable
>>>> StringTable
>>>> Placeholder Table
>>>> LoaderConstraints Table
>>>> ProtectionDomainCache Table
>>>>
>>>> Webrev:? http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>>>> Bug:???? https://bugs.openjdk.java.net/browse/JDK-8185525
>>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in 
>>>> progress?)
>>>>
>>>>
>>>> Cheers

From erik.gahlin at oracle.com  Thu Apr  4 21:11:57 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 4 Apr 2019 23:11:57 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <c80a1a3c-852c-b119-0fd6-23070dafdb18@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
Message-ID: <5CA6731D.7020907@oracle.com>

Thanks for fixing.

A quick comments about the test.

I think it can be simplified by using some of the test library 
functionality, i.e

   public static void main(String[] args) throws Throwable {
     try (Recording recording = new Recording()) {
       recording.enable(EventNames.SymbolTableStatistics);
       recording.enable(EventNames.StringTableStatistics);
       recording.enable(EventNames.PlaceholderTableStatistics);
recording.enable(EventNames.LoaderConstraintsTableStatistics);
recording.enable(EventNames.ProtectionDomainCacheTableStatistics);
       recording.start();
       recording.stop();

       List<RecordedEvent> events = Events.fromRecording(recording);
       verifyTable(events, EventNames.SymbolTableStatistics);
       verifyTable(events, EventNames.StringTableStatistics);
       verifyTable(events, EventNames.PlaceholderTableStatistics);
       verifyTable(events, EventNames.LoaderConstraintsTableStatistics);
       verifyTable(events, EventNames.ProtectionDomainCacheTableStatistics);
     }
   }

   private static void verifyTable(List<RecordedEvent> allEvents, String 
eventName) throws Exception {
     List<RecordedEvent> eventsForTable = allEvents.stream()
                                                   .filter(e -> 
e.getEventType().getName().equals(eventName))
.collect(Collectors.toList());
      if (eventsForTable.isEmpty()) {
        throw new Exception("No events for " + eventName);
      }
      for (RecordedEvent event : eventsForTable) {
        Events.assertField(event, "bucketCount").atLeast(0L);
        long entryCount = Events.assertField(event, 
"entryCount").atLeast(0L).getValue();
        Events.assertField(event, "totalFootprint").atLeast(0L);
        long averageBucketCount = Events.assertField(event, 
"averageBucketCount").atLeast(0L).getValue();
        Events.assertField(event, 
"maximumBucketCount").atLeast(averageBucketCount);
        Events.assertField(event, "bucketCountVariance").atLeast(0.0f);
        Events.assertField(event, 
"bucketCountStandardDeviation").atLeast(0.0f);
        float insertionRate = Events.assertField(event, 
"insertionRate").atLeast(0.0f).getValue();
        float removalRate = Events.assertField(event, 
"removalRate").atLeast(0.0f).getValue();
        if ((insertionRate > 0.0f) && (insertionRate > removalRate)) {
          Asserts.assertGreaterThan(entryCount, 0L, "Entries marked as 
added, but no entries found for " + eventName);
        }
     }
   }

- It's nice to have the main method on top so you can easily see what 
the test is supposed to do.
- Changed (some) field names that used the previous naming style.
- Reduced the number of methods to make it easier to read
- Reduced number of calls to Events.fromRecording(...) as will 
repeatedly dump a file to disk.
- Used Events.assertField() which will provide better error message if 
an assertion fails,
- Used EventType::getName instead of event.toString() contains
- Added sanity checks for standard deviation and variance fields
- Wrapped Recording creation in try-with-resource to avoid warning about 
resource leak
- Removed threshold as the events are periodic and don't use a threshold
- Removed "Thread.sleep"
- The test now relies on events having period "everyChunk" which means 
at least two events per recording are guaranteed

Could you explain how the string table test work, and why it needs 
special handling?

I also missed changes to the file EventNames.java

(I haven't actually tried the code, but you get the idea)

Thanks
Erik

> Thank you Erik for clarifications.
>
> I have implemented all your suggestions, which you can find here 
> http://cr.openjdk.java.net/~gziemski/8185525_rev2
>
> I started Mach5 tier1-6 test to test the changes ...
>
>
> cheers
>
> On 4/4/19 1:16 PM, Erik Gahlin wrote:
>> On 2019-04-04 17:39, gerard ziemski wrote:
>>> hi Erik,
>>>
>>>
>>> On 4/3/19 12:44 PM, Erik Gahlin wrote:
>>>> Hi Gerard,
>>>>
>>>> Here are some comments about the metadata (to make it consistent 
>>>> with other events).
>>>>
>>>> The events should not be in the "Java Application" category since 
>>>> they are JVM events. You could perhaps put them in "Java Virtual 
>>>> Machine, Runtime, Tables". Some comments about the names and labels 
>>>> of fields.
>>>>
>>>> - Label: Number of buckets => Bucket Count
>>>> - Label: Number of entries => Entry Count
>>>> - Label: Total footprint => Total Footprint
>>>>
>>>> Could you remove descriptions that are exactly the same as the label.
>>>>
>>>> - Label: Maximum bucket size => Maximum Bucket Size
>>>> - Label: Average bucket size => Average Bucket Size
>>>> - Label: Variance of bucket  size => Bucket Size Variance
>>>> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
>>>> - Label: Standard deviation of bucket size => Bucket Size Standard 
>>>> Deviation"
>>>>
>>>> Instead of using the word "size", it may make more sense to use the 
>>>> word "count" here as well, i.e "Average Bucket Count", or maybe I'm 
>>>> missing something? Is there a difference?
>>>>
>>>> I wonder how useful standard deviation and variance is? If support 
>>>> engineers are looking at a recording, or JMC adds a rule for the 
>>>> events, what would a good or bad value be? Is it possible to use 
>>>> the information for troubleshooting?
>>>
>>> While I'm working on all the above changes you suggested, we can 
>>> discuss the standard devation and variance.
>>>
>>> I added them because they are part of the jcmd "VM.symboltable 
>>> -verbose" command, so we are consistent.
>> OK
>>>
>>> Now, regarding how useful they are, I always understood them as a 
>>> sign of imbalanced table distribution, and without a proper 
>>> histogram, this is the best description of the histogram shape. In 
>>> reality, however, I think that if they identify an issue, then we 
>>> might have a very curious distribution (some sort of hash table 
>>> attack), or we have an issue with our hash function for the 
>>> particular usage case.
>>>
>>> Still, I'd personally elect to keep them.
>>>
>>> Let me ask you a different question though, Is it expensive to have 
>>> 2 doubles as part of an event (5 events per second)? 
>> Doubles can't be compressed so each value will take 8 bytes. I don't 
>> think the precision of a double is needed, so you could change it 
>> into a float and save a few bytes.
>>
>> Most user will not care about JVM internals and a lower rate than 
>> once per second is probably sufficient for support engineers to spot 
>> that something is wrong.
>>
>> The Thread Context Switch Rate event is emitted once every ten 
>> seconds. I think the same rate could be used here.
>>
>>> And if so, is there currently (or planned) granularity for 
>>> controlling not just which events to record, but also which attributes?
>>>
>> No.
>>
>> If overhead becomes an issues, it's usually better to emit all the 
>> information, but at a lower rate.  That way, users can find out that 
>> the information exists, and increase the rate if a higher resolution 
>> is needed to solve their specific issue.
>>
>>>>
>>>> - Name: addRate => insertionRate
>>>> - Label: Rate of addition =>  Insertation Rate
>>>> - Name: removeRate => removalRate
>>>> - Label: Rate of removal => Removal Rate
>>>
>>> Will do.
>>>
>>>>
>>>> I'm missing unit tests for the events. Could you please add in 
>>>> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
>>>> average not exceeding max, no negative values etc.
>>>
>>> Working on it, do we need separate test per each event (table), or 
>>> just one table will suffice (ex. StringTable)?
>> They are kind of similar, so I think one test file is sufficient, but 
>> we should sanity check data for all events.
>>
>> Thanks
>> Erik
>>
>>>
>>> Thank you for the feedback!
>>>
>>>
>>> cheers
>>>>
>>>> Thanks!
>>>> Erik
>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review this feature, which adds tracing events for the 
>>>>> internal hash tables.
>>>>>
>>>>> The following attributes are implemented:
>>>>>
>>>>> <Field type="ulong" name="numberOfBuckets" label="Number of 
>>>>> buckets" description="Number of buckets" />
>>>>> <Field type="ulong" name="numberOfEntries" label="Number of 
>>>>> entries" description="Number of all entries" />
>>>>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>>>>> label="Total footprint" description="Total memory footprint (the 
>>>>> table itself plus all of the entries)" />
>>>>> <Field type="ulong" name="maximumBucketSize" label="Maximum bucket 
>>>>> size" description="The maximum bucket length (entries in a single 
>>>>> bucket)" />
>>>>> <Field type="double" name="averageBucketSize" label="Average 
>>>>> bucket size" description="The average bucket length (entries in a 
>>>>> bucket)" /> <Field type="double" name="varianceOfBucketSize" 
>>>>> label="Variance of bucket sizes" description="How far bucket 
>>>>> lengths are spread out from their average value" />
>>>>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>>>>> deviation of bucket sizes" description="How far bucket lengths are 
>>>>> spread out from their mean (expected) value" />
>>>>> <Field type="double" name="addRate" label="Rate of addition" 
>>>>> description="How many items were added since last event (per 
>>>>> second)" />
>>>>> <Field type="double" name="removeRate" label="Rate of removal" 
>>>>> description="How many items were removed since last event (per 
>>>>> second)" />
>>>>>
>>>>> This event was implemented for the following system tables:
>>>>>
>>>>> SymbolTable
>>>>> StringTable
>>>>> Placeholder Table
>>>>> LoaderConstraints Table
>>>>> ProtectionDomainCache Table
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>>>>> Bug:     https://bugs.openjdk.java.net/browse/JDK-8185525
>>>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in 
>>>>> progress?)
>>>>>
>>>>>
>>>>> Cheers


From erik.gahlin at oracle.com  Thu Apr  4 21:15:17 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 4 Apr 2019 23:15:17 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CA6731D.7020907@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <5CA6731D.7020907@oracle.com>
Message-ID: <5CA673E5.4030306@oracle.com>

Sorry, I saw the EventNames.java file now.

Thanks
Erik

> Thanks for fixing.
>
> A quick comments about the test.
>
> I think it can be simplified by using some of the test library 
> functionality, i.e
>
>   public static void main(String[] args) throws Throwable {
>     try (Recording recording = new Recording()) {
>       recording.enable(EventNames.SymbolTableStatistics);
>       recording.enable(EventNames.StringTableStatistics);
>       recording.enable(EventNames.PlaceholderTableStatistics);
> recording.enable(EventNames.LoaderConstraintsTableStatistics);
> recording.enable(EventNames.ProtectionDomainCacheTableStatistics);
>       recording.start();
>       recording.stop();
>
>       List<RecordedEvent> events = Events.fromRecording(recording);
>       verifyTable(events, EventNames.SymbolTableStatistics);
>       verifyTable(events, EventNames.StringTableStatistics);
>       verifyTable(events, EventNames.PlaceholderTableStatistics);
>       verifyTable(events, EventNames.LoaderConstraintsTableStatistics);
>       verifyTable(events, 
> EventNames.ProtectionDomainCacheTableStatistics);
>     }
>   }
>
>   private static void verifyTable(List<RecordedEvent> allEvents, 
> String eventName) throws Exception {
>     List<RecordedEvent> eventsForTable = allEvents.stream()
>                                                   .filter(e -> 
> e.getEventType().getName().equals(eventName))
> .collect(Collectors.toList());
>      if (eventsForTable.isEmpty()) {
>        throw new Exception("No events for " + eventName);
>      }
>      for (RecordedEvent event : eventsForTable) {
>        Events.assertField(event, "bucketCount").atLeast(0L);
>        long entryCount = Events.assertField(event, 
> "entryCount").atLeast(0L).getValue();
>        Events.assertField(event, "totalFootprint").atLeast(0L);
>        long averageBucketCount = Events.assertField(event, 
> "averageBucketCount").atLeast(0L).getValue();
>        Events.assertField(event, 
> "maximumBucketCount").atLeast(averageBucketCount);
>        Events.assertField(event, "bucketCountVariance").atLeast(0.0f);
>        Events.assertField(event, 
> "bucketCountStandardDeviation").atLeast(0.0f);
>        float insertionRate = Events.assertField(event, 
> "insertionRate").atLeast(0.0f).getValue();
>        float removalRate = Events.assertField(event, 
> "removalRate").atLeast(0.0f).getValue();
>        if ((insertionRate > 0.0f) && (insertionRate > removalRate)) {
>          Asserts.assertGreaterThan(entryCount, 0L, "Entries marked as 
> added, but no entries found for " + eventName);
>        }
>     }
>   }
>
> - It's nice to have the main method on top so you can easily see what 
> the test is supposed to do.
> - Changed (some) field names that used the previous naming style.
> - Reduced the number of methods to make it easier to read
> - Reduced number of calls to Events.fromRecording(...) as will 
> repeatedly dump a file to disk.
> - Used Events.assertField() which will provide better error message if 
> an assertion fails,
> - Used EventType::getName instead of event.toString() contains
> - Added sanity checks for standard deviation and variance fields
> - Wrapped Recording creation in try-with-resource to avoid warning 
> about resource leak
> - Removed threshold as the events are periodic and don't use a threshold
> - Removed "Thread.sleep"
> - The test now relies on events having period "everyChunk" which means 
> at least two events per recording are guaranteed
>
> Could you explain how the string table test work, and why it needs 
> special handling?
>
> I also missed changes to the file EventNames.java
>
> (I haven't actually tried the code, but you get the idea)
>
> Thanks
> Erik
>
>> Thank you Erik for clarifications.
>>
>> I have implemented all your suggestions, which you can find here 
>> http://cr.openjdk.java.net/~gziemski/8185525_rev2
>>
>> I started Mach5 tier1-6 test to test the changes ...
>>
>>
>> cheers
>>
>> On 4/4/19 1:16 PM, Erik Gahlin wrote:
>>> On 2019-04-04 17:39, gerard ziemski wrote:
>>>> hi Erik,
>>>>
>>>>
>>>> On 4/3/19 12:44 PM, Erik Gahlin wrote:
>>>>> Hi Gerard,
>>>>>
>>>>> Here are some comments about the metadata (to make it consistent 
>>>>> with other events).
>>>>>
>>>>> The events should not be in the "Java Application" category since 
>>>>> they are JVM events. You could perhaps put them in "Java Virtual 
>>>>> Machine, Runtime, Tables". Some comments about the names and 
>>>>> labels of fields.
>>>>>
>>>>> - Label: Number of buckets => Bucket Count
>>>>> - Label: Number of entries => Entry Count
>>>>> - Label: Total footprint => Total Footprint
>>>>>
>>>>> Could you remove descriptions that are exactly the same as the label.
>>>>>
>>>>> - Label: Maximum bucket size => Maximum Bucket Size
>>>>> - Label: Average bucket size => Average Bucket Size
>>>>> - Label: Variance of bucket  size => Bucket Size Variance
>>>>> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
>>>>> - Label: Standard deviation of bucket size => Bucket Size Standard 
>>>>> Deviation"
>>>>>
>>>>> Instead of using the word "size", it may make more sense to use 
>>>>> the word "count" here as well, i.e "Average Bucket Count", or 
>>>>> maybe I'm missing something? Is there a difference?
>>>>>
>>>>> I wonder how useful standard deviation and variance is? If support 
>>>>> engineers are looking at a recording, or JMC adds a rule for the 
>>>>> events, what would a good or bad value be? Is it possible to use 
>>>>> the information for troubleshooting?
>>>>
>>>> While I'm working on all the above changes you suggested, we can 
>>>> discuss the standard devation and variance.
>>>>
>>>> I added them because they are part of the jcmd "VM.symboltable 
>>>> -verbose" command, so we are consistent.
>>> OK
>>>>
>>>> Now, regarding how useful they are, I always understood them as a 
>>>> sign of imbalanced table distribution, and without a proper 
>>>> histogram, this is the best description of the histogram shape. In 
>>>> reality, however, I think that if they identify an issue, then we 
>>>> might have a very curious distribution (some sort of hash table 
>>>> attack), or we have an issue with our hash function for the 
>>>> particular usage case.
>>>>
>>>> Still, I'd personally elect to keep them.
>>>>
>>>> Let me ask you a different question though, Is it expensive to have 
>>>> 2 doubles as part of an event (5 events per second)? 
>>> Doubles can't be compressed so each value will take 8 bytes. I don't 
>>> think the precision of a double is needed, so you could change it 
>>> into a float and save a few bytes.
>>>
>>> Most user will not care about JVM internals and a lower rate than 
>>> once per second is probably sufficient for support engineers to spot 
>>> that something is wrong.
>>>
>>> The Thread Context Switch Rate event is emitted once every ten 
>>> seconds. I think the same rate could be used here.
>>>
>>>> And if so, is there currently (or planned) granularity for 
>>>> controlling not just which events to record, but also which 
>>>> attributes?
>>>>
>>> No.
>>>
>>> If overhead becomes an issues, it's usually better to emit all the 
>>> information, but at a lower rate.  That way, users can find out that 
>>> the information exists, and increase the rate if a higher resolution 
>>> is needed to solve their specific issue.
>>>
>>>>>
>>>>> - Name: addRate => insertionRate
>>>>> - Label: Rate of addition =>  Insertation Rate
>>>>> - Name: removeRate => removalRate
>>>>> - Label: Rate of removal => Removal Rate
>>>>
>>>> Will do.
>>>>
>>>>>
>>>>> I'm missing unit tests for the events. Could you please add in 
>>>>> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
>>>>> average not exceeding max, no negative values etc.
>>>>
>>>> Working on it, do we need separate test per each event (table), or 
>>>> just one table will suffice (ex. StringTable)?
>>> They are kind of similar, so I think one test file is sufficient, 
>>> but we should sanity check data for all events.
>>>
>>> Thanks
>>> Erik
>>>
>>>>
>>>> Thank you for the feedback!
>>>>
>>>>
>>>> cheers
>>>>>
>>>>> Thanks!
>>>>> Erik
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Please review this feature, which adds tracing events for the 
>>>>>> internal hash tables.
>>>>>>
>>>>>> The following attributes are implemented:
>>>>>>
>>>>>> <Field type="ulong" name="numberOfBuckets" label="Number of 
>>>>>> buckets" description="Number of buckets" />
>>>>>> <Field type="ulong" name="numberOfEntries" label="Number of 
>>>>>> entries" description="Number of all entries" />
>>>>>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>>>>>> label="Total footprint" description="Total memory footprint (the 
>>>>>> table itself plus all of the entries)" />
>>>>>> <Field type="ulong" name="maximumBucketSize" label="Maximum 
>>>>>> bucket size" description="The maximum bucket length (entries in a 
>>>>>> single bucket)" />
>>>>>> <Field type="double" name="averageBucketSize" label="Average 
>>>>>> bucket size" description="The average bucket length (entries in a 
>>>>>> bucket)" /> <Field type="double" name="varianceOfBucketSize" 
>>>>>> label="Variance of bucket sizes" description="How far bucket 
>>>>>> lengths are spread out from their average value" />
>>>>>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>>>>>> deviation of bucket sizes" description="How far bucket lengths 
>>>>>> are spread out from their mean (expected) value" />
>>>>>> <Field type="double" name="addRate" label="Rate of addition" 
>>>>>> description="How many items were added since last event (per 
>>>>>> second)" />
>>>>>> <Field type="double" name="removeRate" label="Rate of removal" 
>>>>>> description="How many items were removed since last event (per 
>>>>>> second)" />
>>>>>>
>>>>>> This event was implemented for the following system tables:
>>>>>>
>>>>>> SymbolTable
>>>>>> StringTable
>>>>>> Placeholder Table
>>>>>> LoaderConstraints Table
>>>>>> ProtectionDomainCache Table
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185525
>>>>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in 
>>>>>> progress?)
>>>>>>
>>>>>>
>>>>>> Cheers
>


From gerard.ziemski at oracle.com  Fri Apr  5 15:42:27 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Fri, 5 Apr 2019 10:42:27 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CA6731D.7020907@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <5CA6731D.7020907@oracle.com>
Message-ID: <55d79be9-1e33-613f-36e5-c710f618bb52@oracle.com>

Thank you Erik for more suggestions.

I have implemented them, which you can find here 
http://cr.openjdk.java.net/~gziemski/8185525_rev3

I will start Mach5 tier1-6 test to test the changes shortly


On 4/4/19 4:11 PM, Erik Gahlin wrote:
> Thanks for fixing.
>
> A quick comments about the test.
>
> I think it can be simplified by using some of the test library 
> functionality, i.e
>
> ? public static void main(String[] args) throws Throwable {
> ??? try (Recording recording = new Recording()) {
> ????? recording.enable(EventNames.SymbolTableStatistics);
> ????? recording.enable(EventNames.StringTableStatistics);
> ????? recording.enable(EventNames.PlaceholderTableStatistics);
> recording.enable(EventNames.LoaderConstraintsTableStatistics);
> recording.enable(EventNames.ProtectionDomainCacheTableStatistics);
> ????? recording.start();
> ????? recording.stop();
>
> ????? List<RecordedEvent> events = Events.fromRecording(recording);
> ????? verifyTable(events, EventNames.SymbolTableStatistics);
> ????? verifyTable(events, EventNames.StringTableStatistics);
> ????? verifyTable(events, EventNames.PlaceholderTableStatistics);
> ????? verifyTable(events, EventNames.LoaderConstraintsTableStatistics);
> ????? verifyTable(events, 
> EventNames.ProtectionDomainCacheTableStatistics);
> ??? }
> ? }
>
> ? private static void verifyTable(List<RecordedEvent> allEvents, 
> String eventName) throws Exception {
> ??? List<RecordedEvent> eventsForTable = allEvents.stream()
> ????????????????????????????????????????????????? .filter(e -> 
> e.getEventType().getName().equals(eventName))
> .collect(Collectors.toList());
> ???? if (eventsForTable.isEmpty()) {
> ?????? throw new Exception("No events for " + eventName);
> ???? }
> ???? for (RecordedEvent event : eventsForTable) {
> ?????? Events.assertField(event, "bucketCount").atLeast(0L);
> ?????? long entryCount = Events.assertField(event, 
> "entryCount").atLeast(0L).getValue();
> ?????? Events.assertField(event, "totalFootprint").atLeast(0L);
> ?????? long averageBucketCount = Events.assertField(event, 
> "averageBucketCount").atLeast(0L).getValue();
> ?????? Events.assertField(event, 
> "maximumBucketCount").atLeast(averageBucketCount);
> ?????? Events.assertField(event, "bucketCountVariance").atLeast(0.0f);
> ?????? Events.assertField(event, 
> "bucketCountStandardDeviation").atLeast(0.0f);
> ?????? float insertionRate = Events.assertField(event, 
> "insertionRate").atLeast(0.0f).getValue();
> ?????? float removalRate = Events.assertField(event, 
> "removalRate").atLeast(0.0f).getValue();
> ?????? if ((insertionRate > 0.0f) && (insertionRate > removalRate)) {
> ???????? Asserts.assertGreaterThan(entryCount, 0L, "Entries marked as 
> added, but no entries found for " + eventName);
> ?????? }
> ??? }
> ? }
>
> - It's nice to have the main method on top so you can easily see what 
> the test is supposed to do.
> - Changed (some) field names that used the previous naming style.
> - Reduced the number of methods to make it easier to read
> - Reduced number of calls to Events.fromRecording(...) as will 
> repeatedly dump a file to disk.
> - Used Events.assertField() which will provide better error message if 
> an assertion fails,
> - Used EventType::getName instead of event.toString() contains
> - Added sanity checks for standard deviation and variance fields
> - Wrapped Recording creation in try-with-resource to avoid warning 
> about resource leak
> - Removed threshold as the events are periodic and don't use a threshold
> - Removed "Thread.sleep"
> - The test now relies on events having period "everyChunk" which means 
> at least two events per recording are guaranteed
>
> Could you explain how the string table test work, and why it needs 
> special handling?
Some tables might have zero entries, so I just wanted to be clear that 
for StringTable (which will always have some entries) we do something 
that will make it grow. I was planning on doing more elaborate tests, 
but I don't think it's necessary.


>
> I also missed changes to the file EventNames.java
>
> (I haven't actually tried the code, but you get the idea)

I fixed it up just a bit, and it works nice, thanks!


>
> Thanks
> Erik
>
>> Thank you Erik for clarifications.
>>
>> I have implemented all your suggestions, which you can find here 
>> http://cr.openjdk.java.net/~gziemski/8185525_rev2
>>
>> I started Mach5 tier1-6 test to test the changes ...
>>
>>
>> cheers
>>
>> On 4/4/19 1:16 PM, Erik Gahlin wrote:
>>> On 2019-04-04 17:39, gerard ziemski wrote:
>>>> hi Erik,
>>>>
>>>>
>>>> On 4/3/19 12:44 PM, Erik Gahlin wrote:
>>>>> Hi Gerard,
>>>>>
>>>>> Here are some comments about the metadata (to make it consistent 
>>>>> with other events).
>>>>>
>>>>> The events should not be in the "Java Application" category since 
>>>>> they are JVM events. You could perhaps put them in "Java Virtual 
>>>>> Machine, Runtime, Tables". Some comments about the names and 
>>>>> labels of fields.
>>>>>
>>>>> - Label: Number of buckets => Bucket Count
>>>>> - Label: Number of entries => Entry Count
>>>>> - Label: Total footprint => Total Footprint
>>>>>
>>>>> Could you remove descriptions that are exactly the same as the label.
>>>>>
>>>>> - Label: Maximum bucket size => Maximum Bucket Size
>>>>> - Label: Average bucket size => Average Bucket Size
>>>>> - Label: Variance of bucket? size => Bucket Size Variance
>>>>> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
>>>>> - Label: Standard deviation of bucket size => Bucket Size Standard 
>>>>> Deviation"
>>>>>
>>>>> Instead of using the word "size", it may make more sense to use 
>>>>> the word "count" here as well, i.e "Average Bucket Count", or 
>>>>> maybe I'm missing something? Is there a difference?
>>>>>
>>>>> I wonder how useful standard deviation and variance is? If support 
>>>>> engineers are looking at a recording, or JMC adds a rule for the 
>>>>> events, what would a good or bad value be? Is it possible to use 
>>>>> the information for troubleshooting?
>>>>
>>>> While I'm working on all the above changes you suggested, we can 
>>>> discuss the standard devation and variance.
>>>>
>>>> I added them because they are part of the jcmd "VM.symboltable 
>>>> -verbose" command, so we are consistent.
>>> OK
>>>>
>>>> Now, regarding how useful they are, I always understood them as a 
>>>> sign of imbalanced table distribution, and without a proper 
>>>> histogram, this is the best description of the histogram shape. In 
>>>> reality, however, I think that if they identify an issue, then we 
>>>> might have a very curious distribution (some sort of hash table 
>>>> attack), or we have an issue with our hash function for the 
>>>> particular usage case.
>>>>
>>>> Still, I'd personally elect to keep them.
>>>>
>>>> Let me ask you a different question though, Is it expensive to have 
>>>> 2 doubles as part of an event (5 events per second)? 
>>> Doubles can't be compressed so each value will take 8 bytes. I don't 
>>> think the precision of a double is needed, so you could change it 
>>> into a float and save a few bytes.
>>>
>>> Most user will not care about JVM internals and a lower rate than 
>>> once per second is probably sufficient for support engineers to spot 
>>> that something is wrong.
>>>
>>> The Thread Context Switch Rate event is emitted once every ten 
>>> seconds. I think the same rate could be used here.
>>>
>>>> And if so, is there currently (or planned) granularity for 
>>>> controlling not just which events to record, but also which 
>>>> attributes?
>>>>
>>> No.
>>>
>>> If overhead becomes an issues, it's usually better to emit all the 
>>> information, but at a lower rate.? That way, users can find out that 
>>> the information exists, and increase the rate if a higher resolution 
>>> is needed to solve their specific issue.
>>>
>>>>>
>>>>> - Name: addRate => insertionRate
>>>>> - Label: Rate of addition =>? Insertation Rate
>>>>> - Name: removeRate => removalRate
>>>>> - Label: Rate of removal => Removal Rate
>>>>
>>>> Will do.
>>>>
>>>>>
>>>>> I'm missing unit tests for the events. Could you please add in 
>>>>> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
>>>>> average not exceeding max, no negative values etc.
>>>>
>>>> Working on it, do we need separate test per each event (table), or 
>>>> just one table will suffice (ex. StringTable)?
>>> They are kind of similar, so I think one test file is sufficient, 
>>> but we should sanity check data for all events.
>>>
>>> Thanks
>>> Erik
>>>
>>>>
>>>> Thank you for the feedback!
>>>>
>>>>
>>>> cheers
>>>>>
>>>>> Thanks!
>>>>> Erik
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Please review this feature, which adds tracing events for the 
>>>>>> internal hash tables.
>>>>>>
>>>>>> The following attributes are implemented:
>>>>>>
>>>>>> <Field type="ulong" name="numberOfBuckets" label="Number of 
>>>>>> buckets" description="Number of buckets" />
>>>>>> <Field type="ulong" name="numberOfEntries" label="Number of 
>>>>>> entries" description="Number of all entries" />
>>>>>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>>>>>> label="Total footprint" description="Total memory footprint (the 
>>>>>> table itself plus all of the entries)" />
>>>>>> <Field type="ulong" name="maximumBucketSize" label="Maximum 
>>>>>> bucket size" description="The maximum bucket length (entries in a 
>>>>>> single bucket)" />
>>>>>> <Field type="double" name="averageBucketSize" label="Average 
>>>>>> bucket size" description="The average bucket length (entries in a 
>>>>>> bucket)" /> <Field type="double" name="varianceOfBucketSize" 
>>>>>> label="Variance of bucket sizes" description="How far bucket 
>>>>>> lengths are spread out from their average value" />
>>>>>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>>>>>> deviation of bucket sizes" description="How far bucket lengths 
>>>>>> are spread out from their mean (expected) value" />
>>>>>> <Field type="double" name="addRate" label="Rate of addition" 
>>>>>> description="How many items were added since last event (per 
>>>>>> second)" />
>>>>>> <Field type="double" name="removeRate" label="Rate of removal" 
>>>>>> description="How many items were removed since last event (per 
>>>>>> second)" />
>>>>>>
>>>>>> This event was implemented for the following system tables:
>>>>>>
>>>>>> SymbolTable
>>>>>> StringTable
>>>>>> Placeholder Table
>>>>>> LoaderConstraints Table
>>>>>> ProtectionDomainCache Table
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185525
>>>>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in 
>>>>>> progress?)
>>>>>>
>>>>>>
>>>>>> Cheers
>
>


From almacdon at redhat.com  Fri Apr  5 17:28:51 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Fri, 5 Apr 2019 13:28:51 -0400
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context menu
Message-ID: <CAOsn=kqQOObGc=O8D7ewN0ydj=2R0EGgxSawwKQO=t+ggyGV7Q@mail.gmail.com>

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

From almacdon at redhat.com  Fri Apr  5 18:36:21 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Fri, 5 Apr 2019 14:36:21 -0400
Subject: Review request for JMC-4645: Add size distribution chart to IO
 Pages
In-Reply-To: <CADPaBq=wDCPdznYD=BECUoBKU8jYB54e1q5CqR9s-Kp5MBNqbA@mail.gmail.com>
References: <CADPaBq=wDCPdznYD=BECUoBKU8jYB54e1q5CqR9s-Kp5MBNqbA@mail.gmail.com>
Message-ID: <CAOsn=kr9a--EyCd91O5--jykiGrdOHeHjRC0D4gmEQ1vDdhDzw@mail.gmail.com>

Hi Ken,

On Fri, Mar 29, 2019 at 4:08 PM Ken Dobson <kdobson at redhat.com> wrote:

> Hi all,
>
> Please review this patch I've made that adds a size distribution chart to
> the IO Pages.
>
> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
> Webrev: http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/


Overall the code looks good from what I can tell.

Having said that, I just want to confirm what I'm reading off the chart,
let's use this sample screen shot [0] (https://imgur.com/sPo9Xeo) as an
example. The y-axis displays the number of reads/writes, and the x-axis
displays the size of that read or write? If that's the case I'm a bit
confused. The blue bar (write) hits 1 on the y axis for 1 read, and is
displayed at ~6.16KiB on the x axis because that's how much it wrote.
However, the red bar (read) hits 1797 on the y axis for 1797 reads as
expected, but why does the x axis display 0 - 256B when there was 1.89 KiB
read in total?

A couple of formatting nits:

1. There are some unused imports in the DataPageToolkit

[...]
+import org.openjdk.jmc.flightrecorder.ui.PageManager;
[...]
+import org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage;+import
org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage.ItemHandlerUiStandIn;
[...]

2. Excess white space just before (and inside)
DataPageToolkit.buildSizeHistogram()
3. JDKAttributes, SocketIO & FileIO pages also each have a few instances of
excess/trailing white space


>
> Thanks,
>
> Ken Dobson
>

Cheers,

Alex

[0] https://imgur.com/sPo9Xeo

From kdobson at redhat.com  Fri Apr  5 19:49:14 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Fri, 5 Apr 2019 15:49:14 -0400
Subject: Review request for JMC-4645: Add size distribution chart to IO
 Pages
In-Reply-To: <CAOsn=kr9a--EyCd91O5--jykiGrdOHeHjRC0D4gmEQ1vDdhDzw@mail.gmail.com>
References: <CADPaBq=wDCPdznYD=BECUoBKU8jYB54e1q5CqR9s-Kp5MBNqbA@mail.gmail.com>
 <CAOsn=kr9a--EyCd91O5--jykiGrdOHeHjRC0D4gmEQ1vDdhDzw@mail.gmail.com>
Message-ID: <CADPaBqk22qqFQsZ8x0ygnaU+4HZnBPh6zsOAZsmVK01j1QofXg@mail.gmail.com>

Here is the previous messages from this list for some reason they haven't
shown up to the others on the list as well as the pipermail archives.

From: Marcus Hirt <marcus.hirt at datadoghq.com>
Date: Tue, Apr 2, 2019 at 10:55 PM
Subject: Re: Review request for JMC-4645: Add size distribution chart to IO
Pages
To: Ken Dobson <kdobson at redhat.com>
Cc: <jmc-dev at openjdk.java.net>


Looks good!

Kind regards,
Marcus

On Tue, Apr 2, 2019 at 4:51 PM Ken Dobson <kdobson at redhat.com> wrote:

> Thanks for the review, here's the new webrev removing unnecessary
> whitespace.
>
> http://cr.openjdk.java.net/~kdobson/sizedistributionchart0/webrev
>
> Ken Dobson
>
> On Mon, Apr 1, 2019 at 9:27 PM Marcus Hirt <marcus.hirt at datadoghq.com>
> wrote:
>
>> Hi Ken,
>>
>> It generally looks good, but:
>>
>>    - When I apply your patch, I see a lot of whitespace line endings.
>>    Whilst we're not enforcing that there is no trailing whitespace, it would
>>    be nice to avoid. E.g.
>>
>> [image: image.png]
>>
>>    - Is the reason for adding 64 bytes to the maxValue (if there is one)
>>    cosmetic padding?
>>      sizeMax = sizeMax == null ? UnitLookup.BYTE.quantity(64):
>>    sizeMax.add(UnitLookup.BYTE.quantity(64));
>>
>> Kind regards,
>> Marcus
>>
>> On Fri, Mar 29, 2019 at 4:07 PM Ken Dobson <kdobson at redhat.com> wrote:
>>
>>> Hi all,
>>>
>>> Please review this patch I've made that adds a size distribution chart to
>>> the IO Pages.
>>>
>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
>>> Webrev:
>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
>>>
>>> Thanks,
>>>
>>> Ken Dobson
>>>
>>
On Fri, Apr 5, 2019 at 2:36 PM Alex Macdonald <almacdon at redhat.com> wrote:

> Hi Ken,
>
> On Fri, Mar 29, 2019 at 4:08 PM Ken Dobson <kdobson at redhat.com> wrote:
>
>> Hi all,
>>
>> Please review this patch I've made that adds a size distribution chart to
>> the IO Pages.
>>
>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
>> Webrev: http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
>
>
> Overall the code looks good from what I can tell.
>
> Having said that, I just want to confirm what I'm reading off the chart,
> let's use this sample screen shot [0] (https://imgur.com/sPo9Xeo) as an
> example. The y-axis displays the number of reads/writes, and the x-axis
> displays the size of that read or write? If that's the case I'm a bit
> confused. The blue bar (write) hits 1 on the y axis for 1 read, and is
> displayed at ~6.16KiB on the x axis because that's how much it wrote.
> However, the red bar (read) hits 1797 on the y axis for 1797 reads as
> expected, but why does the x axis display 0 - 256B when there was 1.89 KiB
> read in total?
>
> A couple of formatting nits:
>
> 1. There are some unused imports in the DataPageToolkit
>
> [...]
> +import org.openjdk.jmc.flightrecorder.ui.PageManager;
> [...]
> +import org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage;+import org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage.ItemHandlerUiStandIn;
> [...]
>
> 2. Excess white space just before (and inside)
> DataPageToolkit.buildSizeHistogram()
> 3. JDKAttributes, SocketIO & FileIO pages also each have a few instances
> of excess/trailing white space
>
>
>>
>> Thanks,
>>
>> Ken Dobson
>>
>
> Cheers,
>
> Alex
>
> [0] https://imgur.com/sPo9Xeo
>

From kdobson at redhat.com  Fri Apr  5 19:56:39 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Fri, 5 Apr 2019 15:56:39 -0400
Subject: Review request for JMC-4645: Add size distribution chart to IO
 Pages
In-Reply-To: <CADPaBqk22qqFQsZ8x0ygnaU+4HZnBPh6zsOAZsmVK01j1QofXg@mail.gmail.com>
References: <CADPaBq=wDCPdznYD=BECUoBKU8jYB54e1q5CqR9s-Kp5MBNqbA@mail.gmail.com>
 <CAOsn=kr9a--EyCd91O5--jykiGrdOHeHjRC0D4gmEQ1vDdhDzw@mail.gmail.com>
 <CADPaBqk22qqFQsZ8x0ygnaU+4HZnBPh6zsOAZsmVK01j1QofXg@mail.gmail.com>
Message-ID: <CADPaBqmRB7-w19fKDi9Dj7xnRPKzfUZvY04FGBfCVB7YrnGWYQ@mail.gmail.com>

And here is an updated webrev that removes the unused imports and should
have no excess whitespace.

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

Addressing Alex's question about the distribution, there were 1797 socket
reads each of ~1B which adds up to a total of 1.89KiB read.

Thanks,

Ken Dobson

On Fri, Apr 5, 2019 at 3:49 PM Ken Dobson <kdobson at redhat.com> wrote:

> Here is the previous messages from this list for some reason they haven't
> shown up to the others on the list as well as the pipermail archives.
>
> From: Marcus Hirt <marcus.hirt at datadoghq.com>
> Date: Tue, Apr 2, 2019 at 10:55 PM
> Subject: Re: Review request for JMC-4645: Add size distribution chart to
> IO Pages
> To: Ken Dobson <kdobson at redhat.com>
> Cc: <jmc-dev at openjdk.java.net>
>
>
> Looks good!
>
> Kind regards,
> Marcus
>
> On Tue, Apr 2, 2019 at 4:51 PM Ken Dobson <kdobson at redhat.com> wrote:
>
>> Thanks for the review, here's the new webrev removing unnecessary
>> whitespace.
>>
>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart0/webrev
>>
>> Ken Dobson
>>
>> On Mon, Apr 1, 2019 at 9:27 PM Marcus Hirt <marcus.hirt at datadoghq.com>
>> wrote:
>>
>>> Hi Ken,
>>>
>>> It generally looks good, but:
>>>
>>>    - When I apply your patch, I see a lot of whitespace line endings.
>>>    Whilst we're not enforcing that there is no trailing whitespace, it would
>>>    be nice to avoid. E.g.
>>>
>>> [image: image.png]
>>>
>>>    - Is the reason for adding 64 bytes to the maxValue (if there is
>>>    one) cosmetic padding?
>>>      sizeMax = sizeMax == null ? UnitLookup.BYTE.quantity(64):
>>>    sizeMax.add(UnitLookup.BYTE.quantity(64));
>>>
>>> Kind regards,
>>> Marcus
>>>
>>> On Fri, Mar 29, 2019 at 4:07 PM Ken Dobson <kdobson at redhat.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Please review this patch I've made that adds a size distribution chart
>>>> to
>>>> the IO Pages.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
>>>>
>>>> Thanks,
>>>>
>>>> Ken Dobson
>>>>
>>>
> On Fri, Apr 5, 2019 at 2:36 PM Alex Macdonald <almacdon at redhat.com> wrote:
>
>> Hi Ken,
>>
>> On Fri, Mar 29, 2019 at 4:08 PM Ken Dobson <kdobson at redhat.com> wrote:
>>
>>> Hi all,
>>>
>>> Please review this patch I've made that adds a size distribution chart to
>>> the IO Pages.
>>>
>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
>>> Webrev:
>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
>>
>>
>> Overall the code looks good from what I can tell.
>>
>> Having said that, I just want to confirm what I'm reading off the chart,
>> let's use this sample screen shot [0] (https://imgur.com/sPo9Xeo) as an
>> example. The y-axis displays the number of reads/writes, and the x-axis
>> displays the size of that read or write? If that's the case I'm a bit
>> confused. The blue bar (write) hits 1 on the y axis for 1 read, and is
>> displayed at ~6.16KiB on the x axis because that's how much it wrote.
>> However, the red bar (read) hits 1797 on the y axis for 1797 reads as
>> expected, but why does the x axis display 0 - 256B when there was 1.89 KiB
>> read in total?
>>
>> A couple of formatting nits:
>>
>> 1. There are some unused imports in the DataPageToolkit
>>
>> [...]
>> +import org.openjdk.jmc.flightrecorder.ui.PageManager;
>> [...]
>> +import org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage;+import org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage.ItemHandlerUiStandIn;
>> [...]
>>
>> 2. Excess white space just before (and inside)
>> DataPageToolkit.buildSizeHistogram()
>> 3. JDKAttributes, SocketIO & FileIO pages also each have a few instances
>> of excess/trailing white space
>>
>>
>>>
>>> Thanks,
>>>
>>> Ken Dobson
>>>
>>
>> Cheers,
>>
>> Alex
>>
>> [0] https://imgur.com/sPo9Xeo
>>
>

From deepa.avhad at oracle.com  Mon Apr  8 06:34:07 2019
From: deepa.avhad at oracle.com (Deepa Avhad)
Date: Sun, 7 Apr 2019 23:34:07 -0700 (PDT)
Subject: Review Request for JMC-5366 : Abort generating of a page if the user
 switches to another.
Message-ID: <f18f17d5-da43-4365-9f08-7ed4c4ea0053@default>

Hi All,

Please review the fix for JMC-5366.

JIRA   : https://bugs.openjdk.java.net/browse/JMC-5366
Webrev : http://cr.openjdk.java.net/~ghb/davhad/JMC-5366/webrev_00/

Solution:  When navigating views the selection changes frequently - especially when the keyboard is used to scroll through long
           lists or the mouse is dragged over some text. This will lead to many unnecessary updates of the viewers registered, 
           making application less responsive.
           So use of post selection events will be send-out with a slight delay. All intermediate selections during the delay time
           are ignored; just the final selection is propagated.
           Example: (addPostSelectionListener(ISelectionListener listener) ).


Thanks,
Deepa

From marcus at hirt.se  Mon Apr  8 10:49:55 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Mon, 8 Apr 2019 12:49:55 +0200
Subject: SV: Review Request for JMC-5366 : Abort generating of a page if the
 user switches to another.
In-Reply-To: <f18f17d5-da43-4365-9f08-7ed4c4ea0053@default>
References: <f18f17d5-da43-4365-9f08-7ed4c4ea0053@default>
Message-ID: <1358901d4edf8$cd7c3a50$6874aef0$@hirt.se>

Hi Deepa,

This only works for the keyboard, right?

>From the javadocs on the IPostSelectionProvider interface:
"Selection provider extension interface to allow providers to notify about 
post selection changed events. A post selection changed event is equivalent 
to selection changed event if the selection change was triggered by the mouse, 
but it has a delay if the selection change is triggered by keyboard navigation."

Please check with Markus Gr?nlund and Erik Gahlin to see if the solution 
solves their problem.

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Deepa Avhad
Skickat: den 8 april 2019 08:34
Till: Jmc-Dev <jmc-dev at openjdk.java.net>
?mne: Review Request for JMC-5366 : Abort generating of a page if the user switches to another.

Hi All,

Please review the fix for JMC-5366.

JIRA   : https://bugs.openjdk.java.net/browse/JMC-5366
Webrev : http://cr.openjdk.java.net/~ghb/davhad/JMC-5366/webrev_00/

Solution:  When navigating views the selection changes frequently - especially when the keyboard is used to scroll through long
           lists or the mouse is dragged over some text. This will lead to many unnecessary updates of the viewers registered, 
           making application less responsive.
           So use of post selection events will be send-out with a slight delay. All intermediate selections during the delay time
           are ignored; just the final selection is propagated.
           Example: (addPostSelectionListener(ISelectionListener listener) ).


Thanks,
Deepa


From erik.gahlin at oracle.com  Mon Apr  8 12:18:18 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 8 Apr 2019 14:18:18 +0200
Subject: SV: Review Request for JMC-5366 : Abort generating of a page if
 the user switches to another.
In-Reply-To: <1358901d4edf8$cd7c3a50$6874aef0$@hirt.se>
References: <f18f17d5-da43-4365-9f08-7ed4c4ea0053@default>
 <1358901d4edf8$cd7c3a50$6874aef0$@hirt.se>
Message-ID: <5CAB3C0A.5030601@oracle.com>

Hi Deepa,

Previously (4.x) there was a flag that would terminate a "view model 
builder" job, if a new task was started.

That way, it was possible to navigate quickly around, using both mouse 
and keyboard, and between tabs and tables/graphs. The background task 
would poll a terminated flag once every 100 000 event that was 
processed. It made the GUI very responsive, even with large recordings.

I haven't tried the current patch, so it is hard for me to compare, but 
waiting for a selection doesn't seem sufficient if there is a lot of 
data to process.

Have you tried with a recording with 10-20 million events?

Thanks
Erik

> Hi Deepa,
>
> This only works for the keyboard, right?
>
>  From the javadocs on the IPostSelectionProvider interface:
> "Selection provider extension interface to allow providers to notify about
> post selection changed events. A post selection changed event is equivalent
> to selection changed event if the selection change was triggered by the mouse,
> but it has a delay if the selection change is triggered by keyboard navigation."
>
> Please check with Markus Gr?nlund and Erik Gahlin to see if the solution
> solves their problem.
>
> Kind regards,
> Marcus
>
> -----Ursprungligt meddelande-----
> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Deepa Avhad
> Skickat: den 8 april 2019 08:34
> Till: Jmc-Dev <jmc-dev at openjdk.java.net>
> ?mne: Review Request for JMC-5366 : Abort generating of a page if the user switches to another.
>
> Hi All,
>
> Please review the fix for JMC-5366.
>
> JIRA   : https://bugs.openjdk.java.net/browse/JMC-5366
> Webrev : http://cr.openjdk.java.net/~ghb/davhad/JMC-5366/webrev_00/
>
> Solution:  When navigating views the selection changes frequently - especially when the keyboard is used to scroll through long
>             lists or the mouse is dragged over some text. This will lead to many unnecessary updates of the viewers registered,
>             making application less responsive.
>             So use of post selection events will be send-out with a slight delay. All intermediate selections during the delay time
>             are ignored; just the final selection is propagated.
>             Example: (addPostSelectionListener(ISelectionListener listener) ).
>
>
> Thanks,
> Deepa
>


From almacdon at redhat.com  Mon Apr  8 13:30:47 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Mon, 8 Apr 2019 09:30:47 -0400
Subject: Review request for JMC-4645: Add size distribution chart to IO
 Pages
In-Reply-To: <CADPaBqmRB7-w19fKDi9Dj7xnRPKzfUZvY04FGBfCVB7YrnGWYQ@mail.gmail.com>
References: <CADPaBq=wDCPdznYD=BECUoBKU8jYB54e1q5CqR9s-Kp5MBNqbA@mail.gmail.com>
 <CAOsn=kr9a--EyCd91O5--jykiGrdOHeHjRC0D4gmEQ1vDdhDzw@mail.gmail.com>
 <CADPaBqk22qqFQsZ8x0ygnaU+4HZnBPh6zsOAZsmVK01j1QofXg@mail.gmail.com>
 <CADPaBqmRB7-w19fKDi9Dj7xnRPKzfUZvY04FGBfCVB7YrnGWYQ@mail.gmail.com>
Message-ID: <CAOsn=ko0NBJB3+2RiAEzzC+HPMLL6ogZdZ1VvW090eV+YVSHKg@mail.gmail.com>

On Fri, Apr 5, 2019 at 3:56 PM Ken Dobson <kdobson at redhat.com> wrote:

> And here is an updated webrev that removes the unused imports and should
> have no excess whitespace.
>
> http://cr.openjdk.java.net/~kdobson/sizedistributionchart1/webrev/
>

Thanks, it looks good to me.


>
> Addressing Alex's question about the distribution, there were 1797 socket
> reads each of ~1B which adds up to a total of 1.89KiB read.
>
> Thanks,
>
> Ken Dobson
>
> On Fri, Apr 5, 2019 at 3:49 PM Ken Dobson <kdobson at redhat.com> wrote:
>
>> Here is the previous messages from this list for some reason they haven't
>> shown up to the others on the list as well as the pipermail archives.
>>
>> From: Marcus Hirt <marcus.hirt at datadoghq.com>
>> Date: Tue, Apr 2, 2019 at 10:55 PM
>> Subject: Re: Review request for JMC-4645: Add size distribution chart to
>> IO Pages
>> To: Ken Dobson <kdobson at redhat.com>
>> Cc: <jmc-dev at openjdk.java.net>
>>
>>
>> Looks good!
>>
>> Kind regards,
>> Marcus
>>
>> On Tue, Apr 2, 2019 at 4:51 PM Ken Dobson <kdobson at redhat.com> wrote:
>>
>>> Thanks for the review, here's the new webrev removing unnecessary
>>> whitespace.
>>>
>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart0/webrev
>>>
>>> Ken Dobson
>>>
>>> On Mon, Apr 1, 2019 at 9:27 PM Marcus Hirt <marcus.hirt at datadoghq.com>
>>> wrote:
>>>
>>>> Hi Ken,
>>>>
>>>> It generally looks good, but:
>>>>
>>>>    - When I apply your patch, I see a lot of whitespace line endings.
>>>>    Whilst we're not enforcing that there is no trailing whitespace, it would
>>>>    be nice to avoid. E.g.
>>>>
>>>> [image: image.png]
>>>>
>>>>    - Is the reason for adding 64 bytes to the maxValue (if there is
>>>>    one) cosmetic padding?
>>>>      sizeMax = sizeMax == null ? UnitLookup.BYTE.quantity(64):
>>>>    sizeMax.add(UnitLookup.BYTE.quantity(64));
>>>>
>>>> Kind regards,
>>>> Marcus
>>>>
>>>> On Fri, Mar 29, 2019 at 4:07 PM Ken Dobson <kdobson at redhat.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review this patch I've made that adds a size distribution chart
>>>>> to
>>>>> the IO Pages.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ken Dobson
>>>>>
>>>>
>> On Fri, Apr 5, 2019 at 2:36 PM Alex Macdonald <almacdon at redhat.com>
>> wrote:
>>
>>> Hi Ken,
>>>
>>> On Fri, Mar 29, 2019 at 4:08 PM Ken Dobson <kdobson at redhat.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Please review this patch I've made that adds a size distribution chart
>>>> to
>>>> the IO Pages.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
>>>
>>>
>>> Overall the code looks good from what I can tell.
>>>
>>> Having said that, I just want to confirm what I'm reading off the chart,
>>> let's use this sample screen shot [0] (https://imgur.com/sPo9Xeo) as an
>>> example. The y-axis displays the number of reads/writes, and the x-axis
>>> displays the size of that read or write? If that's the case I'm a bit
>>> confused. The blue bar (write) hits 1 on the y axis for 1 read, and is
>>> displayed at ~6.16KiB on the x axis because that's how much it wrote.
>>> However, the red bar (read) hits 1797 on the y axis for 1797 reads as
>>> expected, but why does the x axis display 0 - 256B when there was 1.89 KiB
>>> read in total?
>>>
>>> A couple of formatting nits:
>>>
>>> 1. There are some unused imports in the DataPageToolkit
>>>
>>> [...]
>>> +import org.openjdk.jmc.flightrecorder.ui.PageManager;
>>> [...]
>>> +import org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage;+import org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage.ItemHandlerUiStandIn;
>>> [...]
>>>
>>> 2. Excess white space just before (and inside)
>>> DataPageToolkit.buildSizeHistogram()
>>> 3. JDKAttributes, SocketIO & FileIO pages also each have a few instances
>>> of excess/trailing white space
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ken Dobson
>>>>
>>>
>>> Cheers,
>>>
>>> Alex
>>>
>>> [0] https://imgur.com/sPo9Xeo
>>>
>>

From guru.hb at oracle.com  Tue Apr  9 10:34:50 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 9 Apr 2019 16:04:50 +0530
Subject: Review request: JMC-6395: update jetty-maven-plugin from
 org.morbay.jetty to org.eclipse.jetty
Message-ID: <0AF3E43E-9814-4C88-8FF1-3215C37CD83C@oracle.com>

Hi,

Please review the fix for 
JBS : https://bugs.openjdk.java.net/browse/JMC-6395
 <https://bugs.openjdk.java.net/browse/JMC-6395>Web rev : http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.0/>
RC : updated jetty-maven-plugin to latest version (which is not maintained by eclipse community). 

Thanks,
Guru 

From marcus.hirt at datadoghq.com  Tue Apr  9 10:52:17 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 9 Apr 2019 12:52:17 +0200
Subject: Review request: JMC-6395: update jetty-maven-plugin from
 org.morbay.jetty to org.eclipse.jetty
In-Reply-To: <0AF3E43E-9814-4C88-8FF1-3215C37CD83C@oracle.com>
References: <0AF3E43E-9814-4C88-8FF1-3215C37CD83C@oracle.com>
Message-ID: <CAOpWGx2EiTYW41xVBs+JfXu99Zk8mhuUApOLhz1bi3a46D+zhA@mail.gmail.com>

Hi Guru,

The upgrade applies and builds properly, but the p2 site will no longer
start with mvn jetty:run. Some additional work will be required.

Kind regards,
Marcus

On Tue, Apr 9, 2019 at 12:36 PM Guru <guru.hb at oracle.com> wrote:

> Hi,
>
> Please review the fix for
> JBS : https://bugs.openjdk.java.net/browse/JMC-6395
> Web rev : http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.0/
> RC : updated jetty-maven-plugin to latest version (which is not maintained
> by eclipse community).
>
> Thanks,
> Guru
>

From guru.hb at oracle.com  Tue Apr  9 10:57:56 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 9 Apr 2019 16:27:56 +0530
Subject: Review request: JMC-6395: update jetty-maven-plugin from
 org.morbay.jetty to org.eclipse.jetty
In-Reply-To: <CAOpWGx2EiTYW41xVBs+JfXu99Zk8mhuUApOLhz1bi3a46D+zhA@mail.gmail.com>
References: <0AF3E43E-9814-4C88-8FF1-3215C37CD83C@oracle.com>
 <CAOpWGx2EiTYW41xVBs+JfXu99Zk8mhuUApOLhz1bi3a46D+zhA@mail.gmail.com>
Message-ID: <DE50C4B5-8BA2-4908-89C2-E6B6A9E6CBAF@oracle.com>

Thanks Marcus, 

Please find updated web rev : http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.1/ <http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.1/> 
RC : updated packaging type to ?war? instead of ?pom?. Updated jetty-maven-plugin expects deployable module to be of type ?war?. 

Thanks,
Guru 
> On 09-Apr-2019, at 4:22 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> 
> Hi Guru,
> 
> The upgrade applies and builds properly, but the p2 site will no longer start with mvn jetty:run. Some additional work will be required.
> 
> Kind regards,
> Marcus
> 
> On Tue, Apr 9, 2019 at 12:36 PM Guru <guru.hb at oracle.com <mailto:guru.hb at oracle.com>> wrote:
> Hi,
> 
> Please review the fix for 
> JBS : https://bugs.openjdk.java.net/browse/JMC-6395
>  <https://bugs.openjdk.java.net/browse/JMC-6395>Web rev : http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.0/>
> RC : updated jetty-maven-plugin to latest version (which is not maintained by eclipse community). 
> 
> Thanks,
> Guru 


From marcus at hirt.se  Tue Apr  9 11:26:02 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 9 Apr 2019 13:26:02 +0200
Subject: SV: Review request: JMC-6395: update jetty-maven-plugin from
 org.morbay.jetty to org.eclipse.jetty
In-Reply-To: <DE50C4B5-8BA2-4908-89C2-E6B6A9E6CBAF@oracle.com>
References: <0AF3E43E-9814-4C88-8FF1-3215C37CD83C@oracle.com>
 <CAOpWGx2EiTYW41xVBs+JfXu99Zk8mhuUApOLhz1bi3a46D+zhA@mail.gmail.com>
 <DE50C4B5-8BA2-4908-89C2-E6B6A9E6CBAF@oracle.com>
Message-ID: <1f4201d4eec7$034d30c0$09e79240$@hirt.se>

Hi Guru,

Looks good!

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Guru
Skickat: den 9 april 2019 12:58
Till: Marcus Hirt <marcus.hirt at datadoghq.com>; jmc-dev at openjdk.java.net
?mne: Re: Review request: JMC-6395: update jetty-maven-plugin from org.morbay.jetty to org.eclipse.jetty

Thanks Marcus, 

Please find updated web rev : http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.1/ <http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.1/> 
RC : updated packaging type to ?war? instead of ?pom?. Updated jetty-maven-plugin expects deployable module to be of type ?war?. 

Thanks,
Guru 
> On 09-Apr-2019, at 4:22 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> 
> Hi Guru,
> 
> The upgrade applies and builds properly, but the p2 site will no longer start with mvn jetty:run. Some additional work will be required.
> 
> Kind regards,
> Marcus
> 
> On Tue, Apr 9, 2019 at 12:36 PM Guru <guru.hb at oracle.com <mailto:guru.hb at oracle.com>> wrote:
> Hi,
> 
> Please review the fix for 
> JBS : https://bugs.openjdk.java.net/browse/JMC-6395
>  <https://bugs.openjdk.java.net/browse/JMC-6395>Web rev : http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6395/webrev.0/>
> RC : updated jetty-maven-plugin to latest version (which is not maintained by eclipse community). 
> 
> Thanks,
> Guru 



From guru.hb at oracle.com  Tue Apr  9 12:51:28 2019
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Tue, 09 Apr 2019 12:51:28 +0000
Subject: hg: jmc/jmc: JMC-6395: update jetty-maven-plugin from
 org.morbay.jetty to org.eclipse.jetty
Message-ID: <201904091251.x39CpSrI008627@aojmv0008.oracle.com>

Changeset: a43fa230b1bb
Author:    ghb <guru.hb at oracle.com>
Date:      2019-04-09 18:21 +0530
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/a43fa230b1bb

JMC-6395: update jetty-maven-plugin from org.morbay.jetty to org.eclipse.jetty
Reviewed-by: hirt <marcus at hirt.se>

! releng/third-party/pom.xml


From gerard.ziemski at oracle.com  Tue Apr  9 15:44:42 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Tue, 9 Apr 2019 10:44:42 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <6b9dcad0-5563-0e6b-1c37-c8a4c40d407a@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <e96eb0f3-8b88-f586-31b5-8a650f84acdd@oracle.com>
 <4862ac3f-f165-7d04-6248-514e588e70a2@oracle.com>
 <6b9dcad0-5563-0e6b-1c37-c8a4c40d407a@oracle.com>
Message-ID: <e51da881-763d-c26d-67fd-bf890f510514@oracle.com>

Thank you Coleen for more feedback!


On 4/9/19 9:43 AM, coleen.phillimore at oracle.com wrote:
>>> http://cr.openjdk.java.net/~gziemski/8185525_rev2/src/hotspot/share/utilities/statistics.hpp.html 
>>>
>>>
>>> Can you rename this file tableStatistics.cpp/hpp because 
>>> "statistics" is too general and the class is called TableStatistics.
>> I deliberately named the file "statistics.hpp", because I assume we 
>> will be adding more JFR events in the future, and this file could 
>> hold all the related code, which for now just comprises of table 
>> statistics as you pointed out.
>
> Hi I don't agree with that.? I think if you want more different JFR 
> statistics you could add files where they belong as 
> differentStatistics.hpp

Done.


>>> http://cr.openjdk.java.net/~gziemski/8185525_rev2/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp.udiff.html 
>>>
>>>
>>> Is there anyway to parameterize these functions and/or add them to 
>>> TableStatistics?
>> I didn't want to add JFR dependency to TableStatistics. I'm unsure 
>> what I can do more here, and whether it deserves the effort - 
>> TableStatistics basically serves as a struct for passing event 
>> attributes around, but I'm open to suggestions.
>>
>
> I didn't think this should be moved from jfrPeriodic.cpp.? I thought 
> it could be something like an X macro.
>
> Or just make this bit a function that they all call with event as 
> parameter.
>
> + event.set_numberOfBuckets(statistics._number_of_buckets);
> + event.set_numberOfEntries(statistics._number_of_entries);
> + event.set_totalFootprint(statistics._total_footprint);
> + event.set_maximumBucketCount(statistics._maximum_bucket_size);
> + event.set_averageBucketCount(statistics._average_bucket_size);
> + event.set_varianceOfBucketCount(statistics._variance_of_bucket_size);
> + event.set_stdDevOfBucketCount(statistics._stddev_of_bucket_size);
> + event.set_insertionRate(statistics._add_rate);
> + event.set_removalRate(statistics._remove_rate);
> + event.commit();

Each of those JFR events are an instance of a different class, so the 
best I can do is a macro here (otherwise I'd have to create a base class 
for the TableStatistics events from which to extend our 6 table events, 
but I'm not sure JFR architecture supports that - it generates class 
automatically from the event's meta description)

Updated webrev http://cr.openjdk.java.net/~gziemski/8185525_rev4/


cheers

From coleen.phillimore at oracle.com  Tue Apr  9 15:57:15 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 9 Apr 2019 11:57:15 -0400
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <e51da881-763d-c26d-67fd-bf890f510514@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <e96eb0f3-8b88-f586-31b5-8a650f84acdd@oracle.com>
 <4862ac3f-f165-7d04-6248-514e588e70a2@oracle.com>
 <6b9dcad0-5563-0e6b-1c37-c8a4c40d407a@oracle.com>
 <e51da881-763d-c26d-67fd-bf890f510514@oracle.com>
Message-ID: <72cbb5f1-c843-2995-12da-31eb22734c30@oracle.com>



On 4/9/19 11:44 AM, gerard ziemski wrote:
> Thank you Coleen for more feedback!
>
>
> On 4/9/19 9:43 AM, coleen.phillimore at oracle.com wrote:
>>>> http://cr.openjdk.java.net/~gziemski/8185525_rev2/src/hotspot/share/utilities/statistics.hpp.html 
>>>>
>>>>
>>>> Can you rename this file tableStatistics.cpp/hpp because 
>>>> "statistics" is too general and the class is called TableStatistics.
>>> I deliberately named the file "statistics.hpp", because I assume we 
>>> will be adding more JFR events in the future, and this file could 
>>> hold all the related code, which for now just comprises of table 
>>> statistics as you pointed out.
>>
>> Hi I don't agree with that.? I think if you want more different JFR 
>> statistics you could add files where they belong as 
>> differentStatistics.hpp
>
> Done.

Thanks!
>
>
>>>> http://cr.openjdk.java.net/~gziemski/8185525_rev2/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp.udiff.html 
>>>>
>>>>
>>>> Is there anyway to parameterize these functions and/or add them to 
>>>> TableStatistics?
>>> I didn't want to add JFR dependency to TableStatistics. I'm unsure 
>>> what I can do more here, and whether it deserves the effort - 
>>> TableStatistics basically serves as a struct for passing event 
>>> attributes around, but I'm open to suggestions.
>>>
>>
>> I didn't think this should be moved from jfrPeriodic.cpp.? I thought 
>> it could be something like an X macro.
>>
>> Or just make this bit a function that they all call with event as 
>> parameter.
>>
>> + event.set_numberOfBuckets(statistics._number_of_buckets);
>> + event.set_numberOfEntries(statistics._number_of_entries);
>> + event.set_totalFootprint(statistics._total_footprint);
>> + event.set_maximumBucketCount(statistics._maximum_bucket_size);
>> + event.set_averageBucketCount(statistics._average_bucket_size);
>> + event.set_varianceOfBucketCount(statistics._variance_of_bucket_size);
>> + event.set_stdDevOfBucketCount(statistics._stddev_of_bucket_size);
>> + event.set_insertionRate(statistics._add_rate);
>> + event.set_removalRate(statistics._remove_rate);
>> + event.commit();
>
> Each of those JFR events are an instance of a different class, so the 
> best I can do is a macro here (otherwise I'd have to create a base 
> class for the TableStatistics events from which to extend our 6 table 
> events, but I'm not sure JFR architecture supports that - it generates 
> class automatically from the event's meta description)
>
> Updated webrev http://cr.openjdk.java.net/~gziemski/8185525_rev4/

Yes, that looks better to me.

+ //statistics.print(tty, "SymbolTable");


You should remove commented out code.?? You can always add it back 
locally if you want to debug it again.? (I don't need to see this change).

thanks,
Coleen
>
>
> cheers


From marcus at hirt.se  Tue Apr  9 18:07:19 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Tue, 09 Apr 2019 18:07:19 +0000
Subject: hg: jmc/jmc: JMC-6442: Transform sampledThread attribute to
 eventThread attribute for NativeMethodSample events
Message-ID: <201904091807.x39I7Jdw006769@aojmv0008.oracle.com>

Changeset: b3e6820e4a77
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-04-09 20:07 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/b3e6820e4a77

JMC-6442: Transform sampledThread attribute to eventThread attribute for NativeMethodSample events
Reviewed-by: hirt
Contributed-by: klward

! 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/parser/synthetic/SyntheticAttributeExtension.java


From almacdon at redhat.com  Tue Apr  9 19:13:59 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Tue, 9 Apr 2019 15:13:59 -0400
Subject: RFR: JMC-4613 - Thread name striked out
Message-ID: <CAOsn=kqBpkEA9iTYBuNF0XZ8vW=Y1MMQuSzVzxWz=VcKDh4T-w@mail.gmail.com>

Hi,

The following webrev [0] addresses issue JMC-4613 [1], in which the line
drawn when hovering a thread lane on the Jfr Threads page could intersect
the name label for the thread.

The problem here was the vertical offset for displaying the thread name was
always given the value of 4. However, this could be insufficient for a
number of reasons, the first being that when viewing a few threads 1 to ~4
it didn't offer enough clearance for when the mouse hovers a thread lane -
the bottom of the lane extender clips the name of the thread [2].
Additionally, when there are a lot of threads on the page the labels can be
hard to read because there is no guarantee as to whether or not they will
be displayed in the middle of the row, or at the bottom of the row [3].

To amend this, a new vertical offset value is used in the cases where a
horizontal line is displayed under the thread name. This value if roughly
half the height of the string, and gives enough clearance to not get
intersected [4]. Additionally, when there are no line separators being
drawn the thread names will now be drawn in the middle of the row, which
should make them line up better with their respective lanes [5] and improve
readability when there are many threads on the chart [6].

Lastly, the thread names were previously only printed to the screen if the
height of their row was greater than 20 units. However, there could be
instances where there was enough space to display the names, as seen in the
comparison picture [7].

Thoughts?

Cheers,

Alex

[0] http://cr.openjdk.java.net/~aptmac/JMC-4613/webrev.00/
[1] https://bugs.openjdk.java.net/browse/JMC-4613
[2] https://imgur.com/RGpn4qS
[3] https://imgur.com/RiPEyui
[4] https://imgur.com/6bXzT6g
[5] https://imgur.com/qhFBbNz
[6] https://imgur.com/VByL3zQ
[7] https://imgur.com/JASaq2n

From erik.gahlin at oracle.com  Tue Apr  9 20:50:55 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 9 Apr 2019 22:50:55 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <b5a611ee-c72f-d7ab-c01f-c833ee94f2ce@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>
Message-ID: <5CAD05AF.1090700@oracle.com>

Thanks Gerard,

In metadata.xml (and possible elsewhere) can you change the fields

"varianceOfBucketCount" to "bucketCountVariance"
"stdDevOfBucketCount" to "bucketCountStandardDeviation"

I noticed that events are only emitted if we are able to take the resize 
lock. Can this be fixed? What prevents us from always getting the data? 
That's how other periodic events work and losing data sometimes may lead 
to subtle bugs that hard to understand and replicate in systems that 
rely on the information. Could we retry on a failure?

If it is very problematic to fix, it may be OK to skip the events, but 
then tests would need to be updated to take that into account 
(retrying). Otherwise we may get intermittent failures.

Thanks
Erik

> hi Erik,
>
>
> On 4/3/19 12:44 PM, Erik Gahlin wrote:
>> Hi Gerard,
>>
>> Here are some comments about the metadata (to make it consistent with 
>> other events).
>>
>> The events should not be in the "Java Application" category since 
>> they are JVM events. You could perhaps put them in "Java Virtual 
>> Machine, Runtime, Tables". Some comments about the names and labels 
>> of fields.
>>
>> - Label: Number of buckets => Bucket Count
>> - Label: Number of entries => Entry Count
>> - Label: Total footprint => Total Footprint
>>
>> Could you remove descriptions that are exactly the same as the label.
>>
>> - Label: Maximum bucket size => Maximum Bucket Size
>> - Label: Average bucket size => Average Bucket Size
>> - Label: Variance of bucket  size => Bucket Size Variance
>> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
>> - Label: Standard deviation of bucket size => Bucket Size Standard 
>> Deviation"
>>
>> Instead of using the word "size", it may make more sense to use the 
>> word "count" here as well, i.e "Average Bucket Count", or maybe I'm 
>> missing something? Is there a difference?
>>
>> I wonder how useful standard deviation and variance is? If support 
>> engineers are looking at a recording, or JMC adds a rule for the 
>> events, what would a good or bad value be? Is it possible to use the 
>> information for troubleshooting?
>
> While I'm working on all the above changes you suggested, we can 
> discuss the standard devation and variance.
>
> I added them because they are part of the jcmd "VM.symboltable 
> -verbose" command, so we are consistent.
>
> Now, regarding how useful they are, I always understood them as a sign 
> of imbalanced table distribution, and without a proper histogram, this 
> is the best description of the histogram shape. In reality, however, I 
> think that if they identify an issue, then we might have a very 
> curious distribution (some sort of hash table attack), or we have an 
> issue with our hash function for the particular usage case.
>
> Still, I'd personally elect to keep them.
>
> Let me ask you a different question though, Is it expensive to have 2 
> doubles as part of an event (5 events per second)? And if so, is there 
> currently (or planned) granularity for controlling not just which 
> events to record, but also which attributes?
>
>>
>> - Name: addRate => insertionRate
>> - Label: Rate of addition =>  Insertation Rate
>> - Name: removeRate => removalRate
>> - Label: Rate of removal => Removal Rate
>
> Will do.
>
>>
>> I'm missing unit tests for the events. Could you please add in 
>> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
>> average not exceeding max, no negative values etc.
>
> Working on it, do we need separate test per each event (table), or 
> just one table will suffice (ex. StringTable)?
>
> Thank you for the feedback!
>
>
> cheers
>>
>> Thanks!
>> Erik
>>
>>> Hi all,
>>>
>>> Please review this feature, which adds tracing events for the 
>>> internal hash tables.
>>>
>>> The following attributes are implemented:
>>>
>>> <Field type="ulong" name="numberOfBuckets" label="Number of buckets" 
>>> description="Number of buckets" />
>>> <Field type="ulong" name="numberOfEntries" label="Number of entries" 
>>> description="Number of all entries" />
>>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>>> label="Total footprint" description="Total memory footprint (the 
>>> table itself plus all of the entries)" />
>>> <Field type="ulong" name="maximumBucketSize" label="Maximum bucket 
>>> size" description="The maximum bucket length (entries in a single 
>>> bucket)" />
>>> <Field type="double" name="averageBucketSize" label="Average bucket 
>>> size" description="The average bucket length (entries in a bucket)" 
>>> /> <Field type="double" name="varianceOfBucketSize" label="Variance 
>>> of bucket sizes" description="How far bucket lengths are spread out 
>>> from their average value" />
>>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>>> deviation of bucket sizes" description="How far bucket lengths are 
>>> spread out from their mean (expected) value" />
>>> <Field type="double" name="addRate" label="Rate of addition" 
>>> description="How many items were added since last event (per 
>>> second)" />
>>> <Field type="double" name="removeRate" label="Rate of removal" 
>>> description="How many items were removed since last event (per 
>>> second)" />
>>>
>>> This event was implemented for the following system tables:
>>>
>>> SymbolTable
>>> StringTable
>>> Placeholder Table
>>> LoaderConstraints Table
>>> ProtectionDomainCache Table
>>>
>>> Webrev:  http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>>> Bug:     https://bugs.openjdk.java.net/browse/JDK-8185525
>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in progress?)
>>>
>>>
>>> Cheers
>>>
>>
>>
>


From gerard.ziemski at oracle.com  Wed Apr 10 17:06:17 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Wed, 10 Apr 2019 12:06:17 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CAD05AF.1090700@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>
Message-ID: <2404c7a6-b701-bba9-a2d2-a0b3232cde7e@oracle.com>

Thank you Erik for more feedback.

New webrev:? http://cr.openjdk.java.net/~gziemski/8185525_rev5


On 4/9/19 3:50 PM, Erik Gahlin wrote:
> Thanks Gerard,
>
> In metadata.xml (and possible elsewhere) can you change the fields
>
> "varianceOfBucketCount" to "bucketCountVariance"
> "stdDevOfBucketCount" to "bucketCountStandardDeviation"

I changed those, but I also changed:

"maximumBucketCount" to "bucketCountMaximum"
"averageBucketCount" to "bucketCountAverage"

to be fully consistent.


>
> I noticed that events are only emitted if we are able to take the 
> resize lock. Can this be fixed? What prevents us from always getting 
> the data? That's how other periodic events work and losing data 
> sometimes may lead to subtle bugs that hard to understand and 
> replicate in systems that rely on the information. Could we retry on a 
> failure?
Good observation. If the resize lock is taken, then it's not likely that 
whoever owns it will be done soon, so retrying is most likely not going 
to succeed right away. Is it OK to tie up JFR periodic thread for some 
time? If so, how long?

If the lock is taken, then it means that someone is scanning through the 
entire table, or the table is being resized. Either way, we're not 
loosing data, but are just temporarily blind - I don't see a problem 
here for a long running apps, they will start receiving events 
eventually (which happen every 10 sec by default)

>
> If it is very problematic to fix, it may be OK to skip the events, but 
> then tests would need to be updated to take that into account 
> (retrying). Otherwise we may get intermittent failures.
At the startup of our jtreg JFR test, no one, besides us, should take 
the lock, so if we don't get the event, because someone else is holding 
it (too small system hash table that gets resized up immediately after 
VM starts up), we probably would want to know about it, so a failure 
here might be in fact welcome.


cheers



>
> Thanks
> Erik
>
>> hi Erik,
>>
>>
>> On 4/3/19 12:44 PM, Erik Gahlin wrote:
>>> Hi Gerard,
>>>
>>> Here are some comments about the metadata (to make it consistent 
>>> with other events).
>>>
>>> The events should not be in the "Java Application" category since 
>>> they are JVM events. You could perhaps put them in "Java Virtual 
>>> Machine, Runtime, Tables". Some comments about the names and labels 
>>> of fields.
>>>
>>> - Label: Number of buckets => Bucket Count
>>> - Label: Number of entries => Entry Count
>>> - Label: Total footprint => Total Footprint
>>>
>>> Could you remove descriptions that are exactly the same as the label.
>>>
>>> - Label: Maximum bucket size => Maximum Bucket Size
>>> - Label: Average bucket size => Average Bucket Size
>>> - Label: Variance of bucket? size => Bucket Size Variance
>>> - Name: stdDevOfBucketSize => bucketSizeStandardDeviation
>>> - Label: Standard deviation of bucket size => Bucket Size Standard 
>>> Deviation"
>>>
>>> Instead of using the word "size", it may make more sense to use the 
>>> word "count" here as well, i.e "Average Bucket Count", or maybe I'm 
>>> missing something? Is there a difference?
>>>
>>> I wonder how useful standard deviation and variance is? If support 
>>> engineers are looking at a recording, or JMC adds a rule for the 
>>> events, what would a good or bad value be? Is it possible to use the 
>>> information for troubleshooting?
>>
>> While I'm working on all the above changes you suggested, we can 
>> discuss the standard devation and variance.
>>
>> I added them because they are part of the jcmd "VM.symboltable 
>> -verbose" command, so we are consistent.
>>
>> Now, regarding how useful they are, I always understood them as a 
>> sign of imbalanced table distribution, and without a proper 
>> histogram, this is the best description of the histogram shape. In 
>> reality, however, I think that if they identify an issue, then we 
>> might have a very curious distribution (some sort of hash table 
>> attack), or we have an issue with our hash function for the 
>> particular usage case.
>>
>> Still, I'd personally elect to keep them.
>>
>> Let me ask you a different question though, Is it expensive to have 2 
>> doubles as part of an event (5 events per second)? And if so, is 
>> there currently (or planned) granularity for controlling not just 
>> which events to record, but also which attributes?
>>
>>>
>>> - Name: addRate => insertionRate
>>> - Label: Rate of addition =>? Insertation Rate
>>> - Name: removeRate => removalRate
>>> - Label: Rate of removal => Removal Rate
>>
>> Will do.
>>
>>>
>>> I'm missing unit tests for the events. Could you please add in 
>>> /test/jdk/jdk/jfr/event/runtime. They can be sanity tests. i.e the 
>>> average not exceeding max, no negative values etc.
>>
>> Working on it, do we need separate test per each event (table), or 
>> just one table will suffice (ex. StringTable)?
>>
>> Thank you for the feedback!
>>
>>
>> cheers
>>>
>>> Thanks!
>>> Erik
>>>
>>>> Hi all,
>>>>
>>>> Please review this feature, which adds tracing events for the 
>>>> internal hash tables.
>>>>
>>>> The following attributes are implemented:
>>>>
>>>> <Field type="ulong" name="numberOfBuckets" label="Number of 
>>>> buckets" description="Number of buckets" />
>>>> <Field type="ulong" name="numberOfEntries" label="Number of 
>>>> entries" description="Number of all entries" />
>>>> <Field type="ulong" contentType="bytes" name="totalFootprint" 
>>>> label="Total footprint" description="Total memory footprint (the 
>>>> table itself plus all of the entries)" />
>>>> <Field type="ulong" name="maximumBucketSize" label="Maximum bucket 
>>>> size" description="The maximum bucket length (entries in a single 
>>>> bucket)" />
>>>> <Field type="double" name="averageBucketSize" label="Average bucket 
>>>> size" description="The average bucket length (entries in a bucket)" 
>>>> /> <Field type="double" name="varianceOfBucketSize" label="Variance 
>>>> of bucket sizes" description="How far bucket lengths are spread out 
>>>> from their average value" />
>>>> <Field type="double" name="stdDevOfBucketSize" label="Standard 
>>>> deviation of bucket sizes" description="How far bucket lengths are 
>>>> spread out from their mean (expected) value" />
>>>> <Field type="double" name="addRate" label="Rate of addition" 
>>>> description="How many items were added since last event (per 
>>>> second)" />
>>>> <Field type="double" name="removeRate" label="Rate of removal" 
>>>> description="How many items were removed since last event (per 
>>>> second)" />
>>>>
>>>> This event was implemented for the following system tables:
>>>>
>>>> SymbolTable
>>>> StringTable
>>>> Placeholder Table
>>>> LoaderConstraints Table
>>>> ProtectionDomainCache Table
>>>>
>>>> Webrev:? http://cr.openjdk.java.net/~gziemski/8185525_rev1/
>>>> Bug:???? https://bugs.openjdk.java.net/browse/JDK-8185525
>>>> Testing: Mach5 tier1,2,3 (another Mach5 tier1,2,3,4,5,6,7 in 
>>>> progress?)
>>>>
>>>>
>>>> Cheers
>>>>
>>>
>>>
>>
>
>


From gerard.ziemski at oracle.com  Wed Apr 10 17:10:00 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Wed, 10 Apr 2019 12:10:00 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <72cbb5f1-c843-2995-12da-31eb22734c30@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <e96eb0f3-8b88-f586-31b5-8a650f84acdd@oracle.com>
 <4862ac3f-f165-7d04-6248-514e588e70a2@oracle.com>
 <6b9dcad0-5563-0e6b-1c37-c8a4c40d407a@oracle.com>
 <e51da881-763d-c26d-67fd-bf890f510514@oracle.com>
 <72cbb5f1-c843-2995-12da-31eb22734c30@oracle.com>
Message-ID: <6ba4c5dc-1346-d377-808d-05c16c769e3b@oracle.com>

Thank you Coleen!


On 4/9/19 10:57 AM, coleen.phillimore at oracle.com wrote:
>>>
>>> I didn't think this should be moved from jfrPeriodic.cpp.? I thought 
>>> it could be something like an X macro.
>>>
>>> Or just make this bit a function that they all call with event as 
>>> parameter.
>>>
>>> + event.set_numberOfBuckets(statistics._number_of_buckets);
>>> + event.set_numberOfEntries(statistics._number_of_entries);
>>> + event.set_totalFootprint(statistics._total_footprint);
>>> + event.set_maximumBucketCount(statistics._maximum_bucket_size);
>>> + event.set_averageBucketCount(statistics._average_bucket_size);
>>> + event.set_varianceOfBucketCount(statistics._variance_of_bucket_size);
>>> + event.set_stdDevOfBucketCount(statistics._stddev_of_bucket_size);
>>> + event.set_insertionRate(statistics._add_rate);
>>> + event.set_removalRate(statistics._remove_rate);
>>> + event.commit();
>>
>> Each of those JFR events are an instance of a different class, so the 
>> best I can do is a macro here (otherwise I'd have to create a base 
>> class for the TableStatistics events from which to extend our 6 table 
>> events, but I'm not sure JFR architecture supports that - it 
>> generates class automatically from the event's meta description)
>>
>> Updated webrev http://cr.openjdk.java.net/~gziemski/8185525_rev4/
>
> Yes, that looks better to me.
>
> + //statistics.print(tty, "SymbolTable");
>
> You should remove commented out code.?? You can always add it back 
> locally if you want to debug it again.? (I don't need to see this change).

It was pointed out to me, that we can use templates instead of macro 
here, so I tried it and I like it:

http://cr.openjdk.java.net/~gziemski/8185525_rev5


cheers


From gerard.ziemski at oracle.com  Wed Apr 10 20:03:57 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Wed, 10 Apr 2019 15:03:57 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <7002f66b-49af-b38d-8d97-8642e684e998@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>
Message-ID: <b56d39a3-9bd7-4eb1-0208-199c9fbaa49f@oracle.com>



On 4/10/19 1:12 PM, coleen.phillimore at oracle.com wrote:
>>>
>>> I noticed that events are only emitted if we are able to take the 
>>> resize lock. Can this be fixed? What prevents us from always getting 
>>> the data? That's how other periodic events work and losing data 
>>> sometimes may lead to subtle bugs that hard to understand and 
>>> replicate in systems that rely on the information. Could we retry on 
>>> a failure?
>> Good observation. If the resize lock is taken, then it's not likely 
>> that whoever owns it will be done soon, so retrying is most likely 
>> not going to succeed right away. Is it OK to tie up JFR periodic 
>> thread for some time? If so, how long?
>>
>> If the lock is taken, then it means that someone is scanning through 
>> the entire table, or the table is being resized. Either way, we're 
>> not loosing data, but are just temporarily blind - I don't see a 
>> problem here for a long running apps, they will start receiving 
>> events eventually (which happen every 10 sec by default)
>
> Robbin was talking about allowing scanning the table while resizing, 
> ie. not having the resize_lock, if we can accept that there might be 
> some entries double counted.

Yes, we could do that - are you suggesting that this is what we should 
do? Personally, I think I'd prefer not to emit the event at all, rather 
than emit one that might be wrong (that's exactly what we do currently 
for jcmd print statistics).

Erik, Robbin, do you have a preference here?


cheers


From coleen.phillimore at oracle.com  Wed Apr 10 21:56:09 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 10 Apr 2019 17:56:09 -0400
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <b56d39a3-9bd7-4eb1-0208-199c9fbaa49f@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>
Message-ID: <9b492479-5f03-47a9-bb6b-014cee395545@oracle.com>



On 4/10/19 4:03 PM, gerard ziemski wrote:
>
>
> On 4/10/19 1:12 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>> I noticed that events are only emitted if we are able to take the 
>>>> resize lock. Can this be fixed? What prevents us from always 
>>>> getting the data? That's how other periodic events work and losing 
>>>> data sometimes may lead to subtle bugs that hard to understand and 
>>>> replicate in systems that rely on the information. Could we retry 
>>>> on a failure?
>>> Good observation. If the resize lock is taken, then it's not likely 
>>> that whoever owns it will be done soon, so retrying is most likely 
>>> not going to succeed right away. Is it OK to tie up JFR periodic 
>>> thread for some time? If so, how long?
>>>
>>> If the lock is taken, then it means that someone is scanning through 
>>> the entire table, or the table is being resized. Either way, we're 
>>> not loosing data, but are just temporarily blind - I don't see a 
>>> problem here for a long running apps, they will start receiving 
>>> events eventually (which happen every 10 sec by default)
>>
>> Robbin was talking about allowing scanning the table while resizing, 
>> ie. not having the resize_lock, if we can accept that there might be 
>> some entries double counted.
>
> Yes, we could do that - are you suggesting that this is what we should 
> do? 

Not for this change.
Coleen

> Personally, I think I'd prefer not to emit the event at all, rather 
> than emit one that might be wrong (that's exactly what we do currently 
> for jcmd print statistics).
>
> Erik, Robbin, do you have a preference here?
>
>
> cheers
>


From coleen.phillimore at oracle.com  Wed Apr 10 22:01:45 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 10 Apr 2019 18:01:45 -0400
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <6ba4c5dc-1346-d377-808d-05c16c769e3b@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <e96eb0f3-8b88-f586-31b5-8a650f84acdd@oracle.com>
 <4862ac3f-f165-7d04-6248-514e588e70a2@oracle.com>
 <6b9dcad0-5563-0e6b-1c37-c8a4c40d407a@oracle.com>
 <e51da881-763d-c26d-67fd-bf890f510514@oracle.com>
 <72cbb5f1-c843-2995-12da-31eb22734c30@oracle.com>
 <6ba4c5dc-1346-d377-808d-05c16c769e3b@oracle.com>
Message-ID: <ed19f0bc-d772-6f41-e341-516aaaecdd78@oracle.com>


http://cr.openjdk.java.net/~gziemski/8185525_rev5/src/hotspot/share/utilities/tableStatistics.cpp.html

Sorry I didn't notice this before but these constructors should have 
initializers like:

   31 TableRateStatistics::TableRateStatistics() {
   32   _added_items = 0;
   33   _removed_items = 0;
   34
   35   _time_stamp = 0;
   36   _seconds_stamp = 0.0;
   37   _added_items_stamp = 0;
   38   _added_items_stamp_prev = 0;
   39   _removed_items_stamp = 0;
   40   _removed_items_stamp_prev = 0;
   41 }

Should be:

   31 TableRateStatistics::TableRateStatistics() :
   32   _added_items(0), _removed_items(0), _time_stamp(0), etc. {}

Kim could tell you why this is better but he's on vacation.

http://cr.openjdk.java.net/~gziemski/8185525_rev5/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp.udiff.html

The template looks great!

Thanks,
Coleen

On 4/10/19 1:10 PM, gerard ziemski wrote:
> Thank you Coleen!
>
>
> On 4/9/19 10:57 AM, coleen.phillimore at oracle.com wrote:
>>>>
>>>> I didn't think this should be moved from jfrPeriodic.cpp.? I 
>>>> thought it could be something like an X macro.
>>>>
>>>> Or just make this bit a function that they all call with event as 
>>>> parameter.
>>>>
>>>> + event.set_numberOfBuckets(statistics._number_of_buckets);
>>>> + event.set_numberOfEntries(statistics._number_of_entries);
>>>> + event.set_totalFootprint(statistics._total_footprint);
>>>> + event.set_maximumBucketCount(statistics._maximum_bucket_size);
>>>> + event.set_averageBucketCount(statistics._average_bucket_size);
>>>> + event.set_varianceOfBucketCount(statistics._variance_of_bucket_size);
>>>> + event.set_stdDevOfBucketCount(statistics._stddev_of_bucket_size);
>>>> + event.set_insertionRate(statistics._add_rate);
>>>> + event.set_removalRate(statistics._remove_rate);
>>>> + event.commit();
>>>
>>> Each of those JFR events are an instance of a different class, so 
>>> the best I can do is a macro here (otherwise I'd have to create a 
>>> base class for the TableStatistics events from which to extend our 6 
>>> table events, but I'm not sure JFR architecture supports that - it 
>>> generates class automatically from the event's meta description)
>>>
>>> Updated webrev http://cr.openjdk.java.net/~gziemski/8185525_rev4/
>>
>> Yes, that looks better to me.
>>
>> + //statistics.print(tty, "SymbolTable");
>>
>> You should remove commented out code.?? You can always add it back 
>> locally if you want to debug it again.? (I don't need to see this 
>> change).
>
> It was pointed out to me, that we can use templates instead of macro 
> here, so I tried it and I like it:
>
> http://cr.openjdk.java.net/~gziemski/8185525_rev5
>
>
> cheers
>


From neugens at redhat.com  Thu Apr 11 11:36:38 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 11 Apr 2019 13:36:38 +0200
Subject: On the subject of releases (and can we please call 7.0 done and
 move forward?)
Message-ID: <54f11bb9a63e601e32db73a3233999144ad5cbc7.camel@redhat.com>

Hi all,

I have a small (but important) issue that we should address and solve.

Initially, we discussed the release schedule for Mission Control to
something following more or less the releases of OpenJDKs, in
particular we had the idea to release JMC 7 for OpenJDK 11, 7.1 for
OpenJDK 12 etc.. with some alignment to what is being considered LTS
(although technically upstream OpenJDK doesn't really make such
distrinction) that makes the jump to a major version.

Now, this is mostly because of convenience, since some people tend to
rely on numbers to see what is what, in the world of JMC releases are
really very compatible with the underlying version of the JDK so if we
decide to alter this schema and do something else I'm happy either way.

The one problem however (that is the part were I'm less happy!) is that
we're still waiting for a 7.0 release, despite having forked jmc7
months ago and having the repository basically in minor maintainance
mode.

I think we should release a source drop now and obsolete the 7.0 fork
and call it done, and if we're still aiming at sync with OpenJDK, have
a 7.2 fork repository (we can skip 7.1 I guess?) as soon as possible so
we can match the OpenJDK 13 release while mainline continues to be
handled without major interruptions.

I think binary downstream releases should be handled like any other
downstream release of OpenJDK rather than block (wheter directly or
indirectly) the upstream releases, so in other world, we should be able
to independently close a line of development and make a release
whenever we're done.

Can we have our 7.0 now? :)

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  Thu Apr 11 13:39:18 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 11 Apr 2019 15:39:18 +0200
Subject: Current reviewer shortage.
Message-ID: <CAOpWGx3szD9ab9pBa9_VP-aS62zrnM=Xe5gL8bwbQnz1ZNm0nQ@mail.gmail.com>

Hi all,

Since all the reviewers are rather busy at the moment, I suggest we
continue with the policy that passing independent reviews by two
committers is enough to push. I'll try to pick up some of the slack in
the next few days!

Kind regards,
Marcus

From gerard.ziemski at oracle.com  Thu Apr 11 17:08:25 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 11 Apr 2019 12:08:25 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <ed19f0bc-d772-6f41-e341-516aaaecdd78@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <e96eb0f3-8b88-f586-31b5-8a650f84acdd@oracle.com>
 <4862ac3f-f165-7d04-6248-514e588e70a2@oracle.com>
 <6b9dcad0-5563-0e6b-1c37-c8a4c40d407a@oracle.com>
 <e51da881-763d-c26d-67fd-bf890f510514@oracle.com>
 <72cbb5f1-c843-2995-12da-31eb22734c30@oracle.com>
 <6ba4c5dc-1346-d377-808d-05c16c769e3b@oracle.com>
 <ed19f0bc-d772-6f41-e341-516aaaecdd78@oracle.com>
Message-ID: <83ea1c8d-09ab-2aa3-e3c9-8bd221727ebe@oracle.com>



On 4/10/19 5:01 PM, coleen.phillimore at oracle.com wrote:
>
> http://cr.openjdk.java.net/~gziemski/8185525_rev5/src/hotspot/share/utilities/tableStatistics.cpp.html
>
> Sorry I didn't notice this before but these constructors should have 
> initializers like:
>
>    31 TableRateStatistics::TableRateStatistics() {
>    32   _added_items = 0;
>    33   _removed_items = 0;
>    34
>    35   _time_stamp = 0;
>    36   _seconds_stamp = 0.0;
>    37   _added_items_stamp = 0;
>    38   _added_items_stamp_prev = 0;
>    39   _removed_items_stamp = 0;
>    40   _removed_items_stamp_prev = 0;
>    41 }
> Should be:
>    31 TableRateStatistics::TableRateStatistics() :
>    32   _added_items(0), _removed_items(0), _time_stamp(0), etc. {}
> Kim could tell you why this is better but he's on vacation.

Done.

I also went back to src/hotspot/share/jfr/periodic/jfrPeriodic.cpp and 
changed TableEventFiller::fill() to be static, since we don't actually 
need an instance of TableEventFiller to do its job.

webrev: http://cr.openjdk.java.net/~gziemski/8185525_rev6


cheers

From coleen.phillimore at oracle.com  Thu Apr 11 17:58:19 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 11 Apr 2019 13:58:19 -0400
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <83ea1c8d-09ab-2aa3-e3c9-8bd221727ebe@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>
 <5CA649FE.9070904@oracle.com>
 <c80a1a3c-852c-b119-0fd6-23070dafdb18@oracle.com>
 <e96eb0f3-8b88-f586-31b5-8a650f84acdd@oracle.com>
 <4862ac3f-f165-7d04-6248-514e588e70a2@oracle.com>
 <6b9dcad0-5563-0e6b-1c37-c8a4c40d407a@oracle.com>
 <e51da881-763d-c26d-67fd-bf890f510514@oracle.com>
 <72cbb5f1-c843-2995-12da-31eb22734c30@oracle.com>
 <6ba4c5dc-1346-d377-808d-05c16c769e3b@oracle.com>
 <ed19f0bc-d772-6f41-e341-516aaaecdd78@oracle.com>
 <83ea1c8d-09ab-2aa3-e3c9-8bd221727ebe@oracle.com>
Message-ID: <262b4365-fef8-3caa-7e32-f4bf5097dbc4@oracle.com>



On 4/11/19 1:08 PM, gerard ziemski wrote:
>
>
> On 4/10/19 5:01 PM, coleen.phillimore at oracle.com wrote:
>>
>> http://cr.openjdk.java.net/~gziemski/8185525_rev5/src/hotspot/share/utilities/tableStatistics.cpp.html
>>
>> Sorry I didn't notice this before but these constructors should have 
>> initializers like:
>>
>>    31 TableRateStatistics::TableRateStatistics() {
>>    32   _added_items = 0;
>>    33   _removed_items = 0;
>>    34
>>    35   _time_stamp = 0;
>>    36   _seconds_stamp = 0.0;
>>    37   _added_items_stamp = 0;
>>    38   _added_items_stamp_prev = 0;
>>    39   _removed_items_stamp = 0;
>>    40   _removed_items_stamp_prev = 0;
>>    41 }
>> Should be:
>>    31 TableRateStatistics::TableRateStatistics() :
>>    32   _added_items(0), _removed_items(0), _time_stamp(0), etc. {}
>> Kim could tell you why this is better but he's on vacation.
>
> Done.
>
> I also went back to src/hotspot/share/jfr/periodic/jfrPeriodic.cpp and 
> changed TableEventFiller::fill() to be static, since we don't actually 
> need an instance of TableEventFiller to do its job.
>
> webrev: http://cr.openjdk.java.net/~gziemski/8185525_rev6
>
>

Yes, this looks really good!
Thanks,
Coleen
> cheers


From marcus at hirt.se  Fri Apr 12 13:35:15 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 12 Apr 2019 15:35:15 +0200
Subject: SV: JMC-4613 - Thread name striked out
In-Reply-To: <CAOsn=kqBpkEA9iTYBuNF0XZ8vW=Y1MMQuSzVzxWz=VcKDh4T-w@mail.gmail.com>
References: <CAOsn=kqBpkEA9iTYBuNF0XZ8vW=Y1MMQuSzVzxWz=VcKDh4T-w@mail.gmail.com>
Message-ID: <624601d4f134$8fed3d30$afc7b790$@hirt.se>

Looks good Alex! Thank you for the contribution!

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Alex Macdonald
Skickat: den 9 april 2019 21:14
Till: jmc-dev at openjdk.java.net
?mne: RFR: JMC-4613 - Thread name striked out

Hi,

The following webrev [0] addresses issue JMC-4613 [1], in which the line drawn when hovering a thread lane on the Jfr Threads page could intersect the name label for the thread.

The problem here was the vertical offset for displaying the thread name was always given the value of 4. However, this could be insufficient for a number of reasons, the first being that when viewing a few threads 1 to ~4 it didn't offer enough clearance for when the mouse hovers a thread lane - the bottom of the lane extender clips the name of the thread [2].
Additionally, when there are a lot of threads on the page the labels can be hard to read because there is no guarantee as to whether or not they will be displayed in the middle of the row, or at the bottom of the row [3].

To amend this, a new vertical offset value is used in the cases where a horizontal line is displayed under the thread name. This value if roughly half the height of the string, and gives enough clearance to not get intersected [4]. Additionally, when there are no line separators being drawn the thread names will now be drawn in the middle of the row, which should make them line up better with their respective lanes [5] and improve readability when there are many threads on the chart [6].

Lastly, the thread names were previously only printed to the screen if the height of their row was greater than 20 units. However, there could be instances where there was enough space to display the names, as seen in the comparison picture [7].

Thoughts?

Cheers,

Alex

[0] http://cr.openjdk.java.net/~aptmac/JMC-4613/webrev.00/
[1] https://bugs.openjdk.java.net/browse/JMC-4613
[2] https://imgur.com/RGpn4qS
[3] https://imgur.com/RiPEyui
[4] https://imgur.com/6bXzT6g
[5] https://imgur.com/qhFBbNz
[6] https://imgur.com/VByL3zQ
[7] https://imgur.com/JASaq2n


From jkang at redhat.com  Fri Apr 12 14:00:05 2019
From: jkang at redhat.com (Jie Kang)
Date: Fri, 12 Apr 2019 10:00:05 -0400
Subject: RFR: Fix name of JDK Flight Recorder feature
Message-ID: <CAEBeOco_qu+LHafOGOKUU8DwNtsBiuoBOtVpJbb8puKGJu1BYg@mail.gmail.com>

Hi,

This patch, pasted below, changes the name of the feature from "Oracle
JDK Flight Recorder" to "JDK Flight Recorder", matching it's
description.

I'm not sure if the inclusion of Oracle in the name is intentional.
Does this fix make sense?

diff --git a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
b/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
--- a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
+++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
@@ -30,7 +30,7 @@
 #  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY
 #  WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
 #
-name=Oracle JDK Flight Recorder
+name=JDK Flight Recorder
 provider=Oracle Corporation
 copyright=Copyright \u00A9 2018, 2019, Oracle and/or its affiliates.
All rights reserved.
 description=The JDK Flight Recorder feature contains all the JFR
related plug-ins.


Regards,

From neugens at redhat.com  Fri Apr 12 14:02:31 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 12 Apr 2019 16:02:31 +0200
Subject: Current reviewer shortage.
In-Reply-To: <CAOpWGx3szD9ab9pBa9_VP-aS62zrnM=Xe5gL8bwbQnz1ZNm0nQ@mail.gmail.com>
References: <CAOpWGx3szD9ab9pBa9_VP-aS62zrnM=Xe5gL8bwbQnz1ZNm0nQ@mail.gmail.com>
Message-ID: <b3f1278da8680ff960d3d338a94f0dc19a9e0ca4.camel@redhat.com>

On Thu, 2019-04-11 at 15:39 +0200, Marcus Hirt wrote:
> Hi all,
> 
> Since all the reviewers are rather busy at the moment, I suggest we
> continue with the policy that passing independent reviews by two
> committers is enough to push. I'll try to pick up some of the slack
> in
> the next few days!

Makes sense for me. This isn't really a problem (oh, well...) from the
goverance POW, since each project is free to choose rules about how to
carry on reviews etc...

I would like to have this in the project page however, just to be sure
it's accessible somewhere easily (the mailing list is of course "on the
record" enough, but it's a bit cumbersome to go and search rules
scattered around emails).

Do you think that would be possible? If not the wiki should be enough
too.

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  Fri Apr 12 14:03:19 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 12 Apr 2019 16:03:19 +0200
Subject: CFV: New jmc Committer: Alex Macdonald
Message-ID: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>

I hereby nominate Alex Macdonald to jmc Committer.

Alex has been a prolific contributor to JDK Mission Control over the
past months, with 9 contributions and more in the work (or waiting for
review), with his most recent contributions tackling the complex issue
of enhancing the threads page. Alex has shown both passion and ability
to work independently and with little or no supervision.

Votes are due by 2019-04-26, 17:00 CET.

Only current jmc Committers and Reviewers [1] are eligible to vote on
this nomination. Votes must be cast in the open by replying to
this mailing list.

For Lazy Consensus voting instructions, see [2].

Kind regards,
Mario

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

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


From marcus at hirt.se  Fri Apr 12 14:08:16 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 12 Apr 2019 16:08:16 +0200
Subject: SV: Fix name of JDK Flight Recorder feature
In-Reply-To: <CAEBeOco_qu+LHafOGOKUU8DwNtsBiuoBOtVpJbb8puKGJu1BYg@mail.gmail.com>
References: <CAEBeOco_qu+LHafOGOKUU8DwNtsBiuoBOtVpJbb8puKGJu1BYg@mail.gmail.com>
Message-ID: <626301d4f139$2caef380$860cda80$@hirt.se>

Hi Jie,

I think it makes sense. I have a vague memory that this may have been one of those things that made it easier to get closer to a JMC 7 release (though, not easy enough, it would seem). I believe it should be changed in the  mainline repo, and that any vendors who want something different (including Oracle) should override. 

Guru, what do you say?

Kind regards,
Marcus
-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Jie Kang
Skickat: den 12 april 2019 16:00
Till: jmc-dev at openjdk.java.net
?mne: RFR: Fix name of JDK Flight Recorder feature

Hi,

This patch, pasted below, changes the name of the feature from "Oracle JDK Flight Recorder" to "JDK Flight Recorder", matching it's description.

I'm not sure if the inclusion of Oracle in the name is intentional.
Does this fix make sense?

diff --git a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
b/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
--- a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
+++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.propert
+++ ies
@@ -30,7 +30,7 @@
 #  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY  #  WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #
-name=Oracle JDK Flight Recorder
+name=JDK Flight Recorder
 provider=Oracle Corporation
 copyright=Copyright \u00A9 2018, 2019, Oracle and/or its affiliates.
All rights reserved.
 description=The JDK Flight Recorder feature contains all the JFR related plug-ins.


Regards,


From neugens at redhat.com  Fri Apr 12 14:07:01 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 12 Apr 2019 16:07:01 +0200
Subject: CFV: New jmc Committer: Alex Macdonald
In-Reply-To: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>
References: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>
Message-ID: <CAJwKKmZo6vxgw8Ci5NgC4QEUjzhS+cvWmzDrLrGTBh4qv39WMw@mail.gmail.com>

Vote: Yes.

Cheers,
Mario

On Fri, Apr 12, 2019 at 4:03 PM Mario Torre <neugens at redhat.com> wrote:
>
> I hereby nominate Alex Macdonald to jmc Committer.
>
> Alex has been a prolific contributor to JDK Mission Control over the
> past months, with 9 contributions and more in the work (or waiting for
> review), with his most recent contributions tackling the complex issue
> of enhancing the threads page. Alex has shown both passion and ability
> to work independently and with little or no supervision.
>
> Votes are due by 2019-04-26, 17:00 CET.
>
> Only current jmc Committers and Reviewers [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to
> this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Kind regards,
> Mario
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <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 jmatsuok at redhat.com  Fri Apr 12 14:14:33 2019
From: jmatsuok at redhat.com (Joshua Matsuoka)
Date: Fri, 12 Apr 2019 10:14:33 -0400
Subject: CFV: New jmc Committer: Alex Macdonald
In-Reply-To: <CAJwKKmZo6vxgw8Ci5NgC4QEUjzhS+cvWmzDrLrGTBh4qv39WMw@mail.gmail.com>
References: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>
 <CAJwKKmZo6vxgw8Ci5NgC4QEUjzhS+cvWmzDrLrGTBh4qv39WMw@mail.gmail.com>
Message-ID: <CAGLrAXO_vrgWjrmeA2zmn1AbX9QOyydnbo7YJN-Yskfacf4b3A@mail.gmail.com>

Vote: Yes.

Cheers,

- Josh

On Fri, Apr 12, 2019 at 10:08 AM Mario Torre <neugens at redhat.com> wrote:

> Vote: Yes.
>
> Cheers,
> Mario
>
> On Fri, Apr 12, 2019 at 4:03 PM Mario Torre <neugens at redhat.com> wrote:
> >
> > I hereby nominate Alex Macdonald to jmc Committer.
> >
> > Alex has been a prolific contributor to JDK Mission Control over the
> > past months, with 9 contributions and more in the work (or waiting for
> > review), with his most recent contributions tackling the complex issue
> > of enhancing the threads page. Alex has shown both passion and ability
> > to work independently and with little or no supervision.
> >
> > Votes are due by 2019-04-26, 17:00 CET.
> >
> > Only current jmc Committers and Reviewers [1] are eligible to vote on
> > this nomination. Votes must be cast in the open by replying to
> > this mailing list.
> >
> > For Lazy Consensus voting instructions, see [2].
> >
> > Kind regards,
> > Mario
> >
> > [1] http://openjdk.java.net/census
> > [2] http://openjdk.java.net/projects/#committer-vote
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <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 neugens at redhat.com  Fri Apr 12 14:19:16 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 12 Apr 2019 16:19:16 +0200
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context
 menu
In-Reply-To: <CAOsn=kqQOObGc=O8D7ewN0ydj=2R0EGgxSawwKQO=t+ggyGV7Q@mail.gmail.com>
References: <CAOsn=kqQOObGc=O8D7ewN0ydj=2R0EGgxSawwKQO=t+ggyGV7Q@mail.gmail.com>
Message-ID: <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com>

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?

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 almacdon at redhat.com  Fri Apr 12 14:28:27 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Fri, 12 Apr 2019 10:28:27 -0400
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context
 menu
In-Reply-To: <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com>
References: <CAOsn=kqQOObGc=O8D7ewN0ydj=2R0EGgxSawwKQO=t+ggyGV7Q@mail.gmail.com>
 <6319309372f38fb99c38d1bd13b1904664c98ade.camel@redhat.com>
Message-ID: <CAOsn=krTXy1L3-k8MXAWQPu_tRtm+km3ux43W+ihadtzojc6Jw@mail.gmail.com>

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

From guru.hb at oracle.com  Fri Apr 12 17:36:03 2019
From: guru.hb at oracle.com (Guru)
Date: Fri, 12 Apr 2019 23:06:03 +0530
Subject: Fix name of JDK Flight Recorder feature
In-Reply-To: <626301d4f139$2caef380$860cda80$@hirt.se>
References: <CAEBeOco_qu+LHafOGOKUU8DwNtsBiuoBOtVpJbb8puKGJu1BYg@mail.gmail.com>
 <626301d4f139$2caef380$860cda80$@hirt.se>
Message-ID: <DA34E016-186B-4D5F-9CB5-6B2A6690DA43@oracle.com>

I Agree with you Marcus, 

@Jie, Please file a JBS bug for the same and send out for the review. 

Thanks,
Guru
> On 12-Apr-2019, at 7:38 PM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi Jie,
> 
> I think it makes sense. I have a vague memory that this may have been one of those things that made it easier to get closer to a JMC 7 release (though, not easy enough, it would seem). I believe it should be changed in the  mainline repo, and that any vendors who want something different (including Oracle) should override. 
> 
> Guru, what do you say?
> 
> Kind regards,
> Marcus
> -----Ursprungligt meddelande-----
> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Jie Kang
> Skickat: den 12 april 2019 16:00
> Till: jmc-dev at openjdk.java.net
> ?mne: RFR: Fix name of JDK Flight Recorder feature
> 
> Hi,
> 
> This patch, pasted below, changes the name of the feature from "Oracle JDK Flight Recorder" to "JDK Flight Recorder", matching it's description.
> 
> I'm not sure if the inclusion of Oracle in the name is intentional.
> Does this fix make sense?
> 
> diff --git a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
> b/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
> --- a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
> +++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.propert
> +++ ies
> @@ -30,7 +30,7 @@
> #  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY  #  WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> #
> -name=Oracle JDK Flight Recorder
> +name=JDK Flight Recorder
> provider=Oracle Corporation
> copyright=Copyright \u00A9 2018, 2019, Oracle and/or its affiliates.
> All rights reserved.
> description=The JDK Flight Recorder feature contains all the JFR related plug-ins.
> 
> 
> Regards,
> 


From guru.hb at oracle.com  Fri Apr 12 17:36:38 2019
From: guru.hb at oracle.com (Guru)
Date: Fri, 12 Apr 2019 23:06:38 +0530
Subject: CFV: New jmc Committer: Alex Macdonald
In-Reply-To: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>
References: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>
Message-ID: <938C2A09-B1DA-431A-AFFE-9283DD28DC48@oracle.com>

Vote: Yes.

Thanks,
Guru
> On 12-Apr-2019, at 7:33 PM, Mario Torre <neugens at redhat.com> wrote:
> 
> I hereby nominate Alex Macdonald to jmc Committer.
> 
> Alex has been a prolific contributor to JDK Mission Control over the
> past months, with 9 contributions and more in the work (or waiting for
> review), with his most recent contributions tackling the complex issue
> of enhancing the threads page. Alex has shown both passion and ability
> to work independently and with little or no supervision.
> 
> Votes are due by 2019-04-26, 17:00 CET.
> 
> Only current jmc Committers and Reviewers [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to
> this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Kind regards,
> Mario
> 
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
> 
> -- 
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 


From erik.gahlin at oracle.com  Fri Apr 12 17:45:34 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 12 Apr 2019 19:45:34 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <b56d39a3-9bd7-4eb1-0208-199c9fbaa49f@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>
Message-ID: <5CB0CEBE.5000400@oracle.com>

On 2019-04-10 22:03, gerard ziemski wrote:
>
>
> On 4/10/19 1:12 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>> I noticed that events are only emitted if we are able to take the 
>>>> resize lock. Can this be fixed? What prevents us from always 
>>>> getting the data? That's how other periodic events work and losing 
>>>> data sometimes may lead to subtle bugs that hard to understand and 
>>>> replicate in systems that rely on the information. Could we retry 
>>>> on a failure?
>>> Good observation. If the resize lock is taken, then it's not likely 
>>> that whoever owns it will be done soon, so retrying is most likely 
>>> not going to succeed right away. Is it OK to tie up JFR periodic 
>>> thread for some time? If so, how long? 
There is no general upper limit for periodic events.

If we need to wait for a safepoint, we need to do it. That said, events 
that can induce significant latencies or CPU overhead (even in 
pathological cases) are off in default.jfc and only enabled in 
profile.jfr, or not at all.

As I understand it, the events themselves don't cause latencies and the 
tables are not expanded that often, so I think it would be okay to emit 
them.  If you think otherwise, I would try to scan concurrently, even if 
it means we are slightly off.

>>>
>>>
>>> If the lock is taken, then it means that someone is scanning through 
>>> the entire table, or the table is being resized. Either way, we're 
>>> not loosing data, but are just temporarily blind - I don't see a 
>>> problem here for a long running apps, they will start receiving 
>>> events eventually (which happen every 10 sec by default)
A user can set period "everyChunk" which means events are guaranteed to 
be in the recording.

I think we should try to avoid breaking that contract. When event 
streaming is in place, we can implement requestable events where a user 
can demand an event programmatically from Java. If they sometimes don't 
get an event, it will break their code in a subtle way.

Thanks
Erik

>>
>> Robbin was talking about allowing scanning the table while resizing, 
>> ie. not having the resize_lock, if we can accept that there might be 
>> some entries double counted.
>
> Yes, we could do that - are you suggesting that this is what we should 
> do? Personally, I think I'd prefer not to emit the event at all, 
> rather than emit one that might be wrong (that's exactly what we do 
> currently for jcmd print statistics).
>
> Erik, Robbin, do you have a preference here?
>
>
> cheers
>


From guru.hb at oracle.com  Fri Apr 12 18:00:05 2019
From: guru.hb at oracle.com (Guru)
Date: Fri, 12 Apr 2019 23:30:05 +0530
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context
 menu
In-Reply-To: <CAOsn=krTXy1L3-k8MXAWQPu_tRtm+km3ux43W+ihadtzojc6Jw@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>
Message-ID: <A4102A46-3E4E-4C9C-B71B-E3A329BE70DB@oracle.com>

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).

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 <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/
>>> [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 <https://www.redhat.com/>>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>> 
> 
> Thanks,
> 
> Alex


From marcus.hirt at datadoghq.com  Fri Apr 12 18:08:33 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 12 Apr 2019 20:08:33 +0200
Subject: CFV: New jmc Committer: Alex Macdonald
In-Reply-To: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>
References: <39ec3ad1334f2ef68d564bdc1f5b1e17bbe556fc.camel@redhat.com>
Message-ID: <CAOpWGx2D7B0L0nnYpAvOcFyrSzzgQg=rr3yf8Z6X+pfN3gmnZA@mail.gmail.com>

Vote: Yes.

Kind regards,
Marcus

On Fri, Apr 12, 2019 at 4:04 PM Mario Torre <neugens at redhat.com> wrote:
>
> I hereby nominate Alex Macdonald to jmc Committer.
>
> Alex has been a prolific contributor to JDK Mission Control over the
> past months, with 9 contributions and more in the work (or waiting for
> review), with his most recent contributions tackling the complex issue
> of enhancing the threads page. Alex has shown both passion and ability
> to work independently and with little or no supervision.
>
> Votes are due by 2019-04-26, 17:00 CET.
>
> Only current jmc Committers and Reviewers [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to
> this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Kind regards,
> Mario
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From marcus.hirt at datadoghq.com  Fri Apr 12 19:26:08 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 12 Apr 2019 21:26:08 +0200
Subject: CFV: New JMC Reviewer: Guru Hb
Message-ID: <CAOpWGx2QULx2=ZTNQHvocFifOvvzRcuTGgpvU+wKdey=OMf-yw@mail.gmail.com>

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 erik.gahlin at oracle.com  Fri Apr 12 19:28:03 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 12 Apr 2019 21:28:03 +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: <5CB0E6C3.5050300@oracle.com>

Vote: yes

Erik
> 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 gerard.ziemski at oracle.com  Fri Apr 12 20:13:22 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Fri, 12 Apr 2019 15:13:22 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CB0CEBE.5000400@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>
Message-ID: <72c5aeb5-d65c-33d0-fc95-5e469316478f@oracle.com>



On 4/12/19 12:45 PM, Erik Gahlin wrote:
> On 2019-04-10 22:03, gerard ziemski wrote:
>>
>>
>> On 4/10/19 1:12 PM, coleen.phillimore at oracle.com wrote:
>>>>>
>>>>> I noticed that events are only emitted if we are able to take the 
>>>>> resize lock. Can this be fixed? What prevents us from always 
>>>>> getting the data? That's how other periodic events work and losing 
>>>>> data sometimes may lead to subtle bugs that hard to understand and 
>>>>> replicate in systems that rely on the information. Could we retry 
>>>>> on a failure?
>>>> Good observation. If the resize lock is taken, then it's not likely 
>>>> that whoever owns it will be done soon, so retrying is most likely 
>>>> not going to succeed right away. Is it OK to tie up JFR periodic 
>>>> thread for some time? If so, how long? 
> There is no general upper limit for periodic events.
>
> If we need to wait for a safepoint, we need to do it. That said, 
> events that can induce significant latencies or CPU overhead (even in 
> pathological cases) are off in default.jfc and only enabled in 
> profile.jfr, or not at all.
>
> As I understand it, the events themselves don't cause latencies and 
> the tables are not expanded that often, so I think it would be okay to 
> emit them.? If you think otherwise, I would try to scan concurrently, 
> even if it means we are slightly off.
>
>>>>
>>>>
>>>> If the lock is taken, then it means that someone is scanning 
>>>> through the entire table, or the table is being resized. Either 
>>>> way, we're not loosing data, but are just temporarily blind - I 
>>>> don't see a problem here for a long running apps, they will start 
>>>> receiving events eventually (which happen every 10 sec by default)
> A user can set period "everyChunk" which means events are guaranteed 
> to be in the recording.
>
> I think we should try to avoid breaking that contract. When event 
> streaming is in place, we can implement requestable events where a 
> user can demand an event programmatically from Java. If they sometimes 
> don't get an event, it will break their code in a subtle way.

No problem, I removed the resize_lock around the JFR table statistics, 
so we might get a slightly incorrect stats every now and then, but we 
will be emitting the events on schedule: 
http://cr.openjdk.java.net/~gziemski/8185525_rev7

Last question: what is the recommended way to programatically tell if 
JFR is ON? I'm wondering whether I should collect the add/remove rates 
for the tables only if JRF is ON. As it is right now, we collect them 
always. It's just an atomic increment, but still, it's work only JFR 
events need.


cheers



From marcus.hirt at datadoghq.com  Fri Apr 12 20:46:23 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 12 Apr 2019 22:46:23 +0200
Subject: CFV: New JMC Reviewer: Guru Hb
References: <CAOpWGx2QULx2=ZTNQHvocFifOvvzRcuTGgpvU+wKdey=OMf-yw@mail.gmail.com>
Message-ID: <CAOpWGx3GKvXfe2c3f6qK-QYqcx04fxZtpEUfPdB3cvEQVx1jwA@mail.gmail.com>

Vote: yes.

Kind regards,
Marcus

On Fri, Apr 12, 2019 at 9:26 PM Marcus Hirt <marcus.hirt at datadoghq.com> 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 at hirt.se  Mon Apr 15 11:14:42 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Mon, 15 Apr 2019 11:14:42 +0000
Subject: hg: jmc/jmc: JMC-6455: Building source jars when building core
Message-ID: <201904151114.x3FBEgmt005386@aojmv0008.oracle.com>

Changeset: 64229c9df7c2
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-04-15 13:14 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/64229c9df7c2

JMC-6455: Building source jars when building core
Reviewed-by: hirt
Contributed-by: Stefan Ferstl <st.ferstl at gmail.com>

! core/pom.xml


From jkang at redhat.com  Mon Apr 15 13:15:11 2019
From: jkang at redhat.com (Jie Kang)
Date: Mon, 15 Apr 2019 09:15:11 -0400
Subject: Fix name of JDK Flight Recorder feature
In-Reply-To: <DA34E016-186B-4D5F-9CB5-6B2A6690DA43@oracle.com>
References: <CAEBeOco_qu+LHafOGOKUU8DwNtsBiuoBOtVpJbb8puKGJu1BYg@mail.gmail.com>
 <626301d4f139$2caef380$860cda80$@hirt.se>
 <DA34E016-186B-4D5F-9CB5-6B2A6690DA43@oracle.com>
Message-ID: <CAEBeOcpUytjsqx0LAo=TdDD1Zv_q1oc7VPd9+ONDyOLB3YOLAA@mail.gmail.com>

Hi Guru, Marcus,

Alex has filed a JBS bug for me, JMC-6456:
https://bugs.openjdk.java.net/browse/JMC-6456

If there are no objections I will ask Josh to push in my stead. Thanks
for taking a look!


Regards,

On Fri, Apr 12, 2019 at 1:38 PM Guru <guru.hb at oracle.com> wrote:
>
> I Agree with you Marcus,
>
> @Jie, Please file a JBS bug for the same and send out for the review.
>
> Thanks,
> Guru
> > On 12-Apr-2019, at 7:38 PM, Marcus Hirt <marcus at hirt.se> wrote:
> >
> > Hi Jie,
> >
> > I think it makes sense. I have a vague memory that this may have been one of those things that made it easier to get closer to a JMC 7 release (though, not easy enough, it would seem). I believe it should be changed in the  mainline repo, and that any vendors who want something different (including Oracle) should override.
> >
> > Guru, what do you say?
> >
> > Kind regards,
> > Marcus
> > -----Ursprungligt meddelande-----
> > Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Jie Kang
> > Skickat: den 12 april 2019 16:00
> > Till: jmc-dev at openjdk.java.net
> > ?mne: RFR: Fix name of JDK Flight Recorder feature
> >
> > Hi,
> >
> > This patch, pasted below, changes the name of the feature from "Oracle JDK Flight Recorder" to "JDK Flight Recorder", matching it's description.
> >
> > I'm not sure if the inclusion of Oracle in the name is intentional.
> > Does this fix make sense?
> >
> > diff --git a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
> > b/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
> > --- a/application/org.openjdk.jmc.feature.flightrecorder/feature.properties
> > +++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.propert
> > +++ ies
> > @@ -30,7 +30,7 @@
> > #  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY  #  WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > #
> > -name=Oracle JDK Flight Recorder
> > +name=JDK Flight Recorder
> > provider=Oracle Corporation
> > copyright=Copyright \u00A9 2018, 2019, Oracle and/or its affiliates.
> > All rights reserved.
> > description=The JDK Flight Recorder feature contains all the JFR related plug-ins.
> >
> >
> > Regards,
> >
>

From jmatsuok at redhat.com  Mon Apr 15 14:43:53 2019
From: jmatsuok at redhat.com (jmatsuok at redhat.com)
Date: Mon, 15 Apr 2019 14:43:53 +0000
Subject: hg: jmc/jmc: JMC-4613: Thread name striked out
Message-ID: <201904151443.x3FEhr8w006436@aojmv0008.oracle.com>

Changeset: e18ff62cd8dd
Author:    aptmac <almacdon at redhat.com>
Date:      2019-04-12 14:59 -0400
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/e18ff62cd8dd

JMC-4613: Thread name striked out
Reviewed-by: hirt

! application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/charts/XYChart.java


From jmatsuok at redhat.com  Mon Apr 15 14:48:59 2019
From: jmatsuok at redhat.com (jmatsuok at redhat.com)
Date: Mon, 15 Apr 2019 14:48:59 +0000
Subject: hg: jmc/jmc: JMC-6456: Fix name of JDK Flight Recorder feature
Message-ID: <201904151449.x3FEn0cp007783@aojmv0008.oracle.com>

Changeset: 3b45c165cd46
Author:    jmatsuoka <jmatsuok at redhat.com>
Date:      2019-04-15 10:48 -0400
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/3b45c165cd46

JMC-6456: Fix name of JDK Flight Recorder feature
Summary: Fix name of JDK Flight Recorder feature
Contributed-by: Jie Kang <jkang at redhat.com>
Reviewed-by: ghb, hirt

! application/org.openjdk.jmc.feature.flightrecorder/feature.properties


From markus.gronlund at oracle.com  Mon Apr 15 16:14:49 2019
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Mon, 15 Apr 2019 09:14:49 -0700 (PDT)
Subject: FW: JMC left pane Thread not seen
In-Reply-To: <073dcf08-2520-d02a-18eb-3c5e5cdb95a2@oracle.com>
References: <073dcf08-2520-d02a-18eb-3c5e5cdb95a2@oracle.com>
Message-ID: <530118b0-8757-4830-ade1-f649d582bd22@default>

Hi Balaji,

I will forward your questions to the JDK Mission Control development list.

Thanks
Markus

PS I used an early access version of JMC 7.0 in the video.


-----Original Message-----
From: Balaji Natarajan 
Sent: den 15 april 2019 18:05
To: MARKUS.GRONLUND <markus.gronlund at oracle.com>
Subject: JMC left pane Thread not seen


Hi Markus,

I work in the Weblogic Support organization in Orlando Office

I saw your youtube video 'JDK11 - Introduction to JDK Flight Recorder'

Your advise to focus on the vertical pattern in the thread caught my attention and pulled up a .jfr which was around and ran it thru a jmc 6.0 client.
Two questions. Appreciate if you can enlighten me.

* I do not see the 'Threads' on the left pane in my JMC. I do see the Thread dumps though.? Any thoughts why I do not have it. Is it a later version of JMC?

* Is JMC delinked from java downloads henceforth. i.e is it to be dowloaded
 ? seperately. If so, from where?



Thanks
Balaji


From marcus.hirt at datadoghq.com  Mon Apr 15 17:18:45 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 15 Apr 2019 19:18:45 +0200
Subject: FW: JMC left pane Thread not seen
In-Reply-To: <530118b0-8757-4830-ade1-f649d582bd22@default>
References: <073dcf08-2520-d02a-18eb-3c5e5cdb95a2@oracle.com>
 <530118b0-8757-4830-ade1-f649d582bd22@default>
Message-ID: <CAOpWGx17NxVvOqKppdmdTjCtt+d4uw9Xyvi-dpmWAa2QxuaoyQ@mail.gmail.com>

Hi Balaji,

Right now we're waiting for Oracle to do a binary release. The source
in the JMC 7 repo has not changed for quite some time, and the release
should, as far as the open source project is concerned, be done. I've
been told it is a TPA (Third Party Approval) issue that is taking some
time to resolve. Hopefully it will be resolved soon, and the binary
builds will be up again. That said, this is all taking longer than I
would have expected. I will make another effort to see what is going
on. Since you are Oracle, you can probably ask the Java PM (Aurelio)
directly.

Kind regards,
Marcus

On Mon, Apr 15, 2019 at 6:15 PM Markus Gronlund
<markus.gronlund at oracle.com> wrote:
>
> Hi Balaji,
>
> I will forward your questions to the JDK Mission Control development list.
>
> Thanks
> Markus
>
> PS I used an early access version of JMC 7.0 in the video.
>
>
> -----Original Message-----
> From: Balaji Natarajan
> Sent: den 15 april 2019 18:05
> To: MARKUS.GRONLUND <markus.gronlund at oracle.com>
> Subject: JMC left pane Thread not seen
>
>
> Hi Markus,
>
> I work in the Weblogic Support organization in Orlando Office
>
> I saw your youtube video 'JDK11 - Introduction to JDK Flight Recorder'
>
> Your advise to focus on the vertical pattern in the thread caught my attention and pulled up a .jfr which was around and ran it thru a jmc 6.0 client.
> Two questions. Appreciate if you can enlighten me.
>
> * I do not see the 'Threads' on the left pane in my JMC. I do see the Thread dumps though.  Any thoughts why I do not have it. Is it a later version of JMC?
>
> * Is JMC delinked from java downloads henceforth. i.e is it to be dowloaded
>    seperately. If so, from where?
>
>
>
> Thanks
> Balaji
>

From neugens at redhat.com  Tue Apr 16 12:54:44 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 16 Apr 2019 14:54:44 +0200
Subject: FW: JMC left pane Thread not seen
In-Reply-To: <CAOpWGx17NxVvOqKppdmdTjCtt+d4uw9Xyvi-dpmWAa2QxuaoyQ@mail.gmail.com>
References: <073dcf08-2520-d02a-18eb-3c5e5cdb95a2@oracle.com>
 <530118b0-8757-4830-ade1-f649d582bd22@default>
 <CAOpWGx17NxVvOqKppdmdTjCtt+d4uw9Xyvi-dpmWAa2QxuaoyQ@mail.gmail.com>
Message-ID: <031ef2c6376bb7de8cc94d3f795a662baa47d1f9.camel@redhat.com>

On Mon, 2019-04-15 at 19:18 +0200, Marcus Hirt wrote:
> Hi Balaji,
> 
> Right now we're waiting for Oracle to do a binary release. The source
> in the JMC 7 repo has not changed for quite some time, and the
> release
> should, as far as the open source project is concerned, be done. I've
> been told it is a TPA (Third Party Approval) issue that is taking
> some
> time to resolve. Hopefully it will be resolved soon, and the binary
> builds will be up again. That said, this is all taking longer than I
> would have expected. I will make another effort to see what is going
> on. Since you are Oracle, you can probably ask the Java PM (Aurelio)
> directly.

Hi Balaji,

I don't know what's your setup, but if you need a binary to try out and
you are using a Fedora based distribution, Fedora is now shipping a
working binary based on the latest JMC 7 branch (which is effectively
done as Marcus said), so you can use this one.

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 jkang at redhat.com  Tue Apr 16 13:02:30 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 16 Apr 2019 09:02:30 -0400
Subject: RFR: Add support for jdk.jfr.Frequency
Message-ID: <CAEBeOcoQk24WTkKnC2FWK0pt2g06CWtivCjNLzWjjevYQDOkEA@mail.gmail.com>

Hi,

The patch attached adds support for the annotation jdk.jfr.Frequency,
using the Hertz unit introduced in JMC-5768 for JFR events like
CPUTimeStampCounter, ThreadContextSwitchRate, etc.

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

How does it look?

I was initially also trying to find related unit tests, but I don't
think any exist. I will be looking to write some but I'd like some
feedback if this is even a correct implementation before continuing.


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

From erik.gahlin at oracle.com  Wed Apr 17 03:05:51 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 17 Apr 2019 05:05:51 +0200
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <72c5aeb5-d65c-33d0-fc95-5e469316478f@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>
Message-ID: <5CB6980F.2050800@oracle.com>

On 2019-04-12 22:13, gerard ziemski wrote:
>
>
> On 4/12/19 12:45 PM, Erik Gahlin wrote:
>> On 2019-04-10 22:03, gerard ziemski wrote:
>>>
>>>
>>> On 4/10/19 1:12 PM, coleen.phillimore at oracle.com wrote:
>>>>>>
>>>>>> I noticed that events are only emitted if we are able to take the 
>>>>>> resize lock. Can this be fixed? What prevents us from always 
>>>>>> getting the data? That's how other periodic events work and 
>>>>>> losing data sometimes may lead to subtle bugs that hard to 
>>>>>> understand and replicate in systems that rely on the information. 
>>>>>> Could we retry on a failure?
>>>>> Good observation. If the resize lock is taken, then it's not 
>>>>> likely that whoever owns it will be done soon, so retrying is most 
>>>>> likely not going to succeed right away. Is it OK to tie up JFR 
>>>>> periodic thread for some time? If so, how long? 
>> There is no general upper limit for periodic events.
>>
>> If we need to wait for a safepoint, we need to do it. That said, 
>> events that can induce significant latencies or CPU overhead (even in 
>> pathological cases) are off in default.jfc and only enabled in 
>> profile.jfr, or not at all.
>>
>> As I understand it, the events themselves don't cause latencies and 
>> the tables are not expanded that often, so I think it would be okay 
>> to emit them.  If you think otherwise, I would try to scan 
>> concurrently, even if it means we are slightly off.
>>
>>>>>
>>>>>
>>>>> If the lock is taken, then it means that someone is scanning 
>>>>> through the entire table, or the table is being resized. Either 
>>>>> way, we're not loosing data, but are just temporarily blind - I 
>>>>> don't see a problem here for a long running apps, they will start 
>>>>> receiving events eventually (which happen every 10 sec by default)
>> A user can set period "everyChunk" which means events are guaranteed 
>> to be in the recording.
>>
>> I think we should try to avoid breaking that contract. When event 
>> streaming is in place, we can implement requestable events where a 
>> user can demand an event programmatically from Java. If they 
>> sometimes don't get an event, it will break their code in a subtle way.
>
> No problem, I removed the resize_lock around the JFR table statistics, 
> so we might get a slightly incorrect stats every now and then, but we 
> will be emitting the events on schedule: 
> http://cr.openjdk.java.net/~gziemski/8185525_rev7
Is it sufficient to just remove the lock to make it "work"?

I think it could be OK to use stale data, or perhaps count a value 
twice, but are there other issues that needs to be fixed as well? Robbin 
may have more information on this.

An alternative approach would be to use the last known data, if we are 
not able to take the lock. It would be old, but not out of whack.

That said, it would be interesting to have some numbers on what the cost 
would be to wait for the lock.

>
> Last question: what is the recommended way to programatically tell if 
> JFR is ON? I'm wondering whether I should collect the add/remove rates 
> for the tables only if JRF is ON. As it is right now, we collect them 
> always. It's just an atomic increment, but still, it's work only JFR 
> events need.

You can use the JFR_ONLY macro, if it's not built with JFR. If you want 
to check if a recording is running, you can use Jfr::is_recording(), but 
perhaps Jfr::is_enabled() is more accurate/correct if a recording is 
started/stopped repeatedly?

I looked at jfrPeriodic.cpp, and it seems to me that things could be 
simplified, i.e.

template<typename T>
static void emit_table_statistics(TableStatistics& statistics) {
    T event;
    event.set_bucketCount(statistics._number_of_buckets);
    ...
    event.commit();
}

Thanks
Erik

From almacdon at redhat.com  Wed Apr 17 16:33:08 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Wed, 17 Apr 2019 12:33:08 -0400
Subject: RFR: JMC-4466 - Hide thread directly from Thread graph context
 menu
In-Reply-To: <A4102A46-3E4E-4C9C-B71B-E3A329BE70DB@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>
Message-ID: <CAOsn=krz=eY4S+ESvRDeTAbzcYKVy961HWoqDKf3KC7iv=B-XQ@mail.gmail.com>

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.


>
> 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/

From gerard.ziemski at oracle.com  Thu Apr 18 15:45:24 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 18 Apr 2019 10:45:24 -0500
Subject: RFR: 8185525: [Event Request] Add Tracing event for
 DictionarySizes
In-Reply-To: <5CB6980F.2050800@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>
Message-ID: <16c2e23d-0c69-40bc-40d0-75cad1630e4d@oracle.com>

Sorry Erik that it took me a while to respond, but the thread got so 
long, that I missed your reply initially.


On 4/16/19 10:05 PM, Erik Gahlin wrote:
>>>>>>
>>>>>> If the lock is taken, then it means that someone is scanning 
>>>>>> through the entire table, or the table is being resized. Either 
>>>>>> way, we're not loosing data, but are just temporarily blind - I 
>>>>>> don't see a problem here for a long running apps, they will start 
>>>>>> receiving events eventually (which happen every 10 sec by default)
>>> A user can set period "everyChunk" which means events are guaranteed 
>>> to be in the recording.
>>>
>>> I think we should try to avoid breaking that contract. When event 
>>> streaming is in place, we can implement requestable events where a 
>>> user can demand an event programmatically from Java. If they 
>>> sometimes don't get an event, it will break their code in a subtle way.
>>
>> No problem, I removed the resize_lock around the JFR table 
>> statistics, so we might get a slightly incorrect stats every now and 
>> then, but we will be emitting the events on schedule: 
>> http://cr.openjdk.java.net/~gziemski/8185525_rev7
> Is it sufficient to just remove the lock to make it "work"?

Yes, the event statistics might be slightly off though.


>
> I think it could be OK to use stale data, or perhaps count a value 
> twice, but are there other issues that needs to be fixed as well? 
> Robbin may have more information on this.

Yes, we might end up miscounting some items, as Coleen pointed out 
before. I already noted that emitting the event in such situation might 
result is slightly wrong data, and used that as an argument that I'd 
prefer not to emit the event at all, but you said that you preferred 
slightly wrong data as long as we emit the event.

I don't want to speak for Robbin here, but I want to note that he 
already expressed his opinion, by saying that we might as well skip the 
event, when we can't grab the lock, which would me my personal choice 
here as well.


>
> An alternative approach would be to use the last known data, if we are 
> not able to take the lock. It would be old, but not out of whack.

This is not really much better than not emitting the event at all, as we 
had in previous implementation. Any client reading the events might as 
well assume that the missing event would be same as the last for this 
particular event and synthesize one as needed. I don't see this as much 
improvement.

>
> That said, it would be interesting to have some numbers on what the 
> cost would be to wait for the lock.

Robbin's hash table is concurrent and I personally would hate to 
introduce, even in JFR code base, a mechanism that blocks and waits 
around for the table to be locked (however infrequent such situation 
might be called for).

I'm not saying that it can not be done, but I personally would not want 
to do this. If you want to follow up on this yourself, however, you can 
always do that.


>
>>
>> Last question: what is the recommended way to programatically tell if 
>> JFR is ON? I'm wondering whether I should collect the add/remove 
>> rates for the tables only if JRF is ON. As it is right now, we 
>> collect them always. It's just an atomic increment, but still, it's 
>> work only JFR events need.
>
> You can use the JFR_ONLY macro, if it's not built with JFR. If you 
> want to check if a recording is running, you can use 
> Jfr::is_recording(), but perhaps Jfr::is_enabled() is more 
> accurate/correct if a recording is started/stopped repeatedly?'

Thanks! I used some of these APIs, but I think that we currently don't 
have enough granularity here, so I filed JDK-8222736 expressing my 
concerns and the logic behind it.


>
> I looked at jfrPeriodic.cpp, and it seems to me that things could be 
> simplified, i.e.
>
> template<typename T>
> static void emit_table_statistics(TableStatistics& statistics) {
> ?? T event;
> ?? event.set_bucketCount(statistics._number_of_buckets);
> ?? ...
> ?? event.commit();
> }

Very nice suggestion, thank you.

As much as I'd like to move on from this issue, I'm having second 
thoughts about the "insertion rate" and "deletion rate" attributes for 
these events. They can be synthesized by clients, and I wonder whether 
or not we should include them. I'd rather see only the core attributes 
be part of the event, and anything else that can be synthesized by 
clients, not "clutter" the event.


Uploaded update revision here 
http://cr.openjdk.java.net/~gziemski/8185525_rev8


cheers

From guru.hb at oracle.com  Fri Apr 19 08:34:01 2019
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Fri, 19 Apr 2019 08:34:01 +0000
Subject: hg: jmc/jmc7: JMC-6395: update jetty-maven-plugin from
 org.morbay.jetty to org.eclipse.jetty
Message-ID: <201904190834.x3J8Y16K011741@aojmv0008.oracle.com>

Changeset: 8896d6716f78
Author:    ghb <guru.hb at oracle.com>
Date:      2019-04-09 18:21 +0530
URL:       http://hg.openjdk.java.net/jmc/jmc7/rev/8896d6716f78

JMC-6395: update jetty-maven-plugin from org.morbay.jetty to org.eclipse.jetty
Reviewed-by: hirt <marcus at hirt.se>

! releng/third-party/pom.xml


From guru.hb at oracle.com  Fri Apr 19 10:40:35 2019
From: guru.hb at oracle.com (Guru)
Date: Fri, 19 Apr 2019 16:10:35 +0530
Subject: Review Request for JMC-6444: Switch to
 fix-info-plist-maven-plugin 1.5
In-Reply-To: <BEDA68A1-AE11-4BD0-9872-FD2689C7F792@oracle.com>
References: <CAOpWGx01zvzV_L+AJYLpBYG2DWtDcVxuknNjEqdSv50LgVkd8w@mail.gmail.com>
 <BEDA68A1-AE11-4BD0-9872-FD2689C7F792@oracle.com>
Message-ID: <A193BD13-C29F-4E29-AB91-AFC094455EAC@oracle.com>

Hi Marcus,

Please commit the changes. 

Thanks,
Guru
> On 02-Apr-2019, at 10:32 AM, Guru <guru.hb at oracle.com> wrote:
> 
> +1, Changes looks good to me, 
> 
> Please Wait for the Third party approval to push the changes. 
> 
> Thanks,
> Guru
>> On 02-Apr-2019, at 7:32 AM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>> 
>> Hi all,
>> 
>> Please review this fix to switch to fix-info-plist-maven-plugin 1.5
>> 
>> Jira:   https://bugs.openjdk.java.net/browse/JMC-6444
>> Patch:
>> diff -r 5b9d72265772 application/org.openjdk.jmc.rcp.product/pom.xml
>> --- a/application/org.openjdk.jmc.rcp.product/pom.xml   Tue Mar 26 14:11:58
>> 2019 -0400
>> +++ b/application/org.openjdk.jmc.rcp.product/pom.xml   Mon Apr 01 21:52:34
>> 2019 -0400
>> @@ -93,7 +93,7 @@
>>                       <plugin>
>>                               <groupId>name.abuchen</groupId>
>> 
>> <artifactId>fix-info-plist-maven-plugin</artifactId>
>> -                               <version>1.2</version>
>> +                               <version>1.5</version>
>>                               <executions>
>>                                       <execution>
>>                                               <id>fix-info-plist</id>
>> 
>> Kind regards,
>> Marcus
> 


From marcus at hirt.se  Fri Apr 19 11:07:47 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Fri, 19 Apr 2019 11:07:47 +0000
Subject: hg: jmc/jmc: JMC-6444: Upgrading to fix-info-plist 1.5
Message-ID: <201904191107.x3JB7lxP008627@aojmv0008.oracle.com>

Changeset: 2e2d0e1aaf42
Author:    hirt <marcus.hirt at datadoghq.com>
Date:      2019-04-19 12:55 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/2e2d0e1aaf42

JMC-6444: Upgrading to fix-info-plist 1.5
Reviewed-by: ghb

! application/org.openjdk.jmc.rcp.product/pom.xml


From marcus at hirt.se  Fri Apr 19 14:56:14 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 19 Apr 2019 16:56:14 +0200
Subject: Review Request for JMC-6454: Upgrade to Tycho 1.4.0.
Message-ID: <017701d4f6c0$08f0f5b0$1ad2e110$@hirt.se>

Hi all,

Please review this fix to upgrade to Tycho 1.4.0.

Jira:   https://bugs.openjdk.java.net/browse/JMC-6454
Patch:
diff -r 3b45c165cd46 pom.xml
--- a/pom.xml   Mon Apr 15 10:48:19 2019 -0400
+++ b/pom.xml   Fri Apr 19 16:54:07 2019 +0200
@@ -75,7 +75,7 @@
        <properties>
 
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
-               <tycho.version>1.3.0</tycho.version>
+               <tycho.version>1.4.0</tycho.version>
                <maven.buildnumber.version>1.4</maven.buildnumber.version>
                <maven.deploy.version>2.8.2</maven.deploy.version>
                <maven.directory.version>0.2</maven.directory.version>

Kind regards,
Marcus


From guru.hb at oracle.com  Fri Apr 19 15:09:50 2019
From: guru.hb at oracle.com (Guru)
Date: Fri, 19 Apr 2019 20:39:50 +0530
Subject: Review Request for JMC-6454: Upgrade to Tycho 1.4.0.
In-Reply-To: <017701d4f6c0$08f0f5b0$1ad2e110$@hirt.se>
References: <017701d4f6c0$08f0f5b0$1ad2e110$@hirt.se>
Message-ID: <1CC4BCDA-4918-47DF-A1B7-550A705220EF@oracle.com>

+1, Looks good to me.

Thanks,
Guru
> On 19-Apr-2019, at 8:26 PM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi all,
> 
> Please review this fix to upgrade to Tycho 1.4.0.
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6454
> Patch:
> diff -r 3b45c165cd46 pom.xml
> --- a/pom.xml   Mon Apr 15 10:48:19 2019 -0400
> +++ b/pom.xml   Fri Apr 19 16:54:07 2019 +0200
> @@ -75,7 +75,7 @@
>        <properties>
> 
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
> 
> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
> -               <tycho.version>1.3.0</tycho.version>
> +               <tycho.version>1.4.0</tycho.version>
>                <maven.buildnumber.version>1.4</maven.buildnumber.version>
>                <maven.deploy.version>2.8.2</maven.deploy.version>
>                <maven.directory.version>0.2</maven.directory.version>
> 
> Kind regards,
> Marcus
> 


From marcus at hirt.se  Fri Apr 19 19:52:32 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Fri, 19 Apr 2019 19:52:32 +0000
Subject: hg: jmc/jmc: JMC-6454: Upgrade to Tycho 1.4.0
Message-ID: <201904191952.x3JJqWja014651@aojmv0008.oracle.com>

Changeset: e616f5ab13e2
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-04-19 21:51 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/e616f5ab13e2

JMC-6454: Upgrade to Tycho 1.4.0
Reviewed-by: ghb

! pom.xml


From gerard.ziemski at oracle.com  Fri Apr 26 18:00:08 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Fri, 26 Apr 2019 13:00:08 -0500
Subject: RFR 8211331: [Event Request] Events to track Unsafe memory allocations
In-Reply-To: <0471A20B-654D-42FF-B28F-828E6B50FF59@me.com>
References: <0471A20B-654D-42FF-B28F-828E6B50FF59@me.com>
Message-ID: <0e9db086-4acc-e2a9-c88c-c825a12dfb7c@oracle.com>

Hi all,

Please review this feature, which adds JFR event tracking for Unsafe 
memory allocations/deallocations.

I chose to use malloc_size() on Mac, malloc_usable_size() on Linux and 
_msize() on Windows to track pointer size, which allowed me to track the 
sizes during deallocations (as well as the actual sizes that the OS 
allocated). Other platforms have that feature disabled, but still track 
the (client) allocation sizes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8211331
Webrev: http://cr.openjdk.java.net/~gziemski/8211331_rev1
Testing: Mach5 tier1 passes, Mach5 tier1,2,3,4,5,6,7 in progress?


cheers

From marcus at hirt.se  Mon Apr 29 09:30:33 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Mon, 29 Apr 2019 11:30:33 +0200
Subject: Review request for JMC-6274: Adding Eclipse 2018-12 and 2019-03
 target platforms.
Message-ID: <001501d4fe6e$32031ef0$96095cd0$@hirt.se>

Hi all,

Please review this fix to support new Eclipse platforms and switching to
2019-03 by default. Also removing Oxygen.

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

Kind regards,
Marcus



From guru.hb at oracle.com  Mon Apr 29 10:40:10 2019
From: guru.hb at oracle.com (Guru)
Date: Mon, 29 Apr 2019 16:10:10 +0530
Subject: Review request for JMC-6274: Adding Eclipse 2018-12 and 2019-03
 target platforms.
In-Reply-To: <001501d4fe6e$32031ef0$96095cd0$@hirt.se>
References: <001501d4fe6e$32031ef0$96095cd0$@hirt.se>
Message-ID: <85AD3809-A2D7-4116-9018-BB73CE11FC99@oracle.com>

+1, Tested on Mac OS X, Windows and Linux (Ubuntu). 

Thanks
Guru 
> On 29-Apr-2019, at 3:00 PM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi all,
> 
> Please review this fix to support new Eclipse platforms and switching to
> 2019-03 by default. Also removing Oxygen.
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6274
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6274/webrev.3/
> 
> Kind regards,
> Marcus
> 
> 


From jkang at redhat.com  Mon Apr 29 19:50:35 2019
From: jkang at redhat.com (Jie Kang)
Date: Mon, 29 Apr 2019 15:50:35 -0400
Subject: Review request for JMC-6274: Adding Eclipse 2018-12 and 2019-03
 target platforms.
In-Reply-To: <85AD3809-A2D7-4116-9018-BB73CE11FC99@oracle.com>
References: <001501d4fe6e$32031ef0$96095cd0$@hirt.se>
 <85AD3809-A2D7-4116-9018-BB73CE11FC99@oracle.com>
Message-ID: <CAEBeOcrA33o2i3Phvc1X7bq9u+BPJXGCzg3w=ie-akSBOtbJHA@mail.gmail.com>

Hi,

I tried both new target platforms and it looks okay to me as well. The
patch file has a weird file path with the './' in front but I imagine
it will resolve itself when you commit.

--- old/./pom.xml 2019-04-28 01:26:32.861640100 +0200
+++ new/./pom.xml 2019-04-28 01:26:32.742624000 +0200


Regards,

On Mon, Apr 29, 2019 at 6:40 AM Guru <guru.hb at oracle.com> wrote:
>
> +1, Tested on Mac OS X, Windows and Linux (Ubuntu).
>
> Thanks
> Guru
> > On 29-Apr-2019, at 3:00 PM, Marcus Hirt <marcus at hirt.se> wrote:
> >
> > Hi all,
> >
> > Please review this fix to support new Eclipse platforms and switching to
> > 2019-03 by default. Also removing Oxygen.
> >
> > Jira:   https://bugs.openjdk.java.net/browse/JMC-6274
> > Webrev: http://cr.openjdk.java.net/~hirt/JMC-6274/webrev.3/
> >
> > Kind regards,
> > Marcus
> >
> >
>

From jmatsuok at redhat.com  Mon Apr 29 20:26:50 2019
From: jmatsuok at redhat.com (Joshua Matsuoka)
Date: Mon, 29 Apr 2019 16:26:50 -0400
Subject: Review Request for JMC-4469: Adding a page from the properties
 view
In-Reply-To: <CADPaBqkQC2voHrGWVWjP5gPRt=6G_ioyiuhZtY6APz_Zm9xzqg@mail.gmail.com>
References: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>
 <CAOpWGx3u0p-SwNevwHXcMrKj=KFRixSV1cLE35XNEkotHuSBkQ@mail.gmail.com>
 <CADPaBqnpDAqKbc4Skd0rq5=dOgcmAS0TztrYYwN0_U1aWTNsQw@mail.gmail.com>
 <CAOpWGx2QhJ2czwXmHW79fmJOGYFPBw7Vo7MiWWekK4H_R4hSWA@mail.gmail.com>
 <CADPaBqkQC2voHrGWVWjP5gPRt=6G_ioyiuhZtY6APz_Zm9xzqg@mail.gmail.com>
Message-ID: <CAGLrAXNECGL0HkXQ1OCD61M5b4CysMpqq_=VRoEYPNMN-jAMPg@mail.gmail.com>

Hi Ken,

The patch looks good to me. If there are no objections I'll push this for
you.

Cheers,

- Josh

On Wed, Apr 3, 2019 at 10:33 AM Ken Dobson <kdobson at redhat.com> wrote:

> Oops good catch not sure how I missed that. I think I've caught them all
> now.
>
> http://cr.openjdk.java.net/~kdobson/addpagefromproperties2/webrev/
>
> Ken Dobson
>
> On Tue, Apr 2, 2019 at 11:02 PM Marcus Hirt <marcus.hirt at datadoghq.com>
> wrote:
>
> > Hi Ken,
> >
> > Thanks for the updated review!
> >
> > There is a System.out.println that you probably didn't intend to leave in
> > there:
> >
> >
> http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrPropertySheet.java.cdiff.html
> >
> > Also, I still see funky whitespace in line endings JfrPropertySheet @@
> > -330,7 +342,19 @@.
> >
> > Kind regards,
> > Marcus
> >
> > On Tue, Apr 2, 2019 at 4:02 PM Ken Dobson <kdobson at redhat.com> wrote:
> >
> >> Thanks for the review, here's the webrev with trailing spaces removed.
> >>
> >> http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/
> >>
> >> Thanks,
> >>
> >> Ken Dobson
> >>
> >> On Mon, Apr 1, 2019 at 9:44 PM Marcus Hirt <marcus.hirt at datadoghq.com>
> >> wrote:
> >>
> >>> Hi Ken!
> >>>
> >>> There are some trailing spaces that should be removed, but other than
> >>> that it looks good!
> >>>
> >>> Kind regards,
> >>> Marcus
> >>>
> >>> On Mon, Apr 1, 2019 at 7:14 PM Ken Dobson <kdobson at redhat.com> wrote:
> >>>
> >>>> Hi all,
> >>>> please review this patch for JMC-4469 to allow for adding a page with
> >>>> the
> >>>> events selected in the property view.
> >>>>
> >>>> bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4469
> >>>> webrev:
> >>>> http://cr.openjdk.java.net/~kdobson/addpagefromproperties/webrev/
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Ken Dobson
> >>>>
> >>>
>

From marcus at hirt.se  Mon Apr 29 20:36:22 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Mon, 29 Apr 2019 20:36:22 +0000
Subject: hg: jmc/jmc: JMC-6274: Add Eclipse 2018-12 and 2019-03 target
 platforms
Message-ID: <201904292036.x3TKaMnU004478@aojmv0008.oracle.com>

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


From jmatsuok at redhat.com  Mon Apr 29 20:37:49 2019
From: jmatsuok at redhat.com (Joshua Matsuoka)
Date: Mon, 29 Apr 2019 16:37:49 -0400
Subject: Review request for JMC-4645: Add size distribution chart to IO
 Pages
In-Reply-To: <CAOsn=ko0NBJB3+2RiAEzzC+HPMLL6ogZdZ1VvW090eV+YVSHKg@mail.gmail.com>
References: <CADPaBq=wDCPdznYD=BECUoBKU8jYB54e1q5CqR9s-Kp5MBNqbA@mail.gmail.com>
 <CAOsn=kr9a--EyCd91O5--jykiGrdOHeHjRC0D4gmEQ1vDdhDzw@mail.gmail.com>
 <CADPaBqk22qqFQsZ8x0ygnaU+4HZnBPh6zsOAZsmVK01j1QofXg@mail.gmail.com>
 <CADPaBqmRB7-w19fKDi9Dj7xnRPKzfUZvY04FGBfCVB7YrnGWYQ@mail.gmail.com>
 <CAOsn=ko0NBJB3+2RiAEzzC+HPMLL6ogZdZ1VvW090eV+YVSHKg@mail.gmail.com>
Message-ID: <CAGLrAXPdRKZAmc_eXKrcgmmubNmFs2O1RfSrFikjGrC-_MF5fQ@mail.gmail.com>

Hi Ken,

Looks good to me. If there are no further objections I'll push this for you.

Cheers,

- Josh

On Mon, Apr 8, 2019 at 9:31 AM Alex Macdonald <almacdon at redhat.com> wrote:

> On Fri, Apr 5, 2019 at 3:56 PM Ken Dobson <kdobson at redhat.com> wrote:
>
> > And here is an updated webrev that removes the unused imports and should
> > have no excess whitespace.
> >
> > http://cr.openjdk.java.net/~kdobson/sizedistributionchart1/webrev/
> >
>
> Thanks, it looks good to me.
>
>
> >
> > Addressing Alex's question about the distribution, there were 1797 socket
> > reads each of ~1B which adds up to a total of 1.89KiB read.
> >
> > Thanks,
> >
> > Ken Dobson
> >
> > On Fri, Apr 5, 2019 at 3:49 PM Ken Dobson <kdobson at redhat.com> wrote:
> >
> >> Here is the previous messages from this list for some reason they
> haven't
> >> shown up to the others on the list as well as the pipermail archives.
> >>
> >> From: Marcus Hirt <marcus.hirt at datadoghq.com>
> >> Date: Tue, Apr 2, 2019 at 10:55 PM
> >> Subject: Re: Review request for JMC-4645: Add size distribution chart to
> >> IO Pages
> >> To: Ken Dobson <kdobson at redhat.com>
> >> Cc: <jmc-dev at openjdk.java.net>
> >>
> >>
> >> Looks good!
> >>
> >> Kind regards,
> >> Marcus
> >>
> >> On Tue, Apr 2, 2019 at 4:51 PM Ken Dobson <kdobson at redhat.com> wrote:
> >>
> >>> Thanks for the review, here's the new webrev removing unnecessary
> >>> whitespace.
> >>>
> >>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart0/webrev
> >>>
> >>> Ken Dobson
> >>>
> >>> On Mon, Apr 1, 2019 at 9:27 PM Marcus Hirt <marcus.hirt at datadoghq.com>
> >>> wrote:
> >>>
> >>>> Hi Ken,
> >>>>
> >>>> It generally looks good, but:
> >>>>
> >>>>    - When I apply your patch, I see a lot of whitespace line endings.
> >>>>    Whilst we're not enforcing that there is no trailing whitespace,
> it would
> >>>>    be nice to avoid. E.g.
> >>>>
> >>>> [image: image.png]
> >>>>
> >>>>    - Is the reason for adding 64 bytes to the maxValue (if there is
> >>>>    one) cosmetic padding?
> >>>>      sizeMax = sizeMax == null ? UnitLookup.BYTE.quantity(64):
> >>>>    sizeMax.add(UnitLookup.BYTE.quantity(64));
> >>>>
> >>>> Kind regards,
> >>>> Marcus
> >>>>
> >>>> On Fri, Mar 29, 2019 at 4:07 PM Ken Dobson <kdobson at redhat.com>
> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Please review this patch I've made that adds a size distribution
> chart
> >>>>> to
> >>>>> the IO Pages.
> >>>>>
> >>>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
> >>>>> Webrev:
> >>>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Ken Dobson
> >>>>>
> >>>>
> >> On Fri, Apr 5, 2019 at 2:36 PM Alex Macdonald <almacdon at redhat.com>
> >> wrote:
> >>
> >>> Hi Ken,
> >>>
> >>> On Fri, Mar 29, 2019 at 4:08 PM Ken Dobson <kdobson at redhat.com> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Please review this patch I've made that adds a size distribution chart
> >>>> to
> >>>> the IO Pages.
> >>>>
> >>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
> >>>> Webrev:
> >>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
> >>>
> >>>
> >>> Overall the code looks good from what I can tell.
> >>>
> >>> Having said that, I just want to confirm what I'm reading off the
> chart,
> >>> let's use this sample screen shot [0] (https://imgur.com/sPo9Xeo) as
> an
> >>> example. The y-axis displays the number of reads/writes, and the x-axis
> >>> displays the size of that read or write? If that's the case I'm a bit
> >>> confused. The blue bar (write) hits 1 on the y axis for 1 read, and is
> >>> displayed at ~6.16KiB on the x axis because that's how much it wrote.
> >>> However, the red bar (read) hits 1797 on the y axis for 1797 reads as
> >>> expected, but why does the x axis display 0 - 256B when there was 1.89
> KiB
> >>> read in total?
> >>>
> >>> A couple of formatting nits:
> >>>
> >>> 1. There are some unused imports in the DataPageToolkit
> >>>
> >>> [...]
> >>> +import org.openjdk.jmc.flightrecorder.ui.PageManager;
> >>> [...]
> >>> +import
> org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage;+import
> org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage.ItemHandlerUiStandIn;
> >>> [...]
> >>>
> >>> 2. Excess white space just before (and inside)
> >>> DataPageToolkit.buildSizeHistogram()
> >>> 3. JDKAttributes, SocketIO & FileIO pages also each have a few
> instances
> >>> of excess/trailing white space
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Ken Dobson
> >>>>
> >>>
> >>> Cheers,
> >>>
> >>> Alex
> >>>
> >>> [0] https://imgur.com/sPo9Xeo
> >>>
> >>
>

From marcus at hirt.se  Mon Apr 29 20:54:57 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Mon, 29 Apr 2019 22:54:57 +0200
Subject: SV: Review Request for JMC-4469: Adding a page from the properties
 view
In-Reply-To: <CAGLrAXNECGL0HkXQ1OCD61M5b4CysMpqq_=VRoEYPNMN-jAMPg@mail.gmail.com>
References: <CADPaBqnoF4kD0Et53nrrbpFwU0CzZKXVO2wnYQ47d6+YmseiLA@mail.gmail.com>
 <CAOpWGx3u0p-SwNevwHXcMrKj=KFRixSV1cLE35XNEkotHuSBkQ@mail.gmail.com>
 <CADPaBqnpDAqKbc4Skd0rq5=dOgcmAS0TztrYYwN0_U1aWTNsQw@mail.gmail.com>
 <CAOpWGx2QhJ2czwXmHW79fmJOGYFPBw7Vo7MiWWekK4H_R4hSWA@mail.gmail.com>
 <CADPaBqkQC2voHrGWVWjP5gPRt=6G_ioyiuhZtY6APz_Zm9xzqg@mail.gmail.com>
 <CAGLrAXNECGL0HkXQ1OCD61M5b4CysMpqq_=VRoEYPNMN-jAMPg@mail.gmail.com>
Message-ID: <062c01d4fecd$ce0c9970$6a25cc50$@hirt.se>

Good to go! :)

/M

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Joshua Matsuoka
Skickat: den 29 april 2019 22:27
Till: Ken Dobson <kdobson at redhat.com>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: Review Request for JMC-4469: Adding a page from the properties view

Hi Ken,

The patch looks good to me. If there are no objections I'll push this for you.

Cheers,

- Josh

On Wed, Apr 3, 2019 at 10:33 AM Ken Dobson <kdobson at redhat.com> wrote:

> Oops good catch not sure how I missed that. I think I've caught them 
> all now.
>
> http://cr.openjdk.java.net/~kdobson/addpagefromproperties2/webrev/
>
> Ken Dobson
>
> On Tue, Apr 2, 2019 at 11:02 PM Marcus Hirt 
> <marcus.hirt at datadoghq.com>
> wrote:
>
> > Hi Ken,
> >
> > Thanks for the updated review!
> >
> > There is a System.out.println that you probably didn't intend to 
> > leave in
> > there:
> >
> >
> http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/appl
> ication/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jm
> c/flightrecorder/ui/JfrPropertySheet.java.cdiff.html
> >
> > Also, I still see funky whitespace in line endings JfrPropertySheet 
> > @@
> > -330,7 +342,19 @@.
> >
> > Kind regards,
> > Marcus
> >
> > On Tue, Apr 2, 2019 at 4:02 PM Ken Dobson <kdobson at redhat.com> wrote:
> >
> >> Thanks for the review, here's the webrev with trailing spaces removed.
> >>
> >> http://cr.openjdk.java.net/~kdobson/addpagefromproperties1/webrev/
> >>
> >> Thanks,
> >>
> >> Ken Dobson
> >>
> >> On Mon, Apr 1, 2019 at 9:44 PM Marcus Hirt 
> >> <marcus.hirt at datadoghq.com>
> >> wrote:
> >>
> >>> Hi Ken!
> >>>
> >>> There are some trailing spaces that should be removed, but other 
> >>> than that it looks good!
> >>>
> >>> Kind regards,
> >>> Marcus
> >>>
> >>> On Mon, Apr 1, 2019 at 7:14 PM Ken Dobson <kdobson at redhat.com> wrote:
> >>>
> >>>> Hi all,
> >>>> please review this patch for JMC-4469 to allow for adding a page 
> >>>> with the events selected in the property view.
> >>>>
> >>>> bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4469
> >>>> webrev:
> >>>> http://cr.openjdk.java.net/~kdobson/addpagefromproperties/webrev/
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Ken Dobson
> >>>>
> >>>
>


From marcus at hirt.se  Mon Apr 29 20:55:10 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Mon, 29 Apr 2019 22:55:10 +0200
Subject: SV: Review request for JMC-4645: Add size distribution chart to IO
 Pages
In-Reply-To: <CAGLrAXPdRKZAmc_eXKrcgmmubNmFs2O1RfSrFikjGrC-_MF5fQ@mail.gmail.com>
References: <CADPaBq=wDCPdznYD=BECUoBKU8jYB54e1q5CqR9s-Kp5MBNqbA@mail.gmail.com>
 <CAOsn=kr9a--EyCd91O5--jykiGrdOHeHjRC0D4gmEQ1vDdhDzw@mail.gmail.com>
 <CADPaBqk22qqFQsZ8x0ygnaU+4HZnBPh6zsOAZsmVK01j1QofXg@mail.gmail.com>
 <CADPaBqmRB7-w19fKDi9Dj7xnRPKzfUZvY04FGBfCVB7YrnGWYQ@mail.gmail.com>
 <CAOsn=ko0NBJB3+2RiAEzzC+HPMLL6ogZdZ1VvW090eV+YVSHKg@mail.gmail.com>
 <CAGLrAXPdRKZAmc_eXKrcgmmubNmFs2O1RfSrFikjGrC-_MF5fQ@mail.gmail.com>
Message-ID: <062e01d4fecd$d5642d50$802c87f0$@hirt.se>

Good to go! :)

/M

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Joshua Matsuoka
Skickat: den 29 april 2019 22:38
Till: Alex Macdonald <almacdon at redhat.com>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: Review request for JMC-4645: Add size distribution chart to IO Pages

Hi Ken,

Looks good to me. If there are no further objections I'll push this for you.

Cheers,

- Josh

On Mon, Apr 8, 2019 at 9:31 AM Alex Macdonald <almacdon at redhat.com> wrote:

> On Fri, Apr 5, 2019 at 3:56 PM Ken Dobson <kdobson at redhat.com> wrote:
>
> > And here is an updated webrev that removes the unused imports and 
> > should have no excess whitespace.
> >
> > http://cr.openjdk.java.net/~kdobson/sizedistributionchart1/webrev/
> >
>
> Thanks, it looks good to me.
>
>
> >
> > Addressing Alex's question about the distribution, there were 1797 
> > socket reads each of ~1B which adds up to a total of 1.89KiB read.
> >
> > Thanks,
> >
> > Ken Dobson
> >
> > On Fri, Apr 5, 2019 at 3:49 PM Ken Dobson <kdobson at redhat.com> wrote:
> >
> >> Here is the previous messages from this list for some reason they
> haven't
> >> shown up to the others on the list as well as the pipermail archives.
> >>
> >> From: Marcus Hirt <marcus.hirt at datadoghq.com>
> >> Date: Tue, Apr 2, 2019 at 10:55 PM
> >> Subject: Re: Review request for JMC-4645: Add size distribution 
> >> chart to IO Pages
> >> To: Ken Dobson <kdobson at redhat.com>
> >> Cc: <jmc-dev at openjdk.java.net>
> >>
> >>
> >> Looks good!
> >>
> >> Kind regards,
> >> Marcus
> >>
> >> On Tue, Apr 2, 2019 at 4:51 PM Ken Dobson <kdobson at redhat.com> wrote:
> >>
> >>> Thanks for the review, here's the new webrev removing unnecessary 
> >>> whitespace.
> >>>
> >>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart0/webrev
> >>>
> >>> Ken Dobson
> >>>
> >>> On Mon, Apr 1, 2019 at 9:27 PM Marcus Hirt 
> >>> <marcus.hirt at datadoghq.com>
> >>> wrote:
> >>>
> >>>> Hi Ken,
> >>>>
> >>>> It generally looks good, but:
> >>>>
> >>>>    - When I apply your patch, I see a lot of whitespace line endings.
> >>>>    Whilst we're not enforcing that there is no trailing 
> >>>> whitespace,
> it would
> >>>>    be nice to avoid. E.g.
> >>>>
> >>>> [image: image.png]
> >>>>
> >>>>    - Is the reason for adding 64 bytes to the maxValue (if there is
> >>>>    one) cosmetic padding?
> >>>>      sizeMax = sizeMax == null ? UnitLookup.BYTE.quantity(64):
> >>>>    sizeMax.add(UnitLookup.BYTE.quantity(64));
> >>>>
> >>>> Kind regards,
> >>>> Marcus
> >>>>
> >>>> On Fri, Mar 29, 2019 at 4:07 PM Ken Dobson <kdobson at redhat.com>
> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Please review this patch I've made that adds a size distribution
> chart
> >>>>> to
> >>>>> the IO Pages.
> >>>>>
> >>>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
> >>>>> Webrev:
> >>>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev
> >>>>> /
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Ken Dobson
> >>>>>
> >>>>
> >> On Fri, Apr 5, 2019 at 2:36 PM Alex Macdonald <almacdon at redhat.com>
> >> wrote:
> >>
> >>> Hi Ken,
> >>>
> >>> On Fri, Mar 29, 2019 at 4:08 PM Ken Dobson <kdobson at redhat.com> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Please review this patch I've made that adds a size distribution 
> >>>> chart to the IO Pages.
> >>>>
> >>>> Bug: https://bugs.openjdk.java.net/projects/JMC/issues/JMC-4645
> >>>> Webrev:
> >>>> http://cr.openjdk.java.net/~kdobson/sizedistributionchart/webrev/
> >>>
> >>>
> >>> Overall the code looks good from what I can tell.
> >>>
> >>> Having said that, I just want to confirm what I'm reading off the
> chart,
> >>> let's use this sample screen shot [0] (https://imgur.com/sPo9Xeo) 
> >>> as
> an
> >>> example. The y-axis displays the number of reads/writes, and the 
> >>> x-axis displays the size of that read or write? If that's the case 
> >>> I'm a bit confused. The blue bar (write) hits 1 on the y axis for 
> >>> 1 read, and is displayed at ~6.16KiB on the x axis because that's how much it wrote.
> >>> However, the red bar (read) hits 1797 on the y axis for 1797 reads 
> >>> as expected, but why does the x axis display 0 - 256B when there 
> >>> was 1.89
> KiB
> >>> read in total?
> >>>
> >>> A couple of formatting nits:
> >>>
> >>> 1. There are some unused imports in the DataPageToolkit
> >>>
> >>> [...]
> >>> +import org.openjdk.jmc.flightrecorder.ui.PageManager;
> >>> [...]
> >>> +import
> org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage;+i
> mport 
> org.openjdk.jmc.flightrecorder.ui.pages.itemhandler.ItemHandlerPage.It
> emHandlerUiStandIn;
> >>> [...]
> >>>
> >>> 2. Excess white space just before (and inside)
> >>> DataPageToolkit.buildSizeHistogram()
> >>> 3. JDKAttributes, SocketIO & FileIO pages also each have a few
> instances
> >>> of excess/trailing white space
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Ken Dobson
> >>>>
> >>>
> >>> Cheers,
> >>>
> >>> Alex
> >>>
> >>> [0] https://imgur.com/sPo9Xeo
> >>>
> >>
>


From marcus at hirt.se  Mon Apr 29 21:11:40 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Mon, 29 Apr 2019 23:11:40 +0200
Subject: Review request for JMC-6429: Upgrade to ASM 7.1.
Message-ID: <063001d4fed0$235913c0$6a0b3b40$@hirt.se>

Hi all,

Please review this upgrade to ASM 7.1 for the JMC agent.

Jira:   https://bugs.openjdk.java.net/browse/JMC-6429
Patch:

diff -r 0339c57d510c core/org.openjdk.jmc.agent/pom.xml
--- a/core/org.openjdk.jmc.agent/pom.xml       Mon Apr 29 22:36:10 2019 +0200
+++ b/core/org.openjdk.jmc.agent/pom.xml       Mon Apr 29 22:47:53 2019 +0200
@@ -40,7 +40,7 @@
        <properties>
                <maven.compiler.source>1.7</maven.compiler.source>
                <maven.compiler.target>1.7</maven.compiler.target>
-            <asm.version>7.0</asm.version>
+            <asm.version>7.1</asm.version>
                <junit.version>4.12</junit.version>
 
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        </properties>

Kind regards,
Marcus


From guru.hb at oracle.com  Tue Apr 30 00:34:02 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 30 Apr 2019 06:04:02 +0530
Subject: Review request for JMC-6429: Upgrade to ASM 7.1.
In-Reply-To: <063001d4fed0$235913c0$6a0b3b40$@hirt.se>
References: <063001d4fed0$235913c0$6a0b3b40$@hirt.se>
Message-ID: <4E459C8B-76D7-4036-B23F-BB96DBD4FC16@oracle.com>

+1, 

Thanks,
Guru
> On 30-Apr-2019, at 2:41 AM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi all,
> 
> Please review this upgrade to ASM 7.1 for the JMC agent.
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6429
> Patch:
> 
> diff -r 0339c57d510c core/org.openjdk.jmc.agent/pom.xml
> --- a/core/org.openjdk.jmc.agent/pom.xml       Mon Apr 29 22:36:10 2019 +0200
> +++ b/core/org.openjdk.jmc.agent/pom.xml       Mon Apr 29 22:47:53 2019 +0200
> @@ -40,7 +40,7 @@
>        <properties>
>                <maven.compiler.source>1.7</maven.compiler.source>
>                <maven.compiler.target>1.7</maven.compiler.target>
> -            <asm.version>7.0</asm.version>
> +            <asm.version>7.1</asm.version>
>                <junit.version>4.12</junit.version>
> 
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
>        </properties>
> 
> Kind regards,
> Marcus
> 


From marcus at hirt.se  Tue Apr 30 07:34:26 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Tue, 30 Apr 2019 07:34:26 +0000
Subject: hg: jmc/jmc: JMC-6429: Upgrade to ASM 7.1
Message-ID: <201904300734.x3U7YQZb019056@aojmv0008.oracle.com>

Changeset: 4a531e6f5fef
Author:    hirt <marcus.hirt at oracle.com>
Date:      2019-04-30 09:34 +0200
URL:       http://hg.openjdk.java.net/jmc/jmc/rev/4a531e6f5fef

JMC-6429: Upgrade to ASM 7.1
Reviewed-by: ghb

! core/org.openjdk.jmc.agent/pom.xml


From neugens at redhat.com  Tue Apr 30 16:34:22 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 30 Apr 2019 18:34:22 +0200
Subject: Result: New jmc Committer: Alex Macdonald
Message-ID: <CAJwKKma0LxbVBVEGgBr9BygHSoeswye-Q6Lqi=X3PejQsWvs5A@mail.gmail.com>

Voting for  Alex Macdonald [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Kind regards,
Mario

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

-- 
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  Tue Apr 30 17:00:47 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 30 Apr 2019 19:00:47 +0200
Subject: Result: New jmc Committer: Alex Macdonald
In-Reply-To: <CAJwKKma0LxbVBVEGgBr9BygHSoeswye-Q6Lqi=X3PejQsWvs5A@mail.gmail.com>
References: <CAJwKKma0LxbVBVEGgBr9BygHSoeswye-Q6Lqi=X3PejQsWvs5A@mail.gmail.com>
Message-ID: <CAOpWGx1JZwJHhBAzErwTKGpb3rEBFMXSJ1wZDkP9S3586SaByQ@mail.gmail.com>

Congratulations Alex, and welcome as a committer! :)

Kind regards,
Marcus

On Tue, Apr 30, 2019 at 6:35 PM Mario Torre <neugens at redhat.com> wrote:

> Voting for  Alex Macdonald [1] is now closed.
>
> Yes: 4
> Veto: 0
> Abstain: 0
>
> According to the Bylaws definition of Lazy Consensus, this is
> sufficient to approve the nomination.
>
> Kind regards,
> Mario
>
> [1] https://mail.openjdk.java.net/pipermail/jmc-dev/2019-April/000934.html
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From miro.wengner at gmail.com  Tue Apr 30 19:32:22 2019
From: miro.wengner at gmail.com (Miro Wengner)
Date: Tue, 30 Apr 2019 21:32:22 +0200
Subject: Result: New jmc Committer: Alex Macdonald
In-Reply-To: <CAOpWGx1JZwJHhBAzErwTKGpb3rEBFMXSJ1wZDkP9S3586SaByQ@mail.gmail.com>
References: <CAJwKKma0LxbVBVEGgBr9BygHSoeswye-Q6Lqi=X3PejQsWvs5A@mail.gmail.com>
 <CAOpWGx1JZwJHhBAzErwTKGpb3rEBFMXSJ1wZDkP9S3586SaByQ@mail.gmail.com>
Message-ID: <E2FB5401-1D07-48CD-862E-0840A7C664A5@gmail.com>

Congratulation Alex ! 

> On Apr 30, 2019, at 7:00 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> 
> Congratulations Alex, and welcome as a committer! :)
> 
> Kind regards,
> Marcus
> 
> On Tue, Apr 30, 2019 at 6:35 PM Mario Torre <neugens at redhat.com> wrote:
> 
>> Voting for  Alex Macdonald [1] is now closed.
>> 
>> Yes: 4
>> Veto: 0
>> Abstain: 0
>> 
>> According to the Bylaws definition of Lazy Consensus, this is
>> sufficient to approve the nomination.
>> 
>> Kind regards,
>> Mario
>> 
>> [1] https://mail.openjdk.java.net/pipermail/jmc-dev/2019-April/000934.html
>> 
>> --
>> 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 at hirt.se  Tue Apr 30 20:17:48 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 30 Apr 2019 22:17:48 +0200
Subject: Review request for JMC-6460: Simple mechanism for building JMC under
 docker.
Message-ID: <003301d4ff91$c781cb60$56856220$@hirt.se>

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 jkang at redhat.com  Tue Apr 30 21:10:44 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 30 Apr 2019 17:10:44 -0400
Subject: Review request for JMC-6460: Simple mechanism for building JMC
 under docker.
In-Reply-To: <003301d4ff91$c781cb60$56856220$@hirt.se>
References: <003301d4ff91$c781cb60$56856220$@hirt.se>
Message-ID: <CAEBeOcpvA0HBXTw1BOaNJuZ0j6EtgJUFWR4m1ov8PVe-aQYxOA@mail.gmail.com>

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
>