From hirt at openjdk.java.net  Wed May  6 00:51:22 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 6 May 2020 00:51:22 GMT
Subject: RFR: 6778: Removing dependency on OPS4j maven repo and javax.mail:dsn
Message-ID: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>

Also upgrading jakarta.mail.

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

Commit messages:
 - 6778: Removing dependency on OPS4j maven repo and javax.mail:dsn, also upgrading jakarta.mail

Changes: https://git.openjdk.java.net/jmc/pull/73/files
 Webrev: https://webrevs.openjdk.java.net/jmc/73/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6778
  Stats: 27 lines in 7 files changed: 1 ins; 20 del; 6 mod
  Patch: https://git.openjdk.java.net/jmc/pull/73.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/73/head:pull/73

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

From jkang at openjdk.java.net  Wed May  6 14:23:49 2020
From: jkang at openjdk.java.net (Jie Kang)
Date: Wed, 6 May 2020 14:23:49 GMT
Subject: RFR: 6778: Removing dependency on OPS4j maven repo and
 javax.mail:dsn
In-Reply-To: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
References: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
Message-ID: <La7HUtF1aOZBTKqOLjELigR4FoS7MAHZWTH-RHgLsgo=.d01aab57-4c27-4f4c-a71a-049d6d412137@github.com>

On Wed, 6 May 2020 00:45:01 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also upgrading jakarta.mail.

Works for me.

I'm curious what dsn was used for before, or intended to be used for.

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

Marked as reviewed by jkang (Author).

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

From hdafgard at openjdk.java.net  Wed May  6 16:16:09 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 6 May 2020 16:16:09 GMT
Subject: RFR: 6778: Removing dependency on OPS4j maven repo and
 javax.mail:dsn
In-Reply-To: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
References: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
Message-ID: <GxCqOxLFsUkw7NOyXpQNH1TtLUJ4edagOOoQXqcUhrU=.84efb71c-4d5c-4445-8f91-7f0413354798@github.com>

On Wed, 6 May 2020 00:45:01 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also upgrading jakarta.mail.

Ship it!

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

Marked as reviewed by hdafgard (Reviewer).

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

From ghb at openjdk.java.net  Thu May  7 03:43:44 2020
From: ghb at openjdk.java.net (Guru Hb)
Date: Thu, 7 May 2020 03:43:44 GMT
Subject: RFR: 6778: Removing dependency on OPS4j maven repo and
 javax.mail:dsn
In-Reply-To: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
References: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
Message-ID: <5HPgmZZ-brmjjZUaDnw0RwhFgl3W4VXlsqhf8SwjJdM=.7819d1d3-7c1c-44f7-87b6-2270b7d70b9e@github.com>

On Wed, 6 May 2020 00:45:01 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also upgrading jakarta.mail.

Looks good to me

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

Marked as reviewed by ghb (Reviewer).

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

From hirt at openjdk.java.net  Thu May  7 13:39:52 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 7 May 2020 13:39:52 GMT
Subject: [Integrated] RFR: 6778: Removing dependency on OPS4j maven repo
 and javax.mail:dsn
In-Reply-To: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
References: <nSgs-u_Mcqf1waCJjy9THDM8T8TphWRBlKfhjSYqc1Y=.3da7ebbf-2c32-4d3b-be6a-5f0281d26b82@github.com>
Message-ID: <RkK3NRoUL_yznilP2I2QCn0a-gGCm-VixaYXab5MpdE=.3fc5c9f7-bcad-4e06-b959-85676dc82f13@github.com>

On Wed, 6 May 2020 00:45:01 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Also upgrading jakarta.mail.

This pull request has now been integrated.

Changeset: 9036f22b
Author:    Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/9036f22b
Stats:     27 lines in 7 files changed: 20 ins; 1 del; 6 mod

6778: Removing dependency on OPS4j maven repo and javax.mail:dsn

Co-authored-by: Jason Zaugg <jzaugg at gmail.com>
Reviewed-by: jkang, hdafgard, ghb

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

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

From hdafgard at openjdk.java.net  Fri May  8 17:22:01 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Fri, 8 May 2020 17:22:01 GMT
Subject: FYI: 6784: Getting rid of compiler warnings in the agent
In-Reply-To: <74X280YyjT63neKSKA_S1OwOm0RzbIbNOqyiAEwnR_I=.5f7edc05-9883-4d15-a080-89d212060215@github.com>
References: <74X280YyjT63neKSKA_S1OwOm0RzbIbNOqyiAEwnR_I=.5f7edc05-9883-4d15-a080-89d212060215@github.com>
Message-ID: <DCEwZr2kKVOa0ZUsDRiC55JbedFg80ilgtA0eXq_wpA=.ef90a1eb-612d-4e08-8b6b-8baa880a412a@github.com>

On Thu, 7 May 2020 15:44:05 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> What the title says.

LGTM! Don't forget to add something to the PR body.

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

Marked as reviewed by hdafgard (Reviewer).

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

From hirt at openjdk.java.net  Fri May  8 17:22:01 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 8 May 2020 17:22:01 GMT
Subject: FYI: 6784: Getting rid of compiler warnings in the agent
Message-ID: <74X280YyjT63neKSKA_S1OwOm0RzbIbNOqyiAEwnR_I=.5f7edc05-9883-4d15-a080-89d212060215@github.com>

