From jpbempel at openjdk.org Mon Oct 3 09:00:37 2022 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Mon, 3 Oct 2022 09:00:37 GMT Subject: RFR: 7903: FastAccessNumberMap is slow for sparse values [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 12:53:36 GMT, Richard Startin wrote: >> This reworks `FastAccessNumberMap` so that a small bitset can be stored in each page of values, which can be used to skip over null values during iteration. A simple benchmark shows a modest enhancement to calls to `get`, but significant improvements to iteration speed when the map contains sparse values (iteration now scales with the number of non-null values, not the number of pages). >> >> >> import org.openjdk.jmc.common.collection.FastAccessNumberMap; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.BenchmarkMode; >> import org.openjdk.jmh.annotations.Fork; >> import org.openjdk.jmh.annotations.Level; >> import org.openjdk.jmh.annotations.Measurement; >> import org.openjdk.jmh.annotations.Mode; >> import org.openjdk.jmh.annotations.OutputTimeUnit; >> import org.openjdk.jmh.annotations.Param; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.Warmup; >> import org.openjdk.jmh.infra.Blackhole; >> >> import java.util.concurrent.TimeUnit; >> >> @OutputTimeUnit(TimeUnit.MICROSECONDS) >> @Warmup(iterations = 5, time = 1) >> @Measurement(iterations = 5, time = 1) >> @Fork(1) >> @BenchmarkMode(Mode.AverageTime) >> @State(Scope.Benchmark) >> public class FastAccessNumberMapBenchmark { >> private FastAccessNumberMap map; >> @Param({"1", "2", "3", "4", "64"}) >> int period; >> private int size; >> private long[] values; >> >> @Setup(Level.Trial) >> public void setup() { >> map = new FastAccessNumberMap<>(); >> values = new long[5000]; >> for (int i = 0; i < 5000; i += period) { >> map.put(i, String.valueOf(i)); >> values[size++] = i; >> } >> } >> >> @Benchmark >> public void get(Blackhole bh) { >> for (int i = 0; i < size; i++) { >> bh.consume(map.get(values[i])); >> } >> } >> >> @Benchmark >> public void iterate(Blackhole bh) { >> map.forEach(bh::consume); >> } >> } >> ``` >> >> Tested with 17.0.4.1 2022-08-12 on a Mac M1 >> After: >> >> Benchmark (period) Mode Cnt Score Error Units >> FastAccessNumberMapBenchmark.get 1 avgt 5 17.864 ? 0.044 us/op >> FastAccessNumberMapBenchmark.get 2 avgt 5 8.921 ? 0.124 us/op >> FastAccessNumberMapBenchmark.get 3 avgt 5 5.916 ? 0.052 us/op >> FastAccessNumberMapBenchmark.get 4 avgt 5 4.351 ? 0.011 us/op >> FastAccessNumberMapBenchmark.get 64 avgt 5 0.273 ? 0.001 us/op >> FastAccessNumberMapBenchmark.iterate 1 avgt 5 16.241 ? 0.581 us/op >> FastAccessNumberMapBenchmark.iterate 2 avgt 5 8.768 ? 0.205 us/op >> FastAccessNumberMapBenchmark.iterate 3 avgt 5 5.463 ? 0.051 us/op >> FastAccessNumberMapBenchmark.iterate 4 avgt 5 4.095 ? 0.103 us/op >> FastAccessNumberMapBenchmark.iterate 64 avgt 5 0.441 ? 0.002 us/op >> >> >> Before: >> >> Benchmark (period) Mode Cnt Score Error Units >> FastAccessNumberMapBenchmark.get 1 avgt 5 18.937 ? 0.212 us/op >> FastAccessNumberMapBenchmark.get 2 avgt 5 9.419 ? 0.042 us/op >> FastAccessNumberMapBenchmark.get 3 avgt 5 6.151 ? 0.108 us/op >> FastAccessNumberMapBenchmark.get 4 avgt 5 4.618 ? 0.031 us/op >> FastAccessNumberMapBenchmark.get 64 avgt 5 0.286 ? 0.001 us/op >> FastAccessNumberMapBenchmark.iterate 1 avgt 5 19.142 ? 0.611 us/op >> FastAccessNumberMapBenchmark.iterate 2 avgt 5 18.930 ? 4.756 us/op >> FastAccessNumberMapBenchmark.iterate 3 avgt 5 11.579 ? 0.082 us/op >> FastAccessNumberMapBenchmark.iterate 4 avgt 5 11.650 ? 0.500 us/op >> FastAccessNumberMapBenchmark.iterate 64 avgt 5 11.781 ? 0.541 us/op >> >> >> We use the jmc common library in a backend process at Datadog and see bigger improvements than the microbenchmark above would suggest. > > Richard Startin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 7903: optimise FastAccessNumberMap.get and FastAccessNumberMap.iterate Copyright year was not updated either ------------- PR: https://git.openjdk.org/jmc/pull/431 From hirt at openjdk.org Tue Oct 4 14:14:34 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 4 Oct 2022 14:14:34 GMT Subject: RFR: 7350: [Accessibility, JAWS] Deadlinks in Help Page In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:35:15 GMT, Suchita Chaturvedi wrote: > This link is present in all the help pages and everywhere its just a dead link. As per the code, it navigates to the begin of the page which is already displayed and no extra navigation is required for the same. I can't find a logical purpose this link serves. Hence, this PR removes this link from all pages. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.org/jmc/pull/430 From hirt at openjdk.org Tue Oct 4 14:18:34 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 4 Oct 2022 14:18:34 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 22:09:37 GMT, Suchita Chaturvedi wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > >> Is https://bugs.openjdk.org/browse/JMC-7879 a duplicate of https://bugs.openjdk.org/browse/JMC-7248? >> >> It looks like this PR is #248 with some of the review comments addressed, should the former PR be closed in favor of this? >> >> There are a couple of review comments that didn't receive any changes in this PR: https://github.com/openjdk/jmc/pull/248/files#r756349943 https://github.com/openjdk/jmc/pull/248/files#r756353644 >> >> It looks like the consensus on #248 was that it was good enough to go in, maybe ping @bric3 and/or @Gunde for a re-review/approval? > > This PR is a superset of the previous one. The older one deals with only optimization of the class leak rule but this one deals with the optimization as well as the correction of the results shown on automated analysis page for class leak rule. I have implemented all the review comments given on the previous PR. With respect to the two comments mentioned above, the configured timeout is being fetched from preference hence I am finding it difficult to make it final. The interrupted exception handling is done where the method is called in catch block. I had already pinged about this issue in general slack channel and it was discussed in hangout also. > > @Gunde and @bric3 Request both of you to please take a look at this PR and let me know your review comments. Thanks in advance. Hi @Suchitainf! When will you be able to fix the remaining issues? ------------- PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Wed Oct 5 10:38:29 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 5 Oct 2022 10:38:29 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 17:25:03 GMT, Henrik Dafg?rd wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 156: > >> 154: IItemCollection items, IPreferenceValueProvider valueProvider, IResultValueProvider dependencyResults) { >> 155: int warningLimit = (int) valueProvider.getPreferenceValue(WARNING_LIMIT).longValue(); >> 156: CONFIGURED_TIMEOUT = (int) valueProvider.getPreferenceValue(MAX_TIMEOUT).longValue(); > > Nit: This preference should use .clampedLongValueIn and passing in the appropriate unit, so since the timeout use of this specifies TimeUnit.MINUTES we should use valueProvider.getPreferenceValue(MAX_TIMEOUT).clampedLongValueIn(UnitLookup.MINUTE).longValue(). If we use clampedLongValueIn then longValue() should be removed right? We can't use both together. ------------- PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Wed Oct 5 11:03:35 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 5 Oct 2022 11:03:35 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. In-Reply-To: References: Message-ID: On Sat, 20 Aug 2022 18:59:14 GMT, Suchita Chaturvedi wrote: > This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. I believe some changes are still required. core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 105: > 103: > 104: public static final TypedPreference MAX_TIMEOUT = new TypedPreference<>( > 105: "classLeaking.calculation.timeout", //$NON-NLS-1$ Just a suggestion Suggestion: "classLeakingRuke.calculation.timeout", //$NON-NLS-1$ core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 54: > 52: import org.openjdk.jmc.common.item.IType; > 53: import org.openjdk.jmc.common.item.ItemFilters; > 54: import org.openjdk.jmc.flightrecorder.rules.jdk.general.ClassLeakingRule; I don't think that desirable to make `DefaultIItemResultSet` depend on `ClassLeakingRule`, this make every rule that use that class usage of that class having the same timeout as `ClassLeakingRule` (even if _as of today_ only 2 rule use this). I believe the code will be better to add an override like this (adapt the timeout type if necessary), and of course the constructor of `DefaultIItemResultSet`. public class ItemResultSetFactory { public IItemResultSet createResultSet(IItemCollection items, IItemQuery query) { return new DefaultIItemResultSet(items, query); } + public IItemResultSet createResultSet(IItemCollection items, IItemQuery query, LinearQuantity timeout) { + return new DefaultIItemResultSet(items, query, timeout); + } } And make `ItemResultSetFactory.createResultSet(IItemCollection items, IItemQuery query)` use the default timeout. Maybe the default can be `null` to indicate there's no timeout, I think `MINUTE.quantity(-1)` could work. ----- Rule usages https://github.com/openjdk/jmc/blob/1696e03a1fddb9cc68d32bf21a281ef24366e552/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java#L220 https://github.com/openjdk/jmc/blob/1696e03a1fddb9cc68d32bf21a281ef24366e552/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/latency/BiasedLockingRevocationRule.java#L256 core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 128: > 126: synchronized (data) { > 127: data.add(row); > 128: } In my previous [comment](https://github.com/openjdk/jmc/pull/248/files#r633606757) on #248 I was thinking more about tweaking the collection, sorry for the lack of precision back then. So something like: - private final ArrayList data = new ArrayList<>(); + private final List data = Collections.synchronizedList(new ArrayList()); Or if the insertion order is irrelevant one might think of a `ConcurrentLinkedQueue` instead during the calculation, and copy the elements in the array list once done. core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 134: > 132: } finally { > 133: exec.shutdown(); > 134: exec.awaitTermination(ClassLeakingRule.CONFIGURED_TIMEOUT, TimeUnit.MINUTES); I believe the proper executor shutdown sequence would be something like this Suggestion: } finally { exec.shutdown(); try { if (!exec.awaitTermination(60, TimeUnit.SECONDS)) { exec.shutdownNow(); // possibly wait for other task to respond to cancellation, possibly not needed in this case. But useful to keep, if this code gets extracted away. if (!pool.awaitTermination(timeout.clampedLongValueIn(MINUTE), TimeUnit.MINUTES)) { // TODO notify error that pool did not terminate } } } catch (InterruptedException ie) { exec.shutdownNow(); Thread.currentThread().interrupt(); } ------------- Changes requested by bdutheil (Author). PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Wed Oct 5 11:03:36 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 5 Oct 2022 11:03:36 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 18:26:23 GMT, Henrik Dafg?rd wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 108: > >> 106: Messages.getString(Messages.ClassLeakingRule_CONFIG_CALCULATION_TIMEOUT), >> 107: Messages.getString(Messages.ClassLeakingRule_CONFIG_CALCULATION_TIMEOUT_LONG), NUMBER, >> 108: NUMBER_UNITY.quantity(5)); > > Nit: The timeout value should be a timestamp instead. Why not `TIMESPAN`, `MINUTE.quantity(5)` ? ------------- PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Wed Oct 5 11:03:36 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 5 Oct 2022 11:03:36 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 10:27:42 GMT, Brice Dutheil wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 128: > >> 126: synchronized (data) { >> 127: data.add(row); >> 128: } > > In my previous [comment](https://github.com/openjdk/jmc/pull/248/files#r633606757) on #248 I was thinking more about tweaking the collection, sorry for the lack of precision back then. So something like: > > > - private final ArrayList data = new ArrayList<>(); > + private final List data = Collections.synchronizedList(new ArrayList()); > > > Or if the insertion order is irrelevant one might think of a `ConcurrentLinkedQueue` instead during the calculation, and copy the elements in the array list once done. Last time I didn't thought about the order of the results, Is it something to take care, I really lack flightrecorder rule knowledge here. ------------- PR: https://git.openjdk.org/jmc/pull/419 From hdafgard at openjdk.org Wed Oct 5 11:47:16 2022 From: hdafgard at openjdk.org (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Wed, 5 Oct 2022 11:47:16 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 09:32:51 GMT, Brice Dutheil wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 105: > >> 103: >> 104: public static final TypedPreference MAX_TIMEOUT = new TypedPreference<>( >> 105: "classLeaking.calculation.timeout", //$NON-NLS-1$ > > Just a suggestion > > Suggestion: > > "classLeakingRuke.calculation.timeout", //$NON-NLS-1$ `classLeakingRule`, no? ------------- PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Wed Oct 5 12:28:24 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 5 Oct 2022 12:28:24 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 11:43:37 GMT, Henrik Dafg?rd wrote: >> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 105: >> >>> 103: >>> 104: public static final TypedPreference MAX_TIMEOUT = new TypedPreference<>( >>> 105: "classLeaking.calculation.timeout", //$NON-NLS-1$ >> >> Just a suggestion >> >> Suggestion: >> >> "classLeakingRuke.calculation.timeout", //$NON-NLS-1$ > > `classLeakingRule`, no? I have checked at other places and "Rule" is not mentioned anywhere for Preferences. For ClassLeakRule also there are other preferences like classLeaking.warning.limit and classLeaking.classesToReport.limit , the keyword Rule is not used anywhere. Hence, I have skipped it to follow the convention. For other rules also like Biased Revocation Rule, the preference is biasedRevocation.classesToReport.limit. ------------- PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Wed Oct 5 18:40:35 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 5 Oct 2022 18:40:35 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v2] In-Reply-To: References: Message-ID: > This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments ------------- Changes: - all: https://git.openjdk.org/jmc/pull/419/files - new: https://git.openjdk.org/jmc/pull/419/files/258e62fe..2486c86b Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=00-01 Stats: 43 lines in 4 files changed: 22 ins; 4 del; 17 mod Patch: https://git.openjdk.org/jmc/pull/419.diff Fetch: git fetch https://git.openjdk.org/jmc pull/419/head:pull/419 PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Wed Oct 5 18:40:35 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 5 Oct 2022 18:40:35 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 17:53:47 GMT, Henrik Dafg?rd wrote: >> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented review comments > > I have a few nits and one necessary change before we can merge this. @Gunde @bric3 I have tried to implement all the review comments. Please re-review the PR and let me know if there is something which is still need to be corrected. ------------- PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Wed Oct 5 20:02:30 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 5 Oct 2022 20:02:30 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v2] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 12:24:56 GMT, Suchita Chaturvedi wrote: >> `classLeakingRule`, no? > > I have checked at other places and "Rule" is not mentioned anywhere for Preferences. For ClassLeakRule also there are other preferences like classLeaking.warning.limit and classLeaking.classesToReport.limit , the keyword Rule is not used anywhere. Hence, I have skipped it to follow the convention. For other rules also like Biased Revocation Rule, the preference is biasedRevocation.classesToReport.limit. > `classLeakingRule`, no? Good catch on the typo, fixed @Suchitainf I missed those from GH, you can dismiss this suggestion ! ------------- PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Wed Oct 5 20:21:32 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 5 Oct 2022 20:21:32 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v2] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 18:35:26 GMT, Suchita Chaturvedi wrote: >> I have a few nits and one necessary change before we can merge this. > > @Gunde @bric3 I have tried to implement all the review comments. Please re-review the PR and let me know if there is something which is still need to be corrected. @Suchitainf There's still these two comment to address in my opinion: * https://github.com/openjdk/jmc/pull/419#discussion_r987769827 * https://github.com/openjdk/jmc/pull/419#discussion_r988313757 Note I'm really unsure about the result ordering there, may be @thegreystone or @Gunde may chime in there to make sure this change is ok. ------------- PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Wed Oct 5 20:21:33 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Wed, 5 Oct 2022 20:21:33 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v2] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 18:40:35 GMT, Suchita Chaturvedi wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/ItemResultSetFactory.java line 43: > 41: public class ItemResultSetFactory { > 42: public IItemResultSet createResultSet(IItemCollection items, IItemQuery query) { > 43: return new DefaultIItemResultSet(items, query, 0); The issue with a value of 0 means the termination will be effective immediately (after the first 60 seconds), I think you can choose either * a guard value like `-1` is better and in `DefaultIItemResultSet` just skip the termination. * chose a very big value like one day (that's what JDK 19 does in `ExecutorService.close`, but the code can even wait longer) ------------- PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Thu Oct 6 04:19:30 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Thu, 6 Oct 2022 04:19:30 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v2] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 20:16:36 GMT, Brice Dutheil wrote: >> @Gunde @bric3 I have tried to implement all the review comments. Please re-review the PR and let me know if there is something which is still need to be corrected. > > @Suchitainf There's still these two comment to address in my opinion: > * https://github.com/openjdk/jmc/pull/419#discussion_r987769827 > * https://github.com/openjdk/jmc/pull/419#discussion_r988313757 > > Note I'm really unsure about the result ordering there, may be @thegreystone or @Gunde may chime in there to make sure this change is ok. @bric3 We need to show the names of top 5 classes which were loaded maximum times without being unloaded. So the ordering matters here. That's why I have skipped that comment. ------------- PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Thu Oct 6 04:54:23 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Thu, 6 Oct 2022 04:54:23 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v3] In-Reply-To: References: Message-ID: > This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Added check for default configured timeout ------------- Changes: - all: https://git.openjdk.org/jmc/pull/419/files - new: https://git.openjdk.org/jmc/pull/419/files/2486c86b..026795d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/419.diff Fetch: git fetch https://git.openjdk.org/jmc pull/419/head:pull/419 PR: https://git.openjdk.org/jmc/pull/419 From jbachorik at openjdk.org Thu Oct 6 07:27:27 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 6 Oct 2022 07:27:27 GMT Subject: RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v2] In-Reply-To: References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> Message-ID: <1ggycSBbykLhhFJdcYPyD9MrrGBHxgN83TK2xxwph6s=.3273397d-af1f-4a0d-9549-729af6aa5763@github.com> On Mon, 18 Jul 2022 11:57:08 GMT, Christoph Langer wrote: >> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Update copyrights >> - Merge branch 'master' into jb/JMC-7855 >> - JMC-7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks > > core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/api/RecordingSettingsBuilder.java line 57: > >> 55: * @since 8.3.0 >> 56: */ >> 57: default RecordingSettingsBuilder withStartTicks(long ticks) { > > Do we really need a default method here? That is, could it be that we load an older implementation class of this interface that doesn't have this method implemented? I was being defensive here since this is a public API. But perhaps we can get away with a technically breaking change since our writer APIs are never accepting an instance of `RecordingSettings` but rather just providing it in a callback - that way we are still having the full control over the concrete instance being used. ------------- PR: https://git.openjdk.org/jmc/pull/412 From jbachorik at openjdk.org Thu Oct 6 07:32:32 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 6 Oct 2022 07:32:32 GMT Subject: RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v2] In-Reply-To: <1ggycSBbykLhhFJdcYPyD9MrrGBHxgN83TK2xxwph6s=.3273397d-af1f-4a0d-9549-729af6aa5763@github.com> References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> <1ggycSBbykLhhFJdcYPyD9MrrGBHxgN83TK2xxwph6s=.3273397d-af1f-4a0d-9549-729af6aa5763@github.com> Message-ID: <_IP_p9vGGq2Ur-cb-hpqDxz3vbaD5j0R6Oxo7JOzxVE=.f70b4918-69f0-40c4-926d-552e12710b52@github.com> On Thu, 6 Oct 2022 07:25:15 GMT, Jaroslav Bachorik wrote: >> core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/api/RecordingSettingsBuilder.java line 57: >> >>> 55: * @since 8.3.0 >>> 56: */ >>> 57: default RecordingSettingsBuilder withStartTicks(long ticks) { >> >> Do we really need a default method here? That is, could it be that we load an older implementation class of this interface that doesn't have this method implemented? > > I was being defensive here since this is a public API. > But perhaps we can get away with a technically breaking change since our writer APIs are never accepting an instance of `RecordingSettings` but rather just providing it in a callback - that way we are still having the full control over the concrete instance being used. Let's see what @thegreystone has to say - I agree that in this case the default methods don't make much sense, on the other hand there is the thing about API evolution and added interface methods ... So it is more of a question of the code hygiene here. ------------- PR: https://git.openjdk.org/jmc/pull/412 From jbachorik at openjdk.org Thu Oct 6 08:28:28 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 6 Oct 2022 08:28:28 GMT Subject: RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v3] In-Reply-To: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> Message-ID: > Currently, the JFR recordings created by the JMC writer will have the start ticks set to the same value as the start timestamp. This will cause problems with the duration calculation which is using directly `System.nanoTime()` and as such the resulting value will be rather nonsensical. > > This PR adds two new recording settings - `startTicks` and `duration` which can be used to write a JFR recording with correct values set. If the user does not set those settings `startTicks` will be set to the value of `System.nanoTime()` at the moment the recording is started (a `Recording` instance is created) and `duration` will be computed as a diff between the current value of `System.nanoTime()` and `startTicks`. Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision: - Outstanding 'duration' fixes and cleanup - Update and formalize new jfr.writer dependencies ------------- Changes: - all: https://git.openjdk.org/jmc/pull/412/files - new: https://git.openjdk.org/jmc/pull/412/files/d0e5225d..dfedb3f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=412&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=412&range=01-02 Stats: 29 lines in 5 files changed: 18 ins; 6 del; 5 mod Patch: https://git.openjdk.org/jmc/pull/412.diff Fetch: git fetch https://git.openjdk.org/jmc pull/412/head:pull/412 PR: https://git.openjdk.org/jmc/pull/412 From jbachorik at openjdk.org Thu Oct 6 08:28:32 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 6 Oct 2022 08:28:32 GMT Subject: RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v2] In-Reply-To: References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> Message-ID: On Mon, 18 Jul 2022 12:06:50 GMT, Christoph Langer wrote: >> Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Update copyrights >> - Merge branch 'master' into jb/JMC-7855 >> - JMC-7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks > > core/tests/org.openjdk.jmc.flightrecorder.writer.test/pom.xml line 103: > >> 101: org.slf4j >> 102: slf4j-simple >> 103: 1.7.32 > > Any reason for not using 1.7.36 here as well? Fixed ------------- PR: https://git.openjdk.org/jmc/pull/412 From jbachorik at openjdk.org Thu Oct 6 08:33:19 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 6 Oct 2022 08:33:19 GMT Subject: RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v3] In-Reply-To: References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> Message-ID: <6mjBa53noiLJG_UKlT9v7uLqLoelOiZ5qAf7vUy02bw=.ae402af8-cbe9-4e84-a9cb-58a08147190e@github.com> On Thu, 6 Oct 2022 08:28:28 GMT, Jaroslav Bachorik wrote: >> Currently, the JFR recordings created by the JMC writer will have the start ticks set to the same value as the start timestamp. This will cause problems with the duration calculation which is using directly `System.nanoTime()` and as such the resulting value will be rather nonsensical. >> >> This PR adds two new recording settings - `startTicks` and `duration` which can be used to write a JFR recording with correct values set. If the user does not set those settings `startTicks` will be set to the value of `System.nanoTime()` at the moment the recording is started (a `Recording` instance is created) and `duration` will be computed as a diff between the current value of `System.nanoTime()` and `startTicks`. > > Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision: > > - Outstanding 'duration' fixes and cleanup > - Update and formalize new jfr.writer dependencies Hi Christoph, Regarding the varint signedness - it is a bit of grey area. The encoding used in JFR and this writer impl is not preserving sign - but, IMO, it should be possible to write a Java long number in its entirety such that when I write out -1 and read it back to Java I would get -1, although it is really treated as `0xffffffffffffffff` by the writer/parser. But changing that behaviour would require changes in JFR and JMC as in both places the number of bytes comprising a long number is limited to 9. Regarding the usage - we are not using the writer in the JMC project yet. However, we are using it at Datadog to generate 'on-the-fly' recordings for tests where we can create really exotic combinations of events to make sure our backend can deal with them. ------------- PR: https://git.openjdk.org/jmc/pull/412 From hirt at openjdk.org Thu Oct 6 11:44:34 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 6 Oct 2022 11:44:34 GMT Subject: RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v2] In-Reply-To: <_IP_p9vGGq2Ur-cb-hpqDxz3vbaD5j0R6Oxo7JOzxVE=.f70b4918-69f0-40c4-926d-552e12710b52@github.com> References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> <1ggycSBbykLhhFJdcYPyD9MrrGBHxgN83TK2xxwph6s=.3273397d-af1f-4a0d-9549-729af6aa5763@github.com> <_IP_p9vGGq2Ur-cb-hpqDxz3vbaD5j0R6Oxo7JOzxVE=.f70b4918-69f0-40c4-926d-552e12710b52@github.com> Message-ID: On Thu, 6 Oct 2022 07:29:08 GMT, Jaroslav Bachorik wrote: >> I was being defensive here since this is a public API. >> But perhaps we can get away with a technically breaking change since our writer APIs are never accepting an instance of `RecordingSettings` but rather just providing it in a callback - that way we are still having the full control over the concrete instance being used. > > Let's see what @thegreystone has to say - I agree that in this case the default methods don't make much sense, on the other hand there is the thing about API evolution and added interface methods ... > So it is more of a question of the code hygiene here. I think it's friendly to not introduce compilation breaking changes for people using this. Especially in a minor version upgrade. ------------- PR: https://git.openjdk.org/jmc/pull/412 From hdafgard at openjdk.org Thu Oct 6 12:03:17 2022 From: hdafgard at openjdk.org (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Thu, 6 Oct 2022 12:03:17 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v3] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 09:38:57 GMT, Brice Dutheil wrote: >> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 108: >> >>> 106: Messages.getString(Messages.ClassLeakingRule_CONFIG_CALCULATION_TIMEOUT), >>> 107: Messages.getString(Messages.ClassLeakingRule_CONFIG_CALCULATION_TIMEOUT_LONG), NUMBER, >>> 108: NUMBER_UNITY.quantity(5)); >> >> Nit: The timeout value should be a timestamp instead. > > Why not `TIMESPAN`, `MINUTE.quantity(5)` ? ? Of course that's right, a timespan is the correct type here. ------------- PR: https://git.openjdk.org/jmc/pull/419 From hdafgard at openjdk.org Thu Oct 6 12:03:18 2022 From: hdafgard at openjdk.org (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Thu, 6 Oct 2022 12:03:18 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v3] In-Reply-To: References: Message-ID: <0wIGE6D2Q7uTNTpTDdltZRSipF6ogsXSvg1DLYYvykc=.bdab6c37-2c4c-4e26-aad9-7f4706c9aa43@github.com> On Wed, 5 Oct 2022 10:34:42 GMT, Suchita Chaturvedi wrote: >> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 156: >> >>> 154: IItemCollection items, IPreferenceValueProvider valueProvider, IResultValueProvider dependencyResults) { >>> 155: int warningLimit = (int) valueProvider.getPreferenceValue(WARNING_LIMIT).longValue(); >>> 156: CONFIGURED_TIMEOUT = (int) valueProvider.getPreferenceValue(MAX_TIMEOUT).longValue(); >> >> Nit: This preference should use .clampedLongValueIn and passing in the appropriate unit, so since the timeout use of this specifies TimeUnit.MINUTES we should use valueProvider.getPreferenceValue(MAX_TIMEOUT).clampedLongValueIn(UnitLookup.MINUTE).longValue(). > > If we use clampedLongValueIn then longValue() should be removed right? We can't use both together. Yes, sorry about that confusion. ------------- PR: https://git.openjdk.org/jmc/pull/419 From hdafgard at openjdk.org Thu Oct 6 13:46:36 2022 From: hdafgard at openjdk.org (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=) Date: Thu, 6 Oct 2022 13:46:36 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v3] In-Reply-To: References: Message-ID: On Thu, 6 Oct 2022 04:54:23 GMT, Suchita Chaturvedi wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Added check for default configured timeout core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/ClassLeakingRule.java line 108: > 106: "classLeaking.calculation.timeout", //$NON-NLS-1$ > 107: Messages.getString(Messages.ClassLeakingRule_CONFIG_CALCULATION_TIMEOUT), > 108: Messages.getString(Messages.ClassLeakingRule_CONFIG_CALCULATION_TIMEOUT_LONG), NUMBER, MINUTE.quantity(5)); Suggestion: Messages.getString(Messages.ClassLeakingRule_CONFIG_CALCULATION_TIMEOUT_LONG), TIMESPAN, MINUTE.quantity(5)); ------------- PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Thu Oct 6 16:37:18 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Thu, 6 Oct 2022 16:37:18 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v3] In-Reply-To: References: Message-ID: On Thu, 6 Oct 2022 04:54:23 GMT, Suchita Chaturvedi wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Added check for default configured timeout > @bric3 We need to show the names of top 5 classes which were loaded maximum times without being unloaded. So the ordering matters here. That's why I have skipped that comment. I'm a bit confused, as in `DefaultIItemResultSet` the _insertion_ in `data` order is dependent on the iteration order of the aggregate collection, since it's a set, there's no ordering guarantees. Although I lack knowledge of the actual type and the implementation is a `TreeSet` or something alike. https://github.com/openjdk/jmc/blob/1696e03a1fddb9cc68d32bf21a281ef24366e552/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java#L95-L99 Moreover the usage of the thread pool here will not guarantee the `add` operation will happen in the same order as the tasks have been submitted. Which leads me to think that the code should be reworked here to ensure that the results will be inserted in order. core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 138: > 136: exec.shutdownNow(); > 137: if (configuredTimeout != 0) > 138: exec.awaitTermination(configuredTimeout, TimeUnit.MINUTES); Sorry looking at this now I think the proposition (1) in [comment](https://github.com/openjdk/jmc/pull/419#discussion_r988313757) is incorrect * ~~a guard value like `-1` is better and in `DefaultIItemResultSet` just skip the termination.~~ If the value is `0` (or the `-1` which conveys to human this is an invalid value and a such disable the timeout) the code should just wait that all results have been delivered. Also maybe make this guard value a constant that can be reused in `ItemResultSetFactory`. Instead the other proposition, to have a very large termination timeout, might be more appropriate in the present case, JDK 19's `ExecutorService.close()` for example use a timeout of _1 day_. ------------- PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Thu Oct 6 19:18:26 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Thu, 6 Oct 2022 19:18:26 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v3] In-Reply-To: References: Message-ID: <0mioSkY_ti5RLq-M3K5DGfXwv4WbQKjpsiNmxei5spo=.35ddaaf5-1bce-4ea0-b4ec-01a8c4027264@github.com> On Wed, 5 Oct 2022 20:16:36 GMT, Brice Dutheil wrote: >> @Gunde @bric3 I have tried to implement all the review comments. Please re-review the PR and let me know if there is something which is still need to be corrected. > > @Suchitainf There's still these two comment to address in my opinion: > * https://github.com/openjdk/jmc/pull/419#discussion_r987769827 > * https://github.com/openjdk/jmc/pull/419#discussion_r988313757 > > Note I'm really unsure about the result ordering there, may be @thegreystone or @Gunde may chime in there to make sure this change is ok. > > @bric3 We need to show the names of top 5 classes which were loaded maximum times without being unloaded. So the ordering matters here. That's why I have skipped that comment. > > I'm a bit confused, as in `DefaultIItemResultSet` the _insertion_ in `data` order is dependent on the iteration order of the aggregate collection, since it's a set, there's no ordering guarantees. Although I lack knowledge of the actual type and the implementation is a `TreeSet` or something alike. > > https://github.com/openjdk/jmc/blob/1696e03a1fddb9cc68d32bf21a281ef24366e552/core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java#L95-L99 > > Moreover the usage of the thread pool here will not guarantee the `add` operation will happen in the same order as the tasks have been submitted. Which leads me to think that the code should be reworked here to ensure that the results will be inserted in order. I have used a synchronized block for data. After that I am getting consistent results. Without that I was getting different results every time. I mean when I was working for test JFR wldf.jfr without synchronized block on data, the top 5 results varied every time. ------------- PR: https://git.openjdk.org/jmc/pull/419 From schaturvedi at openjdk.org Thu Oct 6 20:28:14 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Thu, 6 Oct 2022 20:28:14 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v4] In-Reply-To: References: Message-ID: > This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Adding higher timeout as default value ------------- Changes: - all: https://git.openjdk.org/jmc/pull/419/files - new: https://git.openjdk.org/jmc/pull/419/files/026795d6..9876fd12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=03 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=02-03 Stats: 6 lines in 3 files changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jmc/pull/419.diff Fetch: git fetch https://git.openjdk.org/jmc pull/419/head:pull/419 PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Fri Oct 7 07:32:13 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 7 Oct 2022 07:32:13 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v4] In-Reply-To: <0mioSkY_ti5RLq-M3K5DGfXwv4WbQKjpsiNmxei5spo=.35ddaaf5-1bce-4ea0-b4ec-01a8c4027264@github.com> References: <0mioSkY_ti5RLq-M3K5DGfXwv4WbQKjpsiNmxei5spo=.35ddaaf5-1bce-4ea0-b4ec-01a8c4027264@github.com> Message-ID: On Thu, 6 Oct 2022 19:14:45 GMT, Suchita Chaturvedi wrote: > I have used a synchronized block for data. After that I am getting consistent results. Without that I was getting different results every time. I mean when I was working for test JFR wldf.jfr without synchronized block on data, the top 5 results varied every time. Have you tried with an intermediate `ConcurrentLinkedQueue`, then copy the results in the data array list ? ------------- PR: https://git.openjdk.org/jmc/pull/419 From bdutheil at openjdk.org Fri Oct 7 07:59:31 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 7 Oct 2022 07:59:31 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v4] In-Reply-To: References: Message-ID: <4f4NQhWbUC7wj4xLiqX5ozEm3-W6Ueq4ywD0a31jc0k=.e889c8d8-a75e-40fc-be8f-46f6c205048f@github.com> On Wed, 28 Sep 2022 21:46:39 GMT, Henrik Dafg?rd wrote: >> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding higher timeout as default value > > core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 108: > >> 106: Set aggregate = input.getAggregate((IAggregator, ?>) aggregator); >> 107: if (aggregate != null) { >> 108: ExecutorService exec = Executors.newWorkStealingPool(); > > We might want to set a target level parallelism here? Or have an executor service initialized on class load instead of at each invocation of the method? We might also not want a work stealing pool here then. I just had the same realization today. And somewhat stumbled on your comment. I'm not sure if the rules using this `DefaultIITemResultSet`, are used in backend servers at this time, but if they are the creation of an executor here (each time this rule is run) is likely inappropriate. It might be worth to investigate how to make this work by passing an executor instance to `DefaultIITemResultSet`, and work the timeout with futures ? ------------- PR: https://git.openjdk.org/jmc/pull/419 From clanger at openjdk.org Mon Oct 10 21:28:57 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 10 Oct 2022 21:28:57 GMT Subject: RFR: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks [v3] In-Reply-To: References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> Message-ID: On Thu, 6 Oct 2022 08:28:28 GMT, Jaroslav Bachorik wrote: >> Currently, the JFR recordings created by the JMC writer will have the start ticks set to the same value as the start timestamp. This will cause problems with the duration calculation which is using directly `System.nanoTime()` and as such the resulting value will be rather nonsensical. >> >> This PR adds two new recording settings - `startTicks` and `duration` which can be used to write a JFR recording with correct values set. If the user does not set those settings `startTicks` will be set to the value of `System.nanoTime()` at the moment the recording is started (a `Recording` instance is created) and `duration` will be computed as a diff between the current value of `System.nanoTime()` and `startTicks`. > > Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision: > > - Outstanding 'duration' fixes and cleanup > - Update and formalize new jfr.writer dependencies Looks good to me now. Thanks for working in my review comments. ------------- Marked as reviewed by clanger (Committer). PR: https://git.openjdk.org/jmc/pull/412 From clanger at openjdk.org Mon Oct 10 21:33:58 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 10 Oct 2022 21:33:58 GMT Subject: RFR: 7350: [Accessibility, JAWS] Deadlinks in Help Page In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:35:15 GMT, Suchita Chaturvedi wrote: > This link is present in all the help pages and everywhere its just a dead link. As per the code, it navigates to the begin of the page which is already displayed and no extra navigation is required for the same. I can't find a logical purpose this link serves. Hence, this PR removes this link from all pages. > /integrate @Suchitainf you will need to change the PR title to the JBS title ("[Accessibility, JAWS] [Misc] Deadlinks in Help Page"), then the PR will likely become ready. ------------- PR: https://git.openjdk.org/jmc/pull/430 From hirt at openjdk.org Tue Oct 11 00:36:13 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 11 Oct 2022 00:36:13 GMT Subject: RFR: 7921: Create 8.3 release notes Message-ID: The fixed issue count my get higher in the end, but I think that's ok. ------------- Commit messages: - 7921: Create 8.3 release notes Changes: https://git.openjdk.org/jmc/pull/437/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=437&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7921 Stats: 179 lines in 18 files changed: 176 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jmc/pull/437.diff Fetch: git fetch https://git.openjdk.org/jmc pull/437/head:pull/437 PR: https://git.openjdk.org/jmc/pull/437 From hirt at openjdk.org Tue Oct 11 00:54:25 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 11 Oct 2022 00:54:25 GMT Subject: RFR: 7923: Cleanup warnings in core Message-ID: Cleanup to reduce the warning noise a bit. ------------- Commit messages: - 7923: Cleanup warnings in core Changes: https://git.openjdk.org/jmc/pull/438/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=438&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7923 Stats: 46 lines in 26 files changed: 28 ins; 17 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/438.diff Fetch: git fetch https://git.openjdk.org/jmc pull/438/head:pull/438 PR: https://git.openjdk.org/jmc/pull/438 From hirt at openjdk.org Tue Oct 11 01:00:37 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 11 Oct 2022 01:00:37 GMT Subject: RFR: 7921: Create 8.3 release notes [v2] In-Reply-To: References: Message-ID: > The fixed issue count my get higher in the end, but I think that's ok. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Image fix ------------- Changes: - all: https://git.openjdk.org/jmc/pull/437/files - new: https://git.openjdk.org/jmc/pull/437/files/4934cb24..7745a292 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=437&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=437&range=00-01 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/437.diff Fetch: git fetch https://git.openjdk.org/jmc pull/437/head:pull/437 PR: https://git.openjdk.org/jmc/pull/437 From hirt at openjdk.org Tue Oct 11 01:03:06 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 11 Oct 2022 01:03:06 GMT Subject: RFR: 7921: Create 8.3 release notes [v3] In-Reply-To: References: Message-ID: <2NrsHwAnh2ZyynXlea2yD9xk2h1SbsK4J7cN4Jg8r4k=.2a08593d-0f68-4e2b-8996-665b78497d1e@github.com> > The fixed issue count my get higher in the end, but I think that's ok. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Removing superflous image ------------- Changes: - all: https://git.openjdk.org/jmc/pull/437/files - new: https://git.openjdk.org/jmc/pull/437/files/7745a292..35646349 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=437&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=437&range=01-02 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/437.diff Fetch: git fetch https://git.openjdk.org/jmc pull/437/head:pull/437 PR: https://git.openjdk.org/jmc/pull/437 From jpbempel at openjdk.org Tue Oct 11 07:08:01 2022 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 11 Oct 2022 07:08:01 GMT Subject: RFR: 7922: Issue using attribute selections in the stack trace view Message-ID: Remove check on setting the model ------------- Commit messages: - 7922: Issue using attribute selections in the stack trace view Changes: https://git.openjdk.org/jmc/pull/439/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=439&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7922 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jmc/pull/439.diff Fetch: git fetch https://git.openjdk.org/jmc pull/439/head:pull/439 PR: https://git.openjdk.org/jmc/pull/439 From schaturvedi at openjdk.org Tue Oct 11 07:49:02 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Tue, 11 Oct 2022 07:49:02 GMT Subject: RFR: 7350: [Accessibility, JAWS] [Misc] Deadlinks in Help Page In-Reply-To: References: Message-ID: On Mon, 10 Oct 2022 21:30:08 GMT, Christoph Langer wrote: > > /integrate > > @Suchitainf you will need to change the PR title to the JBS title ("[Accessibility, JAWS] [Misc] Deadlinks in Help Page"), then the PR will likely become ready. Thanks for the pointer. Actually the JBS summary got changed after the PR was raised. Hence, there was a discrepancy. I have updated now. ------------- PR: https://git.openjdk.org/jmc/pull/430 From jbachorik at openjdk.org Tue Oct 11 08:17:34 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 11 Oct 2022 08:17:34 GMT Subject: Integrated: 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks In-Reply-To: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> References: <-0SXAK6-q6u7WKMe7H7u9hpjV7qsrnCyxhlVGOVdKPM=.7af628b0-7f3d-43a9-8a67-af7eeeeb01db@github.com> Message-ID: On Thu, 14 Jul 2022 18:44:14 GMT, Jaroslav Bachorik wrote: > Currently, the JFR recordings created by the JMC writer will have the start ticks set to the same value as the start timestamp. This will cause problems with the duration calculation which is using directly `System.nanoTime()` and as such the resulting value will be rather nonsensical. > > This PR adds two new recording settings - `startTicks` and `duration` which can be used to write a JFR recording with correct values set. If the user does not set those settings `startTicks` will be set to the value of `System.nanoTime()` at the moment the recording is started (a `Recording` instance is created) and `duration` will be computed as a diff between the current value of `System.nanoTime()` and `startTicks`. This pull request has now been integrated. Changeset: b1494d2c Author: Jaroslav Bachorik Committer: Christoph Langer URL: https://git.openjdk.org/jmc/commit/b1494d2cd81a5225e8bd79a55c507ef577476c38 Stats: 1202 lines in 15 files changed: 1187 ins; 0 del; 15 mod 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks Reviewed-by: clanger ------------- PR: https://git.openjdk.org/jmc/pull/412 From clanger at openjdk.org Tue Oct 11 08:17:35 2022 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 11 Oct 2022 08:17:35 GMT Subject: RFR: 7350: [Accessibility, JAWS] [Misc] Deadlinks in Help Page In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 07:47:02 GMT, Suchita Chaturvedi wrote: > > > /integrate > > > > > > @Suchitainf you will need to change the PR title to the JBS title ("[Accessibility, JAWS] [Misc] Deadlinks in Help Page"), then the PR will likely become ready. > > Thanks for the pointer. Actually the JBS summary got changed after the PR was raised. Hence, there was a discrepancy. I have updated now. Great, looks like you can integrate now. ------------- PR: https://git.openjdk.org/jmc/pull/430 From schaturvedi at openjdk.org Tue Oct 11 08:20:20 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Tue, 11 Oct 2022 08:20:20 GMT Subject: Integrated: 7350: [Accessibility, JAWS] [Misc] Deadlinks in Help Page In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:35:15 GMT, Suchita Chaturvedi wrote: > This link is present in all the help pages and everywhere its just a dead link. As per the code, it navigates to the begin of the page which is already displayed and no extra navigation is required for the same. I can't find a logical purpose this link serves. Hence, this PR removes this link from all pages. This pull request has now been integrated. Changeset: e3f4c5bd Author: Suchita Chaturvedi URL: https://git.openjdk.org/jmc/commit/e3f4c5bde20730a4e1aecffe263ac185463cd444 Stats: 79 lines in 79 files changed: 0 ins; 79 del; 0 mod 7350: [Accessibility, JAWS] [Misc] Deadlinks in Help Page Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/430 From jpbempel at openjdk.org Tue Oct 11 08:47:30 2022 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 11 Oct 2022 08:47:30 GMT Subject: RFR: 7921: Create 8.3 release notes [v3] In-Reply-To: <2NrsHwAnh2ZyynXlea2yD9xk2h1SbsK4J7cN4Jg8r4k=.2a08593d-0f68-4e2b-8996-665b78497d1e@github.com> References: <2NrsHwAnh2ZyynXlea2yD9xk2h1SbsK4J7cN4Jg8r4k=.2a08593d-0f68-4e2b-8996-665b78497d1e@github.com> Message-ID: <6Sg54O-Eart7BM6hMkl7HtO4gcjdM33BcL1Yld5iW64=.bb01f0d6-72ae-41bb-858f-00118136c2f5@github.com> On Tue, 11 Oct 2022 01:03:06 GMT, Marcus Hirt wrote: >> The fixed issue count my get higher in the end, but I think that's ok. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Removing superflous image Marked as reviewed by jpbempel (Committer). ------------- PR: https://git.openjdk.org/jmc/pull/437 From jpbempel at openjdk.org Tue Oct 11 08:47:52 2022 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 11 Oct 2022 08:47:52 GMT Subject: RFR: 7923: Cleanup warnings in core In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 00:44:56 GMT, Marcus Hirt wrote: > Cleanup to reduce the warning noise a bit. Marked as reviewed by jpbempel (Committer). ------------- PR: https://git.openjdk.org/jmc/pull/438 From clanger at openjdk.org Tue Oct 11 08:53:37 2022 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 11 Oct 2022 08:53:37 GMT Subject: RFR: 7921: Create 8.3 release notes [v3] In-Reply-To: <2NrsHwAnh2ZyynXlea2yD9xk2h1SbsK4J7cN4Jg8r4k=.2a08593d-0f68-4e2b-8996-665b78497d1e@github.com> References: <2NrsHwAnh2ZyynXlea2yD9xk2h1SbsK4J7cN4Jg8r4k=.2a08593d-0f68-4e2b-8996-665b78497d1e@github.com> Message-ID: <1mgLeHHNe4wYN3qS8FvKTf2f75T5T8ot-Gm8lI1Hy-Q=.ad5cf031-b6f1-4704-bfab-912baced4e58@github.com> On Tue, 11 Oct 2022 01:03:06 GMT, Marcus Hirt wrote: >> The fixed issue count my get higher in the end, but I think that's ok. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Removing superflous image Marked as reviewed by clanger (Committer). ------------- PR: https://git.openjdk.org/jmc/pull/437 From clanger at openjdk.org Tue Oct 11 08:53:38 2022 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 11 Oct 2022 08:53:38 GMT Subject: RFR: 7923: Cleanup warnings in core In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 00:44:56 GMT, Marcus Hirt wrote: > Cleanup to reduce the warning noise a bit. Marked as reviewed by clanger (Committer). ------------- PR: https://git.openjdk.org/jmc/pull/438 From bdutheil at openjdk.org Tue Oct 11 12:43:33 2022 From: bdutheil at openjdk.org (Brice Dutheil) Date: Tue, 11 Oct 2022 12:43:33 GMT Subject: RFR: 7921: Create 8.3 release notes [v3] In-Reply-To: <2NrsHwAnh2ZyynXlea2yD9xk2h1SbsK4J7cN4Jg8r4k=.2a08593d-0f68-4e2b-8996-665b78497d1e@github.com> References: <2NrsHwAnh2ZyynXlea2yD9xk2h1SbsK4J7cN4Jg8r4k=.2a08593d-0f68-4e2b-8996-665b78497d1e@github.com> Message-ID: On Tue, 11 Oct 2022 01:03:06 GMT, Marcus Hirt wrote: >> The fixed issue count my get higher in the end, but I think that's ok. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Removing superflous image Marked as reviewed by bdutheil (Author). ------------- PR: https://git.openjdk.org/jmc/pull/437 From hirt at openjdk.org Tue Oct 11 13:27:43 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 11 Oct 2022 13:27:43 GMT Subject: RFR: 7922: Issue using attribute selections in the stack trace view In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 07:00:50 GMT, Jean-Philippe Bempel wrote: > Remove check on setting the model Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.org/jmc/pull/439 From hirt at openjdk.org Tue Oct 11 13:43:29 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 11 Oct 2022 13:43:29 GMT Subject: Integrated: 7923: Cleanup warnings in core In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 00:44:56 GMT, Marcus Hirt wrote: > Cleanup to reduce the warning noise a bit. This pull request has now been integrated. Changeset: 33c4872d Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/33c4872dd4f4fa2816d99533ac187ee78b117eb7 Stats: 46 lines in 26 files changed: 28 ins; 17 del; 1 mod 7923: Cleanup warnings in core Reviewed-by: jpbempel, clanger ------------- PR: https://git.openjdk.org/jmc/pull/438 From jpbempel at openjdk.org Tue Oct 11 13:43:35 2022 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 11 Oct 2022 13:43:35 GMT Subject: Integrated: 7922: Issue using attribute selections in the stack trace view In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 07:00:50 GMT, Jean-Philippe Bempel wrote: > Remove check on setting the model This pull request has now been integrated. Changeset: 095d0687 Author: Jean-Philippe Bempel URL: https://git.openjdk.org/jmc/commit/095d0687156be8eb3c0cfd7738ea44de6a2b0c55 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod 7922: Issue using attribute selections in the stack trace view Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/439 From hirt at openjdk.org Tue Oct 11 13:43:36 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 11 Oct 2022 13:43:36 GMT Subject: Integrated: 7921: Create 8.3 release notes In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 00:27:30 GMT, Marcus Hirt wrote: > The fixed issue count my get higher in the end, but I think that's ok. This pull request has now been integrated. Changeset: a359db89 Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/a359db89a72abc888a1f8721d1c81c3e781bd003 Stats: 179 lines in 17 files changed: 176 ins; 0 del; 3 mod 7921: Create 8.3 release notes Reviewed-by: jpbempel, clanger, bdutheil ------------- PR: https://git.openjdk.org/jmc/pull/437 From hirt at openjdk.org Wed Oct 12 19:52:32 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 12 Oct 2022 19:52:32 GMT Subject: RFR: 7928: Merge master into jmc8 in preparation for the 8.3 release Message-ID: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> Prepping for release. ------------- Commit messages: - Merge branch 'master' into jmc8 in preparation for the 8.3 release. - 7922: Issue using attribute selections in the stack trace view - 7923: Cleanup warnings in core - 7921: Create 8.3 release notes - 7350: [Accessibility, JAWS] [Misc] Deadlinks in Help Page - 7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks - 7902: UseCompressedOopsRule has flipped comparison - 7910: Fix spotless finding after JMC-7903 - 7903: FastAccessNumberMap is slow for sparse values - 7813: Unable to open Help page in macOS M1 when JMC started with JDK11 - ... and 39 more: https://git.openjdk.org/jmc/compare/ed260098...cb24f0a8 Changes: https://git.openjdk.org/jmc/pull/440/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=440&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7928 Stats: 12995 lines in 601 files changed: 10235 ins; 1317 del; 1443 mod Patch: https://git.openjdk.org/jmc/pull/440.diff Fetch: git fetch https://git.openjdk.org/jmc pull/440/head:pull/440 PR: https://git.openjdk.org/jmc/pull/440 From aptmac at openjdk.org Thu Oct 13 02:35:11 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 13 Oct 2022 02:35:11 GMT Subject: RFR: Merge jmc:master In-Reply-To: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> References: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> Message-ID: On Wed, 12 Oct 2022 19:47:14 GMT, Marcus Hirt wrote: > Prepping for release. Marked as reviewed by aptmac (Reviewer). ------------- PR: https://git.openjdk.org/jmc/pull/440 From duke at openjdk.org Thu Oct 13 04:12:12 2022 From: duke at openjdk.org (Virag Purnam) Date: Thu, 13 Oct 2022 04:12:12 GMT Subject: RFR: Merge jmc:master In-Reply-To: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> References: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> Message-ID: On Wed, 12 Oct 2022 19:47:14 GMT, Marcus Hirt wrote: > Prepping for release. Looks good. ------------- PR: https://git.openjdk.org/jmc/pull/440 From clanger at openjdk.org Thu Oct 13 05:54:14 2022 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 13 Oct 2022 05:54:14 GMT Subject: RFR: Merge jmc:master In-Reply-To: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> References: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> Message-ID: On Wed, 12 Oct 2022 19:47:14 GMT, Marcus Hirt wrote: > Prepping for release. Marked as reviewed by clanger (Committer). ------------- PR: https://git.openjdk.org/jmc/pull/440 From hirt at openjdk.org Thu Oct 13 12:53:01 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 13 Oct 2022 12:53:01 GMT Subject: RFR: Merge jmc:master [v2] In-Reply-To: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> References: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> Message-ID: > Prepping for release. Marcus Hirt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge branch 'master' into jmc8 in preparation for the 8.3 release. - 7877: Update the jmc version in jmc8 branch to 8.2.1 Reviewed-by: aptmac, clanger - 7381: Better descriptions for reports - 7443: Wrong version in THIRDPARTYREADME Reviewed-by: hirt - 7569: Improve the implementation of Twitter plugin Reviewed-by: hirt - 7561: Update to the release splash screen for JMC 8.2 Reviewed-by: hdafgard - Merge branch 'master' into jmc8 - 7436: Update version to 8.1.1 in the jmc8 branch Reviewed-by: hdafgard - 7231: JMC createReport for JMC8 Automated Analysis fails to evaluate several rules Reviewed-by: hirt, hdafgard - 7419: Update XML parsing Reviewed-by: hirt - ... and 19 more: https://git.openjdk.org/jmc/compare/095d0687...cb24f0a8 ------------- Changes: https://git.openjdk.org/jmc/pull/440/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=440&range=01 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/440.diff Fetch: git fetch https://git.openjdk.org/jmc pull/440/head:pull/440 PR: https://git.openjdk.org/jmc/pull/440 From hirt at openjdk.org Thu Oct 13 12:53:03 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 13 Oct 2022 12:53:03 GMT Subject: Integrated: Merge jmc:master In-Reply-To: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> References: <16dCKEC_bsaBtG049keHG-G1UPZQp3p0JLxtw49xUNU=.d3de1dde-fdee-48b8-b789-80ecc9fc886c@github.com> Message-ID: On Wed, 12 Oct 2022 19:47:14 GMT, Marcus Hirt wrote: > Prepping for release. This pull request has now been integrated. Changeset: 90375e32 Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/90375e32f36d0f1743de877ae14e239b84fa6372 Stats: 12995 lines in 601 files changed: 10235 ins; 1317 del; 1443 mod Merge Reviewed-by: aptmac, clanger ------------- PR: https://git.openjdk.org/jmc/pull/440 From hirt at openjdk.org Thu Oct 13 16:02:29 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 13 Oct 2022 16:02:29 GMT Subject: RFR: 7929: Add release splash for 8.3 Message-ID: What it says. ------------- Commit messages: - 7929: Add release splash for 8.3 - Merge branch 'master' into jmc8 in preparation for the 8.3 release. - 7877: Update the jmc version in jmc8 branch to 8.2.1 - 7381: Better descriptions for reports - 7443: Wrong version in THIRDPARTYREADME - 7569: Improve the implementation of Twitter plugin - 7561: Update to the release splash screen for JMC 8.2 - Merge branch 'master' into jmc8 - 7436: Update version to 8.1.1 in the jmc8 branch - 7231: JMC createReport for JMC8 Automated Analysis fails to evaluate several rules - ... and 20 more: https://git.openjdk.org/jmc/compare/095d0687...70c4c3f9 Changes: https://git.openjdk.org/jmc/pull/441/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=441&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7929 Stats: 23 lines in 2 files changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/441.diff Fetch: git fetch https://git.openjdk.org/jmc pull/441/head:pull/441 PR: https://git.openjdk.org/jmc/pull/441 From aptmac at openjdk.org Thu Oct 13 18:06:59 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 13 Oct 2022 18:06:59 GMT Subject: RFR: 7929: Add release splash for 8.3 In-Reply-To: References: Message-ID: On Thu, 13 Oct 2022 15:32:10 GMT, Marcus Hirt wrote: > What it says. Marked as reviewed by aptmac (Reviewer). application/tests/org.openjdk.jmc.flightrecorder.flameview.test/META-INF/MANIFEST.MF line 2: > 1: Manifest-Version: 1.0 > 2: Bundle-Version: 8.0.1.qualifier 8.3.0? ------------- PR: https://git.openjdk.org/jmc/pull/441 From hirt at openjdk.org Thu Oct 13 18:07:00 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 13 Oct 2022 18:07:00 GMT Subject: RFR: 7929: Add release splash for 8.3 In-Reply-To: References: Message-ID: On Thu, 13 Oct 2022 15:32:10 GMT, Marcus Hirt wrote: > What it says. Better. :) ------------- PR: https://git.openjdk.org/jmc/pull/441 From hirt at openjdk.org Thu Oct 13 18:07:00 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 13 Oct 2022 18:07:00 GMT Subject: RFR: 7929: Add release splash for 8.3 In-Reply-To: References: Message-ID: On Thu, 13 Oct 2022 17:47:36 GMT, Alex Macdonald wrote: >> What it says. > > application/tests/org.openjdk.jmc.flightrecorder.flameview.test/META-INF/MANIFEST.MF line 2: > >> 1: Manifest-Version: 1.0 >> 2: Bundle-Version: 8.0.1.qualifier > > 8.3.0? Weird that this change is here in the first place. Will take a look. ------------- PR: https://git.openjdk.org/jmc/pull/441 From hirt at openjdk.org Thu Oct 13 18:16:44 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 13 Oct 2022 18:16:44 GMT Subject: RFR: 7929: Add release splash for 8.3 [v2] In-Reply-To: References: Message-ID: > What it says. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Delete MANIFEST.MF Shouldn't be here. ------------- Changes: - all: https://git.openjdk.org/jmc/pull/441/files - new: https://git.openjdk.org/jmc/pull/441/files/70c4c3f9..8c5aa11c Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=441&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=441&range=00-01 Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/441.diff Fetch: git fetch https://git.openjdk.org/jmc pull/441/head:pull/441 PR: https://git.openjdk.org/jmc/pull/441 From hirt at openjdk.org Thu Oct 13 18:27:00 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 13 Oct 2022 18:27:00 GMT Subject: Integrated: 7929: Add release splash for 8.3 In-Reply-To: References: Message-ID: On Thu, 13 Oct 2022 15:32:10 GMT, Marcus Hirt wrote: > What it says. This pull request has now been integrated. Changeset: 7097ed26 Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/7097ed26ab4d04a691544aaf02f0ca12dc2db947 Stats: 23 lines in 2 files changed: 0 ins; 23 del; 0 mod 7929: Add release splash for 8.3 Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/441 From duke at openjdk.org Sun Oct 16 02:50:32 2022 From: duke at openjdk.org (duke) Date: Sun, 16 Oct 2022 02:50:32 GMT Subject: git: openjdk/jmc: Added tag 8.3.0-rc for changeset 7097ed26 Message-ID: <7ef6e800-b3e4-45d0-a31e-d8c7bb463f61@openjdk.org> Tagged by: thegreystone Date: 2022-10-15 19:45:47 +0000 Release candidate for JMC 8.3.0 Changeset: 7097ed26 Author: Marcus Hirt Date: 2022-10-13 18:18:43 +0000 URL: https://git.openjdk.org/jmc/commit/7097ed26ab4d04a691544aaf02f0ca12dc2db947 From marcus.hirt at datadoghq.com Sun Oct 16 02:52:34 2022 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Sat, 15 Oct 2022 19:52:34 -0700 Subject: JMC 8.3.0 rc tag set. Message-ID: Hi all (especially vendors), I've now set the JMC 8.3.0 release candidate tag: https://github.com/openjdk/jmc/releases/tag/8.3.0-rc Please let me know if any problems are found in your testing. Kind regards, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Oct 18 11:39:05 2022 From: duke at openjdk.org (Ashley) Date: Tue, 18 Oct 2022 11:39:05 GMT Subject: RFR: 7056: Fix dark mode In-Reply-To: <_P56NvgPUBJ_PH40VUL5Vw3-SGlGTqu6BWkl-Z_4j00=.6e67b969-4b35-4a33-b608-c989d75f6bc9@github.com> References: <_P56NvgPUBJ_PH40VUL5Vw3-SGlGTqu6BWkl-Z_4j00=.6e67b969-4b35-4a33-b608-c989d75f6bc9@github.com> Message-ID: <7juYgl29xrmvbh5QrjvnqMVGutdcO0ArdcKpwClzzPo=.33089c62-9d36-4de6-bb4b-f6038201c86c@github.com> On Sun, 16 Jan 2022 15:32:33 GMT, Brice Dutheil wrote: > This change allows a user of the JMC RCP application to switch the appearance with the default Eclipse themes. > > Those are shipped via the `org.eclipse.ui.themes` and `org.eclipse.e4.ui.css.swt.theme` plugin. > In order to activate them all that is is required is to add the above in the application feature file, and to declare them in the application manifest file. > > > > **After** > ![Screenshot 2022-01-16 at 16 23 46](https://user-images.githubusercontent.com/803621/149666554-3016effc-b527-4dd7-aa6b-baa07a9569ad.png) > ![Screenshot 2022-01-16 at 16 26 21](https://user-images.githubusercontent.com/803621/149666560-cab76fc9-dd9a-4977-9fe7-0a7dc99335c5.png) > > > > **Before** > ![Screenshot 2022-01-16 at 16 24 45](https://user-images.githubusercontent.com/803621/149666542-b8e22717-a797-44b6-9805-30b9c14fb9fa.png) > There's no theme, as such the combo box doesn't open either. Looks like a temporary workaround for this is to (at least for GTK) set the `GTK_THEME` environment variable before starting jmc. GTK_THEME="Adwaita:light" jmc & GTK_THEME="Adwaita:dark" jmc & ![image](https://user-images.githubusercontent.com/73482956/196418680-764f48de-046e-4fc5-99d4-fb68718bab79.png) ------------- PR: https://git.openjdk.org/jmc/pull/362 From hirt at openjdk.org Tue Oct 18 23:14:24 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 18 Oct 2022 23:14:24 GMT Subject: RFR: 7930: Upgrade to Eclipse 2022-09 Message-ID: <5yxqK0pKh5DfScIrw1ugNNVBvRFaeQX09lTPXoLF27E=.09cf9798-bb9b-4532-86e5-e660d2e49954@github.com> Upgrading to Eclipse 2022 proved a little bit more complicated that previous upgrades. See https://github.com/eclipse-platform/eclipse.platform.common/blob/master/bundles/org.eclipse.platform.doc.isv/porting/4.25/incompatibilities.html. ------------- Commit messages: - Moving to JUnit 4 just to keep things easy - Fixing some problems due to the new platform - 7930: Upgrade to Eclipse 2022-09 Changes: https://git.openjdk.org/jmc/pull/442/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=442&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7930 Stats: 111 lines in 17 files changed: 43 ins; 37 del; 31 mod Patch: https://git.openjdk.org/jmc/pull/442.diff Fetch: git fetch https://git.openjdk.org/jmc pull/442/head:pull/442 PR: https://git.openjdk.org/jmc/pull/442 From duke at openjdk.org Wed Oct 19 08:16:58 2022 From: duke at openjdk.org (Virag Purnam) Date: Wed, 19 Oct 2022 08:16:58 GMT Subject: RFR: 7930: Upgrade to Eclipse 2022-09 In-Reply-To: <5yxqK0pKh5DfScIrw1ugNNVBvRFaeQX09lTPXoLF27E=.09cf9798-bb9b-4532-86e5-e660d2e49954@github.com> References: <5yxqK0pKh5DfScIrw1ugNNVBvRFaeQX09lTPXoLF27E=.09cf9798-bb9b-4532-86e5-e660d2e49954@github.com> Message-ID: On Tue, 18 Oct 2022 23:08:27 GMT, Marcus Hirt wrote: > Upgrading to Eclipse 2022 proved a little bit more complicated that previous upgrades. See https://github.com/eclipse-platform/eclipse.platform.common/blob/master/bundles/org.eclipse.platform.doc.isv/porting/4.25/incompatibilities.html. Looks good ------------- PR: https://git.openjdk.org/jmc/pull/442 From duke at openjdk.org Wed Oct 19 16:08:05 2022 From: duke at openjdk.org (Christoph Dreis) Date: Wed, 19 Oct 2022 16:08:05 GMT Subject: RFR: 7933: Avoid volatile writes for default field values Message-ID: Hi, this PR avoids some volatile writes similar to https://bugs.openjdk.org/browse/JMC-7414. Since I can't create JIRA issues, I hope you can create this for me. Let me know if I can help in any other way, though. It has been a while since I contributed to JMC Cheers, Christoph ------------- Commit messages: - Avoid volatile writes for default field values Changes: https://git.openjdk.org/jmc/pull/435/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=435&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7933 Stats: 18 lines in 16 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jmc/pull/435.diff Fetch: git fetch https://git.openjdk.org/jmc pull/435/head:pull/435 PR: https://git.openjdk.org/jmc/pull/435 From hirt at openjdk.org Wed Oct 19 17:03:15 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 19 Oct 2022 17:03:15 GMT Subject: RFR: 7933: Avoid volatile writes for default field values In-Reply-To: References: Message-ID: On Sat, 1 Oct 2022 10:47:21 GMT, Christoph Dreis wrote: > Hi, > > this PR avoids some volatile writes similar to https://bugs.openjdk.org/browse/JMC-7414. > > Since I can't create JIRA issues, I hope you can create this for me. Let me know if I can help in any other way, though. It has been a while since I contributed to JMC > > Cheers, > Christoph Changes requested by hirt (Lead). agent/src/main/java/org/openjdk/jmc/agent/impl/DefaultTransformRegistry.java line 95: > 93: private final HashMap> transformData = new HashMap<>(); > 94: > 95: private volatile boolean revertInstrumentation; Please don't forget to update the copyright year. application/org.openjdk.jmc.console.jconsole/src/main/java/org/openjdk/jmc/console/jconsole/tabs/JConsolePluginTabbedPane.java line 72: > 70: private final List plugins = new ArrayList<>(); > 71: private final Map> swingWorkers = new HashMap<>(); > 72: private volatile boolean disposeTimerTask; Please don't forget to update the copyright year. application/org.openjdk.jmc.greychart/src/main/java/org/openjdk/jmc/greychart/providers/AveragingProvider.java line 65: > 63: private long m_requestedStartX = Long.MIN_VALUE; > 64: private long m_requestedEndX = Long.MAX_VALUE; > 65: private volatile boolean dataChangeOccured; Please don't forget to update the copyright year. application/org.openjdk.jmc.greychart/src/main/java/org/openjdk/jmc/greychart/providers/IntermediateStackingProvider.java line 65: > 63: > 64: private int m_lastSubSampleWidth = -1; > 65: private volatile boolean dataChangeOccured; Please don't forget to update the copyright year. application/org.openjdk.jmc.greychart/src/main/java/org/openjdk/jmc/greychart/providers/SampleCountingProvider.java line 69: > 67: private long m_requestedEndX = Long.MAX_VALUE; > 68: > 69: private volatile boolean dataChangeOccured; Please don't forget to update the copyright year. application/org.openjdk.jmc.greychart/src/main/java/org/openjdk/jmc/greychart/providers/SubsamplingProvider.java line 71: > 69: private long m_requestedStartX = Long.MIN_VALUE; > 70: private long m_requestedEndX = Long.MAX_VALUE; > 71: private volatile boolean dataChangeOccured; Please don't forget to update the copyright year. application/org.openjdk.jmc.joverflow/src/main/java/org/openjdk/jmc/joverflow/util/NumberToObjectMap.java line 54: > 52: protected int firstElementIdx, prevAddedElementIdx; > 53: > 54: private volatile Collection valuesCollectionView; Please don't forget to update the copyright year. application/org.openjdk.jmc.joverflow/src/main/java/org/openjdk/jmc/joverflow/util/ValueWitIntIdMap.java line 58: > 56: private int size, capacity, threshold; > 57: > 58: volatile Collection valuesCollectionView; Please don't forget to update the copyright year. application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/subscription/internal/DefaultAttributeSubscriptionThread.java line 90: > 88: private boolean sendNulls; > 89: > 90: private volatile boolean collectDebugInfo; Please don't forget to update the copyright year. application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/subscription/internal/DefaultNotificationSubscriptionManager.java line 74: > 72: private final MBeanServerConnection mbeanServer; > 73: > 74: private volatile boolean collectDebugInfo; Please don't forget to update the copyright year. application/org.openjdk.jmc.ui.common/src/main/java/org/openjdk/jmc/ui/common/util/FilterMatcher.java line 55: > 53: private final static FilterMatcher instance = new FilterMatcher(); > 54: > 55: private static volatile Pattern lastPattern; Please don't forget to update the copyright year. application/org.openjdk.jmc.ui/src/main/java/org/openjdk/jmc/ui/polling/PollManager.java line 56: > 54: private final Vector m_pollableObjects = new Vector<>(); > 55: volatile private int m_pollingInterval; > 56: volatile private boolean m_keepAlive; Please don't forget to update the copyright year. application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/synthetic/SyntheticNotificationTest.java line 63: > 61: private IConnectionHandle handle; > 62: private MBeanServerConnection connection; > 63: private volatile boolean gotNotification; Please don't forget to update the copyright year. core/org.openjdk.jmc.flightrecorder.writer/src/main/java/org/openjdk/jmc/flightrecorder/writer/MetadataImpl.java line 77: > 75: private final Set unresolvedTypes = new CopyOnWriteArraySet<>(); > 76: > 77: private volatile TypesImpl types; Please don't forget to update the copyright year. core/tests/org.openjdk.jmc.common.test/src/main/java/org/openjdk/jmc/common/util/BoundedListTest.java line 51: > 49: private static class ProducerThread implements Runnable { > 50: private final BoundedList list; > 51: private volatile boolean shouldStop; Please don't forget to update the copyright year. ------------- PR: https://git.openjdk.org/jmc/pull/435 From hirt at openjdk.org Wed Oct 19 17:09:09 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 19 Oct 2022 17:09:09 GMT Subject: RFR: 7894: Provide an alternative Java based flamegraph visualization In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 14:40:51 GMT, Brice Dutheil wrote: >> Do we want to still provide both variants, or simply replace the web based one with the Java based one? > >> Do we want to still provide both variants, or simply replace the web based one with the Java based one? > > No I believe the web variant should be eventually removed. But I think it's better to do that later. Hi @bric3 - if the svg-files aren't used by the plug-in, you should make a PR in the jmc-graphics project for them instead. ------------- PR: https://git.openjdk.org/jmc/pull/408 From duke at openjdk.org Wed Oct 19 19:06:25 2022 From: duke at openjdk.org (Christoph Dreis) Date: Wed, 19 Oct 2022 19:06:25 GMT Subject: RFR: 7933: Avoid volatile writes for default field values [v2] In-Reply-To: References: Message-ID: > Hi, > > this PR avoids some volatile writes similar to https://bugs.openjdk.org/browse/JMC-7414. > > Since I can't create JIRA issues, I hope you can create this for me. Let me know if I can help in any other way, though. It has been a while since I contributed to JMC > > Cheers, > Christoph Christoph Dreis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 7933: Avoid volatile writes for default field values ------------- Changes: - all: https://git.openjdk.org/jmc/pull/435/files - new: https://git.openjdk.org/jmc/pull/435/files/ee79a414..15296802 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=435&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=435&range=00-01 Stats: 16 lines in 15 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jmc/pull/435.diff Fetch: git fetch https://git.openjdk.org/jmc pull/435/head:pull/435 PR: https://git.openjdk.org/jmc/pull/435 From duke at openjdk.org Wed Oct 19 19:06:25 2022 From: duke at openjdk.org (Christoph Dreis) Date: Wed, 19 Oct 2022 19:06:25 GMT Subject: RFR: 7933: Avoid volatile writes for default field values [v2] In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 17:01:04 GMT, Marcus Hirt wrote: >> Christoph Dreis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 7933: Avoid volatile writes for default field values > > Changes requested by hirt (Lead). @thegreystone Thanks for the review. I hopefully adjusted everything in the way you wanted it and squashed the commits already with the proper ticket ID in front (thanks for creating this) ------------- PR: https://git.openjdk.org/jmc/pull/435 From aptmac at openjdk.org Thu Oct 20 02:18:30 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 20 Oct 2022 02:18:30 GMT Subject: RFR: 7930: Upgrade to Eclipse 2022-09 In-Reply-To: <5yxqK0pKh5DfScIrw1ugNNVBvRFaeQX09lTPXoLF27E=.09cf9798-bb9b-4532-86e5-e660d2e49954@github.com> References: <5yxqK0pKh5DfScIrw1ugNNVBvRFaeQX09lTPXoLF27E=.09cf9798-bb9b-4532-86e5-e660d2e49954@github.com> Message-ID: On Tue, 18 Oct 2022 23:08:27 GMT, Marcus Hirt wrote: > Upgrading to Eclipse 2022 proved a little bit more complicated that previous upgrades. See https://github.com/eclipse-platform/eclipse.platform.common/blob/master/bundles/org.eclipse.platform.doc.isv/porting/4.25/incompatibilities.html. Marked as reviewed by aptmac (Reviewer). ------------- PR: https://git.openjdk.org/jmc/pull/442 From clanger at openjdk.org Thu Oct 20 15:10:33 2022 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 20 Oct 2022 15:10:33 GMT Subject: RFR: 7861: Bump Agent build to Java 11 compliance and cleanup POM [v2] In-Reply-To: <9w5LulZ5aF3cYLKfHf44T7HvN5LZENmjPJTghdKjuLQ=.f77d3912-4795-4f95-b4ae-7edd62219c85@github.com> References: <9w5LulZ5aF3cYLKfHf44T7HvN5LZENmjPJTghdKjuLQ=.f77d3912-4795-4f95-b4ae-7edd62219c85@github.com> Message-ID: > The JMC Agent project is set up in a somewhat awkward way at the moment. The maven.compiler.source and maven.compiler.target properties are set to 1.8 but we enforce a JDK 11 during the build and also have a test case that implicitly uses/tests JDK11 features. Maybe it is time now to bump the agent to Java 11 compliance? > > Furthermore, the POM file could be cleaned up and a few maven plugins that are used could be bumped to more recent versions. Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: Cleanup JMC agent pom ------------- Changes: - all: https://git.openjdk.org/jmc/pull/415/files - new: https://git.openjdk.org/jmc/pull/415/files/6e16c710..b144c770 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=415&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=415&range=00-01 Stats: 10446 lines in 206 files changed: 9020 ins; 770 del; 656 mod Patch: https://git.openjdk.org/jmc/pull/415.diff Fetch: git fetch https://git.openjdk.org/jmc pull/415/head:pull/415 PR: https://git.openjdk.org/jmc/pull/415 From hirt at openjdk.org Thu Oct 20 16:37:10 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 20 Oct 2022 16:37:10 GMT Subject: Integrated: 7930: Upgrade to Eclipse 2022-09 In-Reply-To: <5yxqK0pKh5DfScIrw1ugNNVBvRFaeQX09lTPXoLF27E=.09cf9798-bb9b-4532-86e5-e660d2e49954@github.com> References: <5yxqK0pKh5DfScIrw1ugNNVBvRFaeQX09lTPXoLF27E=.09cf9798-bb9b-4532-86e5-e660d2e49954@github.com> Message-ID: <6ekW2ltnPLKWvjuon7WiXHIu1fh5RO_6hyTOPb9nDtQ=.5693033e-54b8-43b4-8c6d-4b2ff1e6a45a@github.com> On Tue, 18 Oct 2022 23:08:27 GMT, Marcus Hirt wrote: > Upgrading to Eclipse 2022 proved a little bit more complicated that previous upgrades. See https://github.com/eclipse-platform/eclipse.platform.common/blob/master/bundles/org.eclipse.platform.doc.isv/porting/4.25/incompatibilities.html. This pull request has now been integrated. Changeset: 65bd6b8e Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/65bd6b8ee771c9e192cc4f7b260c843684fcd654 Stats: 111 lines in 17 files changed: 43 ins; 37 del; 31 mod 7930: Upgrade to Eclipse 2022-09 Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/442 From hirt at openjdk.org Thu Oct 20 16:53:54 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 20 Oct 2022 16:53:54 GMT Subject: RFR: 7933: Avoid volatile writes for default field values [v2] In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 19:06:25 GMT, Christoph Dreis wrote: >> Hi, >> >> this PR avoids some volatile writes similar to https://bugs.openjdk.org/browse/JMC-7414. >> >> Since I can't create JIRA issues, I hope you can create this for me. Let me know if I can help in any other way, though. It has been a while since I contributed to JMC >> >> Cheers, >> Christoph > > Christoph Dreis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 7933: Avoid volatile writes for default field values Great! Thanks for the contribution! :) ------------- Marked as reviewed by hirt (Lead). PR: https://git.openjdk.org/jmc/pull/435 From hirt at openjdk.org Thu Oct 20 17:07:34 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 20 Oct 2022 17:07:34 GMT Subject: RFR: 7935: Upgrade the trunk to 9 Message-ID: This will upgrade the master branch to be JMC 9. Woho! ------------- Commit messages: - 7935: Upgrade the trunk to 9 Changes: https://git.openjdk.org/jmc/pull/443/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=443&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7935 Stats: 211 lines in 149 files changed: 0 ins; 0 del; 211 mod Patch: https://git.openjdk.org/jmc/pull/443.diff Fetch: git fetch https://git.openjdk.org/jmc pull/443/head:pull/443 PR: https://git.openjdk.org/jmc/pull/443 From duke at openjdk.org Thu Oct 20 17:11:59 2022 From: duke at openjdk.org (Christoph Dreis) Date: Thu, 20 Oct 2022 17:11:59 GMT Subject: Integrated: 7933: Avoid volatile writes for default field values In-Reply-To: References: Message-ID: On Sat, 1 Oct 2022 10:47:21 GMT, Christoph Dreis wrote: > Hi, > > this PR avoids some volatile writes similar to https://bugs.openjdk.org/browse/JMC-7414. > > Since I can't create JIRA issues, I hope you can create this for me. Let me know if I can help in any other way, though. It has been a while since I contributed to JMC > > Cheers, > Christoph This pull request has now been integrated. Changeset: 3a0af372 Author: Christoph Dreis Committer: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/3a0af3723a7389f1c7c8c1f0e8d52dbb83cfb830 Stats: 34 lines in 16 files changed: 0 ins; 0 del; 34 mod 7933: Avoid volatile writes for default field values Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/435 From hirt at openjdk.org Thu Oct 20 17:29:05 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 20 Oct 2022 17:29:05 GMT Subject: RFR: 7935: Upgrade the trunk to 9 [v2] In-Reply-To: References: Message-ID: > This will upgrade the master branch to be JMC 9. Woho! Marcus Hirt has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Small fix for changes in master - Merge branch 'master' into 7935-update-to-9 - 7935: Upgrade the trunk to 9 ------------- Changes: - all: https://git.openjdk.org/jmc/pull/443/files - new: https://git.openjdk.org/jmc/pull/443/files/7073e695..b0dffec8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=443&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=443&range=00-01 Stats: 145 lines in 33 files changed: 43 ins; 37 del; 65 mod Patch: https://git.openjdk.org/jmc/pull/443.diff Fetch: git fetch https://git.openjdk.org/jmc pull/443/head:pull/443 PR: https://git.openjdk.org/jmc/pull/443 From marcus.hirt at datadoghq.com Thu Oct 20 19:06:24 2022 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Thu, 20 Oct 2022 12:06:24 -0700 Subject: JMC 8.3.0 ga. Message-ID: Hi all, Unless anyone is of a different opinion, I'll be setting the JMC 8.3.0 ga tag tomorrow. Please let me know! Kind regards, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From schaturvedi at openjdk.org Thu Oct 20 19:41:02 2022 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Thu, 20 Oct 2022 19:41:02 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v4] In-Reply-To: References: Message-ID: On Thu, 6 Oct 2022 20:28:14 GMT, Suchita Chaturvedi wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Adding higher timeout as default value This PR is with respect to an issue raised by one of our customers where Class Leak Rule is taking 60-90 minutes to evaluate the results. The issue was raised on Sat Apr 24 2021. Its been more than a year and we couldn't give any solution to our customers, they are still living with that unacceptable calculation time. Now they are chasing us with several messages and mails to understand when will they receive a fix for it. They have marked it as P2. Hence, considering below points: 1. We are reducing the rule calculation time from 60-90 mins to less than 60 seconds. These calculation timings are with respect to the JFR shared by customer while raising the issue in BugDB (Oracle Internal portal for raising issues). 2. We are correcting the results shown for Class Leak Rule and the correction is a drastic change. The existing approach is showing everything in GREEN even if there is a big issue and HIGH ALERT should be given as part of this rule results. This PR is fixing that issue and showing the correct result to the customers. 3. We have a fix which is not breaking anything as such. No Critical or Must DO review comment is left out unattended. Is it possible to accept this PR for 8.3 release and create a new lesser priority enhancement request if there are any modifications required with respect to re-designing of this Rule or using some other data structure? @thegreystone @Gunde @aptmac @bric3 I would like to know your views on this. Thanks in advance. ------------- PR: https://git.openjdk.org/jmc/pull/419 From suchita.chaturvedi at oracle.com Thu Oct 20 19:41:52 2022 From: suchita.chaturvedi at oracle.com (Suchita Chaturvedi) Date: Thu, 20 Oct 2022 19:41:52 +0000 Subject: JMC 8.3.0 ga. In-Reply-To: References: Message-ID: Hi Marcus, Its regarding Class Leak Rule related PR. https://github.com/openjdk/jmc/pull/419 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. This PR is with respect to an issue raised by one of our customers where Class Leak Rule is taking 60-90 minutes to evaluate the results. The issue was raised on Sat Apr 24 2021. Its been more than a year and we couldn't give any solution to our customers, they are still living with that unacceptable calculation time. Now they are chasing us with several messages and mails to understand when will they receive a fix for it. They have marked it as P2. Hence, considering below points: 1. We are reducing the rule calculation time from 60-90 mins to less than 60 seconds. These calculation timings are with respect to the JFR shared by customer while raising the issue in BugDB (Oracle Internal portal for raising issues). 2. We are correcting the results shown for Class Leak Rule and the correction is a drastic change. The existing approach is showing everything in GREEN even if there is a big issue and HIGH ALERT should be given as part of this rule results. This PR is fixing that issue and showing the correct result to the customers. 3. We have a fix which is not breaking anything as such. No Critical or Must DO review comment is left out unattended. Is it possible to accept this PR for 8.3 release and create a new lesser priority enhancement request if there are any modifications required with respect to re-designing of this Rule or using some other data structure? Thanks Suchita Chaturvedi From: jmc-dev On Behalf Of Marcus Hirt Sent: Friday, October 21, 2022 12:36 AM To: jmc-dev at openjdk.java.net Subject: JMC 8.3.0 ga. Hi all, Unless anyone is of a different opinion, I'll be setting the JMC 8.3.0 ga tag tomorrow. Please let me know! Kind regards, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From clanger at openjdk.org Thu Oct 20 19:42:57 2022 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 20 Oct 2022 19:42:57 GMT Subject: RFR: 7935: Upgrade the trunk to 9 [v2] In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 17:29:05 GMT, Marcus Hirt wrote: >> This will upgrade the master branch to be JMC 9. Woho! > > Marcus Hirt has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Small fix for changes in master > - Merge branch 'master' into 7935-update-to-9 > - 7935: Upgrade the trunk to 9 Great ? ------------- Marked as reviewed by clanger (Committer). PR: https://git.openjdk.org/jmc/pull/443 From clanger at openjdk.org Thu Oct 20 19:58:36 2022 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 20 Oct 2022 19:58:36 GMT Subject: RFR: 7939: Cleanup of JDK dependencies in JMC tycho build Message-ID: This cleans out some project settings and compilation flags to access JDK internals. ------------- Commit messages: - JMC-7939 Changes: https://git.openjdk.org/jmc/pull/444/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=444&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7939 Stats: 417 lines in 24 files changed: 38 ins; 296 del; 83 mod Patch: https://git.openjdk.org/jmc/pull/444.diff Fetch: git fetch https://git.openjdk.org/jmc pull/444/head:pull/444 PR: https://git.openjdk.org/jmc/pull/444 From jpbempel at openjdk.org Thu Oct 20 20:10:57 2022 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Thu, 20 Oct 2022 20:10:57 GMT Subject: RFR: 7935: Upgrade the trunk to 9 [v2] In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 17:29:05 GMT, Marcus Hirt wrote: >> This will upgrade the master branch to be JMC 9. Woho! > > Marcus Hirt has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Small fix for changes in master > - Merge branch 'master' into 7935-update-to-9 > - 7935: Upgrade the trunk to 9 Marked as reviewed by jpbempel (Committer). ------------- PR: https://git.openjdk.org/jmc/pull/443 From hirt at openjdk.org Thu Oct 20 21:18:58 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 20 Oct 2022 21:18:58 GMT Subject: Integrated: 7935: Upgrade the trunk to 9 In-Reply-To: References: Message-ID: <-Xr5KYf8EEmzhCf9_d6Y28PkuDqO1c_U9UC2SlhFPLk=.f890f2e0-2ff8-4659-9182-50051abe023f@github.com> On Thu, 20 Oct 2022 17:00:44 GMT, Marcus Hirt wrote: > This will upgrade the master branch to be JMC 9. Woho! This pull request has now been integrated. Changeset: da85800b Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/da85800b87382d1f5aeb28c6feca2e7acf00d9cc Stats: 213 lines in 150 files changed: 0 ins; 0 del; 213 mod 7935: Upgrade the trunk to 9 Reviewed-by: clanger, jpbempel ------------- PR: https://git.openjdk.org/jmc/pull/443 From hirt at openjdk.org Thu Oct 20 21:29:56 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 20 Oct 2022 21:29:56 GMT Subject: RFR: 7939: Cleanup of JDK dependencies in JMC tycho build In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 19:51:43 GMT, Christoph Langer wrote: > This cleans out some project settings and compilation flags to access JDK internals. > > It removes the remnants of JMC_JDK user library. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.org/jmc/pull/444 From hirt at openjdk.org Thu Oct 20 22:37:35 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 20 Oct 2022 22:37:35 GMT Subject: RFR: 7940: Fix manifest making the Eclipse IDE unhappy Message-ID: ... ------------- Commit messages: - 7940: Fix manifest making the Eclipse IDE unhappy Changes: https://git.openjdk.org/jmc/pull/445/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=445&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7940 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/445.diff Fetch: git fetch https://git.openjdk.org/jmc pull/445/head:pull/445 PR: https://git.openjdk.org/jmc/pull/445 From aptmac at openjdk.org Fri Oct 21 02:37:56 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 21 Oct 2022 02:37:56 GMT Subject: RFR: 7940: Fix manifest making the Eclipse IDE unhappy In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 22:30:34 GMT, Marcus Hirt wrote: > ... Marked as reviewed by aptmac (Reviewer). ------------- PR: https://git.openjdk.org/jmc/pull/445 From clanger at openjdk.org Fri Oct 21 04:35:02 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 21 Oct 2022 04:35:02 GMT Subject: Integrated: 7939: Cleanup of JDK dependencies in JMC tycho build In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 19:51:43 GMT, Christoph Langer wrote: > This cleans out some project settings and compilation flags to access JDK internals. > > It removes the remnants of JMC_JDK user library. This pull request has now been integrated. Changeset: 0e8e2004 Author: Christoph Langer URL: https://git.openjdk.org/jmc/commit/0e8e2004c2c9452a03f762796fd70dc410ed9d59 Stats: 417 lines in 24 files changed: 38 ins; 296 del; 83 mod 7939: Cleanup of JDK dependencies in JMC tycho build Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/444 From clanger at openjdk.org Fri Oct 21 04:57:53 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 21 Oct 2022 04:57:53 GMT Subject: RFR: 7940: Fix manifest making the Eclipse IDE unhappy In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 22:30:34 GMT, Marcus Hirt wrote: > ... Marked as reviewed by clanger (Committer). ------------- PR: https://git.openjdk.org/jmc/pull/445 From clanger at openjdk.org Fri Oct 21 05:54:45 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 21 Oct 2022 05:54:45 GMT Subject: RFR: JMC-7941 More Eclipse IDE fixes Message-ID: This repairs a classpath warning in flightrecorder.graphview due to missing folder src/test/java. Furthermore, I removed .settings files which are excluded via .gitignore anyway and are generated by local IDE setup. ------------- Commit messages: - Update Java SE version in manifest, too - JMC-7941 More Eclipse IDE fixes Changes: https://git.openjdk.org/jmc/pull/446/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=446&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7941 Stats: 31 lines in 5 files changed: 0 ins; 28 del; 3 mod Patch: https://git.openjdk.org/jmc/pull/446.diff Fetch: git fetch https://git.openjdk.org/jmc pull/446/head:pull/446 PR: https://git.openjdk.org/jmc/pull/446 From aptmac at openjdk.org Fri Oct 21 18:10:06 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 21 Oct 2022 18:10:06 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v5] In-Reply-To: References: 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. > > `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. > > So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: > - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate > - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult > > [0] https://bugs.openjdk.java.net/browse/JMC-7307 Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - update license headers to 2022 - fix package name in JFCXMLValidator logger - re-order flightrecorder.configuration.test in test pom - update license headers - migrate VolatileStorageDelegate to flightrecorder.configuration.model - revert .classpath files to their original from application - minor cleanup - move configuration.model.xml test from application to core; remove controlpanel.ui.configuration.test The controlpanel.ui.configuration only had the XML test, which is now located in flightrecorder.configuration.test in core. Currently all tests in both core and application will pass. - move flightrecorder.configuration coverage from application to core - temporarily silence test modules that are moved, will cleanup after - ... and 2 more: https://git.openjdk.org/jmc/compare/0e8e2004...9fad2d39 ------------- Changes: https://git.openjdk.org/jmc/pull/299/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=299&range=04 Stats: 1004 lines in 97 files changed: 373 ins; 475 del; 156 mod Patch: https://git.openjdk.org/jmc/pull/299.diff Fetch: git fetch https://git.openjdk.org/jmc pull/299/head:pull/299 PR: https://git.openjdk.org/jmc/pull/299 From aptmac at openjdk.org Fri Oct 21 18:10:08 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 21 Oct 2022 18:10:08 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v4] In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 16:03:42 GMT, Alex Macdonald 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. >> >> `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. >> >> So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: >> - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult >> >> [0] https://bugs.openjdk.java.net/browse/JMC-7307 > > Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - update license headers to 2022 > - fix package name in JFCXMLValidator logger > - re-order flightrecorder.configuration.test in test pom > - update license headers > - migrate VolatileStorageDelegate to flightrecorder.configuration.model > - revert .classpath files to their original from application > - minor cleanup > - move configuration.model.xml test from application to core; remove controlpanel.ui.configuration.test > > The controlpanel.ui.configuration only had the XML test, which is now > located in flightrecorder.configuration.test in core. Currently all > tests in both core and application will pass. > - move flightrecorder.configuration coverage from application to core > - temporarily silence test modules that are moved, will cleanup after > - ... and 2 more: https://git.openjdk.org/jmc/compare/9ec05b30...511343e1 Now that JMC 9 looks like it's around the corner, I've rebased this PR on top of the current master branch. ------------- PR: https://git.openjdk.org/jmc/pull/299 From aptmac at openjdk.org Fri Oct 21 18:33:56 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 21 Oct 2022 18:33:56 GMT Subject: RFR: 7308: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common [v3] In-Reply-To: References: Message-ID: > This PR addresses JMC-7308 [[0]](https://bugs.openjdk.java.net/browse/JMC-7308), in which it would be helpful to have some of the classes currently in jmc.ui.common shipped in core. > > There are a number of classes currently in jmc.ui.common that would be a great asset to the core distribution (and the third-party applications that consume jmc-core), and these classes could live in jmc.common. > > It isn't as straightforward as moving all of the packages to core, as there are still classes in these jmc.ui.common packages that have dependencies on Eclipse or rjmx. Having said that, the ones listed below can be moved without much difficulty: > > - org.openjdk.jmc.ui.common.action (3) > Executable, IActionProvider, IUserAction > > - org.openjdk.jmc.ui.common.jvm (5) > Connectable, JVMArch, JVMCommandLineToolkit, JVMDescriptor, JVMType > > - org.openjdk.jmc.ui.common.resource (2) > IImageResource, Resource > > - org.openjdk.jmc.ui.common.security (10) > ActionNotGrantedException, CredentialsNotAvailableException, FailedToSaveException, ICredentials, InMemoryCredentials, ISecurityManager, PersistentCredentials, SecurlyStoredByteArray, SecurityException, SecurityManagerFactory > > - org.opendjk.jmc.ui.common.tree (3) > IArray, IChild, IParent > > - org.openjdk.jmc.ui.common.util (4) > Environment, Filename, ICopyable, IObservable > > - org.openjdk.jmc.ui.common.xydata (5) > DataSeries, DefautlTimestampedData, DefaultXYData, ITimeStampedData, IXYData > > [0] https://bugs.openjdk.java.net/browse/JMC-7308 Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - fix imports for PersistentCredentials I must have missed this when I rebased onto the master branch. Fixing it up here. - update license headers to 2022 - update license headers - update agent plugin imports - migrate classes from ui.common.resource to core - migrate interfaces from ui.common.action to core - migrate most of the remainder from ui.common.security to core - migrate ui.common.xydata to core - migrate Environment, Filename, ICopyable, and IObservable from ui.common.util to core - migrate ui.common.tree to core - ... and 2 more: https://git.openjdk.org/jmc/compare/0e8e2004...a99a9c1b ------------- Changes: https://git.openjdk.org/jmc/pull/300/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=300&range=02 Stats: 621 lines in 174 files changed: 149 ins; 173 del; 299 mod Patch: https://git.openjdk.org/jmc/pull/300.diff Fetch: git fetch https://git.openjdk.org/jmc pull/300/head:pull/300 PR: https://git.openjdk.org/jmc/pull/300 From aptmac at openjdk.org Fri Oct 21 18:33:56 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 21 Oct 2022 18:33:56 GMT Subject: RFR: 7308: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common [v2] In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 16:42:44 GMT, Alex Macdonald wrote: >> This PR addresses JMC-7308 [[0]](https://bugs.openjdk.java.net/browse/JMC-7308), in which it would be helpful to have some of the classes currently in jmc.ui.common shipped in core. >> >> There are a number of classes currently in jmc.ui.common that would be a great asset to the core distribution (and the third-party applications that consume jmc-core), and these classes could live in jmc.common. >> >> It isn't as straightforward as moving all of the packages to core, as there are still classes in these jmc.ui.common packages that have dependencies on Eclipse or rjmx. Having said that, the ones listed below can be moved without much difficulty: >> >> - org.openjdk.jmc.ui.common.action (3) >> Executable, IActionProvider, IUserAction >> >> - org.openjdk.jmc.ui.common.jvm (5) >> Connectable, JVMArch, JVMCommandLineToolkit, JVMDescriptor, JVMType >> >> - org.openjdk.jmc.ui.common.resource (2) >> IImageResource, Resource >> >> - org.openjdk.jmc.ui.common.security (10) >> ActionNotGrantedException, CredentialsNotAvailableException, FailedToSaveException, ICredentials, InMemoryCredentials, ISecurityManager, PersistentCredentials, SecurlyStoredByteArray, SecurityException, SecurityManagerFactory >> >> - org.opendjk.jmc.ui.common.tree (3) >> IArray, IChild, IParent >> >> - org.openjdk.jmc.ui.common.util (4) >> Environment, Filename, ICopyable, IObservable >> >> - org.openjdk.jmc.ui.common.xydata (5) >> DataSeries, DefautlTimestampedData, DefaultXYData, ITimeStampedData, IXYData >> >> [0] https://bugs.openjdk.java.net/browse/JMC-7308 > > Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - update license headers to 2022 > - update license headers > - update agent plugin imports > - migrate classes from ui.common.resource to core > - migrate interfaces from ui.common.action to core > - migrate most of the remainder from ui.common.security to core > - migrate ui.common.xydata to core > - migrate Environment, Filename, ICopyable, and IObservable from ui.common.util to core > - migrate ui.common.tree to core > - migrate ui.common.jvm to core > - ... and 1 more: https://git.openjdk.org/jmc/compare/9ec05b30...69aeed33 Similar to my other PR (https://github.com/openjdk/jmc/pull/299), this has been rebased onto the current master branch for consideration in JMC 9. ------------- PR: https://git.openjdk.org/jmc/pull/300 From hirt at openjdk.org Fri Oct 21 22:16:39 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 21 Oct 2022 22:16:39 GMT Subject: Integrated: 7940: Fix manifest making the Eclipse IDE unhappy In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 22:30:34 GMT, Marcus Hirt wrote: > ... This pull request has now been integrated. Changeset: b5f34909 Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/b5f34909964bf387e6edb65aa30f1e082c789d16 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 7940: Fix manifest making the Eclipse IDE unhappy Reviewed-by: aptmac, clanger ------------- PR: https://git.openjdk.org/jmc/pull/445 From hirt at openjdk.org Fri Oct 21 22:16:53 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 21 Oct 2022 22:16:53 GMT Subject: RFR: JMC-7941 Fixes for Graphview and Flameview projects In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 05:48:13 GMT, Christoph Langer wrote: > This repairs a classpath warning in flightrecorder.graphview due to missing folder src/test/java. > > Furthermore, I bumped the flameview project to JDK 11 and cleaned up its IDE settings. Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.org/jmc/pull/446 From hirt at openjdk.org Fri Oct 21 22:18:59 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Fri, 21 Oct 2022 22:18:59 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v4] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 02:27:16 GMT, Alex Macdonald wrote: >> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding higher timeout as default value > > Is https://bugs.openjdk.org/browse/JMC-7879 a duplicate of https://bugs.openjdk.org/browse/JMC-7248? > > It looks like this PR is https://github.com/openjdk/jmc/pull/248 with some of the review comments addressed, should the former PR be closed in favor of this? > > There are a couple of review comments that didn't receive any changes in this PR: > https://github.com/openjdk/jmc/pull/248/files#r756349943 > https://github.com/openjdk/jmc/pull/248/files#r756353644 > > It looks like the consensus on https://github.com/openjdk/jmc/pull/248 was that it was good enough to go in, maybe ping @bric3 and/or @Gunde for a re-review/approval? @aptmac, @Gunde & @bric3 - can you please help Suchita complete this PR? ------------- PR: https://git.openjdk.org/jmc/pull/419 From marcus.hirt at datadoghq.com Sun Oct 23 07:26:35 2022 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Sun, 23 Oct 2022 09:26:35 +0200 Subject: JMC 8.3.0 ga. In-Reply-To: References: Message-ID: Hi Suchita, The way to get this change in is to work with the reviewers to finish up the work. It is very late in the 8.3.0 release, but if it can be done during the beginning of next week that would be ok. Kind regards, Marcus On Thu, Oct 20, 2022 at 9:41 PM Suchita Chaturvedi < suchita.chaturvedi at oracle.com> wrote: > Hi Marcus, > > > > Its regarding Class Leak Rule related PR. > > https://github.com/openjdk/jmc/pull/419 > > > *7879: Automated Analysis taking very long time to produce results for > Class Leak Rule and showing wrong results.* > > > > > This PR is with respect to an issue raised by one of our customers where > Class Leak Rule is taking 60-90 minutes to evaluate the results. The issue > was raised on Sat Apr 24 2021. Its been more than a year and we couldn't > give any solution to our customers, they are still living with that > unacceptable calculation time. Now they are chasing us with several > messages and mails to understand when will they receive a fix for it. They > have marked it as P2. > > > > Hence, considering below points: > > 1. We are reducing the rule calculation time from 60-90 mins to less than > 60 seconds. These calculation timings are with respect to the JFR shared by > customer while raising the issue in BugDB (Oracle Internal portal for > raising issues). > > 2. We are correcting the results shown for Class Leak Rule and the > correction is a drastic change. The existing approach is showing everything > in GREEN even if there is a big issue and HIGH ALERT should be given as > part of this rule results. This PR is fixing that issue and showing the > correct result to the customers. > > 3. We have a fix which is not breaking anything as such. No Critical or > Must DO review comment is left out unattended. > > > > Is it possible to accept this PR for 8.3 release and create a new lesser > priority enhancement request if there are any modifications required with > respect to re-designing of this Rule or using some other data structure? > > > > Thanks > > Suchita Chaturvedi > > *From:* jmc-dev *On Behalf Of *Marcus Hirt > *Sent:* Friday, October 21, 2022 12:36 AM > *To:* jmc-dev at openjdk.java.net > *Subject:* JMC 8.3.0 ga. > > > > Hi all, > > > > Unless anyone is of a different opinion, I'll be setting the JMC 8.3.0 ga > tag tomorrow. > > Please let me know! > > > > Kind regards, > > Marcus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clanger at openjdk.org Sun Oct 23 13:23:15 2022 From: clanger at openjdk.org (Christoph Langer) Date: Sun, 23 Oct 2022 13:23:15 GMT Subject: Integrated: JMC-7941 Fixes for Graphview and Flameview projects In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 05:48:13 GMT, Christoph Langer wrote: > This repairs a classpath warning in flightrecorder.graphview due to missing folder src/test/java. > > Furthermore, I bumped the flameview project to JDK 11 and cleaned up its IDE settings. This pull request has now been integrated. Changeset: 53991b11 Author: Christoph Langer URL: https://git.openjdk.org/jmc/commit/53991b1167ed02e8b8d8eea55f8037799815c373 Stats: 31 lines in 5 files changed: 0 ins; 28 del; 3 mod 7941: Fixes for Graphview and Flameview projects Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/446 From hirt at openjdk.org Mon Oct 24 08:09:09 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 24 Oct 2022 08:09:09 GMT Subject: Integrated: 7538: Check in launcher for JVMKeepAlive In-Reply-To: References: Message-ID: On Fri, 21 Jan 2022 11:54:10 GMT, Marcus Hirt wrote: > Helpful for new developers. This pull request has now been integrated. Changeset: ad2171da Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/ad2171da7dc31fc1e0aab091f2fb6c5ff6062c13 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod 7538: Check in launcher for JVMKeepAlive Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/368 From aptmac at openjdk.org Mon Oct 24 13:48:57 2022 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 24 Oct 2022 13:48:57 GMT Subject: RFR: 7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results. [v4] In-Reply-To: References: Message-ID: On Thu, 6 Oct 2022 20:28:14 GMT, Suchita Chaturvedi wrote: >> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Adding higher timeout as default value I think it looks okay for me. It would be nice to have a way of reproducing the issue to verify, but I get it's tough if the original jfr is from a customer and can't be shared. Having said that, @Gunde and @bric3 did substantial review on this PR as well as the previous (https://github.com/openjdk/jmc/pull/248), and while on the surface it looks like everything has been addressed I would feel much more comfortable if they could just confirm that what they wanted addressed was updated in this PR before merging it. core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 84: > 82: private void calculateData(IItemCollection input, int configuredTimeout) throws InterruptedException { > 83: input = input.apply(query.getFilter()); > 84: final IItemCollection newInput = input; Very minor nit, but this could be moved to be inside the else block where it's used? It's not required for the first chunk of the if-statement. ------------- PR: https://git.openjdk.org/jmc/pull/419 From duke at openjdk.org Tue Oct 25 09:13:29 2022 From: duke at openjdk.org (Richard Startin) Date: Tue, 25 Oct 2022 09:13:29 GMT Subject: RFR: 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader Message-ID: When using jmc-common in a backend process we throw the following swallowed exception millions of times a day: java.lang.NoSuchFieldException: package at java.base/java.lang.Class.getField(Class.java:2149) at org.openjdk.jmc.flightrecorder.internal.parser.v1.ValueReaders$ReflectiveReader.addField(ValueReaders.java:593) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:200) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$EventTypeEntry.init(TypeManager.java:357) at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.(TypeManager.java:432) at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:70) at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:48) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) This adds a simple memoization to store the identifier to field mapping, with size bounded by the number of classes used in JFR events. --------- ### Progress - [ ] Commit message must refer to an issue - [ ] Change must be properly reviewed (1 review required, with at least 1 [Committer](https://openjdk.org/bylaws#committer)) ### Error  ?? The pull request body must not be empty. ### Reviewing
Using git Checkout this PR locally: \ `$ git fetch https://git.openjdk.org/jmc pull/447/head:pull/447` \ `$ git checkout pull/447` Update a local copy of the PR: \ `$ git checkout pull/447` \ `$ git pull https://git.openjdk.org/jmc pull/447/head`
Using Skara CLI tools Checkout this PR locally: \ `$ git pr checkout 447` View PR using the GUI difftool: \ `$ git pr show -t 447`
Using diff file Download this PR as a diff file: \ https://git.openjdk.org/jmc/pull/447.diff
------------- Commit messages: - 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader Changes: https://git.openjdk.org/jmc/pull/447/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=447&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7945 Stats: 29 lines in 1 file changed: 21 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jmc/pull/447.diff Fetch: git fetch https://git.openjdk.org/jmc pull/447/head:pull/447 PR: https://git.openjdk.org/jmc/pull/447 From duke at openjdk.org Tue Oct 25 09:25:37 2022 From: duke at openjdk.org (Richard Startin) Date: Tue, 25 Oct 2022 09:25:37 GMT Subject: RFR: 7944: Reduce allocations of Double during chunk loading Message-ID: Using jmc-common as a library in a backend process we see high allocation rates of `Double` and have observed moderate performance improvements from this simple refactoring: * Use primitive `double` in `ImpreciseScaleFactor` * Use primitive `double` in `IScalarAffineTransformation.getOffset` * Push multiplication of a scale factor down to a new method `ScaleFactor.scale(long multiplier)` * Push `ScalarQuantity.in` down to `LongStored`/`DoubleStored` to avoid generalising over primitive types, when the `IQuantity` type can be varied instead. --------- ### Progress - [ ] Commit message must refer to an issue - [ ] Change must be properly reviewed (1 review required, with at least 1 [Committer](https://openjdk.org/bylaws#committer)) ### Reviewing
Using git Checkout this PR locally: \ `$ git fetch https://git.openjdk.org/jmc pull/436/head:pull/436` \ `$ git checkout pull/436` Update a local copy of the PR: \ `$ git checkout pull/436` \ `$ git pull https://git.openjdk.org/jmc pull/436/head`
Using Skara CLI tools Checkout this PR locally: \ `$ git pr checkout 436` View PR using the GUI difftool: \ `$ git pr show -t 436`
Using diff file Download this PR as a diff file: \ https://git.openjdk.org/jmc/pull/436.diff
------------- Commit messages: - JMC-7944: Reduce allocations of Double during chunk loading Changes: https://git.openjdk.org/jmc/pull/436/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=436&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7944 Stats: 103 lines in 10 files changed: 47 ins; 28 del; 28 mod Patch: https://git.openjdk.org/jmc/pull/436.diff Fetch: git fetch https://git.openjdk.org/jmc pull/436/head:pull/436 PR: https://git.openjdk.org/jmc/pull/436 From hirt at openjdk.org Tue Oct 25 10:25:14 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 25 Oct 2022 10:25:14 GMT Subject: RFR: 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 09:01:22 GMT, Richard Startin wrote: > When using jmc-common in a backend process we throw the following swallowed exception millions of times a day: > > > java.lang.NoSuchFieldException: package > at java.base/java.lang.Class.getField(Class.java:2149) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ValueReaders$ReflectiveReader.addField(ValueReaders.java:593) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:200) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$EventTypeEntry.init(TypeManager.java:357) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.(TypeManager.java:432) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:70) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:48) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:833) > > > This adds a simple memoization to store the identifier to field mapping, with size bounded by the number of classes used in JFR events. > > --------- > ### Progress > - [ ] Commit message must refer to an issue > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Committer](https://openjdk.org/bylaws#committer)) > > ### Error >  ?? The pull request body must not be empty. > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jmc pull/447/head:pull/447` \ > `$ git checkout pull/447` > > Update a local copy of the PR: \ > `$ git checkout pull/447` \ > `$ git pull https://git.openjdk.org/jmc pull/447/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 447` > > View PR using the GUI difftool: \ > `$ git pr show -t 447` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jmc/pull/447.diff > >
Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.org/jmc/pull/447 From hirt at openjdk.org Tue Oct 25 10:36:30 2022 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 25 Oct 2022 10:36:30 GMT Subject: RFR: 7861: Bump Agent build to Java 11 compliance and cleanup POM [v2] In-Reply-To: References: <9w5LulZ5aF3cYLKfHf44T7HvN5LZENmjPJTghdKjuLQ=.f77d3912-4795-4f95-b4ae-7edd62219c85@github.com> Message-ID: On Thu, 20 Oct 2022 15:10:33 GMT, Christoph Langer wrote: >> The JMC Agent project is set up in a somewhat awkward way at the moment. The maven.compiler.source and maven.compiler.target properties are set to 1.8 but we enforce a JDK 11 during the build and also have a test case that implicitly uses/tests JDK11 features. Maybe it is time now to bump the agent to Java 11 compliance? >> >> Furthermore, the POM file could be cleaned up and a few maven plugins that are used could be bumped to more recent versions. > > Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > Cleanup JMC agent pom Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.org/jmc/pull/415 From duke at openjdk.org Tue Oct 25 11:17:25 2022 From: duke at openjdk.org (Richard Startin) Date: Tue, 25 Oct 2022 11:17:25 GMT Subject: RFR: 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader [v2] In-Reply-To: References: Message-ID: <1iF5O-biVu8gEZWTJuE8HKIEe35MOQdmh8_vd02iRBA=.57f4c048-3b9e-40b9-bd73-767eae1cdd50@github.com> > When using jmc-common in a backend process we throw the following swallowed exception millions of times a day: > > > java.lang.NoSuchFieldException: package > at java.base/java.lang.Class.getField(Class.java:2149) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ValueReaders$ReflectiveReader.addField(ValueReaders.java:593) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:200) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$EventTypeEntry.init(TypeManager.java:357) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.(TypeManager.java:432) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:70) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:48) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:833) > > > This adds a simple memoization to store the identifier to field mapping, with size bounded by the number of classes used in JFR events. > > --------- > ### Progress > - [ ] Commit message must refer to an issue > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Committer](https://openjdk.org/bylaws#committer)) > > ### Error >  ?? The pull request body must not be empty. > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jmc pull/447/head:pull/447` \ > `$ git checkout pull/447` > > Update a local copy of the PR: \ > `$ git checkout pull/447` \ > `$ git pull https://git.openjdk.org/jmc pull/447/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 447` > > View PR using the GUI difftool: \ > `$ git pr show -t 447` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jmc/pull/447.diff > >
Richard Startin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader ------------- Changes: https://git.openjdk.org/jmc/pull/447/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=447&range=01 Stats: 30 lines in 1 file changed: 21 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jmc/pull/447.diff Fetch: git fetch https://git.openjdk.org/jmc pull/447/head:pull/447 PR: https://git.openjdk.org/jmc/pull/447 From duke at openjdk.org Tue Oct 25 11:17:26 2022 From: duke at openjdk.org (Richard Startin) Date: Tue, 25 Oct 2022 11:17:26 GMT Subject: RFR: 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 09:01:22 GMT, Richard Startin wrote: > When using jmc-common in a backend process we throw the following swallowed exception millions of times a day: > > > java.lang.NoSuchFieldException: package > at java.base/java.lang.Class.getField(Class.java:2149) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ValueReaders$ReflectiveReader.addField(ValueReaders.java:593) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:200) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$EventTypeEntry.init(TypeManager.java:357) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.(TypeManager.java:432) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:70) > at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:48) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:833) > > > This adds a simple memoization to store the identifier to field mapping, with size bounded by the number of classes used in JFR events. > > --------- > ### Progress > - [ ] Commit message must refer to an issue > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Committer](https://openjdk.org/bylaws#committer)) > > ### Error >  ?? The pull request body must not be empty. > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jmc pull/447/head:pull/447` \ > `$ git checkout pull/447` > > Update a local copy of the PR: \ > `$ git checkout pull/447` \ > `$ git pull https://git.openjdk.org/jmc pull/447/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 447` > > View PR using the GUI difftool: \ > `$ git pr show -t 447` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jmc/pull/447.diff > >
rebased and updated copyright year ------------- PR: https://git.openjdk.org/jmc/pull/447 From jbachorik at openjdk.org Tue Oct 25 11:53:43 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 25 Oct 2022 11:53:43 GMT Subject: RFR: 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader [v2] In-Reply-To: <1iF5O-biVu8gEZWTJuE8HKIEe35MOQdmh8_vd02iRBA=.57f4c048-3b9e-40b9-bd73-767eae1cdd50@github.com> References: <1iF5O-biVu8gEZWTJuE8HKIEe35MOQdmh8_vd02iRBA=.57f4c048-3b9e-40b9-bd73-767eae1cdd50@github.com> Message-ID: On Tue, 25 Oct 2022 11:17:25 GMT, Richard Startin wrote: >> When using jmc-common in a backend process we throw the following swallowed exception millions of times a day: >> >> >> java.lang.NoSuchFieldException: package >> at java.base/java.lang.Class.getField(Class.java:2149) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.ValueReaders$ReflectiveReader.addField(ValueReaders.java:593) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:200) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$TypeEntry.getReader(TypeManager.java:198) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.createFieldReader(TypeManager.java:493) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.access$000(TypeManager.java:86) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager$EventTypeEntry.init(TypeManager.java:357) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.TypeManager.(TypeManager.java:432) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:70) >> at org.openjdk.jmc.flightrecorder.internal.parser.v1.ChunkLoaderV1.call(ChunkLoaderV1.java:48) >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >> at java.base/java.lang.Thread.run(Thread.java:833) >> >> >> This adds a simple memoization to store the identifier to field mapping, with size bounded by the number of classes used in JFR events. >> >> --------- >> ### Progress >> - [ ] Commit message must refer to an issue >> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Committer](https://openjdk.org/bylaws#committer)) >> >> ### Error >>  ?? The pull request body must not be empty. >> >> ### Reviewing >>
Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jmc pull/447/head:pull/447` \ >> `$ git checkout pull/447` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/447` \ >> `$ git pull https://git.openjdk.org/jmc pull/447/head` >> >>
>>
Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 447` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 447` >> >>
>>
Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jmc/pull/447.diff >> >>
> > Richard Startin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > 7945: Avoid throwing NoSuchFieldException in ValueReaders$ReflectiveReader Marked as reviewed by jbachorik (Author). ------------- PR: https://git.openjdk.org/jmc/pull/447 From clanger at openjdk.org Tue Oct 25 16:23:06 2022 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 25 Oct 2022 16:23:06 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v5] In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 18:10:06 GMT, Alex Macdonald 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. >> >> `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. >> >> So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: >> - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult >> >> [0] https://bugs.openjdk.java.net/browse/JMC-7307 > > Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - update license headers to 2022 > - fix package name in JFCXMLValidator logger > - re-order flightrecorder.configuration.test in test pom > - update license headers > - migrate VolatileStorageDelegate to flightrecorder.configuration.model > - revert .classpath files to their original from application > - minor cleanup > - move configuration.model.xml test from application to core; remove controlpanel.ui.configuration.test > > The controlpanel.ui.configuration only had the XML test, which is now > located in flightrecorder.configuration.test in core. Currently all > tests in both core and application will pass. > - move flightrecorder.configuration coverage from application to core > - temporarily silence test modules that are moved, will cleanup after > - ... and 2 more: https://git.openjdk.org/jmc/compare/0e8e2004...9fad2d39 Hi @aptmac, First of all, thanks for doing this refactoring. I now took the time to review this. I have added a few review comments inline. Furthermore, in project flightrecorder.configuration.test, please move the test classes from src/test/java to src/main/java, as in the other test projects. That is the current convention. To make it work, you have to add this to pom.xml: ` ${project.basedir}/src/main/java ` Then, in core/org.openjdk.jmc.flightrecorder.configuration/META-INF/MANIFEST.MF, it could be better/required now to use `Require-Bundle: org.openjdk.jmc.common, + org.openjdk.jmc.flightrecorder` instead of `Import-Package: org.openjdk.jmc.flightrecorder.internal` Other than that, it looks good to me. See above. core/tests/org.openjdk.jmc.common.test/src/main/java/org/openjdk/jmc/common/util/MethodToolkitTest.java line 41: > 39: > 40: import org.junit.Test; > 41: import org.openjdk.jmc.common.util.MethodToolkit; This import is not needed atm since the test class lives in package org.openjdk.jmc.common.util from module org.openjdk.jmc:common. A better way for these tests would be to change their package to org.openjdk.jmc.common.util.test but that should be addressed in another PR. core/tests/org.openjdk.jmc.common.test/src/main/java/org/openjdk/jmc/common/util/SortedHeadTest.java line 42: > 40: > 41: import org.junit.Test; > 42: import org.openjdk.jmc.common.util.SortedHead; Same as my comment in MethodToolkitTest.java core/tests/org.openjdk.jmc.common.test/src/main/java/org/openjdk/jmc/common/util/TypeHandlingTest.java line 38: > 36: > 37: import org.junit.Test; > 38: import org.openjdk.jmc.common.util.TypeHandling; Same as my comment in MethodToolkitTest.java core/tests/org.openjdk.jmc.common.test/src/main/java/org/openjdk/jmc/common/version/JavaVMVersionToolkitTest.java line 33: > 31: * WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > 32: */ > 33: package org.openjdk.jmc.common.test.version; This test should then be moved into subdirectory org/openjdk/jmc/common/test/version. But I think also in a separate change. core/tests/org.openjdk.jmc.common.test/src/main/java/org/openjdk/jmc/common/version/JavaVersionTest.java line 33: > 31: * WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > 32: */ > 33: package org.openjdk.jmc.common.test.version; This test should then be moved into subdirectory org/openjdk/jmc/common/test/version. But I think also in a separate change. core/tests/org.openjdk.jmc.flightrecorder.configuration.test/build.properties line 2: > 1: # > 2: # Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. Wrong Copyright year. If the file content doesn't change, the copyright doesn't need to be updated, anyway. core/tests/org.openjdk.jmc.flightrecorder.configuration.test/pom.xml line 3: > 1: > 2: