From reinhapa at openjdk.org  Tue Aug  1 08:42:57 2023
From: reinhapa at openjdk.org (Patrick Reinhart)
Date: Tue, 1 Aug 2023 08:42:57 GMT
Subject: RFR: 8116: build{.sh,.bat} fail to detect started p2 jetty process
Message-ID: <ZFyWXt9yVydZmwZ_KVDokuXudy7Mm_51wQiMTT0QQdw=.883bd51d-06fe-4676-98be-22136213832b@github.com>

This pull request fixes the detection of the started jetty p2 instance needed for the build to succeed.

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

Commit messages:
 - 8116: Fix jetty startup detection

Changes: https://git.openjdk.org/jmc/pull/510/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=510&range=00
  Issue: https://bugs.openjdk.org/browse/JMC-8116
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jmc/pull/510.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/510/head:pull/510

PR: https://git.openjdk.org/jmc/pull/510

From clanger at openjdk.org  Tue Aug  1 09:16:50 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Aug 2023 09:16:50 GMT
Subject: RFR: 8116: build{.sh,
 .bat} fail to detect started p2 jetty process
In-Reply-To: <ZFyWXt9yVydZmwZ_KVDokuXudy7Mm_51wQiMTT0QQdw=.883bd51d-06fe-4676-98be-22136213832b@github.com>
References: <ZFyWXt9yVydZmwZ_KVDokuXudy7Mm_51wQiMTT0QQdw=.883bd51d-06fe-4676-98be-22136213832b@github.com>
Message-ID: <Mki8MuyPiuKdPZBgI7ukIzqH6IAt0fkNsa1bRG4LtoI=.a64b7121-04ab-48bc-8382-a3649205c175@github.com>

On Tue, 1 Aug 2023 08:36:28 GMT, Patrick Reinhart <reinhapa at openjdk.org> wrote:

> This pull request fixes the detection of the started jetty p2 instance needed for the build to succeed.

LGTM

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

Marked as reviewed by clanger (Committer).

PR Review: https://git.openjdk.org/jmc/pull/510#pullrequestreview-1556524132

From vpurnam at openjdk.org  Tue Aug  1 09:28:47 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Tue, 1 Aug 2023 09:28:47 GMT
Subject: RFR: 8116: build{.sh,
 .bat} fail to detect started p2 jetty process
In-Reply-To: <ZFyWXt9yVydZmwZ_KVDokuXudy7Mm_51wQiMTT0QQdw=.883bd51d-06fe-4676-98be-22136213832b@github.com>
References: <ZFyWXt9yVydZmwZ_KVDokuXudy7Mm_51wQiMTT0QQdw=.883bd51d-06fe-4676-98be-22136213832b@github.com>
Message-ID: <U-zie3gwZg2evR47429thvdtikH4cxSkU27a2diCb2s=.7c0a7682-3af0-4a34-8d7d-41be5135b1d8@github.com>

On Tue, 1 Aug 2023 08:36:28 GMT, Patrick Reinhart <reinhapa at openjdk.org> wrote:

> This pull request fixes the detection of the started jetty p2 instance needed for the build to succeed.

Marked as reviewed by vpurnam (Committer).

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

PR Review: https://git.openjdk.org/jmc/pull/510#pullrequestreview-1556549085

From reinhapa at openjdk.org  Tue Aug  1 11:07:51 2023
From: reinhapa at openjdk.org (Patrick Reinhart)
Date: Tue, 1 Aug 2023 11:07:51 GMT
Subject: Integrated: 8116: build{.sh,.bat} fail to detect started p2 jetty
 process
In-Reply-To: <ZFyWXt9yVydZmwZ_KVDokuXudy7Mm_51wQiMTT0QQdw=.883bd51d-06fe-4676-98be-22136213832b@github.com>
References: <ZFyWXt9yVydZmwZ_KVDokuXudy7Mm_51wQiMTT0QQdw=.883bd51d-06fe-4676-98be-22136213832b@github.com>
Message-ID: <iJE3cAevbSndXPCBcFn1aaYtIPoClIlfH5_bfwOWjMs=.0c4244c8-da93-4ed9-85f0-1453f011c94d@github.com>

On Tue, 1 Aug 2023 08:36:28 GMT, Patrick Reinhart <reinhapa at openjdk.org> wrote:

> This pull request fixes the detection of the started jetty p2 instance needed for the build to succeed.

This pull request has now been integrated.

Changeset: 75f89e73
Author:    Patrick Reinhart <reinhapa at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/75f89e73b6ce30d203130e88f50f975820d5a1a9
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8116: build{.sh,.bat} fail to detect started p2 jetty process

Reviewed-by: clanger, vpurnam

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

PR: https://git.openjdk.org/jmc/pull/510

From vpurnam at openjdk.org  Wed Aug  2 06:14:53 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Wed, 2 Aug 2023 06:14:53 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to heap
 memory drain
Message-ID: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>

When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)

For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 

**Scenario:**
For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 

![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)

![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)


**Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 

Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?

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

Commit messages:
 - 7885: Graphical rendering of dependency view fails due to heap memory drain

Changes: https://git.openjdk.org/jmc/pull/511/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=511&range=00
  Issue: https://bugs.openjdk.org/browse/JMC-7885
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jmc/pull/511.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/511/head:pull/511

PR: https://git.openjdk.org/jmc/pull/511

From bdutheil at openjdk.org  Thu Aug  3 11:08:37 2023
From: bdutheil at openjdk.org (Brice Dutheil)
Date: Thu, 3 Aug 2023 11:08:37 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain
In-Reply-To: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
Message-ID: <Cyuglkqth724yLI21JYSRiSIP0AkhHf35UfJZQY5_c0=.5b5fb468-3d2c-4f44-8036-f935c7ae20ea@github.com>

On Wed, 2 Aug 2023 06:08:22 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
> 
> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
> 
> **Scenario:**
> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
> 
> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
> 
> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
> 
> 
> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
> 
> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?

I believe the change shouldn't be applied on the core libraries.

core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/IItemCollectionJsonSerializer.java line 62:

