From hirt at openjdk.java.net  Mon Dec  2 16:05:58 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 2 Dec 2019 16:05:58 GMT
Subject: RFR: 6640: Run spotless and tests as part of the workflow
In-Reply-To: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
References: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
Message-ID: <w2MmVUKeLFsw2eVGXI1UujBqvKDEN5J_-G9PvjHZDY4=.ae758563-60d8-450c-a6db-4b246e253745@github.com>

On Thu, 28 Nov 2019 23:52:00 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Running the tests on Linux, Mac OS X and Windows. Holding off a bit on the UI-tests for now.
> 
> ----------------
> 
> Commits:
>  - d312b938: Want scripts
>  - 6c2b8533: Installing core before the formatting check
>  - 7158f059: More windows fun
>  - 5a0b675e: Fixing windows formatting script
>  - b08ef9a3: Adding scripts for checking formatting and running tests
>  - 1aea5e6e: Better name
>  - 80d352f3: Testing
> 
> Changes: https://git.openjdk.java.net/jmc/pull/10/files
>  Webrev: https://webrevs.openjdk.java.net/jmc/10/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JMC-6640
>   Stats: 106 lines in 8 files changed: 105 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/10.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/10/head:pull/10

@rwestberg - I don't have much experience with this; is this the right way to do this?

PR: https://git.openjdk.java.net/jmc/pull/10

From rwestberg at openjdk.java.net  Mon Dec  2 16:15:41 2019
From: rwestberg at openjdk.java.net (Robin Westberg)
Date: Mon, 2 Dec 2019 16:15:41 GMT
Subject: [Rev 04] RFR: 6640: Run spotless and tests as part of the workflow
In-Reply-To: <SO-aPihy4v8ZpkQRjP_nD52I4vNzIDgwSPmiOdD4Z98=.60c8563c-7fb1-40ba-bc65-a7fc996bec53@github.com>
References: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
 <SO-aPihy4v8ZpkQRjP_nD52I4vNzIDgwSPmiOdD4Z98=.60c8563c-7fb1-40ba-bc65-a7fc996bec53@github.com>
Message-ID: <zh_q_H2P89NMe9GB4AxqDXmWD7G4VTIXyvvEPu7VHn4=.63cfc4b4-f56b-4a15-9327-b8c37354a02e@github.com>

On Fri, 29 Nov 2019 13:22:47 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - c41f5c0f: Making the .gitignore better whilst forcing a rerun to ensure that passing on all platforms was more than a lucky break
> 
> Changes:
>   - all: https://git.openjdk.java.net/jmc/pull/10/files
>   - new: https://git.openjdk.java.net/jmc/pull/10/files/e2d8a1d7..c41f5c0f
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jmc/10/webrev.04
>  - incr: https://webrevs.openjdk.java.net/jmc/10/webrev.03-04
> 
>   Issue: https://bugs.openjdk.java.net/browse/JMC-6640
>   Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/10.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/10/head:pull/10

Looks good to me! I'm not an expert in this area, but I think it's pretty much how you do it. You could probably combine the identical mac and linux steps with some more advanced syntax, but not sure it's worth it.

.jcheck/conf line 41:

> 40: [checks]
> 41: error=author,reviewers,merge,message,issues
> 42: 

If you want to retain the executable check, you could prefix the commands with `sh`..

----------------

Approved by rwestberg (no project role).

PR: https://git.openjdk.java.net/jmc/pull/10

From hirt at openjdk.java.net  Mon Dec  2 17:29:31 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 2 Dec 2019 17:29:31 GMT
Subject: [Rev 04] RFR: 6640: Run spotless and tests as part of the workflow
In-Reply-To: <zh_q_H2P89NMe9GB4AxqDXmWD7G4VTIXyvvEPu7VHn4=.63cfc4b4-f56b-4a15-9327-b8c37354a02e@github.com>
References: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
 <SO-aPihy4v8ZpkQRjP_nD52I4vNzIDgwSPmiOdD4Z98=.60c8563c-7fb1-40ba-bc65-a7fc996bec53@github.com>
 <zh_q_H2P89NMe9GB4AxqDXmWD7G4VTIXyvvEPu7VHn4=.63cfc4b4-f56b-4a15-9327-b8c37354a02e@github.com>
Message-ID: <Fz9qopQMcvK--TyPDSqrOzjSKyg7-SHSy5VsvvEKtfM=.2783886d-3666-4a00-a12a-fc4637cdb993@github.com>

On Mon, 2 Dec 2019 16:15:41 GMT, Robin Westberg <rwestberg at openjdk.org> wrote:

> On Fri, 29 Nov 2019 13:22:47 GMT, Marcus Hirt <hirt at openjdk.org> wrote:
> 
>> The pull request has been updated with additional changes.
>> 
>> ----------------
>> 
>> Added commits:
>>  - c41f5c0f: Making the .gitignore better whilst forcing a rerun to ensure that passing on all platforms was more than a lucky break
>> 
>> Changes:
>>   - all: https://git.openjdk.java.net/jmc/pull/10/files
>>   - new: https://git.openjdk.java.net/jmc/pull/10/files/e2d8a1d7..c41f5c0f
>> 
>> Webrevs:
>>  - full: https://webrevs.openjdk.java.net/jmc/10/webrev.04
>>  - incr: https://webrevs.openjdk.java.net/jmc/10/webrev.03-04
>> 
>>   Issue: https://bugs.openjdk.java.net/browse/JMC-6640
>>   Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
>>   Patch: https://git.openjdk.java.net/jmc/pull/10.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/10/head:pull/10
> 
> Looks good to me! I'm not an expert in this area, but I think it's pretty much how you do it. You could probably combine the identical mac and linux steps with some more advanced syntax, but not sure it's worth it.
> 
> .jcheck/conf line 41:
> 
>> 40: [checks]
>> 41: error=author,reviewers,merge,message,issues
>> 42: 
> 
> If you want to retain the executable check, you could prefix the commands with `sh`..
> 
> ----------------
> 
> Approved by rwestberg (no project role).

Ok. I find it convenient to have these scripts executable locally. I have no real strong opinions on this though. If someone cares strongly either way, please let me know.

PR: https://git.openjdk.java.net/jmc/pull/10

From hirt at openjdk.java.net  Mon Dec  2 19:05:51 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 2 Dec 2019 19:05:51 GMT
Subject: [Rev 05] RFR: 6640: Run spotless and tests as part of the workflow
In-Reply-To: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
References: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
Message-ID: <oQNx3kZnR9k7-KLAq2UUeOZz4xVYS-aGrlmm3AAHnNw=.95bdde30-0a76-49fd-94df-70d735368cf0@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 82498734: Fixing bug in the windows script

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/10/files
  - new: https://git.openjdk.java.net/jmc/pull/10/files/c41f5c0f..82498734

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/10/webrev.05
 - incr: https://webrevs.openjdk.java.net/jmc/10/webrev.04-05

  Issue: https://bugs.openjdk.java.net/browse/JMC-6640
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/10.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/10/head:pull/10

PR: https://git.openjdk.java.net/jmc/pull/10

From hdafgard at openjdk.java.net  Tue Dec  3 14:25:49 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Tue, 3 Dec 2019 14:25:49 GMT
Subject: [Approved] RFR: 6640: Run spotless and tests as part of the
 workflow
In-Reply-To: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
References: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
 <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
Message-ID: <9EjKcYPxPMKnvHg_ewALiAFgRXpYAzjhZTFVDgqsmjU=.0083c8b2-2da9-47cb-8175-398f8dfaef40@github.com>

On Mon, 2 Dec 2019 19:05:51 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 82498734: Fixing bug in the windows script
> 
> Changes:
>   - all: https://git.openjdk.java.net/jmc/pull/10/files
>   - new: https://git.openjdk.java.net/jmc/pull/10/files/c41f5c0f..82498734
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jmc/10/webrev.05
>  - incr: https://webrevs.openjdk.java.net/jmc/10/webrev.04-05
> 
>   Issue: https://bugs.openjdk.java.net/browse/JMC-6640
>   Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/10.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/10/head:pull/10

Approved by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/10

From hdafgard at openjdk.java.net  Tue Dec  3 15:47:16 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Tue, 3 Dec 2019 15:47:16 GMT
Subject: RFR: 6650: Autoboxing rule breaks on allocation outside TLAB
Message-ID: <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>

The autoboxing rule sometimes breaks when run on a recording that contains allocations outside tlabs, since it looks for an attribute that doesn't exist on that type.

----------------

Commits:
 - 8c4c0cf7: Create synthetic attribute combining inside/outside tlab allocation sizes, used for autoboxing rule

Changes: https://git.openjdk.java.net/jmc/pull/11/files
 Webrev: https://webrevs.openjdk.java.net/jmc/11/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6650
  Stats: 41 lines in 5 files changed: 15 ins; 14 del; 12 mod
  Patch: https://git.openjdk.java.net/jmc/pull/11.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/11/head:pull/11

PR: https://git.openjdk.java.net/jmc/pull/11

From hdafgard at openjdk.java.net  Tue Dec  3 15:51:10 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Tue, 3 Dec 2019 15:51:10 GMT
Subject: [Rev 01] RFR: 6650: Autoboxing rule breaks on allocation outside
 TLAB
In-Reply-To: <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>
References: <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>
Message-ID: <6EaxkMhF625Qb3-whiI9m0AQnvXnd3DfcmzG-cO3Iic=.c79740bd-5541-4187-a69f-2de3960e5e42@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 34483fc7: Fix formatting

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/11/files
  - new: https://git.openjdk.java.net/jmc/pull/11/files/8c4c0cf7..34483fc7

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/11/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/11/webrev.00-01

  Issue: https://bugs.openjdk.java.net/browse/JMC-6650
  Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jmc/pull/11.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/11/head:pull/11

PR: https://git.openjdk.java.net/jmc/pull/11

From hirt at openjdk.java.net  Tue Dec  3 17:14:03 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 3 Dec 2019 17:14:03 GMT
Subject: [Approved] RFR: 6650: Autoboxing rule breaks on allocation
 outside TLAB
In-Reply-To: <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>
References: <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>
 <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>
Message-ID: <LqzKEotiwz96Sw3oAU3yPIwMEQ_Euf9TGtcwoBSkgj8=.9d9229fd-1e41-4004-a92b-d137fa84eb44@github.com>

On Tue, 3 Dec 2019 15:51:10 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 34483fc7: Fix formatting
> 
> Changes:
>   - all: https://git.openjdk.java.net/jmc/pull/11/files
>   - new: https://git.openjdk.java.net/jmc/pull/11/files/8c4c0cf7..34483fc7
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jmc/11/webrev.01
>  - incr: https://webrevs.openjdk.java.net/jmc/11/webrev.00-01
> 
>   Issue: https://bugs.openjdk.java.net/browse/JMC-6650
>   Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/11.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/11/head:pull/11

Approved by hirt (Lead).

PR: https://git.openjdk.java.net/jmc/pull/11

From hdafgard at openjdk.java.net  Tue Dec  3 17:40:41 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Tue, 3 Dec 2019 17:40:41 GMT
Subject: [Integrated] RFR: 6650: Autoboxing rule breaks on allocation
 outside TLAB
In-Reply-To: <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>
References: <ibDXJHWKEc3WJA-SJP7mWv6ylP0i6OEhB1N5vBZv8ws=.4781dda2-56cc-4221-88aa-0c320f8cafd3@github.com>
Message-ID: <37ab72ee-2a07-4c57-90ff-8a6f7cba0d6a@openjdk.org>

Changeset: db8c7e44
Author:    Henrik Dafg?rd <hdafgard at openjdk.org>
Date:      2019-12-03 17:39:59 +0000
URL:       https://git.openjdk.java.net/jmc/commit/db8c7e44

6650: Autoboxing rule breaks on allocation outside TLAB

Reviewed-by: hirt

! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AutoBoxingRule.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/messages/internal/Messages.java
! core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/jdk/messages/internal/messages.properties

From hdafgard at gmail.com  Tue Dec  3 18:28:22 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Tue, 3 Dec 2019 19:28:22 +0100
Subject: Review Request: JMC-6650 Fix Autoboxing Rule
Message-ID: <CADFkdVS_H7=jSDN5J47bK8OtOq-GoKCfvbK0E4cTB++uewogZg@mail.gmail.com>

Hi all,

The Primitive to Object Conversion (or Autoboxing) rule breaks when run on
recordings with Allocation Outside TLAB events. The fix for this is fairly
simple and requires creating a synthetic attribute that combines TLAB size
and Allocation size (the same as is used by the total allocation
aggregator). This issue is a backport of the fix recently merged into the
main repo.

JIRA: https://bugs.openjdk.java.net/browse/JMC-6650
WebRev: https://cr.openjdk.java.net/~hdafgard/JMC-6650/webrev.0/


Cheers,
Henrik Dafg?rd

From marcus at hirt.se  Tue Dec  3 18:56:19 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 3 Dec 2019 19:56:19 +0100
Subject: Sv: Review Request: JMC-6650 Fix Autoboxing Rule
In-Reply-To: <CADFkdVS_H7=jSDN5J47bK8OtOq-GoKCfvbK0E4cTB++uewogZg@mail.gmail.com>
References: <CADFkdVS_H7=jSDN5J47bK8OtOq-GoKCfvbK0E4cTB++uewogZg@mail.gmail.com>
Message-ID: <021501d5aa0b$59096dd0$0b1c4970$@hirt.se>

LGTM!

/M

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Henrik Dafg?rd
Skickat: den 3 december 2019 19:28
Till: jmc-dev at openjdk.java.net
?mne: Review Request: JMC-6650 Fix Autoboxing Rule

Hi all,

The Primitive to Object Conversion (or Autoboxing) rule breaks when run on recordings with Allocation Outside TLAB events. The fix for this is fairly simple and requires creating a synthetic attribute that combines TLAB size and Allocation size (the same as is used by the total allocation aggregator). This issue is a backport of the fix recently merged into the main repo.

JIRA: https://bugs.openjdk.java.net/browse/JMC-6650
WebRev: https://cr.openjdk.java.net/~hdafgard/JMC-6650/webrev.0/


Cheers,
Henrik Dafg?rd


From hdafgard at gmail.com  Wed Dec  4 12:52:02 2019
From: hdafgard at gmail.com (hdafgard at gmail.com)
Date: Wed, 04 Dec 2019 12:52:02 +0000
Subject: hg: jmc/jmc7: JMC-6650: Autoboxing rule does not handle some
 allocation events
Message-ID: <201912041252.xB4Cq2P6019603@aojmv0008.oracle.com>

Changeset: 0dc338015575
Author:    hdafgard <hdafgard at gmail.com>
Date:      2019-12-04 13:51 +0100
URL:       https://hg.openjdk.java.net/jmc/jmc7/rev/0dc338015575

JMC-6650: Autoboxing rule does not handle some allocation events
Summary: Added synthetic attribute combining TLAB size and allocation size to allow rule to get values from any kind of allocation event.
Reviewed-by: hirt

! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/AutoBoxingRule.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAttributes.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/messages/internal/Messages.java
! core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/jdk/messages/internal/messages.properties


From rwestberg at openjdk.java.net  Wed Dec  4 17:29:43 2019
From: rwestberg at openjdk.java.net (Robin Westberg)
Date: Wed, 4 Dec 2019 17:29:43 GMT
Subject: RFR: 6640: Run spotless and tests as part of the workflow
In-Reply-To: <w2MmVUKeLFsw2eVGXI1UujBqvKDEN5J_-G9PvjHZDY4=.ae758563-60d8-450c-a6db-4b246e253745@github.com>
References: <yKQ458cktFwtsgkOMKyq6FfYDeuuyqvQXQvjH8UjVYk=.c212372d-dddb-4bee-9216-19634fe806cd@github.com>
 <w2MmVUKeLFsw2eVGXI1UujBqvKDEN5J_-G9PvjHZDY4=.ae758563-60d8-450c-a6db-4b246e253745@github.com>
Message-ID: <C9dmBQm40M9-y3xy8Z5lVP-D69VGpO6tqp3H75nEgss=.56a05f54-9939-4971-b557-636632e5a106@github.com>

On Mon, 2 Dec 2019 16:05:58 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> On Thu, 28 Nov 2019 23:52:00 GMT, Marcus Hirt <hirt at openjdk.org> wrote:
> 
>> Running the tests on Linux, Mac OS X and Windows. Holding off a bit on the UI-tests for now.
>> 
>> ----------------
>> 
>> Commits:
>>  - d312b938: Want scripts
>>  - 6c2b8533: Installing core before the formatting check
>>  - 7158f059: More windows fun
>>  - 5a0b675e: Fixing windows formatting script
>>  - b08ef9a3: Adding scripts for checking formatting and running tests
>>  - 1aea5e6e: Better name
>>  - 80d352f3: Testing
>> 
>> Changes: https://git.openjdk.java.net/jmc/pull/10/files
>>  Webrev: https://webrevs.openjdk.java.net/jmc/10/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JMC-6640
>>   Stats: 106 lines in 8 files changed: 105 ins; 0 del; 1 mod
>>   Patch: https://git.openjdk.java.net/jmc/pull/10.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/10/head:pull/10
> 
> @rwestberg - I don't have much experience with this; is this the right way to do this?

I forgot to mention that you'll not be able to `/integrate` this PR - GitHub doesn't allow the "openjdk" user account to push changes to action workflow files. So you will have to push this change manually.

PR: https://git.openjdk.java.net/jmc/pull/10

From employeen13 at gmail.com  Thu Dec  5 09:56:58 2019
From: employeen13 at gmail.com (E N13)
Date: Thu, 5 Dec 2019 12:56:58 +0300
Subject: JMC-5721 Reintroduce the Percentage column
Message-ID: <CANd5FXxOo2PVPtRQ3typWnA7z=JvcFDhpdT8F9twWVQzJmMPqw@mail.gmail.com>

Hi all,

If there is no objection I'd like to work on the subj:
https://bugs.openjdk.java.net/browse/JMC-5721. Percentage column was very
helpfull in JMC 5.5 (JDK 8) when I needed to compare JFR profiles that were
collected before and after some code changes I made.


Regards,
Dmitry Popov

From marcus.hirt at datadoghq.com  Thu Dec  5 14:05:36 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 5 Dec 2019 15:05:36 +0100
Subject: JMC-5721 Reintroduce the Percentage column
In-Reply-To: <CANd5FXxOo2PVPtRQ3typWnA7z=JvcFDhpdT8F9twWVQzJmMPqw@mail.gmail.com>
References: <CANd5FXxOo2PVPtRQ3typWnA7z=JvcFDhpdT8F9twWVQzJmMPqw@mail.gmail.com>
Message-ID: <CAOpWGx3A-QCc9ibFHOBbmFyKndUD59NJOuE18=7EGnoyxP=RXg@mail.gmail.com>

No objection at all! :)

Kind regards,
Marcus

On Thu, Dec 5, 2019 at 10:57 AM E N13 <employeen13 at gmail.com> wrote:
>
> Hi all,
>
> If there is no objection I'd like to work on the subj:
> https://bugs.openjdk.java.net/browse/JMC-5721. Percentage column was very
> helpfull in JMC 5.5 (JDK 8) when I needed to compare JFR profiles that were
> collected before and after some code changes I made.
>
>
> Regards,
> Dmitry Popov

From duke at openjdk.java.net  Thu Dec  5 14:49:40 2019
From: duke at openjdk.java.net (duke)
Date: Thu, 5 Dec 2019 14:49:40 GMT
Subject: git: openjdk/jmc: 6640: Run spotless and tests as part of the workflow
Message-ID: <9da5891d-8510-475c-919b-2e38826e2345@openjdk.java.net>

Changeset: 93ab7cdb
Author:    Marcus Hirt <marcus at hirt.se>
Date:      2019-12-05 15:40:47 +0000
URL:       https://git.openjdk.java.net/jmc/commit/93ab7cdb

6640: Run spotless and tests as part of the workflow

+ .github/workflows/validate.yml
! .gitignore
! .jcheck/conf
+ scripts/checkformatting.bat
+ scripts/checkformatting.sh
+ scripts/runapptests.bat
+ scripts/runapptests.sh
+ scripts/runcoretests.bat
+ scripts/runcoretests.sh


From github.com+29706926+jessyec-s at openjdk.java.net  Thu Dec  5 15:32:23 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Thu, 5 Dec 2019 15:32:23 GMT
Subject: RFR: 6617: Make return value its own element
Message-ID: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>

