From jkang at openjdk.java.net  Mon Jan  6 14:04:26 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Mon, 6 Jan 2020 14:04:26 GMT
Subject: RFR: 6665: .project files still exist for removed platform definitions
Message-ID: <ML08hx8nEgOQV9e3X9h0xGrCgL07yI4IAnFyP2hrbOA=.078b853b-828d-471d-b6c1-a5de54dcadda@github.com>

Removes the .project files that remain in the directories. See https://github.com/openjdk/jmc/commit/423e72db602667b72ac924d1178301253321cbd1 for the removal of the platform definitions.

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

Commits:
 - 0c5147e5: 6665: .project files still exist for removed platform definitions

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

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

From jkang at openjdk.java.net  Mon Jan  6 19:39:59 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Mon, 6 Jan 2020 19:39:59 GMT
Subject: RFR: 6663: Reloading the Flame Chart View in Linux displays file
 browser
Message-ID: <jG35iPMkD5XmlqBXQ3N-TpiglpEV7gYVzm6H9TTpEjU=.922f9388-19e1-478c-bbe8-b2a73fad1d30@github.com>

The context menu to reload is disabled

The disable comes from looking at Webkit source that respects doit field:
https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT%20WebKit/gtk/org/eclipse/swt/browser/WebKit.java#L819

The issue occurs as we set Browser text to some HTML and no URL is set. The reload action seems to revisit the URL with the default result being the file system, I guess.

A bug against SWT was opened to respect HTML text set when refresh/reload.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=558846

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

Commits:
 - 0996a28a: 6663: Reloading the Flame Chart View in Linux displays file browser

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

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

From jkang at openjdk.java.net  Mon Jan  6 20:06:27 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Mon, 6 Jan 2020 20:06:27 GMT
Subject: RFR: 6663: Reloading the Flame Chart View in Linux displays file
 browser
In-Reply-To: <jG35iPMkD5XmlqBXQ3N-TpiglpEV7gYVzm6H9TTpEjU=.922f9388-19e1-478c-bbe8-b2a73fad1d30@github.com>
References: <jG35iPMkD5XmlqBXQ3N-TpiglpEV7gYVzm6H9TTpEjU=.922f9388-19e1-478c-bbe8-b2a73fad1d30@github.com>
Message-ID: <0ZjOc0h5dKTGuUWYCPMALOvrjwBrMNyvT-o4Cd3njY8=.10be7868-cfee-4347-b6a6-353f5ccbdb50@github.com>

On Mon, 6 Jan 2020 16:41:04 GMT, Jie Kang <jkang at openjdk.org> wrote:

> The context menu to reload is disabled
> 
> The disable comes from looking at Webkit source that respects doit field:
> https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT%20WebKit/gtk/org/eclipse/swt/browser/WebKit.java#L819
> 
> The issue occurs as we set Browser text to some HTML and no URL is set. The reload action seems to revisit the URL with the default result being the file system, I guess.
> 
> A bug against SWT was opened to respect HTML text set when refresh/reload.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=558846

Er, just to be clear. This is a workaround fix that prevents users from reloading/refreshing. As far as I can tell the keyboard shortcuts aren't being captured so various modifier + R combinations don't reload either.

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

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

From hirt at openjdk.java.net  Tue Jan  7 00:49:19 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 7 Jan 2020 00:49:19 GMT
Subject: RFR: 6665: .project files still exist for removed platform
 definitions
In-Reply-To: <ML08hx8nEgOQV9e3X9h0xGrCgL07yI4IAnFyP2hrbOA=.078b853b-828d-471d-b6c1-a5de54dcadda@github.com>
References: <ML08hx8nEgOQV9e3X9h0xGrCgL07yI4IAnFyP2hrbOA=.078b853b-828d-471d-b6c1-a5de54dcadda@github.com>
Message-ID: <VV-stcP6WO23vfOivYVyLdYkTBtkUV6jKZC7t6atqgY=.2ff66768-b19a-41db-acc1-38affefc083a@github.com>

On Mon, 6 Jan 2020 14:01:09 GMT, Jie Kang <jkang at openjdk.org> wrote:

> Removes the .project files that remain in the directories. See https://github.com/openjdk/jmc/commit/423e72db602667b72ac924d1178301253321cbd1 for the removal of the platform definitions.



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

Marked as reviewed by hirt (Lead).

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

From hirt at openjdk.java.net  Tue Jan  7 09:32:24 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 7 Jan 2020 09:32:24 GMT
Subject: RFR: 6663: Reloading the Flame Chart View in Linux displays file
 browser
In-Reply-To: <jG35iPMkD5XmlqBXQ3N-TpiglpEV7gYVzm6H9TTpEjU=.922f9388-19e1-478c-bbe8-b2a73fad1d30@github.com>
References: <jG35iPMkD5XmlqBXQ3N-TpiglpEV7gYVzm6H9TTpEjU=.922f9388-19e1-478c-bbe8-b2a73fad1d30@github.com>
Message-ID: <0bUe4GDxj_r47h0PZ50A8FQbhezcGqf5hNDV4e_es_o=.f08c8357-e429-41e5-8d4a-6883362fe374@github.com>

On Mon, 6 Jan 2020 16:41:04 GMT, Jie Kang <jkang at openjdk.org> wrote:

> The context menu to reload is disabled
> 
> The disable comes from looking at Webkit source that respects doit field:
> https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT%20WebKit/gtk/org/eclipse/swt/browser/WebKit.java#L819
> 
> The issue occurs as we set Browser text to some HTML and no URL is set. The reload action seems to revisit the URL with the default result being the file system, I guess.
> 
> A bug against SWT was opened to respect HTML text set when refresh/reload.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=558846



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

Marked as reviewed by hirt (Lead).

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

From aptmac at openjdk.java.net  Tue Jan  7 15:39:14 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Tue, 7 Jan 2020 15:39:14 GMT
Subject: [Integrated] RFR: 6665: .project files still exist for removed
 platform definitions
In-Reply-To: <ML08hx8nEgOQV9e3X9h0xGrCgL07yI4IAnFyP2hrbOA=.078b853b-828d-471d-b6c1-a5de54dcadda@github.com>
References: <ML08hx8nEgOQV9e3X9h0xGrCgL07yI4IAnFyP2hrbOA=.078b853b-828d-471d-b6c1-a5de54dcadda@github.com>
Message-ID: <ca7d6c39-3c0b-4c3e-85eb-81d21af59276@openjdk.org>

Changeset: 31d82a7d
Author:    Jie Kang <jkang at openjdk.org>
Committer: Alex Macdonald <aptmac at openjdk.org>
Date:      2020-01-07 15:38:19 +0000
URL:       https://git.openjdk.java.net/jmc/commit/31d82a7d

6665: .project files still exist for removed platform definitions

Reviewed-by: hirt

- releng/platform-definitions/platform-definition-2018-09/.project
- releng/platform-definitions/platform-definition-2018-12/.project
- releng/platform-definitions/platform-definition-2019-03/.project
- releng/platform-definitions/platform-definition-2019-06/.project

From aptmac at openjdk.java.net  Tue Jan  7 15:40:10 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Tue, 7 Jan 2020 15:40:10 GMT
Subject: [Integrated] RFR: 6663: Reloading the Flame Chart View in Linux
 displays file browser
In-Reply-To: <jG35iPMkD5XmlqBXQ3N-TpiglpEV7gYVzm6H9TTpEjU=.922f9388-19e1-478c-bbe8-b2a73fad1d30@github.com>
References: <jG35iPMkD5XmlqBXQ3N-TpiglpEV7gYVzm6H9TTpEjU=.922f9388-19e1-478c-bbe8-b2a73fad1d30@github.com>
Message-ID: <43a66b9f-b8ca-41af-a91f-b6ef3b03a074@openjdk.org>

Changeset: 7ad8f7c0
Author:    Jie Kang <jkang at openjdk.org>
Committer: Alex Macdonald <aptmac at openjdk.org>
Date:      2020-01-07 15:39:08 +0000
URL:       https://git.openjdk.java.net/jmc/commit/7ad8f7c0

6663: Reloading the Flame Chart View in Linux displays file browser

Reviewed-by: hirt

! application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/FlameGraphView.java

From jkang at redhat.com  Tue Jan  7 21:09:44 2020
From: jkang at redhat.com (Jie Kang)
Date: Tue, 7 Jan 2020 16:09:44 -0500
Subject: Proposal: Moving/refactoring some more bundles/packages/classes from
 application into core
Message-ID: <CAEBeOcqT5-FwwgZTYkEptV7+umKJ+DiQ7yfpjAsr0zHj275KRQ@mail.gmail.com>

Hi,

For 8.0.0 and beyond I would like to propose moving some portion of
the below bundles/packages/classes from application module into core
module for easier re-use by third-party applications. I've tried to
divide things into sensible sets and provide a quick explanation for
each. I'm willing to prepare patches for sets on a case-by-case basis
but would like some opinions now before I start to put in a large amount
of work.

Bundle:
org.openjdk.jmc.flightrecorder.configuration

This bundle contains classes used to manipulate the configuration for
a Flight Recording. For example to describe which events should be
enabled and with what parameters when starting a recording. It
requires one bundle and imports one package, both from core. I think
moving the entire bundle is low risk.

Bundle:
org.openjdk.jmc.jdp

This bundle contains classes used to discover JVM services on a
network. It has zero imports. I think moving the entire bundle is low
risk.

Bundles:
org.openjdk.jmc.rjmx
org.openjdk.jmc.rjmx.services.jfr

These bundles are used to provide jfr rjmx client side API to connect
to a JVM and start/stop/extract flight recordings, etc. Moving these,
or some part of these would require some refactoring (yet to analyze),
and would be higher risk. Conceptually, I think it makes sense to
provide these features in core for third-party applications to use.

Bundle:
org.openjdk.jmc.ui.common
Package group:
org.openjdk.jmc.ui.common.security

Some of the packages in this bundle don't seem to fit the term 'ui'.
Specifically the security package provides a SecurityManager, one use
being secure rjmx connections for the above org.openjdk.jmc.rjmx and
org.openjdk.rjmx.services.jfr functionality. In general it's used to
securely store usernames/passwords in various configuration pages.
This comes about as a dependency from using the rjmx code; moving this
may also require some refactoring and rework.


Usage of these bundles comes from work to reuse existing code
to manage connections to JVMs for JFR related tasks, starting,
stopping, extracting recordings, etc. I think it makes sense to have
this capability in the exported API, core. I'd appreciate your
opinions on this proposal, thanks!


Regards,


From github.com+29706926+jessyec-s at openjdk.java.net  Wed Jan  8 17:49:10 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Wed, 8 Jan 2020 17:49:10 GMT
Subject: [Rev 01] 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: <LTf4GaYEEPowrHFB8eQWIxH-qOnp97UCGw5AnRjcvfk=.39c64cda-1462-4c46-bfbe-fabdc1620862@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).

The pull request has been updated with a new target base due to a merge or a rebase.

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

Commits:
 - dc2c00b5: Make testSetTransforms check if byte code is actually transformed/reverted
 - 6a3c9141: 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.01
  Stats: 154 lines in 4 files changed: 76 ins; 48 del; 30 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  Wed Jan  8 18:01:48 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Wed, 8 Jan 2020 18:01:48 GMT
Subject: RFR: 6658: Remove unnecessary storing of pre-instrumented bytecode
In-Reply-To: <3c9YvOmWOPHQM_wd6sDmWP7YOyWzb4BAjOfwQw4I9BE=.3065105d-7594-40db-8eeb-fc4d1539ac88@github.com>
References: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>
 <3c9YvOmWOPHQM_wd6sDmWP7YOyWzb4BAjOfwQw4I9BE=.3065105d-7594-40db-8eeb-fc4d1539ac88@github.com>
Message-ID: <apvTTulYW5IvHZZB2Q743nFqG6tBZvM01VAzGl5KZUc=.21bdb0ae-37d4-4065-8bed-0010607c2c5f@github.com>

On Fri, 20 Dec 2019 19:02:18 GMT, Marcus Hirt <hirt 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 emission of the events. Also, since the test execution order 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.

With huge help from @tabjy in https://github.com/openjdk/jmc/pull/23/commits/dc2c00b5da05bcb584fb83f7bac1893452bb0c9d I have made the two previous tests, testSetTransforms and testClearAllTransforms, into one testSetTransforms test.  I did this to make one non redundant test because as mentioned, before testing the clearing of all transforms, transforms have to be applied first, which is what testSetTransforms was previously doing . 

In this patch testSetTransforms has been modified to transform a method with an event that throws a run time exception.  To test that the byte code actually gets instrumented the transformed method is ran and checked to see that this run time exception is fired.  Similarly, clearing all transforms is tested by rerunning this method and ensuring that the exception is not fired.

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

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

From hirt at openjdk.java.net  Wed Jan  8 19:29:01 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 8 Jan 2020 19:29:01 GMT
Subject: [Rev 01] RFR: 6658: Remove unnecessary storing of
 pre-instrumented bytecode
In-Reply-To: <LTf4GaYEEPowrHFB8eQWIxH-qOnp97UCGw5AnRjcvfk=.39c64cda-1462-4c46-bfbe-fabdc1620862@github.com>
References: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>
 <LTf4GaYEEPowrHFB8eQWIxH-qOnp97UCGw5AnRjcvfk=.39c64cda-1462-4c46-bfbe-fabdc1620862@github.com>
Message-ID: <jQBueBDHFHZ4IwjYI5VmP0-1NYzB4brgZ7sL_Glcikk=.eb7088f2-d22d-439b-9a72-60d5ffd87805@github.com>

On Wed, 8 Jan 2020 19:29:00 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).
> 
> The pull request has been updated with a new target base due to a merge or a rebase.

core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestSetTransforms.java line 101:

> 100: 		injectFailingEvent();
> 101: 		doSetTransfroms(XML_DESCRIPTION);
> 102: 		try {

doSetTransfroms -> doSetTransforms

core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestSetTransforms.java line 105:

> 104: 		} catch (RuntimeException e) {
> 105: 			excpetionThrown = true;
> 106: 		}

Typo: excpetionThrown -> exceptionThrown

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

Changes requested by hirt (Lead).

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

From github.com+29706926+jessyec-s at openjdk.java.net  Wed Jan  8 19:53:31 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Wed, 8 Jan 2020 19:53:31 GMT
Subject: [Rev 02] 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: <r-b--Es-XXvuh2T4mQD1aMw1aJsCp8vw4Rwsnax5llQ=.8db9baa7-5fcc-48cc-8fbd-c2273e4ad505@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).

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 846cddff: Fix typos

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/23/files
  - new: https://git.openjdk.java.net/jmc/pull/23/files/dc2c00b5..846cddff

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

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 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  Wed Jan  8 19:53:33 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Wed, 8 Jan 2020 19:53:33 GMT
Subject: [Rev 01] RFR: 6658: Remove unnecessary storing of
 pre-instrumented bytecode
In-Reply-To: <jQBueBDHFHZ4IwjYI5VmP0-1NYzB4brgZ7sL_Glcikk=.eb7088f2-d22d-439b-9a72-60d5ffd87805@github.com>
References: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>
 <LTf4GaYEEPowrHFB8eQWIxH-qOnp97UCGw5AnRjcvfk=.39c64cda-1462-4c46-bfbe-fabdc1620862@github.com>
 <jQBueBDHFHZ4IwjYI5VmP0-1NYzB4brgZ7sL_Glcikk=.eb7088f2-d22d-439b-9a72-60d5ffd87805@github.com>
Message-ID: <4Ci5xQ9OuWbpzvguKhXloDo_L5TOTQtzgZuX44rPy-0=.9c3ea616-3bfb-4eca-ab5d-a3fb4cfd8ebd@github.com>

On Wed, 8 Jan 2020 19:28:04 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with a new target base due to a merge or a rebase.
> 
> core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestSetTransforms.java line 105:
> 
>> 104: 		} catch (RuntimeException e) {
>> 105: 			excpetionThrown = true;
>> 106: 		}
> 
> Typo: excpetionThrown -> exceptionThrown

Fixed in https://github.com/openjdk/jmc/pull/23/commits/846cddff4c5d733e7544d096755566bc783cd5bf

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

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

From github.com+29706926+jessyec-s at openjdk.java.net  Wed Jan  8 19:54:04 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Wed, 8 Jan 2020 19:54:04 GMT
Subject: [Rev 01] RFR: 6658: Remove unnecessary storing of
 pre-instrumented bytecode
In-Reply-To: <jQBueBDHFHZ4IwjYI5VmP0-1NYzB4brgZ7sL_Glcikk=.eb7088f2-d22d-439b-9a72-60d5ffd87805@github.com>
References: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>
 <LTf4GaYEEPowrHFB8eQWIxH-qOnp97UCGw5AnRjcvfk=.39c64cda-1462-4c46-bfbe-fabdc1620862@github.com>
 <jQBueBDHFHZ4IwjYI5VmP0-1NYzB4brgZ7sL_Glcikk=.eb7088f2-d22d-439b-9a72-60d5ffd87805@github.com>
Message-ID: <ByKCaZTuLVN73IAW8xZoNRjOqBOCgRNmGUpj9lEpFrc=.0c4c82ac-e9c3-4fc1-837a-3e2844a032c6@github.com>

On Wed, 8 Jan 2020 19:26:05 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with a new target base due to a merge or a rebase.
> 
> core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestSetTransforms.java line 101:
> 
>> 100: 		injectFailingEvent();
>> 101: 		doSetTransfroms(XML_DESCRIPTION);
>> 102: 		try {
> 
> Typo: doSetTransfroms -> doSetTransforms

Fixed in https://github.com/openjdk/jmc/pull/23/commits/846cddff4c5d733e7544d096755566bc783cd5bf

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

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

From hirt at openjdk.java.net  Thu Jan  9 14:21:27 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 9 Jan 2020 14:21:27 GMT
Subject: [Rev 02] RFR: 6658: Remove unnecessary storing of
 pre-instrumented bytecode
In-Reply-To: <r-b--Es-XXvuh2T4mQD1aMw1aJsCp8vw4Rwsnax5llQ=.8db9baa7-5fcc-48cc-8fbd-c2273e4ad505@github.com>
References: <1Z7bs2mtx6tx71c_9QAAaTRcOXmgvndyX4FE2zlCQCw=.79b5a212-8ad0-4d2a-9e20-0a495f078943@github.com>
 <r-b--Es-XXvuh2T4mQD1aMw1aJsCp8vw4Rwsnax5llQ=.8db9baa7-5fcc-48cc-8fbd-c2273e4ad505@github.com>
Message-ID: <Gz2ydutQEqNaGlcuGfg36OzMaqCURNFmZGYPG6SDTGo=.dab97655-af05-45f9-bf1e-8506385f0224@github.com>

On Thu, 9 Jan 2020 14:21:26 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).
> 
> The pull request has been updated with 1 additional commit.



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

Marked as reviewed by hirt (Lead).

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

From github.com+29706926+jessyec-s at openjdk.java.net  Fri Jan 10 14:35:28 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Fri, 10 Jan 2020 14:35:28 GMT
Subject: RFR: 6659: Remove 'Showing X of Y events...' table message when not
 applicable
Message-ID: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>

This patch addresses the following issue: 