> 60: 	private final static Logger LOGGER = Logger.getLogger("org.openjdk.jmc.flightrecorder.json");
> 61: 
> 62: 	public synchronized static String toJsonString(IItemCollection items) {

I'm not sure putting `synchronized` on this method in core libraries is the right call. Every consumer of this method will now pay the price for a JMC issue.

I think it's better to fix the issue where the web based views use this methods.

----

Also on the topic of synchronization I believe it's better to synchronize in the method body rather than the method.

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

PR Review: https://git.openjdk.org/jmc/pull/511#pullrequestreview-1560845018
PR Review Comment: https://git.openjdk.org/jmc/pull/511#discussion_r1283038535

From vpurnam at openjdk.org  Fri Aug  4 15:25:11 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Fri, 4 Aug 2023 15:25:11 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
Message-ID: <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>

> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
> 
> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
> 
> **Scenario:**
> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
> 
> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
> 
> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
> 
> 
> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
> 
> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?

Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:

  7885: Graphical rendering of dependency view fails due to heap memory drain

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

Changes:
  - all: https://git.openjdk.org/jmc/pull/511/files
  - new: https://git.openjdk.org/jmc/pull/511/files/2f28410d..1f70b722

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=511&range=01
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=511&range=00-01

  Stats: 72 lines in 5 files changed: 62 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jmc/pull/511.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/511/head:pull/511

PR: https://git.openjdk.org/jmc/pull/511

From vpurnam at openjdk.org  Fri Aug  4 15:26:43 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Fri, 4 Aug 2023 15:26:43 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <Cyuglkqth724yLI21JYSRiSIP0AkhHf35UfJZQY5_c0=.5b5fb468-3d2c-4f44-8036-f935c7ae20ea@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <Cyuglkqth724yLI21JYSRiSIP0AkhHf35UfJZQY5_c0=.5b5fb468-3d2c-4f44-8036-f935c7ae20ea@github.com>
Message-ID: <KNBvzEiUwjH-ZApIq5vzz19cAAmNgFadpYOEO_CpxAY=.2b504671-0028-4ba7-98d4-26bdc8420a00@github.com>

On Thu, 3 Aug 2023 11:04:41 GMT, Brice Dutheil <bdutheil at openjdk.org> wrote:

>> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   7885: Graphical rendering of dependency view fails due to heap memory drain
>
> core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/IItemCollectionJsonSerializer.java line 62:
> 
>> 60: 	private final static Logger LOGGER = Logger.getLogger("org.openjdk.jmc.flightrecorder.json");
>> 61: 
>> 62: 	public synchronized static String toJsonString(IItemCollection items) {
> 
> I'm not sure putting `synchronized` on this method in core libraries is the right call. Every consumer of this method will now pay the price for a JMC issue.
> 
> I think it's better to fix the issue where the web based views use this methods.
> 
> ----
> 
> Also on the topic of synchronization I believe it's better to synchronize in the method body rather than the method.

Hi @bric3, I have done the changes accordingly. As method present in core library has been called from different views, I have created a util method. I have reverted the changes done in core library. Could you please review the changes?

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

PR Review Comment: https://git.openjdk.org/jmc/pull/511#discussion_r1284560931

From bdutheil at openjdk.org  Fri Aug  4 23:45:36 2023
From: bdutheil at openjdk.org (Brice Dutheil)
Date: Fri, 4 Aug 2023 23:45:36 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
Message-ID: <a3ZhW2GdpyR_mprlE4oN3U9t-KsF-qBKwRxJvkkLxck=.799b7777-9494-41ea-a011-47d1687737d2@github.com>

On Fri, 4 Aug 2023 15:25:11 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

>> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
>> 
>> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> **Scenario:**
>> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
>> 
>> 
>> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
>> 
>> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?
>
> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7885: Graphical rendering of dependency view fails due to heap memory drain

I'll be off the grid for 2 weeks and cannot properly review the PR. While the synchronization on the core method is gone, I cannot help thinking synchronization is not appropriate there.

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1666283576

From jmatsuoka at openjdk.org  Tue Aug  8 14:59:52 2023
From: jmatsuoka at openjdk.org (Joshua Matsuoka)
Date: Tue, 8 Aug 2023 14:59:52 GMT
Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration
 bundle from application to core [v2]
In-Reply-To: <8p-z-kv8ll6PNFq7L5wxKpIv7n1Cy8KIv2wzlSRD7PU=.2073f3f6-ad4e-480d-b20c-431ace2e9d7a@github.com>
References: <8p-z-kv8ll6PNFq7L5wxKpIv7n1Cy8KIv2wzlSRD7PU=.2073f3f6-ad4e-480d-b20c-431ace2e9d7a@github.com>
Message-ID: <q3cWFzneAA3Jfe_VXjRkiZKxl0jT_sSTBH2yRjNqvSo=.917ddab1-ffde-46af-a0a8-b3c3a93f435e@github.com>

> This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have flightrecorder.configuration distributed in jmc core.
> 
> This PR continues from #299 , Alex is currently away so I'll be continuing this PR/bug. This PR builds off of Alex's existing branch and preserves the history. It fixes the merge conflicts and addresses the remaining review comments on #299 .
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-7307

Joshua Matsuoka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Fixing merge conflicts
 - Merge remote-tracking branch 'upstream/master' into 7307
 - Fixing manifest
 - Fixing visibility of XML classes
 - Addressing review comments
 - Merge remote-tracking branch 'aptmac/PR-7307' into 7307
 - update license headers to 2022
 - fix package name in JFCXMLValidator logger
 - re-order flightrecorder.configuration.test in test pom
 - update license headers
 - ... and 8 more: https://git.openjdk.org/jmc/compare/75f89e73...10171662

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

Changes: https://git.openjdk.org/jmc/pull/469/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=469&range=01
  Stats: 1101 lines in 110 files changed: 361 ins; 561 del; 179 mod
  Patch: https://git.openjdk.org/jmc/pull/469.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/469/head:pull/469

PR: https://git.openjdk.org/jmc/pull/469

From aptmac at openjdk.org  Wed Aug  9 13:38:30 2023
From: aptmac at openjdk.org (Alex Macdonald)
Date: Wed, 9 Aug 2023 13:38:30 GMT
Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration
 bundle from application to core [v2]
In-Reply-To: <q3cWFzneAA3Jfe_VXjRkiZKxl0jT_sSTBH2yRjNqvSo=.917ddab1-ffde-46af-a0a8-b3c3a93f435e@github.com>
References: <8p-z-kv8ll6PNFq7L5wxKpIv7n1Cy8KIv2wzlSRD7PU=.2073f3f6-ad4e-480d-b20c-431ace2e9d7a@github.com>
 <q3cWFzneAA3Jfe_VXjRkiZKxl0jT_sSTBH2yRjNqvSo=.917ddab1-ffde-46af-a0a8-b3c3a93f435e@github.com>
Message-ID: <JwTxVE7T0KV9CsRVBMC3R2fSZUtfCMLR463C8LdIoXw=.3edc6746-eefe-4626-9926-031d93de4628@github.com>

On Tue, 8 Aug 2023 14:59:52 GMT, Joshua Matsuoka <jmatsuoka at openjdk.org> wrote:

>> This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have flightrecorder.configuration distributed in jmc core.
>> 
>> This PR continues from #299 , Alex is currently away so I'll be continuing this PR/bug. This PR builds off of Alex's existing branch and preserves the history. It fixes the merge conflicts and addresses the remaining review comments on #299 .
>> 
>> [0] https://bugs.openjdk.java.net/browse/JMC-7307
>
> Joshua Matsuoka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Fixing merge conflicts
>  - Merge remote-tracking branch 'upstream/master' into 7307
>  - Fixing manifest
>  - Fixing visibility of XML classes
>  - Addressing review comments
>  - Merge remote-tracking branch 'aptmac/PR-7307' into 7307
>  - update license headers to 2022
>  - fix package name in JFCXMLValidator logger
>  - re-order flightrecorder.configuration.test in test pom
>  - update license headers
>  - ... and 8 more: https://git.openjdk.org/jmc/compare/75f89e73...10171662

Thanks for giving this PR an update. It looks like there's a few (3) files with some leftovers from resolving merge conflicts that are causing build issues. Also the license headers will need to be updated to 2023 at some point as well.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/jvm/JVMType.java line 50:

> 48: 	HOTSPOT,
> 49: 	/**
> 50: <<<<<<< HEAD

There are a couple in this file

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/ISecurityManager.java line 193:

> 191: 	 * @param encryptionCipher
> 192: 	 *            the encryption cipher to use.
> 193: <<<<<<< HEAD

and in here

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/Environment.java line 93:

> 91: 
> 92: 	/**
> 93: <<<<<<< HEAD

And here too.

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

PR Review: https://git.openjdk.org/jmc/pull/469#pullrequestreview-1569543409
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1288473222
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1288474124
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1288474338

From aptmac at openjdk.org  Wed Aug  9 15:09:59 2023
From: aptmac at openjdk.org (Alex Macdonald)
Date: Wed, 9 Aug 2023 15:09:59 GMT
Subject: RFR: 8112: Flamegraph model creation performance improvements [v4]
In-Reply-To: <frP5br1-PBQF8LODLn_a6J3lTHkNVL5GeZ9YruB2duc=.a7caf247-b490-41b0-b4c0-859d27ac1e3b@github.com>
References: <SYmKx2gf9iEhYt3KwZie3RjMrKEnUwMyccjewsA7BLU=.76b51bda-9993-4efc-9cd8-1b2e9a219f57@github.com>
 <frP5br1-PBQF8LODLn_a6J3lTHkNVL5GeZ9YruB2duc=.a7caf247-b490-41b0-b4c0-859d27ac1e3b@github.com>
Message-ID: <1-tiEQJTHwdGQgdLCDJtvQB7DwKiZnpinbRoAqpKIfc=.31cccbb0-405d-4469-8cda-f63af9ba7d70@github.com>

On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte <duke at openjdk.org> wrote:

>> This pull request improves the performance of creating the model that the flame graph visualization is drawn from.
>> 
>> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task.
>> The use case where that tends to happen to me goes as follows:
>> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test.
>> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two"
>> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread.
>> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it.
>> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app)
>> 
>> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel.
>> 
>> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time.
>> 
>> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick:
>> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee...
>
> Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header with 2023

Changes look straightforward enough, thanks for adding a unit test as well.

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

Marked as reviewed by aptmac (Reviewer).

PR Review: https://git.openjdk.org/jmc/pull/502#pullrequestreview-1569842716

From jmatsuoka at openjdk.org  Thu Aug 10 17:53:58 2023
From: jmatsuoka at openjdk.org (Joshua Matsuoka)
Date: Thu, 10 Aug 2023 17:53:58 GMT
Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration
 bundle from application to core [v3]
In-Reply-To: <8p-z-kv8ll6PNFq7L5wxKpIv7n1Cy8KIv2wzlSRD7PU=.2073f3f6-ad4e-480d-b20c-431ace2e9d7a@github.com>
References: <8p-z-kv8ll6PNFq7L5wxKpIv7n1Cy8KIv2wzlSRD7PU=.2073f3f6-ad4e-480d-b20c-431ace2e9d7a@github.com>
Message-ID: <H_PzG0lI95QX4Wg_BnP4MRKVRqHDajPntkG_xs35iK4=.43d1edcc-5b5f-4a4e-8edb-128a297c4c76@github.com>

> This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have flightrecorder.configuration distributed in jmc core.
> 
> This PR continues from #299 , Alex is currently away so I'll be continuing this PR/bug. This PR builds off of Alex's existing branch and preserves the history. It fixes the merge conflicts and addresses the remaining review comments on #299 .
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-7307

Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision:

  running spotlesS

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

Changes:
  - all: https://git.openjdk.org/jmc/pull/469/files
  - new: https://git.openjdk.org/jmc/pull/469/files/10171662..cbeb507d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=469&range=02
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=469&range=01-02

  Stats: 29 lines in 3 files changed: 3 ins; 7 del; 19 mod
  Patch: https://git.openjdk.org/jmc/pull/469.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/469/head:pull/469

PR: https://git.openjdk.org/jmc/pull/469

From aptmac at openjdk.org  Fri Aug 11 20:39:58 2023
From: aptmac at openjdk.org (Alex Macdonald)
Date: Fri, 11 Aug 2023 20:39:58 GMT
Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration
 bundle from application to core [v3]
In-Reply-To: <H_PzG0lI95QX4Wg_BnP4MRKVRqHDajPntkG_xs35iK4=.43d1edcc-5b5f-4a4e-8edb-128a297c4c76@github.com>
References: <8p-z-kv8ll6PNFq7L5wxKpIv7n1Cy8KIv2wzlSRD7PU=.2073f3f6-ad4e-480d-b20c-431ace2e9d7a@github.com>
 <H_PzG0lI95QX4Wg_BnP4MRKVRqHDajPntkG_xs35iK4=.43d1edcc-5b5f-4a4e-8edb-128a297c4c76@github.com>
Message-ID: <3MRbkfZPy-GW50ZOOVMJrZI-bYlbwgLkbgVjDLRV9CU=.4f46b9dd-2199-443b-aa40-9cfb7cee6c06@github.com>

On Thu, 10 Aug 2023 17:53:58 GMT, Joshua Matsuoka <jmatsuoka at openjdk.org> wrote:

>> This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have flightrecorder.configuration distributed in jmc core.
>> 
>> This PR continues from #299 , Alex is currently away so I'll be continuing this PR/bug. This PR builds off of Alex's existing branch and preserves the history. It fixes the merge conflicts and addresses the remaining review comments on #299 .
>> 
>> [0] https://bugs.openjdk.java.net/browse/JMC-7307
>
> Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   running spotlesS

Still a handful of merge artifacts left behind, most of them are in comments but there's 3 that aren't and are stopping the ci builds.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/jvm/JVMType.java line 50:

> 48: 	HOTSPOT,
> 49: 	/**
> 50: 	 * <<<<<<< HEAD ======= The JVM is Substrate VM.

Stuck in a comment

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/jvm/JVMType.java line 54:

> 52: 	SUBSTRATE,
> 53: 	/**
> 54: 	 * >>>>>>> upstream/master The JVM is unknown.

Also in a comment

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/jvm/JVMType.java line 74:

> 72: 		} else if (JavaVMVersionToolkit.isHotspotJVMName(jvmName)) {
> 73: 			return JVMType.HOTSPOT;
> 74: <<<<<<< HEAD

This is where spotless wasn't too happy in that last run. There's two more to clean up below as well.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/ISecurityManager.java line 192:

> 190: 	 *
> 191: 	 * @param encryptionCipher
> 192: 	 *            the encryption cipher to use. <<<<<<< HEAD

Leftover (<<<<<<< HEAD) in a comment.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/ISecurityManager.java line 206:

> 204: 
> 205: 	/**
> 206: 	 * Triggers a change of the master password. <<<<<<< HEAD

Leftover (<<<<<<< HEAD) in a comment.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/Environment.java line 93:

> 91: 
> 92: 	/**
> 93: 	 * <<<<<<< HEAD

Leftover (<<<<<<< HEAD) in a comment.

core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/util/Environment.java line 95:

> 93: 	 * <<<<<<< HEAD
> 94: 	 * 
> 95: 	 * @return the "normal" 100% scaled DPI setting of the OS, 96 for Windows & Linux and 72 for

This comment block will need to be cleanup up as well.

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

PR Review: https://git.openjdk.org/jmc/pull/469#pullrequestreview-1574335248
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1291752272
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1291752374
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1291752578
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1291753055
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1291753082
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1291753162
PR Review Comment: https://git.openjdk.org/jmc/pull/469#discussion_r1291753459

From duke at openjdk.org  Wed Aug 16 05:13:17 2023
From: duke at openjdk.org (Vincent Alexander Beelte)
Date: Wed, 16 Aug 2023 05:13:17 GMT
Subject: RFR: 8112: Flamegraph model creation performance improvements [v4]
In-Reply-To: <frP5br1-PBQF8LODLn_a6J3lTHkNVL5GeZ9YruB2duc=.a7caf247-b490-41b0-b4c0-859d27ac1e3b@github.com>
References: <SYmKx2gf9iEhYt3KwZie3RjMrKEnUwMyccjewsA7BLU=.76b51bda-9993-4efc-9cd8-1b2e9a219f57@github.com>
 <frP5br1-PBQF8LODLn_a6J3lTHkNVL5GeZ9YruB2duc=.a7caf247-b490-41b0-b4c0-859d27ac1e3b@github.com>
Message-ID: <MHIIGpm6ba4yxOU8g_EjSkHGQB0U3Ym-hFfmoUzZ70I=.88ede013-6de7-4c3d-bb81-84d1b7bd99fd@github.com>

On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte <duke at openjdk.org> wrote:

>> This pull request improves the performance of creating the model that the flame graph visualization is drawn from.
>> 
>> The first issue this fixes is not actually really "performance" but rather a case where the thread pool used to create the models can be fully saturated with tasks that are already invaliated and blocking the newest useful task.
>> The use case where that tends to happen to me goes as follows:
>> My jfr file contains about 1.8 million events (1.5 mio "Allocation in new TLAB", 200k "Allocation outside TLAB", 70k "Method Profiling Sample"). It was created by async-profiler during a 5 minute load test.
>> When loading this file and switching to the Java Application view (with the Flame Graph visualization already in focus) multiple tasks are generated to create a flamegraph for all event types and all threads. I did not investigate why there would be multiple tasks. "multiple" is "at least two"
>> Then without waiting for the graph to load I go on to filter to the thread that I am interested about which generates multiple tasks to generate a flamegraph for all event types in that thread.
>> Lastly I filter to the Method Profiling Samples which creates the last task, which then has to wait for enough of the other tasks to finish that one of the 3 thread in the pool can run it.
>> All in all with this specific jfr file and the current master (everything including commit 5ace151) in this scenario I am waiting about 55 seconds until I see the graph. (just measured with a stopwatch app)
>> 
>> My solution to this was to give the StacktraceTreeModel constructor a stop flag that it checks at the start both the inner and the outer loop. So that it can return early. The flag is then implemented by the FlamegraphSwingView.ModelRebuildRunnable.isInvalid field which is already checked at some places to see if the current task is still needed. It does feel strange to do this in a constructor but it was the easiest way to interrupt the most expensive part of creating the StacktraceTreeModel.
>> 
>> With this flag alone use case above goes from 55 seconds to about 6 seconds and there I am already the limiting factor stopping the clock in time.
>> 
>> When looking at the flamegraph of a flight recording of jmc where I had it draw me a bunch of different flamegraph with different filters in my 1.8 mio event file it did look like there where some additional low hanging fruit to pick:
>> ![streams](https://github.com/openjdk/jmc/assets/917408/892a5851-ed3c-4337-8646-07ee...
>
> Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header with 2023

Thanks. So now to see if it manages to integrate without pulling first. It should if there or no conflicts right?

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

PR Comment: https://git.openjdk.org/jmc/pull/502#issuecomment-1679973654

From duke at openjdk.org  Wed Aug 16 05:37:14 2023
From: duke at openjdk.org (Vincent Alexander Beelte)
Date: Wed, 16 Aug 2023 05:37:14 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
Message-ID: <BYVLBqlrvfu1luhrpwum1yfqAHn_Qx_GMM4OkEExvJg=.1242ce4e-639c-4c04-9f3a-fe629b654d6a@github.com>

On Fri, 4 Aug 2023 15:25:11 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

>> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
>> 
>> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> **Scenario:**
>> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
>> 
>> 
>> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
>> 
>> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?
>
> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7885: Graphical rendering of dependency view fails due to heap memory drain

I also made an attempt to work around this problem with the idea of adding stop flags like I did in #502 . You can find the results over in https://github.com/grandmasterpixel/jmc/tree/more_stop_flags if you are interested (I also did some experiments with making the generation of the graph view go faster in there. Just ignore that).
In contrast to making json generation mutually exclusive that would reduce concurrent generation of JSONs by stopping unneeded computations as early as possible. So you do not use heap for JSONs that are thrown away soon anyway.
I never made a pull request out of that because I think the real problem is having to use JSONs at all. I found it pretty easy to get OOMEs not because of to heap exhaustion but because of array size limits anyways.

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1679990275

From vpurnam at openjdk.org  Thu Aug 17 17:03:52 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Thu, 17 Aug 2023 17:03:52 GMT
Subject: RFR: 8117: mvn clean install on JMC Core fails if path contains space
Message-ID: <M8U82hcaQeF0JvXr6haaIJ0ZexddBQxxZcYseAJzH4g=.1f5370e0-d1f1-4a98-845a-2c859002feb8@github.com>

mvn clean install on JMC Core fails if path contains space. 

If there is a space in path, mvn clean install fails. Space has been replaced by %20 and it makes the path incorrect. To fix this issue URI has to be used in place of URL.
Please refer the below screen shot for error.
<img width="1776" alt="8117" src="https://github.com/openjdk/jmc/assets/97600378/83657740-3731-46a6-8b94-a1a092f0cf08">

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

Commit messages:
 - 8117: mvn clean install on JMC Core fails if path contains space

Changes: https://git.openjdk.org/jmc/pull/512/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=512&range=00
  Issue: https://bugs.openjdk.org/browse/JMC-8117
  Stats: 11 lines in 2 files changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jmc/pull/512.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/512/head:pull/512

PR: https://git.openjdk.org/jmc/pull/512

From aptmac at openjdk.org  Thu Aug 17 19:12:33 2023
From: aptmac at openjdk.org (Alex Macdonald)
Date: Thu, 17 Aug 2023 19:12:33 GMT
Subject: RFR: 8117: mvn clean install on JMC Core fails if path contains
 space
In-Reply-To: <M8U82hcaQeF0JvXr6haaIJ0ZexddBQxxZcYseAJzH4g=.1f5370e0-d1f1-4a98-845a-2c859002feb8@github.com>
References: <M8U82hcaQeF0JvXr6haaIJ0ZexddBQxxZcYseAJzH4g=.1f5370e0-d1f1-4a98-845a-2c859002feb8@github.com>
Message-ID: <M_ealRWD0iBB3McV_44evzPFf2XH7p6TGvAyxv2LTOA=.c1fe8606-196d-4095-89f0-b943708a1dcd@github.com>

On Thu, 17 Aug 2023 16:56:44 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

> mvn clean install on JMC Core fails if path contains space. 
> 
> If there is a space in path, mvn clean install fails. Space has been replaced by %20 and it makes the path incorrect. To fix this issue URI has to be used in place of URL.
> Please refer the below screen shot for error.
> <img width="1776" alt="8117" src="https://github.com/openjdk/jmc/assets/97600378/83657740-3731-46a6-8b94-a1a092f0cf08">

Marked as reviewed by aptmac (Reviewer).

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

PR Review: https://git.openjdk.org/jmc/pull/512#pullrequestreview-1583295133

From vpurnam at openjdk.org  Fri Aug 18 05:32:34 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Fri, 18 Aug 2023 05:32:34 GMT
Subject: Integrated: 8117: mvn clean install on JMC Core fails if path contains
 space
In-Reply-To: <M8U82hcaQeF0JvXr6haaIJ0ZexddBQxxZcYseAJzH4g=.1f5370e0-d1f1-4a98-845a-2c859002feb8@github.com>
References: <M8U82hcaQeF0JvXr6haaIJ0ZexddBQxxZcYseAJzH4g=.1f5370e0-d1f1-4a98-845a-2c859002feb8@github.com>
Message-ID: <jsUZtyYCwcbqznJG1Lg-7mcqywn5sbm1FkC03O6l3yY=.6ae50423-f4c4-4f3d-ae02-47b415d45ce8@github.com>

On Thu, 17 Aug 2023 16:56:44 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

> mvn clean install on JMC Core fails if path contains space. 
> 
> If there is a space in path, mvn clean install fails. Space has been replaced by %20 and it makes the path incorrect. To fix this issue URI has to be used in place of URL.
> Please refer the below screen shot for error.
> <img width="1776" alt="8117" src="https://github.com/openjdk/jmc/assets/97600378/83657740-3731-46a6-8b94-a1a092f0cf08">

This pull request has now been integrated.

Changeset: 6003efc5
Author:    Virag Purnam <vpurnam at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/6003efc56f0b43bf2a2392d800394438c8e0a967
Stats:     11 lines in 2 files changed: 3 ins; 0 del; 8 mod

8117: mvn clean install on JMC Core fails if path contains space

Reviewed-by: aptmac

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

PR: https://git.openjdk.org/jmc/pull/512

From vpurnam at openjdk.org  Wed Aug 23 15:44:30 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Wed, 23 Aug 2023 15:44:30 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <BYVLBqlrvfu1luhrpwum1yfqAHn_Qx_GMM4OkEExvJg=.1242ce4e-639c-4c04-9f3a-fe629b654d6a@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
 <BYVLBqlrvfu1luhrpwum1yfqAHn_Qx_GMM4OkEExvJg=.1242ce4e-639c-4c04-9f3a-fe629b654d6a@github.com>
Message-ID: <uqIwflF2AW6OEYdm69FmX11pP7KBLNUlBfg5PtpPPus=.1087463e-34cf-4d11-b62b-e2c3519e51cb@github.com>

On Wed, 16 Aug 2023 05:34:36 GMT, Vincent Alexander Beelte <duke at openjdk.org> wrote:

> I also made an attempt to work around this problem with the idea of adding stop flags like I did in #502 . You can find the results over in https://github.com/grandmasterpixel/jmc/tree/more_stop_flags if you are interested (I also did some experiments with making the generation of the graph view go faster in there. Just ignore that). In contrast to making json generation mutually exclusive that would reduce concurrent generation of JSONs by stopping unneeded computations as early as possible. So you do not use heap for JSONs that are thrown away soon anyway. I never made a pull request out of that because I think the real problem is having to use JSONs at all. I found it pretty easy to get OOMEs not because of to heap exhaustion but because of array size limits anyways.

Hi @grandmasterpixel, Sorry for late response as I was occupied with some other tasks and Thanks for your valuable comment. I have just gone through the code changes in  https://github.com/grandmasterpixel/jmc/tree/more_stop_flags. I tried with the changes specific to DependencyView and HaatmapView. With the changes, I do not hit Out Of Memory Error. If you are fine then I would like to take the changes and update this PR. I will overload the method in "IItemCollectionJsonSerializer" class. Method overloading is needed as we are doing changes in JMC core libraries and other consumers of this method will not be impacted. Could you please share your thoughts on this?

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1690194339

From duke at openjdk.org  Wed Aug 23 19:44:29 2023
From: duke at openjdk.org (Vincent Alexander Beelte)
Date: Wed, 23 Aug 2023 19:44:29 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
Message-ID: <OgbujOb3yjoRNFoEcL0wA1AsPD7zsbhDXrlQFkHQi7o=.7053f535-86a7-4b3a-9ae0-c51332168f51@github.com>

On Fri, 4 Aug 2023 15:25:11 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

>> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
>> 
>> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> **Scenario:**
>> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
>> 
>> 
>> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
>> 
>> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?
>
> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7885: Graphical rendering of dependency view fails due to heap memory drain

Sure go ahead and adapt that idea however you see fit. I had already gotten approval to contribute that myself from Accenture but I never did because in the end I felt it wasn't enough of an improvement.
Even with that change I could easily make the JSONs big enough that they won't fit into the Java array size limits. And I did not even need to use abnormally large recordings for that.
I think fully removing the JSONs is not easily possible but you might want to explore changing the format unless there are consumers outside the scope of what you could change.
I imagine there might be a lot of duplicate content in those JSONs like maybe stacktraces or class names. You could implement a manual dictionary compression (I believe that's the word for what I am proposing).
Instead of for example

{
    "people": [
        {
            "firstName": "John",
            "lastName": "Smith"
        },
        {
            "firstName": "Max",
            "lastName": "Miller"
        },
        {
            "firstName": "Max",
            "lastName": "Smith"
        },
        {
            "firstName": "John",
            "lastName": "Miller"
        }
    ]
}

you could do this

{
    "people": [
        {
            "firstName": 0,
            "lastName": 1
        },
        {
            "firstName": 2,
            "lastName": 3
        },
        {
            "firstName": 2,
            "lastName": 1
        },
        {
            "firstName": 0,
            "lastName": 3
        }
    ],
    "strings": ["John", "Smith", "Max", "Miller"]
}

In this example the last JSON wasn't actually smaller in terms of characters because the names are too short, but I think I have shown the idea.

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1690536265

From vpurnam at openjdk.org  Thu Aug 24 05:12:32 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Thu, 24 Aug 2023 05:12:32 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <OgbujOb3yjoRNFoEcL0wA1AsPD7zsbhDXrlQFkHQi7o=.7053f535-86a7-4b3a-9ae0-c51332168f51@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
 <OgbujOb3yjoRNFoEcL0wA1AsPD7zsbhDXrlQFkHQi7o=.7053f535-86a7-4b3a-9ae0-c51332168f51@github.com>
Message-ID: <v2eGFKfYD1-l9MQeCnHYLd2NtogWnb61Lbys843shqM=.04361011-46f3-4875-ad4a-fdbb0580de52@github.com>

On Wed, 23 Aug 2023 19:41:19 GMT, Vincent Alexander Beelte <duke at openjdk.org> wrote:

>> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   7885: Graphical rendering of dependency view fails due to heap memory drain
>
> Sure go ahead and adapt that idea however you see fit. I had already gotten approval to contribute that myself from Accenture but I never did because in the end I felt it wasn't enough of an improvement.
> Even with that change I could easily make the JSONs big enough that they won't fit into the Java array size limits. And I did not even need to use abnormally large recordings for that.
> I think fully removing the JSONs is not easily possible but you might want to explore changing the format unless there are consumers outside the scope of what you could change.
> I imagine there might be a lot of duplicate content in those JSONs like maybe stacktraces or class names. You could implement a manual dictionary compression (I believe that's the word for what I am proposing).
> Instead of for example
> 
> {
>     "people": [
>         {
>             "firstName": "John",
>             "lastName": "Smith"
>         },
>         {
>             "firstName": "Max",
>             "lastName": "Miller"
>         },
>         {
>             "firstName": "Max",
>             "lastName": "Smith"
>         },
>         {
>             "firstName": "John",
>             "lastName": "Miller"
>         }
>     ]
> }
> 
> you could do this
> 
> {
>     "people": [
>         {
>             "firstName": 0,
>             "lastName": 1
>         },
>         {
>             "firstName": 2,
>             "lastName": 3
>         },
>         {
>             "firstName": 2,
>             "lastName": 1
>         },
>         {
>             "firstName": 0,
>             "lastName": 3
>         }
>     ],
>     "strings": ["John", "Smith", "Max", "Miller"]
> }
> 
> In this example the last JSON wasn't actually smaller in terms of characters because the names are too short, but I think I have shown the idea.

Hi @grandmasterpixel, Thanks! Your idea for improvement is really promising. I need to experiment a bit on that and need to check how users other than JMC are consuming. We have several bugs opened for this OutOfMemory and I think the changes proposed by you are good enough to fix this issue (normal scenario) as of now. We will create a new ticket for the enhancement.

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1691011682

From bdutheil at openjdk.org  Thu Aug 24 10:59:36 2023
From: bdutheil at openjdk.org (Brice Dutheil)
Date: Thu, 24 Aug 2023 10:59:36 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
Message-ID: <H3sl5K7GqHCIgvZ_UvnEBE2USFgO_IBZzFOZZgDxTwI=.7dd84905-9dfa-4995-af33-d899dbf8b4f7@github.com>

On Fri, 4 Aug 2023 15:25:11 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

>> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
>> 
>> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> **Scenario:**
>> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
>> 
>> 
>> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
>> 
>> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?
>
> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7885: Graphical rendering of dependency view fails due to heap memory drain

Changing the Json format might be a breaking change, even if pooling constants is a very good improvement in my opinion, it could a format option ?

I was thinking about a **possible** alternative by introducing `IItemCollectionJsonSerializer::toJsonCharSequence` variants (and deprecating `IItemCollectionJsonSerializer::toJsonString` methods). 

<details><summary>Code suggestion</summary>


	@Deprecated
	public static String toJsonString(IItemCollection items) {
		return toJsonCharSequence(items).toString();
	}

	@Deprecated
	public static String toJsonString(Iterable<IItem> items) {
		return toJsonCharSequence(items).toString();
	}

	public static CharSequence toJsonCharSequence(IItemCollection items) {
		StringWriter sw = new StringWriter();
		IItemCollectionJsonSerializer marshaller = new IItemCollectionJsonSerializer(sw);
		try {
			marshaller.writeRecording(items);
		} catch (IOException e) {
			LOGGER.log(Level.SEVERE, "Failed to serialize recording to JSON", e);
		}
		return sw.getBuffer();
	}

	public static CharSequence toJsonCharSequence(Iterable<IItem> items) {
		StringWriter sw = new StringWriter();
		IItemCollectionJsonSerializer marshaller = new IItemCollectionJsonSerializer(sw);
		try {
			marshaller.writeEvents(items);
		} catch (IOException e) {
			LOGGER.log(Level.SEVERE, "Failed to serialize items to JSON", e);
		}
		return sw.getBuffer();
	}


</details>


The existing methods, actually build the payload using a `StringWriter` under the hood, notice that the methods build the `String` from a `StringBuffer` which is a `CharSequence`.

https://github.com/openjdk/jmc/blob/6003efc56f0b43bf2a2392d800394438c8e0a967/core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/IItemCollectionJsonSerializer.java#L62-L83

The idea would be to convert the `CharSequence`, very late, i.e. when actually passing the payload. Actually `String.format` will do that for us, the other changes would be the change the declared type `String` -> `CharSequence`.

https://github.com/openjdk/jmc/blob/6003efc56f0b43bf2a2392d800394438c8e0a967/application/org.openjdk.jmc.flightrecorder.heatmap/src/main/java/org/openjdk/jmc/flightrecorder/heatmap/views/HeatmapView.java#L216-L216

Unfortunately the `org.eclipse.swt.browser.Browser` API only work with `String`s so at some point this gigantic object has to be created. And the effort to pool objects might be interesting then.

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1691459563

From duke at openjdk.org  Mon Aug 28 11:43:20 2023
From: duke at openjdk.org (Marius Volkhart)
Date: Mon, 28 Aug 2023 11:43:20 GMT
Subject: Integrated: 8064: Typo in agent wizard
In-Reply-To: <v2w88MwzEXVPCOVwIIm_U1NJ6vxC5DQOJayS0PvdF1U=.3b4244e2-9dec-470f-acea-cc507f049822@github.com>
References: <v2w88MwzEXVPCOVwIIm_U1NJ6vxC5DQOJayS0PvdF1U=.3b4244e2-9dec-470f-acea-cc507f049822@github.com>
Message-ID: <Yh97YG9n4NLCWmQGl8Uea-k5Ptd5TC8MHDhDss_K3c4=.8b859017-d8ef-4274-9cbe-e99f2188a0e5@github.com>

On Thu, 2 Mar 2023 23:30:23 GMT, Marius Volkhart <duke at openjdk.org> wrote:

> prset -> preset

This pull request has now been integrated.

Changeset: 26bd7e62
Author:    Marius Volkhart <marius at volkhart.com>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/26bd7e62e05de10e95327e389e5448a68a6487e9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8064: Typo in agent wizard

Reviewed-by: hdafgard, clanger

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

PR: https://git.openjdk.org/jmc/pull/474

From aptmac at openjdk.org  Mon Aug 28 19:40:43 2023
From: aptmac at openjdk.org (Alex Macdonald)
Date: Mon, 28 Aug 2023 19:40:43 GMT
Subject: RFR: 8118: Add user configuration for delay between JVM discovery and
 attachment
Message-ID: <_kTX5BGBt6tU3JqOEmiBmgiz47Ren7v66xugqQdsGdI=.33147219-1411-49fe-b532-9a344559a12c@github.com>

This PR addresses JMC-8118 [0], in which it'd be nice to be able to specify a time delay between when a JVM is discovered and when JVM is attached to (for the JvmDescriptor creation). I've placed this option into the Preferences menu at Preferences > JDK Mission Control > JVM Browser > Local, with a maximum delay time of 1 minute and a default time of 0ms (current).

There is currently an issue where if a newly launched JVM is not fully set-up by the time JMC discovers and attaches to it (via JvmDescriptor creation), then the target JVM could through an error and/or crash on startup. For example, if an application uses a custom logging manager that hasn't been fully initialized prior to JvmDescriptor creation, it may/will just crash.

Example:
![8118](https://github.com/openjdk/jmc/assets/10425301/d199cf50-2dba-4577-86fb-1dd65973d67a)

[0] https://bugs.openjdk.org/browse/JMC-8118

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

Commit messages:
 - 8118: Add user configuration for delay between JVM discovery and attachment

Changes: https://git.openjdk.org/jmc/pull/513/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=513&range=00
  Issue: https://bugs.openjdk.org/browse/JMC-8118
  Stats: 55 lines in 6 files changed: 55 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jmc/pull/513.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/513/head:pull/513

PR: https://git.openjdk.org/jmc/pull/513

From vpurnam at openjdk.org  Wed Aug 30 04:59:16 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Wed, 30 Aug 2023 04:59:16 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
Message-ID: <PaHg5oFaWB4ZG3hkIiKPk1D18h3VCmgAQe9QamK67gg=.bb0948e5-f624-4d0c-a060-57a9188ed2d1@github.com>

On Fri, 4 Aug 2023 15:25:11 GMT, Virag Purnam <vpurnam at openjdk.org> wrote:

>> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
>> 
>> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> **Scenario:**
>> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
>> 
>> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
>> 
>> 
>> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
>> 
>> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?
>
> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7885: Graphical rendering of dependency view fails due to heap memory drain

> Changing the Json format might be a breaking change, even if pooling constants is a very good improvement in my opinion, it could a format option ?
> 
> I was thinking about a **possible** alternative by introducing `IItemCollectionJsonSerializer::toJsonCharSequence` variants (and deprecating `IItemCollectionJsonSerializer::toJsonString` methods).
> 
> Code suggestion
> The existing methods, actually build the payload using a `StringWriter` under the hood, notice that the methods build the `String` from a `StringBuffer` which is a `CharSequence`.
> 
> https://github.com/openjdk/jmc/blob/6003efc56f0b43bf2a2392d800394438c8e0a967/core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/IItemCollectionJsonSerializer.java#L62-L83
> 
> The idea would be to convert the `CharSequence`, very late, i.e. when actually passing the payload. Actually `String.format` will do that for us, the other changes would be the change the declared type `String` -> `CharSequence`.
> 
> https://github.com/openjdk/jmc/blob/6003efc56f0b43bf2a2392d800394438c8e0a967/application/org.openjdk.jmc.flightrecorder.heatmap/src/main/java/org/openjdk/jmc/flightrecorder/heatmap/views/HeatmapView.java#L216-L216
> 
> Unfortunately the `org.eclipse.swt.browser.Browser` API only work with `String`s so at some point this gigantic object has to be created. And the effort to pool objects might be interesting then.

Hi @bric3, I have taken the changes suggested by you, but that has not solved the issue. I get the same error. The changes suggested by @grandmasterpixel, we do not get this error for normal usecases. If we decrease the Max Heap (-Xmx) to less than 512m, we get that error. I hope users are not using JMC with so much less memory. I feel we can take the changes. I will do the changes and update this PR for review. Similar change has already been taken for FlameGraph.

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1698492641

From duke at openjdk.org  Thu Aug 31 01:01:26 2023
From: duke at openjdk.org (duke)
Date: Thu, 31 Aug 2023 01:01:26 GMT
Subject: git: openjdk/jmc: 7823: Enhance JMC configuration
Message-ID: <230efa22-7d75-405c-b4aa-0a4b76fbd7f9@openjdk.org>

Changeset: e037d23d
Author:    schaturvedi <suchita.chaturvedi at oracle.com>
Committer: thegreystone <marcus at hirt.se>
Date:      2023-01-18 13:25:21 +0000
URL:       https://git.openjdk.org/jmc/commit/e037d23d277115c3cad94e1b24d6bff28abdf63a

7823: Enhance JMC configuration

! application/org.openjdk.jmc.console.agent/src/main/java/org/openjdk/jmc/console/agent/manager/model/Preset.java
! application/org.openjdk.jmc.console.agent/src/main/java/org/openjdk/jmc/console/agent/utils/ProbeValidator.java
! releng/tools/org.openjdk.jmc.util.releasenotes/src/org/openjdk/jmc/utils/releasenotes/Transform.java


From vpurnam at openjdk.org  Thu Aug 31 05:14:37 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Thu, 31 Aug 2023 05:14:37 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v3]
In-Reply-To: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
Message-ID: <D5e9xx_X0iltQalCeXFMQcXfyiZJI47_1tcFieYq2YA=.bd342dc3-d853-482b-8731-6e86cd94a796@github.com>

> When multiple views are enabled in JMC mainly Dependency View and Heatmap View. (Issue was with Flame graph as well but it got fixed as the implementation is now based on swing component)
> 
> For the Dependency View and Heatmap View still the implementation is based on javascript and for one particular scenario JMC gives "**java.lang.OutOfMemoryError: Java heap space**". 
> 
> **Scenario:**
> For each selection in a table, views get rendered. For each click on table, 4 threads call method "**toJsonString(IItemCollection items)**" present in "**IItemCollectionJsonSerializer**" class. Within method it appends the items to a StringBuilder and then it writes it to a StringWriter. When we have multiple JFR files open in editor, or we select the table contents very fast, multiple threads call the method at the same time and all try to append and write at the same time. This results in the "**java.lang.OutOfMemoryError: Java heap space**". 
> 
> ![image](https://github.com/openjdk/jmc/assets/97600378/ae24614c-c640-4dc0-9c4c-7f70ee2f164f)
> 
> ![image](https://github.com/openjdk/jmc/assets/97600378/a41434d7-7bb1-47a0-bb7f-6a8b8e17af30)
> 
> 
> **Possible solution:** Making method  "**toJsonString(IItemCollection items)**" synchronized. I have done the changes and created a PR. 
> 
> Could you please review and provide your comments on this? If there are better way to solve this issue, could you please suggest me the same?

Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:

  7885: Graphical rendering of dependency view fails due to heap memory drain

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

Changes:
  - all: https://git.openjdk.org/jmc/pull/511/files
  - new: https://git.openjdk.org/jmc/pull/511/files/1f70b722..a0df94ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=511&range=02
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=511&range=01-02

  Stats: 159 lines in 5 files changed: 73 ins; 62 del; 24 mod
  Patch: https://git.openjdk.org/jmc/pull/511.diff
  Fetch: git fetch https://git.openjdk.org/jmc.git pull/511/head:pull/511

PR: https://git.openjdk.org/jmc/pull/511

From vpurnam at openjdk.org  Thu Aug 31 05:53:09 2023
From: vpurnam at openjdk.org (Virag Purnam)
Date: Thu, 31 Aug 2023 05:53:09 GMT
Subject: RFR: 7885: Graphical rendering of dependency view fails due to
 heap memory drain [v2]
In-Reply-To: <OgbujOb3yjoRNFoEcL0wA1AsPD7zsbhDXrlQFkHQi7o=.7053f535-86a7-4b3a-9ae0-c51332168f51@github.com>
References: <rOhyqaxvgbIigEJvuqcmldYWo0OkTT0gfKZwAklLuxc=.6c8c68f7-2179-4d66-99b1-d50a477da6a6@github.com>
 <hCicbw-M8Bq3I50QGl6TYk_fqmP5840ev0m_lAjytv4=.aff5ce26-53b1-451f-b9d9-0c36002413b3@github.com>
 <OgbujOb3yjoRNFoEcL0wA1AsPD7zsbhDXrlQFkHQi7o=.7053f535-86a7-4b3a-9ae0-c51332168f51@github.com>
Message-ID: <5LOOqqZEB8_SI8ggFSrEDCKFw2xqAGwqNvSShYfMrqI=.90a3ef0a-690a-4168-a13f-fb72064f9147@github.com>

On Wed, 23 Aug 2023 19:41:19 GMT, Vincent Alexander Beelte <duke at openjdk.org> wrote:

>> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   7885: Graphical rendering of dependency view fails due to heap memory drain
>
> Sure go ahead and adapt that idea however you see fit. I had already gotten approval to contribute that myself from Accenture but I never did because in the end I felt it wasn't enough of an improvement.
> Even with that change I could easily make the JSONs big enough that they won't fit into the Java array size limits. And I did not even need to use abnormally large recordings for that.
> I think fully removing the JSONs is not easily possible but you might want to explore changing the format unless there are consumers outside the scope of what you could change.
> I imagine there might be a lot of duplicate content in those JSONs like maybe stacktraces or class names. You could implement a manual dictionary compression (I believe that's the word for what I am proposing).
> Instead of for example
> 
> {
>     "people": [
>         {
>             "firstName": "John",
>             "lastName": "Smith"
>         },
>         {
>             "firstName": "Max",
>             "lastName": "Miller"
>         },
>         {
>             "firstName": "Max",
>             "lastName": "Smith"
>         },
>         {
>             "firstName": "John",
>             "lastName": "Miller"
>         }
>     ]
> }
> 
> you could do this
> 
> {
>     "people": [
>         {
>             "firstName": 0,
>             "lastName": 1
>         },
>         {
>             "firstName": 2,
>             "lastName": 3
>         },
>         {
>             "firstName": 2,
>             "lastName": 1
>         },
>         {
>             "firstName": 0,
>             "lastName": 3
>         }
>     ],
>     "strings": ["John", "Smith", "Max", "Miller"]
> }
> 
> In this example the last JSON wasn't actually smaller in terms of characters because the names are too short, but I think I have shown the idea.

I have updated this PR with the changes suggested by @grandmasterpixel. Could somebody please review the changes. Thanks

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

PR Comment: https://git.openjdk.org/jmc/pull/511#issuecomment-1700406211