What the title says.

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

Commit messages:
 - 6784: Getting rid of compiler warnings in the agent

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

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

From hirt at openjdk.java.net  Fri May  8 17:22:01 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 8 May 2020 17:22:01 GMT
Subject: [Integrated] FYI: 6784: Getting rid of compiler warnings in the
 agent
In-Reply-To: <74X280YyjT63neKSKA_S1OwOm0RzbIbNOqyiAEwnR_I=.5f7edc05-9883-4d15-a080-89d212060215@github.com>
References: <74X280YyjT63neKSKA_S1OwOm0RzbIbNOqyiAEwnR_I=.5f7edc05-9883-4d15-a080-89d212060215@github.com>
Message-ID: <e_2Q6eTArccdrNNedJD7TfTgkV1vkqEfwZ8GqnWxHQU=.f152d2b6-16db-46b6-8b8c-eba29d717627@github.com>

On Thu, 7 May 2020 15:44:05 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> What the title says.

This pull request has now been integrated.

Changeset: 5825cb40
Author:    Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/5825cb40
Stats:     10 lines in 4 files changed: 0 ins; 9 del; 1 mod

6784: Getting rid of compiler warnings in the agent

Reviewed-by: hdafgard

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

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

From hirt at openjdk.java.net  Fri May  8 22:20:02 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Fri, 8 May 2020 22:20:02 GMT
Subject: RFR: 6785: Compiler warning cleanup
Message-ID: <Femq5b1_CPJD0jStoISfpylM5Bj9a_X5nNNLpgXf9ao=.0c95a4ca-5cc1-4e5f-b87f-abaca0fd9261@github.com>

Cleaning up various compiler warnings. I've opened issues for some internal deprecated JMC APIs that we will need to
discuss a bit further.

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

Commit messages:
 - Formatting fix
 - Formatting fix
 - More cleanup
 - More cleanup
 - More cleanup
 - More cleanup
 - More cleanup
 - More cleanup
 - More cleanup
 - Deprecated use
 - ... and 7 more: https://git.openjdk.java.net/jmc/compare/5825cb40...4cb345e5

Changes: https://git.openjdk.java.net/jmc/pull/75/files
 Webrev: https://webrevs.openjdk.java.net/jmc/75/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6785
  Stats: 175 lines in 53 files changed: 55 ins; 80 del; 40 mod
  Patch: https://git.openjdk.java.net/jmc/pull/75.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/75/head:pull/75

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

From guru.hb at oracle.com  Wed May 13 06:57:55 2020
From: guru.hb at oracle.com (Guru)
Date: Wed, 13 May 2020 12:27:55 +0530
Subject: [backport][7.1.1] RFR: JMC-6783: OPS4J Maven Repo no longer available
Message-ID: <3CFEACAD-8825-4A55-808B-D30E2A00687D@oracle.com>

Hi,