When a table made with an itemList has more rows than the set maximum that can be shown, it displays a message "Showing X of Y events..." in its last row. This message is not removed if a search is performed on the table that results in fewer then the maximum number of events being displayed. For example, this is seen in the Exceptions page in the Event Log table.
![table-example](https://user-images.githubusercontent.com/29706926/72159945-6cf9c380-338b-11ea-9f32-0fd3a6654709.png)

This patch makes the 'Showing X of Y events...'  table message disappear when less than the maximum number of events that can be displayed populate a table.

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

Commits:
 - cd97aca3: Add ability to remove the 'Showing X of Y events...' table message

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

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

From jkang at openjdk.java.net  Fri Jan 10 15:12:27 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Fri, 10 Jan 2020 15:12:27 GMT
Subject: RFR: 6659: Remove 'Showing X of Y events...' table message when
 not applicable
In-Reply-To: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
References: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
Message-ID: <yQr4_3XK9cEQ37LqPfcK2aVz0Oa7WIPJTrMOcDI-vwQ=.811e2a0d-55b7-4f33-ba85-63c3102f5c7e@github.com>

On Fri, 10 Jan 2020 14:34:27 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch addresses the following issue: 
> 
> When a table made with an itemList has more rows than the set maximum that can be shown, it displays a message "Showing X of Y events..." in its last row. This message is not removed if a search is performed on the table that results in fewer then the maximum number of events being displayed. For example, this is seen in the Exceptions page in the Event Log table.
> ![table-example](https://user-images.githubusercontent.com/29706926/72159945-6cf9c380-338b-11ea-9f32-0fd3a6654709.png)
> 
> This patch makes the 'Showing X of Y events...'  table message disappear when less than the maximum number of events that can be displayed populate a table.

Could the change be made to the user of this class? ExtraRowTableViewer could be used elsewhere for showing any kind of extra message not necessarily related to x of y events; maybe some text they always want to show. Then applying this logic wouldn't make sense.

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

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

From aptmac at openjdk.java.net  Fri Jan 10 15:13:12 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Fri, 10 Jan 2020 15:13:12 GMT
Subject: RFR: 6364: Improvements to the Thread Graph
Message-ID: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com>

This patch addresses JMC-6364 [[0]](https://bugs.openjdk.java.net/browse/JMC-6364), the epic for tracking Improvements to the JFR Thread Graph. This RFR is also a follow-up to an RFC [[1]](http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html) that was posted to the jmc-dev list and incorporates the feedback that was brought up during discussion.

The new design and features was imagined in collaboration with our UX team, and the implementation has been a joint effort between myself and Jessye (@jessyec-s) - we had been originally collaborating on a fork of the old (unofficial) JMC GitHub repo. I've folded all the commits down into one because the older commits were merged using PRs with a similar format (e.g., `jmc/pull/23`) to this repo, so to avoid accidental noise (sorry about that) on other PRs I've just folded them away. If anyone is interested in the individual commits that got to this point, I've kept them around in the old repo [[2]](https://github.com/aptmac/jmc-old/commits/jfr-threads-page).

This PR aims to improve the usability and functionality of the JFR Threads Page by extending and enhancing existing classes. In an attempt to not clutter this PR with lots of images and explanatory text, I've created a gist [[3]](https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36) that provides information and images/gifs of the new components and intended functionality.

Gist: https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36

Summary of changes:
- Introduction of canvases to display the thread names (left) and timeline (bottom)
- Scrolled composites to house the text and chart canvases, for vertical scrolling of the chart area
- Timeline canvas (bottom) is draggable for panning the chart
- Current threads table has been re-located to a popup table
- New filter bar (top) which alters the chart view based on time ranges and desired visible activity lanes
- New display bar (right) which houses the zoom mechanics
- New zoom pan component for easily navigating the chart
- Introduction of a colour palette to increase contrast between neighbouring activity lanes
- Controls to change the height of the thread lanes
- updated and new uitests

Before:
![before](https://i.imgur.com/TNfGrtJ.png)

After:
![after](https://user-images.githubusercontent.com/10425301/71993902-dfd93200-3205-11ea-8249-cc50409a7a9f.png)

Let me know if you have any questions about the design & functionality.

[0] https://bugs.openjdk.java.net/browse/JMC-6364
[1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html
[2] https://github.com/aptmac/jmc-old/commits/jfr-threads-page
[3] https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36

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

Commits:
 - 5dc0e35f: re-ran mvn spotless:apply with the uitest profile active
 - 8b53fd7d: cleaned up formatting issues by running mvn spotless:apply
 - 157a98ab: 6364: Improvements to the Thread Graph

Changes: https://git.openjdk.java.net/jmc/pull/27/files
 Webrev: https://webrevs.openjdk.java.net/jmc/27/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6364
  Stats: 4087 lines in 43 files changed: 3943 ins; 38 del; 106 mod
  Patch: https://git.openjdk.java.net/jmc/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/27/head:pull/27

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

From jkang at openjdk.java.net  Fri Jan 10 15:13:12 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Fri, 10 Jan 2020 15:13:12 GMT
Subject: RFR: 6364: Improvements to the Thread Graph
In-Reply-To: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com>
References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com>
Message-ID: <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com>

On Wed, 8 Jan 2020 15:59:38 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> This patch addresses JMC-6364 [[0]](https://bugs.openjdk.java.net/browse/JMC-6364), the epic for tracking Improvements to the JFR Thread Graph. This RFR is also a follow-up to an RFC [[1]](http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html) that was posted to the jmc-dev list and incorporates the feedback that was brought up during discussion.
> 
> The new design and features was imagined in collaboration with our UX team, and the implementation has been a joint effort between myself and Jessye (@jessyec-s) - we had been originally collaborating on a fork of the old (unofficial) JMC GitHub repo. I've folded all the commits down into one because the older commits were merged using PRs with a similar format (e.g., `jmc/pull/23`) to this repo, so to avoid accidental noise (sorry about that) on other PRs I've just folded them away. If anyone is interested in the individual commits that got to this point, I've kept them around in the old repo [[2]](https://github.com/aptmac/jmc-old/commits/jfr-threads-page).
> 
> This PR aims to improve the usability and functionality of the JFR Threads Page by extending and enhancing existing classes. In an attempt to not clutter this PR with lots of images and explanatory text, I've created a gist [[3]](https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36) that provides information and images/gifs of the new components and intended functionality.
> 
> Gist: https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36
> 
> Summary of changes:
> - Introduction of canvases to display the thread names (left) and timeline (bottom)
> - Scrolled composites to house the text and chart canvases, for vertical scrolling of the chart area
> - Timeline canvas (bottom) is draggable for panning the chart
> - Current threads table has been re-located to a popup table
> - New filter bar (top) which alters the chart view based on time ranges and desired visible activity lanes
> - New display bar (right) which houses the zoom mechanics
> - New zoom pan component for easily navigating the chart
> - Introduction of a colour palette to increase contrast between neighbouring activity lanes
> - Controls to change the height of the thread lanes
> - updated and new uitests
> 
> Before:
> ![before](https://i.imgur.com/TNfGrtJ.png)
> 
> After:
> ![after](https://user-images.githubusercontent.com/10425301/71993902-dfd93200-3205-11ea-8249-cc50409a7a9f.png)
> 
> Let me know if you have any questions about the design & functionality.
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-6364
> [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html
> [2] https://github.com/aptmac/jmc-old/commits/jfr-threads-page
> [3] https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36

jcheck is requesting:

s/JMC-6364/6364

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

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

From aptmac at openjdk.java.net  Fri Jan 10 15:14:37 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Fri, 10 Jan 2020 15:14:37 GMT
Subject: RFR: 6364: Improvements to the Thread Graph
In-Reply-To: <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com>
References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com>
 <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com>
Message-ID: <RzkGUXMijABPraKoBm2yRnh7490ldPx8R1pVnLkZuQo=.49c6a560-d0bc-4870-8fc8-6b16c31a4edf@github.com>

On Fri, 10 Jan 2020 14:00:27 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> This patch addresses JMC-6364 [[0]](https://bugs.openjdk.java.net/browse/JMC-6364), the epic for tracking Improvements to the JFR Thread Graph. This RFR is also a follow-up to an RFC [[1]](http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html) that was posted to the jmc-dev list and incorporates the feedback that was brought up during discussion.
>> 
>> The new design and features was imagined in collaboration with our UX team, and the implementation has been a joint effort between myself and Jessye (@jessyec-s) - we had been originally collaborating on a fork of the old (unofficial) JMC GitHub repo. I've folded all the commits down into one because the older commits were merged using PRs with a similar format (e.g., `jmc/pull/23`) to this repo, so to avoid accidental noise (sorry about that) on other PRs I've just folded them away. If anyone is interested in the individual commits that got to this point, I've kept them around in the old repo [[2]](https://github.com/aptmac/jmc-old/commits/jfr-threads-page).
>> 
>> This PR aims to improve the usability and functionality of the JFR Threads Page by extending and enhancing existing classes. In an attempt to not clutter this PR with lots of images and explanatory text, I've created a gist [[3]](https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36) that provides information and images/gifs of the new components and intended functionality.
>> 
>> Gist: https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36
>> 
>> Summary of changes:
>> - Introduction of canvases to display the thread names (left) and timeline (bottom)
>> - Scrolled composites to house the text and chart canvases, for vertical scrolling of the chart area
>> - Timeline canvas (bottom) is draggable for panning the chart
>> - Current threads table has been re-located to a popup table
>> - New filter bar (top) which alters the chart view based on time ranges and desired visible activity lanes
>> - New display bar (right) which houses the zoom mechanics
>> - New zoom pan component for easily navigating the chart
>> - Introduction of a colour palette to increase contrast between neighbouring activity lanes
>> - Controls to change the height of the thread lanes
>> - updated and new uitests
>> 
>> Before:
>> ![before](https://i.imgur.com/TNfGrtJ.png)
>> 
>> After:
>> ![after](https://user-images.githubusercontent.com/10425301/71993902-dfd93200-3205-11ea-8249-cc50409a7a9f.png)
>> 
>> Let me know if you have any questions about the design & functionality.
>> 
>> [0] https://bugs.openjdk.java.net/browse/JMC-6364
>> [1] http://mail.openjdk.java.net/pipermail/jmc-dev/2019-October/001454.html
>> [2] https://github.com/aptmac/jmc-old/commits/jfr-threads-page
>> [3] https://gist.github.com/aptmac/61808c89bfcf1888080884fc8a61bd36
> 
> jcheck is requesting:
> 
> s/JMC-6364/6364

> jcheck is requesting:
> 
> s/JMC-6364/6364

Neat, thanks for the heads up. I changed the commit description and force pushed them back here, but it looks like once a PR has been made with the invalid ID format it's the PR name change that gets jcheck to pass. This automation is nice, the `mvn spotless:apply` was especially nice to have.

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

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

From hirt at openjdk.java.net  Fri Jan 10 15:59:55 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 10 Jan 2020 15:59:55 GMT
Subject: [Integrated] 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: <7befd1b1-afa5-4168-b0ac-144290ef89b7@openjdk.org>

Changeset: 67bc8668
Author:    Jessye Coleman-Shapiro <jescolem at redhat.com>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-10 15:59:20 +0000
URL:       https://git.openjdk.java.net/jmc/commit/67bc8668

6658: Remove unnecessary storing of pre-instrumented bytecode

Reviewed-by: hirt

! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/TransformRegistry.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Transformer.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/impl/DefaultTransformRegistry.java
! core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestSetTransforms.java

From hdafgard at openjdk.java.net  Fri Jan 10 16:06:07 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Fri, 10 Jan 2020 16:06:07 GMT
Subject: [Rev 01] RFR: 5721: Reintroduce the Percentage column
In-Reply-To: <48uTfzrJj_PisNEMpIkEKE_8BCpkw9v0cbbhBWGtVG4=.6b089079-91ef-4fd1-83d4-d4b55b4b7503@github.com>
References: <6xxEdn0pmrGCcBbu3ONWdZ3C06ED04eg3H_0OZQfxRw=.3e084af0-b37d-42d1-8457-b27dab8e6239@github.com>
 <48uTfzrJj_PisNEMpIkEKE_8BCpkw9v0cbbhBWGtVG4=.6b089079-91ef-4fd1-83d4-d4b55b4b7503@github.com>
Message-ID: <-7m3WlvSMIDYFnUhFXoy8emjkiVaMA5oMNvRjVkVaQw=.d0428330-91a1-4b2c-b403-62578103a718@github.com>

On Fri, 10 Jan 2020 16:06:07 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.
> 
> 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.



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

Marked as reviewed by hdafgard (Reviewer).

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

From kxu at openjdk.java.net  Fri Jan 10 18:33:58 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Fri, 10 Jan 2020 18:33:58 GMT
Subject: [Rev 04] 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: <u1SyhZsdLfAfFlDK-icI7ZuZ80w3WmzZ16HwFhb00Ho=.0329e5b2-bfe4-4056-ba41-1e99d0034663@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 a new target base due to a merge or a rebase.

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

Commits:
 - 4bb163b9: update TestSetTransforms with new changes
 - 04185668: Merge remote-tracking branch 'upstream/master' into agent-path-expression
 - c78ce947: lazy-load class with InspectionClassLoader
 - c35788f2: add javadoc
 - 9782c758: update license header year
 - 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.04
  Stats: 2403 lines in 24 files changed: 2306 ins; 1 del; 96 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  Fri Jan 10 20:02:33 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Fri, 10 Jan 2020 20:02:33 GMT
Subject: [Rev 01] RFR: 6659: Remove 'Showing X of Y events...' table
 message when not applicable
In-Reply-To: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
References: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
Message-ID: <nozXMEsWWnSfBdcyhTuaIK5f1c6ssieUZo_1HUJrBEE=.ffb8e25c-81d4-4b12-83d3-f3ed98aae751@github.com>

> This patch addresses the following issue: 
> 
> When a table made with an itemList has more rows than the set maximum that can be shown, it displays a message "Showing X of Y events..." in its last row. This message is not removed if a search is performed on the table that results in fewer then the maximum number of events being displayed. For example, this is seen in the Exceptions page in the Event Log table.
> ![table-example](https://user-images.githubusercontent.com/29706926/72159945-6cf9c380-338b-11ea-9f32-0fd3a6654709.png)
> 
> This patch makes the 'Showing X of Y events...'  table message disappear when less than the maximum number of events that can be displayed populate a table.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - fec30fd1: Move fix to base class

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/28/files
  - new: https://git.openjdk.java.net/jmc/pull/28/files/cd97aca3..fec30fd1

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

  Stats: 32 lines in 3 files changed: 27 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jmc/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/28/head:pull/28

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

From github.com+29706926+jessyec-s at openjdk.java.net  Fri Jan 10 20:09:05 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Fri, 10 Jan 2020 20:09:05 GMT
Subject: RFR: 6659: Remove 'Showing X of Y events...' table message when
 not applicable
In-Reply-To: <yQr4_3XK9cEQ37LqPfcK2aVz0Oa7WIPJTrMOcDI-vwQ=.811e2a0d-55b7-4f33-ba85-63c3102f5c7e@github.com>
References: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
 <yQr4_3XK9cEQ37LqPfcK2aVz0Oa7WIPJTrMOcDI-vwQ=.811e2a0d-55b7-4f33-ba85-63c3102f5c7e@github.com>
Message-ID: <eokB6HbA0bHILyNvsCbD6HppW84L_-qmQcxYM2Be_kk=.7194a05a-7566-4d83-8a21-260a98da4a73@github.com>

On Fri, 10 Jan 2020 15:12:18 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> This patch addresses the following issue: 
>> 
>> When a table made with an itemList has more rows than the set maximum that can be shown, it displays a message "Showing X of Y events..." in its last row. This message is not removed if a search is performed on the table that results in fewer then the maximum number of events being displayed. For example, this is seen in the Exceptions page in the Event Log table.
>> ![table-example](https://user-images.githubusercontent.com/29706926/72159945-6cf9c380-338b-11ea-9f32-0fd3a6654709.png)
>> 
>> This patch makes the 'Showing X of Y events...'  table message disappear when less than the maximum number of events that can be displayed populate a table.
> 
> Could the change be made to the user of this class? ExtraRowTableViewer could be used elsewhere for showing any kind of extra message not necessarily related to x of y events; maybe some text they always want to show. Then applying this logic wouldn't make sense.

In https://github.com/openjdk/jmc/pull/28/commits/fec30fd19289b4b2446f242723a6e7e7ee2b98d4 I have modified this patch to be implemented in the users of the ExtraRowTableViewer class instead of the class itself. This is keep the functionality of the ExtraRowTableViewer class more general as @jiekang mentioned.

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

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

From github.com+29706926+jessyec-s at openjdk.java.net  Fri Jan 10 20:23:17 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Fri, 10 Jan 2020 20:23:17 GMT
Subject: [Rev 02] RFR: 6659: Remove 'Showing X of Y events...' table
 message when not applicable
In-Reply-To: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
References: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
Message-ID: <XK9D7hzxau2v6eFEaonINPFFLBd8vNaNsDj-oMTmXRE=.f1bca746-1952-4113-ad0e-1f83cbc104f3@github.com>

> This patch addresses the following issue: 
> 
> When a table made with an itemList has more rows than the set maximum that can be shown, it displays a message "Showing X of Y events..." in its last row. This message is not removed if a search is performed on the table that results in fewer then the maximum number of events being displayed. For example, this is seen in the Exceptions page in the Event Log table.
> ![table-example](https://user-images.githubusercontent.com/29706926/72159945-6cf9c380-338b-11ea-9f32-0fd3a6654709.png)
> 
> This patch makes the 'Showing X of Y events...'  table message disappear when less than the maximum number of events that can be displayed populate a table.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - fa8bf0bd: Fix formatting errors

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/28/files
  - new: https://git.openjdk.java.net/jmc/pull/28/files/fec30fd1..fa8bf0bd

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

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

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

From mwengner at openjdk.java.net  Sun Jan 12 19:43:38 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Sun, 12 Jan 2020 19:43:38 GMT
Subject: RFR: 6549: Color flame chart based on package name
Message-ID: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>

implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
additionally:
1. fixed issue with displaying big data set in flameview
2. improved display speed

comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
conclusion: the flameview is always displayed

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

Commits:
 - c173c1cf: 6549: Color flame chart based on package name

Changes: https://git.openjdk.java.net/jmc/pull/29/files
 Webrev: https://webrevs.openjdk.java.net/jmc/29/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6549
  Stats: 162 lines in 5 files changed: 151 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jmc/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/29/head:pull/29

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

From hirt at openjdk.java.net  Mon Jan 13 00:08:04 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 00:08:04 GMT
Subject: RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <5IxfI_JttZ54ndevl-V8G_jdsX7t61wU3XW0OAgxNp0=.20357fab-8034-4f0f-b8d3-7eaded3f7f86@github.com>

On Sun, 12 Jan 2020 19:41:43 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js line 78:

> 77: const modulo = function(a, b){
> 78:     if (b === 0 || isNaN(a) || isNaN(b)) {
> 79:         return NaN;

This JavaScript is imported as is into the template right? No template replacements. I think you should be able to just use the modulo operator.

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

Changes requested by hirt (Lead).

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

From hirt at openjdk.java.net  Mon Jan 13 00:09:16 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 00:09:16 GMT
Subject: RFR: 6549: Color flame chart based on package name
In-Reply-To: <5IxfI_JttZ54ndevl-V8G_jdsX7t61wU3XW0OAgxNp0=.20357fab-8034-4f0f-b8d3-7eaded3f7f86@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <5IxfI_JttZ54ndevl-V8G_jdsX7t61wU3XW0OAgxNp0=.20357fab-8034-4f0f-b8d3-7eaded3f7f86@github.com>
Message-ID: <GH3_sT6dvuKucs05TSia-AZa6b2pdLTBekyMmcoESzE=.83026cc9-de0c-49a9-abd6-760ec01123f3@github.com>

On Mon, 13 Jan 2020 00:07:50 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
>> additionally:
>> 1. fixed issue with displaying big data set in flameview
>> 2. improved display speed
>> 
>> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
>> conclusion: the flameview is always displayed
> 
> 

Also formatting errors. Try mvn spotless:check to see your formatting errors. Usually mvn spotless:apply will fix them for you.

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

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

From hdafgard at openjdk.java.net  Mon Jan 13 12:19:53 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 13 Jan 2020 12:19:53 GMT
Subject: [Integrated] 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: <a1ce8e3a-6f0c-43ff-a8f0-4b21f7b10108@openjdk.org>

Changeset: 0f08461f
Author:    Dmitry Popov <dmitry.popov at macys.com>
Committer: Henrik Dafg?rd <hdafgard at openjdk.org>
Date:      2020-01-13 12:19:09 +0000
URL:       https://git.openjdk.java.net/jmc/commit/0f08461f

5721: Reintroduce the Percentage column

Reviewed-by: hdafgard

! application/l10n/org.openjdk.jmc.flightrecorder.ui.ja/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages_ja.properties
! application/l10n/org.openjdk.jmc.flightrecorder.ui.zh_CN/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages_zh_CN.properties
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties

From mwengner at openjdk.java.net  Mon Jan 13 12:27:53 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 12:27:53 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Added commits:
 - 4d6f5838: 6549: Color flame chart based on package name
 - b051b390: Merge branch 'master' of https://github.com/openjdk/jmc into feature/JMC_6549_color_flame_chart_based_packagename
 - 67bc8668: 6658: Remove unnecessary storing of pre-instrumented bytecode

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/c173c1cf..4d6f5838

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

  Stats: 186 lines in 8 files changed: 77 ins; 71 del; 38 mod
  Patch: https://git.openjdk.java.net/jmc/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/29/head:pull/29

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

From mwengner at openjdk.java.net  Mon Jan 13 12:32:23 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 12:32:23 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <5IxfI_JttZ54ndevl-V8G_jdsX7t61wU3XW0OAgxNp0=.20357fab-8034-4f0f-b8d3-7eaded3f7f86@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <5IxfI_JttZ54ndevl-V8G_jdsX7t61wU3XW0OAgxNp0=.20357fab-8034-4f0f-b8d3-7eaded3f7f86@github.com>
Message-ID: <7eq_jYs_FFhhtdMLJk6rslTI_XeqqA4f_QC9SlbIMpA=.cfa564cc-d189-455e-82ef-d8ca6fc20a1b@github.com>

On Mon, 13 Jan 2020 00:07:20 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
> 
> application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js line 78:
> 
>> 77: const modulo = function(a, b){
>> 78:     if (b === 0 || isNaN(a) || isNaN(b)) {
>> 79:         return NaN;
> 
> This JavaScript is imported as is into the template right? No template replacements. I think you should be able to just use the modulo operator.

corrected and tested

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

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

From hirt at openjdk.java.net  Mon Jan 13 13:41:23 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 13:41:23 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
Message-ID: <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>

On Mon, 13 Jan 2020 13:41:21 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
>> additionally:
>> 1. fixed issue with displaying big data set in flameview
>> 2. improved display speed
>> 
>> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
>> conclusion: the flameview is always displayed
> 
> The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js line 39:

> 38:             const packageMarkerSelected = getPackageMarker(packageNameStrip);
> 39: 
> 40: 			const packageNameStripHash = packageNameStrip.hashCode();

Formatting looks funny here.

application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js line 92:

> 91: 	return d.data.n + "\u003Cbr\u002F\u003Epackage: " + d.data.p + "\u003Cbr\u002F\u003Esamples: " + d.data.v;
> 92: };

Perhaps add newline here.

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

Changes requested by hirt (Lead).

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

From kxu at openjdk.java.net  Mon Jan 13 16:35:02 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Mon, 13 Jan 2020 16:35:02 GMT
Subject: [Rev 05] 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: <VKgo474U0GB8w50opIHooWYnkqAL7WbCBQXnLa9SiLE=.ab01ced1-3b8a-425e-bfd6-fb36c084a1f7@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:
 - f7c3e52e: empty commit to force re-trigger github actions

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/20/files
  - new: https://git.openjdk.java.net/jmc/pull/20/files/4bb163b9..f7c3e52e

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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  Mon Jan 13 16:52:28 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Mon, 13 Jan 2020 16:52:28 GMT
Subject: [Rev 06] 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: <55U3P5dsnqhOUnqkYe7DCIKyCTkDSmB-KCOAP278eyc=.4bc8eb23-d9a4-4ae0-9678-ea36c22c014f@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!

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:
 - 09abbb99: remove unused function

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/20/files
  - new: https://git.openjdk.java.net/jmc/pull/20/files/f7c3e52e..09abbb99

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

  Stats: 24 lines in 1 file changed: 0 ins; 24 del; 0 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 mwengner at openjdk.java.net  Mon Jan 13 18:16:35 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 18:16:35 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
Message-ID: <yW0kpNXxF1qJQZu_LbnZ0aj5uX9t_TydrstD-GEi_Y4=.13efc49c-85e8-4efc-a1a7-9271c60c5a96@github.com>

On Mon, 13 Jan 2020 13:39:58 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
> 
> application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js line 39:
> 
>> 38:             const packageMarkerSelected = getPackageMarker(packageNameStrip);
>> 39: 
>> 40: 			const packageNameStripHash = packageNameStrip.hashCode();
> 
> Formatting looks funny here.

I've not spot anything unusual.  IDE gives me such formatting by default

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

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

From hirt at openjdk.java.net  Mon Jan 13 18:17:56 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 18:17:56 GMT
Subject: [Rev 02] RFR: 6659: Remove 'Showing X of Y events...' table
 message when not applicable
In-Reply-To: <XK9D7hzxau2v6eFEaonINPFFLBd8vNaNsDj-oMTmXRE=.f1bca746-1952-4113-ad0e-1f83cbc104f3@github.com>
References: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
 <XK9D7hzxau2v6eFEaonINPFFLBd8vNaNsDj-oMTmXRE=.f1bca746-1952-4113-ad0e-1f83cbc104f3@github.com>
Message-ID: <mGWK7YnU6ozldynj3VQg6Kn9sFd8v4b2XGI68JtBC8c=.081ee374-23de-49fe-a77b-99a68e200a78@github.com>

On Mon, 13 Jan 2020 18:17:56 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

>> This patch addresses the following issue: 
>> 
>> When a table made with an itemList has more rows than the set maximum that can be shown, it displays a message "Showing X of Y events..." in its last row. This message is not removed if a search is performed on the table that results in fewer then the maximum number of events being displayed. For example, this is seen in the Exceptions page in the Event Log table.
>> ![table-example](https://user-images.githubusercontent.com/29706926/72159945-6cf9c380-338b-11ea-9f32-0fd3a6654709.png)
>> 
>> This patch makes the 'Showing X of Y events...'  table message disappear when less than the maximum number of events that can be displayed populate a table.
> 
> The pull request has been updated with 1 additional commit.



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

Marked as reviewed by hirt (Lead).

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

From hirt at openjdk.java.net  Mon Jan 13 18:23:46 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 18:23:46 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <yW0kpNXxF1qJQZu_LbnZ0aj5uX9t_TydrstD-GEi_Y4=.13efc49c-85e8-4efc-a1a7-9271c60c5a96@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
 <yW0kpNXxF1qJQZu_LbnZ0aj5uX9t_TydrstD-GEi_Y4=.13efc49c-85e8-4efc-a1a7-9271c60c5a96@github.com>
Message-ID: <m_ysV7laPnSLr5g3N_QBTvpwomOz4vVUyEuBjlf55WI=.4688a17b-8f72-4f93-be2c-947440e60908@github.com>

On Mon, 13 Jan 2020 18:16:29 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js line 39:
>> 
>>> 38:             const packageMarkerSelected = getPackageMarker(packageNameStrip);
>>> 39: 
>>> 40: 			const packageNameStripHash = packageNameStrip.hashCode();
>> 
>> Formatting looks funny here.
> 
> I've not spot anything unusual.  IDE gives me such formatting by default

Indentation level looks like it is different for packageMarkerSelected and packageNameStripHash, but it should not be. I would also remove the new line.

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

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

From mwengner at openjdk.java.net  Mon Jan 13 19:00:16 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 19:00:16 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <m_ysV7laPnSLr5g3N_QBTvpwomOz4vVUyEuBjlf55WI=.4688a17b-8f72-4f93-be2c-947440e60908@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
 <yW0kpNXxF1qJQZu_LbnZ0aj5uX9t_TydrstD-GEi_Y4=.13efc49c-85e8-4efc-a1a7-9271c60c5a96@github.com>
 <m_ysV7laPnSLr5g3N_QBTvpwomOz4vVUyEuBjlf55WI=.4688a17b-8f72-4f93-be2c-947440e60908@github.com>
Message-ID: <W7yxwsIctiBdKkMtawEpUwtRdSpzLyDmvS1uECdg7AY=.58c49502-9c58-447a-a02c-f91114900adc@github.com>

On Mon, 13 Jan 2020 18:23:37 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> I've not spot anything unusual.  IDE gives me such formatting by default
> 
> Indentation level looks like it is different for packageMarkerSelected and packageNameStripHash, but it should not be. I would also remove the new line.

corrected

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

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

From hdafgard at openjdk.java.net  Mon Jan 13 19:11:30 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 13 Jan 2020 19:11:30 GMT
Subject: RFR: 6671: Eagerly convert end time to the same unit as start time
Message-ID: <U3ncavLxANITX3MAN76bjVpzHpV_Zdsx0PVU7DEFAEE=.dcc61762-ded3-492c-9a6f-3c30332d9051@github.com>

Set event end time to use the same unit as start time when accessing the values, rather than when comparing between them.

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

Commits:
 - f27518aa: Eagerly convert end time to the same unit as start time

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

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

From hirt at openjdk.java.net  Mon Jan 13 19:14:58 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 19:14:58 GMT
Subject: RFR: 6671: Eagerly convert end time to the same unit as start time
In-Reply-To: <U3ncavLxANITX3MAN76bjVpzHpV_Zdsx0PVU7DEFAEE=.dcc61762-ded3-492c-9a6f-3c30332d9051@github.com>
References: <U3ncavLxANITX3MAN76bjVpzHpV_Zdsx0PVU7DEFAEE=.dcc61762-ded3-492c-9a6f-3c30332d9051@github.com>
Message-ID: <6hBE9MdbKgTfJNp4if9Blhcj7-SzEAdqRlkVo5v5Bxw=.3cb9be46-d3a8-45d5-9c05-1b0158177fdd@github.com>

On Mon, 13 Jan 2020 19:10:11 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

> Set event end time to use the same unit as start time when accessing the values, rather than when comparing between them.



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

Marked as reviewed by hirt (Lead).

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

From mwengner at openjdk.java.net  Mon Jan 13 19:36:54 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 19:36:54 GMT
Subject: [Rev 02] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <8hrSWZVfHJOy7BNm0l76vn_jMGa5astJc9LKgYUmcfo=.de79fd8a-70ab-4d1c-b093-a6d2f1f2b857@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with 1 additional commit.

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

Added commits:
 - daf8a309: 6549: Color flame chart based on package name

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/4d6f5838..daf8a309

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

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

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

From mwengner at openjdk.java.net  Mon Jan 13 19:42:09 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 19:42:09 GMT
Subject: [Rev 03] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <KNYDKnSXFebExrivVjr7pM3DuUmIvKGj6J9ugubPqZw=.a7dc6266-1e08-4950-a2cc-bc95fe363e3e@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Added commits:
 - 9970ca65: Merge branch 'master' of https://github.com/openjdk/jmc into feature/JMC_6549_color_flame_chart_based_packagename
 - 0f08461f: 5721: Reintroduce the Percentage column

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/daf8a309..9970ca65

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

  Stats: 23 lines in 5 files changed: 16 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jmc/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/29/head:pull/29

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

From mwengner at openjdk.java.net  Mon Jan 13 19:48:11 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 19:48:11 GMT
Subject: [Rev 04] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <dq8XqERwnSHWdu1y-E7zsbyXKqIOmOQFoPGtNKiKRGQ=.a3f8941c-4b35-4801-a803-2ff6ec968298@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 59afc3d9: 6549: Color flame chart based on package name

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/9970ca65..59afc3d9

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

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

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

From mwengner at openjdk.java.net  Mon Jan 13 19:58:59 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 19:58:59 GMT
Subject: [Rev 05] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <c3cq-F97v1wW5rihtP9NL8YxPMm_1Qqka1MCz5fdvJ0=.32ee6ec4-b9b4-4678-a378-4ee10afe52b3@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with 1 additional commit.

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

Added commits:
 - be283068: 6549: Color flame chart based on package name

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/59afc3d9..be283068

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

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

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

From hirt at openjdk.java.net  Mon Jan 13 20:34:22 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 20:34:22 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
Message-ID: <b63Nkfya478VzlP_sAdDv1yT__0JlsvxMZze9bN0BvM=.ec620323-48a7-4d19-8a53-cb7e07e28e9f@github.com>

On Mon, 13 Jan 2020 13:41:02 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
> 
> 

Still a few confusing colorings for JDK base packages. We want java.*, sun.*, com.sun.* to be grey. (Come to think of it, we probably want to add jdk.* classes to the grey ones too.) And we've said that we want the really core public APIs to be lighter grey and the most internal ones be a darker grey. To me, that means that java.lang should probably be a smidge lighter than java.util. And sun.* be darker than com.sun. We may want to set the colors for these packages, and some other popular ones, like java.io, java.nio ourselves. Or simply have one lighter grey for java.*, one a little bit darker for com.sun.* and jdk.*, and a dark one for sun.*. None with any other hint of color in them (equal amounts of R, G and B).

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

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

From hirt at openjdk.java.net  Mon Jan 13 20:39:36 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 20:39:36 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <b63Nkfya478VzlP_sAdDv1yT__0JlsvxMZze9bN0BvM=.ec620323-48a7-4d19-8a53-cb7e07e28e9f@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
 <b63Nkfya478VzlP_sAdDv1yT__0JlsvxMZze9bN0BvM=.ec620323-48a7-4d19-8a53-cb7e07e28e9f@github.com>
Message-ID: <SzvgEyiP7gsqPVDqQ7deuwgeQqDPgQewedm_TVegm34=.61421d5b-ece7-4721-b865-0801ac4eeaf3@github.com>

On Mon, 13 Jan 2020 20:33:43 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>>
> 
> Still a few confusing colorings for JDK base packages. We want java.*, sun.*, com.sun.* to be grey. (Come to think of it, we probably want to add jdk.* classes to the grey ones too.) And we've said that we want the really core public APIs to be lighter grey and the most internal ones be a darker grey. To me, that means that java.lang should probably be a smidge lighter than java.util. And sun.* be darker than com.sun. We may want to set the colors for these packages, and some other popular ones, like java.io, java.nio ourselves. Or simply have one lighter grey for java.*, one a little bit darker for com.sun.* and jdk.*, and a dark one for sun.*. None with any other hint of color in them (equal amounts of R, G and B).

I think the last (easiest) alternative is probably quite okay since:
1. You typically care less about the JDK classes (you're normally not interested in changing them).
2. The fact that package transitions in JDK classes are less obvious with the easy pure grey coloring scheme is outweighed by reliably being able to identify them as JDK classes (if it's a pure grey, it's JDK).

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

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

From hirt at openjdk.java.net  Mon Jan 13 20:45:51 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 13 Jan 2020 20:45:51 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <SzvgEyiP7gsqPVDqQ7deuwgeQqDPgQewedm_TVegm34=.61421d5b-ece7-4721-b865-0801ac4eeaf3@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
 <b63Nkfya478VzlP_sAdDv1yT__0JlsvxMZze9bN0BvM=.ec620323-48a7-4d19-8a53-cb7e07e28e9f@github.com>
 <SzvgEyiP7gsqPVDqQ7deuwgeQqDPgQewedm_TVegm34=.61421d5b-ece7-4721-b865-0801ac4eeaf3@github.com>
Message-ID: <Br4FhjZ-TXZmxq-p9qx_My9cIpj4ePOfoF70Z6IMWSQ=.7cfb22c9-65e7-43f5-9a5c-4a234f493bae@github.com>

On Mon, 13 Jan 2020 20:39:24 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Still a few confusing colorings for JDK base packages. We want java.*, sun.*, com.sun.* to be grey. (Come to think of it, we probably want to add jdk.* classes to the grey ones too.) And we've said that we want the really core public APIs to be lighter grey and the most internal ones be a darker grey. To me, that means that java.lang should probably be a smidge lighter than java.util. And sun.* be darker than com.sun. We may want to set the colors for these packages, and some other popular ones, like java.io, java.nio ourselves. Or simply have one lighter grey for java.*, one a little bit darker for com.sun.* and jdk.*, and a dark one for sun.*. None with any other hint of color in them (equal amounts of R, G and B).
> 
> I think the last (easiest) alternative is probably quite okay since:
> 1. You typically care less about the JDK classes (you're normally not interested in changing them).
> 2. The fact that package transitions in JDK classes are less obvious with the easy pure grey coloring scheme is outweighed by reliably being able to identify them as JDK classes (if it's a pure grey, it's JDK).

So, in other words, these simple semantics:
1. Is it a standard public Java JDK API -> light grey.
2. Is it a public non-standard Java JDK API -> medium grey.
3. Is it an internal Java JDK API -> dark grey.

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

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

From hdafgard at openjdk.java.net  Mon Jan 13 21:34:50 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 13 Jan 2020 21:34:50 GMT
Subject: [Integrated] RFR: 6671: Eagerly convert end time to the same unit
 as start time
In-Reply-To: <U3ncavLxANITX3MAN76bjVpzHpV_Zdsx0PVU7DEFAEE=.dcc61762-ded3-492c-9a6f-3c30332d9051@github.com>
References: <U3ncavLxANITX3MAN76bjVpzHpV_Zdsx0PVU7DEFAEE=.dcc61762-ded3-492c-9a6f-3c30332d9051@github.com>
Message-ID: <91bbe06d-bca9-4e66-8605-b682bb59042a@openjdk.org>

Changeset: bfb23cde
Author:    Henrik Dafg?rd <hdafgard at openjdk.org>
Date:      2020-01-13 21:33:40 +0000
URL:       https://git.openjdk.java.net/jmc/commit/bfb23cde

6671: Eagerly convert end time to the same unit as start time

Reviewed-by: hirt

! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/util/DisjointBuilder.java

From mwengner at openjdk.java.net  Mon Jan 13 22:13:31 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 22:13:31 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Br4FhjZ-TXZmxq-p9qx_My9cIpj4ePOfoF70Z6IMWSQ=.7cfb22c9-65e7-43f5-9a5c-4a234f493bae@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
 <b63Nkfya478VzlP_sAdDv1yT__0JlsvxMZze9bN0BvM=.ec620323-48a7-4d19-8a53-cb7e07e28e9f@github.com>
 <SzvgEyiP7gsqPVDqQ7deuwgeQqDPgQewedm_TVegm34=.61421d5b-ece7-4721-b865-0801ac4eeaf3@github.com>
 <Br4FhjZ-TXZmxq-p9qx_My9cIpj4ePOfoF70Z6IMWSQ=.7cfb22c9-65e7-43f5-9a5c-4a234f493bae@github.com>
Message-ID: <brxsmp8nbK_66pcEqQ-7p3D0-anQo6lH3dXq0vlw4wo=.d56a830b-78fa-4c49-80f5-51123d525caa@github.com>

On Mon, 13 Jan 2020 20:45:20 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> I think the last (easiest) alternative is probably quite okay since:
>> 1. You typically care less about the JDK classes (you're normally not interested in changing them).
>> 2. The fact that package transitions in JDK classes are less obvious with the easy pure grey coloring scheme is outweighed by reliably being able to identify them as JDK classes (if it's a pure grey, it's JDK).
> 
> So, in other words, these simple semantics:
> 1. Is it a standard public Java JDK API -> light grey.
> 2. Is it a public non-standard Java JDK API -> medium grey.
> 3. Is it an internal Java JDK API -> dark grey.

I thing that such coloring makes things simpler. I've modified the colors:

1. standard public (java.*) -> light grey
2. public non-standard (com.sun.*, jdk.*) -> dark grey
3. internal (sun.*) -> grey 
scale according to the semantic is from Lighter to Darker (1,2,3)

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

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

From mwengner at openjdk.java.net  Mon Jan 13 22:17:06 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 13 Jan 2020 22:17:06 GMT
Subject: [Rev 06] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <tw0OTpF5KrrnlF59ZtskHp7U3-ZYV1guzbHqK_QH4Cg=.ba9c5c10-66f4-4e3f-bedf-90291e441d03@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 53b90b12: 6549: Color flame chart based on package name

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/be283068..53b90b12

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

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

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

From mwengner at openjdk.java.net  Tue Jan 14 07:13:57 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Tue, 14 Jan 2020 07:13:57 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <brxsmp8nbK_66pcEqQ-7p3D0-anQo6lH3dXq0vlw4wo=.d56a830b-78fa-4c49-80f5-51123d525caa@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
 <b63Nkfya478VzlP_sAdDv1yT__0JlsvxMZze9bN0BvM=.ec620323-48a7-4d19-8a53-cb7e07e28e9f@github.com>
 <SzvgEyiP7gsqPVDqQ7deuwgeQqDPgQewedm_TVegm34=.61421d5b-ece7-4721-b865-0801ac4eeaf3@github.com>
 <Br4FhjZ-TXZmxq-p9qx_My9cIpj4ePOfoF70Z6IMWSQ=.7cfb22c9-65e7-43f5-9a5c-4a234f493bae@github.com>
 <brxsmp8nbK_66pcEqQ-7p3D0-anQo6lH3dXq0vlw4wo=.d56a830b-78fa-4c49-80f5-51123d525caa@github.com>
Message-ID: <62RUPmGpB1Bwg13hAjgVSXDhsc1sMUv9-u_vBC15-pw=.9556f3bf-50fb-4544-8285-11cdadc74219@github.com>

On Mon, 13 Jan 2020 22:08:19 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> So, in other words, these simple semantics:
>> 1. Is it a standard public Java JDK API -> light grey.
>> 2. Is it a public non-standard Java JDK API -> medium grey.
>> 3. Is it an internal Java JDK API -> dark grey.
> 
> I thing that such coloring makes things simpler. I've modified the colors:
> 
> 1. standard public (java.*) -> light grey
> 2. public non-standard (com.sun.*, jdk.*) -> dark grey
> 3. internal (sun.*) -> grey 
> scale according to the semantic is from Lighter to Darker (1,2,3)

looks like the job has been terminated for windows.

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

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

From hirt at openjdk.java.net  Tue Jan 14 12:14:31 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 14 Jan 2020 12:14:31 GMT
Subject: [Rev 06] 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: <7JKjsSro-czIrvqb8I28JBVLdpGtcHW-OMa2aRmKgPw=.f8be3836-13c5-4a8d-a687-2b9ea12e3909@github.com>

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

>> 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.
> 
> First quick review. Will take a closer look as soon as I can find some more time.

All copyrights need to have 2020 added now, like so:

 * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.

Happy New Year! :)

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

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

From hirt at openjdk.java.net  Tue Jan 14 12:16:53 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 14 Jan 2020 12:16:53 GMT
Subject: [Integrated] RFR: 6659: Remove 'Showing X of Y events...' table
 message when not applicable
In-Reply-To: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
References: <_OYHr-aREyM4qKoWpexU3IMTNCvrgwOBNUdMopW0dvk=.6cb7ce47-7324-4955-b800-bf1c6a53b577@github.com>
Message-ID: <a793e77a-9260-4485-9dff-b858dd4091bc@openjdk.org>

Changeset: 055db4fc
Author:    Jessye Coleman-Shapiro <jescolem at redhat.com>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-14 12:16:15 +0000
URL:       https://git.openjdk.java.net/jmc/commit/055db4fc

6659: Remove 'Showing X of Y events...' table message when not applicable

Reviewed-by: hirt

! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ExtraRowTableViewer.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/FilterComponent.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/common/ItemList.java

From hirt at openjdk.java.net  Tue Jan 14 12:19:43 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 14 Jan 2020 12:19:43 GMT
Subject: [Rev 01] RFR: 6549: Color flame chart based on package name
In-Reply-To: <62RUPmGpB1Bwg13hAjgVSXDhsc1sMUv9-u_vBC15-pw=.9556f3bf-50fb-4544-8285-11cdadc74219@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <9-KKCnb1k5TSbULJa9u5Dk6OWdHDHrIfBgjiUB5a0xE=.7e394362-66cf-4080-8d38-6069b9a94ff6@github.com>
 <A0J6tYdp9pvyK4i76mhgSE1Cp0n8VcMvwpmd98WxUlQ=.cc9262e5-e3db-47ec-8e1e-6afce75c2f80@github.com>
 <b63Nkfya478VzlP_sAdDv1yT__0JlsvxMZze9bN0BvM=.ec620323-48a7-4d19-8a53-cb7e07e28e9f@github.com>
 <SzvgEyiP7gsqPVDqQ7deuwgeQqDPgQewedm_TVegm34=.61421d5b-ece7-4721-b865-0801ac4eeaf3@github.com>
 <Br4FhjZ-TXZmxq-p9qx_My9cIpj4ePOfoF70Z6IMWSQ=.7cfb22c9-65e7-43f5-9a5c-4a234f493bae@github.com>
 <brxsmp8nbK_66pcEqQ-7p3D0-anQo6lH3dXq0vlw4wo=.d56a830b-78fa-4c49-80f5-51123d525caa@github.com>
 <62RUPmGpB1Bwg13hAjgVSXDhsc1sMUv9-u_vBC15-pw=.9556f3bf-50fb-4544-8285-11cdadc74219@github.com>
Message-ID: <temRfveXzZrU6QRKTFWHtSiFInahWOwV7eDzbNY-yMw=.e4742576-f993-45a5-a7cf-4281e8c62cb0@github.com>

On Tue, 14 Jan 2020 07:13:42 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> I thing that such coloring makes things simpler. I've modified the colors:
>> 
>> 1. standard public (java.*) -> light grey
>> 2. public non-standard (com.sun.*, jdk.*) -> dark grey
>> 3. internal (sun.*) -> grey 
>> scale according to the semantic is from Lighter to Darker (1,2,3)
> 
> looks like the job has been terminated for windows.

Copyrights need to be updated, e.g.:

 * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
 * Copyright (c) 2019, 2020, Datadog, Inc. All rights reserved.

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

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

From hirt at openjdk.java.net  Tue Jan 14 12:20:08 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 14 Jan 2020 12:20:08 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <bTmQavGW9K4mLHe22ziWHR6KmCiXFPPgBmYGGFbbVIc=.afc84d2f-907c-470c-9d2c-e7bda6bd75cc@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>
 <bTmQavGW9K4mLHe22ziWHR6KmCiXFPPgBmYGGFbbVIc=.afc84d2f-907c-470c-9d2c-e7bda6bd75cc@github.com>
Message-ID: <WL7Atk9jWavX3ivK-1_mIl_L-VnozKPqwT0c-oxM2Ww=.fee97f45-b4a9-4c71-9b3c-662c560026da@github.com>

On Fri, 20 Dec 2019 11:02:57 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

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

Note that copyrights need to be updated.

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

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

From jkang at openjdk.java.net  Tue Jan 14 16:10:27 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Tue, 14 Jan 2020 16:10:27 GMT
Subject: [Rev 05] 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: <GKBrjxiW3MvgYV85SaVnT3xSBeHmHUBoG21ZUu_mYp0=.396c9f45-e720-43b1-8190-f4b24a4a9a90@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:
 - b118b2a3: Update licenses for year 2020

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

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

  Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 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 kxu at openjdk.java.net  Tue Jan 14 17:18:05 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Tue, 14 Jan 2020 17:18:05 GMT
Subject: [Rev 07] 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: <Sg5LviStMEwBlbGKBxjRlA3cAUmCcD7BTxus-ms9iiI=.14ff80ec-0f83-4c2a-9483-f356aba58b1f@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:
 - 10e48d58: update license header year values

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/20/files
  - new: https://git.openjdk.java.net/jmc/pull/20/files/09abbb99..10e48d58

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

  Stats: 25 lines in 24 files changed: 0 ins; 0 del; 25 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 mwengner at openjdk.java.net  Tue Jan 14 18:45:03 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Tue, 14 Jan 2020 18:45:03 GMT
Subject: [Rev 07] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <-0xlnpkvkaOsfUnw6NKM5oLG2Q_8ZmYsY4__rB0WCUY=.7a64cd24-f5a7-4a4f-9040-d4a32b98917d@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 738bfe8e: 6549: Color flame chart based on package name

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/53b90b12..738bfe8e

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

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

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

From hdafgard at openjdk.java.net  Tue Jan 14 18:54:34 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Tue, 14 Jan 2020 18:54:34 GMT
Subject: RFR: 6674: Optimize finding of first start time and first & last end
 times
Message-ID: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>

This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.

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

Commits:
 - f6af24e4: Update RulesToolkit.java
 - 56a760ef: Optimize sliding window and other start time aggregations

Changes: https://git.openjdk.java.net/jmc/pull/31/files
 Webrev: https://webrevs.openjdk.java.net/jmc/31/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6674
  Stats: 123 lines in 10 files changed: 93 ins; 9 del; 21 mod
  Patch: https://git.openjdk.java.net/jmc/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/31/head:pull/31

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

From hdafgard at openjdk.java.net  Tue Jan 14 18:59:48 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Tue, 14 Jan 2020 18:59:48 GMT
Subject: [Rev 01] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
Message-ID: <2mCEyGGcGKiGWvQ_YJ75R2N4-tbKYSMQXRP1LveEuc0=.629a1822-ec93-426e-98e4-bc477c1b4aa5@github.com>

> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
> 
> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 25fb5af9: Update RulesToolkit.java

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/31/files
  - new: https://git.openjdk.java.net/jmc/pull/31/files/f6af24e4..25fb5af9

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

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

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

From hirt at openjdk.java.net  Tue Jan 14 19:32:28 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 14 Jan 2020 19:32:28 GMT
Subject: RFR: 6674: Optimize finding of first start time and first & last
 end times
In-Reply-To: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
Message-ID: <mh1xfRByzbMOsetykLcMrj-pF0C_9ATQXz_SeAOfD3U=.05bd349e-e10f-481f-8c7e-43fc1f758a90@github.com>

On Tue, 14 Jan 2020 18:53:19 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
> 
> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.

Careful here. They are not sorted on start and end time both, and events are not guaranteed (except that we recommend that this is the case for the events of a particular event type, if at all possible) to be non-overlapping.

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

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

From mwengner at openjdk.java.net  Tue Jan 14 22:35:22 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Tue, 14 Jan 2020 22:35:22 GMT
Subject: [Rev 08] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <J7wwsCMH-UsPQwd4acad-S-xeqyYw6Ik6EDxJFFNZ34=.a2e2b792-a53a-4eb8-9ff5-a93814677a05@github.com>

> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
> additionally:
> 1. fixed issue with displaying big data set in flameview
> 2. improved display speed
> 
> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
> conclusion: the flameview is always displayed

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 6180dd37: 6549: Color flame chart based on package name

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/29/files
  - new: https://git.openjdk.java.net/jmc/pull/29/files/738bfe8e..6180dd37

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/29/webrev.08
 - incr: https://webrevs.openjdk.java.net/jmc/29/webrev.07-08

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

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

From hirt at openjdk.java.net  Tue Jan 14 23:12:26 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 14 Jan 2020 23:12:26 GMT
Subject: [Rev 04] RFR: 6549: Color flame chart based on package name
In-Reply-To: <dq8XqERwnSHWdu1y-E7zsbyXKqIOmOQFoPGtNKiKRGQ=.a3f8941c-4b35-4801-a803-2ff6ec968298@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
 <dq8XqERwnSHWdu1y-E7zsbyXKqIOmOQFoPGtNKiKRGQ=.a3f8941c-4b35-4801-a803-2ff6ec968298@github.com>
Message-ID: <b6xwFfYecyBfh8xOPFHHjQw_GJgb6vAGNOySB2DkkCY=.78166362-629e-49bd-9b9e-46ae9cb30cad@github.com>

On Tue, 14 Jan 2020 23:12:25 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> implemented ticket : https://bugs.openjdk.java.net/browse/JMC-6549
>> additionally:
>> 1. fixed issue with displaying big data set in flameview
>> 2. improved display speed
>> 
>> comments:  cell coloring algorithm is based on packageName hash with defined depth to avoid collisions and guarantee same stripPackageName color.
>> conclusion: the flameview is always displayed
> 
> The pull request has been updated with 1 additional commit.

application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js line 42:

> 41:         if (packageSelectedColor === undefined) {
> 42:         	const packageMarkerSelected = getPackageMarker(packageNameStrip);
> 43:         	const packageNameStripHash = packageNameStrip.hashCode();

These lines are mixing space and tabs for indentation. The rest of the file is using spaces for indentation. I'd go with tabs throughout the file, since that is used for the rest of the project.

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

Marked as reviewed by hirt (Lead).

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

From github.com+29706926+jessyec-s at openjdk.java.net  Wed Jan 15 15:09:30 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Wed, 15 Jan 2020 15:09:30 GMT
Subject: RFR: 6660: Make JMX API not return classes
Message-ID: <L9r2YmZ9_L0culT1bG0xqzJnOMA-rnv00sGXFQE-nxY=.b291ffd8-e423-4fbc-abd2-ee332b5b74ac@github.com>

This patch modifies the JMX API so that functions return void instead of class arrays.

The name of the function setTransforms was also changed to defineEventProbes as a result of this change because an mbean function whose name begins with "set", has one parameter and a return type of void, gets registered as a setter not an operation.

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

Commits:
 - e935d42d: Make JMX API not return classes

Changes: https://git.openjdk.java.net/jmc/pull/32/files
 Webrev: https://webrevs.openjdk.java.net/jmc/32/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6660
  Stats: 356 lines in 6 files changed: 174 ins; 176 del; 6 mod
  Patch: https://git.openjdk.java.net/jmc/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/32/head:pull/32

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

From hdafgard at openjdk.java.net  Wed Jan 15 17:03:56 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 15 Jan 2020 17:03:56 GMT
Subject: RFR: 6674: Optimize finding of first start time and first & last
 end times
In-Reply-To: <mh1xfRByzbMOsetykLcMrj-pF0C_9ATQXz_SeAOfD3U=.05bd349e-e10f-481f-8c7e-43fc1f758a90@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
 <mh1xfRByzbMOsetykLcMrj-pF0C_9ATQXz_SeAOfD3U=.05bd349e-e10f-481f-8c7e-43fc1f758a90@github.com>
Message-ID: <SmP6mAUO6hOcKma0o4SGOFDROprtiXV3y61gyhuBVIo=.8834cfcd-3317-4b89-812a-1ae45c5d6f69@github.com>

On Tue, 14 Jan 2020 19:31:59 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
>> 
>> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.
> 
> Careful here. They are not sorted on start and end time both, and events are not guaranteed (except that we recommend that this is the case for the events of a particular event type, if at all possible) to be non-overlapping.

JMC parser currently guarantees that IItemCollection events are retrieved in sorted, disjoint, lanes. Each event is iterated over in the time that it was emitted, and if there is an overlap then it will be in another lane. This is why we iterate through the IItemCollection and then through the IItemIterable, even if the IItemCollection is filtered to only contain one type.

There is still the problem that this relies on the implicit assumption that these lanes are sorted in this fashion, but since we're currently performing a computationally intensive sorting during the parsing we should think about exploiting that fact.

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

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

From hdafgard at openjdk.java.net  Wed Jan 15 17:14:02 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 15 Jan 2020 17:14:02 GMT
Subject: RFR: 6674: Use try-with-resource in more places and close un-closed
 resources
Message-ID: <uVfakM3yp2xw8TNSJFLWJBFYeK9RyPpmkv9ANiOMh4E=.bae3dcec-c649-4957-b516-db615fc03348@github.com>

This PR fixes a few places where we didn't close resources properly before and also changes a number of older usages of IOToolkit to instead use try-with-resource.

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

Commits:
 - 3d150a42: Fix formatting
 - 428e6409: Use auto-closable in more places and close un-closed resources

Changes: https://git.openjdk.java.net/jmc/pull/33/files
 Webrev: https://webrevs.openjdk.java.net/jmc/33/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6674
  Stats: 313 lines in 38 files changed: 28 ins; 151 del; 134 mod
  Patch: https://git.openjdk.java.net/jmc/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/33/head:pull/33

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

From hirt at openjdk.java.net  Wed Jan 15 17:16:55 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 15 Jan 2020 17:16:55 GMT
Subject: [Integrated] RFR: 6549: Color flame chart based on package name
In-Reply-To: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
References: <Zv9ug4GhIDSZpFP_b-RVEuMtbDm3IAFAChpwofvcrTg=.2be57060-4ded-4b33-9665-aa309742f958@github.com>
Message-ID: <201f2b04-92f4-4628-a095-805b109f81df@openjdk.org>

Changeset: f74caa81
Author:    Miroslav Wengner <mwengner at openjdk.org>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-15 17:16:02 +0000
URL:       https://git.openjdk.java.net/jmc/commit/f74caa81

6549: Color flame chart based on package name

Co-authored-by: Marcus Hirt <marcus at hirt.se>
Reviewed-by: hirt

! application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceNode.java
! application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java
! application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/FlameGraphView.java
+ application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js
! application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/page.template

From hdafgard at openjdk.java.net  Wed Jan 15 17:32:06 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 15 Jan 2020 17:32:06 GMT
Subject: [Rev 02] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
Message-ID: <aB7EQQcbVV_IMz41GaTftmjC8S0kMMgk_Bgz7_3DE8o=.fe40e6e6-9aaa-4e66-96b2-70ea6a42cd03@github.com>

> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
> 
> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 9fdd627c: Fix formatting

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/31/files
  - new: https://git.openjdk.java.net/jmc/pull/31/files/25fb5af9..9fdd627c

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

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

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

From hdafgard at openjdk.java.net  Wed Jan 15 17:35:27 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 15 Jan 2020 17:35:27 GMT
Subject: [Rev 01] RFR: 6674: Use try-with-resource in more places and
 close un-closed resources
In-Reply-To: <uVfakM3yp2xw8TNSJFLWJBFYeK9RyPpmkv9ANiOMh4E=.bae3dcec-c649-4957-b516-db615fc03348@github.com>
References: <uVfakM3yp2xw8TNSJFLWJBFYeK9RyPpmkv9ANiOMh4E=.bae3dcec-c649-4957-b516-db615fc03348@github.com>
Message-ID: <Ee_AMsD1sYl6QXANZDEDfHuSIevw6CiMhUCnZZEOTX4=.b8940d33-2bba-4dd4-9605-d5e39e9c6ddc@github.com>

> This PR fixes a few places where we didn't close resources properly before and also changes a number of older usages of IOToolkit to instead use try-with-resource.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - be2d6092: Fix formatting in core

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/33/files
  - new: https://git.openjdk.java.net/jmc/pull/33/files/3d150a42..be2d6092

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

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

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

From jkang at openjdk.java.net  Wed Jan 15 19:51:08 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 15 Jan 2020 19:51:08 GMT
Subject: RFR: 6668: Move org.openjdk.jmc.jdp bundle from application to core
Message-ID: <zJ18SSPOVMLa1zLq6cWm9Rbr8jN6XqLVRdDKfaof6Vg=.a194aae8-d351-46f4-9e38-7e4bcc8dc379@github.com>

Addresses https://bugs.openjdk.java.net/browse/JMC-6668

No code changes were made.

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

Commits:
 - 1de78af4: Update licenses for year 2020. Fix some codestyle
 - 6d02e3dc: Add jdp dependency to application module
 - 31041d2e: 6668: Move org.openjdk.jmc.jdp bundle from application to core

Changes: https://git.openjdk.java.net/jmc/pull/34/files
 Webrev: https://webrevs.openjdk.java.net/jmc/34/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6668
  Stats: 6163 lines in 77 files changed: 3069 ins; 3076 del; 18 mod
  Patch: https://git.openjdk.java.net/jmc/pull/34.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/34/head:pull/34

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

From jkang at openjdk.java.net  Wed Jan 15 19:51:49 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 15 Jan 2020 19:51:49 GMT
Subject: [Rev 06] 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: <98K_kDEvWOmKRYNY-fbrNTNcO5G9u0LmA5howej904A=.b1c52a6d-7988-4c2b-86a7-0d0b9f93901d@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:
 - 867c2bb9: Update licenses with correct year field

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/21/files
  - new: https://git.openjdk.java.net/jmc/pull/21/files/b118b2a3..867c2bb9

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

  Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 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 hdafgard at openjdk.java.net  Thu Jan 16 13:36:08 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Thu, 16 Jan 2020 13:36:08 GMT
Subject: RFR: 6668: Move org.openjdk.jmc.jdp bundle from application to
 core
In-Reply-To: <zJ18SSPOVMLa1zLq6cWm9Rbr8jN6XqLVRdDKfaof6Vg=.a194aae8-d351-46f4-9e38-7e4bcc8dc379@github.com>
References: <zJ18SSPOVMLa1zLq6cWm9Rbr8jN6XqLVRdDKfaof6Vg=.a194aae8-d351-46f4-9e38-7e4bcc8dc379@github.com>
Message-ID: <6AVpavOTwKdxyS2pxt2HZ7n3nuuKJHeZP0pfB9kQ66M=.849ef59e-e3d9-4db3-b945-206468217c4f@github.com>

On Wed, 15 Jan 2020 19:48:49 GMT, Jie Kang <jkang at openjdk.org> wrote:

> Addresses https://bugs.openjdk.java.net/browse/JMC-6668
> 
> No code changes were made.

Looks good to me!

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

Marked as reviewed by hdafgard (Reviewer).

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

From hdafgard at openjdk.java.net  Thu Jan 16 15:54:09 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Thu, 16 Jan 2020 15:54:09 GMT
Subject: [Integrated] RFR: 6668: Move org.openjdk.jmc.jdp bundle from
 application to core
In-Reply-To: <zJ18SSPOVMLa1zLq6cWm9Rbr8jN6XqLVRdDKfaof6Vg=.a194aae8-d351-46f4-9e38-7e4bcc8dc379@github.com>
References: <zJ18SSPOVMLa1zLq6cWm9Rbr8jN6XqLVRdDKfaof6Vg=.a194aae8-d351-46f4-9e38-7e4bcc8dc379@github.com>
Message-ID: <4dc9a453-9ca7-4e49-97d7-bef8e2f399d2@openjdk.org>

Changeset: 87905922
Author:    Jie Kang <jkang at openjdk.org>
Committer: Henrik Dafg?rd <hdafgard at openjdk.org>
Date:      2020-01-16 15:53:39 +0000
URL:       https://git.openjdk.java.net/jmc/commit/87905922

6668: Move org.openjdk.jmc.jdp bundle from application to core

Reviewed-by: hdafgard

! application/coverage/pom.xml
- application/org.openjdk.jmc.jdp/build.properties
- application/org.openjdk.jmc.jdp/pom.xml
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/Discoverable.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/DiscoveryEvent.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/DiscoveryListener.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/JDPClient.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/PacketListener.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/PacketProcessor.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/Pruner.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/package-info.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/CodingException.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/Configuration.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/ConfigurationFactory.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/JDPPacket.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/JRockitJDPPacketDecoder.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/package-info.java
- application/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/jmx/JMXDataKeys.java
! application/pom.xml
- application/tests/org.openjdk.jmc.jdp.test/build.properties
- application/tests/org.openjdk.jmc.jdp.test/pom.xml
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/AllTests.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/ClientTester.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/ServerTester.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPClientTest.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPJMXTest.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPPacketTest.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPServerTest.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/TestToolkit.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/Broadcaster.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/JDPServer.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/jmx/JMXJDPServer.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/jmx/PIDHelper.java
- application/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/jmx/package-info.java
! application/tests/pom.xml
! core/coverage/pom.xml
= core/org.openjdk.jmc.jdp/.classpath
= core/org.openjdk.jmc.jdp/.project
= core/org.openjdk.jmc.jdp/.settings/org.eclipse.jdt.core.prefs
= core/org.openjdk.jmc.jdp/META-INF/MANIFEST.MF
+ core/org.openjdk.jmc.jdp/build.properties
+ core/org.openjdk.jmc.jdp/pom.xml
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/Discoverable.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/DiscoveryEvent.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/DiscoveryListener.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/JDPClient.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/PacketListener.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/PacketProcessor.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/Pruner.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/client/package-info.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/CodingException.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/Configuration.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/ConfigurationFactory.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/JDPPacket.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/JRockitJDPPacketDecoder.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/common/package-info.java
+ core/org.openjdk.jmc.jdp/src/main/java/org/openjdk/jmc/jdp/jmx/JMXDataKeys.java
! core/pom.xml
= core/tests/org.openjdk.jmc.jdp.test/.classpath
= core/tests/org.openjdk.jmc.jdp.test/.project
= core/tests/org.openjdk.jmc.jdp.test/META-INF/MANIFEST.MF
+ core/tests/org.openjdk.jmc.jdp.test/build.properties
+ core/tests/org.openjdk.jmc.jdp.test/pom.xml
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/AllTests.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/ClientTester.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/ServerTester.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPClientTest.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPJMXTest.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPPacketTest.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/JDPServerTest.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/client/TestToolkit.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/Broadcaster.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/JDPServer.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/jmx/JMXJDPServer.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/jmx/PIDHelper.java
+ core/tests/org.openjdk.jmc.jdp.test/src/test/java/org/openjdk/jmc/jdp/server/jmx/package-info.java
! core/tests/pom.xml

From hirt at openjdk.java.net  Fri Jan 17 10:27:29 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 17 Jan 2020 10:27:29 GMT
Subject: [Rev 01] RFR: 6674: Use try-with-resource in more places and
 close un-closed resources
In-Reply-To: <Ee_AMsD1sYl6QXANZDEDfHuSIevw6CiMhUCnZZEOTX4=.b8940d33-2bba-4dd4-9605-d5e39e9c6ddc@github.com>
References: <uVfakM3yp2xw8TNSJFLWJBFYeK9RyPpmkv9ANiOMh4E=.bae3dcec-c649-4957-b516-db615fc03348@github.com>
 <Ee_AMsD1sYl6QXANZDEDfHuSIevw6CiMhUCnZZEOTX4=.b8940d33-2bba-4dd4-9605-d5e39e9c6ddc@github.com>
Message-ID: <_ZDnwXp4IECR3xMIozTN9P5G1PHZy5a433nwjLOYpzU=.a6e3b2d2-7235-4dc7-bfca-09e4d74f3b52@github.com>

On Fri, 17 Jan 2020 10:27:29 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> This PR fixes a few places where we didn't close resources properly before and also changes a number of older usages of IOToolkit to instead use try-with-resource.
> 
> The pull request has been updated with 1 additional commit.



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

Marked as reviewed by hirt (Lead).

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

From hirt at openjdk.java.net  Fri Jan 17 10:27:47 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 17 Jan 2020 10:27:47 GMT
Subject: RFR: 6660: Make JMX API not return classes
In-Reply-To: <L9r2YmZ9_L0culT1bG0xqzJnOMA-rnv00sGXFQE-nxY=.b291ffd8-e423-4fbc-abd2-ee332b5b74ac@github.com>
References: <L9r2YmZ9_L0culT1bG0xqzJnOMA-rnv00sGXFQE-nxY=.b291ffd8-e423-4fbc-abd2-ee332b5b74ac@github.com>
Message-ID: <GApFSMOSFAFbzoQN3lSHmtMdQXRXuDDNDM3_r5zIL2w=.386e82fb-dcd3-41c4-b611-cc9b6b278fac@github.com>

On Wed, 15 Jan 2020 15:07:29 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch modifies the JMX API so that functions return void instead of class arrays.
> 
> The name of the function setTransforms was also changed to defineEventProbes as a result of this change because an mbean function whose name begins with "set", has one parameter and a return type of void, gets registered as a setter not an operation.



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

Marked as reviewed by hirt (Lead).

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

From hdafgard at openjdk.java.net  Fri Jan 17 14:26:51 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Fri, 17 Jan 2020 14:26:51 GMT
Subject: [Integrated] RFR: 6674: Use try-with-resource in more places and
 close un-closed resources
In-Reply-To: <uVfakM3yp2xw8TNSJFLWJBFYeK9RyPpmkv9ANiOMh4E=.bae3dcec-c649-4957-b516-db615fc03348@github.com>
References: <uVfakM3yp2xw8TNSJFLWJBFYeK9RyPpmkv9ANiOMh4E=.bae3dcec-c649-4957-b516-db615fc03348@github.com>
Message-ID: <39407cd7-bb55-4360-831a-f890793fca1d@openjdk.org>

Changeset: ea933fab
Author:    Henrik Dafg?rd <hdafgard at openjdk.org>
Date:      2020-01-17 14:25:45 +0000
URL:       https://git.openjdk.java.net/jmc/commit/ea933fab

6674: Use try-with-resource in more places and close un-closed resources

Reviewed-by: hirt

! application/org.openjdk.jmc.console.jconsole/src/main/java/org/openjdk/jmc/console/jconsole/JConsolePluginLoader.java
! application/org.openjdk.jmc.console.ui.notification/src/main/java/org/openjdk/jmc/console/ui/notification/action/TriggerActionStartTimeBoundRecording.java
! application/org.openjdk.jmc.console.ui.notification/src/main/java/org/openjdk/jmc/console/ui/notification/action/WriteAndOpenRecordingJob.java
! application/org.openjdk.jmc.console.ui.notification/src/main/java/org/openjdk/jmc/console/ui/notification/tab/TriggerToolkit.java
! application/org.openjdk.jmc.flightrecorder.controlpanel.ui.configuration/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/configuration/model/xml/XMLModel.java
! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/actions/DumpAnyRecordingAction.java
! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/actions/EditRecordingAction.java
! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/actions/StartRecordingAction.java
! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/jobs/UpdateRecordingJob.java
! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/model/EventConfiguration.java
! application/org.openjdk.jmc.flightrecorder.controlpanel.ui/src/main/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/model/PrivateStorageDelegate.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/RecordingLoader.java
! application/org.openjdk.jmc.ide.launch/src/main/java/org/openjdk/jmc/ide/launch/JfrLaunchDelegateHelper.java
! application/org.openjdk.jmc.ide.launch/src/main/java/org/openjdk/jmc/ide/launch/model/JfrLaunchModel.java
! application/org.openjdk.jmc.joverflow/src/main/java/org/openjdk/jmc/joverflow/heap/parser/ReadBuffer.java
! application/org.openjdk.jmc.joverflow/src/main/java/org/openjdk/jmc/joverflow/util/FileUtils.java
! application/org.openjdk.jmc.rcp.application/src/main/java/org/openjdk/jmc/rcp/logging/LoggingToolkit.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/persistence/internal/PersistenceFile.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/subscription/internal/FileMRIMetadata.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/triggers/internal/NotificationRuleBag.java
! application/org.openjdk.jmc.ui.common/src/main/java/org/openjdk/jmc/ui/common/util/MCVersion.java
! application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.test/src/test/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/model/test/EventConfigurationModelTest.java
! application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.test/src/test/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/model/test/EventConfigurationTest.java
! application/tests/org.openjdk.jmc.flightrecorder.controlpanel.ui.test/src/test/java/org/openjdk/jmc/flightrecorder/controlpanel/ui/model/test/JfrControlTestCase.java
! application/tests/org.openjdk.jmc.rjmx.services.jfr.test/src/test/java/org/openjdk/jmc/rjmx/services/jfr/test/JfrPackageExampleTest.java
! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/DefaultServicesTest.java
! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/PackageExampleTest.java
! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/services/ServicesPackageExampleTest.java
! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/subscription/MRIMetadataServiceTest.java
! application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/JfrMetadataToolkit.java
! application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/MetadataTestBase.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/Agent.java
! core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/util/TestToolkit.java
! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/io/IOToolkit.java
! core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/XmlToolkit.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/JfrLoaderToolkit.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/EventAppearance.java
! core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/java/org/openjdk/jmc/flightrecorder/test/rules/jdk/TestRulesWithJfr.java

From kxu at openjdk.java.net  Fri Jan 17 17:03:27 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Fri, 17 Jan 2020 17:03:27 GMT
Subject: [Rev 07] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <mjWhI-nj-Naa6kSDfR51uPZqIklGskWY-GdMrZJreUg=.4e0000a8-3cac-4715-84ed-2b19313908d5@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>
 <mjWhI-nj-Naa6kSDfR51uPZqIklGskWY-GdMrZJreUg=.4e0000a8-3cac-4715-84ed-2b19313908d5@github.com>
Message-ID: <118F-c92Gg2dfdCprHY8RvP2Sx6fwmFmmxae7M0O6Ik=.db96002c-5656-47ed-9c96-a753819af272@github.com>

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

>> Private constructor throwing unsupported exception might be nice so people don't even try instantiate it.
> 
> Javadocs for public methods would be nice.

The class is not final. A private constructor throwing exceptions has been added. Javadocs have been added for public methods.

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

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

From kxu at openjdk.java.net  Fri Jan 17 17:03:29 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Fri, 17 Jan 2020 17:03:29 GMT
Subject: [Rev 07] 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: <zi6ib-7hpB-gQHWGcFXQBlG93ZdVibJ8qomtBXuOZbY=.032f5d6b-6e1d-4fe8-86df-ed412d43d8f1@github.com>

On Thu, 19 Dec 2019 12:01:02 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/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.

Javadoc now added.

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

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

From kxu at openjdk.java.net  Fri Jan 17 19:35:22 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Fri, 17 Jan 2020 19:35:22 GMT
Subject: RFR: 6246: Making the agent stop using Unsafe
Message-ID: <k-rg1Nek8Ko12TV4uxj-4yZxjrw9YNu1RRN0WSX6mKY=.d2dc4fc7-9897-40be-9610-197d99886fae@github.com>

This patch addresses [JMC-6246](https://bugs.openjdk.java.net/browse/JMC-6246).

The usage of `Unsafe.defineClass()` is replaced with:
- for pre-Java 9, reflective access on `ClassLoader.getSystemClassLoader().defineClass()`
- for Java 9 and later, `MethodHandles.Lookup.defineClass()`

Please note that `LookUp.defineClass()` can only define classes within the same package of the lookup. Therefore generated events classes will be in the dedicated package `org.openjdk.jmc.agent.generated_events`, instead of being in the same package of the instrumented class.

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

Commits:
 - 3c26203d: remove unsafe related helpers functions
 - bf895935: make agent stop using Unsafe

Changes: https://git.openjdk.java.net/jmc/pull/35/files
 Webrev: https://webrevs.openjdk.java.net/jmc/35/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6246
  Stats: 102 lines in 5 files changed: 36 ins; 58 del; 8 mod
  Patch: https://git.openjdk.java.net/jmc/pull/35.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/35/head:pull/35

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

From hirt at openjdk.java.net  Fri Jan 17 20:02:22 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 17 Jan 2020 20:02:22 GMT
Subject: RFR: 6672: JavaScript formatting template
Message-ID: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>

Also fixing indentation in various places. For some reason spotless could not use the formatting settings to format the flame view javascript file, so adding a note on how to enable it in the pom. Also lowering the animation time for animations, since they are annoyingly slow now.

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

Commits:
 - e9269758: Fixing formatting and adding note on how to enable javascript in spotless
 - c0e921de: Merge branch 'master' into jsformatting
 - 7d55a7e2: 6672: Adding standardized javascript formatting

Changes: https://git.openjdk.java.net/jmc/pull/36/files
 Webrev: https://webrevs.openjdk.java.net/jmc/36/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6672
  Stats: 558 lines in 8 files changed: 418 ins; 124 del; 16 mod
  Patch: https://git.openjdk.java.net/jmc/pull/36.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/36/head:pull/36

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

From hirt at openjdk.java.net  Fri Jan 17 20:03:56 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 17 Jan 2020 20:03:56 GMT
Subject: RFR: 6246: Making the agent stop using Unsafe
In-Reply-To: <k-rg1Nek8Ko12TV4uxj-4yZxjrw9YNu1RRN0WSX6mKY=.d2dc4fc7-9897-40be-9610-197d99886fae@github.com>
References: <k-rg1Nek8Ko12TV4uxj-4yZxjrw9YNu1RRN0WSX6mKY=.d2dc4fc7-9897-40be-9610-197d99886fae@github.com>
Message-ID: <AKPKFcytcfzlNE04mZ3UNgK8nrDOxG9xFIqEjbGjPDE=.95041bc2-eb6a-447d-bf08-3fc87f334ec7@github.com>

On Fri, 17 Jan 2020 19:34:16 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

> This patch addresses [JMC-6246](https://bugs.openjdk.java.net/browse/JMC-6246).
> 
> The usage of `Unsafe.defineClass()` is replaced with:
> - for pre-Java 9, reflective access on `ClassLoader.getSystemClassLoader().defineClass()`
> - for Java 9 and later, `MethodHandles.Lookup.defineClass()`
> 
> Please note that `LookUp.defineClass()` can only define classes within the same package of the lookup. Therefore generated events classes will be in the dedicated package `org.openjdk.jmc.agent.generated_events`, instead of being in the same package of the instrumented class.

Doesn't this affect in which class loader the event classes are defined, and especially their unload behaviour?

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

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

From kxu at openjdk.java.net  Fri Jan 17 20:11:04 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Fri, 17 Jan 2020 20:11:04 GMT
Subject: RFR: 6246: Making the agent stop using Unsafe
In-Reply-To: <AKPKFcytcfzlNE04mZ3UNgK8nrDOxG9xFIqEjbGjPDE=.95041bc2-eb6a-447d-bf08-3fc87f334ec7@github.com>
References: <k-rg1Nek8Ko12TV4uxj-4yZxjrw9YNu1RRN0WSX6mKY=.d2dc4fc7-9897-40be-9610-197d99886fae@github.com>
 <AKPKFcytcfzlNE04mZ3UNgK8nrDOxG9xFIqEjbGjPDE=.95041bc2-eb6a-447d-bf08-3fc87f334ec7@github.com>
Message-ID: <qqGLDIHFxw771bjav16HI2a3JeaHpJjXMzlI7fW9ja8=.44ba4f7d-a8c0-4953-b1b8-0b28cb41543f@github.com>

On Fri, 17 Jan 2020 20:03:42 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> This patch addresses [JMC-6246](https://bugs.openjdk.java.net/browse/JMC-6246).
>> 
>> The usage of `Unsafe.defineClass()` is replaced with:
>> - for pre-Java 9, reflective access on `ClassLoader.getSystemClassLoader().defineClass()`
>> - for Java 9 and later, `MethodHandles.Lookup.defineClass()`
>> 
>> Please note that `LookUp.defineClass()` can only define classes within the same package of the lookup. Therefore generated events classes will be in the dedicated package `org.openjdk.jmc.agent.generated_events`, instead of being in the same package of the instrumented class.
> 
> Doesn't this affect in which class loader the event classes are defined, and especially their unload behaviour?

In the case of reflective access, it's called directly on the system class loader. For `Lookup.defineClass`, the event class is defined on the class loader of the lookup, which in this case is the system class loader that loads `org.openjdk.jmc.agent.generated_events.Dummy`.

In both cases, events are defined with the system class loader, just like `Unsafe.defineClass`.

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

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

From hirt at openjdk.java.net  Fri Jan 17 20:17:54 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 17 Jan 2020 20:17:54 GMT
Subject: [Integrated] RFR: 6660: Make JMX API not return classes
In-Reply-To: <L9r2YmZ9_L0culT1bG0xqzJnOMA-rnv00sGXFQE-nxY=.b291ffd8-e423-4fbc-abd2-ee332b5b74ac@github.com>
References: <L9r2YmZ9_L0culT1bG0xqzJnOMA-rnv00sGXFQE-nxY=.b291ffd8-e423-4fbc-abd2-ee332b5b74ac@github.com>
Message-ID: <99d34a2c-d2dc-4806-8568-03f8b4f88b10@openjdk.org>

Changeset: afcf74db
Author:    Jessye Coleman-Shapiro <jescolem at redhat.com>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-17 20:04:53 +0000
URL:       https://git.openjdk.java.net/jmc/commit/afcf74db

6660: Make JMX API not return classes

Reviewed-by: hirt

! core/org.openjdk.jmc.agent/README.md
! core/org.openjdk.jmc.agent/pom.xml
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentController.java
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentControllerMBean.java
+ core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestDefineEventProbes.java
- core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestSetTransforms.java

From github.com+29706926+jessyec-s at openjdk.java.net  Fri Jan 17 20:48:21 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Fri, 17 Jan 2020 20:48:21 GMT
Subject: RFR: 6661: Simplify Agent JMX tests
Message-ID: <gWcnpFIfYjAgMqTeGvbk6idBSvnKZKG3oSswebtQh4Y=.e1c7379e-660a-4ccb-b31d-6585d044b599@github.com>

This patch simplifies mbean function calls for agent JMX tests.  

The proposed solution, which is outlined in the ticket's description, was to create an mbean object by calling ManagementFactory.newPlatformMXBeanProxy(...). However this function requires the  AgentControllerMBean class to be loaded by the platform class loader, which it is not.  So instead I have called the JMX.newMXBeanProxy(...) directly.

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

Commits:
 - 646146d7: Simplify Agent JMX tests

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

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

From kxu at openjdk.java.net  Fri Jan 17 21:00:34 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Fri, 17 Jan 2020 21:00:34 GMT
Subject: [Rev 08] 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: <hnXsGvvckc37i-lvQ21sfxBFB2Y1LY4tdMZwLOO9Rac=.c46000bf-5381-448a-bcba-3670842817fc@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 a new target base due to a merge or a rebase.

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

Commits:
 - 5dc43be5: Merge remote-tracking branch 'upstream/master' into agent-path-expression
 - 10e48d58: update license header year values
 - 09abbb99: remove unused function
 - 4bb163b9: update TestSetTransforms with new changes
 - 04185668: Merge remote-tracking branch 'upstream/master' into agent-path-expression
 - c78ce947: lazy-load class with InspectionClassLoader
 - c35788f2: add javadoc
 - 9782c758: update license header year
 - 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.08
  Stats: 2396 lines in 24 files changed: 2282 ins; 1 del; 113 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 hdafgard at openjdk.java.net  Sat Jan 18 12:20:09 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Sat, 18 Jan 2020 12:20:09 GMT
Subject: RFR: 6672: JavaScript formatting template
In-Reply-To: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
References: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
Message-ID: <g3b2Jqwskai-gR-iSLVYuazWVCQfF7socjDb5snXPpI=.33c64574-062c-4e70-b168-d1a539aa752b@github.com>

On Fri, 17 Jan 2020 20:00:25 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also fixing indentation in various places. For some reason spotless could not use the formatting settings to format the flame view javascript file, so adding a note on how to enable it in the pom. Also lowering the animation time for animations, since they are annoyingly slow now.

application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/page.template line 32:

> 31: 				.cellHeight(18)
> 32: 				.transitionDuration(320)
> 33: 				.minFrameSize(5)

Was this change intended to be included in this formatting PR?

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

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

From hirt at openjdk.java.net  Sat Jan 18 16:31:27 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 18 Jan 2020 16:31:27 GMT
Subject: RFR: 6672: JavaScript formatting template
In-Reply-To: <g3b2Jqwskai-gR-iSLVYuazWVCQfF7socjDb5snXPpI=.33c64574-062c-4e70-b168-d1a539aa752b@github.com>
References: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
 <g3b2Jqwskai-gR-iSLVYuazWVCQfF7socjDb5snXPpI=.33c64574-062c-4e70-b168-d1a539aa752b@github.com>
Message-ID: <LTEPP_j2CPkkrO4n4Gq8gxMPoErFtZg63SKhoB3FBPM=.2fffecd7-612b-4150-b433-660362bca17e@github.com>

On Sat, 18 Jan 2020 12:19:38 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> Also fixing indentation in various places. For some reason spotless could not use the formatting settings to format the flame view javascript file, so adding a note on how to enable it in the pom. Also lowering the animation time for animations, since they are annoyingly slow now.
> 
> application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/page.template line 32:
> 
>> 31: 				.cellHeight(18)
>> 32: 				.transitionDuration(320)
>> 33: 				.minFrameSize(5)
> 
> Was this change intended to be included in this formatting PR?

"Also lowering the animation time for animations, since they are annoyingly slow now." 
Yes, thought I might as well, since it's such a small change.

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

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

From hirt at openjdk.java.net  Sat Jan 18 16:36:07 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 18 Jan 2020 16:36:07 GMT
Subject: RFR: 6661: Simplify Agent JMX tests
In-Reply-To: <gWcnpFIfYjAgMqTeGvbk6idBSvnKZKG3oSswebtQh4Y=.e1c7379e-660a-4ccb-b31d-6585d044b599@github.com>
References: <gWcnpFIfYjAgMqTeGvbk6idBSvnKZKG3oSswebtQh4Y=.e1c7379e-660a-4ccb-b31d-6585d044b599@github.com>
Message-ID: <Z4HtUEeNO7j3v-EdUpXt-ib32cdi-v3n9npVeZlmA0I=.aad7af31-2a12-42b5-a902-194e0465ee82@github.com>

On Fri, 17 Jan 2020 20:46:09 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch simplifies mbean function calls for agent JMX tests.  
> 
> The proposed solution, which is outlined in the ticket's description, was to create an mbean object by calling ManagementFactory.newPlatformMXBeanProxy(...). However this function requires the  AgentControllerMBean class to be loaded by the platform class loader, which it is not.  So instead I have called the JMX.newMXBeanProxy(...) directly.



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

Marked as reviewed by hirt (Lead).

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

From hirt at openjdk.java.net  Sun Jan 19 11:35:17 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sun, 19 Jan 2020 11:35:17 GMT
Subject: RFR: 6246: Making the agent stop using Unsafe
In-Reply-To: <qqGLDIHFxw771bjav16HI2a3JeaHpJjXMzlI7fW9ja8=.44ba4f7d-a8c0-4953-b1b8-0b28cb41543f@github.com>
References: <k-rg1Nek8Ko12TV4uxj-4yZxjrw9YNu1RRN0WSX6mKY=.d2dc4fc7-9897-40be-9610-197d99886fae@github.com>
 <AKPKFcytcfzlNE04mZ3UNgK8nrDOxG9xFIqEjbGjPDE=.95041bc2-eb6a-447d-bf08-3fc87f334ec7@github.com>
 <qqGLDIHFxw771bjav16HI2a3JeaHpJjXMzlI7fW9ja8=.44ba4f7d-a8c0-4953-b1b8-0b28cb41543f@github.com>
Message-ID: <zgbts0OZv3JZjN_oVsl8IYIFJ4ZaWcm2pzbTpXZKzuM=.86e331c7-7fc2-4fb0-86e0-1f10d31c3d40@github.com>

On Fri, 17 Jan 2020 20:10:37 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

>> Doesn't this affect in which class loader the event classes are defined, and especially their unload behaviour?
> 
> In the case of reflective access, it's called directly on the system class loader. For `Lookup.defineClass`, the event class is defined on the class loader of the lookup, which in this case is the system class loader that loads `org.openjdk.jmc.agent.generated_events.Dummy`.
> 
> In both cases, events are defined with the system class loader, just like `Unsafe.defineClass`.

I was under the impression that the class loader and protection domain arguments given to define class would define the class with that class loader and protection domain, allowing the event class to be unloaded when the class where it is being used is unloaded. If this is not done, we?re basically introducing a class leak.

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

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

From mwengner at openjdk.java.net  Sun Jan 19 15:41:43 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Sun, 19 Jan 2020 15:41:43 GMT
Subject: RFR: 6670: harmonize unclassifiable across flameview
Message-ID: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>

6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
https://bugs.openjdk.java.net/browse/JMC-6670

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

Commits:
 - 0f529ec0: 6670: Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
 - 16ae867f: Merge branch 'master' into feature/6670_Harmonize_Unclassifiable_across_flameview
 - 4d66678b: 6670: Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
 - 44d3e526: 6670: Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
 - 60a1b66a: 6670: Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View

Changes: https://git.openjdk.java.net/jmc/pull/38/files
 Webrev: https://webrevs.openjdk.java.net/jmc/38/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6670
  Stats: 85 lines in 7 files changed: 62 ins; 15 del; 8 mod
  Patch: https://git.openjdk.java.net/jmc/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/38/head:pull/38

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

From hdafgard at openjdk.java.net  Sun Jan 19 18:07:15 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Sun, 19 Jan 2020 18:07:15 GMT
Subject: RFR: 6672: JavaScript formatting template
In-Reply-To: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
References: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
Message-ID: <LoOzNUvygKmLkbWuU6UnBSYF7Arpf01DHQM3rMjZVlM=.f58fbb6f-626a-4d6b-9140-3e78391ff1d4@github.com>

On Fri, 17 Jan 2020 20:00:25 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also fixing indentation in various places. For some reason spotless could not use the formatting settings to format the flame view javascript file, so adding a note on how to enable it in the pom. Also lowering the animation time for animations, since they are annoyingly slow now.



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

Marked as reviewed by hdafgard (Reviewer).

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

From mwengner at openjdk.java.net  Sun Jan 19 21:09:47 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Sun, 19 Jan 2020 21:09:47 GMT
Subject: RFR: 6672: JavaScript formatting template
In-Reply-To: <LTEPP_j2CPkkrO4n4Gq8gxMPoErFtZg63SKhoB3FBPM=.2fffecd7-612b-4150-b433-660362bca17e@github.com>
References: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
 <g3b2Jqwskai-gR-iSLVYuazWVCQfF7socjDb5snXPpI=.33c64574-062c-4e70-b168-d1a539aa752b@github.com>
 <LTEPP_j2CPkkrO4n4Gq8gxMPoErFtZg63SKhoB3FBPM=.2fffecd7-612b-4150-b433-660362bca17e@github.com>
Message-ID: <Y1UG9j4EIWkUtKGuyBD5UjnhELBo-za9A4vFkc4tfN4=.b461ca21-ea78-408f-9cd8-52fece9535db@github.com>

On Sat, 18 Jan 2020 16:30:39 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/page.template line 32:
>> 
>>> 31: 				.cellHeight(18)
>>> 32: 				.transitionDuration(320)
>>> 33: 				.minFrameSize(5)
>> 
>> Was this change intended to be included in this formatting PR?
> 
> "Also lowering the animation time for animations, since they are annoyingly slow now." 
> Yes, thought I might as well, since it's such a small change.

it makes sense

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

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

From mwengner at openjdk.java.net  Sun Jan 19 21:10:22 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Sun, 19 Jan 2020 21:10:22 GMT
Subject: RFR: 6672: JavaScript formatting template
In-Reply-To: <Y1UG9j4EIWkUtKGuyBD5UjnhELBo-za9A4vFkc4tfN4=.b461ca21-ea78-408f-9cd8-52fece9535db@github.com>
References: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
 <g3b2Jqwskai-gR-iSLVYuazWVCQfF7socjDb5snXPpI=.33c64574-062c-4e70-b168-d1a539aa752b@github.com>
 <LTEPP_j2CPkkrO4n4Gq8gxMPoErFtZg63SKhoB3FBPM=.2fffecd7-612b-4150-b433-660362bca17e@github.com>
 <Y1UG9j4EIWkUtKGuyBD5UjnhELBo-za9A4vFkc4tfN4=.b461ca21-ea78-408f-9cd8-52fece9535db@github.com>
Message-ID: <Z4ooxktkr9uDVQV9BegI1yTS-jeil31FxIab8f4FMxo=.1b3e4ed7-d068-41d1-84d8-d91f779aea7f@github.com>

On Sun, 19 Jan 2020 21:09:38 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> "Also lowering the animation time for animations, since they are annoyingly slow now." 
>> Yes, thought I might as well, since it's such a small change.
> 
> it makes sense

it makes sense

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

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

From mwengner at openjdk.java.net  Mon Jan 20 08:57:39 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 08:57:39 GMT
Subject: [Rev 01] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <I9FBx8M12o4kZ3K22r-MY_cEJiYQV-Q7eRDRT2pqNgQ=.8a480c1e-6593-4f9e-91ea-f37799fd29c0@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - f47bf343: 6670: clean up, value comparison strategy

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/0f529ec0..f47bf343

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

  Stats: 30 lines in 3 files changed: 4 ins; 17 del; 9 mod
  Patch: https://git.openjdk.java.net/jmc/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/38/head:pull/38

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

From hirt at openjdk.java.net  Mon Jan 20 12:54:50 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 12:54:50 GMT
Subject: [Integrated] RFR: 6672: JavaScript formatting template
In-Reply-To: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
References: <0h-E1Ss0HU19hSPno-j-GLFoHNuO32DG3ZEBrO2LHDk=.174c366a-65c8-432e-ac96-60e3c1dfcf1c@github.com>
Message-ID: <ea69d135-f14a-4f99-9a28-e3ecc1318314@openjdk.org>

Changeset: c2134e2f
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-20 12:53:32 +0000
URL:       https://git.openjdk.java.net/jmc/commit/c2134e2f

6672: JavaScript formatting template

Reviewed-by: hdafgard

! application/org.openjdk.jmc.flightrecorder.flameview/build.properties
! application/org.openjdk.jmc.flightrecorder.flameview/pom.xml
! application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/FlameGraphView.java
+ application/org.openjdk.jmc.flightrecorder.flameview/src/main/js/flameviewColoring.js
- application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/jsjmclibs/flameviewColoring.js
! application/org.openjdk.jmc.flightrecorder.flameview/src/main/resources/page.template
+ configuration/ide/eclipse/formatting/formattingjs.xml
! pom.xml

From hirt at openjdk.java.net  Mon Jan 20 13:28:46 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 13:28:46 GMT
Subject: [Rev 01] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <I9FBx8M12o4kZ3K22r-MY_cEJiYQV-Q7eRDRT2pqNgQ=.8a480c1e-6593-4f9e-91ea-f37799fd29c0@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <I9FBx8M12o4kZ3K22r-MY_cEJiYQV-Q7eRDRT2pqNgQ=.8a480c1e-6593-4f9e-91ea-f37799fd29c0@github.com>
Message-ID: <JZJfHL-7JlkJHyvFHjXFJ8oiz3eyBjTaIo6_Mz-vD1A=.558c4a21-ed88-487d-b829-784653c4c7a6@github.com>

On Mon, 20 Jan 2020 13:28:44 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
>> https://bugs.openjdk.java.net/browse/JMC-6670
> 
> The pull request has been updated with 1 additional commit.

application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java line 56:

> 55: 
> 56: 		private static TraceNode getRootTraceNode(String rootName, Fork rootFork) {
> 57: 			return new TraceNode(rootName == null ? DEFAULT_ROOT_NAME : rootName, rootFork.getItemsInFork(),

Is this really necessary? The factory class doesn't add much in terms of abstraction over having a factory method, and it's not clear to me why the get by frame method belongs in there and not the rest of the utility methods. I'd revert these changes, or at least add the helper methods as private statics without the extra inner class.

application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java line 526:

> 525: 	public static String VMOperationPage_TIMELINE_SELECTION;
> 526: 	public static String Flameview_UNCLASSIFIABLE_FRAME_DESC;
> 527: 

Since it's only the flame view that uses this description, it could be in FlameView (it really should be, if it is to be named FlameView something). If we want the description to be generally available, it should be somewhere else. If we want it to be available to rules etc, it probably should live somewhere in core, near to where the definition of the unclassifiable frame is, e.g. in flightrecorder. One possible solution, would e.g. be to add a public messages bundle in the stacktrace package.

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

Changes requested by hirt (Lead).

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

From hirt at openjdk.java.net  Mon Jan 20 14:16:37 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 14:16:37 GMT
Subject: [Integrated] RFR: 6661: Simplify Agent JMX tests
In-Reply-To: <gWcnpFIfYjAgMqTeGvbk6idBSvnKZKG3oSswebtQh4Y=.e1c7379e-660a-4ccb-b31d-6585d044b599@github.com>
References: <gWcnpFIfYjAgMqTeGvbk6idBSvnKZKG3oSswebtQh4Y=.e1c7379e-660a-4ccb-b31d-6585d044b599@github.com>
Message-ID: <9c42c897-15bb-4418-9bc9-c8d797f0cd3e@openjdk.org>

Changeset: e647a9d1
Author:    Jessye Coleman-Shapiro <jescolem at redhat.com>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-20 14:15:25 +0000
URL:       https://git.openjdk.java.net/jmc/commit/e647a9d1

6661: Simplify Agent JMX tests

Reviewed-by: hirt

! core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestDefineEventProbes.java

From hirt at openjdk.java.net  Mon Jan 20 15:00:20 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 15:00:20 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <WL7Atk9jWavX3ivK-1_mIl_L-VnozKPqwT0c-oxM2Ww=.fee97f45-b4a9-4c71-9b3c-662c560026da@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>
 <bTmQavGW9K4mLHe22ziWHR6KmCiXFPPgBmYGGFbbVIc=.afc84d2f-907c-470c-9d2c-e7bda6bd75cc@github.com>
 <WL7Atk9jWavX3ivK-1_mIl_L-VnozKPqwT0c-oxM2Ww=.fee97f45-b4a9-4c71-9b3c-662c560026da@github.com>
Message-ID: <nDnNSBsQeNzM6Z9NBaezWcI_-Dp8wihhTj1kKtEJ-Ec=.a84de08f-1976-4a3b-8cbb-4ad124772c4d@github.com>

On Tue, 14 Jan 2020 12:19:09 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> 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.
> 
> Note that copyrights need to be updated.

Hi Jie!

How about hiding the count column, or even removing it? This is the event count for both of the TLAB events - it does not correspond to the number of actual objects. We could perhaps estimate the number of allocated objects (using the size of the allocated object inside tlab and the tlab size) and add that as a new column, but the event count doesn't really make sense. Now that we have the percentages, we may want to instead have the backdrop bars on them.

Also, how about hiding the average columns by default? There is a bit of information overload right now, and I think the sums may be what people will usually want. They can show the other columns if they need them.

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

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

From hirt at openjdk.java.net  Mon Jan 20 15:26:49 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 15:26:49 GMT
Subject: [Rev 08] RFR: 6656: Allow capturing field values with path syntax
In-Reply-To: <hnXsGvvckc37i-lvQ21sfxBFB2Y1LY4tdMZwLOO9Rac=.c46000bf-5381-448a-bcba-3670842817fc@github.com>
References: <Fg2D1kl85ifKiX_rSRCSI30YR8jMA6mgeMsL-TBjqvI=.a298cd04-4038-4276-913c-71f57d274926@github.com>
 <hnXsGvvckc37i-lvQ21sfxBFB2Y1LY4tdMZwLOO9Rac=.c46000bf-5381-448a-bcba-3670842817fc@github.com>
Message-ID: <fXdSv3uqzexgRxahmlf5HQK5nKNV4vQeOo5p2emML1s=.515bdfc0-5420-49b2-a724-ba9bf59b4284@github.com>

On Mon, 20 Jan 2020 15:26:45 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!
> 
> The pull request has been updated with a new target base due to a merge or a rebase.

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

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

We only need to parse/load the class if we are looking up fields. Can't we do this later, and only if we need it lazily? It's seems a bit premature to do it here in the Transformer.

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

Changes requested by hirt (Lead).

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

From hdafgard at openjdk.java.net  Mon Jan 20 16:19:36 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 20 Jan 2020 16:19:36 GMT
Subject: RFR: 6364: Improvements to the Thread Graph
In-Reply-To: <RzkGUXMijABPraKoBm2yRnh7490ldPx8R1pVnLkZuQo=.49c6a560-d0bc-4870-8fc8-6b16c31a4edf@github.com>
References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com>
 <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com>
 <RzkGUXMijABPraKoBm2yRnh7490ldPx8R1pVnLkZuQo=.49c6a560-d0bc-4870-8fc8-6b16c31a4edf@github.com>
Message-ID: <VtxWPdJ5lCNJANcyQQKDpUAc6oMz6sIIl4AdCngGzNY=.3e9e164a-aeca-4a31-9c0d-90b32e505e1f@github.com>

On Fri, 10 Jan 2020 15:14:16 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> jcheck is requesting:
>> 
>> s/JMC-6364/6364
> 
>> jcheck is requesting:
>> 
>> s/JMC-6364/6364
> 
> Neat, thanks for the heads up. I changed the commit description and force pushed them back here, but it looks like once a PR has been made with the invalid ID format it's the PR name change that gets jcheck to pass. This automation is nice, the `mvn spotless:apply` was especially nice to have.

I actually liked the old behaviour of being able to see all thread states on one screen (given that you had sufficient pixels to display them). It gave a more helpful overview of the application state during the recording. I.e. the old view had a minimum lane height of 1 pixel. To do the same thing here you'd have to collapse the table, since 1 pixel isn't enough to render thread names.

The selection highlighter also seems to have taken a significant performance hit, so it's a bit harder to drag and select a region of threads.

Unless I'm missing something it also appears that I can't sort the thread table, and I'm uncertain what order the threads are shown in now.

I'm also a bit confused by why the scroll bar on the right hand side scrolls horizontally when it's rendered vertically, and the component now doesn't zoom through time with the scroll wheel, like all other pages do?

It would also be nice if the "Thread State Selection" toolbar button could do more of the "Edit Thread Activity Lanes" dialog, since they're doing very similar things?

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

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

From github.com+29706926+jessyec-s at openjdk.java.net  Mon Jan 20 16:37:57 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Mon, 20 Jan 2020 16:37:57 GMT
Subject: RFR: 6572: Make mbean functions protected by permission checks
Message-ID: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>

This patch adds a permission check to Agent MBean functions for the 'control' management permission. 

I have also added a test "testPermissionChecks" to see if a security exception is fired when this permission is not given.

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

Commits:
 - 0e3ebef1: Make mbean functions protected by permission checks

Changes: https://git.openjdk.java.net/jmc/pull/39/files
 Webrev: https://webrevs.openjdk.java.net/jmc/39/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6572
  Stats: 136 lines in 5 files changed: 128 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jmc/pull/39.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/39/head:pull/39

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

From hirt at openjdk.java.net  Mon Jan 20 16:50:50 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 16:50:50 GMT
Subject: RFR: 6673: Upgrading to Tycho 1.6.0
Message-ID: <oTjxz8t7_Xr7axfkDE0a_WVTF-iVVaWMJHOBJksi9Iw=.a5651e15-0b78-4a3c-b274-2395bb7de9bf@github.com>

6673: Upgrading to Tycho 1.6.0

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

Commits:
 - eeb79868: 6673: Upgrading to Tycho 1.6.0

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

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

From hdafgard at openjdk.java.net  Mon Jan 20 17:03:56 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 20 Jan 2020 17:03:56 GMT
Subject: RFR: 6673: Upgrading to Tycho 1.6.0
In-Reply-To: <oTjxz8t7_Xr7axfkDE0a_WVTF-iVVaWMJHOBJksi9Iw=.a5651e15-0b78-4a3c-b274-2395bb7de9bf@github.com>
References: <oTjxz8t7_Xr7axfkDE0a_WVTF-iVVaWMJHOBJksi9Iw=.a5651e15-0b78-4a3c-b274-2395bb7de9bf@github.com>
Message-ID: <vtUYtMZcxxgO5agOSFWHFp6dfARIT53d7T28uiM6kJ8=.7bc75046-dd36-41b9-9e13-ec519cc1684e@github.com>

On Mon, 20 Jan 2020 16:49:24 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> 6673: Upgrading to Tycho 1.6.0

LGTM! Nice to have faster dependency resolution, if it's noticable.

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

Marked as reviewed by hdafgard (Reviewer).

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

From hirt at openjdk.java.net  Mon Jan 20 17:19:30 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 17:19:30 GMT
Subject: [Integrated] RFR: 6673: Upgrading to Tycho 1.6.0
In-Reply-To: <oTjxz8t7_Xr7axfkDE0a_WVTF-iVVaWMJHOBJksi9Iw=.a5651e15-0b78-4a3c-b274-2395bb7de9bf@github.com>
References: <oTjxz8t7_Xr7axfkDE0a_WVTF-iVVaWMJHOBJksi9Iw=.a5651e15-0b78-4a3c-b274-2395bb7de9bf@github.com>
Message-ID: <ee1812c7-3961-4981-8e98-2611fcf9e434@openjdk.org>

Changeset: 1676ecce
Author:    Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-20 17:18:28 +0000
URL:       https://git.openjdk.java.net/jmc/commit/1676ecce

6673: Upgrading to Tycho 1.6.0

Reviewed-by: hdafgard

! pom.xml

From jkang at openjdk.java.net  Mon Jan 20 18:05:04 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Mon, 20 Jan 2020 18:05:04 GMT
Subject: [Rev 07] 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: <LQjK_dLlzKF_6RrfWxm8kkSQcMdF4XiRFgknlL5dEo8=.834e3288-552f-4e09-93cf-a5715b5ad4cc@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 a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Added commits:
 - b5ddfdc1: Update licenses with correct year field
 - 86811758: Update licenses for year 2020
 - 546c1d9f: Revert field name change
 - dccecea0: Move name and description setting to percentage column creation. Remove duplicate aggregators
 - f03e96cb: Add translations for new column name and descriptions
 - 53cb730d: Shorten column names with short form for Allocation(s)
 - 0304f078: Shorten column names with short form for Average and Percentage
 - 658bb8a4: Fix accidental removal of code text
 - 81046ef0: Update name and description for percentage columns
 - 80136239: Fix key name in messages.properties
 - 44d1843d: Add tabs to tlab page for tlabs by threads and by top methods
 - 114ea7d4: Add percentage columns to tlab view
 - 9e97aa84: Store reference to all items in AggregationModel rather than the AggregationRow
 - 857bb4fe: Add allocation percentage column to memory view
 - 1676ecce: 6673: Upgrading to Tycho 1.6.0
 - e647a9d1: 6661: Simplify Agent JMX tests
 - c2134e2f: 6672: JavaScript formatting template
 - afcf74db: 6660: Make JMX API not return classes
 - ea933fab: 6674: Use try-with-resource in more places and close un-closed resources
 - 87905922: 6668: Move org.openjdk.jmc.jdp bundle from application to core
 - f74caa81: 6549: Color flame chart based on package name
 - 055db4fc: 6659: Remove 'Showing X of Y events...' table message when not applicable
 - bfb23cde: 6671: Eagerly convert end time to the same unit as start time
 - 0f08461f: 5721: Reintroduce the Percentage column
 - 67bc8668: 6658: Remove unnecessary storing of pre-instrumented bytecode
 - 7ad8f7c0: 6663: Reloading the Flame Chart View in Linux displays file browser
 - 31d82a7d: 6665: .project files still exist for removed platform definitions
 - 423e72db: 6662: Updating to Eclipse 2019-12 (4.14)
 - 2e81a835: 6583: Add filter and search table actions to EventBrowser page

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/21/files
  - new: https://git.openjdk.java.net/jmc/pull/21/files/867c2bb9..b5ddfdc1

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

  Stats: 8102 lines in 159 files changed: 3942 ins; 3950 del; 210 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  Mon Jan 20 21:29:47 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 21:29:47 GMT
Subject: RFR: 6572: Make mbean functions protected by permission checks
In-Reply-To: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
References: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
Message-ID: <4lnVm6xuwr0iZmJe_v6WKpKKQ3y32qmwo9hHH9e315Y=.6271ff68-efc1-4b91-888b-aaf97d573846@github.com>

On Mon, 20 Jan 2020 16:35:16 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

> This patch adds a permission check to Agent MBean functions for the 'control' management permission. 
> 
> I have also added a test "testPermissionChecks" to see if a security exception is fired when this permission is not given.

core/org.openjdk.jmc.agent/README.md line 32:

> 31: ### Using a security manager
> 32: To make MBean calls more secure, the agent can be run with a security manager. A manager can be enabled by adding the VM option `-Djava.security.manager` and by supplying a policy file of permissions to grant as such: `-Djava.security.policy=permissions.policy`. The 'control' Management Permission must be granted in order for MBean function calls to succeed.
> 33: 

I'd probably paraphrase this a bit. It's running with a security manager - not just running the agent with security manager. Perhaps something along the lines of: "When running with a security manager, the 'control' Management Permission must be granted to control the agent through the MBean. To set fine grained permissions for authenticated remote users, see e.g. https://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdeup and  https://docs.oracle.com/javadb/10.10.1.2/adminguide/radminjmxenablepolicy.html#radminjmxenablepolicy. Blahblahblah."

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

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

From mwengner at openjdk.java.net  Mon Jan 20 21:31:59 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 21:31:59 GMT
Subject: [Rev 01] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <JZJfHL-7JlkJHyvFHjXFJ8oiz3eyBjTaIo6_Mz-vD1A=.558c4a21-ed88-487d-b829-784653c4c7a6@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <I9FBx8M12o4kZ3K22r-MY_cEJiYQV-Q7eRDRT2pqNgQ=.8a480c1e-6593-4f9e-91ea-f37799fd29c0@github.com>
 <JZJfHL-7JlkJHyvFHjXFJ8oiz3eyBjTaIo6_Mz-vD1A=.558c4a21-ed88-487d-b829-784653c4c7a6@github.com>
Message-ID: <z84MTj2LOXIVjncAzSzPl8RL9OrVieaH2-Br3ZaKKY8=.959956ba-8052-469a-ba30-701dad8fe94b@github.com>

On Mon, 20 Jan 2020 13:03:48 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java line 56:
> 
>> 55: 
>> 56: 		private static TraceNode getRootTraceNode(String rootName, Fork rootFork) {
>> 57: 			return new TraceNode(rootName == null ? DEFAULT_ROOT_NAME : rootName, rootFork.getItemsInFork(),
> 
> Is this really necessary? The factory class doesn't add much in terms of abstraction over having a factory method, and it's not clear to me why the get by frame method belongs in there and not the rest of the utility methods. I'd revert these changes, or at least add the helper methods as private statics without the extra inner class.

agree, helper methods are fine.

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

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

From mwengner at openjdk.java.net  Mon Jan 20 21:34:42 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 21:34:42 GMT
Subject: [Rev 02] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <8_PfEElffaxhciGgnfZoCU7pLnBlivA37aMyQJPbzRA=.cf860ed9-79c2-45e4-9fbc-9be7b764f908@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - e501ab26: 6670: stactrace message, helper methods

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/f47bf343..e501ab26

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

  Stats: 49 lines in 5 files changed: 21 ins; 23 del; 5 mod
  Patch: https://git.openjdk.java.net/jmc/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/38/head:pull/38

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

From mwengner at openjdk.java.net  Mon Jan 20 21:35:11 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 21:35:11 GMT
Subject: [Rev 01] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <JZJfHL-7JlkJHyvFHjXFJ8oiz3eyBjTaIo6_Mz-vD1A=.558c4a21-ed88-487d-b829-784653c4c7a6@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <I9FBx8M12o4kZ3K22r-MY_cEJiYQV-Q7eRDRT2pqNgQ=.8a480c1e-6593-4f9e-91ea-f37799fd29c0@github.com>
 <JZJfHL-7JlkJHyvFHjXFJ8oiz3eyBjTaIo6_Mz-vD1A=.558c4a21-ed88-487d-b829-784653c4c7a6@github.com>
Message-ID: <Fcwawyly7Cuhiu9FfbQWVLrvsKwdOYZTHtnDBiRIV_Q=.fb805f59-6150-423d-aadb-614b2bc4d3bb@github.com>

On Mon, 20 Jan 2020 13:27:48 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java line 526:
> 
>> 525: 	public static String VMOperationPage_TIMELINE_SELECTION;
>> 526: 	public static String Flameview_UNCLASSIFIABLE_FRAME_DESC;
>> 527: 
> 
> Since it's only the flame view that uses this description, it could be in FlameView (it really should be, if it is to be named FlameView something). If we want the description to be generally available, it should be somewhere else. If we want it to be available to rules etc, it probably should live somewhere in core, near to where the definition of the unclassifiable frame is, e.g. in flightrecorder. One possible solution, would e.g. be to add a public messages bundle in the stacktrace package.

thanks, corrected, I had the solution in stacktrace bundle before as we want to add similar tooltip to the stactrace view

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

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

From hirt at openjdk.java.net  Mon Jan 20 21:37:10 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 21:37:10 GMT
Subject: [Rev 02] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <aB7EQQcbVV_IMz41GaTftmjC8S0kMMgk_Bgz7_3DE8o=.fe40e6e6-9aaa-4e66-96b2-70ea6a42cd03@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
 <aB7EQQcbVV_IMz41GaTftmjC8S0kMMgk_Bgz7_3DE8o=.fe40e6e6-9aaa-4e66-96b2-70ea6a42cd03@github.com>
Message-ID: <AMruSwUynW6lFNSJUPbQVSKhp96vfxz-Lf9JRl48G5Q=.adc273e4-13de-481c-970b-983091f0927c@github.com>

On Mon, 20 Jan 2020 21:37:09 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
>> 
>> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.
> 
> The pull request has been updated with 1 additional commit.

core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java line 1432:

> 1431: 	 * Returns the latest end time in the provided item collection. This method is based on the
> 1432: 	 * assumption that item collection lanes are sorted by timestamp.
> 1433: 	 * 

...and that they are not overlapping.

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

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

From hirt at openjdk.java.net  Mon Jan 20 21:37:21 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 21:37:21 GMT
Subject: [Rev 02] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <aB7EQQcbVV_IMz41GaTftmjC8S0kMMgk_Bgz7_3DE8o=.fe40e6e6-9aaa-4e66-96b2-70ea6a42cd03@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
 <aB7EQQcbVV_IMz41GaTftmjC8S0kMMgk_Bgz7_3DE8o=.fe40e6e6-9aaa-4e66-96b2-70ea6a42cd03@github.com>
Message-ID: <Ewg8Cm2A7zL5MrY0YHqnZZOPI2ALN74BAJAkVsqktkA=.1133c266-230d-48e0-bf5d-3aa1504f2739@github.com>

On Mon, 20 Jan 2020 21:37:20 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
>> 
>> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.
> 
> The pull request has been updated with 1 additional commit.

core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java line 1402:

> 1401: 	 * Returns the earliest end time in the provided item collection. This method is based on the
> 1402: 	 * assumption that item collection lanes are sorted by timestamp.
> 1403: 	 * 

...and that they are not overlapping.

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

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

From hirt at openjdk.java.net  Mon Jan 20 21:41:26 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 20 Jan 2020 21:41:26 GMT
Subject: RFR: 6674: Optimize finding of first start time and first & last
 end times
In-Reply-To: <SmP6mAUO6hOcKma0o4SGOFDROprtiXV3y61gyhuBVIo=.8834cfcd-3317-4b89-812a-1ae45c5d6f69@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
 <mh1xfRByzbMOsetykLcMrj-pF0C_9ATQXz_SeAOfD3U=.05bd349e-e10f-481f-8c7e-43fc1f758a90@github.com>
 <SmP6mAUO6hOcKma0o4SGOFDROprtiXV3y61gyhuBVIo=.8834cfcd-3317-4b89-812a-1ae45c5d6f69@github.com>
Message-ID: <YYPz_vQFiID0L0IOFjI1FmLt3HwQCrqYhoC7jyQIbu4=.68318f87-bb7e-4c9c-8c64-ae6bdb2a35c9@github.com>

On Wed, 15 Jan 2020 17:03:41 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> Careful here. They are not sorted on start and end time both, and events are not guaranteed (except that we recommend that this is the case for the events of a particular event type, if at all possible) to be non-overlapping.
> 
> JMC parser currently guarantees that IItemCollection events are retrieved in sorted, disjoint, lanes. Each event is iterated over in the time that it was emitted, and if there is an overlap then it will be in another lane. This is why we iterate through the IItemCollection and then through the IItemIterable, even if the IItemCollection is filtered to only contain one type.
> 
> There is still the problem that this relies on the implicit assumption that these lanes are sorted in this fashion, but since we're currently performing a computationally intensive sorting during the parsing we should think about exploiting that fact.

Can we add some verification tests showing that we get the same results for a few sets of data? I think it would be nice if we added a recording with (custom, well defined) overlapping events (of all types of overlap) to the test recordings.

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

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

From mwengner at openjdk.java.net  Mon Jan 20 21:58:13 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 21:58:13 GMT
Subject: [Rev 03] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <wsX6U3rfw07w8UKElLe-0e6QtVKdLVHxTKFu3doqmCI=.26dc6d9d-482f-4b3e-92a1-17a094a1dafc@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Added commits:
 - 73095855: Merge branch 'master' into feature/6670_Harmonize_Unclassifiable_across_flameview
 - 1676ecce: 6673: Upgrading to Tycho 1.6.0
 - e647a9d1: 6661: Simplify Agent JMX tests
 - c2134e2f: 6672: JavaScript formatting template

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/e501ab26..73095855

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

  Stats: 583 lines in 9 files changed: 427 ins; 135 del; 21 mod
  Patch: https://git.openjdk.java.net/jmc/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/38/head:pull/38

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

From mwengner at openjdk.java.net  Mon Jan 20 22:47:18 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 22:47:18 GMT
Subject: [Rev 04] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <_8j1i3E5pdUIo_oVGrN1ovBXu9nwJlIDocjb3Pxocds=.7b7be901-ff6b-438a-b9fb-0c47b3e6e424@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 8c4a0f6a: 6670: stactrace message eval

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/73095855..8c4a0f6a

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

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

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

From mwengner at openjdk.java.net  Mon Jan 20 22:57:56 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 22:57:56 GMT
Subject: [Rev 05] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <pqBYbScnP_dBuavoVhl2zvl23JyJ9LYyBS9JLefUECE=.436d77ca-311d-4fd2-8a63-572d397afc4f@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - a5cfb5e5: 6670: js cleanup

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/8c4a0f6a..a5cfb5e5

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

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

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

From mwengner at openjdk.java.net  Mon Jan 20 23:04:44 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 23:04:44 GMT
Subject: [Rev 06] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <UySLDTz4sLR0SQb6Xlp2EXrQJxN4h_7j4ZKub1UWwTc=.bd5d539c-f256-4c49-b7bb-25aab971b958@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - d6410894: 6670: cleanup

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/a5cfb5e5..d6410894

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

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

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

From mwengner at openjdk.java.net  Mon Jan 20 23:06:47 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Mon, 20 Jan 2020 23:06:47 GMT
Subject: [Rev 07] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <On0KXEYqnx7G9qtsiCy0ARaeGyGArgqiulkwC36e3W8=.f01f2e13-d5d6-439e-887e-74c8725c953b@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 521d1709: 6670: cleanup

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/d6410894..521d1709

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

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

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

From hirt at openjdk.java.net  Tue Jan 21 11:55:21 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 21 Jan 2020 11:55:21 GMT
Subject: [Rev 07] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <On0KXEYqnx7G9qtsiCy0ARaeGyGArgqiulkwC36e3W8=.f01f2e13-d5d6-439e-887e-74c8725c953b@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <On0KXEYqnx7G9qtsiCy0ARaeGyGArgqiulkwC36e3W8=.f01f2e13-d5d6-439e-887e-74c8725c953b@github.com>
Message-ID: <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>

On Tue, 21 Jan 2020 11:55:16 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
>> https://bugs.openjdk.java.net/browse/JMC-6670
> 
> The pull request has been updated with 1 additional commit.

Changes requested by hirt (Lead).

application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java line 46:

> 45: import org.openjdk.jmc.flightrecorder.stacktrace.StacktraceFrame;
> 46: import org.openjdk.jmc.flightrecorder.stacktrace.messages.internal.Messages;
> 47: 

Messages to be shared should not be in an internal bundle.

application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/FlameGraphView.java line 80:

> 79: 
> 80: import static org.openjdk.jmc.flightrecorder.stacktrace.messages.internal.Messages.STACKTRACE_UNCLASSIFIABLE_FRAME;
> 81: import static org.openjdk.jmc.flightrecorder.stacktrace.messages.internal.Messages.STACKTRACE_UNCLASSIFIABLE_FRAME_DESC;

Messages to be shared should not be in an internal bundle.

core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages/internal/messages.properties line 39:

> 38: STACKTRACE_UNCLASSIFIABLE_FRAME=~ UNCLASSIFIABLE ~
> 39: STACKTRACE_UNCLASSIFIABLE_FRAME_DESC=Unclassified means the stacktrace reached the stackdepth limit

Lacks a newline at the end of the last property.

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

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

From github.com+29706926+jessyec-s at openjdk.java.net  Tue Jan 21 14:51:04 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Tue, 21 Jan 2020 14:51:04 GMT
Subject: [Rev 01] RFR: 6572: Make mbean functions protected by permission
 checks
In-Reply-To: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
References: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
Message-ID: <rx4XJ4SANujYBGRGNuxl9i3XghiuRyjf0afMRYw9AOA=.21cbbaec-0be0-426e-b3a8-fc594db5443d@github.com>

> This patch adds a permission check to Agent MBean functions for the 'control' management permission. 
> 
> I have also added a test "testPermissionChecks" to see if a security exception is fired when this permission is not given.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - d94062ca: Modify README description

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/39/files
  - new: https://git.openjdk.java.net/jmc/pull/39/files/0e3ebef1..d94062ca

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

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

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

From github.com+29706926+jessyec-s at openjdk.java.net  Tue Jan 21 14:51:49 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Tue, 21 Jan 2020 14:51:49 GMT
Subject: [Rev 01] RFR: 6572: Make mbean functions protected by permission
 checks
In-Reply-To: <4lnVm6xuwr0iZmJe_v6WKpKKQ3y32qmwo9hHH9e315Y=.6271ff68-efc1-4b91-888b-aaf97d573846@github.com>
References: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
 <4lnVm6xuwr0iZmJe_v6WKpKKQ3y32qmwo9hHH9e315Y=.6271ff68-efc1-4b91-888b-aaf97d573846@github.com>
Message-ID: <B8U7srgkr7qqXvrVu7VqzIYxnFwF2cSwqGc2RXgqXbo=.9ec40c27-8627-4dd6-b201-2000f7f5d11f@github.com>

On Mon, 20 Jan 2020 21:28:31 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> core/org.openjdk.jmc.agent/README.md line 32:
> 
>> 31: ### Using a security manager
>> 32: To make MBean calls more secure, the agent can be run with a security manager. A manager can be enabled by adding the VM option `-Djava.security.manager` and by supplying a policy file of permissions to grant as such: `-Djava.security.policy=permissions.policy`. The 'control' Management Permission must be granted in order for MBean function calls to succeed.
>> 33: 
> 
> I'd probably paraphrase this a bit. It's running with a security manager - not just running the agent with security manager. Perhaps something along the lines of: "When running with a security manager, the 'control' Management Permission must be granted to control the agent through the MBean. To set fine grained permissions for authenticated remote users, see e.g. https://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdeup and  https://docs.oracle.com/javadb/10.10.1.2/adminguide/radminjmxenablepolicy.html#radminjmxenablepolicy. Blahblahblah."

Ok I have modified the description in https://github.com/openjdk/jmc/pull/39/commits/d94062ca316631dffba2e4642215ada40e34ff03.  Let me know what you think.

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

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

From mwengner at openjdk.java.net  Tue Jan 21 23:25:44 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Tue, 21 Jan 2020 23:25:44 GMT
Subject: [Rev 08] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <4UUA2q8DmLIDV0G-S7nKgcFblusdRghYE6l4UblJ5ao=.6ee291cf-491c-4ec4-91ca-5d28ab3828bc@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 910a015c: 6670: partial commit

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/521d1709..910a015c

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/38/webrev.08
 - incr: https://webrevs.openjdk.java.net/jmc/38/webrev.07-08

  Stats: 184 lines in 12 files changed: 167 ins; 12 del; 5 mod
  Patch: https://git.openjdk.java.net/jmc/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/38/head:pull/38

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

From jkang at openjdk.java.net  Wed Jan 22 16:30:42 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 22 Jan 2020 16:30:42 GMT
Subject: [Rev 08] 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: <-UqG2ofduzPXTKh_EyYJJ0_lQEwzhHou5dFDPd23z3g=.cc669f76-c833-4aea-bc92-97fe95c68346@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:
 - c819e9d8: Remove count column and hide average columns by default on TlabPage

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/21/files
  - new: https://git.openjdk.java.net/jmc/pull/21/files/b5ddfdc1..c819e9d8

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/21/webrev.08
 - incr: https://webrevs.openjdk.java.net/jmc/21/webrev.07-08

  Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 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  Wed Jan 22 16:30:42 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 22 Jan 2020 16:30:42 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <nDnNSBsQeNzM6Z9NBaezWcI_-Dp8wihhTj1kKtEJ-Ec=.a84de08f-1976-4a3b-8cbb-4ad124772c4d@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>
 <bTmQavGW9K4mLHe22ziWHR6KmCiXFPPgBmYGGFbbVIc=.afc84d2f-907c-470c-9d2c-e7bda6bd75cc@github.com>
 <WL7Atk9jWavX3ivK-1_mIl_L-VnozKPqwT0c-oxM2Ww=.fee97f45-b4a9-4c71-9b3c-662c560026da@github.com>
 <nDnNSBsQeNzM6Z9NBaezWcI_-Dp8wihhTj1kKtEJ-Ec=.a84de08f-1976-4a3b-8cbb-4ad124772c4d@github.com>
Message-ID: <A4rlWf1Mb6KKLo3JHkUJiQOKVZ6WtHERwqsjMV42a9g=.86690366-b39e-4caf-9a67-6f7297f5ac13@github.com>

On Mon, 20 Jan 2020 15:00:00 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Note that copyrights need to be updated.
> 
> Hi Jie!
> 
> How about hiding the count column, or even removing it? I believe this is the event count for both of the TLAB events - it does not correspond to the number of actual objects allocated. We could perhaps estimate the number of allocated objects (using the size of the allocated object inside tlab and the tlab size) and add that as a new column, with a proper description, but the total event count doesn't really make sense. Now that we have the percentages, we may want to instead have the backdrop bars on them.
> 
> Also, how about hiding the average columns by default? There is a bit of information overload right now, and I think the sums may be what people will usually want. They can show the other columns if they need them.

> Hi Jie!
> 
> How about hiding the count column, or even removing it? I believe this is the event count for both of the TLAB events - it does not correspond to the number of actual objects allocated. We could perhaps estimate the number of allocated objects (using the size of the allocated object inside tlab and the tlab size) and add that as a new column, with a proper description, but the total event count doesn't really make sense. Now that we have the percentages, we may want to instead have the backdrop bars on them.
> 
> Also, how about hiding the average columns by default? There is a bit of information overload right now, and I think the sums may be what people will usually want. They can show the other columns if they need them.

I agree with your suggestions. I've removed the count column and hidden the average columns by default. I am currently working on the backdrop bars. It's a bit more complicated than I had initially hoped.

I think an estimated count of number of objects allocated could be useful. I can also try to add this here, but I think it's extending a little more past the issue contents. Is it acceptable if I open another issue in JIRA to address this?

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

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

From mwengner at openjdk.java.net  Wed Jan 22 17:34:02 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 17:34:02 GMT
Subject: [Rev 09] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <wBMqpAGzxUgiEx64m1xst36rjDSfGvGOn50d2oWpq8A=.b0f6ba8a-9aab-4944-a9b1-8f0ae5433219@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 9a5d526d: 6670: message bundle correction

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/910a015c..9a5d526d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/38/webrev.09
 - incr: https://webrevs.openjdk.java.net/jmc/38/webrev.08-09

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

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

From mwengner at openjdk.java.net  Wed Jan 22 17:34:04 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 17:34:04 GMT
Subject: [Rev 07] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <On0KXEYqnx7G9qtsiCy0ARaeGyGArgqiulkwC36e3W8=.f01f2e13-d5d6-439e-887e-74c8725c953b@github.com>
 <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>
Message-ID: <RbtPqOlEuH8zgRhbSGeFv_3yYDHn1B8Ziy9EYKgaFUI=.436b720b-374a-45cb-9dd1-c3ff20de1f9f@github.com>

On Tue, 21 Jan 2020 11:53:48 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/FlameGraphView.java line 80:
> 
>> 79: 
>> 80: import static org.openjdk.jmc.flightrecorder.stacktrace.messages.internal.Messages.STACKTRACE_UNCLASSIFIABLE_FRAME;
>> 81: import static org.openjdk.jmc.flightrecorder.stacktrace.messages.internal.Messages.STACKTRACE_UNCLASSIFIABLE_FRAME_DESC;
> 
> Messages to be shared should not be in an internal bundle.

I've put them into the move them into the package : org.openjdk.jmc.flightrecorder.stacktrace.messages.common.

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

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

From mwengner at openjdk.java.net  Wed Jan 22 17:34:03 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 17:34:03 GMT
Subject: [Rev 07] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <On0KXEYqnx7G9qtsiCy0ARaeGyGArgqiulkwC36e3W8=.f01f2e13-d5d6-439e-887e-74c8725c953b@github.com>
 <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>
Message-ID: <guOpEQMMa7Ml-RhecQG9UIee1URKeaSIxLqICspBq_4=.7d84a17a-3d6c-4922-8271-cc2223557737@github.com>

On Tue, 21 Jan 2020 11:52:57 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java line 46:
> 
>> 45: import org.openjdk.jmc.flightrecorder.stacktrace.StacktraceFrame;
>> 46: import org.openjdk.jmc.flightrecorder.stacktrace.messages.internal.Messages;
>> 47: 
> 
> Messages to be shared should not be in an internal bundle.

I've put them into the move them into the package : org.openjdk.jmc.flightrecorder.stacktrace.messages.common.
is it fine ?

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

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

From mwengner at openjdk.java.net  Wed Jan 22 17:34:04 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 17:34:04 GMT
Subject: [Rev 07] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <On0KXEYqnx7G9qtsiCy0ARaeGyGArgqiulkwC36e3W8=.f01f2e13-d5d6-439e-887e-74c8725c953b@github.com>
 <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>
Message-ID: <Tuv5gb7ydtXEvteKMLPtgKdP-v1zX26zguL3wN-yCcE=.69b9d41d-63f6-4a82-b89e-d78002b9b067@github.com>

On Tue, 21 Jan 2020 11:55:04 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages/internal/messages.properties line 39:
> 
>> 38: STACKTRACE_UNCLASSIFIABLE_FRAME=~ UNCLASSIFIABLE ~
>> 39: STACKTRACE_UNCLASSIFIABLE_FRAME_DESC=Unclassified means the stacktrace reached the stackdepth limit
> 
> Lacks a newline at the end of the last property.

corrected

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

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

From mwengner at openjdk.java.net  Wed Jan 22 17:45:24 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 17:45:24 GMT
Subject: [Rev 10] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <wuaMVawGE71v2iI5q5lxWSalhIxRrgDtMxnS61GE5XE=.6a6dff85-145b-4080-9383-a75c1770712a@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - 3f9ec087: 6670: cleanup

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/9a5d526d..3f9ec087

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/38/webrev.10
 - incr: https://webrevs.openjdk.java.net/jmc/38/webrev.09-10

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

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

From mwengner at openjdk.java.net  Wed Jan 22 18:00:38 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 18:00:38 GMT
Subject: [Rev 11] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <pa5AfCmVWNoBEBqJ3Ol2OKDbaR7JQwPfF6RK6TlrsxY=.a24b29af-91e6-44ab-a623-11559372ad38@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - fac00a68: 6670: spotless correction

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/3f9ec087..fac00a68

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/38/webrev.11
 - incr: https://webrevs.openjdk.java.net/jmc/38/webrev.10-11

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

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

From hirt at openjdk.java.net  Wed Jan 22 18:45:47 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 22 Jan 2020 18:45:47 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <A4rlWf1Mb6KKLo3JHkUJiQOKVZ6WtHERwqsjMV42a9g=.86690366-b39e-4caf-9a67-6f7297f5ac13@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>
 <bTmQavGW9K4mLHe22ziWHR6KmCiXFPPgBmYGGFbbVIc=.afc84d2f-907c-470c-9d2c-e7bda6bd75cc@github.com>
 <WL7Atk9jWavX3ivK-1_mIl_L-VnozKPqwT0c-oxM2Ww=.fee97f45-b4a9-4c71-9b3c-662c560026da@github.com>
 <nDnNSBsQeNzM6Z9NBaezWcI_-Dp8wihhTj1kKtEJ-Ec=.a84de08f-1976-4a3b-8cbb-4ad124772c4d@github.com>
 <A4rlWf1Mb6KKLo3JHkUJiQOKVZ6WtHERwqsjMV42a9g=.86690366-b39e-4caf-9a67-6f7297f5ac13@github.com>
Message-ID: <McTBOzDDONF9ovWqNZprXRtXBY9I3hPQYKZ-7H0YAFU=.255b7392-1291-4727-82ec-205bf8643e0d@github.com>

On Wed, 22 Jan 2020 16:10:19 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> Hi Jie!
>> 
>> How about hiding the count column, or even removing it? I believe this is the event count for both of the TLAB events - it does not correspond to the number of actual objects allocated. We could perhaps estimate the number of allocated objects (using the size of the allocated object inside tlab and the tlab size) and add that as a new column, with a proper description, but the total event count doesn't really make sense. Now that we have the percentages, we may want to instead have the backdrop bars on them.
>> 
>> Also, how about hiding the average columns by default? There is a bit of information overload right now, and I think the sums may be what people will usually want. They can show the other columns if they need them.
> 
>> Hi Jie!
>> 
>> How about hiding the count column, or even removing it? I believe this is the event count for both of the TLAB events - it does not correspond to the number of actual objects allocated. We could perhaps estimate the number of allocated objects (using the size of the allocated object inside tlab and the tlab size) and add that as a new column, with a proper description, but the total event count doesn't really make sense. Now that we have the percentages, we may want to instead have the backdrop bars on them.
>> 
>> Also, how about hiding the average columns by default? There is a bit of information overload right now, and I think the sums may be what people will usually want. They can show the other columns if they need them.
> 
> I agree with your suggestions. I've removed the count column and hidden the average columns by default. I am currently working on the backdrop bars. It's a bit more complicated than I had initially hoped.
> 
> I think an estimated count of number of objects allocated could be useful. I can also try to add this here, but I think it's extending a little more past the issue contents. Is it acceptable if I open another issue in JIRA to address this?

> Is it acceptable if I open another issue in JIRA to address this?

Certainly!

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

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

From hirt at openjdk.java.net  Wed Jan 22 19:00:17 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 22 Jan 2020 19:00:17 GMT
Subject: [Rev 01] RFR: 6572: Make mbean functions protected by permission
 checks
In-Reply-To: <rx4XJ4SANujYBGRGNuxl9i3XghiuRyjf0afMRYw9AOA=.21cbbaec-0be0-426e-b3a8-fc594db5443d@github.com>
References: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
 <rx4XJ4SANujYBGRGNuxl9i3XghiuRyjf0afMRYw9AOA=.21cbbaec-0be0-426e-b3a8-fc594db5443d@github.com>
Message-ID: <GlPqJT8iE-pMQynV6EQZoH6PVbOQbzhE8F2iKZb4Lz8=.ae5ff130-d885-485a-8d12-16eeb084d174@github.com>

On Wed, 22 Jan 2020 19:00:17 GMT, Jessye Coleman-Shapiro <github.com+29706926+jessyec-s at openjdk.org> wrote:

>> This patch adds a permission check to Agent MBean functions for the 'control' management permission. 
>> 
>> I have also added a test "testPermissionChecks" to see if a security exception is fired when this permission is not given.
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by hirt (Lead).

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

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

From mwengner at openjdk.java.net  Wed Jan 22 19:29:55 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 19:29:55 GMT
Subject: [Rev 12] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <WweSQ7y62JzWiDkhj80bxkYagUMkU10aPE3AaBDiaEI=.3561db3d-87f6-4666-bdce-aeee044eb286@github.com>

> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
> https://bugs.openjdk.java.net/browse/JMC-6670

The pull request has been updated with 1 additional commit.

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

Added commits:
 - fc80b578: 6670: messages package correction

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/38/files
  - new: https://git.openjdk.java.net/jmc/pull/38/files/fac00a68..fc80b578

Webrevs:
 - full: https://webrevs.openjdk.java.net/jmc/38/webrev.12
 - incr: https://webrevs.openjdk.java.net/jmc/38/webrev.11-12

  Stats: 121 lines in 9 files changed: 58 ins; 60 del; 3 mod
  Patch: https://git.openjdk.java.net/jmc/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/38/head:pull/38

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

From mwengner at openjdk.java.net  Wed Jan 22 19:30:36 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Wed, 22 Jan 2020 19:30:36 GMT
Subject: [Rev 07] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <guOpEQMMa7Ml-RhecQG9UIee1URKeaSIxLqICspBq_4=.7d84a17a-3d6c-4922-8271-cc2223557737@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <On0KXEYqnx7G9qtsiCy0ARaeGyGArgqiulkwC36e3W8=.f01f2e13-d5d6-439e-887e-74c8725c953b@github.com>
 <KVtcDdIYsi4CcFX8yAw3EQR_qjmcjNoLd0XNLqXt_gM=.73a25d1d-7fe0-429c-a2b6-bfc8fb42034f@github.com>
 <guOpEQMMa7Ml-RhecQG9UIee1URKeaSIxLqICspBq_4=.7d84a17a-3d6c-4922-8271-cc2223557737@github.com>
Message-ID: <o_qnNzyl2XlDVxkGFUv622tgWp8V6xd9KJ3133n0Yg8=.142af0dc-9ccd-454d-b4f3-dc14d6f8e38a@github.com>

On Wed, 22 Jan 2020 17:29:56 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java line 46:
>> 
>>> 45: import org.openjdk.jmc.flightrecorder.stacktrace.StacktraceFrame;
>>> 46: import org.openjdk.jmc.flightrecorder.stacktrace.messages.internal.Messages;
>>> 47: 
>> 
>> Messages to be shared should not be in an internal bundle.
> 
> I've put them into the move them into the package : org.openjdk.jmc.flightrecorder.stacktrace.messages.common.
> is it fine ?

moved to the org.openjdk.jmc.flightrecorder.stacktrace

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

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

From jkang at openjdk.java.net  Wed Jan 22 21:29:52 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 22 Jan 2020 21:29:52 GMT
Subject: RFR: 6657: Add allocation pressure column to Memory and TLAB views
In-Reply-To: <McTBOzDDONF9ovWqNZprXRtXBY9I3hPQYKZ-7H0YAFU=.255b7392-1291-4727-82ec-205bf8643e0d@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>
 <bTmQavGW9K4mLHe22ziWHR6KmCiXFPPgBmYGGFbbVIc=.afc84d2f-907c-470c-9d2c-e7bda6bd75cc@github.com>
 <WL7Atk9jWavX3ivK-1_mIl_L-VnozKPqwT0c-oxM2Ww=.fee97f45-b4a9-4c71-9b3c-662c560026da@github.com>
 <nDnNSBsQeNzM6Z9NBaezWcI_-Dp8wihhTj1kKtEJ-Ec=.a84de08f-1976-4a3b-8cbb-4ad124772c4d@github.com>
 <A4rlWf1Mb6KKLo3JHkUJiQOKVZ6WtHERwqsjMV42a9g=.86690366-b39e-4caf-9a67-6f7297f5ac13@github.com>
 <McTBOzDDONF9ovWqNZprXRtXBY9I3hPQYKZ-7H0YAFU=.255b7392-1291-4727-82ec-205bf8643e0d@github.com>
Message-ID: <miIkKx3zQZ2GdlrVYilAQpU71GNB19kegHCbTRhNX98=.b3133508-0078-4b6b-b995-e4b5cb3c18e4@github.com>

On Wed, 22 Jan 2020 18:45:38 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>>> Hi Jie!
>>> 
>>> How about hiding the count column, or even removing it? I believe this is the event count for both of the TLAB events - it does not correspond to the number of actual objects allocated. We could perhaps estimate the number of allocated objects (using the size of the allocated object inside tlab and the tlab size) and add that as a new column, with a proper description, but the total event count doesn't really make sense. Now that we have the percentages, we may want to instead have the backdrop bars on them.
>>> 
>>> Also, how about hiding the average columns by default? There is a bit of information overload right now, and I think the sums may be what people will usually want. They can show the other columns if they need them.
>> 
>> I agree with your suggestions. I've removed the count column and hidden the average columns by default. I am currently working on the backdrop bars. It's a bit more complicated than I had initially hoped.
>> 
>> I think an estimated count of number of objects allocated could be useful. I can also try to add this here, but I think it's extending a little more past the issue contents. Is it acceptable if I open another issue in JIRA to address this?
> 
>> Is it acceptable if I open another issue in JIRA to address this?
> 
> Certainly!

> > Is it acceptable if I open another issue in JIRA to address this?
> 
> Certainly!

Created @ https://bugs.openjdk.java.net/browse/JMC-6678

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

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

From aptmac at openjdk.java.net  Wed Jan 22 22:06:28 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Wed, 22 Jan 2020 22:06:28 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
Message-ID: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>

This PR addresses JMC-6531 [[0]](https://bugs.openjdk.java.net/browse/JMC-6531), in which the flame chart view displays nothing in Windows.

tl;dr: the proposed solution uses a fork of d3-flame-graph [[1]](https://github.com/aptmac/d3-flame-graph) which substitutes the incompatible svg element with one that works with Internet Explorer, and modifies the flameviewColoring script to work with an older ECMA version.

Screenshot of Windows:
![windows-works](https://user-images.githubusercontent.com/10425301/72937103-7cd3b900-3d36-11ea-9939-8c71880cfbee.png)

For reference, here's the same view in Linux:
![2020-01-22-165007_1913x1031_scrot](https://user-images.githubusercontent.com/10425301/72937506-4480aa80-3d37-11ea-9628-431f240dd457.png)

When I had originally taken a look into the SWT Browser and compatibility with Windows, it looked as though we'd be able to use Edge as an embedded browser, which would be nice because it already plays nice with the d3-flame-graph library. After quite a bit of trial and error I was first able to get d3 to work (making simple line charts), and then found that d3-flame-graph version <= 2.0.2 will work. With this older version of d3-flame-graph the coloured labels will be drawn, but no text is shown - regardless of the SWT browser property being set to IE or Edge .. which makes it look like Edge can be used for visiting external webpages, but not local ones (internal browser stays IE). This is because the foreignObject element is incompatible with IE, and this has already been raised as an issue and closed as a "wontfix" by the maintainer on the upstream repo [[2]](https://github.com/spiermar/d3-flame-graph/issues/84). 

I made a fork of the d3-flame-graph repo [[1]](https://github.com/aptmac/d3-flame-graph), which accomplishes two things:
- substitutes `<foreignObject>` for `<text>` [[3]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211)
- trims the text in the labels because the ellipsis css doesn't work [[4]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238)

This forked version of d3-flame-graph is downloaded by the maven-download-plugin like the other jslibs, and is used if the Environment type is `WINDOWS` as detected in `FlameGraphView.java` [[5]](https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102).

Now that the flame chart view works at this point, I had to edit `flameviewColoring.java` to be compatible with IE. From what I can find, Internet Explorer uses JScript, which in it's latest version supports ECMA 5 [[6]](https://en.wikipedia.org/wiki/JScript#JScript). This means no maps, no named functions, etc.

Lastly, and not completely related to this issue, I changed the name of `page.template` to `template.html` because my IDE won't provide syntax highlighting unless the file ends with -.html, and it was a big help here. If it's deemed unecessary I can just drop the associated commit.

Let me know what you think!

[0] https://bugs.openjdk.java.net/browse/JMC-6531
[1] https://github.com/aptmac/d3-flame-graph
[2] https://github.com/spiermar/d3-flame-graph/issues/84
[3] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211
[4] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238
[5] https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102
[6] https://en.wikipedia.org/wiki/JScript#JScript

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

Commits:
 - 3b354650: rename page.template to template.html for compatibility with IDE syntax highlighting
 - b64b4349: 6531: Make the flame chart view render labels on windows

Changes: https://git.openjdk.java.net/jmc/pull/41/files
 Webrev: https://webrevs.openjdk.java.net/jmc/41/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6531
  Stats: 64 lines in 4 files changed: 31 ins; 0 del; 33 mod
  Patch: https://git.openjdk.java.net/jmc/pull/41.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/41/head:pull/41

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

From aptmac at openjdk.java.net  Wed Jan 22 22:22:15 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Wed, 22 Jan 2020 22:22:15 GMT
Subject: [Rev 01] RFR: 6531: Make the flame chart view render labels on
 windows
In-Reply-To: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
Message-ID: <lT6BU-LTOCgAwesExQ8e-6ewNfiMr7Ynw32llp69nrE=.9bc3c9c9-2355-4d61-af74-780c8c9f9b22@github.com>

> This PR addresses JMC-6531 [[0]](https://bugs.openjdk.java.net/browse/JMC-6531), in which the flame chart view displays nothing in Windows.
> 
> tl;dr: the proposed solution uses a fork of d3-flame-graph [[1]](https://github.com/aptmac/d3-flame-graph) which substitutes the incompatible svg element with one that works with Internet Explorer, and modifies the flameviewColoring script to work with an older ECMA version.
> 
> Screenshot of Windows:
> ![windows-works](https://user-images.githubusercontent.com/10425301/72937103-7cd3b900-3d36-11ea-9939-8c71880cfbee.png)
> 
> For reference, here's the same view in Linux:
> ![2020-01-22-165007_1913x1031_scrot](https://user-images.githubusercontent.com/10425301/72937506-4480aa80-3d37-11ea-9628-431f240dd457.png)
> 
> When I had originally taken a look into the SWT Browser and compatibility with Windows, it looked as though we'd be able to use Edge as an embedded browser, which would be nice because it already plays nice with the d3-flame-graph library. After quite a bit of trial and error I was first able to get d3 to work (making simple line charts), and then found that d3-flame-graph version <= 2.0.2 will work. With this older version of d3-flame-graph the coloured labels will be drawn, but no text is shown - regardless of the SWT browser property being set to IE or Edge .. which makes it look like Edge can be used for visiting external webpages, but not local ones (internal browser stays IE). This is because the foreignObject element is incompatible with IE, and this has already been raised as an issue and closed as a "wontfix" by the maintainer on the upstream repo [[2]](https://github.com/spiermar/d3-flame-graph/issues/84). 
> 
> I made a fork of the d3-flame-graph repo [[1]](https://github.com/aptmac/d3-flame-graph), which accomplishes two things:
> - substitutes `<foreignObject>` for `<text>` [[3]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211)
> - trims the text in the labels because the ellipsis css doesn't work [[4]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238)
> 
> This forked version of d3-flame-graph is downloaded by the maven-download-plugin like the other jslibs, and is used if the Environment type is `WINDOWS` as detected in `FlameGraphView.java` [[5]](https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102).
> 
> Now that the flame chart view works at this point, I had to edit `flameviewColoring.java` to be compatible with IE. From what I can find, Internet Explorer uses JScript, which in it's latest version supports ECMA 5 [[6]](https://en.wikipedia.org/wiki/JScript#JScript). This means no maps, no named functions, etc.
> 
> Lastly, and not completely related to this issue, I changed the name of `page.template` to `template.html` because my IDE won't provide syntax highlighting unless the file ends with -.html, and it was a big help here. If it's deemed unecessary I can just drop the associated commit.
> 
> Let me know what you think!
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-6531
> [1] https://github.com/aptmac/d3-flame-graph
> [2] https://github.com/spiermar/d3-flame-graph/issues/84
> [3] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211
> [4] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238
> [5] https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102
> [6] https://en.wikipedia.org/wiki/JScript#JScript

The pull request has been updated with 1 additional commit.

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

Added commits:
 - c4c9e91a: fix spacing of <execution> tags in the pom.xml

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/41/files
  - new: https://git.openjdk.java.net/jmc/pull/41/files/3b354650..c4c9e91a

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

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

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

From jkang at openjdk.java.net  Wed Jan 22 22:29:57 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 22 Jan 2020 22:29:57 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
Message-ID: <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>

On Wed, 22 Jan 2020 21:57:59 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> This PR addresses JMC-6531 [[0]](https://bugs.openjdk.java.net/browse/JMC-6531), in which the flame chart view displays nothing in Windows.
> 
> tl;dr: the proposed solution uses a fork of d3-flame-graph [[1]](https://github.com/aptmac/d3-flame-graph) which substitutes the incompatible svg element with one that works with Internet Explorer, and modifies the flameviewColoring script to work with an older ECMA version.
> 
> Screenshot of Windows:
> ![windows-works](https://user-images.githubusercontent.com/10425301/72937103-7cd3b900-3d36-11ea-9939-8c71880cfbee.png)
> 
> For reference, here's the same view in Linux:
> ![2020-01-22-165007_1913x1031_scrot](https://user-images.githubusercontent.com/10425301/72937506-4480aa80-3d37-11ea-9628-431f240dd457.png)
> 
> When I had originally taken a look into the SWT Browser and compatibility with Windows, it looked as though we'd be able to use Edge as an embedded browser, which would be nice because it already plays nice with the d3-flame-graph library. After quite a bit of trial and error I was first able to get d3 to work (making simple line charts), and then found that d3-flame-graph version <= 2.0.2 will work. With this older version of d3-flame-graph the coloured labels will be drawn, but no text is shown - regardless of the SWT browser property being set to IE or Edge .. which makes it look like Edge can be used for visiting external webpages, but not local ones (internal browser stays IE). This is because the foreignObject element is incompatible with IE, and this has already been raised as an issue and closed as a "wontfix" by the maintainer on the upstream repo [[2]](https://github.com/spiermar/d3-flame-graph/issues/84). 
> 
> I made a fork of the d3-flame-graph repo [[1]](https://github.com/aptmac/d3-flame-graph), which accomplishes two things:
> - substitutes `<foreignObject>` for `<text>` [[3]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211)
> - trims the text in the labels because the ellipsis css doesn't work [[4]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238)
> 
> This forked version of d3-flame-graph is downloaded by the maven-download-plugin like the other jslibs, and is used if the Environment type is `WINDOWS` as detected in `FlameGraphView.java` [[5]](https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102).
> 
> Now that the flame chart view works at this point, I had to edit `flameviewColoring.java` to be compatible with IE. From what I can find, Internet Explorer uses JScript, which in it's latest version supports ECMA 5 [[6]](https://en.wikipedia.org/wiki/JScript#JScript). This means no maps, no named functions, etc.
> 
> Lastly, and not completely related to this issue, I changed the name of `page.template` to `template.html` because my IDE won't provide syntax highlighting unless the file ends with -.html, and it was a big help here. If it's deemed unecessary I can just drop the associated commit.
> 
> Let me know what you think!
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-6531
> [1] https://github.com/aptmac/d3-flame-graph
> [2] https://github.com/spiermar/d3-flame-graph/issues/84
> [3] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211
> [4] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238
> [5] https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102
> [6] https://en.wikipedia.org/wiki/JScript#JScript

The comment in the upstream d3-flame-graph suggests that there is no solution and unless someone comes up with one, nothing will change. Your commits in the fork seem to be a solution. Could that be proposed upstream? Does it introduce issues outside of IE?

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

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

From aptmac at openjdk.java.net  Thu Jan 23 15:36:20 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Thu, 23 Jan 2020 15:36:20 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
Message-ID: <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>

On Wed, 22 Jan 2020 22:29:20 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> This PR addresses JMC-6531 [[0]](https://bugs.openjdk.java.net/browse/JMC-6531), in which the flame chart view displays nothing in Windows.
>> 
>> tl;dr: the proposed solution uses a fork of d3-flame-graph [[1]](https://github.com/aptmac/d3-flame-graph) which substitutes the incompatible svg element with one that works with Internet Explorer, and modifies the flameviewColoring script to work with an older ECMA version.
>> 
>> Screenshot of Windows:
>> ![windows-works](https://user-images.githubusercontent.com/10425301/72937103-7cd3b900-3d36-11ea-9939-8c71880cfbee.png)
>> 
>> For reference, here's the same view in Linux:
>> ![2020-01-22-165007_1913x1031_scrot](https://user-images.githubusercontent.com/10425301/72937506-4480aa80-3d37-11ea-9628-431f240dd457.png)
>> 
>> When I had originally taken a look into the SWT Browser and compatibility with Windows, it looked as though we'd be able to use Edge as an embedded browser, which would be nice because it already plays nice with the d3-flame-graph library. After quite a bit of trial and error I was first able to get d3 to work (making simple line charts), and then found that d3-flame-graph version <= 2.0.2 will work. With this older version of d3-flame-graph the coloured labels will be drawn, but no text is shown - regardless of the SWT browser property being set to IE or Edge .. which makes it look like Edge can be used for visiting external webpages, but not local ones (internal browser stays IE). This is because the foreignObject element is incompatible with IE, and this has already been raised as an issue and closed as a "wontfix" by the maintainer on the upstream repo [[2]](https://github.com/spiermar/d3-flame-graph/issues/84). 
>> 
>> I made a fork of the d3-flame-graph repo [[1]](https://github.com/aptmac/d3-flame-graph), which accomplishes two things:
>> - substitutes `<foreignObject>` for `<text>` [[3]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211)
>> - trims the text in the labels because the ellipsis css doesn't work [[4]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238)
>> 
>> This forked version of d3-flame-graph is downloaded by the maven-download-plugin like the other jslibs, and is used if the Environment type is `WINDOWS` as detected in `FlameGraphView.java` [[5]](https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102).
>> 
>> Now that the flame chart view works at this point, I had to edit `flameviewColoring.java` to be compatible with IE. From what I can find, Internet Explorer uses JScript, which in it's latest version supports ECMA 5 [[6]](https://en.wikipedia.org/wiki/JScript#JScript). This means no maps, no named functions, etc.
>> 
>> Lastly, and not completely related to this issue, I changed the name of `page.template` to `template.html` because my IDE won't provide syntax highlighting unless the file ends with -.html, and it was a big help here. If it's deemed unecessary I can just drop the associated commit.
>> 
>> Let me know what you think!
>> 
>> [0] https://bugs.openjdk.java.net/browse/JMC-6531
>> [1] https://github.com/aptmac/d3-flame-graph
>> [2] https://github.com/spiermar/d3-flame-graph/issues/84
>> [3] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211
>> [4] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238
>> [5] https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102
>> [6] https://en.wikipedia.org/wiki/JScript#JScript
> 
> The comment in the upstream d3-flame-graph suggests that there is no solution and unless someone comes up with one, nothing will change. Your commits in the fork seem to be a solution. Could that be proposed upstream? Does it introduce issues outside of IE?

> The comment in the upstream d3-flame-graph suggests that there is no solution and unless someone comes up with one, nothing will change. Your commits in the fork seem to be a solution. Could that be proposed upstream? 

I'll post back on the original issue to see what they think. It looks like they start using ES6 syntax later on, which would explain why versions `> 2.0.2` don't work on IE, so inclusion of this work may be better suited for a branch of a prior version (2.0.2-ie?). 

> Does it introduce issues outside of IE?

Outside of IE I didn't encounter any problems (but I didn't check much more than seeing what it looked like if used in Linux for JMC), although with regards to this patch and JMC the modified JS is only used in Windows environments. 

There is a bit more computation in the fork - the text on the labels need to be trimmed for text-overflow instead of having the css format it. From what I understand, elements within `<svg>` tags all belong to the svg namespace, but putting elements inside a `<foreignObject>` [0] allows them to be recognized as being in the HTML namespace. So in the original code the text on the labels be treated as HTML and formatted by the css, but `svg text` doesn't appear to be formatted the same way, so there's an added function in the IE fork [1] that trims the text instead.

[0] https://www.w3.org/TR/SVG2/embedded.html#ForeignObjectElement
[1] https://github.com/aptmac/d3-flame-graph/blob/internet-explorer-compatibility/dist/d3-flamegraph-ie.js#L5242

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

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

From ehelin at openjdk.java.net  Thu Jan 23 15:55:02 2020
From: ehelin at openjdk.java.net (Erik Helin)
Date: Thu, 23 Jan 2020 15:55:02 GMT
Subject: [Rev 01] RFR: 6572: Make mbean functions protected by permission
 checks
In-Reply-To: <GlPqJT8iE-pMQynV6EQZoH6PVbOQbzhE8F2iKZb4Lz8=.ae5ff130-d885-485a-8d12-16eeb084d174@github.com>
References: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
 <rx4XJ4SANujYBGRGNuxl9i3XghiuRyjf0afMRYw9AOA=.21cbbaec-0be0-426e-b3a8-fc594db5443d@github.com>
 <GlPqJT8iE-pMQynV6EQZoH6PVbOQbzhE8F2iKZb4Lz8=.ae5ff130-d885-485a-8d12-16eeb084d174@github.com>
Message-ID: <YJDb2hWxSl9DrUyrKsiM_IunMYQ4MP41d8Y_QxKj6Ww=.46a6d210-6e66-4a35-9a28-2733fce17c8e@github.com>

On Wed, 22 Jan 2020 19:00:05 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Marked as reviewed by hirt (Lead).

Please ignore this comment, it is just to give the bots a nudge ??

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

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

From aptmac at openjdk.java.net  Thu Jan 23 16:39:08 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Thu, 23 Jan 2020 16:39:08 GMT
Subject: RFR: 6364: Improvements to the Thread Graph
In-Reply-To: <VtxWPdJ5lCNJANcyQQKDpUAc6oMz6sIIl4AdCngGzNY=.3e9e164a-aeca-4a31-9c0d-90b32e505e1f@github.com>
References: <3b_EN291IWMTMl6vId_3HM3r9b2p0Bjxd9QYH5qgDO8=.50cc047a-4486-469a-a341-5908f78bb6df@github.com>
 <9z2_Fmh0wzUWsp9Tu1bEudv8_BvAjeAC6RVPPe76FRQ=.1d13e3bc-3d48-4a9b-831f-40b784d57106@github.com>
 <RzkGUXMijABPraKoBm2yRnh7490ldPx8R1pVnLkZuQo=.49c6a560-d0bc-4870-8fc8-6b16c31a4edf@github.com>
 <VtxWPdJ5lCNJANcyQQKDpUAc6oMz6sIIl4AdCngGzNY=.3e9e164a-aeca-4a31-9c0d-90b32e505e1f@github.com>
Message-ID: <WlsAE5WBZzvaJ7y6s_9776LfwPZxInEyw-9tHkR8BYQ=.cac2ca35-320a-4955-b4ad-9f03cf91e67d@github.com>

On Mon, 20 Jan 2020 16:19:21 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>>> jcheck is requesting:
>>> 
>>> s/JMC-6364/6364
>> 
>> Neat, thanks for the heads up. I changed the commit description and force pushed them back here, but it looks like once a PR has been made with the invalid ID format it's the PR name change that gets jcheck to pass. This automation is nice, the `mvn spotless:apply` was especially nice to have.
> 
> I actually liked the old behaviour of being able to see all thread states on one screen (given that you had sufficient pixels to display them). It gave a more helpful overview of the application state during the recording. I.e. the old view had a minimum lane height of 1 pixel. To do the same thing here you'd have to collapse the table, since 1 pixel isn't enough to render thread names.
> 
> The selection highlighter also seems to have taken a significant performance hit, so it's a bit harder to drag and select a region of threads.
> 
> Unless I'm missing something it also appears that I can't sort the thread table, and I'm uncertain what order the threads are shown in now.
> 
> I'm also a bit confused by why the scroll bar on the right hand side scrolls horizontally when it's rendered vertically, and the component now doesn't zoom through time with the scroll wheel, like all other pages do?
> 
> It would also be nice if the "Thread State Selection" toolbar button could do more of the "Edit Thread Activity Lanes" dialog, since they're doing very similar things?

> I actually liked the old behaviour of being able to see all thread states on one screen (given that you had sufficient pixels to display them). It gave a more helpful overview of the application state during the recording. I.e. the old view had a minimum lane height of 1 pixel. To do the same thing here you'd have to collapse the table, since 1 pixel isn't enough to render thread names.

Fair enough, or perhaps allowing the chart lanes to shrink to that size, but have the text lanes remain at a size that is readable? e.g., having the text lanes hit a min height of ~13px, so there will only be a difference in lane height for 1-12px, and everything above that they re-sync in terms of height? 

> The selection highlighter also seems to have taken a significant performance hit, so it's a bit harder to drag and select a region of threads.
> 
> Unless I'm missing something it also appears that I can't sort the thread table, and I'm uncertain what order the threads are shown in now.

It should be the same order as they are now, the current table has been moved to be like a modal instead, it's available to open via a button near the "edit thread activity lanes" button in the top-right of the page. It's the same table, so the existing sorting mechanics should apply.

> I'm also a bit confused by why the scroll bar on the right hand side scrolls horizontally when it's rendered vertically, 

Are you referring to the SWT spinner? That handles zooming in/out of the chart, and the scrollbar to the right of the chart (should) scroll vertically.

> and the component now doesn't zoom through time with the scroll wheel, like all other pages do?
 
This has to do more with what the expected behaviour should be on a page that has scrollable content. In the cases of the other pages, the charts/graphs don't scroll vertically, so having JMC-specific defined controls with the scrollwheel to zoom should be fine. However, in many other applications where pages have scrollable content (e.g., internet browsers, photoshop, music editing software, etc.) the scrollwheel is reserved for vertically navigating the content.

> It would also be nice if the "Thread State Selection" toolbar button could do more of the "Edit Thread Activity Lanes" dialog, since they're doing very similar things?

I could take a look into that, the concern was that it's quite a bit of information/controls to fit into a dropdown of limited space without having it overlap too much of the chart content.

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

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

From hirt at openjdk.java.net  Thu Jan 23 23:15:29 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 23 Jan 2020 23:15:29 GMT
Subject: [Integrated] RFR: 6572: Make mbean functions protected by
 permission checks
In-Reply-To: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
References: <1Y3Plnbh5ixiHI0qlP2-w0kei9Mndrv-DMcDckUTsno=.997dce68-5f3a-4564-a969-605bd78bcd41@github.com>
Message-ID: <4d866680-06ff-45de-baf8-ec5f3f207c3c@openjdk.org>

Changeset: 2dd271f4
Author:    Jessye Coleman-Shapiro <jescolem at redhat.com>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-23 23:14:36 +0000
URL:       https://git.openjdk.java.net/jmc/commit/2dd271f4

6572: Make mbean functions protected by permission checks

Reviewed-by: hirt

! core/org.openjdk.jmc.agent/README.md
! core/org.openjdk.jmc.agent/pom.xml
! core/org.openjdk.jmc.agent/src/main/java/org/openjdk/jmc/agent/jmx/AgentController.java
+ core/org.openjdk.jmc.agent/src/test/java/org/openjdk/jmc/agent/test/TestPermissionChecks.java
+ core/org.openjdk.jmc.agent/src/test/resources/org/openjdk/jmc/agent/test/failing_control_permission.policy

From hirt at openjdk.java.net  Thu Jan 23 23:23:27 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 23 Jan 2020 23:23:27 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
Message-ID: <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>

On Thu, 23 Jan 2020 15:35:30 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> The comment in the upstream d3-flame-graph suggests that there is no solution and unless someone comes up with one, nothing will change. Your commits in the fork seem to be a solution. Could that be proposed upstream? Does it introduce issues outside of IE?
> 
>> The comment in the upstream d3-flame-graph suggests that there is no solution and unless someone comes up with one, nothing will change. Your commits in the fork seem to be a solution. Could that be proposed upstream? 
> 
> I'll post back on the original issue to see what they think. It looks like they start using ES6 syntax later on, which would explain why versions `> 2.0.2` don't work on IE, so inclusion of this work may be better suited for a branch of a prior version (2.0.2-ie?). 
> 
>> Does it introduce issues outside of IE?
> 
> Outside of IE I didn't encounter any problems (but I didn't check much more than seeing what it looked like if used in Linux for JMC), although with regards to this patch and JMC the modified JS is only used in Windows environments. 
> 
> There is a bit more computation in the fork - the text on the labels need to be trimmed for text-overflow instead of having the css format it. From what I understand, elements within `<svg>` tags all belong to the svg namespace, but putting elements inside a `<foreignObject>` [0] allows them to be recognized as being in the HTML namespace. So in the original code the text on the labels be treated as HTML and formatted by the css, but `svg text` doesn't appear to be formatted the same way, so there's an added function in the IE fork [1] that trims the text instead.
> 
> [0] https://www.w3.org/TR/SVG2/embedded.html#ForeignObjectElement
> [1] https://github.com/aptmac/d3-flame-graph/blob/internet-explorer-compatibility/dist/d3-flamegraph-ie.js#L5242

To me it's a bit scary (as in possibly maintenance heavy) to make a fork of the d3-library, rather than investing in making the SWT browser component work with Edge or chromium. This could potentially be a stop gap measure though. @mirage22, would this complicate anything you were planning on doing with the flame view?

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

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

From hirt at openjdk.java.net  Thu Jan 23 23:25:25 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 23 Jan 2020 23:25:25 GMT
Subject: [Rev 12] RFR: 6670: Harmonize ~ Unclassifiable ~ across Flame
 View and Stacktrace View
In-Reply-To: <WweSQ7y62JzWiDkhj80bxkYagUMkU10aPE3AaBDiaEI=.3561db3d-87f6-4666-bdce-aeee044eb286@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
 <WweSQ7y62JzWiDkhj80bxkYagUMkU10aPE3AaBDiaEI=.3561db3d-87f6-4666-bdce-aeee044eb286@github.com>
Message-ID: <8NluAC-euKUOSr0cR0EGdfWrUZBupVyYRe2VqV5Ob4A=.2087e392-5ecd-48d6-ae3f-4f7349158984@github.com>

On Thu, 23 Jan 2020 23:25:25 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> 6670 : Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View
>> https://bugs.openjdk.java.net/browse/JMC-6670
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by hirt (Lead).

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

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

From hirt at openjdk.java.net  Fri Jan 24 13:38:32 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 24 Jan 2020 13:38:32 GMT
Subject: [Integrated] RFR: 6670: harmonize unclassifiable across flameview
In-Reply-To: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
References: <Parelpw9WaF4r8Jz4Ba0fzrgcCgbHuxHShMpKDt7ko4=.86c1b859-a580-4522-90e6-ae005427cee3@github.com>
Message-ID: <aa0c7435-ce95-4661-9f91-577f3ec3a16d@openjdk.org>

Changeset: 875abcd3
Author:    Miroslav Wengner <mwengner at openjdk.org>
Committer: Marcus Hirt <hirt at openjdk.org>
Date:      2020-01-24 13:37:30 +0000
URL:       https://git.openjdk.java.net/jmc/commit/875abcd3

6670: Harmonize ~ Unclassifiable ~ across Flame View and Stacktrace View

Reviewed-by: hirt

! application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java
! application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/FlameGraphView.java
! application/org.openjdk.jmc.flightrecorder.flameview/src/main/js/flameviewColoring.js
! core/org.openjdk.jmc.flightrecorder/META-INF/MANIFEST.MF
+ core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/Messages.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/StacktraceFormatToolkit.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/messages/internal/Messages.java
+ core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages.properties
! core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages/internal/messages.properties
! core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages/internal/messages_ja.properties
! core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages/internal/messages_zh_CN.properties
+ core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages_ja.properties
+ core/org.openjdk.jmc.flightrecorder/src/main/resources/org/openjdk/jmc/flightrecorder/stacktrace/messages_zh_CN.properties

From hdafgard at openjdk.java.net  Fri Jan 24 15:48:06 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Fri, 24 Jan 2020 15:48:06 GMT
Subject: [Rev 03] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
Message-ID: <QzazNuO6JnExSTx3DA4nLptXXNpsgiZr-EGaMy9pTow=.bc5598c6-312f-49ea-b3d2-3ef9fd5034c5@github.com>

> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
> 
> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - f102abbb: Add test case with custm jfr file

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/31/files
  - new: https://git.openjdk.java.net/jmc/pull/31/files/9fdd627c..f102abbb

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

  Stats: 89 lines in 5 files changed: 86 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jmc/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/31/head:pull/31

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

From jkang at openjdk.java.net  Fri Jan 24 16:55:09 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Fri, 24 Jan 2020 16:55:09 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
 <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
Message-ID: <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>

On Thu, 23 Jan 2020 23:23:03 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>>> The comment in the upstream d3-flame-graph suggests that there is no solution and unless someone comes up with one, nothing will change. Your commits in the fork seem to be a solution. Could that be proposed upstream? 
>> 
>> I'll post back on the original issue to see what they think. It looks like they start using ES6 syntax later on, which would explain why versions `> 2.0.2` don't work on IE, so inclusion of this work may be better suited for a branch of a prior version (2.0.2-ie?). 
>> 
>>> Does it introduce issues outside of IE?
>> 
>> Outside of IE I didn't encounter any problems (but I didn't check much more than seeing what it looked like if used in Linux for JMC), although with regards to this patch and JMC the modified JS is only used in Windows environments. 
>> 
>> There is a bit more computation in the fork - the text on the labels need to be trimmed for text-overflow instead of having the css format it. From what I understand, elements within `<svg>` tags all belong to the svg namespace, but putting elements inside a `<foreignObject>` [0] allows them to be recognized as being in the HTML namespace. So in the original code the text on the labels be treated as HTML and formatted by the css, but `svg text` doesn't appear to be formatted the same way, so there's an added function in the IE fork [1] that trims the text instead.
>> 
>> [0] https://www.w3.org/TR/SVG2/embedded.html#ForeignObjectElement
>> [1] https://github.com/aptmac/d3-flame-graph/blob/internet-explorer-compatibility/dist/d3-flamegraph-ie.js#L5242
> 
> To me it's a bit scary (as in possibly maintenance heavy) to make a fork of the d3-library, rather than investing in making the SWT browser component work with Edge or chromium. This could potentially be a stop gap measure though. @mirage22, would this complicate anything you were planning on doing with the flame view?

While the guard to only use this on Windows does mitigate impact of this patch, I also am concerned with maintenance of a fork of the d3-flame-graph. I would rather see the upstream updated, or as Marcus stated, the SWT browser updated to use an alternative (newer) browser.

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

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

From aptmac at openjdk.java.net  Fri Jan 24 18:09:28 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Fri, 24 Jan 2020 18:09:28 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
 <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
 <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>
Message-ID: <B9U_4nf7rlcEdIKYkv1PC5fEJjNax4_vr1i2y5peneU=.a8a29aa1-255f-46fc-839e-be88c4fa4c64@github.com>

On Fri, 24 Jan 2020 16:54:52 GMT, Jie Kang <jkang at openjdk.org> wrote:

>> To me it's a bit scary (as in possibly maintenance heavy) to make a fork of the d3-library, rather than investing in making the SWT browser component work with Edge or chromium. This could potentially be a stop gap measure though. @mirage22, would this complicate anything you were planning on doing with the flame view?
> 
> While the guard to only use this on Windows does mitigate impact of this patch, I also am concerned with maintenance of a fork of the d3-flame-graph. I would rather see the upstream updated, or as Marcus stated, the SWT browser updated to use an alternative (newer) browser.

> While the guard to only use this on Windows does mitigate impact of this patch, I also am concerned with maintenance of a fork of the d3-flame-graph. I would rather see the upstream updated, or as Marcus stated, the SWT browser updated to use an alternative (newer) browser.

That sounds fair, I replied to the original Windows-related issue and tagged the repo owner, will comment back when there's a response.

In other news it looks like the latest version of Edge is based on Chromium [[0]](https://support.microsoft.com/en-ca/help/4501095/download-the-new-microsoft-edge-based-on-chromium), so getting Chromium support would be nice. Progress on that is tracked at https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585

[0] https://support.microsoft.com/en-ca/help/4501095/download-the-new-microsoft-edge-based-on-chromium

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

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

From mwengner at openjdk.java.net  Sat Jan 25 11:47:26 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Sat, 25 Jan 2020 11:47:26 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <B9U_4nf7rlcEdIKYkv1PC5fEJjNax4_vr1i2y5peneU=.a8a29aa1-255f-46fc-839e-be88c4fa4c64@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
 <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
 <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>
 <B9U_4nf7rlcEdIKYkv1PC5fEJjNax4_vr1i2y5peneU=.a8a29aa1-255f-46fc-839e-be88c4fa4c64@github.com>
Message-ID: <ivqR6SHKQaTTLSBQvLwmUhYhP99r1aOpbcbAqqKgb9E=.3d87afa0-eb46-4da5-917a-04e06ef6801a@github.com>

On Fri, 24 Jan 2020 18:09:15 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> While the guard to only use this on Windows does mitigate impact of this patch, I also am concerned with maintenance of a fork of the d3-flame-graph. I would rather see the upstream updated, or as Marcus stated, the SWT browser updated to use an alternative (newer) browser.
> 
>> While the guard to only use this on Windows does mitigate impact of this patch, I also am concerned with maintenance of a fork of the d3-flame-graph. I would rather see the upstream updated, or as Marcus stated, the SWT browser updated to use an alternative (newer) browser.
> 
> That sounds fair, I replied to the original Windows-related issue and tagged the repo owner, will comment back when there's a response.
> 
> In other news it looks like the latest version of Edge is based on Chromium [[0]](https://support.microsoft.com/en-ca/help/4501095/download-the-new-microsoft-edge-based-on-chromium), so getting Chromium support would be nice. Progress on that is tracked at https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585
> 
> [0] https://support.microsoft.com/en-ca/help/4501095/download-the-new-microsoft-edge-based-on-chromium

It doesn't feel right to me to maintain d3-flame-graph fork, as @thegreystone stated it's a bit scary.   
I'd rather to stay with ECMA 6 due to the d3 library compatibility and its future development. 

 I'd propose the way @thegreystone has stated -> SWT update to use an alternative (newer) browser.

we are planning to do the search/highlighting of nodes inside the flameview.  This feature uses d3-lib functionality. I don't know whether this patch will not force us to maintain also the fork of d3 itself.

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

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

From hirt at openjdk.java.net  Sat Jan 25 17:17:07 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Sat, 25 Jan 2020 17:17:07 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <ivqR6SHKQaTTLSBQvLwmUhYhP99r1aOpbcbAqqKgb9E=.3d87afa0-eb46-4da5-917a-04e06ef6801a@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
 <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
 <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>
 <B9U_4nf7rlcEdIKYkv1PC5fEJjNax4_vr1i2y5peneU=.a8a29aa1-255f-46fc-839e-be88c4fa4c64@github.com>
 <ivqR6SHKQaTTLSBQvLwmUhYhP99r1aOpbcbAqqKgb9E=.3d87afa0-eb46-4da5-917a-04e06ef6801a@github.com>
Message-ID: <dhqwrkYmSw-_S8X3cjdgm255hRvRj6QiJuYb2tHxwxc=.71022587-a601-485a-90be-4b788804c826@github.com>

On Sat, 25 Jan 2020 11:47:13 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>>> While the guard to only use this on Windows does mitigate impact of this patch, I also am concerned with maintenance of a fork of the d3-flame-graph. I would rather see the upstream updated, or as Marcus stated, the SWT browser updated to use an alternative (newer) browser.
>> 
>> That sounds fair, I replied to the original Windows-related issue and tagged the repo owner, will comment back when there's a response.
>> 
>> In other news it looks like the latest version of Edge is based on Chromium [[0]](https://support.microsoft.com/en-ca/help/4501095/download-the-new-microsoft-edge-based-on-chromium), so getting Chromium support would be nice. Progress on that is tracked at https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585
>> 
>> [0] https://support.microsoft.com/en-ca/help/4501095/download-the-new-microsoft-edge-based-on-chromium
> 
> It doesn't feel right to me to maintain d3-flame-graph fork, as @thegreystone stated it's a bit scary.   
> I'd rather to stay with ECMA 6 due to the d3 library compatibility and its future development. 
> 
>  I'd propose the way @thegreystone has stated -> SWT update to use an alternative (newer) browser.
> 
> we are planning to do the search/highlighting of nodes inside the flameview.  This feature uses d3-lib functionality. I don't know whether this patch will not force us to maintain also the fork of d3 itself.

How hard would it be to make SWT use Edge as the default embedded browser and fall back to IE if not available?

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

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

From github.com+3274268+jcompagner at openjdk.java.net  Sat Jan 25 17:31:56 2020
From: github.com+3274268+jcompagner at openjdk.java.net (Johan Compagner)
Date: Sat, 25 Jan 2020 17:31:56 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <dhqwrkYmSw-_S8X3cjdgm255hRvRj6QiJuYb2tHxwxc=.71022587-a601-485a-90be-4b788804c826@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
 <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
 <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>
 <B9U_4nf7rlcEdIKYkv1PC5fEJjNax4_vr1i2y5peneU=.a8a29aa1-255f-46fc-839e-be88c4fa4c64@github.com>
 <ivqR6SHKQaTTLSBQvLwmUhYhP99r1aOpbcbAqqKgb9E=.3d87afa0-eb46-4da5-917a-04e06ef6801a@github.com>
 <dhqwrkYmSw-_S8X3cjdgm255hRvRj6QiJuYb2tHxwxc=.71022587-a601-485a-90be-4b788804c826@github.com>
Message-ID: <irYKIOTn6R9YVa3heoMvbfl3SLq5bjmHmQssXEuvzjI=.c675192c-0ea3-4b80-b118-b896a9d1e035@github.com>

On Sat, 25 Jan 2020 17:16:51 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> It doesn't feel right to me to maintain d3-flame-graph fork, as @thegreystone stated it's a bit scary.   
>> I'd rather to stay with ECMA 6 due to the d3 library compatibility and its future development. 
>> 
>>  I'd propose the way @thegreystone has stated -> SWT update to use an alternative (newer) browser.
>> 
>> we are planning to do the search/highlighting of nodes inside the flameview.  This feature uses d3-lib functionality. I don't know whether this patch will not force us to maintain also the fork of d3 itself.
> 
> How hard would it be to make SWT use Edge as the default embedded browser and fall back to IE if not available?

> How hard would it be to make SWT use Edge as the default embedded browser and fall back to IE if not available?

I think that would be not so easy. Does MS support api for this to embed edge?
Besides that Edge engine is already also kind of depricated... It will be replaced with the a blink/chromium engine..

Not sure if MS will also standardize an engine to use embedded..
What do other native window apps use?

The chromium case for eclipse should just be picked up and fully supported in eclipse, in my eyes really importand, eclipse should ship with there own engine which should be the same then on all platforms..

Also on the Mac because of embedded safari we already have problems...

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

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

From aptmac at openjdk.java.net  Mon Jan 27 16:29:39 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Mon, 27 Jan 2020 16:29:39 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <dhqwrkYmSw-_S8X3cjdgm255hRvRj6QiJuYb2tHxwxc=.71022587-a601-485a-90be-4b788804c826@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
 <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
 <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>
 <B9U_4nf7rlcEdIKYkv1PC5fEJjNax4_vr1i2y5peneU=.a8a29aa1-255f-46fc-839e-be88c4fa4c64@github.com>
 <ivqR6SHKQaTTLSBQvLwmUhYhP99r1aOpbcbAqqKgb9E=.3d87afa0-eb46-4da5-917a-04e06ef6801a@github.com>
 <dhqwrkYmSw-_S8X3cjdgm255hRvRj6QiJuYb2tHxwxc=.71022587-a601-485a-90be-4b788804c826@github.com>
Message-ID: <itkPmgiko2hsdljIYUwUBlR7NrUydkfJmtQ6MW27Z3c=.58ebe3f4-9770-4ce0-8c65-d329722c9f59@github.com>

On Sat, 25 Jan 2020 17:16:51 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> It doesn't feel right to me to maintain d3-flame-graph fork, as @thegreystone stated it's a bit scary.   
>> I'd rather to stay with ECMA 6 due to the d3 library compatibility and its future development. 
>> 
>>  I'd propose the way @thegreystone has stated -> SWT update to use an alternative (newer) browser.
>> 
>> we are planning to do the search/highlighting of nodes inside the flameview.  This feature uses d3-lib functionality. I don't know whether this patch will not force us to maintain also the fork of d3 itself.
> 
> How hard would it be to make SWT use Edge as the default embedded browser and fall back to IE if not available?

> It doesn't feel right to me to maintain d3-flame-graph fork, as @thegreystone stated it's a bit scary.

As for "maintaining the fork", the next version up from the fork (v2.0.3) is incompatible with IE, so the fork is basically a one-shot fix that can't be updated. The interesting thing here is that we're using v2.0.3 (Sept 2018) , so if we had used just one release prior then the flame labels would have rendered in JMC Windows (without text) prior to the latest commits for colouring.

> I'd propose the way @thegreystone has stated -> SWT update to use an alternative (newer) browser.

Chromium support was initially slated for integration Q1 2017 [0], and the related patch looked to be on track to be posted by the end of 2019 [1], but it hasn't made it out yet. So when the patch does get posted, it'll need review, inclusion into SWT, and then shipped with a release .. we're looking at potentially quite a bit of time before this happens, but hopefully not.

I'm conflicted both ways, so I'll go based on the consensus here. I'm not sure how popular JMC is for Windows, or how many people are wanting (or trying) to use the flame view, but it doesn't sit right with me that the view doesn't display anything. Maybe it can print an error screen mentioning the incompatibility instead?

[0] https://projects.eclipse.org/development_effort/implement-swtchromium-integration
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585#c20

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

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

From hirt at openjdk.java.net  Mon Jan 27 17:00:43 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 27 Jan 2020 17:00:43 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <itkPmgiko2hsdljIYUwUBlR7NrUydkfJmtQ6MW27Z3c=.58ebe3f4-9770-4ce0-8c65-d329722c9f59@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
 <rQWhAfUNrrv9EZ1MJnai-yph6rBCN9j7nCK952DeU7Y=.ff750587-48e1-4eec-935d-ac24342b5592@github.com>
 <68acjbRMLklP3EHVSDntqrgJpPbAMXc_HVPpWxdUL2E=.1d2c78f4-ddda-4a33-ab00-e7cd1b116e80@github.com>
 <f0SFQCwQapl0oPglBdeITvNqyEyLVlMVSvu64MEEEEY=.5a18f0a1-6f5a-4860-81c8-29be08e444c3@github.com>
 <0eEKXCG5d03xu_ImemcyQ5KLGlJ3sQr55gGz6VljGJU=.0f85c639-7e93-446d-bc95-16b30849b38f@github.com>
 <B9U_4nf7rlcEdIKYkv1PC5fEJjNax4_vr1i2y5peneU=.a8a29aa1-255f-46fc-839e-be88c4fa4c64@github.com>
 <ivqR6SHKQaTTLSBQvLwmUhYhP99r1aOpbcbAqqKgb9E=.3d87afa0-eb46-4da5-917a-04e06ef6801a@github.com>
 <dhqwrkYmSw-_S8X3cjdgm255hRvRj6QiJuYb2tHxwxc=.71022587-a601-485a-90be-4b788804c826@github.com>
 <itkPmgiko2hsdljIYUwUBlR7NrUydkfJmtQ6MW27Z3c=.58ebe3f4-9770-4ce0-8c65-d329722c9f59@github.com>
Message-ID: <opva9CslSAJIo73UhX2buH8NF-eSx65NrByRGolLSz4=.d17812ef-c6ae-4269-8041-c9217e474a87@github.com>

On Mon, 27 Jan 2020 16:29:23 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> How hard would it be to make SWT use Edge as the default embedded browser and fall back to IE if not available?
> 
>> It doesn't feel right to me to maintain d3-flame-graph fork, as @thegreystone stated it's a bit scary.
> 
> As for "maintaining the fork", the next version up from the fork (v2.0.3) is incompatible with IE, so the fork is basically a one-shot fix that can't be updated. The interesting thing here is that we're using v2.0.3 (Sept 2018) , so if we had used just one release prior then the flame labels would have rendered in JMC Windows (without text) prior to the latest commits for colouring.
> 
>> I'd propose the way @thegreystone has stated -> SWT update to use an alternative (newer) browser.
> 
> Chromium support was initially slated for integration Q1 2017 [0], and the related patch looked to be on track to be posted by the end of 2019 [1], but it hasn't made it out yet. So when the patch does get posted, it'll need review, inclusion into SWT, and then shipped with a release .. we're looking at potentially quite a bit of time before this happens, but hopefully not.
> 
> I'm conflicted both ways, so I'll go based on the consensus here. I'm not sure how popular JMC is for Windows, or how many people are wanting (or trying) to use the flame view, but it doesn't sit right with me that the view doesn't display anything. Maybe it can print an error screen mentioning the incompatibility instead?
> 
> [0] https://projects.eclipse.org/development_effort/implement-swtchromium-integration
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585#c20

I think I'm ok with this being a stop-gap measure. It does make third party-dependencies a bit funny - and there is a bit of trust involved in getting the javascript from a private fork of a project, and even a private push of the resulting build to a CDN. As soon as the Eclipse changes are in, in any form and shape, we should switch.

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

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

From hdafgard at openjdk.java.net  Mon Jan 27 19:41:17 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 27 Jan 2020 19:41:17 GMT
Subject: [Rev 04] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
Message-ID: <om3Da4mAJWYXzRWUeurqDaMsj0ulISVmVvMdsfr2rBo=.0d69e7e8-b530-4a55-a27c-b948068342ca@github.com>

> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
> 
> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.

The pull request has been updated with 2 additional commits.

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

Added commits:
 - 5fddd578: Update test recording to include partially and completely overlapping events
 - e6c1b149: Improve test by using correct aggregators

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/31/files
  - new: https://git.openjdk.java.net/jmc/pull/31/files/f102abbb..5fddd578

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

  Stats: 47 lines in 2 files changed: 4 ins; 33 del; 10 mod
  Patch: https://git.openjdk.java.net/jmc/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/31/head:pull/31

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

From hdafgard at openjdk.java.net  Mon Jan 27 19:57:08 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 27 Jan 2020 19:57:08 GMT
Subject: [Rev 05] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
Message-ID: <9eGq78rcduO3SbF1gmMnYLyyTIkYpmRBpHV1ddc5xCg=.22974350-1522-42e8-8408-333ace4ba5f1@github.com>

> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
> 
> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.

The pull request has been updated with 1 additional commit.

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

Added commits:
 - f18c5d8e: Fix formatting

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/31/files
  - new: https://git.openjdk.java.net/jmc/pull/31/files/5fddd578..f18c5d8e

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

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

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

From hirt at openjdk.java.net  Mon Jan 27 20:44:15 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 27 Jan 2020 20:44:15 GMT
Subject: [Rev 05] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <9eGq78rcduO3SbF1gmMnYLyyTIkYpmRBpHV1ddc5xCg=.22974350-1522-42e8-8408-333ace4ba5f1@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
 <9eGq78rcduO3SbF1gmMnYLyyTIkYpmRBpHV1ddc5xCg=.22974350-1522-42e8-8408-333ace4ba5f1@github.com>
Message-ID: <JwfJUj4bgHAYeNWE-O--LrBVvA0a87eueRKUpbNPRUU=.b26b5935-9c6e-4fde-a4db-c24f3366ecf1@github.com>

On Mon, 27 Jan 2020 20:44:15 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

>> This optimization relies on the fact that event lanes are sorted by timestamp. This allows us to skip performing very costly comparisons when finding the first start time or first/last end times of an IItemCollection and instead just get the first or last events in each lane and find the event in that set that was earliest or last, respectively.
>> 
>> This PR also removes the associated aggregators to strongly encourage downstream users to make use of the added RulesToolkit methods.
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by hirt (Lead).

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

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

From hdafgard at openjdk.java.net  Mon Jan 27 21:25:14 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 27 Jan 2020 21:25:14 GMT
Subject: [Integrated] RFR: 6674: Optimize finding of first start time and
 first & last end times
In-Reply-To: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
References: <NJh5oaSIm1l3Owj4NCJB4P4U31S2pJLx5JrBrsn7jrA=.6549b62d-ee94-426d-a73f-0e555a8f98c7@github.com>
Message-ID: <4e8b8465-781f-4f5d-99fb-ce711641553b@openjdk.org>

Changeset: 6dd19dd5
Author:    Henrik Dafg?rd <hdafgard at openjdk.org>
Date:      2020-01-27 21:24:09 +0000
URL:       https://git.openjdk.java.net/jmc/commit/6dd19dd5

6674: Optimize finding of first start time and first & last end times

Reviewed-by: hirt

! application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/selection/FlavorToolkit.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/HaltsProvider.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLoadingRule.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/JavaBlockingRule.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/GcFreedRatioRule.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/memory/IncreasingLiveSetRule.java
! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/RulesToolkit.java
! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/util/SlidingWindowToolkit.java
! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java
! core/tests/org.openjdk.jmc.flightrecorder.test/META-INF/MANIFEST.MF
! core/tests/org.openjdk.jmc.flightrecorder.test/pom.xml
+ core/tests/org.openjdk.jmc.flightrecorder.test/src/test/java/org/openjdk/jmc/flightrecorder/test/OverlappingEventsTest.java
+ core/tests/org.openjdk.jmc.flightrecorder.test/src/test/resources/recordings/overlap.jfr

From aptmac at openjdk.java.net  Wed Jan 29 17:15:14 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Wed, 29 Jan 2020 17:15:14 GMT
Subject: [Rev 02] RFR: 6531: Make the flame chart view render labels on
 windows
In-Reply-To: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
References: <3T-jxid_jLmDFkY3ptEU22aLNooOUXnQhFEnAgI7ng8=.1467f94f-878e-41d1-a80c-0314da77ca50@github.com>
Message-ID: <kcl2Riz9z5VJuY2rTKDA5Cf57kvHJCkXm7yw7hCn4pw=.7e8d17e7-3c90-49bb-b5fd-980a6aade052@github.com>

> This PR addresses JMC-6531 [[0]](https://bugs.openjdk.java.net/browse/JMC-6531), in which the flame chart view displays nothing in Windows.
> 
> tl;dr: the proposed solution uses a fork of d3-flame-graph [[1]](https://github.com/aptmac/d3-flame-graph) which substitutes the incompatible svg element with one that works with Internet Explorer, and modifies the flameviewColoring script to work with an older ECMA version.
> 
> Screenshot of Windows:
> ![windows-works](https://user-images.githubusercontent.com/10425301/72937103-7cd3b900-3d36-11ea-9939-8c71880cfbee.png)
> 
> For reference, here's the same view in Linux:
> ![2020-01-22-165007_1913x1031_scrot](https://user-images.githubusercontent.com/10425301/72937506-4480aa80-3d37-11ea-9628-431f240dd457.png)
> 
> When I had originally taken a look into the SWT Browser and compatibility with Windows, it looked as though we'd be able to use Edge as an embedded browser, which would be nice because it already plays nice with the d3-flame-graph library. After quite a bit of trial and error I was first able to get d3 to work (making simple line charts), and then found that d3-flame-graph version <= 2.0.2 will work. With this older version of d3-flame-graph the coloured labels will be drawn, but no text is shown - regardless of the SWT browser property being set to IE or Edge .. which makes it look like Edge can be used for visiting external webpages, but not local ones (internal browser stays IE). This is because the foreignObject element is incompatible with IE, and this has already been raised as an issue and closed as a "wontfix" by the maintainer on the upstream repo [[2]](https://github.com/spiermar/d3-flame-graph/issues/84). 
> 
> I made a fork of the d3-flame-graph repo [[1]](https://github.com/aptmac/d3-flame-graph), which accomplishes two things:
> - substitutes `<foreignObject>` for `<text>` [[3]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211)
> - trims the text in the labels because the ellipsis css doesn't work [[4]](https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238)
> 
> This forked version of d3-flame-graph is downloaded by the maven-download-plugin like the other jslibs, and is used if the Environment type is `WINDOWS` as detected in `FlameGraphView.java` [[5]](https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102).
> 
> Now that the flame chart view works at this point, I had to edit `flameviewColoring.java` to be compatible with IE. From what I can find, Internet Explorer uses JScript, which in it's latest version supports ECMA 5 [[6]](https://en.wikipedia.org/wiki/JScript#JScript). This means no maps, no named functions, etc.
> 
> Lastly, and not completely related to this issue, I changed the name of `page.template` to `template.html` because my IDE won't provide syntax highlighting unless the file ends with -.html, and it was a big help here. If it's deemed unecessary I can just drop the associated commit.
> 
> Let me know what you think!
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-6531
> [1] https://github.com/aptmac/d3-flame-graph
> [2] https://github.com/spiermar/d3-flame-graph/issues/84
> [3] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49L5211
> [4] https://github.com/aptmac/d3-flame-graph/commit/c508e2ab95de2a48f03d655d6e7f306273dcaa12#diff-e866318288d23357a14da878e2435b49R5238
> [5] https://github.com/aptmac/jmc/commit/b64b4349057a67aeeb6b5ef560261cdb616a9d24#diff-9cb007d54dc422cf345941df647ef24cR102
> [6] https://en.wikipedia.org/wiki/JScript#JScript

The pull request has been updated with a new target base due to a merge or a rebase.

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

Commits:
 - 4258542a: update adjustTip() to be ECMA5 compatible
 - a9872588: fix spacing of <execution> tags in the pom.xml
 - 24912301: rename page.template to template.html for compatibility with IDE syntax highlighting
 - 22ecd073: 6531: Make the flame chart view render labels on windows

Changes: https://git.openjdk.java.net/jmc/pull/41/files
 Webrev: https://webrevs.openjdk.java.net/jmc/41/webrev.02
  Stats: 64 lines in 4 files changed: 31 ins; 0 del; 33 mod
  Patch: https://git.openjdk.java.net/jmc/pull/41.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/41/head:pull/41

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

From github.com+29706926+jessyec-s at openjdk.java.net  Fri Jan 31 06:53:12 2020
From: github.com+29706926+jessyec-s at openjdk.java.net (Jessye Coleman-Shapiro)
Date: Fri, 31 Jan 2020 06:53:12 GMT
Subject: RFR: 6643: Make VM Operations rule consider close consecutive events
 in score
Message-ID: <COLG87ZMfpZ4HrHal3_1lTFRjCFbRTgRR3EC82hPQns=.4c49025f-c712-4b2b-ae11-230076696c60@github.com>

This patch modifies the VM Operations rule's score calculation so that is considers blocking that could result from the combination of multiple close consecutive operations.  Right now an application's score only takes into account the longest event in its calculation. 

At the moment I have determined two events to be "close" if they occur within 0.01 s of one another.

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

Commits:
 - a2056e6f: Make VM Operations rule consider close consecutive events in score

Changes: https://git.openjdk.java.net/jmc/pull/42/files
 Webrev: https://webrevs.openjdk.java.net/jmc/42/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6643
  Stats: 110 lines in 3 files changed: 94 ins; 6 del; 10 mod
  Patch: https://git.openjdk.java.net/jmc/pull/42.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/42/head:pull/42

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

From aptmac at openjdk.java.net  Fri Jan 31 16:44:18 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Fri, 31 Jan 2020 16:44:18 GMT
Subject: RFR: 6682: Flamegraph gets cutoff when resized horizontally to
 increase the width
Message-ID: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>

Hi!

This PR addresses JMC-6682 [[0]](https://bugs.openjdk.java.net/browse/JMC-6682), in which the flamegraph can be cutoff when resizing to increase the width.

The issue is that the `d3-flame-graph` `width()` function updates the labels, but not the overall `svg` width. As a result, increasing the width of the container will cause the graph dimensions to increase, but the `svg width` stays the same as its initialized value, so clipping can occur. I've raised this as an issue in the upstream repo [[1]](https://github.com/spiermar/d3-flame-graph/issues/146), but altering the width can be done via `css`. If the `svg width` is set to `100%`, then it will fill the `chart` div, and the flamegraph will be displayed in its entirety. This width change also removes excess whitespace that results from resizing the chart smaller, and centers the chart in the view. I included a `css` file for the width value, because placing it in the template html was causing Eclipse to error when reading the html. Does the css file require a license header? I can add one if so.

There are also two other changes here, but I can remove this if desired. The first being that Eclipse kept throwing NPEs when trying to open `flameviewColoring.js`, because it couldn't find the file unless the path wasn't specified to be `src/main/js/[..]`. The second is that the chart container was a SWT `SashForm`, but this could have been a `Composite` because we aren't doing anything with the sash (unless that was a future usage type of thing).

[0] https://bugs.openjdk.java.net/browse/JMC-6682
[1] https://github.com/spiermar/d3-flame-graph/issues/146

Before:
![before-gif](https://user-images.githubusercontent.com/10425301/73555530-ce0d3800-441b-11ea-8e17-7ba33a95a133.gif)

After:
![fixed-gif](https://user-images.githubusercontent.com/10425301/73555525-cbaade00-441b-11ea-84e3-3085690e1c0f.gif)

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

Commits:
 - 87ab4c2d: replace the HTML container to be a Composite instead of a SashForm
 - 7be9fb54: 6682: Flamegraph gets cutoff when resized horizontally to increase the width

Changes: https://git.openjdk.java.net/jmc/pull/44/files
 Webrev: https://webrevs.openjdk.java.net/jmc/44/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6682
  Stats: 19 lines in 3 files changed: 8 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jmc/pull/44.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/44/head:pull/44

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

From mwengner at openjdk.java.net  Fri Jan 31 17:28:37 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Fri, 31 Jan 2020 17:28:37 GMT
Subject: RFR: 6682: Flamegraph gets cutoff when resized horizontally to
 increase the width
In-Reply-To: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
References: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
Message-ID: <yJCT0vnS4kk2zZ3eVg0XgxUGOj2KWsbQ4wemaoxfEUc=.f3e4188e-4ce7-4bb0-8b0f-225b12e9c675@github.com>

On Fri, 31 Jan 2020 16:32:40 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> Hi!
> 
> This PR addresses JMC-6682 [[0]](https://bugs.openjdk.java.net/browse/JMC-6682), in which the flamegraph can be cutoff when resizing to increase the width.
> 
> The issue is that the `d3-flame-graph` `width()` function updates the labels, but not the overall `svg` width. As a result, increasing the width of the container will cause the graph dimensions to increase, but the `svg width` stays the same as its initialized value, so clipping can occur. I've raised this as an issue in the upstream repo [[1]](https://github.com/spiermar/d3-flame-graph/issues/146), but altering the width can be done via `css`. If the `svg width` is set to `100%`, then it will fill the `chart` div, and the flamegraph will be displayed in its entirety. This width change also removes excess whitespace that results from resizing the chart smaller, and centers the chart in the view. I included a `css` file for the width value, because placing it in the template html was causing Eclipse to error when reading the html. Does the css file require a license header? I can add one if so.
> 
> There are also two other changes here, but I can remove this if desired. The first being that Eclipse kept throwing NPEs when trying to open `flameviewColoring.js`, because it couldn't find the file unless the path wasn't specified to be `src/main/js/[..]`. The second is that the chart container was a SWT `SashForm`, but this could have been a `Composite` because we aren't doing anything with the sash (unless that was a future usage type of thing).
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-6682
> [1] https://github.com/spiermar/d3-flame-graph/issues/146
> 
> Before:
> ![before-gif](https://user-images.githubusercontent.com/10425301/73555530-ce0d3800-441b-11ea-8e17-7ba33a95a133.gif)
> 
> After:
> ![fixed-gif](https://user-images.githubusercontent.com/10425301/73555525-cbaade00-441b-11ea-84e3-3085690e1c0f.gif)

I've it fixed in my PR 6677, what do we do ?

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

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

From mwengner at openjdk.java.net  Fri Jan 31 17:31:13 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Fri, 31 Jan 2020 17:31:13 GMT
Subject: RFR: 6682: Flamegraph gets cutoff when resized horizontally to
 increase the width
In-Reply-To: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
References: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
Message-ID: <KU3QikNhrhk3WM1GBcd0k9ictwxuQfVes8aKorDj8ug=.2d9c8e50-c2f2-49f8-aff8-e009cfe6b390@github.com>

On Fri, 31 Jan 2020 16:32:40 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

> Hi!
> 
> This PR addresses JMC-6682 [[0]](https://bugs.openjdk.java.net/browse/JMC-6682), in which the flamegraph can be cutoff when resizing to increase the width.
> 
> The issue is that the `d3-flame-graph` `width()` function updates the labels, but not the overall `svg` width. As a result, increasing the width of the container will cause the graph dimensions to increase, but the `svg width` stays the same as its initialized value, so clipping can occur. I've raised this as an issue in the upstream repo [[1]](https://github.com/spiermar/d3-flame-graph/issues/146), but altering the width can be done via `css`. If the `svg width` is set to `100%`, then it will fill the `chart` div, and the flamegraph will be displayed in its entirety. This width change also removes excess whitespace that results from resizing the chart smaller, and centers the chart in the view. I included a `css` file for the width value, because placing it in the template html was causing Eclipse to error when reading the html. Does the css file require a license header? I can add one if so.
> 
> There are also two other changes here, but I can remove this if desired. The first being that Eclipse kept throwing NPEs when trying to open `flameviewColoring.js`, because it couldn't find the file unless the path wasn't specified to be `src/main/js/[..]`. The second is that the chart container was a SWT `SashForm`, but this could have been a `Composite` because we aren't doing anything with the sash (unless that was a future usage type of thing).
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-6682
> [1] https://github.com/spiermar/d3-flame-graph/issues/146
> 
> Before:
> ![before-gif](https://user-images.githubusercontent.com/10425301/73555530-ce0d3800-441b-11ea-8e17-7ba33a95a133.gif)
> 
> After:
> ![fixed-gif](https://user-images.githubusercontent.com/10425301/73555525-cbaade00-441b-11ea-84e3-3085690e1c0f.gif)

I've fixed in my PR 6677 too, I didn't know about this ticket, what do we do ?

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

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

From aptmac at openjdk.java.net  Fri Jan 31 17:59:28 2020
From: aptmac at openjdk.java.net (Alex Macdonald)
Date: Fri, 31 Jan 2020 17:59:28 GMT
Subject: RFR: 6682: Flamegraph gets cutoff when resized horizontally to
 increase the width
In-Reply-To: <KU3QikNhrhk3WM1GBcd0k9ictwxuQfVes8aKorDj8ug=.2d9c8e50-c2f2-49f8-aff8-e009cfe6b390@github.com>
References: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
 <KU3QikNhrhk3WM1GBcd0k9ictwxuQfVes8aKorDj8ug=.2d9c8e50-c2f2-49f8-aff8-e009cfe6b390@github.com>
Message-ID: <YveY3YgwkNiS_-bAuJX24N3MkXAX3MnfOrN3jrPgIqY=.29605b22-6abd-4648-96e0-d2cb2d400123@github.com>

On Fri, 31 Jan 2020 17:30:38 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> Hi!
>> 
>> This PR addresses JMC-6682 [[0]](https://bugs.openjdk.java.net/browse/JMC-6682), in which the flamegraph can be cutoff when resizing to increase the width.
>> 
>> The issue is that the `d3-flame-graph` `width()` function updates the labels, but not the overall `svg` width. As a result, increasing the width of the container will cause the graph dimensions to increase, but the `svg width` stays the same as its initialized value, so clipping can occur. I've raised this as an issue in the upstream repo [[1]](https://github.com/spiermar/d3-flame-graph/issues/146), but altering the width can be done via `css`. If the `svg width` is set to `100%`, then it will fill the `chart` div, and the flamegraph will be displayed in its entirety. This width change also removes excess whitespace that results from resizing the chart smaller, and centers the chart in the view. I included a `css` file for the width value, because placing it in the template html was causing Eclipse to error when reading the html. Does the css file require a license header? I can add one if so.
>> 
>> There are also two other changes here, but I can remove this if desired. The first being that Eclipse kept throwing NPEs when trying to open `flameviewColoring.js`, because it couldn't find the file unless the path wasn't specified to be `src/main/js/[..]`. The second is that the chart container was a SWT `SashForm`, but this could have been a `Composite` because we aren't doing anything with the sash (unless that was a future usage type of thing).
>> 
>> [0] https://bugs.openjdk.java.net/browse/JMC-6682
>> [1] https://github.com/spiermar/d3-flame-graph/issues/146
>> 
>> Before:
>> ![before-gif](https://user-images.githubusercontent.com/10425301/73555530-ce0d3800-441b-11ea-8e17-7ba33a95a133.gif)
>> 
>> After:
>> ![fixed-gif](https://user-images.githubusercontent.com/10425301/73555525-cbaade00-441b-11ea-84e3-3085690e1c0f.gif)
> 
> I've fixed it in my PR 6677 too, I didn't know about this ticket. There will be few minor conflicts on the javascript side.
> Have you also tested resizing the main JMC window, more than initiated default size ?

> I've fixed it in my PR 6677 too, I didn't know about this ticket. There will be few minor conflicts on the javascript side.

Ah fair enough, I didn't realize it was also included in 6677. I had opened the ticket after searching JIRA and not finding an existing one.

Your PR fixes the increasing width issue, but when shrinking it still seems to keep excess whitespace to the right of the chart because the SVG doesn't resize to be smaller; the `svg width=100%` used in this PR would address that.

I can close this PR and make reference on the bug that it'll get closed by #43 .

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

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

From mwengner at openjdk.java.net  Fri Jan 31 18:30:17 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Fri, 31 Jan 2020 18:30:17 GMT
Subject: RFR: 6682: Flamegraph gets cutoff when resized horizontally to
 increase the width
In-Reply-To: <YveY3YgwkNiS_-bAuJX24N3MkXAX3MnfOrN3jrPgIqY=.29605b22-6abd-4648-96e0-d2cb2d400123@github.com>
References: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
 <KU3QikNhrhk3WM1GBcd0k9ictwxuQfVes8aKorDj8ug=.2d9c8e50-c2f2-49f8-aff8-e009cfe6b390@github.com>
 <YveY3YgwkNiS_-bAuJX24N3MkXAX3MnfOrN3jrPgIqY=.29605b22-6abd-4648-96e0-d2cb2d400123@github.com>
Message-ID: <lf0vCiQaz_UrYkZYm2Kc61PPv29gUZQNBIAs7-a2H2w=.1f454359-55a5-45eb-8dbf-e10f84776de5@github.com>

On Fri, 31 Jan 2020 17:58:42 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> I've fixed it in my PR 6677 too, I didn't know about this ticket. There will be few minor conflicts on the javascript side.
>> Have you also tested resizing the main JMC window, more than initiated default size ?
> 
>> I've fixed it in my PR 6677 too, I didn't know about this ticket. There will be few minor conflicts on the javascript side.
> 
> Ah fair enough, I didn't realize it was also included in 6677. I had opened the ticket after searching JIRA and not finding an existing one.
> 
> Your PR fixes the increasing width issue, but when shrinking it still seems to keep excess whitespace to the right of the chart because the SVG doesn't resize to be smaller; the `svg width=100%` used in this PR would address that.
> 
> I can close this PR and make reference on the bug that it'll get closed by #43 .

actually it was not, I've asked marcus whether I could include into this one, I didn't like the fact when you use splash or resize the window that the flameview stays. I've still used the magnitude 0.95. 

I've also fixed this part 
String jsFlameviewColoring = "src/main/js/flameviewColoring.js"; to work again like was intended 
String jsFlameviewColoring = "flameviewColoring.js";
This was caused by the classpath, somewhere it got lost because it was working before 

I think I'd propose to close the ticket due to work done in 6677 and make a reference.

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

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

From mwengner at openjdk.java.net  Fri Jan 31 18:31:38 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Fri, 31 Jan 2020 18:31:38 GMT
Subject: RFR: 6682: Flamegraph gets cutoff when resized horizontally to
 increase the width
In-Reply-To: <lf0vCiQaz_UrYkZYm2Kc61PPv29gUZQNBIAs7-a2H2w=.1f454359-55a5-45eb-8dbf-e10f84776de5@github.com>
References: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
 <KU3QikNhrhk3WM1GBcd0k9ictwxuQfVes8aKorDj8ug=.2d9c8e50-c2f2-49f8-aff8-e009cfe6b390@github.com>
 <YveY3YgwkNiS_-bAuJX24N3MkXAX3MnfOrN3jrPgIqY=.29605b22-6abd-4648-96e0-d2cb2d400123@github.com>
 <lf0vCiQaz_UrYkZYm2Kc61PPv29gUZQNBIAs7-a2H2w=.1f454359-55a5-45eb-8dbf-e10f84776de5@github.com>
Message-ID: <DYjOjdtfM89kcY5YYzPrFWPyDe7lTtSxXYHSE-IIgNM=.64ba9cf6-a25b-4b9c-9e43-5872d6316bed@github.com>

On Fri, 31 Jan 2020 18:29:49 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>>> I've fixed it in my PR 6677 too, I didn't know about this ticket. There will be few minor conflicts on the javascript side.
>> 
>> Ah fair enough, I didn't realize it was also included in 6677. I had opened the ticket after searching JIRA and not finding an existing one.
>> 
>> Your PR fixes the increasing width issue, but when shrinking it still seems to keep excess whitespace to the right of the chart because the SVG doesn't resize to be smaller; the `svg width=100%` used in this PR would address that.
>> 
>> I can close this PR and make reference on the bug that it'll get closed by #43 .
> 
> actually it was not, I've asked marcus whether I could include into this one, I didn't like the fact when you use splash or resize the window that the flameview stays. I've still used the magnitude 0.95. 
> 
> I've also fixed this part 
> String jsFlameviewColoring = "src/main/js/flameviewColoring.js"; to work again like was intended 
> String jsFlameviewColoring = "flameviewColoring.js";
> This was caused by the classpath, somewhere it got lost because it was working before 
> 
> I think I'd propose to close the ticket due to work done in 6677 and make a reference.

what do you think ?

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

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

From mwengner at openjdk.java.net  Fri Jan 31 19:02:18 2020
From: mwengner at openjdk.java.net (Miroslav Wengner)
Date: Fri, 31 Jan 2020 19:02:18 GMT
Subject: RFR: 6682: Flamegraph gets cutoff when resized horizontally to
 increase the width
In-Reply-To: <DYjOjdtfM89kcY5YYzPrFWPyDe7lTtSxXYHSE-IIgNM=.64ba9cf6-a25b-4b9c-9e43-5872d6316bed@github.com>
References: <hJ3srMsK6EtPPNKkSqznc-nFXtUIEvvfydLm4LAsmrc=.f33c97be-9f47-4006-ace3-cb5df06bec23@github.com>
 <KU3QikNhrhk3WM1GBcd0k9ictwxuQfVes8aKorDj8ug=.2d9c8e50-c2f2-49f8-aff8-e009cfe6b390@github.com>
 <YveY3YgwkNiS_-bAuJX24N3MkXAX3MnfOrN3jrPgIqY=.29605b22-6abd-4648-96e0-d2cb2d400123@github.com>
 <lf0vCiQaz_UrYkZYm2Kc61PPv29gUZQNBIAs7-a2H2w=.1f454359-55a5-45eb-8dbf-e10f84776de5@github.com>
 <DYjOjdtfM89kcY5YYzPrFWPyDe7lTtSxXYHSE-IIgNM=.64ba9cf6-a25b-4b9c-9e43-5872d6316bed@github.com>
Message-ID: <NOl7F2gxfxV_o2IAMQICjlvNzQrEZiH5oCbCPgWBRbo=.36ae0c0a-83b9-422e-a1a0-1bb2805a21e6@github.com>

On Fri, 31 Jan 2020 18:31:29 GMT, Miroslav Wengner <mwengner at openjdk.org> wrote:

>> actually it was not, I've asked marcus whether I could include into this one, I didn't like the fact when you use splash or resize the window that the flameview stays. I've still used the magnitude 0.95. 
>> 
>> I've also fixed this part 
>> String jsFlameviewColoring = "src/main/js/flameviewColoring.js"; to work again like was intended 
>> String jsFlameviewColoring = "flameviewColoring.js";
>> This was caused by the classpath, somewhere it got lost because it was working before 
>> 
>> I think I'd propose to close the ticket due to work done in 6677 and make a reference.
> 
> what do you think ? 
> I've also done in my ticket couple of other changes, would be great to close that one and make a reference to mine
> I can also  totally remove the width scale.

![image](https://user-images.githubusercontent.com/1956942/73566513-57485d00-4464-11ea-93f3-5b6f5c0a96df.png)
this is how looks mine result currently

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

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