From duke at openjdk.org Mon Sep 4 13:36:52 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Mon, 4 Sep 2023 13:36:52 GMT Subject: Integrated: 8112: Flamegraph model creation performance improvements In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 16:06:45 GMT, Vincent Alexander Beelte 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-07ee802d3e63) > This is filtered to on... This pull request has now been integrated. Changeset: 890cccf9 Author: Vincent Alexander Beelte Committer: Christoph Langer URL: https://git.openjdk.org/jmc/commit/890cccf94c6b703003ecacb32f3ff5586ab88683 Stats: 258 lines in 10 files changed: 111 ins; 59 del; 88 mod 8112: Flamegraph model creation performance improvements Reviewed-by: clanger, aptmac ------------- PR: https://git.openjdk.org/jmc/pull/502 From bdutheil at openjdk.org Tue Sep 5 07:55:53 2023 From: bdutheil at openjdk.org (Brice Dutheil) Date: Tue, 5 Sep 2023 07:55:53 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 09:50:11 GMT, Vincent Alexander Beelte 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 Spotted a breaking change. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 366: > 364: FlightRecorderUI.getDefault().getLogger() > 365: .info("model rebuild with isInvalid:" + isInvalid + " in " + duration); > 366: } **suggestion:** Should we remove this wrapping code ? core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/tree/Node.java line 97: > 95: public Integer getNodeId() { > 96: return nodeId; > 97: } **issue:** This is a breaking change. And should be reverted. ------------- PR Review: https://git.openjdk.org/jmc/pull/502#pullrequestreview-1610431803 PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1315510256 PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1315508298 From duke at openjdk.org Tue Sep 5 18:01:58 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Tue, 5 Sep 2023 18:01:58 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 07:48:11 GMT, Brice Dutheil wrote: >> Vincent Alexander Beelte has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright header with 2023 > > core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/tree/Node.java line 97: > >> 95: public Integer getNodeId() { >> 96: return nodeId; >> 97: } > > **issue:** This is a breaking change. And should be reverted. Oh, did someone add a call to this? That's unfortunate. Overall this was not that important for performance. It was however also used in the equals method, which I think was wrong. The nodeId is computed using hashing so in theory there might be collisions. Using that for equals would mean Nodes are only compared to be "kind of" equal and not exactly equal. I did however also never find a reference where the equals would have been called. I even had a breakpoint in it that never was hit. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1316221413 From bdutheil at openjdk.org Tue Sep 5 18:33:53 2023 From: bdutheil at openjdk.org (Brice Dutheil) Date: Tue, 5 Sep 2023 18:33:53 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: Message-ID: <0-EVAIZ5czl4YAqpQoPg2nA6SQXKMGUNxHDSm98qni4=.dbea9a05-591a-473e-9d31-e86ab4cd3c3d@github.com> On Tue, 5 Sep 2023 17:59:07 GMT, Vincent Alexander Beelte wrote: >> core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/stacktrace/tree/Node.java line 97: >> >>> 95: public Integer getNodeId() { >>> 96: return nodeId; >>> 97: } >> >> **issue:** This is a breaking change. And should be reverted. > > Oh, did someone add a call to this? That's unfortunate. Overall this was not that important for performance. It was however also used in the equals method, which I think was wrong. The nodeId is computed using hashing so in theory there might be collisions. Using that for equals would mean Nodes are only compared to be "kind of" equal and not exactly equal. > I did however also never find a reference where the equals would have been called. I even had a breakpoint in it that never was hit. It's probable. This could be used in tests in other libraries, or else. The core libraries are distributed on maven, so whether it is used or not such API changes should be avoided. That said I understand the change to make this lazy. I think this is alright to drop the node id from the equals. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1316254248 From hirt at openjdk.org Fri Sep 8 22:49:58 2023 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 8 Sep 2023 22:49:58 GMT Subject: RFR: 8120: Build JMC for Linux aarch64 Message-ID: It was asked for at Adoptium, issue 46: https://github.com/adoptium/jmc-build/issues/46 I don't have an M1 with Linux installed, so I have no way of verifying this, unfortunately. Perhaps someone out there can help. ------------- Commit messages: - 8120: Build JMC for Linux aarch64 Changes: https://git.openjdk.org/jmc/pull/514/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=514&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8120 Stats: 31 lines in 2 files changed: 29 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jmc/pull/514.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/514/head:pull/514 PR: https://git.openjdk.org/jmc/pull/514 From duke at openjdk.org Sun Sep 10 16:19:50 2023 From: duke at openjdk.org (Vincent Alexander Beelte) Date: Sun, 10 Sep 2023 16:19:50 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: <0-EVAIZ5czl4YAqpQoPg2nA6SQXKMGUNxHDSm98qni4=.dbea9a05-591a-473e-9d31-e86ab4cd3c3d@github.com> References: <0-EVAIZ5czl4YAqpQoPg2nA6SQXKMGUNxHDSm98qni4=.dbea9a05-591a-473e-9d31-e86ab4cd3c3d@github.com> Message-ID: On Tue, 5 Sep 2023 18:29:43 GMT, Brice Dutheil wrote: >> Oh, did someone add a call to this? That's unfortunate. Overall this was not that important for performance. It was however also used in the equals method, which I think was wrong. The nodeId is computed using hashing so in theory there might be collisions. Using that for equals would mean Nodes are only compared to be "kind of" equal and not exactly equal. >> I did however also never find a reference where the equals would have been called. I even had a breakpoint in it that never was hit. > > It's probable. This could be used in tests in other libraries, or else. The core libraries are distributed on maven, so whether it is used or not such API changes should be avoided. > > That said I understand the change to make this lazy. I think this is alright to drop the node id from the equals. Oh that's what you meant. I wasn't aware that all of jmc is also published to maven. Then it was obviously wrong to just delete part of the public API. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1320796828 From bdutheil at openjdk.org Mon Sep 11 06:20:51 2023 From: bdutheil at openjdk.org (Brice Dutheil) Date: Mon, 11 Sep 2023 06:20:51 GMT Subject: RFR: 8112: Flamegraph model creation performance improvements [v4] In-Reply-To: References: <0-EVAIZ5czl4YAqpQoPg2nA6SQXKMGUNxHDSm98qni4=.dbea9a05-591a-473e-9d31-e86ab4cd3c3d@github.com> Message-ID: On Sun, 10 Sep 2023 16:16:46 GMT, Vincent Alexander Beelte wrote: > I wasn't aware that all of jmc is also published to maven. Only the core libraries. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/502#discussion_r1321040268 From hirt at openjdk.org Tue Sep 19 10:12:54 2023 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 19 Sep 2023 10:12:54 GMT Subject: RFR: 7885: Graphical rendering of dependency view fails due to heap memory drain [v3] In-Reply-To: References: Message-ID: <6rxoPpzzIoQ_k_JuaX1iB5wI5WnPLnvXMSPfscqVqho=.bf7f9260-d648-4c0e-87c9-9bb81f07f0e4@github.com> On Thu, 31 Aug 2023 05:14:37 GMT, Virag Purnam 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 Marked as reviewed by hirt (Lead). application/org.openjdk.jmc.flightrecorder.heatmap/src/main/java/org/openjdk/jmc/flightrecorder/heatmap/views/HeatmapView.java line 107: > 105: LOGGER.info("starting to create model"); > 106: try { > 107: view.modelState = ModelState.STARTED; Not really necessary to move into the try block. I'd try to keep the block as small as possible. application/org.openjdk.jmc.flightrecorder.heatmap/src/main/java/org/openjdk/jmc/flightrecorder/heatmap/views/HeatmapView.java line 108: > 106: try { > 107: view.modelState = ModelState.STARTED; > 108: if (isInvalid) { This code smells a bit, but since that is already how we do it, it's fine. ------------- PR Review: https://git.openjdk.org/jmc/pull/511#pullrequestreview-1625011873 PR Review Comment: https://git.openjdk.org/jmc/pull/511#discussion_r1324801732 PR Review Comment: https://git.openjdk.org/jmc/pull/511#discussion_r1324813624 From jmatsuoka at openjdk.org Wed Sep 20 16:16:33 2023 From: jmatsuoka at openjdk.org (Joshua Matsuoka) Date: Wed, 20 Sep 2023 16:16:33 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v4] 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: > 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 21 commits: - Removing extraneous merge artifacts - Merge remote-tracking branch 'upstream/master' into 7307 - running spotlesS - 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 - ... and 11 more: https://git.openjdk.org/jmc/compare/890cccf9...b6ef486d ------------- Changes: https://git.openjdk.org/jmc/pull/469/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=469&range=03 Stats: 1073 lines in 109 files changed: 330 ins; 561 del; 182 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 jmatsuoka at openjdk.org Wed Sep 20 16:34:32 2023 From: jmatsuoka at openjdk.org (Joshua Matsuoka) Date: Wed, 20 Sep 2023 16:34:32 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v5] 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: > 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/b6ef486d..43d0afe8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=469&range=04 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=469&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 Tue Sep 26 14:26:31 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 26 Sep 2023 14:26:31 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v5] In-Reply-To: References: <8p-z-kv8ll6PNFq7L5wxKpIv7n1Cy8KIv2wzlSRD7PU=.2073f3f6-ad4e-480d-b20c-431ace2e9d7a@github.com> Message-ID: On Wed, 20 Sep 2023 16:34:32 GMT, Joshua Matsuoka 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 Just a couple of checkstyle issues here: - there's a redundant import in both `SecurelyStoredByteArray` and `SecurityManagerFactory` - `PersistentCredentials` had it's import of `java.util.regex.Pattern` removed. Other than that I think it's just the license header update to 2023 and then this should be ready for re-reviewing. Here's a quick diff that you could apply to fix: diff --git a/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/PersistentCredentials.java b/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/PersistentCredentials.java index 4e4197b5..1f8bf860 100644 --- a/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/PersistentCredentials.java +++ b/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/PersistentCredentials.java @@ -33,6 +33,7 @@ package org.openjdk.jmc.common.security; import java.util.regex.Matcher; +import java.util.regex.Pattern; /** * {@link ICredentials} stored in the {@link ISecurityManager}. The username and password are lazy diff --git a/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurelyStoredByteArray.java b/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurelyStoredByteArray.java index aa85e5d5..8cd47f8f 100644 --- a/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurelyStoredByteArray.java +++ b/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurelyStoredByteArray.java @@ -32,8 +32,6 @@ */ package org.openjdk.jmc.common.security; -import org.openjdk.jmc.common.security.SecurityManagerFactory; - public class SecurelyStoredByteArray { private final String id; diff --git a/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurityManagerFactory.java b/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurityManagerFactory.java index 64cd7b66..4eb8dac0 100644 --- a/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurityManagerFactory.java +++ b/core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/security/SecurityManagerFactory.java @@ -35,8 +35,6 @@ package org.openjdk.jmc.common.security; import java.util.logging.Level; import java.util.logging.Logger; -import org.openjdk.jmc.common.security.ISecurityManager; - /** * This is the global security manager factory for Mission Control. You can only have one * SecurityManager, and it is initialized at start. It can not be changed once initialized. The only ------------- PR Comment: https://git.openjdk.org/jmc/pull/469#issuecomment-1735650689 From jbechberger at openjdk.org Thu Sep 28 12:18:02 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 28 Sep 2023 12:18:02 GMT Subject: RFR: 8121: JMC should fail properly when executed with <17 JDK Message-ID: Set `osgi.requireJavaVersion` property for in `jmc.product`, so that JMC fails directly with an understandable error message when it started on a <17 JDK. The new error message looks like the follows when running JMC on JDK 1.8: MicrosoftTeams-image I tested it with various supported and unsupported JDK versions and it worked as expected. ------------- Commit messages: - Clarify required Java version for builds - Set osgi required Java version Changes: https://git.openjdk.org/jmc/pull/516/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=516&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8121 Stats: 14 lines in 2 files changed: 1 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/516.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/516/head:pull/516 PR: https://git.openjdk.org/jmc/pull/516 From aptmac at openjdk.org Thu Sep 28 14:55:33 2023 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 28 Sep 2023 14:55:33 GMT Subject: RFR: 8121: JMC should fail properly when executed with <17 JDK In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 12:06:32 GMT, Johannes Bechberger wrote: > Set `osgi.requireJavaVersion` property for in `jmc.product`, so that JMC fails directly with an understandable error message when it started on a <17 JDK. > > The new error message looks like the follows when running JMC on JDK 1.8: > > MicrosoftTeams-image > > I tested it with various supported and unsupported JDK versions and it worked as expected. Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/516#pullrequestreview-1649075415 From jbechberger at openjdk.org Thu Sep 28 15:04:43 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 28 Sep 2023 15:04:43 GMT Subject: Integrated: 8121: JMC should fail properly when executed with <17 JDK In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 12:06:32 GMT, Johannes Bechberger wrote: > Set `osgi.requireJavaVersion` property for in `jmc.product`, so that JMC fails directly with an understandable error message when it started on a <17 JDK. > > The new error message looks like the follows when running JMC on JDK 1.8: > > MicrosoftTeams-image > > I tested it with various supported and unsupported JDK versions and it worked as expected. This pull request has now been integrated. Changeset: ed9c2456 Author: Johannes Bechberger Committer: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/ed9c2456f7c19750191fe06560afee4af84c00b5 Stats: 14 lines in 2 files changed: 1 ins; 12 del; 1 mod 8121: JMC should fail properly when executed with <17 JDK Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/516