Please review the fix (back port of https://bugs.openjdk.java.net/browse/JMC-6778 <https://bugs.openjdk.java.net/browse/JMC-6778> applicable to JMC 7.1.1 dev branch i.e http://hg.openjdk.java.net/jmc/jmc7 <http://hg.openjdk.java.net/jmc/jmc7>) 

JBS : https://bugs.openjdk.java.net/browse/JMC-6783 <https://bugs.openjdk.java.net/browse/JMC-6783> 
Web rev : http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.0/> 

Thanks,
Guru

From marcus.hirt at datadoghq.com  Wed May 13 12:17:38 2020
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Wed, 13 May 2020 14:17:38 +0200
Subject: [backport][7.1.1] RFR: JMC-6783: OPS4J Maven Repo no longer
 available
In-Reply-To: <3CFEACAD-8825-4A55-808B-D30E2A00687D@oracle.com>
References: <3CFEACAD-8825-4A55-808B-D30E2A00687D@oracle.com>
Message-ID: <CAOpWGx3v+DYhJ4yMHqQYmzqhmDetFe_fW4ekZj=S9Gd16GQ+mw@mail.gmail.com>

Hi Guru,

You also want to remove:
<repositories>
<repository>
<id>OPS4j</id>
<url>http://repository.ops4j.org/maven2/</url>
</repository>
</repositories>

From:
https://hg.openjdk.java.net/jmc/jmc7/file/f44a5b681305/releng/third-party/pom.xml

Kind regards,
Marcus

On Wed, May 13, 2020 at 8:58 AM Guru <guru.hb at oracle.com> wrote:
>
> Hi,
>
> Please review the fix (back port of https://bugs.openjdk.java.net/browse/JMC-6778 applicable to JMC 7.1.1 dev branch i.e http://hg.openjdk.java.net/jmc/jmc7)
>
> JBS : https://bugs.openjdk.java.net/browse/JMC-6783
> Web rev : http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.0/
>
> Thanks,
> Guru

From guru.hb at oracle.com  Wed May 13 12:29:56 2020
From: guru.hb at oracle.com (Guru)
Date: Wed, 13 May 2020 17:59:56 +0530
Subject: [backport][7.1.1] RFR: JMC-6783: OPS4J Maven Repo no longer
 available
In-Reply-To: <CAOpWGx3v+DYhJ4yMHqQYmzqhmDetFe_fW4ekZj=S9Gd16GQ+mw@mail.gmail.com>
References: <3CFEACAD-8825-4A55-808B-D30E2A00687D@oracle.com>
 <CAOpWGx3v+DYhJ4yMHqQYmzqhmDetFe_fW4ekZj=S9Gd16GQ+mw@mail.gmail.com>
Message-ID: <EF0326CF-35C1-4726-9F21-FC5CFB46953A@oracle.com>

Thank you Marcus, 

Please find updated web rev : http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.1/ <http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.1/> 

-Guru
> On 13-May-2020, at 5:47 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> 
> Hi Guru,
> 
> You also want to remove:
> <repositories>
> <repository>
> <id>OPS4j</id>
> <url>http://repository.ops4j.org/maven2/</url>
> </repository>
> </repositories>
> 
> From:
> https://hg.openjdk.java.net/jmc/jmc7/file/f44a5b681305/releng/third-party/pom.xml
> 
> Kind regards,
> Marcus
> 
> On Wed, May 13, 2020 at 8:58 AM Guru <guru.hb at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review the fix (back port of https://bugs.openjdk.java.net/browse/JMC-6778 applicable to JMC 7.1.1 dev branch i.e http://hg.openjdk.java.net/jmc/jmc7)
>> 
>> JBS : https://bugs.openjdk.java.net/browse/JMC-6783
>> Web rev : http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.0/
>> 
>> Thanks,
>> Guru


From marcus.hirt at datadoghq.com  Wed May 13 12:45:36 2020
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Wed, 13 May 2020 14:45:36 +0200
Subject: [backport][7.1.1] RFR: JMC-6783: OPS4J Maven Repo no longer
 available
In-Reply-To: <EF0326CF-35C1-4726-9F21-FC5CFB46953A@oracle.com>
References: <3CFEACAD-8825-4A55-808B-D30E2A00687D@oracle.com>
 <CAOpWGx3v+DYhJ4yMHqQYmzqhmDetFe_fW4ekZj=S9Gd16GQ+mw@mail.gmail.com>
 <EF0326CF-35C1-4726-9F21-FC5CFB46953A@oracle.com>
Message-ID: <CAOpWGx1rUe962-xnMXWunn3jCNk-MC5y+Mqi554qh4V7x6---Q@mail.gmail.com>

LGTM!

Kind regards,
Marcus

On Wed, May 13, 2020 at 2:30 PM Guru <guru.hb at oracle.com> wrote:
>
> Thank you Marcus,
>
> Please find updated web rev : http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.1/
>
> -Guru
>
> On 13-May-2020, at 5:47 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>
> Hi Guru,
>
> You also want to remove:
> <repositories>
> <repository>
> <id>OPS4j</id>
> <url>http://repository.ops4j.org/maven2/</url>
> </repository>
> </repositories>
>
> From:
> https://hg.openjdk.java.net/jmc/jmc7/file/f44a5b681305/releng/third-party/pom.xml
>
> Kind regards,
> Marcus
>
> On Wed, May 13, 2020 at 8:58 AM Guru <guru.hb at oracle.com> wrote:
>
>
> Hi,
>
> Please review the fix (back port of https://bugs.openjdk.java.net/browse/JMC-6778 applicable to JMC 7.1.1 dev branch i.e http://hg.openjdk.java.net/jmc/jmc7)
>
> JBS : https://bugs.openjdk.java.net/browse/JMC-6783
> Web rev : http://cr.openjdk.java.net/~ghb/JMC-6778/webrev.0/
>
> Thanks,
> Guru
>
>

From guru.hb at oracle.com  Wed May 13 12:59:55 2020
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Wed, 13 May 2020 12:59:55 +0000
Subject: hg: jmc/jmc7: JMC-6778: OPS4J Maven Repo no longer available
Message-ID: <202005131259.04DCxtB9024884@aojmv0008.oracle.com>

Changeset: 7f192d4bf6b9
Author:    ghb <guru.hb at oracle.com>
Date:      2020-05-13 18:29 +0530
URL:       https://hg.openjdk.java.net/jmc/jmc7/rev/7f192d4bf6b9

JMC-6778: OPS4J Maven Repo no longer available
Co-authored-by: Jason Zaugg <jzaugg at gmail.com>
Reviewed-by: hirt

! application/org.openjdk.jmc.feature.core/feature.xml
! releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target
! releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target
! releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target
! releng/platform-definitions/platform-definition-2019-06/platform-definition-2019-06.target
! releng/platform-definitions/platform-definition-2019-09/platform-definition-2019-09.target
! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target
! releng/third-party/pom.xml


From marcus at hirt.se  Thu May 14 22:14:16 2020
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 15 May 2020 00:14:16 +0200
Subject: Sprint 4 is (finally) dead - long live Sprint 5 (perhaps just not for
 quite as long)
Message-ID: <63d0a32e-5056-7e5a-5e0f-d7f3dd5614b7@hirt.se>

Hi all,

I just put Sprint 4 to rest. Many thanks to everyone who contributed.
I?ll start off Sprint 5 on Monday ? please feel free to add things that
you want to work on for the upcoming Sprint 5. I'm thinking of ending
the sprint on the night of our dev team hangouts from now on, so we can
all demo what we've achieved. Next sprint could for example end the 10th
of June. What do you think?

Kind regards,
Marcus


From hdafgard at openjdk.java.net  Mon May 18 12:22:17 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Mon, 18 May 2020 12:22:17 GMT
Subject: RFR: 6785: Compiler warning cleanup
In-Reply-To: <Femq5b1_CPJD0jStoISfpylM5Bj9a_X5nNNLpgXf9ao=.0c95a4ca-5cc1-4e5f-b87f-abaca0fd9261@github.com>
References: <Femq5b1_CPJD0jStoISfpylM5Bj9a_X5nNNLpgXf9ao=.0c95a4ca-5cc1-4e5f-b87f-abaca0fd9261@github.com>
Message-ID: <kIjPuayq7zjm4Ara5NU9ckrz4GRr7rZVzZ9OYHi5K7o=.bdf2d62c-2523-4da8-9a3f-6085e5db57ed@github.com>

On Fri, 8 May 2020 22:14:14 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Cleaning up various compiler warnings. I've opened issues for some internal deprecated JMC APIs that we will need to
> discuss a bit further.

Marked as reviewed by hdafgard (Reviewer).

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

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

From hirt at openjdk.java.net  Mon May 18 12:28:01 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 18 May 2020 12:28:01 GMT
Subject: [Integrated] RFR: 6785: Compiler warning cleanup
In-Reply-To: <Femq5b1_CPJD0jStoISfpylM5Bj9a_X5nNNLpgXf9ao=.0c95a4ca-5cc1-4e5f-b87f-abaca0fd9261@github.com>
References: <Femq5b1_CPJD0jStoISfpylM5Bj9a_X5nNNLpgXf9ao=.0c95a4ca-5cc1-4e5f-b87f-abaca0fd9261@github.com>
Message-ID: <TcHASZL648vgIFrwoRnkxtOSN9sJ0miKo8fsxkutUhU=.3acb1197-838e-48e8-a216-642aa1f0882f@github.com>

On Fri, 8 May 2020 22:14:14 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Cleaning up various compiler warnings. I've opened issues for some internal deprecated JMC APIs that we will need to
> discuss a bit further.

This pull request has now been integrated.

Changeset: 06b35635
Author:    Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/06b35635
Stats:     176 lines in 53 files changed: 81 ins; 56 del; 39 mod

6785: Compiler warning cleanup

Reviewed-by: hdafgard

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

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

From hdafgard at openjdk.java.net  Wed May 20 17:26:25 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Wed, 20 May 2020 17:26:25 GMT
Subject: RFR: 6801: Rewrite stackdepth setting rule for speed
Message-ID: <2uzG1SEUkLUXuQhTlwMNoVkiRrDOJiG7cfeEAhNZWpg=.0ba8168c-875d-4d3d-90df-46c6f50efb48@github.com>

Rewrites the stackdepth setting rule to complete in one pass over all events with stacktraces. Also sorts the resulting
list of event types with truncated traces.

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

Commit messages:
 - Fix formatting
 - Rewrite stackdepth setting rule for speed

Changes: https://git.openjdk.java.net/jmc/pull/76/files
 Webrev: https://webrevs.openjdk.java.net/jmc/76/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6801
  Stats: 4487 lines in 2 files changed: 24 ins; 29 del; 4434 mod
  Patch: https://git.openjdk.java.net/jmc/pull/76.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/76/head:pull/76

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

From hirt at openjdk.java.net  Thu May 21 12:35:18 2020
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Thu, 21 May 2020 12:35:18 GMT
Subject: RFR: 6801: Improve stackdepth setting rule
In-Reply-To: <2uzG1SEUkLUXuQhTlwMNoVkiRrDOJiG7cfeEAhNZWpg=.0ba8168c-875d-4d3d-90df-46c6f50efb48@github.com>
References: <2uzG1SEUkLUXuQhTlwMNoVkiRrDOJiG7cfeEAhNZWpg=.0ba8168c-875d-4d3d-90df-46c6f50efb48@github.com>
Message-ID: <exs7rsXkm7yazfzO0aMgEG03Ld5sVE_dhD-1wGYdtO0=.c77a40fb-3c9e-40ae-9de3-ed333f827ba2@github.com>

On Wed, 20 May 2020 17:20:17 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

> Rewrites the stackdepth setting rule to complete in one pass over all events with stacktraces. Also sorts the resulting
> list of event types with truncated traces.

Marked as reviewed by hirt (Lead).

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

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

From hdafgard at openjdk.java.net  Fri May 22 13:47:00 2020
From: hdafgard at openjdk.java.net (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Fri, 22 May 2020 13:47:00 GMT
Subject: [Integrated] RFR: 6801: Improve stackdepth setting rule
In-Reply-To: <2uzG1SEUkLUXuQhTlwMNoVkiRrDOJiG7cfeEAhNZWpg=.0ba8168c-875d-4d3d-90df-46c6f50efb48@github.com>
References: <2uzG1SEUkLUXuQhTlwMNoVkiRrDOJiG7cfeEAhNZWpg=.0ba8168c-875d-4d3d-90df-46c6f50efb48@github.com>
Message-ID: <XPLHtGXmc-1eXUNH6zyFo6cy1q9HOTjFrzjxPocoNnY=.53e5f3c5-5207-421e-9e20-64281b4ed932@github.com>

On Wed, 20 May 2020 17:20:17 GMT, Henrik Dafg?rd <hdafgard at openjdk.org> wrote:

> Rewrites the stackdepth setting rule to complete in one pass over all events with stacktraces. Also sorts the resulting
> list of event types with truncated traces.

This pull request has now been integrated.

Changeset: bb6765d7
Author:    Henrik Dafg?rd <hdafgard at openjdk.org>
URL:       https://git.openjdk.java.net/jmc/commit/bb6765d7
Stats:     4487 lines in 2 files changed: 29 ins; 24 del; 4434 mod

6801: Improve stackdepth setting rule

Reviewed-by: hirt

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

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

From erik.gahlin at oracle.com  Wed May 27 15:20:19 2020
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 27 May 2020 17:20:19 +0200
Subject: RFR(xs): 8245926: JFR: Remove chunkSz and rename blockSz from
 classloader statistics
In-Reply-To: <CAA-vtUx0RZ3_RcE0qGXVybC42TxqP3TVmnE2mmMAT4d=X7PV1w@mail.gmail.com>
References: <CAA-vtUxEWrWiXEw=B4W8+Sr2ihOb7po6LJqgWGUbATEqVcuCvQ@mail.gmail.com>
 <2AAE0A43-3B79-4A04-B7AB-03E3D4C13633@oracle.com>
 <CAA-vtUx0RZ3_RcE0qGXVybC42TxqP3TVmnE2mmMAT4d=X7PV1w@mail.gmail.com>
Message-ID: <BA1E8B64-4A6D-4B24-A750-5A853E42CD6D@oracle.com>

Hi Thomas.

> 
> 
> On Wed, May 27, 2020 at 10:06 AM Erik Gahlin <erik.gahlin at oracle.com <mailto:erik.gahlin at oracle.com>> wrote:
> Hi Thomas, 
> 
> An important use case for JFR is to have all relevant information available for support since they can?t typically run jcmd. If jcmd has better information, I think we should strive to make that information available for JFR as well.
> 
> An alternative would be to create a new event for metaspace targeted for JVM engineers/support, with similar information as jcmd(?), and only keep fields relevant to a Java developer in ClassLoaderStatistics.
> 
> Thanks
> Erik 
> 
> 
> Okay, you have a point. I may have misunderstood you before.

Sorry for the mixed message, but when you said jcmd had better information, it got me thinking.

Maybe we should create something more useful than just modify what we have today?

> I'll withdraw the RFE for now. Since a lot of implementation details will change, if this kind of detail is to be exposed via JFR, this will need brushing after JDK-8221173 hits mainline anyway so it makes no sense to put much work into it now.

Sounds good.

> 
> My question about backward compatibility remains though: can one just change/remove event fields? I assume JMC uses those fields for things beyond displaying events in the generic event browser, yes? How does JMC handle backward compatibility - is it only supposed to work with one hotspot or with a range of them?

Users of the API should check that a field exists. It is stated in the Javadoc.

JMC has its own parser and it supports JVMs back to JDK 7 so there is a mechanism to handle missing information. 

That said, we should not remove/change fields unless there is a good reason. 

> 
> For instance, the "Class Loader Statistics" Tab in the "Class Loading" section of the VM still talks about "Anonymous Classes" and shows no content there; I assume this was broken with the Hidden Classes JEP which renamed the fields in ClassLoaderStatistics from "Anonymousxxx" to "Hiddenxxx". So is it bound to one specific hotspot version? Just a guess, I did not look at the JMC sources.

I?m looping in JMC, so they can file a bug on it. 

Thanks
Erik

> 
> Thanks, Thomas
> 
> 
> 
> > On 27 May 2020, at 08:57, Thomas St?fe <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
> > 
> > Hi,
> > 
> > may I have opinions/reviews for this change please:
> > 
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8245926 <https://bugs.openjdk.java.net/browse/JDK-8245926>
> > Webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8245926-jfr-remove-chunksz-rename-blocksz/webrev.00/webrev/ <http://cr.openjdk.java.net/~stuefe/webrevs/8245926-jfr-remove-chunksz-rename-blocksz/webrev.00/webrev/>
> > 
> > This is part of an effort to reduce exposure of Metaspace implementation
> > details somewhat in preparation for JDK-8221173.
> > 
> > In JFR, the classloader statistics event contains the following fields:
> > 
> > chunkSize
> > blockSize
> > hiddenChunkSize
> > hiddenBlockSize
> > 
> > blockSize is the interesting one, the number of bytes of Metaspace used by
> > this class loader for storing metadata. I propose to rename this to
> > "totalMetaspaceUsed" resp. "hiddenClassesMetaspaceUsed".
> > 
> > chunkSize is the total size of chunks given to a class loader. Delta
> > between blockSize and chunkSize constitutes waste if the loader stops
> > loading; however, as far as waste goes this is not very informative since
> > it only is a usually small part of waste in the current metaspace
> > allocator.
> > 
> > Moreover, with JDK-8221173 chunks may be partially uncommitted, so that the
> > delta between chunkSize and blockSize may or may not contribute to RSS. So
> > the chunkSize stat becomes more meaningless.
> > 
> > I'd argue that this stat is quite useless to the average JFR user; and to
> > the VM developer interested in fixing up Metaspace there are better tools
> > (e.g. jcmd VM.metaspace). Therefore I would like to simply remove this stat.
> > 
> > --
> > 
> > Please note that this is my first change to JFR events. Some things are
> > unclear to me, e.g. how backward compatibility in JMC is handled. So if
> > something is missing from the patch, please advice.
> > 
> > 
> > Thanks!
> > 
> > .. Thomas
> 


From github.com+4906592+cogman at openjdk.java.net  Wed May 27 16:44:36 2020
From: github.com+4906592+cogman at openjdk.java.net (Thomas May)
Date: Wed, 27 May 2020 16:44:36 GMT
Subject: RFR: 6531: Make the flame chart view render labels on windows
In-Reply-To: <Vh6y9PFfZPHx57kQa0QA-mcV_68mk4jm72D4-TMwiqE=.2df41d2a-530f-4334-8797-cd558464bea6@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>
 <opva9CslSAJIo73UhX2buH8NF-eSx65NrByRGolLSz4=.d17812ef-c6ae-4269-8041-c9217e474a87@github.com>
 <Vh6y9PFfZPHx57kQa0QA-mcV_68mk4jm72D
 4-TMwiqE=.2df41d2a-530f-4334-8797-cd558464bea6@github.com>
Message-ID: <gpGSErP1mGcoi0VDtFKAORTmv9DGAsRy3EdmCXlEiOI=.2f4acfb4-4fb6-4a64-b2ed-fc3532089783@github.com>

On Mon, 24 Feb 2020 20:36:01 GMT, Alex Macdonald <aptmac at openjdk.org> wrote:

>> 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.
>
>> As soon as the Eclipse changes are in, in any form and shape, we should switch.
> 
> Agreed, it would be very limiting to continue on this way.
> 
> This PR required some rebasing after the latest flamegraph commits to include colour highlighting. I had to include an
> additional commit here that allows for the colouring to work with IE, because some syntax and functions are too
> advanced for ES2015.  About the `flameviewColoring.js`, I made the changes in the file to make it compatible with IE,
> but would it be worthwhile to go the route of making a `flameviewColoring-ie.js` so that if/when Chromium functionality
> is introduced instead of refactoring the colouring script we could just drop the `-ie` version? Let me know your
> thoughts on this one.  Here's an example screenshot of it working in Windows with text highlighting:
> ![windows-highlighting](https://user-images.githubusercontent.com/10425301/75188682-92177b00-571a-11ea-9a3f-e8bd7b91d3b9.png)

Dumb question, but would a shorter path be to run babel against d3 (Or have that as part of the build?)

That would eliminate the need to maintain your own version and make updating a lot easier.

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

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

From thomas.stuefe at gmail.com  Wed May 27 16:46:42 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 27 May 2020 18:46:42 +0200
Subject: RFR(xs): 8245926: JFR: Remove chunkSz and rename blockSz from
 classloader statistics
In-Reply-To: <BA1E8B64-4A6D-4B24-A750-5A853E42CD6D@oracle.com>
References: <CAA-vtUxEWrWiXEw=B4W8+Sr2ihOb7po6LJqgWGUbATEqVcuCvQ@mail.gmail.com>
 <2AAE0A43-3B79-4A04-B7AB-03E3D4C13633@oracle.com>
 <CAA-vtUx0RZ3_RcE0qGXVybC42TxqP3TVmnE2mmMAT4d=X7PV1w@mail.gmail.com>
 <BA1E8B64-4A6D-4B24-A750-5A853E42CD6D@oracle.com>
Message-ID: <CAA-vtUyyRR-eU0fRaXLZEd_TiyLx1i4YuOjgZVFFmJtxEAZRow@mail.gmail.com>

Hi Erik,


On Wed, May 27, 2020 at 5:20 PM Erik Gahlin <erik.gahlin at oracle.com> wrote:

> Hi Thomas.
>
>
>
> On Wed, May 27, 2020 at 10:06 AM Erik Gahlin <erik.gahlin at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> An important use case for JFR is to have all relevant information
>> available for support since they can?t typically run jcmd. If jcmd has
>> better information, I think we should strive to make that information
>> available for JFR as well.
>>
>> An alternative would be to create a new event for metaspace targeted for
>> JVM engineers/support, with similar information as jcmd(?), and only keep
>> fields relevant to a Java developer in ClassLoaderStatistics.
>>
>> Thanks
>> Erik
>>
>>
> Okay, you have a point. I may have misunderstood you before.
>
>
> Sorry for the mixed message, but when you said jcmd had better
> information, it got me thinking.
>
>
No problem. You thinking got me thinking :) So far I have almost
exclusively worked with jcmd and the like since I prefer command line toos;
but if JMC is used by hotspot devs too it makes sense to expose more
information.


> Maybe we should create something more useful than just modify what we have
> today?
>

Yes. I know the metaspace implementation quite well but I find what
JMC tells me not that useful. Part is different terminology (e.g. "Data
Space"), part is just the selection of information. I think this can be
improved. But since I would like to push this beyond Elastic Metaspace
(JDK-8221173) this will not happen before JDk16.


> I'll withdraw the RFE for now. Since a lot of implementation details will
> change, if this kind of detail is to be exposed via JFR, this will need
> brushing after JDK-8221173 hits mainline anyway so it makes no sense to put
> much work into it now.
>
>
> Sounds good.
>
>
> My question about backward compatibility remains though: can one just
> change/remove event fields? I assume JMC uses those fields for things
> beyond displaying events in the generic event browser, yes? How does JMC
> handle backward compatibility - is it only supposed to work with one
> hotspot or with a range of them?
>
>
> Users of the API should check that a field exists. It is stated in the
> Javadoc.
>
> JMC has its own parser and it supports JVMs back to JDK 7 so there is a
> mechanism to handle missing information.
>
> That said, we should not remove/change fields unless there is a good
> reason.
>
>
Okay, thanks.

>
> For instance, the "Class Loader Statistics" Tab in the "Class Loading"
> section of the VM still talks about "Anonymous Classes" and shows no
> content there; I assume this was broken with the Hidden Classes JEP which
> renamed the fields in ClassLoaderStatistics from "Anonymousxxx" to
> "Hiddenxxx". So is it bound to one specific hotspot version? Just a guess,
> I did not look at the JMC sources.
>
>
> I?m looping in JMC, so they can file a bug on it.
>
> Thanks
> Erik
>
>
Cheers, Thomas

>
> Thanks, Thomas
>
>
>
>> > On 27 May 2020, at 08:57, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > may I have opinions/reviews for this change please:
>> >
>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8245926
>> > Webrev:
>> >
>> http://cr.openjdk.java.net/~stuefe/webrevs/8245926-jfr-remove-chunksz-rename-blocksz/webrev.00/webrev/
>> >
>> > This is part of an effort to reduce exposure of Metaspace implementation
>> > details somewhat in preparation for JDK-8221173.
>> >
>> > In JFR, the classloader statistics event contains the following fields:
>> >
>> > chunkSize
>> > blockSize
>> > hiddenChunkSize
>> > hiddenBlockSize
>> >
>> > blockSize is the interesting one, the number of bytes of Metaspace used
>> by
>> > this class loader for storing metadata. I propose to rename this to
>> > "totalMetaspaceUsed" resp. "hiddenClassesMetaspaceUsed".
>> >
>> > chunkSize is the total size of chunks given to a class loader. Delta
>> > between blockSize and chunkSize constitutes waste if the loader stops
>> > loading; however, as far as waste goes this is not very informative
>> since
>> > it only is a usually small part of waste in the current metaspace
>> > allocator.
>> >
>> > Moreover, with JDK-8221173 chunks may be partially uncommitted, so that
>> the
>> > delta between chunkSize and blockSize may or may not contribute to RSS.
>> So
>> > the chunkSize stat becomes more meaningless.
>> >
>> > I'd argue that this stat is quite useless to the average JFR user; and
>> to
>> > the VM developer interested in fixing up Metaspace there are better
>> tools
>> > (e.g. jcmd VM.metaspace). Therefore I would like to simply remove this
>> stat.
>> >
>> > --
>> >
>> > Please note that this is my first change to JFR events. Some things are
>> > unclear to me, e.g. how backward compatibility in JMC is handled. So if
>> > something is missing from the patch, please advice.
>> >
>> >
>> > Thanks!
>> >
>> > .. Thomas
>>
>>
>

From kxu at openjdk.java.net  Wed May 27 19:32:29 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Wed, 27 May 2020 19:32:29 GMT
Subject: RFR: 6810: Create treemap viewer for JOverflow
Message-ID: <UYUmNiZznxIHelCnCrFEKD8goKjCJW7JqegDdkLMyw0=.7273ba4d-3b1d-45fb-a612-d60689598f84@github.com>

This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It
adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like
JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow.

![screen-shot](https://i.imgur.com/hTeNLtw.png)

The treemap is not included in the building by default, therefore you'll need to manually enable the
`org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened
in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*.

---

The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three
components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes
active.
 
### Toolbar actions:

![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png)

Buttons are enabled and disabled automatically according to the state of the treemap.

- Zoom-in button: zoom-in to the selected node of the treemap
- Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap
- Zoom-off button: display the root node (ie. "[ROOT]" node)

### Breadcrumb

![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png)

The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries
are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap.

- Left mouse click: navigate to desired zooming level.

### Treemap

![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png)

The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The
larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with
different background colours. User interactions on the treemap also updates the breadcrumb.

- Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button.
- Middle mouse click: display the root node (ie. "[ROOT]" node)
- Right mouse click: zoom-out to the parent node of the currently expanded node
- Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf)
- Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable
  format.

---

Let me know what you think about the design and functionality. :)

**Note**: at the time of submission the GitHub action CI will probably fail because
  [repository.ops4j.org](http://repository.ops4j.org/) is currently down, but I've built and tested with local cache and
  everything seems to be in order.

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

Commit messages:
 - Merge branch 'master' into joverflow-treemap
 - Set zoom-in disabled when leaf node selected
 - Updated documentation
 - WIP: fixed format and externalized message strings
 - WIP: added/updated license headers
 - WIP: added tool bar buttons
 - WIP: linked Breadcrumb with Treemap
 - WIP: fixed Breadcrumb layout sizes
 - WIP: TODO: fix Breadcrumb layout sizes
 - WIP: add messages when no instances selected
 - ... and 9 more: https://git.openjdk.java.net/jmc/compare/bb6765d7...e4bae1c9

Changes: https://git.openjdk.java.net/jmc/pull/77/files
 Webrev: https://webrevs.openjdk.java.net/jmc/77/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JMC-6810
  Stats: 3860 lines in 31 files changed: 3850 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jmc/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jmc pull/77/head:pull/77

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

From kxu at openjdk.java.net  Wed May 27 20:38:32 2020
From: kxu at openjdk.java.net (Kangcheng Xu)
Date: Wed, 27 May 2020 20:38:32 GMT
Subject: [Rev 01] RFR: 6810: Create treemap viewer for JOverflow
In-Reply-To: <UYUmNiZznxIHelCnCrFEKD8goKjCJW7JqegDdkLMyw0=.7273ba4d-3b1d-45fb-a612-d60689598f84@github.com>
References: <UYUmNiZznxIHelCnCrFEKD8goKjCJW7JqegDdkLMyw0=.7273ba4d-3b1d-45fb-a612-d60689598f84@github.com>
Message-ID: <QVoMWkvIVfi5A0AvgNjuqo4QDHfIsIajJCj4mRzyK9M=.4b723d61-4bd1-4050-a6ba-3e9ba513a71f@github.com>

> This PR implements [JMC-6810: Create treemap viewer for JOverflow](https://bugs.openjdk.java.net/browse/JMC-6810). It
> adds a treemap displaying memory usage by classes. It makes easier to spot what is consuming most of the memory. Like
> JOverflow instance viewer, the treemap viewer utilizes the filtering feature provided by JOverflow.
> ![screen-shot](https://i.imgur.com/hTeNLtw.png)
> The treemap is not included in the building by default, therefore you'll need to manually enable the
> `org.openjdk.jmc.feature.joverflow.ext.treemap` feature explicitly. Once enabled, the treemap view part can be opened
> in *Window* -> *Show View* -> *Other* -> *JOverflow* -> *JOverflow Treemap*.
> ---
> 
> The treemap view part consists of three components: the toolbar actions, the breadcrumb, and the treemap. All three
> components are automatically updated when the JOverflow filter changes, or when a new JOverflow editor page becomes
> active.
>  
> ### Toolbar actions:
> 
> ![toobar-actions-screen-shot](https://i.imgur.com/kxbed1a.png)
> 
> Buttons are enabled and disabled automatically according to the state of the treemap.
> 
> - Zoom-in button: zoom-in to the selected node of the treemap
> - Zoom-out button: zoom-out to the parent node of the currently expanded node of the treemap
> - Zoom-off button: display the root node (ie. "[ROOT]" node)
> 
> ### Breadcrumb
> 
> ![breadcrumb-screen-shot](https://i.imgur.com/kpvWOcp.png)
> 
> The breadcrumb indicates the location of the currently expanded treemap node relative to the root. Breadcrumb entries
> are updated upon treemap expands/collapse. User interactions on the breadcrumb also updates the treemap.
> - Left mouse click: navigate to desired zooming level.
> 
> ### Treemap
> 
> ![treemap-screen-shot](https://i.imgur.com/W1JOPDV.png)
> 
> The treemap implements the squarified treemap algorithm. Memory usage is aggregated by class and package names. The
> larger the area, the more memory consumed by this class/package. Treemap nodes on different levels are labelled with
> different background colours. User interactions on the treemap also updates the breadcrumb.
> - Left mouse click: select and highlight the clicked node, allowing zooming-in with the toolbar button.
> - Middle mouse click: display the root node (ie. "[ROOT]" node)
> - Right mouse click: zoom-out to the parent node of the currently expanded node
> - Left mouse double click: zoom-in to the clicked node (or to its parent node if the clicked node is a leaf)
> - Mouse hover: displays the tooltip with the full qualified package/class name and the memory usage in a human-readable
>   format.
> 
> ---
> 
> Let me know what you think about the design and functionality. :)

Kangcheng Xu has updated the pull request incrementally with one additional commit since the last revision:

  Add serialVersionUID to TreemapEvent

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

Changes:
  - all: https://git.openjdk.java.net/jmc/pull/77/files
  - new: https://git.openjdk.java.net/jmc/pull/77/files/e4bae1c9..cfb67837

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

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

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