This patch addresses [JMC-6617](https://bugs.openjdk.java.net/browse/JMC-6617): Better probe format for return values.

Currently method return values in the agent are described using a parameter element with an index of -1. This patch makes a designated returnvalue element that can be used for return values.

----------------

Commits:
 - 368cc573: Make return value its own element

Changes: https://git.openjdk.java.net/jmc/pull/6/files
 Webrev: https://webrevs.openjdk.java.net/jmc/6/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6617
  Stats: 272 lines in 11 files changed: 200 ins; 25 del; 47 mod
  Patch: https://git.openjdk.java.net/jmc/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6

PR: https://git.openjdk.java.net/jmc/pull/6

From hirt at openjdk.java.net  Thu Dec  5 16:01:42 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Dec 2019 16:01:42 GMT
Subject: RFR: 6617: Make return value its own element
In-Reply-To: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
Message-ID: <fJ4CLy9qXjGiMWK6Oqr6-ToeFLCU_BhmpteMYTX481A=.ee1fb468-1a76-4795-8e8d-1888c79eb99a@github.com>

On Thu, 5 Dec 2019 15:32:23 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch addresses [JMC-6617](https://bugs.openjdk.java.net/browse/JMC-6617): Better probe format for return values.
> 
> Currently method return values in the agent are described using a parameter element with an index of -1. This patch makes a designated returnvalue element that can be used for return values.
> 
> ----------------
> 
> Commits:
>  - 368cc573: Make return value its own element
> 
> Changes: https://git.openjdk.java.net/jmc/pull/6/files
>  Webrev: https://webrevs.openjdk.java.net/jmc/6/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JMC-6617
>   Stats: 272 lines in 11 files changed: 200 ins; 25 del; 47 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/6.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFREventClassGenerator.java line 120:

> 119: 
> 120: 	private static void createField(ClassWriter cw, JFRTransformDescriptor td, ReturnValue returnValue, Type type) {
> 121: 		if (!td.isAllowedFieldType(type)) {

Why explicitly adding returnValue to the parameters? Isn't the return value part of the transform descriptor?

PR: https://git.openjdk.java.net/jmc/pull/6

From github.com+29706926+jessyec-s at openjdk.java.net  Thu Dec  5 16:41:41 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Thu, 5 Dec 2019 16:41:41 GMT
Subject: [Rev 01] RFR: 6617: Make return value its own element
In-Reply-To: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
Message-ID: <PgEfWh6Z8M-b3O6G8CirFsKb_fvIgwbd2GZo0ebXTnw=.ad002f7c-a2a1-4f1d-9538-980591009d33@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 92964d31: Remove unnecessary returnValue param in createField(..)

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/6/files
  - new: https://git.openjdk.java.net/jmc/pull/6/files/368cc573..92964d31

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/6/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/6/webrev.00-01

  Issue: https://bugs.openjdk.java.net/browse/JMC-6617
  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jmc/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6

PR: https://git.openjdk.java.net/jmc/pull/6

From github.com+29706926+jessyec-s at openjdk.java.net  Thu Dec  5 16:49:11 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Thu, 5 Dec 2019 16:49:11 GMT
Subject: RFR: 6617: Make return value its own element
In-Reply-To: <fJ4CLy9qXjGiMWK6Oqr6-ToeFLCU_BhmpteMYTX481A=.ee1fb468-1a76-4795-8e8d-1888c79eb99a@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
 <fJ4CLy9qXjGiMWK6Oqr6-ToeFLCU_BhmpteMYTX481A=.ee1fb468-1a76-4795-8e8d-1888c79eb99a@github.com>
Message-ID: <0XhTOVpPIDTbaWj5pE6pNk6BLeEM6bEcpNr50FqT6g0=.6d45a3ff-f251-46e2-9613-2dd4d70b96a5@github.com>

On Thu, 5 Dec 2019 16:01:42 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> On Thu, 5 Dec 2019 15:32:23 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:
> 
>> This patch addresses [JMC-6617](https://bugs.openjdk.java.net/browse/JMC-6617): Better probe format for return values.
>> 
>> Currently method return values in the agent are described using a parameter element with an index of -1. This patch makes a designated returnvalue element that can be used for return values.
>> 
>> ----------------
>> 
>> Commits:
>>  - 368cc573: Make return value its own element
>> 
>> Changes: https://git.openjdk.java.net/jmc/pull/6/files
>>  Webrev: https://webrevs.openjdk.java.net/jmc/6/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JMC-6617
>>   Stats: 272 lines in 11 files changed: 200 ins; 25 del; 47 mod
>>   Patch: https://git.openjdk.java.net/jmc/pull/6.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6
> 
> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFREventClassGenerator.java line 120:
> 
>> 119: 
>> 120: 	private static void createField(ClassWriter cw, JFRTransformDescriptor td, ReturnValue returnValue, Type type) {
>> 121: 		if (!td.isAllowedFieldType(type)) {
> 
> Why explicitly adding returnValue to the parameters? Isn't the return value part of the transform descriptor?

yes you are correct - I have fixed this in https://github.com/openjdk/jmc/pull/6/commits/92964d31876537cac3dcd7f84fd0173957d34a7f

PR: https://git.openjdk.java.net/jmc/pull/6

From hirt at openjdk.java.net  Thu Dec  5 18:02:05 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Dec 2019 18:02:05 GMT
Subject: [Rev 01] RFR: 6617: Make return value its own element
In-Reply-To: <PgEfWh6Z8M-b3O6G8CirFsKb_fvIgwbd2GZo0ebXTnw=.ad002f7c-a2a1-4f1d-9538-980591009d33@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
 <PgEfWh6Z8M-b3O6G8CirFsKb_fvIgwbd2GZo0ebXTnw=.ad002f7c-a2a1-4f1d-9538-980591009d33@github.com>
Message-ID: <l1zPx-XQcq1ymRQaar2GRiX5VRYLEQoY18UCN712kgE=.2dfe3fa6-e261-40fb-b803-829af14075a7@github.com>

On Thu, 5 Dec 2019 16:41:41 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 92964d31: Remove unnecessary returnValue param in createField(..)
> 
> Changes:
>   - all: https://git.openjdk.java.net/jmc/pull/6/files
>   - new: https://git.openjdk.java.net/jmc/pull/6/files/368cc573..92964d31
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jmc/6/webrev.01
>  - incr: https://webrevs.openjdk.java.net/jmc/6/webrev.00-01
> 
>   Issue: https://bugs.openjdk.java.net/browse/JMC-6617
>   Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/6.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/impl/DefaultTransformRegistry.java line 155:

> 154: 		Method method = null;
> 155: 		ReturnValue[] returnValue = new ReturnValue[1];
> 156: 		while (streamReader.hasNext()) {

Having an array of 1 seems unnecessary here. Wouldn't just having a reference to the ReturnValue be cleaner?

PR: https://git.openjdk.java.net/jmc/pull/6

From github.com+29706926+jessyec-s at openjdk.java.net  Thu Dec  5 19:20:51 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Thu, 5 Dec 2019 19:20:51 GMT
Subject: [Rev 01] RFR: 6617: Make return value its own element
In-Reply-To: <l1zPx-XQcq1ymRQaar2GRiX5VRYLEQoY18UCN712kgE=.2dfe3fa6-e261-40fb-b803-829af14075a7@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
 <PgEfWh6Z8M-b3O6G8CirFsKb_fvIgwbd2GZo0ebXTnw=.ad002f7c-a2a1-4f1d-9538-980591009d33@github.com>
 <l1zPx-XQcq1ymRQaar2GRiX5VRYLEQoY18UCN712kgE=.2dfe3fa6-e261-40fb-b803-829af14075a7@github.com>
Message-ID: <Nr9SJAi_gACoQBJjIX1lSNFC1GdVhtaLmiBUMJ_kiHE=.f35158c0-7b65-4b4a-bb4e-d3294c88f93b@github.com>

On Thu, 5 Dec 2019 18:02:05 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> On Thu, 5 Dec 2019 16:41:41 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:
> 
>> The pull request has been updated with additional changes.
>> 
>> ----------------
>> 
>> Added commits:
>>  - 92964d31: Remove unnecessary returnValue param in createField(..)
>> 
>> Changes:
>>   - all: https://git.openjdk.java.net/jmc/pull/6/files
>>   - new: https://git.openjdk.java.net/jmc/pull/6/files/368cc573..92964d31
>> 
>> Webrevs:
>>  - full: https://webrevs.openjdk.java.net/jmc/6/webrev.01
>>  - incr: https://webrevs.openjdk.java.net/jmc/6/webrev.00-01
>> 
>>   Issue: https://bugs.openjdk.java.net/browse/JMC-6617
>>   Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
>>   Patch: https://git.openjdk.java.net/jmc/pull/6.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6
> 
> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/impl/DefaultTransformRegistry.java line 155:
> 
>> 154: 		Method method = null;
>> 155: 		ReturnValue[] returnValue = new ReturnValue[1];
>> 156: 		while (streamReader.hasNext()) {
> 
> Having an array of 1 seems unnecessary here. Wouldn't just having a reference to the ReturnValue be cleaner?

I made an array as a wrapper so I do not lose the reference of the ReturnValue object created inside the callee function.  The reference to the newly created object gets lost if I pass in a ReturnValue reference that initially is set to null.

I could create an empty ReturnValue object and then pass it into the parseMethod function, where the object's fields can be set, instead of allocating an array of size 1 ?

PR: https://git.openjdk.java.net/jmc/pull/6

From hirt at openjdk.java.net  Thu Dec  5 19:49:12 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Dec 2019 19:49:12 GMT
Subject: [Approved] RFR: 6617: Make return value its own element
In-Reply-To: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
 <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
Message-ID: <LDzPQvttP0Je7OVPdog_gAYr9xqUI4jJWzCIBQA8nkY=.8e630bac-34f6-450e-bb12-951d3114533b@github.com>

On Thu, 5 Dec 2019 16:41:41 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 92964d31: Remove unnecessary returnValue param in createField(..)
> 
> Changes:
>   - all: https://git.openjdk.java.net/jmc/pull/6/files
>   - new: https://git.openjdk.java.net/jmc/pull/6/files/368cc573..92964d31
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jmc/6/webrev.01
>  - incr: https://webrevs.openjdk.java.net/jmc/6/webrev.00-01
> 
>   Issue: https://bugs.openjdk.java.net/browse/JMC-6617
>   Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/6.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6

Approved by hirt (Lead).

PR: https://git.openjdk.java.net/jmc/pull/6

From hirt at openjdk.java.net  Thu Dec  5 19:53:10 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Dec 2019 19:53:10 GMT
Subject: RFR: 6617: Make return value its own element
In-Reply-To: <0XhTOVpPIDTbaWj5pE6pNk6BLeEM6bEcpNr50FqT6g0=.6d45a3ff-f251-46e2-9613-2dd4d70b96a5@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
 <fJ4CLy9qXjGiMWK6Oqr6-ToeFLCU_BhmpteMYTX481A=.ee1fb468-1a76-4795-8e8d-1888c79eb99a@github.com>
 <0XhTOVpPIDTbaWj5pE6pNk6BLeEM6bEcpNr50FqT6g0=.6d45a3ff-f251-46e2-9613-2dd4d70b96a5@github.com>
Message-ID: <wbDJm7C42Ef6VIhgHq3W4DoTZQCXqLzYAhrhNBuUgBo=.ed065a36-bb89-4059-8037-f5df303f6a09@github.com>

On Thu, 5 Dec 2019 16:49:11 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> On Thu, 5 Dec 2019 16:01:42 GMT, Marcus Hirt <hirt at openjdk.org> wrote:
> 
>> On Thu, 5 Dec 2019 15:32:23 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:
>> 
>>> This patch addresses [JMC-6617](https://bugs.openjdk.java.net/browse/JMC-6617): Better probe format for return values.
>>> 
>>> Currently method return values in the agent are described using a parameter element with an index of -1. This patch makes a designated returnvalue element that can be used for return values.
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - 368cc573: Make return value its own element
>>> 
>>> Changes: https://git.openjdk.java.net/jmc/pull/6/files
>>>  Webrev: https://webrevs.openjdk.java.net/jmc/6/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JMC-6617
>>>   Stats: 272 lines in 11 files changed: 200 ins; 25 del; 47 mod
>>>   Patch: https://git.openjdk.java.net/jmc/pull/6.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/6/head:pull/6
>> 
>> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFREventClassGenerator.java line 120:
>> 
>>> 119: 
>>> 120: 	private static void createField(ClassWriter cw, JFRTransformDescriptor td, ReturnValue returnValue, Type type) {
>>> 121: 		if (!td.isAllowedFieldType(type)) {
>> 
>> Why explicitly adding returnValue to the parameters? Isn't the return value part of the transform descriptor?
> 
> yes you are correct - I have fixed this in https://github.com/openjdk/jmc/pull/6/commits/92964d31876537cac3dcd7f84fd0173957d34a7f

Ah. @jessyec-s, you'll have to do integrate first.

PR: https://git.openjdk.java.net/jmc/pull/6

From hirt at openjdk.java.net  Thu Dec  5 23:58:40 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 5 Dec 2019 23:58:40 GMT
Subject: [Integrated] RFR: 6617: Make return value its own element
In-Reply-To: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
References: <1gBhnKwHMGgyavwYl6KH78gtlkiKAOsp-dY_4TJfwhI=.d4da7939-5be2-405e-bdf2-107df73c7d90@github.com>
Message-ID: <984a7799-dd9a-4103-956a-424fa348f986@openjdk.org>

Changeset: 7bb3839e
Author:    Jessye Coleman-Shapiro <jescolem at redhat.com>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-05 23:57:34 +0000
URL:       https://git.openjdk.java.net/jmc/commit/7bb3839e

6617: Make return value its own element

Reviewed-by: hirt

! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Parameter.java
+ core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/ReturnValue.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/TransformDescriptor.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/impl/DefaultTransformRegistry.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/JFRTransformDescriptor.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFREventClassGenerator.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfr/impl/JFRMethodAdvisor.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfrnext/impl/JFRNextEventClassGenerator.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jfrnext/impl/JFRNextMethodAdvisor.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/TypeUtils.java
! core/org.openjdk.jmc.agent/src/test/resources/org/openjdk/jmc/agent/test/jfrprobes_template.xml

From marcus at hirt.se  Fri Dec  6 21:07:10 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Fri, 06 Dec 2019 21:07:10 +0000
Subject: hg: jmc/jmc7: Added tag 7.1.0-ga for changeset 0dc338015575
Message-ID: <201912062107.xB6L7AZV011922@aojmv0008.oracle.com>

Changeset: c27c4cc3e458
Author:    hirt <marcus.hirt at datadoghq.com>
Date:      2019-12-06 22:06 +0100
URL:       https://hg.openjdk.java.net/jmc/jmc7/rev/c27c4cc3e458

Added tag 7.1.0-ga for changeset 0dc338015575

! .hgtags


From employeen13 at gmail.com  Sat Dec  7 15:03:56 2019
From: employeen13 at gmail.com (employeen13 at gmail)
Date: Sat, 7 Dec 2019 18:03:56 +0300
Subject: [PATCH] JMC-5721: Reintroduce the Percentage column
Message-ID: <CANd5FXzPfkQcSbnq56jn6CJO3V+_2T26aNDWrem5Gn-otZ9+-w@mail.gmail.com>

Hi all,

I've prepared a patch addresses JMC-5721
<https://bugs.openjdk.java.net/browse/JMC-5721>: Reintroduce the Percentage
column.

   1. StacktraceView has been amended to display Percentage column as well
   it displays stack trace and count ones. Percentage format is #.## (up-to 2
   decimal points), it will also arbitrarily round the number.
   2. Tool tip with frame fraction and sibling groups info has been moved
   from Count column to Percentage.
   3. Currently Background drawer decorates Percentage column instead of
   Count.

The PR <https://github.com/openjdk/jmc/pull/12> has been created as well.
Could you review it, please.


Regards,
Dmitry Popov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JMC-5721.patch
Type: text/x-patch
Size: 9588 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20191207/0151f212/JMC-5721.patch>

From hirt at openjdk.java.net  Tue Dec 10 15:43:28 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 10 Dec 2019 15:43:28 GMT
Subject: RFR: 6651: Exposing the magic bytes for the compressed formats
 supported
Message-ID: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>

Sometimes you have a stream from elsewhere, and need to do some custom magic.

-------------

Commits:
 - 974055b9: 6651: Exposing the magic bytes for compressed formats supported

Changes: https://git.openjdk.java.net/jmc/pull/13/files
 Webrev: https://webrevs.openjdk.java.net/jmc/13/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6651
  Stats: 21 lines in 1 file changed: 7 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jmc/pull/13.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/13/head:pull/13

PR: https://git.openjdk.java.net/jmc/pull/13

From jkang at openjdk.java.net  Tue Dec 10 16:18:22 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Tue, 10 Dec 2019 16:18:22 GMT
Subject: RFR: 6651: Exposing the magic bytes for the compressed formats
 supported
In-Reply-To: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
References: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
Message-ID: <i9DnmfIxLU1Q3eZGe_nwxDrrfIgnF3xCFlgAzbP7-NA=.09c89840-c400-4f39-ba14-fea335c33c93@github.com>

On Tue, 10 Dec 2019 15:41:52 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Sometimes you have a stream from elsewhere, and need to do some custom magic.

The changes look okay to me!

-------------

Marked as reviewed by jkang (Author).

PR: https://git.openjdk.java.net/jmc/pull/13

From hirt at openjdk.java.net  Tue Dec 10 20:24:26 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 10 Dec 2019 20:24:26 GMT
Subject: [Rev 01] RFR: 6651: Exposing the magic bytes for the compressed
 formats supported
In-Reply-To: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
References: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
Message-ID: <seFW2csptg3foHyV5rWUVC3Iuy_3CNTf3Tzf7apmO5o=.ee173618-37e4-49a0-8c6f-843ea7ec55f6@github.com>

> Sometimes you have a stream from elsewhere, and need to do some custom magic.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 3b594fa4: Making spotless happy

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/13/files
  - new: https://git.openjdk.java.net/jmc/pull/13/files/974055b9..3b594fa4

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/13/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/13/webrev.00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/13.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/13/head:pull/13

PR: https://git.openjdk.java.net/jmc/pull/13

From hirt at openjdk.java.net  Wed Dec 11 11:17:43 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 11:17:43 GMT
Subject: RFR: 6652: Relaxing issue number verfication
Message-ID: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>

6652: Relaxing issue number verfication

-------------

Commits:
 - 4033bf23: Relaxing issue number verfication

Changes: https://git.openjdk.java.net/jmc/pull/16/files
 Webrev: https://webrevs.openjdk.java.net/jmc/16/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6652
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/16/head:pull/16

PR: https://git.openjdk.java.net/jmc/pull/16

From rwestberg at openjdk.java.net  Wed Dec 11 13:53:33 2019
From: rwestberg at openjdk.java.net (Robin Westberg)
Date: Wed, 11 Dec 2019 13:53:33 GMT
Subject: RFR: 6652: Relaxing issue number verfication
In-Reply-To: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>
References: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>
Message-ID: <2uSbuY13HhQmFMvVhOsKgONOO9adgE4rWgCL8Dt91ec=.01daaf6b-a31e-4017-9a09-31daac75aa25@github.com>

On Wed, 11 Dec 2019 11:03:04 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> 6652: Relaxing issue number verfication

Looks good to me! Although you misspelled "verification" in the title ??

-------------

Marked as reviewed by rwestberg (no project role).

PR: https://git.openjdk.java.net/jmc/pull/16

From hdafgard at openjdk.java.net  Wed Dec 11 14:09:59 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 11 Dec 2019 14:09:59 GMT
Subject: [Rev 01] RFR: 6651: Exposing the magic bytes for the compressed
 formats supported
In-Reply-To: <seFW2csptg3foHyV5rWUVC3Iuy_3CNTf3Tzf7apmO5o=.ee173618-37e4-49a0-8c6f-843ea7ec55f6@github.com>
References: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
 <seFW2csptg3foHyV5rWUVC3Iuy_3CNTf3Tzf7apmO5o=.ee173618-37e4-49a0-8c6f-843ea7ec55f6@github.com>
Message-ID: <yA4fyYtrZxV4rSG4B-HHhMxXpTJ7MSBLipN3Zqe-1ZM=.6923b497-9ea2-48b3-92cd-d4969a737cf4@github.com>

On Wed, 11 Dec 2019 14:09:58 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Sometimes you have a stream from elsewhere, and need to do some custom magic.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/13

From hdafgard at openjdk.java.net  Wed Dec 11 14:27:15 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 11 Dec 2019 14:27:15 GMT
Subject: RFR: 6652: Relaxing issue number verfication
In-Reply-To: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>
References: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>
Message-ID: <iaEOtu67tvQLAbztGKqlYewwcyx6AteDHf6t4Dk8t3I=.7dbc59bb-b9cd-42ed-984e-e970f580bc78@github.com>

On Wed, 11 Dec 2019 11:03:04 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> 6652: Relaxing issue number verfication

LGTM!

-------------

Marked as reviewed by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/16

From hirt at openjdk.java.net  Wed Dec 11 15:18:25 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 15:18:25 GMT
Subject: RFR: 6652: Relaxing issue number verification
In-Reply-To: <iaEOtu67tvQLAbztGKqlYewwcyx6AteDHf6t4Dk8t3I=.7dbc59bb-b9cd-42ed-984e-e970f580bc78@github.com>
References: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>
 <iaEOtu67tvQLAbztGKqlYewwcyx6AteDHf6t4Dk8t3I=.7dbc59bb-b9cd-42ed-984e-e970f580bc78@github.com>
Message-ID: <bJl17bhXfvmHxfoD47_vFvJ8UlfEH-Mv7TPp3z5N5K8=.586f49f3-d9de-4161-b58b-0c9046923a97@github.com>

On Wed, 11 Dec 2019 14:27:01 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> 6652: Relaxing issue number verification
> 
> LGTM!

> Looks good to me! Although you misspelled "verification" in the title ??

Haha. Thanks!

-------------

PR: https://git.openjdk.java.net/jmc/pull/16

From hirt at openjdk.java.net  Wed Dec 11 15:20:15 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 15:20:15 GMT
Subject: [Integrated] RFR: 6652: Relaxing issue number verfication
In-Reply-To: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>
References: <hV_HonmJAEBWUF4ydDtkW8DkT0j6Gea7TS-_fCgtP2I=.62330327-7312-42b6-8dc2-32afd5e3653b@github.com>
Message-ID: <9746e7c0-9c06-4b42-95a0-868e77e9e15d@openjdk.org>

Changeset: d84a3e14
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-11 15:19:44 +0000
URL:       https://git.openjdk.java.net/jmc/commit/d84a3e14

6652: Relaxing issue number verification

Reviewed-by: rwestberg, hdafgard

! .jcheck/conf

From hirt at openjdk.java.net  Wed Dec 11 15:23:16 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 15:23:16 GMT
Subject: [Integrated] RFR: 6651: Exposing the magic bytes for the
 compressed formats supported
In-Reply-To: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
References: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
Message-ID: <1d917091-3670-46ac-96ab-e148e08f6b2c@openjdk.org>

Changeset: 16481354
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-11 15:22:41 +0000
URL:       https://git.openjdk.java.net/jmc/commit/16481354

6651: Exposing the magic bytes for the compressed formats supported

Reviewed-by: jkang, hdafgard

! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/io/IOToolkit.java

From hdafgard at openjdk.java.net  Wed Dec 11 15:23:59 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 11 Dec 2019 15:23:59 GMT
Subject: RFR: 5660: Lazy initialize timestamp unit description
Message-ID: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>

Creating a string description for each timestamp unit instance is far too expensive since we have to create a new unit for e.g. each duration comparison. So rules that perform such comparisons cause a lot of unnecessary allocations, on my local machine I estimate that this will reduce total allocations by around 50% for rules evaluations.

This doesn't really fix JMC-5660, but will reduce the performance cost until we get a more proper fix for this bug.

-------------

Commits:
 - 0f8c15f7: Fix formatting
 - e888d1a1: Lazy initialization of TimestampUnit description to reduce allocation pressure from rules evaluation

Changes: https://git.openjdk.java.net/jmc/pull/15/files
 Webrev: https://webrevs.openjdk.java.net/jmc/15/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-5660
  Stats: 8 lines in 1 file changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jmc/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/15/head:pull/15

PR: https://git.openjdk.java.net/jmc/pull/15

From hirt at openjdk.java.net  Wed Dec 11 15:36:11 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 15:36:11 GMT
Subject: RFR: 5660: Lazy initialize timestamp unit description
In-Reply-To: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
References: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
Message-ID: <zaepu9RYBWVeyUqK25J3tquCPLo8f2bz7y4m6qtHH_Y=.3438e77a-e24d-43d0-b37e-3e360484d1ea@github.com>

On Wed, 11 Dec 2019 01:24:54 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

> Creating a string description for each timestamp unit instance is far too expensive since we have to create a new unit for e.g. each duration comparison. So rules that perform such comparisons cause a lot of unnecessary allocations, on my local machine I estimate that this will reduce total allocations by around 50% for rules evaluations.
> 
> This doesn't really fix JMC-5660, but will reduce the performance cost until we get a more proper fix for this bug.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampUnit.java line 226:

> 225: 	public String getLocalizedDescription() {
> 226: 		if (unitDescription == null) {
> 227: 			String multiplier = timeOffsetUnit.asWellKnownQuantity().displayUsing(IDisplayable.EXACT);

This makes this class thread unsafe, in the sense that there can be many local copies made of the unitDescription if used concurrently from multiple threads without any safety measures. Would an atomic reference be too expensive?

-------------

PR: https://git.openjdk.java.net/jmc/pull/15

From erik.gahlin at oracle.com  Wed Dec 11 15:38:06 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 11 Dec 2019 16:38:06 +0100
Subject: [Integrated] RFR: 6651: Exposing the magic bytes for the
 compressed formats supported
In-Reply-To: <1d917091-3670-46ac-96ab-e148e08f6b2c@openjdk.org>
References: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
 <1d917091-3670-46ac-96ab-e148e08f6b2c@openjdk.org>
Message-ID: <08b8f303-869f-bf4f-9481-7f7fc03393c3@oracle.com>

Some static analysis tool will probably classify this as a vulnerability 
since the contents of as public static final array field can be changed 
from the outside by a malicious user.

Erik

On 2019-12-11 16:23, Marcus Hirt wrote:
> Changeset: 16481354
> Author:    Marcus Hirt <hirt at openjdk.org>
> Date:      2019-12-11 15:22:41 +0000
> URL:       https://git.openjdk.java.net/jmc/commit/16481354
>
> 6651: Exposing the magic bytes for the compressed formats supported
>
> Reviewed-by: jkang, hdafgard
>
> ! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/io/IOToolkit.java

From hdafgard at openjdk.java.net  Wed Dec 11 16:26:38 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 11 Dec 2019 16:26:38 GMT
Subject: RFR: 5660: Lazy initialize timestamp unit description
In-Reply-To: <zaepu9RYBWVeyUqK25J3tquCPLo8f2bz7y4m6qtHH_Y=.3438e77a-e24d-43d0-b37e-3e360484d1ea@github.com>
References: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
 <zaepu9RYBWVeyUqK25J3tquCPLo8f2bz7y4m6qtHH_Y=.3438e77a-e24d-43d0-b37e-3e360484d1ea@github.com>
Message-ID: <fgc7quObZ97UrW0z-yZ0gvvCdS2UagUbJxstov8KEk0=.dff101bd-ebc6-4a6f-8ace-b91844403874@github.com>

On Wed, 11 Dec 2019 15:35:41 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Creating a string description for each timestamp unit instance is far too expensive since we have to create a new unit for e.g. each duration comparison. So rules that perform such comparisons cause a lot of unnecessary allocations, on my local machine I estimate that this will reduce total allocations by around 50% for rules evaluations.
>> 
>> This doesn't really fix JMC-5660, but will reduce the performance cost until we get a more proper fix for this bug.
> 
> core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampUnit.java line 226:
> 
>> 225: 	public String getLocalizedDescription() {
>> 226: 		if (unitDescription == null) {
>> 227: 			String multiplier = timeOffsetUnit.asWellKnownQuantity().displayUsing(IDisplayable.EXACT);
> 
> This makes this class thread unsafe, in the sense that there can be many local copies made of the unitDescription if used concurrently from multiple threads without any safety measures. Would an atomic reference be too expensive?

Using an AtomicReference for the description would add an allocation overhead of around 3% for rules evaluations. I'm not sure that that's cheap enough for the cost. Another option is to remove the description as a field entirely, and always re-create it when asked.

-------------

PR: https://git.openjdk.java.net/jmc/pull/15

From hdafgard at openjdk.java.net  Wed Dec 11 17:22:27 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 11 Dec 2019 17:22:27 GMT
Subject: [Rev 01] RFR: 5660: Lazy initialize timestamp unit description
In-Reply-To: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
References: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
Message-ID: <q_h37_4D5y9tmHUnzs8cxLIVlOIsskH7XpBAds5C8KQ=.5f855663-f468-4de9-b46e-63bbdb30cde1@github.com>

> Creating a string description for each timestamp unit instance is far too expensive since we have to create a new unit for e.g. each duration comparison. So rules that perform such comparisons cause a lot of unnecessary allocations, on my local machine I estimate that this will reduce total allocations by around 50% for rules evaluations.
> 
> This doesn't really fix JMC-5660, but will reduce the performance cost until we get a more proper fix for this bug.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 13da2bc0: Use AtomicReference for lazy initialization

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/15/files
  - new: https://git.openjdk.java.net/jmc/pull/15/files/0f8c15f7..13da2bc0

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/15/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/15/webrev.00-01

  Stats: 9 lines in 1 file changed: 1 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jmc/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/15/head:pull/15

PR: https://git.openjdk.java.net/jmc/pull/15

From hdafgard at openjdk.java.net  Wed Dec 11 17:26:32 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 11 Dec 2019 17:26:32 GMT
Subject: [Rev 01] RFR: 5660: Lazy initialize timestamp unit description
In-Reply-To: <zaepu9RYBWVeyUqK25J3tquCPLo8f2bz7y4m6qtHH_Y=.3438e77a-e24d-43d0-b37e-3e360484d1ea@github.com>
References: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
 <zaepu9RYBWVeyUqK25J3tquCPLo8f2bz7y4m6qtHH_Y=.3438e77a-e24d-43d0-b37e-3e360484d1ea@github.com>
Message-ID: <RVYui4X2ytxXRhnGVXPq-RFswarDL37jB_R-M5qAh8U=.9d3c1bdd-6a7f-4317-bb4b-6b99cc9dc444@github.com>

On Wed, 11 Dec 2019 15:35:41 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampUnit.java line 226:
> 
>> 225: 	public String getLocalizedDescription() {
>> 226: 		if (unitDescription == null) {
>> 227: 			String multiplier = timeOffsetUnit.asWellKnownQuantity().displayUsing(IDisplayable.EXACT);
> 
> This makes this class thread unsafe, in the sense that there can be many local copies made of the unitDescription if used concurrently from multiple threads without any safety measures. Would an atomic reference be too expensive?

I did some more benchmarking, and using an AtomicReference is a bit faster than the previous lazy initialization.

-------------

PR: https://git.openjdk.java.net/jmc/pull/15

From hirt at openjdk.java.net  Wed Dec 11 17:48:55 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 17:48:55 GMT
Subject: [Rev 01] RFR: 5660: Lazy initialize timestamp unit description
In-Reply-To: <q_h37_4D5y9tmHUnzs8cxLIVlOIsskH7XpBAds5C8KQ=.5f855663-f468-4de9-b46e-63bbdb30cde1@github.com>
References: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
 <q_h37_4D5y9tmHUnzs8cxLIVlOIsskH7XpBAds5C8KQ=.5f855663-f468-4de9-b46e-63bbdb30cde1@github.com>
Message-ID: <em8xIWbhrCBMIryfFvfsiRceeEZLt-nRrQnMXLdWqUQ=.8d6f0dc9-9cb0-48c5-aa87-540d7933781e@github.com>

On Wed, 11 Dec 2019 17:48:55 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> Creating a string description for each timestamp unit instance is far too expensive since we have to create a new unit for e.g. each duration comparison. So rules that perform such comparisons cause a lot of unnecessary allocations, on my local machine I estimate that this will reduce total allocations by around 50% for rules evaluations.
>> 
>> This doesn't really fix JMC-5660, but will reduce the performance cost until we get a more proper fix for this bug.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by hirt (Lead).

PR: https://git.openjdk.java.net/jmc/pull/15

From hdafgard at openjdk.java.net  Wed Dec 11 17:52:12 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 11 Dec 2019 17:52:12 GMT
Subject: [Integrated] RFR: 5660: Lazy initialize timestamp unit description
In-Reply-To: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
References: <Ld3ILkcq1LmHLoiwbSkZUzk7BAg8gqUaGxdMtSNuyDg=.50fa968b-978d-4e83-a4b5-76a8f673b029@github.com>
Message-ID: <1a2735b5-ebea-4794-b379-48146f67b0a2@openjdk.org>

Changeset: 20373cf9
Author:    Henrik Dafg?rd <hdafgard at openjdk.org>
Date:      2019-12-11 17:51:43 +0000
URL:       https://git.openjdk.java.net/jmc/commit/20373cf9

5660: Lazy initialize timestamp unit description

Reviewed-by: hirt

! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/unit/TimestampUnit.java

From marcus at hirt.se  Wed Dec 11 21:39:08 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 11 Dec 2019 22:39:08 +0100
Subject: Sv: [Integrated] RFR: 6651: Exposing the magic bytes for the
 compressed formats supported
In-Reply-To: <08b8f303-869f-bf4f-9481-7f7fc03393c3@oracle.com>
References: <QHhN_8MUPMKpGYOHcMLBJnWEdmS1O76UCOuBwXRzXcg=.bc8189d6-9104-4069-baca-7a94a06dfc24@github.com>
 <1d917091-3670-46ac-96ab-e148e08f6b2c@openjdk.org>
 <08b8f303-869f-bf4f-9481-7f7fc03393c3@oracle.com>
Message-ID: <015601d5b06b$6b3dd020$41b97060$@hirt.se>

Very good point. This should probably be two separate methods returning defensive copies, documented as such and then the user of the methods can decide whether or not they want to cache.

/M 

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Erik Gahlin
Skickat: den 11 december 2019 16:38
Till: jmc-dev at openjdk.java.net; Marcus Hirt <marcus.hirt at datadoghq.com>
?mne: Re: [Integrated] RFR: 6651: Exposing the magic bytes for the compressed formats supported

Some static analysis tool will probably classify this as a vulnerability since the contents of as public static final array field can be changed from the outside by a malicious user.

Erik

On 2019-12-11 16:23, Marcus Hirt wrote:
> Changeset: 16481354
> Author:    Marcus Hirt <hirt at openjdk.org>
> Date:      2019-12-11 15:22:41 +0000
> URL:       https://git.openjdk.java.net/jmc/commit/16481354
>
> 6651: Exposing the magic bytes for the compressed formats supported
>
> Reviewed-by: jkang, hdafgard
>
> ! 
> core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/io/IO
> Toolkit.java


From hirt at openjdk.java.net  Wed Dec 11 22:13:04 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 22:13:04 GMT
Subject: RFR: 6655: Ignoring test files
Message-ID: <pySz64ZLr0HmJoshoTj96-UCabHZLhJcZY7miqCigJo=.e715038a-49d9-4b84-a83a-4da609ffb905@github.com>

6655: Ignoring test files

-------------

Commits:
 - c00befc0: 6655: Ignoring test files

Changes: https://git.openjdk.java.net/jmc/pull/17/files
 Webrev: https://webrevs.openjdk.java.net/jmc/17/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6655
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/17/head:pull/17

PR: https://git.openjdk.java.net/jmc/pull/17

From hirt at openjdk.java.net  Wed Dec 11 22:40:15 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 11 Dec 2019 22:40:15 GMT
Subject: RFR: 6651: Securing exposed public static array
Message-ID: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>

A version not exposing the magic bytes to corruption by a malicious user

-------------

Commits:
 - ec41d1d4: 6651: Securing exposed public static array

Changes: https://git.openjdk.java.net/jmc/pull/18/files
 Webrev: https://webrevs.openjdk.java.net/jmc/18/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6651
  Stats: 70 lines in 2 files changed: 68 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jmc/pull/18.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/18/head:pull/18

PR: https://git.openjdk.java.net/jmc/pull/18

From egahlin at openjdk.java.net  Thu Dec 12 00:46:06 2019
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 12 Dec 2019 00:46:06 GMT
Subject: RFR: 6651: Securing exposed public static array
In-Reply-To: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>
References: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>
Message-ID: <VjnmXZ3FMWHroZ7VW0C6x0BvyBZ9A0oe-zXrRwwt4iY=.a5466740-f717-449a-81b0-6a24e18584c4@github.com>

On Wed, 11 Dec 2019 22:38:17 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> A version not exposing the magic bytes to corruption by a malicious user

core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/util/IOToolkitTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  * 

2019

-------------

Marked as reviewed by egahlin (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/18

From hirt at openjdk.java.net  Thu Dec 12 01:04:08 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 12 Dec 2019 01:04:08 GMT
Subject: [Rev 01] RFR: 6651: Securing exposed public static array
In-Reply-To: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>
References: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>
Message-ID: <Vn7xXKhBgwO_ayXVlLubc_PMEbDUvs72-7IQIzTZkyg=.a8eeeadf-99f9-483c-8d67-9727d4099289@github.com>

> A version not exposing the magic bytes to corruption by a malicious user

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - d1a0626c: Correcting copyright year

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/18/files
  - new: https://git.openjdk.java.net/jmc/pull/18/files/ec41d1d4..d1a0626c

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/18/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/18/webrev.00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/18.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/18/head:pull/18

PR: https://git.openjdk.java.net/jmc/pull/18

From egahlin at openjdk.java.net  Thu Dec 12 01:12:46 2019
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 12 Dec 2019 01:12:46 GMT
Subject: [Rev 01] RFR: 6651: Securing exposed public static array
In-Reply-To: <Vn7xXKhBgwO_ayXVlLubc_PMEbDUvs72-7IQIzTZkyg=.a8eeeadf-99f9-483c-8d67-9727d4099289@github.com>
References: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>
 <Vn7xXKhBgwO_ayXVlLubc_PMEbDUvs72-7IQIzTZkyg=.a8eeeadf-99f9-483c-8d67-9727d4099289@github.com>
Message-ID: <22Mw9xx1LieW3RAdvEBojbqlouBT9CNlijPXP9qgUIo=.77cfe28d-2318-4052-a699-c19d86657807@github.com>

On Thu, 12 Dec 2019 01:12:46 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> A version not exposing the magic bytes to corruption by a malicious user
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by egahlin (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/18

From hirt at openjdk.java.net  Thu Dec 12 09:44:17 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 12 Dec 2019 09:44:17 GMT
Subject: [Integrated] RFR: 6651: Securing exposed public static array
In-Reply-To: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>
References: <OuTnjvniDcilMv7BqVk5AAogKtsz-S4BH2YoQ538plk=.130e2bab-2768-4704-8b4f-f159b5077f7f@github.com>
Message-ID: <7be30bf9-ba0f-4428-9a59-a60ba6f3b2e5@openjdk.org>

Changeset: 3ae355ea
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-12 09:43:50 +0000
URL:       https://git.openjdk.java.net/jmc/commit/3ae355ea

6651: Securing exposed public static array

Reviewed-by: egahlin

! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/io/IOToolkit.java
+ core/tests/org.openjdk.jmc.common.test/src/test/java/org/openjdk/jmc/common/util/IOToolkitTest.java

From hdafgard at openjdk.java.net  Thu Dec 12 13:06:40 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Thu, 12 Dec 2019 13:06:40 GMT
Subject: RFR: 6655: Ignoring test files
In-Reply-To: <pySz64ZLr0HmJoshoTj96-UCabHZLhJcZY7miqCigJo=.e715038a-49d9-4b84-a83a-4da609ffb905@github.com>
References: <pySz64ZLr0HmJoshoTj96-UCabHZLhJcZY7miqCigJo=.e715038a-49d9-4b84-a83a-4da609ffb905@github.com>
Message-ID: <d15AVPkRzSZPIHXE4lCm7Pxc793U0owjdhRvELQpJfY=.daa7315b-d678-4040-8a6d-490b692cde50@github.com>

On Wed, 11 Dec 2019 22:10:35 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> 6655: Ignoring test files



-------------

Marked as reviewed by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/17

From hirt at openjdk.java.net  Thu Dec 12 13:22:15 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 12 Dec 2019 13:22:15 GMT
Subject: [Integrated] RFR: 6655: Ignoring test files
In-Reply-To: <pySz64ZLr0HmJoshoTj96-UCabHZLhJcZY7miqCigJo=.e715038a-49d9-4b84-a83a-4da609ffb905@github.com>
References: <pySz64ZLr0HmJoshoTj96-UCabHZLhJcZY7miqCigJo=.e715038a-49d9-4b84-a83a-4da609ffb905@github.com>
Message-ID: <97002e47-4705-4a43-999a-1de66e4cab91@openjdk.org>

Changeset: 4a3381c1
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-12 13:21:26 +0000
URL:       https://git.openjdk.java.net/jmc/commit/4a3381c1

6655: Ignoring test files

Reviewed-by: hdafgard

! .gitignore

From marcus.hirt at datadoghq.com  Thu Dec 12 14:02:50 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 12 Dec 2019 15:02:50 +0100
Subject: Automatic resolve of integrated issues.
Message-ID: <CAOpWGx1orZqCzp7OMRuv=0+X4ssowhCxF6Ae_CrZEqrH6RmoyQ@mail.gmail.com>

Hi all,

The Skara team has started implementing automatic resolve of
integrated issues in Jira. It will also automatically add links to
reviews and integrations.

You can see an example of how it looks here:
https://bugs.openjdk.java.net/browse/SKARA-194

Unless someone objects, we'll also start using this functionality in
the JMC-project.

Kind regards,
Marcus

From hirt at openjdk.java.net  Sat Dec 14 00:52:33 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 00:52:33 GMT
Subject: RFR: 6554: Support JFR in OpenJDK 8
Message-ID: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>

This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

-------------

Commits:
 - b8a6680e: Spotless
 - c0d3e450: 6554: Support JFR in OpenJDK 8

Changes: https://git.openjdk.java.net/jmc/pull/19/files
 Webrev: https://webrevs.openjdk.java.net/jmc/19/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6554
  Stats: 176 lines in 10 files changed: 102 ins; 53 del; 21 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Sat Dec 14 00:53:10 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 00:53:10 GMT
Subject: RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <qACrqn-C3Kz_WBAym4XTUpSQePey4MwiY47WqMjoiMc=.db88339a-e576-4c51-9155-344f7ca371dc@github.com>

On Sat, 14 Dec 2019 00:50:44 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

For early access builds of the JDK 8 backport, Shipilev provides builds here:
https://builds.shipilev.net/openjdk-jdk8-jfr/

-------------

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Sat Dec 14 01:00:07 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 01:00:07 GMT
Subject: [Rev 01] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <2FL7UviBo7FAyVVwQoMAgXFp6K8ykYb5rfNUzodTlUI=.38362632-e3b1-4994-812c-7d9e40405543@github.com>

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - afd31e88: Copyright year updates

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/19/files
  - new: https://git.openjdk.java.net/jmc/pull/19/files/b8a6680e..afd31e88

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/19/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.00-01

  Stats: 9 lines in 9 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Sat Dec 14 01:22:27 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 01:22:27 GMT
Subject: [Rev 02] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <6RS3HWC83kGE0PpUrLD8oT8IKYBipEmswbjt4oLl4FA=.b9ca5f72-797a-41f1-b6e7-30f202a49108@github.com>

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - bbb703b4: JDP fix

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/19/files
  - new: https://git.openjdk.java.net/jmc/pull/19/files/afd31e88..bbb703b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/19/webrev.02
 - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Sat Dec 14 01:38:36 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 01:38:36 GMT
Subject: [Rev 03] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <SdYwInK6uhQJVsbjgenE2F3ZqbxkOnPHcqY54xRo9aA=.f2b64caf-b05e-4720-ac0d-32c4d1d5ce46@github.com>

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 69898c6f: Spotbugs exclude

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/19/files
  - new: https://git.openjdk.java.net/jmc/pull/19/files/bbb703b4..69898c6f

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/19/webrev.03
 - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.02-03

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Sat Dec 14 01:53:36 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 01:53:36 GMT
Subject: [Rev 04] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <sl02COSaWXQRD8deut7G6MzbNIYoRZ5YoB7DFG7GxVY=.6b816a9a-0cc6-4361-a00a-fccda836034f@github.com>

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 017555a4: Adding tests

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/19/files
  - new: https://git.openjdk.java.net/jmc/pull/19/files/69898c6f..017555a4

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/19/webrev.04
 - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.03-04

  Stats: 29 lines in 1 file changed: 20 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Sat Dec 14 04:07:25 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 04:07:25 GMT
Subject: [Rev 05] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <hiJjpHUvmN-7KFnxXenzQAbdbErNMGkLnIxIq1mniCQ=.b5e88052-8d99-4cd9-946d-9712776b6e13@github.com>

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 963d159c: Fixing tests and supporting vendor classification without JVMDescriptor

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/19/files
  - new: https://git.openjdk.java.net/jmc/pull/19/files/017555a4..963d159c

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/19/webrev.05
 - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.04-05

  Stats: 49 lines in 3 files changed: 21 ins; 4 del; 24 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From neugens at redhat.com  Sat Dec 14 07:46:46 2019
From: neugens at redhat.com (Mario Torre)
Date: Sat, 14 Dec 2019 08:46:46 +0100
Subject: RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <hiJjpHUvmN-7KFnxXenzQAbdbErNMGkLnIxIq1mniCQ=.b5e88052-8d99-4cd9-946d-9712776b6e13@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
 <hiJjpHUvmN-7KFnxXenzQAbdbErNMGkLnIxIq1mniCQ=.b5e88052-8d99-4cd9-946d-9712776b6e13@github.com>
Message-ID: <CAJwKKmbokZ29+ew+zF9R7u=qmYxbOpkmYVxhphsbeNF-BM=7Kw@mail.gmail.com>

Hi Marcus,

The patch looks good.

I can?t test it right now but I assume you tested with the JFR-incubator so
it should be ok to push.

Cheers,
Mario

On Saturday, December 14, 2019, Marcus Hirt <hirt at openjdk.java.net> wrote:

> > This is for OpenJDK 8 implementations that have backported JFR, e.g.
> Azul's JDK. There is also a backport effort for OpenJDK 8 in general.
>
> The pull request has been updated with 1 additional commit.
>
> -------------
>
> Added commits:
>  - 963d159c: Fixing tests and supporting vendor classification without
> JVMDescriptor
>
> Changes:
>   - all: https://git.openjdk.java.net/jmc/pull/19/files
>   - new: https://git.openjdk.java.net/jmc/pull/19/files/017555a4..963d159c
>
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jmc/19/webrev.05
>  - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.04-05
>
>   Stats: 49 lines in 3 files changed: 21 ins; 4 del; 24 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/19.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19
>
> PR: https://git.openjdk.java.net/jmc/pull/19
>
>

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

From marcus at hirt.se  Sat Dec 14 17:45:41 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Sat, 14 Dec 2019 18:45:41 +0100
Subject: Sv: RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <CAJwKKmbokZ29+ew+zF9R7u=qmYxbOpkmYVxhphsbeNF-BM=7Kw@mail.gmail.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
 <hiJjpHUvmN-7KFnxXenzQAbdbErNMGkLnIxIq1mniCQ=.b5e88052-8d99-4cd9-946d-9712776b6e13@github.com>
 <CAJwKKmbokZ29+ew+zF9R7u=qmYxbOpkmYVxhphsbeNF-BM=7Kw@mail.gmail.com>
Message-ID: <0d6401d5b2a6$4df7ac10$e9e70430$@hirt.se>

Hi Mario,

Yep, it's tested against various Oracle JDKs and Shipilev's build of the incubator (on Windows).

Kind regards,
Marcus 

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
Skickat: den 14 december 2019 08:47
Till: Marcus Hirt <hirt at openjdk.java.net>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: RFR: 6554: Support JFR in OpenJDK 8

Hi Marcus,

The patch looks good.

I can?t test it right now but I assume you tested with the JFR-incubator so it should be ok to push.

Cheers,
Mario

On Saturday, December 14, 2019, Marcus Hirt <hirt at openjdk.java.net> wrote:

> > This is for OpenJDK 8 implementations that have backported JFR, e.g.
> Azul's JDK. There is also a backport effort for OpenJDK 8 in general.
>
> The pull request has been updated with 1 additional commit.
>
> -------------
>
> Added commits:
>  - 963d159c: Fixing tests and supporting vendor classification without 
> JVMDescriptor
>
> Changes:
>   - all: https://git.openjdk.java.net/jmc/pull/19/files
>   - new: 
> https://git.openjdk.java.net/jmc/pull/19/files/017555a4..963d159c
>
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jmc/19/webrev.05
>  - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.04-05
>
>   Stats: 49 lines in 3 files changed: 21 ins; 4 del; 24 mod
>   Patch: https://git.openjdk.java.net/jmc/pull/19.diff
>   Fetch: git fetch https://git.openjdk.java.net/jmc 
> pull/19/head:pull/19
>
> PR: https://git.openjdk.java.net/jmc/pull/19
>
>

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


From hirt at openjdk.java.net  Sat Dec 14 17:50:10 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 14 Dec 2019 17:50:10 GMT
Subject: [Rev 06] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <XaBtOaiyMiihnMoJBebl5kUpZE2woQqBHNRXSgQ6_1M=.29d8752f-16af-460e-b16d-36c230ffde66@github.com>

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 4fa515d3: Correcting javadocs

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/19/files
  - new: https://git.openjdk.java.net/jmc/pull/19/files/963d159c..4fa515d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/19/webrev.06
 - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.05-06

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From hdafgard at openjdk.java.net  Mon Dec 16 12:45:44 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 16 Dec 2019 12:45:44 GMT
Subject: [Rev 06] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <XaBtOaiyMiihnMoJBebl5kUpZE2woQqBHNRXSgQ6_1M=.29d8752f-16af-460e-b16d-36c230ffde66@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
 <XaBtOaiyMiihnMoJBebl5kUpZE2woQqBHNRXSgQ6_1M=.29d8752f-16af-460e-b16d-36c230ffde66@github.com>
Message-ID: <lFUyCyijuX3l_UKO1VrX-gvIt6Csoh4ou7Mg5NhzGTI=.7b02d75f-a04d-467a-a099-b66fdf6681ff@github.com>

On Mon, 16 Dec 2019 12:45:43 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.
> 
> The pull request has been updated with 1 additional commit.

application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java line 50:

> 49: public class JVMSupportToolkitTest {
> 50: 	private static final String ORACLE = "Oracle";
> 51: 	// FIXME: Add tests for the methods that take IConnectionHandle as a parameter.

Non-blocking, but we might want to name this a little more descriptively, like VENDOR_ORACLE?

application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java line 136:

> 135: 		ServerHandle server = new ServerHandle(
> 136: 				new ServerDescriptor(null, null, new JVMDescriptor("1.8.0", JVMType.HOTSPOT, JVMArch.UNKNOWN, "OpenJDK",
> 137: 						null, null, null, false, null)),

If we have made Oracle a constant, we should make "OpenJDK" one too.

-------------

Marked as reviewed by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/19

From neugens at redhat.com  Mon Dec 16 13:19:08 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 16 Dec 2019 14:19:08 +0100
Subject: [Rev 06] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <lFUyCyijuX3l_UKO1VrX-gvIt6Csoh4ou7Mg5NhzGTI=.7b02d75f-a04d-467a-a099-b66fdf6681ff@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
 <XaBtOaiyMiihnMoJBebl5kUpZE2woQqBHNRXSgQ6_1M=.29d8752f-16af-460e-b16d-36c230ffde66@github.com>
 <lFUyCyijuX3l_UKO1VrX-gvIt6Csoh4ou7Mg5NhzGTI=.7b02d75f-a04d-467a-a099-b66fdf6681ff@github.com>
Message-ID: <CAJwKKmZhrJTt=k+rZQwGDYtw+M25Tzdp-wV+iY7xZZC01Tw7Ng@mail.gmail.com>

Those are good points.

I think Marcus hasn't pushed this yet so maybe we can have those fixed
in the pull request.

Cheers,
Mario

On Mon, Dec 16, 2019 at 1:46 PM Henrik Dafg?rd
<hdafgard at openjdk.java.net> wrote:
>
> On Mon, 16 Dec 2019 12:45:43 GMT, Marcus Hirt <hirt at openjdk.org> wrote:
>
> >> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.
> >
> > The pull request has been updated with 1 additional commit.
>
> application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java line 50:
>
> > 49: public class JVMSupportToolkitTest {
> > 50:   private static final String ORACLE = "Oracle";
> > 51:   // FIXME: Add tests for the methods that take IConnectionHandle as a parameter.
>
> Non-blocking, but we might want to name this a little more descriptively, like VENDOR_ORACLE?
>
> application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java line 136:
>
> > 135:          ServerHandle server = new ServerHandle(
> > 136:                          new ServerDescriptor(null, null, new JVMDescriptor("1.8.0", JVMType.HOTSPOT, JVMArch.UNKNOWN, "OpenJDK",
> > 137:                                          null, null, null, false, null)),
>
> If we have made Oracle a constant, we should make "OpenJDK" one too.
>
> -------------
>
> Marked as reviewed by hdafgard (Reviewer).
>
> PR: https://git.openjdk.java.net/jmc/pull/19
>


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


From hirt at openjdk.java.net  Mon Dec 16 13:22:24 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 16 Dec 2019 13:22:24 GMT
Subject: [Rev 07] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <CZo_Ax1WX7ModuTHjDwrU6fgnDT4GdrBUeIE8M-Ajhk=.a11cf1a8-6d99-4ebc-9d0a-ed501c9fd581@github.com>

> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 2b237429: Acting on feedback

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/19/files
  - new: https://git.openjdk.java.net/jmc/pull/19/files/4fa515d3..2b237429

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/19/webrev.07
 - incr: https://webrevs.openjdk.java.net/jmc/19/webrev.06-07

  Stats: 28 lines in 1 file changed: 9 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jmc/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/19/head:pull/19

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Mon Dec 16 13:22:47 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 16 Dec 2019 13:22:47 GMT
Subject: [Rev 06] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <lFUyCyijuX3l_UKO1VrX-gvIt6Csoh4ou7Mg5NhzGTI=.7b02d75f-a04d-467a-a099-b66fdf6681ff@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
 <XaBtOaiyMiihnMoJBebl5kUpZE2woQqBHNRXSgQ6_1M=.29d8752f-16af-460e-b16d-36c230ffde66@github.com>
 <lFUyCyijuX3l_UKO1VrX-gvIt6Csoh4ou7Mg5NhzGTI=.7b02d75f-a04d-467a-a099-b66fdf6681ff@github.com>
Message-ID: <RE_vyGOTB5Y4SVr-HR43GtQ7eRMUk27idM1wRBU9zkw=.7feef90f-754d-4bd9-9a3c-559b6adfb38a@github.com>

On Mon, 16 Dec 2019 12:45:30 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> 

Certainly! :)

-------------

PR: https://git.openjdk.java.net/jmc/pull/19

From hdafgard at openjdk.java.net  Mon Dec 16 13:46:36 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 16 Dec 2019 13:46:36 GMT
Subject: [Rev 07] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <CZo_Ax1WX7ModuTHjDwrU6fgnDT4GdrBUeIE8M-Ajhk=.a11cf1a8-6d99-4ebc-9d0a-ed501c9fd581@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
 <CZo_Ax1WX7ModuTHjDwrU6fgnDT4GdrBUeIE8M-Ajhk=.a11cf1a8-6d99-4ebc-9d0a-ed501c9fd581@github.com>
Message-ID: <Zyw5gmAutu2eG1xMtWPs1aLDBf9Q9zy46dKJY9xlFqg=.f518f2a1-4a90-4f22-80fa-648ea48f30ef@github.com>

On Mon, 16 Dec 2019 13:46:36 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This is for OpenJDK 8 implementations that have backported JFR, e.g. Azul's JDK. There is also a backport effort for OpenJDK 8 in general.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/19

From hirt at openjdk.java.net  Mon Dec 16 13:54:19 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 16 Dec 2019 13:54:19 GMT
Subject: [Integrated] RFR: 6554: Support JFR in OpenJDK 8
In-Reply-To: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
References: <PVkWr5UCiryRyEeL6GOINyiw7BJ5R3Wgc7VduKXgLqY=.c120afa8-705f-4ee3-8a7b-c496b7a74e8c@github.com>
Message-ID: <b2280470-84a2-4558-8266-c6adaf461a52@openjdk.org>

Changeset: 4b315fe6
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-16 13:53:53 +0000
URL:       https://git.openjdk.java.net/jmc/commit/4b315fe6

6554: Support JFR in OpenJDK 8

Reviewed-by: hdafgard

! application/org.openjdk.jmc.browser.attach/src/main/java/org/openjdk/jmc/browser/attach/LocalJVMToolkit.java
! application/org.openjdk.jmc.browser.jdp/src/main/java/org/openjdk/jmc/browser/jdp/JDPDescriptorProvider.java
! application/org.openjdk.jmc.rjmx.services.jfr/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/FlightRecorderServiceV2.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/ConnectionToolkit.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/JVMSupportToolkit.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/ICommercialFeaturesService.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/CommercialFeaturesServiceFactory.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/HotSpot23CommercialFeaturesService.java
- application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/Jdk11CommercialFeaturesService.java
+ application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/services/internal/NoCommercialFeaturesService.java
! application/org.openjdk.jmc.ui.common/src/main/java/org/openjdk/jmc/ui/common/jvm/JVMDescriptor.java
! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java
! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/services/CommercialFeaturesServiceTest.java
! configuration/spotbugs/spotbugs-exclude.xml

From marcus.hirt at datadoghq.com  Mon Dec 16 14:14:16 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 16 Dec 2019 15:14:16 +0100
Subject: JMC 2020 Kick-off
Message-ID: <CAOpWGx248AaHj0gzkCrreVXeoyVuudePW8J_S-HW8RVv8RWNBQ@mail.gmail.com>

Hi all,

I'm thinking we should kick off next year (2020) by having a virtual
meet up over Zoom. It will be the 7th or 8th of January, and I'll do a
poll in the #general channel in the JMC slack [0] to find a time that
works for as many as possible.

Kind regards,
Marcus

[0]: https://join.slack.com/t/jdkmissioncontrol/signup

From neugens at redhat.com  Mon Dec 16 14:20:55 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 16 Dec 2019 15:20:55 +0100
Subject: JMC 2020 Kick-off
In-Reply-To: <CAOpWGx248AaHj0gzkCrreVXeoyVuudePW8J_S-HW8RVv8RWNBQ@mail.gmail.com>
References: <CAOpWGx248AaHj0gzkCrreVXeoyVuudePW8J_S-HW8RVv8RWNBQ@mail.gmail.com>
Message-ID: <CAJwKKmZNtYAhozAMeZ18qJsx1jP1-DbPtFT=Pt5bdBrE8=0hsQ@mail.gmail.com>

+1

Cheers,
Mario

On Mon, Dec 16, 2019 at 3:15 PM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>
> Hi all,
>
> I'm thinking we should kick off next year (2020) by having a virtual
> meet up over Zoom. It will be the 7th or 8th of January, and I'll do a
> poll in the #general channel in the JMC slack [0] to find a time that
> works for as many as possible.
>
> Kind regards,
> Marcus
>
> [0]: https://join.slack.com/t/jdkmissioncontrol/signup
>


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


From github.com+7112604+dmnm at openjdk.java.net  Mon Dec 16 16:07:38 2019
From: github.com+7112604+dmnm at openjdk.java.net (Dmitry Popov)
Date: Mon, 16 Dec 2019 16:07:38 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
Message-ID: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>

This patch addresses [JMC-5721](https://bugs.openjdk.java.net/browse/JMC-5721): Reintroduce the Percentage column.

1. StacktraceView has been amended to display Percentage column as well it displays stack trace and count ones. Percentage format is #.## (up-to 2 decimal points), it will also arbitrarily round the number.
2. Tool tip with frame fraction and sibling groups info has been moved from Count column to Percentage.
3. Currently Background drawer decorates Percentage column instead of Count.

-------------

Commits:
 - b3ad0225: JMC-5721 :: StacktraceView :: Reintroduce the Percentage column

Changes: https://git.openjdk.java.net/jmc/pull/12/files
 Webrev: https://webrevs.openjdk.java.net/jmc/12/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-5721
  Stats: 23 lines in 5 files changed: 16 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jmc/pull/12.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/12/head:pull/12

PR: https://git.openjdk.java.net/jmc/pull/12

From hirt at openjdk.java.net  Mon Dec 16 16:07:39 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 16 Dec 2019 16:07:39 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
Message-ID: <exRFyZmbZB62ChQuYp9N5xPtI7K_dinmpjApfWHuoN4=.b298ed0b-3a9b-4f5f-8357-97510c01e75c@github.com>

On Sat, 7 Dec 2019 14:43:49 GMT, Dmitry Popov <github.com+7112604+dmnm at openjdk.org> wrote:

> This patch addresses [JMC-5721](https://bugs.openjdk.java.net/browse/JMC-5721): Reintroduce the Percentage column.
> 
> 1. StacktraceView has been amended to display Percentage column as well it displays stack trace and count ones. Percentage format is #.## (up-to 2 decimal points), it will also arbitrarily round the number.
> 2. Tool tip with frame fraction and sibling groups info has been moved from Count column to Percentage.
> 3. Currently Background drawer decorates Percentage column instead of Count.

Hi Dmitry! Have you, or the company you are working for, signed the OCA?

-------------

PR: https://git.openjdk.java.net/jmc/pull/12

From github.com+7112604+dmnm at openjdk.java.net  Mon Dec 16 16:07:39 2019
From: github.com+7112604+dmnm at openjdk.java.net (Dmitry Popov)
Date: Mon, 16 Dec 2019 16:07:39 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <exRFyZmbZB62ChQuYp9N5xPtI7K_dinmpjApfWHuoN4=.b298ed0b-3a9b-4f5f-8357-97510c01e75c@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
 <exRFyZmbZB62ChQuYp9N5xPtI7K_dinmpjApfWHuoN4=.b298ed0b-3a9b-4f5f-8357-97510c01e75c@github.com>
Message-ID: <K7NctDzrnT7ntUibMpEG3YS8jUvIJf2pKRyfWKWEKDU=.fb9fd6fa-f374-406b-8b59-97bc659a6b37@github.com>

On Tue, 10 Dec 2019 10:36:28 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This patch addresses [JMC-5721](https://bugs.openjdk.java.net/browse/JMC-5721): Reintroduce the Percentage column.
>> 
>> 1. StacktraceView has been amended to display Percentage column as well it displays stack trace and count ones. Percentage format is #.## (up-to 2 decimal points), it will also arbitrarily round the number.
>> 2. Tool tip with frame fraction and sibling groups info has been moved from Count column to Percentage.
>> 3. Currently Background drawer decorates Percentage column instead of Count.
> 
> Hi Dmitry! Have you, or the company you are working for, signed the OCA?

> Hi Dmitry! Have you, or the company you are working for, signed the OCA?

Hi,
No, but I can do that if necessary. BTW, are there any comments about the PR, approach, code style, commit message, etc?

-------------

PR: https://git.openjdk.java.net/jmc/pull/12

From hirt at openjdk.java.net  Mon Dec 16 16:07:39 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 16 Dec 2019 16:07:39 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <K7NctDzrnT7ntUibMpEG3YS8jUvIJf2pKRyfWKWEKDU=.fb9fd6fa-f374-406b-8b59-97bc659a6b37@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
 <exRFyZmbZB62ChQuYp9N5xPtI7K_dinmpjApfWHuoN4=.b298ed0b-3a9b-4f5f-8357-97510c01e75c@github.com>
 <K7NctDzrnT7ntUibMpEG3YS8jUvIJf2pKRyfWKWEKDU=.fb9fd6fa-f374-406b-8b59-97bc659a6b37@github.com>
Message-ID: <Mua4Uuzz2wFQdvblxZrxJy0eTb74Q37I4Oe1mHo6HaY=.3f21caeb-3bb3-4d1f-8947-f37d7d7a4db7@github.com>

On Tue, 10 Dec 2019 11:14:57 GMT, Dmitry Popov <github.com+7112604+dmnm at openjdk.org> wrote:

>> Hi Dmitry! Have you, or the company you are working for, signed the OCA?
> 
>> Hi Dmitry! Have you, or the company you are working for, signed the OCA?
> 
> Hi,
> No, but I can do that if necessary. BTW, are there any comments about the PR, approach, code style, commit message, etc?

Hi Dmitry! 

Yep, just like most other open source projects, OpenJDK requires you (or the company you work for) to sign a contributor agreement. Please let me know if you need any help - the link to the process is in a previous message from the bot. 

Once the OCA is signed and verified, and barring any other problems, the changes will be sent out for review.

Kind regards,
Marcus

-------------

PR: https://git.openjdk.java.net/jmc/pull/12

From hdafgard at openjdk.java.net  Mon Dec 16 16:48:15 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 16 Dec 2019 16:48:15 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
Message-ID: <roHGISHcHyRlI47D2--pEFZb3KbrXFir6Fr54DGmFbk=.aa933f9f-57d7-4f56-bf50-d9d1e963cb75@github.com>

On Sat, 7 Dec 2019 14:43:49 GMT, Dmitry Popov <github.com+7112604+dmnm at openjdk.org> wrote:

> This patch addresses [JMC-5721](https://bugs.openjdk.java.net/browse/JMC-5721): Reintroduce the Percentage column.
> 
> 1. StacktraceView has been amended to display Percentage column as well it displays stack trace and count ones. Percentage format is #.## (up-to 2 decimal points), it will also arbitrarily round the number.
> 2. Tool tip with frame fraction and sibling groups info has been moved from Count column to Percentage.
> 3. Currently Background drawer decorates Percentage column instead of Count.

application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java line 738:

> 737: 			int totalCount = getRootFork(frame.getBranch().getParentFork()).getItemsInFork();
> 738: 			return String.format("%.2f%%", (itemCount / (float) totalCount) * 100F);
> 739: 		}

You should use the unit toolkit we have for displaying the percentage, i.e. use UnitLookup.PERCENT_UNITY.quantity to get a value, and then format it as a string using .displayUsing and pass in an appropriate formatting hint. For this I'd say that running 

> UnitLookup.PERCENT_UNITY.quantity(itemCount / (float) totalCount).displayUsing(IDisplayable.AUTO)

 will work fine, but feel free to try some alternatives.

-------------

Changes requested by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/12

From jkang at openjdk.java.net  Wed Dec 18 14:26:24 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 18 Dec 2019 14:26:24 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
Message-ID: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>

This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.

The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.

This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have allocations inside and outside TLABs, as a percentage.

TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.

![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)

-------------

Commits:
 - 9f73e4fd: Fix accidental removal of code text
 - d49a06e5: Update name and description for percentage columns
 - e68f4a2e: Fix key name in messages.properties
 - 2f6e4b7b: Add tabs to tlab page for tlabs by threads and by top methods
 - 6d2e5f2a: Add percentage columns to tlab view
 - d6c53b42: Store reference to all items in AggregationModel rather than the AggregationRow
 - bae85de1: Add allocation percentage column to memory view

Changes: https://git.openjdk.java.net/jmc/pull/21/files
 Webrev: https://webrevs.openjdk.java.net/jmc/21/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6657
  Stats: 192 lines in 15 files changed: 145 ins; 3 del; 44 mod
  Patch: https://git.openjdk.java.net/jmc/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/21/head:pull/21

PR: https://git.openjdk.java.net/jmc/pull/21

From ehelin at openjdk.java.net  Wed Dec 18 15:42:40 2019
From: ehelin at openjdk.java.net (Erik Helin)
Date: Wed, 18 Dec 2019 15:42:40 GMT
Subject: RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
Message-ID: <eVKla9F8SWCxvcYUSen9OwMAeptBN1Tk1QpVxx_asn4=.40c8529b-e735-44c6-bee3-d73d028894f9@github.com>

On Tue, 17 Dec 2019 22:26:53 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

> This patch implements [JMC-6656: Allow capturing field values with path syntax](https://bugs.openjdk.java.net/browse/JMC-6656).
> 
> In the xml configuration, a field capture looks like:
> <field>
>   <name>a field value</name>
>   <description>a field value capture with a path syntax</description>
>   <expression>this.field.prop</expression>
> </field>
> See `org/openjdk/jmc/agent/test/jfrprobes_template.xml` for more examples.
> 
> There are currently two limitations to pay attention to:
> 
> 1. Instrumentation point cannot be in synthesized classes:
> Instrumented classes are first loaded by obtaining the bytecode and inspected reflectively to resolve typing information. This fails if the class load is unable to provide the bytecode when `ClassLoader.getResouce()` is called. The cases where it might fail are unlikely to be for classes like proxies or auxiliaries for Java frameworks that have no visible equivalent.
> 
> 2. Instrumentation is unable to access nestmates' private fields:
> Before [nest-base access control](https://openjdk.java.net/jeps/181) was introduced in Java 11, accessing nestmates' private fields is, while lexically correct, forbidden by the JVM. The Java compiler works around by inserting synthetic getters/setters. However, it's not for a BCI agent since changing the class structure is not allowed during class transformation.
> 
> Please let me know your thoughts. Thank you very much!

Please ignore this comment, it is just for the bots to refresh their caches and re-evaluate this PR

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From kxu at openjdk.java.net  Wed Dec 18 15:42:40 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Wed, 18 Dec 2019 15:42:40 GMT
Subject: RFR: 6656: Allow capturing field values with path syntax
Message-ID: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>

This patch implements [JMC-6656: Allow capturing field values with path syntax](https://bugs.openjdk.java.net/browse/JMC-6656).

In the xml configuration, a field capture looks like:
<field>
  <name>a field value</name>
  <description>a field value capture with a path syntax</description>
  <expression>this.field.prop</expression>
</field>
See `org/openjdk/jmc/agent/test/jfrprobes_template.xml` for more examples.

There are currently two limitations to pay attention to:

1. Instrumentation point cannot be in synthesized classes:
Instrumented classes are first loaded by obtaining the bytecode and inspected reflectively to resolve typing information. This fails if the class load is unable to provide the bytecode when `ClassLoader.getResouce()` is called. The cases where it might fail are unlikely to be for classes like proxies or auxiliaries for Java frameworks that have no visible equivalent.

2. Instrumentation is unable to access nestmates' private fields:
Before [nest-base access control](https://openjdk.java.net/jeps/181) was introduced in Java 11, accessing nestmates' private fields is, while lexically correct, forbidden by the JVM. The Java compiler works around by inserting synthetic getters/setters. However, it's not for a BCI agent since changing the class structure is not allowed during class transformation.

Please let me know your thoughts. Thank you very much!

-------------

Commits:
 - caaa7e7e: resolve conflicts after merging from master
 - 3383c080: Merge branch 'master' into agent-path-expression
 - a3e0c61e: error on private member access between nestmates
 - 5c19b765: add test cases for field capture feature
 - e05ea8bf: support legacy JFR api
 - 1019ca0d: change indentations to using tabs. add license headers
 - 1c7b0ac6: rename "watch" to "field"
 - e93a31e2: refactor error handling. cache resolved reference chain
 - 92b92502: add a QualifiedThisReference only when making qualified .this or .super
 - db3d6266: WIP: refactor
 - 040a42d8: add final modifiers
 - a803e7e7: remove unnecessary null checks
 - af33e32f: implemented path-syntax evaluation
 - 4cc7b9ea: WIP: add check for access and static context. improves error messages
 - 036b324e: WIP: state machine for parsing expression
 - 3f2f4023: WIP: syntax parsing with state machine
 - b58a44e4: WIP: implement implicit upwards reference in a nest
 - ad7d64f6: WIP: enforce access checks on reference chains
 - 5e46ed6f: WIP: avoid loading instrumentation pending classes with parent loader
 - 1964111f: WIP: fix loading "this"
 - 74624291: WIP: BCI agent path-syntax evaluation

Changes: https://git.openjdk.java.net/jmc/pull/20/files
 Webrev: https://webrevs.openjdk.java.net/jmc/20/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6656
  Stats: 2245 lines in 23 files changed: 2153 ins; 1 del; 91 mod
  Patch: https://git.openjdk.java.net/jmc/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/20/head:pull/20

PR: https://git.openjdk.java.net/jmc/pull/20

From github.com+29706926+jessyec-s at openjdk.java.net  Wed Dec 18 16:51:08 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Wed, 18 Dec 2019 16:51:08 GMT
Subject: RFR: 6583: Add filter and search table actions to EventBrowser page
Message-ID: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>

This patch addresses [JMC-6583](https://bugs.openjdk.java.net/browse/JMC-6583) : Should be possible to filter and search in the Event Browser.

I have added table search and filter actions in the Event Browser.

-------------

Commits:
 - 068109c6: Add filter and search table to EventBrowser page

Changes: https://git.openjdk.java.net/jmc/pull/22/files
 Webrev: https://webrevs.openjdk.java.net/jmc/22/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6583
  Stats: 34 lines in 3 files changed: 32 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jmc/pull/22.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/22/head:pull/22

PR: https://git.openjdk.java.net/jmc/pull/22

From jkang at openjdk.java.net  Wed Dec 18 17:10:26 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 18 Dec 2019 17:10:26 GMT
Subject: RFR: 6583: Add filter and search table actions to EventBrowser
 page
In-Reply-To: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
References: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
Message-ID: <Dfx2lwQEQgqft-4Z5yQ_1-7X4zeW3T1MafSGtuNj9gE=.5a94fe6b-b856-49da-9586-f7d029c69b51@github.com>

On Wed, 18 Dec 2019 16:49:52 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch addresses [JMC-6583](https://bugs.openjdk.java.net/browse/JMC-6583) : Should be possible to filter and search in the Event Browser.
> 
> I have added table search and filter actions in the Event Browser.

When searching the events table, the last element "Showing X of Y" seems to be broken.

For example:
![event-browser-search](https://user-images.githubusercontent.com/5430520/71107560-4df28200-218f-11ea-92d5-0feef5a0d0f8.png)

-------------

PR: https://git.openjdk.java.net/jmc/pull/22

From hirt at openjdk.java.net  Thu Dec 19 12:05:37 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 19 Dec 2019 12:05:37 GMT
Subject: RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
Message-ID: <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>

On Tue, 17 Dec 2019 22:26:53 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

> This patch implements [JMC-6656: Allow capturing field values with path syntax](https://bugs.openjdk.java.net/browse/JMC-6656).
> 
> In the xml configuration, a field capture looks like:
> <field>
>   <name>a field value</name>
>   <description>a field value capture with a path syntax</description>
>   <expression>this.field.prop</expression>
> </field>
> See `org/openjdk/jmc/agent/test/jfrprobes_template.xml` for more examples.
> 
> There are currently two limitations to pay attention to:
> 
> 1. Instrumentation point cannot be in synthesized classes:
> Instrumented classes are first loaded by obtaining the bytecode and inspected reflectively to resolve typing information. This fails if the class load is unable to provide the bytecode when `ClassLoader.getResouce()` is called. The cases where it might fail are unlikely to be for classes like proxies or auxiliaries for Java frameworks that have no visible equivalent.
> 
> 2. Instrumentation is unable to access nestmates' private fields:
> Before [nest-base access control](https://openjdk.java.net/jeps/181) was introduced in Java 11, accessing nestmates' private fields is, while lexically correct, forbidden by the JVM. The Java compiler works around by inserting synthetic getters/setters. However, it's not for a BCI agent since changing the class structure is not allowed during class transformation.
> 
> Please let me know your thoughts. Thank you very much!

First quick review. Will take a closer look as soon as I can find some more time.

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Attribute.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  *

2019

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Field.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  *

2019

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Transformer.java line 69:

> 68: 		registry.storeClassPreInstrumentation(className, classfileBuffer);
> 69: 		byte[] instrumentedClassfileBuffer = registry.isRevertIntrumentation() ?
> 70: 				registry.getClassPreInstrumentation(className) : classfileBuffer;

This is not related to this change, but this looks funny to me - why are we storing the class pre-instrumentation? To return to the pre-instrumented version should just be to redefine the class (i.e. run all transformers) without applying any transform.

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Transformer.java line 73:

> 72: 			// Don't reuse this class loader instance. We want the loader and its class to unload after we're done.
> 73: 			classBeingRedefined = new InspectionClassLoader(loader).loadClass(TypeUtils.getCanonicalName(className));
> 74: 		} catch (ClassNotFoundException e) {

This means we'll load the class even if we don't need it. Any chance we could do this lazy when and if we need it?

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/AccessUtils.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  *

2019

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/AccessUtils.java line 45:

> 44: 
> 45: public class AccessUtils {
> 46: 	public static Field getFieldOnHierarchy(Class<?> clazz, String name) throws NoSuchFieldException {

Should probably be a final class. Class javadocs would be nice.

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/InspectionClassLoader.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  *

2019

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/InspectionClassLoader.java line 39:

> 38: 
> 39: // One-time use loader for reflective class inspection. Don't keep static reference to one of these.
> 40: public class InspectionClassLoader extends ClassLoader {

Use javadoc instead, so that tooling will render it in IDEs.

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/TypeUtils.java line 273:

> 272: 
> 273: 	public static Object getFrameVerificationType(Type type) {
> 274: 		switch (type.getSort()) {

In general, javadocs for public methods.

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/expression/IllegalSyntaxException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  *

2019

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/expression/ReferenceChain.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  *

2019

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/expression/ReferenceChain.java line 40:

> 39: 
> 40: public class ReferenceChain {
> 41: 	private final Class<?> callerClass;

Javadocs for public classes, in general. Should probably be final.

core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/expression/ReferenceChainElement.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  *

2019

-------------

Changes requested by hirt (Lead).

PR: https://git.openjdk.java.net/jmc/pull/20

From hirt at openjdk.java.net  Thu Dec 19 12:05:38 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 19 Dec 2019 12:05:38 GMT
Subject: RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
Message-ID: <ZS4bPo2JWp3jPxfs6A1QDUb5x141vo2os9VZyMmUI8E=.9fbe2f67-ef5b-40d7-9517-42015d2e1e47@github.com>

On Thu, 19 Dec 2019 11:58:07 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This patch implements [JMC-6656: Allow capturing field values with path syntax](https://bugs.openjdk.java.net/browse/JMC-6656).
>> 
>> In the xml configuration, a field capture looks like:
>> <field>
>>   <name>a field value</name>
>>   <description>a field value capture with a path syntax</description>
>>   <expression>this.field.prop</expression>
>> </field>
>> See `org/openjdk/jmc/agent/test/jfrprobes_template.xml` for more examples.
>> 
>> There are currently two limitations to pay attention to:
>> 
>> 1. Instrumentation point cannot be in synthesized classes:
>> Instrumented classes are first loaded by obtaining the bytecode and inspected reflectively to resolve typing information. This fails if the class load is unable to provide the bytecode when `ClassLoader.getResouce()` is called. The cases where it might fail are unlikely to be for classes like proxies or auxiliaries for Java frameworks that have no visible equivalent.
>> 
>> 2. Instrumentation is unable to access nestmates' private fields:
>> Before [nest-base access control](https://openjdk.java.net/jeps/181) was introduced in Java 11, accessing nestmates' private fields is, while lexically correct, forbidden by the JVM. The Java compiler works around by inserting synthetic getters/setters. However, it's not for a BCI agent since changing the class structure is not allowed during class transformation.
>> 
>> Please let me know your thoughts. Thank you very much!
> 
> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/AccessUtils.java line 45:
> 
>> 44: 
>> 45: public class AccessUtils {
>> 46: 	public static Field getFieldOnHierarchy(Class<?> clazz, String name) throws NoSuchFieldException {
> 
> Should probably be a final class. Class javadocs would be nice.

Private constructor throwing unsupported exception might be nice so people don't even try instantiate it.

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From hirt at openjdk.java.net  Thu Dec 19 12:05:39 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 19 Dec 2019 12:05:39 GMT
Subject: RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <ZS4bPo2JWp3jPxfs6A1QDUb5x141vo2os9VZyMmUI8E=.9fbe2f67-ef5b-40d7-9517-42015d2e1e47@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
 <ZS4bPo2JWp3jPxfs6A1QDUb5x141vo2os9VZyMmUI8E=.9fbe2f67-ef5b-40d7-9517-42015d2e1e47@github.com>
Message-ID: <mjWhI-nj-Naa6kSDfR51uPZqIklGskWY-GdMrZJreUg=.4e0000a8-3cac-4715-84ed-2b19313908d5@github.com>

On Thu, 19 Dec 2019 11:59:09 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/AccessUtils.java line 45:
>> 
>>> 44: 
>>> 45: public class AccessUtils {
>>> 46: 	public static Field getFieldOnHierarchy(Class<?> clazz, String name) throws NoSuchFieldException {
>> 
>> Should probably be a final class. Class javadocs would be nice.
> 
> Private constructor throwing unsupported exception might be nice so people don't even try instantiate it.

Javadocs for public methods would be nice.

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From marcus.hirt at datadoghq.com  Thu Dec 19 13:37:03 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 19 Dec 2019 14:37:03 +0100
Subject: JMC 2020 - kick-off
Message-ID: <CAOpWGx14K8+J58p0Ui01U_7ZJoR9zHmYqp__hXaOayZWbkg=ig@mail.gmail.com>

Hi all,

The kick-off meeting for 2020 will be:
2020-01-08 19:00/CET (13:00/EST, 10:00/PST)

If you want an invite, please let me know!

Kind regards,
Marcus

From hirt at openjdk.java.net  Thu Dec 19 14:44:21 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 19 Dec 2019 14:44:21 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
Message-ID: <ELavXcf9L9mi58wk1juDyzV2m8zFg5dnEabVwDVbQy8=.71691ef3-aa64-465e-944c-8eb13e59a41f@github.com>

On Wed, 18 Dec 2019 14:25:01 GMT, Jie Kang <jkang at openjdk.org> wrote:

> This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.
> 
> The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.
> 
> This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have two new columns: allocations inside and outside TLABs, as a percentage.
> 
> ![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)
> TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.

Hi Jie,

Thank you for looking at this! Here's some feedback before reviewing the code:

Memory tab:
1. "Total Allocation Percentage" is a bit long. Can this be shortened? The description will be there is someone hovers over the header, for someone wanting more info. Maybe "Total Allocation (%)"?
2. Should there perhaps be a backdrop bar in that column, for the percentage?

TLAB allocations:
1. Same here, perhaps shorten the column width by having "Total Allocation (%)".
2. Backdrop bar in that column too?
3. Instead of spelling out Average, perhaps go with Avg? Instead of Allocation go with Alloc? Normally I'm against these kinds of shorthands, but this is a specialized tab, and some of these columns get really wide since the titles are so long. Much wider than their content, leading to waste of screen estate.

-------------

PR: https://git.openjdk.java.net/jmc/pull/21

From egahlin at openjdk.java.net  Thu Dec 19 14:54:44 2019
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 19 Dec 2019 14:54:44 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <ELavXcf9L9mi58wk1juDyzV2m8zFg5dnEabVwDVbQy8=.71691ef3-aa64-465e-944c-8eb13e59a41f@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
 <ELavXcf9L9mi58wk1juDyzV2m8zFg5dnEabVwDVbQy8=.71691ef3-aa64-465e-944c-8eb13e59a41f@github.com>
Message-ID: <eDK1DobbImYja7Zzs8_-SCCOcFzEhaKNzHmls0EaqPw=.142735da-7444-41d1-b2ca-c3641b6fe1b3@github.com>

On Thu, 19 Dec 2019 14:43:30 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.
>> 
>> The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.
>> 
>> This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have two new columns: allocations inside and outside TLABs, as a percentage.
>> 
>> ![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)
>> TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.
> 
> Hi Jie,
> 
> Thank you for looking at this! Here's some feedback before reviewing the code:
> 
> Memory tab:
> 1. "Total Allocation Percentage" is a bit long. Can this be shortened? The description will be there is someone hovers over the header, for someone wanting more info. Maybe "Total Allocation (%)"?
> 2. Should there perhaps be a backdrop bar in that column, for the percentage?
> 
> TLAB allocations:
> 1. Same here, perhaps shorten the column width by having "Total Allocation (%)".
> 2. Backdrop bar in that column too?
> 3. Instead of spelling out Average, perhaps go with Avg? Instead of Allocation go with Alloc? Normally I'm against these kinds of shorthands, but this is a specialized tab, and some of these columns get really wide since the titles are so long. Much wider than their content, leading to waste of screen estate.

I think JMC 5.5 had good pick of default columns and names.
https://www.javacodegeeks.com/wp-content/uploads/2015/03/jfr-allocations.png

-------------

PR: https://git.openjdk.java.net/jmc/pull/21

From kxu at openjdk.java.net  Thu Dec 19 15:16:13 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Thu, 19 Dec 2019 15:16:13 GMT
Subject: [Rev 01] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
Message-ID: <yYjLZAJx9tGzuS2qlZNcy4LgXso7Dj03c_LFMMgywsM=.4e79ba29-5bd8-492d-b706-ee634876471e@github.com>

> This patch implements [JMC-6656: Allow capturing field values with path syntax](https://bugs.openjdk.java.net/browse/JMC-6656).
> 
> In the xml configuration, a field capture looks like:
> <field>
>   <name>a field value</name>
>   <description>a field value capture with a path syntax</description>
>   <expression>this.field.prop</expression>
> </field>
> See `org/openjdk/jmc/agent/test/jfrprobes_template.xml` for more examples.
> 
> There are currently two limitations to pay attention to:
> 
> 1. Instrumentation point cannot be in synthesized classes:
> Instrumented classes are first loaded by obtaining the bytecode and inspected reflectively to resolve typing information. This fails if the class load is unable to provide the bytecode when `ClassLoader.getResouce()` is called. The cases where it might fail are unlikely to be for classes like proxies or auxiliaries for Java frameworks that have no visible equivalent.
> 
> 2. Instrumentation is unable to access nestmates' private fields:
> Before [nest-base access control](https://openjdk.java.net/jeps/181) was introduced in Java 11, accessing nestmates' private fields is, while lexically correct, forbidden by the JVM. The Java compiler works around by inserting synthetic getters/setters. However, it's not for a BCI agent since changing the class structure is not allowed during class transformation.
> 
> Please let me know your thoughts. Thank you very much!

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 9782c758: update license header year

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/20/files
  - new: https://git.openjdk.java.net/jmc/pull/20/files/caaa7e7e..9782c758

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/20/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/20/webrev.00-01

  Stats: 10 lines in 9 files changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jmc/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/20/head:pull/20

PR: https://git.openjdk.java.net/jmc/pull/20

From marcus.hirt at datadoghq.com  Thu Dec 19 16:07:58 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 19 Dec 2019 17:07:58 +0100
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <eDK1DobbImYja7Zzs8_-SCCOcFzEhaKNzHmls0EaqPw=.142735da-7444-41d1-b2ca-c3641b6fe1b3@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
 <ELavXcf9L9mi58wk1juDyzV2m8zFg5dnEabVwDVbQy8=.71691ef3-aa64-465e-944c-8eb13e59a41f@github.com>
 <eDK1DobbImYja7Zzs8_-SCCOcFzEhaKNzHmls0EaqPw=.142735da-7444-41d1-b2ca-c3641b6fe1b3@github.com>
Message-ID: <CAOpWGx073=dH-0jdPtuG5MzWXWk+0D0vz9Ef=3MznUtDZJYaDQ@mail.gmail.com>

In JMC 5.5 there was a split between the event types (and successive
breakdowns in tabs and tabs in tabs), in later versions there is an
attempt to give an overview of both inside and outside of TLAB
allocations, and their relation, in one table and a graph. There are
advantages to both. If anything, I miss having the means to switch the
aggregation between thread and allocated class name and the pressure
column.

On Thu, Dec 19, 2019 at 3:55 PM Erik Gahlin <egahlin at openjdk.java.net> wrote:
>
> On Thu, 19 Dec 2019 14:43:30 GMT, Marcus Hirt <hirt at openjdk.org> wrote:
>
> >> This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.
> >>
> >> The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.
> >>
> >> This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have two new columns: allocations inside and outside TLABs, as a percentage.
> >>
> >> ![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)
> >> TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.
> >
> > Hi Jie,
> >
> > Thank you for looking at this! Here's some feedback before reviewing the code:
> >
> > Memory tab:
> > 1. "Total Allocation Percentage" is a bit long. Can this be shortened? The description will be there is someone hovers over the header, for someone wanting more info. Maybe "Total Allocation (%)"?
> > 2. Should there perhaps be a backdrop bar in that column, for the percentage?
> >
> > TLAB allocations:
> > 1. Same here, perhaps shorten the column width by having "Total Allocation (%)".
> > 2. Backdrop bar in that column too?
> > 3. Instead of spelling out Average, perhaps go with Avg? Instead of Allocation go with Alloc? Normally I'm against these kinds of shorthands, but this is a specialized tab, and some of these columns get really wide since the titles are so long. Much wider than their content, leading to waste of screen estate.
>
> I think JMC 5.5 had good pick of default columns and names.
> https://www.javacodegeeks.com/wp-content/uploads/2015/03/jfr-allocations.png
>
> -------------
>
> PR: https://git.openjdk.java.net/jmc/pull/21

From kxu at openjdk.java.net  Thu Dec 19 16:15:46 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Thu, 19 Dec 2019 16:15:46 GMT
Subject: [Rev 02] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
Message-ID: <6vFGiCWI5bMx0Wm2NWXlYIWAmLn56KF3izneLJkiGcc=.277fdcf3-5d19-4807-92a0-23e0196f9cd5@github.com>

> This patch implements [JMC-6656: Allow capturing field values with path syntax](https://bugs.openjdk.java.net/browse/JMC-6656).
> 
> In the xml configuration, a field capture looks like:
> <field>
>   <name>a field value</name>
>   <description>a field value capture with a path syntax</description>
>   <expression>this.field.prop</expression>
> </field>
> See `org/openjdk/jmc/agent/test/jfrprobes_template.xml` for more examples.
> 
> There are currently two limitations to pay attention to:
> 
> 1. Instrumentation point cannot be in synthesized classes:
> Instrumented classes are first loaded by obtaining the bytecode and inspected reflectively to resolve typing information. This fails if the class load is unable to provide the bytecode when `ClassLoader.getResouce()` is called. The cases where it might fail are unlikely to be for classes like proxies or auxiliaries for Java frameworks that have no visible equivalent.
> 
> 2. Instrumentation is unable to access nestmates' private fields:
> Before [nest-base access control](https://openjdk.java.net/jeps/181) was introduced in Java 11, accessing nestmates' private fields is, while lexically correct, forbidden by the JVM. The Java compiler works around by inserting synthetic getters/setters. However, it's not for a BCI agent since changing the class structure is not allowed during class transformation.
> 
> Please let me know your thoughts. Thank you very much!

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - c35788f2: add javadoc

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/20/files
  - new: https://git.openjdk.java.net/jmc/pull/20/files/9782c758..c35788f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/20/webrev.02
 - incr: https://webrevs.openjdk.java.net/jmc/20/webrev.01-02

  Stats: 163 lines in 4 files changed: 149 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jmc/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/20/head:pull/20

PR: https://git.openjdk.java.net/jmc/pull/20

From kxu at openjdk.java.net  Thu Dec 19 17:35:10 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Thu, 19 Dec 2019 17:35:10 GMT
Subject: [Rev 02] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
Message-ID: <mCNUeV_lqNCL4yeZtBiC-Po8Yx2eyLMAjQA0GDWA-B4=.20aaf1af-7251-40ad-8552-36da5b97e02a@github.com>

On Thu, 19 Dec 2019 11:48:21 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Transformer.java line 69:
> 
>> 68: 		registry.storeClassPreInstrumentation(className, classfileBuffer);
>> 69: 		byte[] instrumentedClassfileBuffer = registry.isRevertIntrumentation() ?
>> 70: 				registry.getClassPreInstrumentation(className) : classfileBuffer;
> 
> This is not related to this change, but this looks funny to me - why are we storing the class pre-instrumentation? To return to the pre-instrumented version should just be to redefine the class (i.e. run all transformers) without applying any transform.

Sorry, this is actually my bad. I thought the bytecode provided to the transformer would be the current running bytecode (ie. possibly after transformation), and I misled @jessyec-s when she was implementing [JMC-5458: Support Class-Redefinitions](https://bugs.openjdk.java.net/browse/JMC-5458).

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From kxu at openjdk.java.net  Thu Dec 19 17:40:03 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Thu, 19 Dec 2019 17:40:03 GMT
Subject: [Rev 02] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
Message-ID: <t2tobVC3PEJD7Lq5KCmo1gB3lTlm6icOvucBRfhpD3M=.4e6860ac-5daf-4039-a06d-488057aeee32@github.com>

On Thu, 19 Dec 2019 12:02:18 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/util/TypeUtils.java line 273:
> 
>> 272: 
>> 273: 	public static Object getFrameVerificationType(Type type) {
>> 274: 		switch (type.getSort()) {
> 
> In general, javadocs for public methods.

It has been updated with Javadoc. Please refer to the latest changeset.

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From kxu at openjdk.java.net  Thu Dec 19 17:56:43 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Thu, 19 Dec 2019 17:56:43 GMT
Subject: [Rev 02] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <mCNUeV_lqNCL4yeZtBiC-Po8Yx2eyLMAjQA0GDWA-B4=.20aaf1af-7251-40ad-8552-36da5b97e02a@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
 <mCNUeV_lqNCL4yeZtBiC-Po8Yx2eyLMAjQA0GDWA-B4=.20aaf1af-7251-40ad-8552-36da5b97e02a@github.com>
Message-ID: <iK6u6hag8ojh3lC4Ri4DzF2gM7BQPtm7GetDJqNWuCw=.bf4078a6-ab62-4a8a-922d-3c78b54a27da@github.com>

On Thu, 19 Dec 2019 17:34:41 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

>> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Transformer.java line 69:
>> 
>>> 68: 		registry.storeClassPreInstrumentation(className, classfileBuffer);
>>> 69: 		byte[] instrumentedClassfileBuffer = registry.isRevertIntrumentation() ?
>>> 70: 				registry.getClassPreInstrumentation(className) : classfileBuffer;
>> 
>> This is not related to this change, but this looks funny to me - why are we storing the class pre-instrumentation? To return to the pre-instrumented version should just be to redefine the class (i.e. run all transformers) without applying any transform.
> 
> Sorry, this is actually my bad. I thought the bytecode provided to the transformer would be the current running bytecode (ie. possibly after transformation), and I misled @jessyec-s when she was implementing [JMC-5458: Support Class-Redefinitions](https://bugs.openjdk.java.net/browse/JMC-5458).

[JMC-6658: Remove unnecessary storing of pre-instrumented bytecode](https://bugs.openjdk.java.net/browse/JMC-6658) is created for resolving this issue.

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From egahlin at openjdk.java.net  Thu Dec 19 18:15:23 2019
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 19 Dec 2019 18:15:23 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <eDK1DobbImYja7Zzs8_-SCCOcFzEhaKNzHmls0EaqPw=.142735da-7444-41d1-b2ca-c3641b6fe1b3@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
 <ELavXcf9L9mi58wk1juDyzV2m8zFg5dnEabVwDVbQy8=.71691ef3-aa64-465e-944c-8eb13e59a41f@github.com>
 <eDK1DobbImYja7Zzs8_-SCCOcFzEhaKNzHmls0EaqPw=.142735da-7444-41d1-b2ca-c3641b6fe1b3@github.com>
Message-ID: <mlhzeJVfaC5sv_CsB_eJOZcMk_Lto3dh3FRAi1ePLfE=.53e52bf7-2e8d-4d78-af09-998e7e89802e@github.com>

On Thu, 19 Dec 2019 14:54:33 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Hi Jie,
>> 
>> Thank you for looking at this! Here's some feedback before reviewing the code:
>> 
>> Memory tab:
>> 1. "Total Allocation Percentage" is a bit long. Can this be shortened? The description will be there is someone hovers over the header, for someone wanting more info. Maybe "Total Allocation (%)"?
>> 2. Should there perhaps be a backdrop bar in that column, for the percentage?
>> 
>> TLAB allocations:
>> 1. Same here, perhaps shorten the column width by having "Total Allocation (%)".
>> 2. Backdrop bar in that column too?
>> 3. Instead of spelling out Average, perhaps go with Avg? Instead of Allocation go with Alloc? Normally I'm against these kinds of shorthands, but this is a specialized tab, and some of these columns get really wide since the titles are so long. Much wider than their content, leading to waste of screen estate.
> 
> I think JMC 5.5 had good pick of default columns and names.
> https://www.javacodegeeks.com/wp-content/uploads/2015/03/jfr-allocations.png

I think we can skip any mention TLAB, at least if the purpose of the view is to find where the top allocation sites are.

I think Class | Sample Count | Pressure will be sufficiernt for 99% of all users.

There could be a seperate tab for those that want to tune TLABs, or hidden columns that can be made visisble for advanced users. In the future, we will probably add an ObjectAllocation event that can be on by default that will not leak implementation details as the TLABs.

-------------

PR: https://git.openjdk.java.net/jmc/pull/21

From jkang at openjdk.java.net  Thu Dec 19 18:26:38 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Thu, 19 Dec 2019 18:26:38 GMT
Subject: [Rev 01] RFR: 6657: Add allocation pressure column to Memory and
 TLAB views
In-Reply-To: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
Message-ID: <R6aGB3u4Ox2VZWtt-xFhILeGYXTxqgMtr9B6HHc4XdQ=.528ec7a8-ac10-4b37-b5d7-232bb39cafdc@github.com>

> This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.
> 
> The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.
> 
> This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have two new columns: allocations inside and outside TLABs, as a percentage.
> 
> ![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)
> TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.

The pull request has been updated with 2 additional commits.

-------------

Added commits:
 - 4fd1fa37: Shorten column names with short form for Allocation(s)
 - 375fb831: Shorten column names with short form for Average and Percentage

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/21/files
  - new: https://git.openjdk.java.net/jmc/pull/21/files/9f73e4fd..4fd1fa37

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/21/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/21/webrev.00-01

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jmc/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/21/head:pull/21

PR: https://git.openjdk.java.net/jmc/pull/21

From jkang at openjdk.java.net  Thu Dec 19 19:25:13 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Thu, 19 Dec 2019 19:25:13 GMT
Subject: [Rev 02] RFR: 6657: Add allocation pressure column to Memory and
 TLAB views
In-Reply-To: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
Message-ID: <t_q88U4sJqlSQ7UAG6sUoB8KB_nV9ND6DGzYhJsS6xM=.aefa18af-bf86-4263-a27c-49f5a5b727ce@github.com>

> This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.
> 
> The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.
> 
> This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have two new columns: allocations inside and outside TLABs, as a percentage.
> 
> ![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)
> TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - d9803793: Add translations for new column name and descriptions

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/21/files
  - new: https://git.openjdk.java.net/jmc/pull/21/files/4fd1fa37..d9803793

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/21/webrev.02
 - incr: https://webrevs.openjdk.java.net/jmc/21/webrev.01-02

  Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jmc/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/21/head:pull/21

PR: https://git.openjdk.java.net/jmc/pull/21

From jkang at openjdk.java.net  Thu Dec 19 19:45:03 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Thu, 19 Dec 2019 19:45:03 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <mlhzeJVfaC5sv_CsB_eJOZcMk_Lto3dh3FRAi1ePLfE=.53e52bf7-2e8d-4d78-af09-998e7e89802e@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
 <ELavXcf9L9mi58wk1juDyzV2m8zFg5dnEabVwDVbQy8=.71691ef3-aa64-465e-944c-8eb13e59a41f@github.com>
 <eDK1DobbImYja7Zzs8_-SCCOcFzEhaKNzHmls0EaqPw=.142735da-7444-41d1-b2ca-c3641b6fe1b3@github.com>
 <mlhzeJVfaC5sv_CsB_eJOZcMk_Lto3dh3FRAi1ePLfE=.53e52bf7-2e8d-4d78-af09-998e7e89802e@github.com>
Message-ID: <R-C-OstKmvqtH3vwyKDJ1rfTFKN53zAaTIkVrsfuu8E=.26980461-f2c7-4050-a404-032d10960245@github.com>

On Thu, 19 Dec 2019 18:15:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think JMC 5.5 had good pick of default columns and names.
>> https://www.javacodegeeks.com/wp-content/uploads/2015/03/jfr-allocations.png
> 
> I think we can skip any mention of TLABs, at least if the purpose of the view is to find where the top allocation sites are.
> 
> I think Class | Sample Count | Pressure will be sufficient for 99% of all users.
> 
> There could be a seperate tab for those that want to tune TLABs, or hidden columns that can be made visible for advanced users. In the future, we will probably add an ObjectAllocation event that can be on by default that will not leak implementation details such TLAB information.

@thegreystone 

Thanks for taking a look. I have shortened the names and added translations. I am also looking at moving the percentage aggregators (e.g. JdkAggregators.ALLOC_INSIDE_TLAB_SUM_PERCENTAGE) out of core, probably into the TlabPage related code, as well as adding something there to make it a cleaner solution. 

It's a bit ugly since the aggregator does not compute a percentage itself. I've been toying with writing some helper classes or functions to work over multiple aggregators and item collections but I haven't come up with anything clean and it's outside the scope of this issue, imo.

@egahlin 

Thank you for sharing the screenshot. I like the setup shown there as well. I will see if I can follow-up the changes here with some more adjustments to the Memory/Tlab page UI in JDK Mission Control. 

Having the Stacktrace View be generic and available for all pages has made things a bit more complicated to mimic what you have shown. It may be cool to have some kind of extension functionality such that when a page is visited, the page can augment this generic view with additional columns (e.g. to show allocation pressure by method while on the memory page).

Regarding removal of reference to TLAB and having more advanced options via initially hidden features (e.g. columns), I think what you wrote makes sense. It may be that what you described is  close to what is in JDK Mission Control. The Memory page shows events by class and includes the percentage column for total allocations. It has initially hidden columns for in/out of TLAB related aggregations. The TLAB page on the other hand, (screenshot in initial description) shows these TLAB events and now by thread or by top method. I think the organization of the UI can be improved and I'm going to think about and potentially propose more changes after this. (I should have also included a screenshot of the Memory page...)

-------------

PR: https://git.openjdk.java.net/jmc/pull/21

From kxu at openjdk.java.net  Thu Dec 19 19:48:55 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Thu, 19 Dec 2019 19:48:55 GMT
Subject: [Rev 03] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
Message-ID: <BlxxLphv_WQMRrbqIFHn6YzU9K_uj9ERi5r1dZGXTe0=.5acb7aca-fa6f-47db-b6e3-631d99b23fbc@github.com>

> This patch implements [JMC-6656: Allow capturing field values with path syntax](https://bugs.openjdk.java.net/browse/JMC-6656).
> 
> In the xml configuration, a field capture looks like:
> <field>
>   <name>a field value</name>
>   <description>a field value capture with a path syntax</description>
>   <expression>this.field.prop</expression>
> </field>
> See `org/openjdk/jmc/agent/test/jfrprobes_template.xml` for more examples.
> 
> There are currently two limitations to pay attention to:
> 
> 1. Instrumentation point cannot be in synthesized classes:
> Instrumented classes are first loaded by obtaining the bytecode and inspected reflectively to resolve typing information. This fails if the class load is unable to provide the bytecode when `ClassLoader.getResouce()` is called. The cases where it might fail are unlikely to be for classes like proxies or auxiliaries for Java frameworks that have no visible equivalent.
> 
> 2. Instrumentation is unable to access nestmates' private fields:
> Before [nest-base access control](https://openjdk.java.net/jeps/181) was introduced in Java 11, accessing nestmates' private fields is, while lexically correct, forbidden by the JVM. The Java compiler works around by inserting synthetic getters/setters. However, it's not for a BCI agent since changing the class structure is not allowed during class transformation.
> 
> Please let me know your thoughts. Thank you very much!

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - c78ce947: lazy-load class with InspectionClassLoader

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/20/files
  - new: https://git.openjdk.java.net/jmc/pull/20/files/c35788f2..c78ce947

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/20/webrev.03
 - incr: https://webrevs.openjdk.java.net/jmc/20/webrev.02-03

  Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jmc/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/20/head:pull/20

PR: https://git.openjdk.java.net/jmc/pull/20

From kxu at openjdk.java.net  Thu Dec 19 19:48:56 2019
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Thu, 19 Dec 2019 19:48:56 GMT
Subject: [Rev 03] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
Message-ID: <5jnaef01M0_Qpu3tkHSkJBrKZpPWh5Nl76skcEi3n20=.2ae0e510-4c69-44b2-80ee-09b3d454f524@github.com>

On Thu, 19 Dec 2019 11:49:34 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Transformer.java line 73:
> 
>> 72: 			// Don't reuse this class loader instance. We want the loader and its class to unload after we're done.
>> 73: 			classBeingRedefined = new InspectionClassLoader(loader).loadClass(TypeUtils.getCanonicalName(className));
>> 74: 		} catch (ClassNotFoundException e) {
> 
> This means we'll load the class even if we don't need it. Any chance we could do this lazy when and if we need it?

I agree. The code has been updated.

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From github.com+29706926+jessyec-s at openjdk.java.net  Thu Dec 19 19:54:53 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Thu, 19 Dec 2019 19:54:53 GMT
Subject: RFR: 6658: Remove unnecessary storing of pre-instrumented bytecode
Message-ID: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>

This patch addresses [JMC-6658](https://bugs.openjdk.java.net/browse/JMC-6658) and removes the unnecessary storing of pre-instrumented bytecode that was implemented in [JMC-5458](https://bugs.openjdk.java.net/browse/JMC-5458).

-------------

Commits:
 - 40ae08f5: Remove unnecessary storing of pre-instrumented bytecode

Changes: https://git.openjdk.java.net/jmc/pull/23/files
 Webrev: https://webrevs.openjdk.java.net/jmc/23/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6658
  Stats: 34 lines in 3 files changed: 0 ins; 32 del; 2 mod
  Patch: https://git.openjdk.java.net/jmc/pull/23.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/23/head:pull/23

PR: https://git.openjdk.java.net/jmc/pull/23

From github.com+29706926+jessyec-s at openjdk.java.net  Thu Dec 19 19:56:39 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Thu, 19 Dec 2019 19:56:39 GMT
Subject: [Rev 03] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <iK6u6hag8ojh3lC4Ri4DzF2gM7BQPtm7GetDJqNWuCw=.bf4078a6-ab62-4a8a-922d-3c78b54a27da@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <DSB_grJx1f-b_MRdpiDfvV_qMDgh7sgHLBftKTE90vM=.595d77c1-f72b-4ca6-bf80-8d2270828f58@github.com>
 <mCNUeV_lqNCL4yeZtBiC-Po8Yx2eyLMAjQA0GDWA-B4=.20aaf1af-7251-40ad-8552-36da5b97e02a@github.com>
 <iK6u6hag8ojh3lC4Ri4DzF2gM7BQPtm7GetDJqNWuCw=.bf4078a6-ab62-4a8a-922d-3c78b54a27da@github.com>
Message-ID: <yybH3alCyLWREJWU41HNVIQ8H7llda2QzyCmcaEspVg=.550b8451-6585-43cf-be84-f7c70f1c1edd@github.com>

On Thu, 19 Dec 2019 17:56:32 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

>> Sorry, this is actually my bad. I thought the bytecode provided to the transformer would be the current running bytecode (ie. possibly after transformation), and I misled @jessyec-s when she was implementing [JMC-5458: Support Class-Redefinitions](https://bugs.openjdk.java.net/browse/JMC-5458).
> 
> [JMC-6658: Remove unnecessary storing of pre-instrumented bytecode](https://bugs.openjdk.java.net/browse/JMC-6658) is created for resolving this issue.

I have created a PR for this issue https://github.com/openjdk/jmc/pull/23

-------------

PR: https://git.openjdk.java.net/jmc/pull/20

From github.com+29706926+jessyec-s at openjdk.java.net  Thu Dec 19 21:06:43 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Thu, 19 Dec 2019 21:06:43 GMT
Subject: RFR: 6583: Add filter and search table actions to EventBrowser
 page
In-Reply-To: <Dfx2lwQEQgqft-4Z5yQ_1-7X4zeW3T1MafSGtuNj9gE=.5a94fe6b-b856-49da-9586-f7d029c69b51@github.com>
References: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
 <Dfx2lwQEQgqft-4Z5yQ_1-7X4zeW3T1MafSGtuNj9gE=.5a94fe6b-b856-49da-9586-f7d029c69b51@github.com>
Message-ID: <bPAobjW_BKytVVeqwbPVCTbALXdwP_12TeHMyNmRmAE=.30c115d3-d166-4247-a388-35d26700f4b7@github.com>

On Wed, 18 Dec 2019 17:10:09 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> This patch addresses [JMC-6583](https://bugs.openjdk.java.net/browse/JMC-6583) : Should be possible to filter and search in the Event Browser.
>> 
>> I have added table search and filter actions in the Event Browser.
> 
> When searching the events table, the last element "Showing X of Y" seems to be broken.
> 
> For example:
> ![event-browser-search](https://user-images.githubusercontent.com/5430520/71107560-4df28200-218f-11ea-92d5-0feef5a0d0f8.png)

> When searching the events table, the last element "Showing X of Y" seems to be broken.
> 
Yes, this seems to be an issue that occurs on all tables using itemLists, as it is also seen in the Event Log table on the Exceptions page.  [JMC-6659](https://bugs.openjdk.java.net/browse/JMC-6659) has been made to address this bug.

-------------

PR: https://git.openjdk.java.net/jmc/pull/22

From hirt at openjdk.java.net  Fri Dec 20 11:03:07 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 20 Dec 2019 11:03:07 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <R-C-OstKmvqtH3vwyKDJ1rfTFKN53zAaTIkVrsfuu8E=.26980461-f2c7-4050-a404-032d10960245@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
 <ELavXcf9L9mi58wk1juDyzV2m8zFg5dnEabVwDVbQy8=.71691ef3-aa64-465e-944c-8eb13e59a41f@github.com>
 <eDK1DobbImYja7Zzs8_-SCCOcFzEhaKNzHmls0EaqPw=.142735da-7444-41d1-b2ca-c3641b6fe1b3@github.com>
 <mlhzeJVfaC5sv_CsB_eJOZcMk_Lto3dh3FRAi1ePLfE=.53e52bf7-2e8d-4d78-af09-998e7e89802e@github.com>
 <R-C-OstKmvqtH3vwyKDJ1rfTFKN53zAaTIkVrsfuu8E=.26980461-f2c7-4050-a404-032d10960245@github.com>
Message-ID: <bTmQavGW9K4mLHe22ziWHR6KmCiXFPPgBmYGGFbbVIc=.afc84d2f-907c-470c-9d2c-e7bda6bd75cc@github.com>

On Thu, 19 Dec 2019 19:44:24 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> I think we can skip any mention of TLABs, at least if the purpose of the view is to find where the top allocation sites are.
>> 
>> I think Class | Sample Count | Pressure will be sufficient for 99% of all users.
>> 
>> There could be a seperate tab for those that want to tune TLABs, or hidden columns that can be made visible for advanced users. In the future, we will probably add an ObjectAllocation event that can be on by default that will not leak implementation details such TLAB information.
> 
> @thegreystone 
> 
> Thanks for taking a look. I have shortened the names and added translations. I am also looking at moving the percentage aggregators (e.g. JdkAggregators.ALLOC_INSIDE_TLAB_SUM_PERCENTAGE) out of core, probably into the TlabPage related code, as well as adding something there to make it a cleaner solution. 
> 
> It's a bit ugly since the aggregator does not compute a percentage itself. I've been toying with writing some helper classes or functions to work over multiple aggregators and item collections but I haven't come up with anything clean and it's outside the scope of this issue, imo.
> 
> @egahlin 
> 
> Thank you for sharing the screenshot. I like the setup shown there as well. I will see if I can follow-up the changes here with some more adjustments to the Memory/Tlab page UI in JDK Mission Control. 
> 
> Having the Stacktrace View be generic and available for all pages has made things a bit more complicated to mimic what you have shown. It may be cool to have some kind of extension functionality such that when a page is visited, the page can augment this generic view with additional columns (e.g. to show allocation pressure by method while on the memory page).
> 
> Regarding removal of reference to TLAB and having more advanced options via initially hidden features (e.g. columns), I think what you wrote makes sense. It may be that what you described is  close to what is in JDK Mission Control. The Memory page shows events by class and includes the percentage column for total allocations. It has initially hidden columns for in/out of TLAB related aggregations. The TLAB page on the other hand, (screenshot in initial description) shows these TLAB events and now by thread or by top method. I think the organization of the UI can be improved and I'm going to think about and potentially propose more changes after this. (I should have also included a screenshot of the Memory page...)

Yep, it's already split up in a general "Memory" page and a TLAB allocations page (which is located under JVM Internals), and which is already grouped by class. The only missing part would be the "Pressure", which is basically Total Allocation (%), added by Jie's PR.

> It may be cool to have some kind of extension functionality such that when a page is visited, the page can augment this generic view with additional columns (e.g. to show allocation pressure by method while on the memory page).

Agreed. I believe this is discussed in another already existing issue. We can start a thread on the dev-list to discuss this in more detail.

-------------

PR: https://git.openjdk.java.net/jmc/pull/21

From jkang at openjdk.java.net  Fri Dec 20 17:29:19 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Fri, 20 Dec 2019 17:29:19 GMT
Subject: [Rev 03] RFR: 6657: Add allocation pressure column to Memory and
 TLAB views
In-Reply-To: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
Message-ID: <eAIJ2cA8_i45xF9IlS1T3hU-AouU_G1coU4t5r6lOQo=.8ed135fb-8a40-4817-a932-aa273a05b13b@github.com>

> This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.
> 
> The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.
> 
> This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have two new columns: allocations inside and outside TLABs, as a percentage.
> 
> ![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)
> TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 9895d81e: Move name and description setting to percentage column creation. Remove duplicate aggregators

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/21/files
  - new: https://git.openjdk.java.net/jmc/pull/21/files/d9803793..9895d81e

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/21/webrev.03
 - incr: https://webrevs.openjdk.java.net/jmc/21/webrev.02-03

  Stats: 72 lines in 12 files changed: 31 ins; 37 del; 4 mod
  Patch: https://git.openjdk.java.net/jmc/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/21/head:pull/21

PR: https://git.openjdk.java.net/jmc/pull/21

From jkang at openjdk.java.net  Fri Dec 20 17:40:10 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Fri, 20 Dec 2019 17:40:10 GMT
Subject: [Rev 04] RFR: 6657: Add allocation pressure column to Memory and
 TLAB views
In-Reply-To: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
References: <mqLSAIjw31aV-jnBhwZbkfkP8DE21Qvi0eK5nrI6n40=.0a50acc5-7c11-46ca-86fe-40e0fa70abe2@github.com>
Message-ID: <_mfpJ9qNawJ6N20-2C_DxHenEza2RV48Z3hqoADojQk=.b42a8979-4279-46b8-b26f-b7a196d685ea@github.com>

> This patch addresses https://bugs.openjdk.java.net/browse/JMC-6657, which itself is a clone of https://bugs.openjdk.java.net/browse/JMC-5923 that targets the Memory and TLAB pages, rather than the stacktrace view.
> 
> The ItemHistogram and related classes now have support for Percentage columns that divides the aggregate value for items in a row against the aggregate value for all items in the model.
> 
> This is used in the Memory page to show Total Allocation as a Percentage. The TLAB page is modified to be tabbed and contains two ItemHistograms, one for classifying against Threads (previously existed) and one against Top Methods (new). Both also have two new columns: allocations inside and outside TLABs, as a percentage.
> 
> ![tlab-page](https://user-images.githubusercontent.com/5430520/71093691-b2094c00-2177-11ea-9965-f27948964cd3.png)
> TLABs by Top Methods, showcasing sorting by the new percentage column. Together with the stacktrace view, I believe these changes make it easier to see relevant areas of allocation pressure.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 1aa7e63b: Revert field name change

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/21/files
  - new: https://git.openjdk.java.net/jmc/pull/21/files/9895d81e..1aa7e63b

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/21/webrev.04
 - incr: https://webrevs.openjdk.java.net/jmc/21/webrev.03-04

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jmc/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/21/head:pull/21

PR: https://git.openjdk.java.net/jmc/pull/21

From hirt at openjdk.java.net  Fri Dec 20 19:02:27 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 20 Dec 2019 19:02:27 GMT
Subject: RFR: 6658: Remove unnecessary storing of pre-instrumented bytecode
In-Reply-To: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>
References: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>
Message-ID: <3c9YvOmWOPHQM_wd6sDmWP7YOyWzb4BAjOfwQw4I9BE=.3065105d-7594-40db-8eeb-fc4d1539ac88@github.com>

On Thu, 19 Dec 2019 19:52:39 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch addresses [JMC-6658](https://bugs.openjdk.java.net/browse/JMC-6658) and removes the unnecessary storing of pre-instrumented bytecode that was implemented in [JMC-5458](https://bugs.openjdk.java.net/browse/JMC-5458).

Hi Jessye! Looks good, but the testClearAllTransforms tests should really validate that the byte code no longer contains the events. Also, since test execution can't be known, the clear all transforms test should first attempt to transform. Also - the JMX API should really, really not return (potentially serialize) classes, but I will open a separate issue for this, as it is not related to this PR.

-------------

PR: https://git.openjdk.java.net/jmc/pull/23

From github.com+7112604+dmnm at openjdk.java.net  Sat Dec 21 07:50:46 2019
From: github.com+7112604+dmnm at openjdk.java.net (Dmitry Popov)
Date: Sat, 21 Dec 2019 07:50:46 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <roHGISHcHyRlI47D2--pEFZb3KbrXFir6Fr54DGmFbk=.aa933f9f-57d7-4f56-bf50-d9d1e963cb75@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
 <roHGISHcHyRlI47D2--pEFZb3KbrXFir6Fr54DGmFbk=.aa933f9f-57d7-4f56-bf50-d9d1e963cb75@github.com>
Message-ID: <9Ay-5YICUCe10RYyEMwCwMOM2L2Av9vn89TtUOzZIJU=.ea491f7b-85f6-4eaf-8c82-921100a4e2a3@github.com>

On Mon, 16 Dec 2019 16:47:28 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> This patch addresses [JMC-5721](https://bugs.openjdk.java.net/browse/JMC-5721): Reintroduce the Percentage column.
>> 
>> 1. StacktraceView has been amended to display Percentage column as well it displays stack trace and count ones. Percentage format is #.## (up-to 2 decimal points), it will also arbitrarily round the number.
>> 2. Tool tip with frame fraction and sibling groups info has been moved from Count column to Percentage.
>> 3. Currently Background drawer decorates Percentage column instead of Count.
> 
> application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java line 738:
> 
>> 737: 			int totalCount = getRootFork(frame.getBranch().getParentFork()).getItemsInFork();
>> 738: 			return String.format("%.2f%%", (itemCount / (float) totalCount) * 100F);
>> 739: 		}
> 
> You should use the unit toolkit we have for displaying the percentage, i.e. use UnitLookup.PERCENT_UNITY.quantity to get a value, and then format it as a string using .displayUsing and pass in an appropriate formatting hint. For this I'd say that running 
> 
>> UnitLookup.PERCENT_UNITY.quantity(itemCount / (float) totalCount).displayUsing(IDisplayable.AUTO)
> 
>  will work fine, but feel free to try some alternatives.

Hi Henrik,

Thanks for the comment. Let me explain why I've chosen `String.format()` there. I thought about using unit toolkit but I tried to reintroduce Percentage column the same way as it worked before, i.e. with unit up-to 2 decimal point. UnitLookup.PERCENT_UNITY, which is used in tool tip, displays the percentage in up to 5 decimal points format, like 0.00689 %. I think it's not so useful for the column percentage representation, but it's open for discussion.

-------------

PR: https://git.openjdk.java.net/jmc/pull/12

From github.com+7112604+dmnm at openjdk.java.net  Sat Dec 21 17:23:48 2019
From: github.com+7112604+dmnm at openjdk.java.net (Dmitry Popov)
Date: Sat, 21 Dec 2019 17:23:48 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <9Ay-5YICUCe10RYyEMwCwMOM2L2Av9vn89TtUOzZIJU=.ea491f7b-85f6-4eaf-8c82-921100a4e2a3@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
 <roHGISHcHyRlI47D2--pEFZb3KbrXFir6Fr54DGmFbk=.aa933f9f-57d7-4f56-bf50-d9d1e963cb75@github.com>
 <9Ay-5YICUCe10RYyEMwCwMOM2L2Av9vn89TtUOzZIJU=.ea491f7b-85f6-4eaf-8c82-921100a4e2a3@github.com>
Message-ID: <8ukcdpgJb7nC6ndCNQKHvfWwI-vUB_ypd_Wy1wsrGL0=.d022a2cc-286f-4ae9-bd0d-fc2fb96b34fe@github.com>

On Sat, 21 Dec 2019 07:50:37 GMT, Dmitry Popov <github.com+7112604+dmnm at openjdk.org> wrote:

>> application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java line 738:
>> 
>>> 737: 			int totalCount = getRootFork(frame.getBranch().getParentFork()).getItemsInFork();
>>> 738: 			return String.format("%.2f%%", (itemCount / (float) totalCount) * 100F);
>>> 739: 		}
>> 
>> You should use the unit toolkit we have for displaying the percentage, i.e. use UnitLookup.PERCENT_UNITY.quantity to get a value, and then format it as a string using .displayUsing and pass in an appropriate formatting hint. For this I'd say that running 
>> 
>>> UnitLookup.PERCENT_UNITY.quantity(itemCount / (float) totalCount).displayUsing(IDisplayable.AUTO)
>> 
>>  will work fine, but feel free to try some alternatives.
> 
> Hi Henrik,
> 
> Thanks for the comment. Let me explain why I've chosen `String.format()` there. I thought about using unit toolkit but I tried to reintroduce Percentage column the same way as it worked before, i.e. with unit up-to 2 decimal point. UnitLookup.PERCENT_UNITY, which is used in tool tip, displays the percentage in up to 5 decimal points format, like 0.00689 %. I think it's not so useful for the column percentage representation, but it's open for discussion.

How it looks with `String.format()` (always has 2 decimal points):
![Screenshot1](https://user-images.githubusercontent.com/7112604/71311286-3e916400-242f-11ea-8937-9e0b1bef761b.png)

How it looks with `UnitLookup.PERCENT_UNITY.quantity` (from 0 to 5 decimal points and a whitespace before % sign):
![Screenshot2](https://user-images.githubusercontent.com/7112604/71311368-a8117280-242f-11ea-9d71-4fa8a71e22ec.png)

-------------

PR: https://git.openjdk.java.net/jmc/pull/12

From hirt at openjdk.java.net  Mon Dec 23 13:23:33 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 23 Dec 2019 13:23:33 GMT
Subject: RFR: 6662: Updating to Eclipse 2019-12 (4.14)
Message-ID: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>

Also removing old outdated versions. Keeping 2 last plus photon (mainly for Mac developers that hasn't upgraded to 2019-12).

-------------

Commits:
 - 09667aaf: 6662: Updating to Eclipse 2019-12 (4.14)

Changes: https://git.openjdk.java.net/jmc/pull/24/files
 Webrev: https://webrevs.openjdk.java.net/jmc/24/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6662
  Stats: 642 lines in 13 files changed: 113 ins; 507 del; 22 mod
  Patch: https://git.openjdk.java.net/jmc/pull/24.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/24/head:pull/24

PR: https://git.openjdk.java.net/jmc/pull/24

From jkang at openjdk.java.net  Mon Dec 23 14:53:46 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Mon, 23 Dec 2019 14:53:46 GMT
Subject: RFR: 6662: Updating to Eclipse 2019-12 (4.14)
In-Reply-To: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
References: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
Message-ID: <ycW7NbCSY80BoAEfZ4R-1o59zNaKu4jZz6ptjDuUCVM=.be1069dd-4f84-49e6-99cc-7e6bcd6d6840@github.com>

On Mon, 23 Dec 2019 13:20:04 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also removing old outdated versions. Keeping 2 last plus photon (mainly for Mac developers that hasn't upgraded to 2019-12).

pom.xml line 111:

> 110: 	<profiles>
> 111: 	<profile>
> 112: 			<id>2019-12</id>

It looks like a tab was cut here;;

-------------

PR: https://git.openjdk.java.net/jmc/pull/24

From hirt at openjdk.java.net  Mon Dec 23 15:24:16 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 23 Dec 2019 15:24:16 GMT
Subject: RFR: 6583: Add filter and search table actions to EventBrowser
 page
In-Reply-To: <bPAobjW_BKytVVeqwbPVCTbALXdwP_12TeHMyNmRmAE=.30c115d3-d166-4247-a388-35d26700f4b7@github.com>
References: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
 <Dfx2lwQEQgqft-4Z5yQ_1-7X4zeW3T1MafSGtuNj9gE=.5a94fe6b-b856-49da-9586-f7d029c69b51@github.com>
 <bPAobjW_BKytVVeqwbPVCTbALXdwP_12TeHMyNmRmAE=.30c115d3-d166-4247-a388-35d26700f4b7@github.com>
Message-ID: <kNFKgr3IfyL4JDAJfil5AaaJLqxaks9X1XAOxUCy-UA=.b752af92-5cba-4b66-b6f3-33f13cb00fef@github.com>

On Thu, 19 Dec 2019 21:05:59 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

>> When searching the events table, the last element "Showing X of Y" seems to be broken.
>> 
>> For example:
>> ![event-browser-search](https://user-images.githubusercontent.com/5430520/71107560-4df28200-218f-11ea-92d5-0feef5a0d0f8.png)
> 
>> When searching the events table, the last element "Showing X of Y" seems to be broken.
>> 
> Yes, this seems to be an issue that occurs on all tables using itemLists, as it is also seen in the Event Log table on the Exceptions page.  [JMC-6659](https://bugs.openjdk.java.net/browse/JMC-6659) has been made to address this bug.

Hi Jessye!

Thanks for looking at this! I think you'd want the search/filter setting to be remembered (perhaps just for the session / in memory - i.e. no real persistence required). Right now, as soon as you switch event type, the search box will disappear, and you need to re-enable it. This gets tedious very quickly.

-------------

PR: https://git.openjdk.java.net/jmc/pull/22

From jkang at openjdk.java.net  Mon Dec 23 15:30:47 2019
From: jkang at openjdk.java.net (Jie Kang)
Date: Mon, 23 Dec 2019 15:30:47 GMT
Subject: RFR: 6662: Updating to Eclipse 2019-12 (4.14)
In-Reply-To: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
References: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
Message-ID: <DQJZmeyy6bJ88BcuOVsFnAYNWG_6iXmHSz2PggLWrC8=.e9c3e23e-65d8-4f81-be29-b4db02d4b949@github.com>

On Mon, 23 Dec 2019 13:20:04 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also removing old outdated versions. Keeping 2 last plus photon (mainly for Mac developers that hasn't upgraded to 2019-12).

The changes worked for me.

-------------

Marked as reviewed by jkang (Author).

PR: https://git.openjdk.java.net/jmc/pull/24

From hirt at openjdk.java.net  Mon Dec 23 15:35:34 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 23 Dec 2019 15:35:34 GMT
Subject: [Rev 01] RFR: 6662: Updating to Eclipse 2019-12 (4.14)
In-Reply-To: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
References: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
Message-ID: <2zZGLzTVH8udzXuK0msXxXPfVArTpxPZTplmyBsT2NM=.f37bd47e-ebbb-4320-b27b-c54809e31abe@github.com>

> Also removing old outdated versions. Keeping 2 last plus photon (mainly for Mac developers that hasn't upgraded to 2019-12).

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 2738041c: Fixing formatting

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/24/files
  - new: https://git.openjdk.java.net/jmc/pull/24/files/09667aaf..2738041c

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/24/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/24/webrev.00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/24.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/24/head:pull/24

PR: https://git.openjdk.java.net/jmc/pull/24

From github.com+29706926+jessyec-s at openjdk.java.net  Mon Dec 23 16:27:35 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Mon, 23 Dec 2019 16:27:35 GMT
Subject: [Rev 01] RFR: 6583: Add filter and search table actions to
 EventBrowser page
In-Reply-To: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
References: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
Message-ID: <qOSSI_6UhEm2AU4MWjOHwokuht5cNyo3GJcel1_QAoc=.166ec3ef-ed38-41bf-a2c0-6682aeb3149f@github.com>

> This patch addresses [JMC-6583](https://bugs.openjdk.java.net/browse/JMC-6583) : Should be possible to filter and search in the Event Browser.
> 
> I have added table search and filter actions in the Event Browser.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - c3c5cfa7: Make filter actions persit between event type switches

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/22/files
  - new: https://git.openjdk.java.net/jmc/pull/22/files/068109c6..c3c5cfa7

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/22/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/22/webrev.00-01

  Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/22.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/22/head:pull/22

PR: https://git.openjdk.java.net/jmc/pull/22

From github.com+29706926+jessyec-s at openjdk.java.net  Mon Dec 23 16:27:56 2019
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Mon, 23 Dec 2019 16:27:56 GMT
Subject: RFR: 6583: Add filter and search table actions to EventBrowser
 page
In-Reply-To: <kNFKgr3IfyL4JDAJfil5AaaJLqxaks9X1XAOxUCy-UA=.b752af92-5cba-4b66-b6f3-33f13cb00fef@github.com>
References: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
 <Dfx2lwQEQgqft-4Z5yQ_1-7X4zeW3T1MafSGtuNj9gE=.5a94fe6b-b856-49da-9586-f7d029c69b51@github.com>
 <bPAobjW_BKytVVeqwbPVCTbALXdwP_12TeHMyNmRmAE=.30c115d3-d166-4247-a388-35d26700f4b7@github.com>
 <kNFKgr3IfyL4JDAJfil5AaaJLqxaks9X1XAOxUCy-UA=.b752af92-5cba-4b66-b6f3-33f13cb00fef@github.com>
Message-ID: <-Ij5b-KaTtqUVbAGg8PEDJrdoC9l7VvvJvoj2Y_ZXyw=.7611a453-778e-4ab8-90bd-ce504f994807@github.com>

On Mon, 23 Dec 2019 15:24:05 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>>> When searching the events table, the last element "Showing X of Y" seems to be broken.
>>> 
>> Yes, this seems to be an issue that occurs on all tables using itemLists, as it is also seen in the Event Log table on the Exceptions page.  [JMC-6659](https://bugs.openjdk.java.net/browse/JMC-6659) has been made to address this bug.
> 
> Hi Jessye!
> 
> Thanks for looking at this! I think you'd want the search/filter setting to be remembered (perhaps just for the session / in memory - i.e. no real persistence required). Right now, as soon as you switch event type, the search box will disappear, and you need to re-enable it. This gets tedious very quickly.

I have made the search and filter table actions persist when event types are switched in https://github.com/openjdk/jmc/pull/22/commits/c3c5cfa7cdf5193f529d3d02f7c719725edcc217

-------------

PR: https://git.openjdk.java.net/jmc/pull/22

From hirt at openjdk.java.net  Mon Dec 23 20:49:35 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 23 Dec 2019 20:49:35 GMT
Subject: RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <roHGISHcHyRlI47D2--pEFZb3KbrXFir6Fr54DGmFbk=.aa933f9f-57d7-4f56-bf50-d9d1e963cb75@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
 <roHGISHcHyRlI47D2--pEFZb3KbrXFir6Fr54DGmFbk=.aa933f9f-57d7-4f56-bf50-d9d1e963cb75@github.com>
Message-ID: <Q3cnD08C5as9qiGjuWfa5SWCI_3Al_ZGES5X61TqOJw=.9e399ba9-baa3-4442-9b59-47e3f655aecc@github.com>

On Mon, 16 Dec 2019 16:47:47 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> This patch addresses [JMC-5721](https://bugs.openjdk.java.net/browse/JMC-5721): Reintroduce the Percentage column.
>> 
>> 1. StacktraceView has been amended to display Percentage column as well it displays stack trace and count ones. Percentage format is #.## (up-to 2 decimal points), it will also arbitrarily round the number.
>> 2. Tool tip with frame fraction and sibling groups info has been moved from Count column to Percentage.
>> 3. Currently Background drawer decorates Percentage column instead of Count.
> 
> 

Hi Dmitry! 

We're using ISO 8000-1 in the JMC project. This means we actually prefer having a space in there, not only between values and units, but also between values and symbols like the percent sign. 

See e.g.:
https://physics.nist.gov/cuu/Units/checklist.html, https://www.euspen.eu/wp-content/uploads/2018/08/A-Style-Guide-For-euspen-Publications-2017.pdf

That said, I agree that sticking to two decimals for the rendering looks neater. I believe the default rendering for PERCENT_UNITY is to try to use up to 3 significant figures, switching to scientific notation if the value is too large/small, which perhaps would be a good representation for the tooltips?

-------------

PR: https://git.openjdk.java.net/jmc/pull/12

From hirt at openjdk.java.net  Mon Dec 23 21:05:25 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 23 Dec 2019 21:05:25 GMT
Subject: [Rev 01] RFR: 6583: Add filter and search table actions to
 EventBrowser page
In-Reply-To: <qOSSI_6UhEm2AU4MWjOHwokuht5cNyo3GJcel1_QAoc=.166ec3ef-ed38-41bf-a2c0-6682aeb3149f@github.com>
References: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
 <qOSSI_6UhEm2AU4MWjOHwokuht5cNyo3GJcel1_QAoc=.166ec3ef-ed38-41bf-a2c0-6682aeb3149f@github.com>
Message-ID: <fbnUV0ZpZdaVYNDOr2PB3L_VmpMZYAguwrJFnRYwW30=.9ea5a4fb-c8fc-47ee-afd3-07c083d9dc44@github.com>

On Mon, 23 Dec 2019 21:05:24 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

>> This patch addresses [JMC-6583](https://bugs.openjdk.java.net/browse/JMC-6583) : Should be possible to filter and search in the Event Browser.
>> 
>> I have added table search and filter actions in the Event Browser.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by hirt (Lead).

PR: https://git.openjdk.java.net/jmc/pull/22

From hirt at openjdk.java.net  Tue Dec 24 13:06:05 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 24 Dec 2019 13:06:05 GMT
Subject: [Integrated] RFR: 6583: Add filter and search table actions to
 EventBrowser page
In-Reply-To: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
References: <MlLBqYl5p3vkCvN0WE-iEsU72yJYwGhQDbc70sIxjUA=.25011e4a-54fe-4f04-9d92-bcb99b3b8508@github.com>
Message-ID: <4377cdea-1028-4452-b212-335988a406cd@openjdk.org>

Changeset: 2e81a835
Author:    Jessye Coleman-Shapiro <jescolem at redhat.com>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-24 13:05:39 +0000
URL:       https://git.openjdk.java.net/jmc/commit/2e81a835

6583: Add filter and search table actions to EventBrowser page

Reviewed-by: hirt

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

From github.com+7112604+dmnm at openjdk.java.net  Wed Dec 25 17:51:50 2019
From: github.com+7112604+dmnm at openjdk.java.net (Dmitry Popov)
Date: Wed, 25 Dec 2019 17:51:50 GMT
Subject: [Rev 01] RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
Message-ID: <48uTfzrJj_PisNEMpIkEKE_8BCpkw9v0cbbhBWGtVG4=.6b089079-91ef-4fd1-83d4-d4b55b4b7503@github.com>

> This patch addresses [JMC-5721](https://bugs.openjdk.java.net/browse/JMC-5721): Reintroduce the Percentage column.
> 
> 1. StacktraceView has been amended to display Percentage column as well it displays stack trace and count ones. Percentage format is #.## (up-to 2 decimal points), it will also arbitrarily round the number.
> 2. Tool tip with frame fraction and sibling groups info has been moved from Count column to Percentage.
> 3. Currently Background drawer decorates Percentage column instead of Count.

Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR.

-------------

Added commits:
 - 565529bb: JMC-5721 :: StacktraceView :: Reintroduce the Percentage column

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/12/files
  - new: https://git.openjdk.java.net/jmc/pull/12/files/b3ad0225..565529bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/12/webrev.01
 - incr: https://webrevs.openjdk.java.net/jmc/12/webrev.00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/12.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/12/head:pull/12

PR: https://git.openjdk.java.net/jmc/pull/12

From github.com+7112604+dmnm at openjdk.java.net  Fri Dec 27 16:25:25 2019
From: github.com+7112604+dmnm at openjdk.java.net (Dmitry Popov)
Date: Fri, 27 Dec 2019 16:25:25 GMT
Subject: [Rev 01] RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <Q3cnD08C5as9qiGjuWfa5SWCI_3Al_ZGES5X61TqOJw=.9e399ba9-baa3-4442-9b59-47e3f655aecc@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
 <roHGISHcHyRlI47D2--pEFZb3KbrXFir6Fr54DGmFbk=.aa933f9f-57d7-4f56-bf50-d9d1e963cb75@github.com>
 <Q3cnD08C5as9qiGjuWfa5SWCI_3Al_ZGES5X61TqOJw=.9e399ba9-baa3-4442-9b59-47e3f655aecc@github.com>
Message-ID: <95Fpm3AYwyi1_hxT3JbfEmlTv3lbdGxw13hTuI4t5no=.351ce4a1-ad50-4922-91b4-18d98a271d5c@github.com>

On Mon, 23 Dec 2019 20:49:22 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>>
> 
> Hi Dmitry! 
> 
> We're using ISO 80000-1 in the JMC project. This means we actually prefer having a space in there, not only between values and units, but also between values and symbols like the percent sign. 
> 
> See e.g.:
> https://physics.nist.gov/cuu/Units/checklist.html, https://www.euspen.eu/wp-content/uploads/2018/08/A-Style-Guide-For-euspen-Publications-2017.pdf
> 
> That said, I agree that sticking to two decimals for the rendering looks neater. I believe the default rendering for PERCENT_UNITY is to try to use up to 3 significant figures, switching to scientific notation if the value is too large/small, which perhaps would be a good representation for the tooltips?

@Gunde @thegreystone 

The PR has been updated. Please review the changes.

-------------

PR: https://git.openjdk.java.net/jmc/pull/12

From hdafgard at openjdk.java.net  Sun Dec 29 17:30:38 2019
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Sun, 29 Dec 2019 17:30:38 GMT
Subject: [Rev 01] RFR: 6662: Updating to Eclipse 2019-12 (4.14)
In-Reply-To: <2zZGLzTVH8udzXuK0msXxXPfVArTpxPZTplmyBsT2NM=.f37bd47e-ebbb-4320-b27b-c54809e31abe@github.com>
References: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
 <2zZGLzTVH8udzXuK0msXxXPfVArTpxPZTplmyBsT2NM=.f37bd47e-ebbb-4320-b27b-c54809e31abe@github.com>
Message-ID: <l68AqDlPnlSES1x3qHsjxlaMPqSEbZE5PSpGxOOFNLE=.27248f0b-9386-4ace-82e8-8c23e107ba56@github.com>

On Sun, 29 Dec 2019 17:30:38 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Also removing old outdated versions. Keeping 2 last plus photon (mainly for Mac developers that hasn't upgraded to 2019-12).
> 
> The pull request has been updated with 1 additional commit.

LGTM

-------------

Marked as reviewed by hdafgard (Reviewer).

PR: https://git.openjdk.java.net/jmc/pull/24

From hirt at openjdk.java.net  Mon Dec 30 08:50:07 2019
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 30 Dec 2019 08:50:07 GMT
Subject: [Integrated] RFR: 6662: Updating to Eclipse 2019-12 (4.14)
In-Reply-To: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
References: <dNL1ZeyGd2uuU5nnwwsZC-B33Lk007rABsgz-EeNoK8=.c62cce45-8bd2-4cc9-966c-cf02586e5d9d@github.com>
Message-ID: <582c6d53-3797-4cc7-b987-db453c5d2f50@openjdk.org>

Changeset: 423e72db
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2019-12-29 17:31:48 +0000
URL:       https://git.openjdk.java.net/jmc/commit/423e72db

6662: Updating to Eclipse 2019-12 (4.14)

Reviewed-by: jkang, hdafgard

! pom.xml
- releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target
- releng/platform-definitions/platform-definition-2018-09/pom.xml
- 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/platform-definition-2019-03.target
- releng/platform-definitions/platform-definition-2019-03/pom.xml
! releng/platform-definitions/platform-definition-2019-06/.project
- releng/platform-definitions/platform-definition-2019-06/platform-definition-2019-06.target
- releng/platform-definitions/platform-definition-2019-06/pom.xml
+ releng/platform-definitions/platform-definition-2019-12/platform-definition-2019-12.target
+ releng/platform-definitions/platform-definition-2019-12/pom.xml
! releng/platform-definitions/pom.xml