From egahlin at openjdk.java.net Mon Nov 1 10:55:30 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 1 Nov 2021 10:55:30 GMT Subject: RFR: 8276218: JFR: Clean up jdk.jfr.dcmd Message-ID: Hi, Could I have a review of a fix that removed an unessary field and System.out.println statement that should be there. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/6183/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6183&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276218 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6183/head:pull/6183 PR: https://git.openjdk.java.net/jdk/pull/6183 From mgronlun at openjdk.java.net Mon Nov 1 11:38:11 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 1 Nov 2021 11:38:11 GMT Subject: RFR: 8276218: JFR: Clean up jdk.jfr.dcmd In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 10:37:02 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of a fix that removes an unessary field and a System.out.println statement that shouldn't be there. > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6183 From egahlin at openjdk.java.net Mon Nov 1 12:36:14 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 1 Nov 2021 12:36:14 GMT Subject: Integrated: 8276218: JFR: Clean up jdk.jfr.dcmd In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 10:37:02 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of a fix that removes an unessary field and a System.out.println statement that shouldn't be there. > > Thanks > Erik This pull request has now been integrated. Changeset: 4ac8403f Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/4ac8403f9a4cedcb5d56bcd34a6bbfa51d67ca18 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod 8276218: JFR: Clean up jdk.jfr.dcmd Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/6183 From minqi at openjdk.java.net Wed Nov 3 03:40:15 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 3 Nov 2021 03:40:15 GMT Subject: RFR: 8275730: Relax memory constraint on MultiThreadedRefCounter In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 17:08:45 GMT, Zhengyu Gu wrote: > It is just an atomic counter, only needs atomic guarantee. add (sub) itself also with a parameter of atomic_memory_order, but this change is more concise. LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6069 From zgu at openjdk.java.net Wed Nov 3 12:12:22 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 3 Nov 2021 12:12:22 GMT Subject: RFR: 8275730: Relax memory constraint on MultiThreadedRefCounter In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 03:36:46 GMT, Yumin Qi wrote: >> It is just an atomic counter, only needs atomic guarantee. > > add (sub) itself also with a parameter of atomic_memory_order, but this change is more concise. > LGTM. Thanks, @yminqi ------------- PR: https://git.openjdk.java.net/jdk/pull/6069 From zgu at openjdk.java.net Wed Nov 3 12:12:23 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 3 Nov 2021 12:12:23 GMT Subject: Integrated: 8275730: Relax memory constraint on MultiThreadedRefCounter In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 17:08:45 GMT, Zhengyu Gu wrote: > It is just an atomic counter, only needs atomic guarantee. This pull request has now been integrated. Changeset: a316c06e Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/a316c06e03e06b86ceca376cf20dcb9c526905f5 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8275730: Relax memory constraint on MultiThreadedRefCounter Reviewed-by: mgronlun, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/6069 From ihse at openjdk.java.net Thu Nov 4 13:10:25 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Nov 2021 13:10:25 GMT Subject: RFR: 8276640: Use blessed modifier order in jfr code Message-ID: I ran bin/blessed-modifier-order.sh on source owned by the JFR team. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. ------------- Commit messages: - 8276640: Use blessed modifier order in jfr code Changes: https://git.openjdk.java.net/jdk/pull/6254/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6254&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276640 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6254/head:pull/6254 PR: https://git.openjdk.java.net/jdk/pull/6254 From mgronlun at openjdk.java.net Thu Nov 4 13:16:22 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 4 Nov 2021 13:16:22 GMT Subject: RFR: 8276640: Use blessed modifier order in jfr code In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 13:01:59 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by the JFR team. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6254 From ihse at openjdk.java.net Thu Nov 4 15:09:21 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Nov 2021 15:09:21 GMT Subject: Integrated: 8276640: Use blessed modifier order in jfr code In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 13:01:59 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by the JFR team. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. This pull request has now been integrated. Changeset: 49b7b2ea Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/49b7b2ea0971fe99567bdbd962d63b90ff2eeefd Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod 8276640: Use blessed modifier order in jfr code Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/6254 From ysuenaga at openjdk.java.net Tue Nov 9 02:30:45 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 9 Nov 2021 02:30:45 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v4] In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: <4NQf3hPWgdwQmY9nfnx2DHX4zplg1z0nM7X2RVeuqnY=.bcd04b4e-db4b-46e4-9b7c-8600fe7cd632@github.com> On Tue, 26 Oct 2021 07:26:43 GMT, Erik Gahlin wrote: >> Yasumasa Suenaga 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 six additional commits since the last revision: >> >> - Add dumppath to JFR.configure dcmd >> - Add "\n" after printing exception >> - Merge remote-tracking branch 'upstream/master' into JDK-8275375-2 >> - Propagate IOException at setDumpPath() to the caller >> - Refactoring setDumpPath related code >> - 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect > > If I remember correctly, if the exception is cleared, the exit status of the process will be incorrect. > > That said, it would be good to get rid of "jdk.jfr.internal.dcmd.DCmdException: Could not ...", but it doesn't necessary need to be fixed in this PR and it must work with other options as well, for example JFR.configure samplethreads=incorrect @egahlin Can you review this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From ludovic at datadoghq.com Fri Nov 12 13:22:43 2021 From: ludovic at datadoghq.com (Ludovic Henry) Date: Fri, 12 Nov 2021 14:22:43 +0100 Subject: Fwd: RFC: JFR Recording Context In-Reply-To: References: Message-ID: Hello, As it's been a couple of months since my last update, I wanted to share some of the progress I've made there. The TL;DR is that it now supports adding context to any event, as well as adding a global or per-event-type filters to control the generation of events based on the context. The changes are available at https://github.com/openjdk/jdk/compare/master...luhenry:jfr-context # Description of a context A context is a map of string key and string value which are attached to relevant JFR events. This context is installed on the current thread, and can be snapshotted and activated on other threads. # Building a context To build a context, you first declare the keys of the context : ``` var contextKey1 = RecordingContextKey.forName("Key1"); ``` Then, to use that key to build a specific context, use the following: ``` var context = RecordingContext.where(contextKey1, "Value1").build(); ``` # Installing a context Building a context will also install the context on the current thread. To uninstall the context, simply do `context.close()`. To capture the context and restore it on another thread, do: ``` // On the thread where the context is already installed: var snapshot = RecordingContext.snapshot(); // On the thread you want to restore/install the context: try (var activation = snapshot.activate()) { ... } ``` You can also use helper functions for structured concurrency: ``` RecordingContext.callWithSnapshot(o -> { ... }, snapshot); RecordingContext.runWithSnapshot(() -> { ... }, snapshot); ``` # Lifecycle of a context Let?s take a look at an example: ``` public class Program { private static final RecordingContextKey contextKey1 = RecordingContextKey.forName("Key1"); public static void main(String[] args) { try (Recording recording = new Recording()) { recording.start(); recording.enable("jdk.ThreadSleep"); try (RecordingContext context = RecordingContext.where(contextKey1, "Value1").build()) { ForkJoinPool pool = ForkJoinPool.commonPool(); final RecordingContext.Snapshot snapshot = RecordingContext.snapshot(); pool.execute(() -> { try (var activation = snapshot.activate()) { Thread.sleep(1); } }); pool.execute(() -> { try (var activation = snapshot.activate()) { Thread.sleep(1); } }); pool.shutdown(); pool.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS); } recording.stop(); recording.dump(Files.createTempFile("my-recording", ".jfr")); } } } ``` The two `jdk.ThreadSleep` events generated are as follows: ``` jdk.ThreadSleep { startTime = 11:06:20.336 (2021-11-12) duration = 1.05 ms time = 1.00 ms eventThread = "main" (javaThreadId = 1) stackTrace = [ java.lang.Thread.sleep(long) Program.lambda$main$0(RecordingContext$Snapshot) line: 23 java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec() line: 1395 java.util.concurrent.ForkJoinTask.doExec() line: 373 java.util.concurrent.ForkJoinPool.externalHelpQuiescePool(long, boolean) line: 2104 ] context = [ Key1 -> Value1, ] } jdk.ThreadSleep { startTime = 11:06:20.336 (2021-11-12) duration = 1.10 ms time = 1.00 ms eventThread = "ForkJoinPool.commonPool-worker-1" (javaThreadId = 18) stackTrace = [ java.lang.Thread.sleep(long) Program.lambda$main$0(RecordingContext$Snapshot) line: 23 java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec() line: 1395 java.util.concurrent.ForkJoinTask.doExec() line: 373 java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinTask, ForkJoinPool$WorkQueue) line: 1182 ] context = [ Key1 -> Value1, ] } ``` # Filtering on the context In order to control the generation of events, this change introduces context filters. A filter is per-type or for all types, and is installed globally. To build and install a filter, you do the following: ``` var filter = RecordingContextFilter.Config.createFilter() .forType(EventType.getEventType(TestEvent.class), b -> { b.hasEntry(contextKey1, "Value1"); }) .forAllTypes(b -> { b.hasKey(contextKey1); }) .build() RecordingContextFilter.Config.setContextFilter(filter); ``` To uninstall a filter, set it to null: `RecordingContextFilter.Config.setContextFilter(null);` The currently supported operations are: - hasKey(key) - hasEntry(key, value) - hasContext() - hasNoContext() To guarantee a certain level of performance, I've made two tradeoffs: - A filter can't have custom code and can only use the supported operations, and - The filters are eagerly computed on the installation of a context to avoid matching the filter on the generation of every event. The per-type and for all types results are stored in a map (or array in native) to guarantee O(1) lookup time. >From microbenchmarks, the current overhead is the following (all the JMH numbers at [1]): - Generating an event with the @Context annotation and an empty context adds ~25ns to the generation of the event - Each entry in the context adds ~100ns to the generation of an event - Setting a filter does not impact the performance of the generation of an event I'll submit a draft PR in the following hours to give an easier time for reviews and feedback. Thank you again very much, and looking forward to your feedback and questions. Ludovic [1] Benchmark Mode Cnt Score Error Units RecordingContextBenchmark.Baseline.withContext avgt 30 0.046 ? 0.001 us/op RecordingContextBenchmark.Baseline.withoutContext avgt 30 0.021 ? 0.001 us/op RecordingContextBenchmark.One.withContext avgt 30 0.160 ? 0.005 us/op RecordingContextBenchmark.One.withoutContext avgt 30 0.021 ? 0.001 us/op RecordingContextBenchmark.Three.withContext avgt 30 0.331 ? 0.009 us/op RecordingContextBenchmark.Three.withoutContext avgt 30 0.022 ? 0.001 us/op RecordingContextBenchmark.Two.withContext avgt 30 0.237 ? 0.003 us/op RecordingContextBenchmark.Two.withoutContext avgt 30 0.021 ? 0.001 us/op RecordingContextFilterBenchmark.Baseline.withContext avgt 30 0.048 ? 0.001 us/op RecordingContextFilterBenchmark.Baseline.withoutContext avgt 30 0.021 ? 0.001 us/op RecordingContextFilterBenchmark.One.withContext avgt 30 0.154 ? 0.003 us/op RecordingContextFilterBenchmark.One.withoutContext avgt 30 0.023 ? 0.001 us/op RecordingContextFilterBenchmark.Three.withContext avgt 30 0.346 ? 0.007 us/op RecordingContextFilterBenchmark.Three.withoutContext avgt 30 0.021 ? 0.001 us/op RecordingContextFilterBenchmark.Two.withContext avgt 30 0.239 ? 0.004 us/op RecordingContextFilterBenchmark.Two.withoutContext avgt 30 0.021 ? 0.001 us/op From ludovic at datadoghq.com Fri Nov 12 13:23:34 2021 From: ludovic at datadoghq.com (Ludovic Henry) Date: Fri, 12 Nov 2021 14:23:34 +0100 Subject: RFC: JFR Recording Context In-Reply-To: References: Message-ID: The link to the draft PR: https://github.com/openjdk/jdk/pull/6368 On Fri, Nov 12, 2021 at 2:22 PM Ludovic Henry wrote: > Hello, > > As it's been a couple of months since my last update, I wanted to share > some of the progress I've made there. The TL;DR is that it now supports > adding context to any event, as well as adding a global or per-event-type > filters to control the generation of events based on the context. > > The changes are available at > https://github.com/openjdk/jdk/compare/master...luhenry:jfr-context > > # Description of a context > > A context is a map of string key and string value which are attached to > relevant JFR events. This context is installed on the current thread, and > can be snapshotted and activated on other threads. > > # Building a context > > To build a context, you first declare the keys of the context : > > ``` > > var contextKey1 = RecordingContextKey.forName("Key1"); > > ``` > > Then, to use that key to build a specific context, use the following: > > ``` > > var context = RecordingContext.where(contextKey1, "Value1").build(); > > ``` > > # Installing a context > > Building a context will also install the context on the current thread. To > uninstall the context, simply do `context.close()`. > > To capture the context and restore it on another thread, do: > > ``` > > // On the thread where the context is already installed: > > var snapshot = RecordingContext.snapshot(); > > // On the thread you want to restore/install the context: > > try (var activation = snapshot.activate()) { ... } > > ``` > > You can also use helper functions for structured concurrency: > > ``` > > RecordingContext.callWithSnapshot(o -> { ... }, snapshot); > > RecordingContext.runWithSnapshot(() -> { ... }, snapshot); > > ``` > > # Lifecycle of a context > > Let?s take a look at an example: > > ``` > > public class Program { > > private static final RecordingContextKey contextKey1 = > > RecordingContextKey.forName("Key1"); > > public static void main(String[] args) { > > try (Recording recording = new Recording()) { > > recording.start(); > > recording.enable("jdk.ThreadSleep"); > > try (RecordingContext context = > > RecordingContext.where(contextKey1, "Value1").build()) { > > ForkJoinPool pool = ForkJoinPool.commonPool(); > > final RecordingContext.Snapshot snapshot = > RecordingContext.snapshot(); > > pool.execute(() -> { > > try (var activation = snapshot.activate()) { > > Thread.sleep(1); > > } > > }); > > pool.execute(() -> { > > try (var activation = snapshot.activate()) { > > Thread.sleep(1); > > } > > }); > > pool.shutdown(); > > pool.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS); > > } > > recording.stop(); > > recording.dump(Files.createTempFile("my-recording", ".jfr")); > > } > > } > > } > > ``` > > The two `jdk.ThreadSleep` events generated are as follows: > ``` > > jdk.ThreadSleep { > > startTime = 11:06:20.336 (2021-11-12) > > duration = 1.05 ms > > time = 1.00 ms > > eventThread = "main" (javaThreadId = 1) > > stackTrace = [ > > java.lang.Thread.sleep(long) > > Program.lambda$main$0(RecordingContext$Snapshot) line: 23 > > java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec() line: > 1395 > > java.util.concurrent.ForkJoinTask.doExec() line: 373 > > java.util.concurrent.ForkJoinPool.externalHelpQuiescePool(long, > boolean) line: 2104 > > ] > > context = [ > > Key1 -> Value1, > > ] > > } > > jdk.ThreadSleep { > > startTime = 11:06:20.336 (2021-11-12) > > duration = 1.10 ms > > time = 1.00 ms > > eventThread = "ForkJoinPool.commonPool-worker-1" (javaThreadId = 18) > > stackTrace = [ > > java.lang.Thread.sleep(long) > > Program.lambda$main$0(RecordingContext$Snapshot) line: 23 > > java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec() line: > 1395 > > java.util.concurrent.ForkJoinTask.doExec() line: 373 > > java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinTask, > ForkJoinPool$WorkQueue) line: 1182 > > ] > > context = [ > > Key1 -> Value1, > > ] > > } > > ``` > > # Filtering on the context > > In order to control the generation of events, this change introduces > context filters. A filter is per-type or for all types, and is installed > globally. > > To build and install a filter, you do the following: > > ``` > > var filter = RecordingContextFilter.Config.createFilter() > > .forType(EventType.getEventType(TestEvent.class), b -> { > > b.hasEntry(contextKey1, "Value1"); > > }) > > .forAllTypes(b -> { > > b.hasKey(contextKey1); > > }) > > .build() > > RecordingContextFilter.Config.setContextFilter(filter); > > ``` > > To uninstall a filter, set it to null: > `RecordingContextFilter.Config.setContextFilter(null);` > > The currently supported operations are: > > - hasKey(key) > > - hasEntry(key, value) > > - hasContext() > > - hasNoContext() > > To guarantee a certain level of performance, I've made two tradeoffs: > > - A filter can't have custom code and can only use the supported > operations, and > > - The filters are eagerly computed on the installation of a context to > avoid matching the filter on the generation of every event. The per-type > and for all types results are stored in a map (or array in native) to > guarantee O(1) lookup time. > > From microbenchmarks, the current overhead is the following (all the JMH > numbers at [1]): > > - Generating an event with the @Context annotation and an empty context > adds ~25ns to the generation of the event > > - Each entry in the context adds ~100ns to the generation of an event > > - Setting a filter does not impact the performance of the generation of an > event > > I'll submit a draft PR in the following hours to give an easier time for > reviews and feedback. > > Thank you again very much, and looking forward to your feedback and > questions. > > Ludovic > > [1] > > Benchmark Mode Cnt Score > Error Units > > RecordingContextBenchmark.Baseline.withContext avgt 30 0.046 > ? 0.001 us/op > > RecordingContextBenchmark.Baseline.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextBenchmark.One.withContext avgt 30 0.160 > ? 0.005 us/op > > RecordingContextBenchmark.One.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextBenchmark.Three.withContext avgt 30 0.331 > ? 0.009 us/op > > RecordingContextBenchmark.Three.withoutContext avgt 30 0.022 > ? 0.001 us/op > > RecordingContextBenchmark.Two.withContext avgt 30 0.237 > ? 0.003 us/op > > RecordingContextBenchmark.Two.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Baseline.withContext avgt 30 0.048 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Baseline.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextFilterBenchmark.One.withContext avgt 30 0.154 > ? 0.003 us/op > > RecordingContextFilterBenchmark.One.withoutContext avgt 30 0.023 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Three.withContext avgt 30 0.346 > ? 0.007 us/op > > RecordingContextFilterBenchmark.Three.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Two.withContext avgt 30 0.239 > ? 0.004 us/op > > RecordingContextFilterBenchmark.Two.withoutContext avgt 30 0.021 > ? 0.001 us/op > From ludovic at datadoghq.com Fri Nov 12 16:07:55 2021 From: ludovic at datadoghq.com (Ludovic Henry) Date: Fri, 12 Nov 2021 17:07:55 +0100 Subject: RFC: JFR Recording Context In-Reply-To: References: Message-ID: The link to the draft PR: https://github.com/openjdk/jdk/pull/6368 On Fri, Nov 12, 2021 at 2:22 PM Ludovic Henry wrote: > Hello, > > As it's been a couple of months since my last update, I wanted to share > some of the progress I've made there. The TL;DR is that it now supports > adding context to any event, as well as adding a global or per-event-type > filters to control the generation of events based on the context. > > The changes are available at > https://github.com/openjdk/jdk/compare/master...luhenry:jfr-context > > # Description of a context > > A context is a map of string key and string value which are attached to > relevant JFR events. This context is installed on the current thread, and > can be snapshotted and activated on other threads. > > # Building a context > > To build a context, you first declare the keys of the context : > > ``` > > var contextKey1 = RecordingContextKey.forName("Key1"); > > ``` > > Then, to use that key to build a specific context, use the following: > > ``` > > var context = RecordingContext.where(contextKey1, "Value1").build(); > > ``` > > # Installing a context > > Building a context will also install the context on the current thread. To > uninstall the context, simply do `context.close()`. > > To capture the context and restore it on another thread, do: > > ``` > > // On the thread where the context is already installed: > > var snapshot = RecordingContext.snapshot(); > > // On the thread you want to restore/install the context: > > try (var activation = snapshot.activate()) { ... } > > ``` > > You can also use helper functions for structured concurrency: > > ``` > > RecordingContext.callWithSnapshot(o -> { ... }, snapshot); > > RecordingContext.runWithSnapshot(() -> { ... }, snapshot); > > ``` > > # Lifecycle of a context > > Let?s take a look at an example: > > ``` > > public class Program { > > private static final RecordingContextKey contextKey1 = > > RecordingContextKey.forName("Key1"); > > public static void main(String[] args) { > > try (Recording recording = new Recording()) { > > recording.start(); > > recording.enable("jdk.ThreadSleep"); > > try (RecordingContext context = > > RecordingContext.where(contextKey1, "Value1").build()) { > > ForkJoinPool pool = ForkJoinPool.commonPool(); > > final RecordingContext.Snapshot snapshot = > RecordingContext.snapshot(); > > pool.execute(() -> { > > try (var activation = snapshot.activate()) { > > Thread.sleep(1); > > } > > }); > > pool.execute(() -> { > > try (var activation = snapshot.activate()) { > > Thread.sleep(1); > > } > > }); > > pool.shutdown(); > > pool.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS); > > } > > recording.stop(); > > recording.dump(Files.createTempFile("my-recording", ".jfr")); > > } > > } > > } > > ``` > > The two `jdk.ThreadSleep` events generated are as follows: > ``` > > jdk.ThreadSleep { > > startTime = 11:06:20.336 (2021-11-12) > > duration = 1.05 ms > > time = 1.00 ms > > eventThread = "main" (javaThreadId = 1) > > stackTrace = [ > > java.lang.Thread.sleep(long) > > Program.lambda$main$0(RecordingContext$Snapshot) line: 23 > > java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec() line: > 1395 > > java.util.concurrent.ForkJoinTask.doExec() line: 373 > > java.util.concurrent.ForkJoinPool.externalHelpQuiescePool(long, > boolean) line: 2104 > > ] > > context = [ > > Key1 -> Value1, > > ] > > } > > jdk.ThreadSleep { > > startTime = 11:06:20.336 (2021-11-12) > > duration = 1.10 ms > > time = 1.00 ms > > eventThread = "ForkJoinPool.commonPool-worker-1" (javaThreadId = 18) > > stackTrace = [ > > java.lang.Thread.sleep(long) > > Program.lambda$main$0(RecordingContext$Snapshot) line: 23 > > java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec() line: > 1395 > > java.util.concurrent.ForkJoinTask.doExec() line: 373 > > java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinTask, > ForkJoinPool$WorkQueue) line: 1182 > > ] > > context = [ > > Key1 -> Value1, > > ] > > } > > ``` > > # Filtering on the context > > In order to control the generation of events, this change introduces > context filters. A filter is per-type or for all types, and is installed > globally. > > To build and install a filter, you do the following: > > ``` > > var filter = RecordingContextFilter.Config.createFilter() > > .forType(EventType.getEventType(TestEvent.class), b -> { > > b.hasEntry(contextKey1, "Value1"); > > }) > > .forAllTypes(b -> { > > b.hasKey(contextKey1); > > }) > > .build() > > RecordingContextFilter.Config.setContextFilter(filter); > > ``` > > To uninstall a filter, set it to null: > `RecordingContextFilter.Config.setContextFilter(null);` > > The currently supported operations are: > > - hasKey(key) > > - hasEntry(key, value) > > - hasContext() > > - hasNoContext() > > To guarantee a certain level of performance, I've made two tradeoffs: > > - A filter can't have custom code and can only use the supported > operations, and > > - The filters are eagerly computed on the installation of a context to > avoid matching the filter on the generation of every event. The per-type > and for all types results are stored in a map (or array in native) to > guarantee O(1) lookup time. > > From microbenchmarks, the current overhead is the following (all the JMH > numbers at [1]): > > - Generating an event with the @Context annotation and an empty context > adds ~25ns to the generation of the event > > - Each entry in the context adds ~100ns to the generation of an event > > - Setting a filter does not impact the performance of the generation of an > event > > I'll submit a draft PR in the following hours to give an easier time for > reviews and feedback. > > Thank you again very much, and looking forward to your feedback and > questions. > > Ludovic > > [1] > > Benchmark Mode Cnt Score > Error Units > > RecordingContextBenchmark.Baseline.withContext avgt 30 0.046 > ? 0.001 us/op > > RecordingContextBenchmark.Baseline.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextBenchmark.One.withContext avgt 30 0.160 > ? 0.005 us/op > > RecordingContextBenchmark.One.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextBenchmark.Three.withContext avgt 30 0.331 > ? 0.009 us/op > > RecordingContextBenchmark.Three.withoutContext avgt 30 0.022 > ? 0.001 us/op > > RecordingContextBenchmark.Two.withContext avgt 30 0.237 > ? 0.003 us/op > > RecordingContextBenchmark.Two.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Baseline.withContext avgt 30 0.048 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Baseline.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextFilterBenchmark.One.withContext avgt 30 0.154 > ? 0.003 us/op > > RecordingContextFilterBenchmark.One.withoutContext avgt 30 0.023 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Three.withContext avgt 30 0.346 > ? 0.007 us/op > > RecordingContextFilterBenchmark.Three.withoutContext avgt 30 0.021 > ? 0.001 us/op > > RecordingContextFilterBenchmark.Two.withContext avgt 30 0.239 > ? 0.004 us/op > > RecordingContextFilterBenchmark.Two.withoutContext avgt 30 0.021 > ? 0.001 us/op > From stefank at openjdk.java.net Thu Nov 18 13:36:41 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 18 Nov 2021 13:36:41 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson wrote: > I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. Retrying with correct labels. ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From eosterlund at openjdk.java.net Thu Nov 18 14:25:47 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 18 Nov 2021 14:25:47 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson wrote: > I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6454 From bchristi at openjdk.java.net Thu Nov 18 22:55:02 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 18 Nov 2021 22:55:02 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal Message-ID: Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. The CSR has been approved. An automated test build+test run passes cleanly (FWIW :D ). ------------- Commit messages: - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - Fix @since on @Deprecated for java.lang.Enum - Clarify conditions for removal of Object.finalize method - ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2 Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276447 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From jbachorik at openjdk.java.net Fri Nov 19 00:04:45 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 19 Nov 2021 00:04:45 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson wrote: > I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. Changes requested by jbachorik (Reviewer). src/hotspot/share/jfr/metadata/metadata.xml line 1037: > 1035: > 1036: > 1037: Can you add a description to the event? For anyone coming from outside it would really help to understand what this event is supposed to represent. src/jdk.jfr/share/conf/jfr/default.jfc line 778: > 776: > 777: > 778: This is just a question - do we want/need to have this event enabled for the 'low overhead profiling' setup? ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Fri Nov 19 07:50:41 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 19 Nov 2021 07:50:41 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 23:59:45 GMT, Jaroslav Bachorik wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > src/hotspot/share/jfr/metadata/metadata.xml line 1037: > >> 1035: >> 1036: >> 1037: > > Can you add a description to the event? > For anyone coming from outside it would really help to understand what this event is supposed to represent. Great idea. > src/jdk.jfr/share/conf/jfr/default.jfc line 778: > >> 776: >> 777: >> 778: > > This is just a question - do we want/need to have this event enabled for the 'low overhead profiling' setup? Yes. I always use default.jfc. The profile.jfc is creating too many allocation related events to make it usable when running with ZGC. I know that there has been some plans to fix that, but I don't know if that made it into JDK 17 or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Fri Nov 19 08:02:12 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 19 Nov 2021 08:02:12 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v2] In-Reply-To: References: Message-ID: > I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review jbachorik ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6454/files - new: https://git.openjdk.java.net/jdk/pull/6454/files/85f9b141..478c38a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6454&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6454&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6454/head:pull/6454 PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Fri Nov 19 08:49:14 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 19 Nov 2021 08:49:14 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: > I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Rename ZThreadEvent to ZThreadDebug ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6454/files - new: https://git.openjdk.java.net/jdk/pull/6454/files/478c38a4..15f4d9a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6454&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6454&range=01-02 Stats: 34 lines in 6 files changed: 0 ins; 18 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/6454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6454/head:pull/6454 PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Fri Nov 19 08:49:16 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 19 Nov 2021 08:49:16 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v2] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:02:12 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review jbachorik I discussed the naming of this event with @pliden, and we decided to rename it to make it more clear that this was only intended for debugging/development of ZGC. ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From pliden at openjdk.java.net Fri Nov 19 08:53:44 2021 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 19 Nov 2021 08:53:44 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug Looks good. ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6454 From rriggs at openjdk.java.net Fri Nov 19 17:31:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 19 Nov 2021 17:31:47 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6465 From alanb at openjdk.java.net Fri Nov 19 17:31:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Nov 2021 17:31:53 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6465 From eosterlund at openjdk.java.net Fri Nov 19 17:31:59 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 19 Nov 2021 17:31:59 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From lancea at openjdk.java.net Fri Nov 19 17:47:57 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 19 Nov 2021 17:47:57 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 18:10:09 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 18:10:09 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). src/java.base/share/classes/java/lang/Object.java line 481: > 479: * system resources or to perform other cleanup. > 480: *

> 481: * When running in a Java virtual machine in which finalization has been Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From darcy at openjdk.java.net Fri Nov 19 18:10:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 19 Nov 2021 18:10:08 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From bchristi at openjdk.java.net Fri Nov 19 18:19:10 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 19 Nov 2021 18:19:10 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung wrote: >> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. >> >> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. >> >> The CSR has been approved. >> An automated test build+test run passes cleanly (FWIW :D ). > > src/java.base/share/classes/java/lang/Object.java line 481: > >> 479: * system resources or to perform other cleanup. >> 480: *

>> 481: * When running in a Java virtual machine in which finalization has been > > Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal. That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 19:10:11 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 19:10:11 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 19:10:12 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 19:10:12 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> References: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> Message-ID: On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian wrote: >> src/java.base/share/classes/java/lang/Object.java line 481: >> >>> 479: * system resources or to perform other cleanup. >>> 480: *

>>> 481: * When running in a Java virtual machine in which finalization has been >> >> Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. > > The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal. That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS. Thanks for pointing out that the CSR for JDK-8276422 ("Add command-line option to disable finalization") includes the change of the SE Platform Spec and JLS to allow an implementation for finalization to be disabled. This makes senses now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From serb at openjdk.java.net Fri Nov 19 20:16:12 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 19 Nov 2021 20:16:12 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From jbachorik at openjdk.java.net Sat Nov 20 12:10:16 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Sat, 20 Nov 2021 12:10:16 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: <1ar4WRPlOYCGpmV-ROI9LI7CoX-2YS_XuLnF7Zdgeik=.89d41895-8ca6-4d50-bc21-5a6f4caf0302@github.com> On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug Marked as reviewed by jbachorik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From mgronlun at openjdk.java.net Mon Nov 22 10:28:11 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 22 Nov 2021 10:28:11 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug What's the overhead of this event being enabled in default.jfc with threshold=0? Do all users really need to have this experimental event enabled by default when running ZGC? ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Mon Nov 22 10:46:08 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 22 Nov 2021 10:46:08 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug > The overhead should be virtually zero, since no event is sent. Having this turned off by default makes this feature more annoying to use. Is this causing problems for the users? ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From mgronlun at openjdk.java.net Mon Nov 22 10:56:08 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 22 Nov 2021 10:56:08 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug Ah. So "debug" means only used in "development builds" of the VM? In that case, there is no problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Mon Nov 22 10:56:08 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 22 Nov 2021 10:56:08 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug > No, this is more likely to be used in release builds to identify and measure performance issues in ZGC. It is intended for us during debugging and development of various features in ZGC. Think of this similar to the UseNewCode flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From mgronlun at openjdk.java.net Mon Nov 22 11:01:11 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 22 Nov 2021 11:01:11 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Wed Nov 24 08:28:13 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 24 Nov 2021 08:28:13 GMT Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency measurements [v3] In-Reply-To: References: Message-ID: <4RY4BtQy2QUlT4oPo661nFIpzGZk5cgEsPtHNHEIf-s=.631befb8-ddcd-4d84-81bb-107a2485fd01@github.com> On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson wrote: >> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Rename ZThreadEvent to ZThreadDebug Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From stefank at openjdk.java.net Wed Nov 24 08:28:14 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 24 Nov 2021 08:28:14 GMT Subject: Integrated: 8277397: ZGC: Add JFR event for temporary latency measurements In-Reply-To: References: Message-ID: <5iysj9BCFn72qN-D-QuMv9iuCvMHlqLLMXao4sd6Hvw=.e4339dbf-3660-4265-81a1-b0ae6772a029@github.com> On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson wrote: > I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging. This pull request has now been integrated. Changeset: 712b8756 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/712b8756828c88d4f71292d19fddb598d188c429 Stats: 43 lines in 6 files changed: 37 ins; 0 del; 6 mod 8277397: ZGC: Add JFR event for temporary latency measurements Reviewed-by: eosterlund, jbachorik, pliden, mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/6454 From egahlin at openjdk.java.net Fri Nov 26 10:57:25 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 26 Nov 2021 10:57:25 GMT Subject: RFR: 8276685: Malformed Javadoc inline tags in JDK source in /jdk/management/jfr/RecordingInfo.java Message-ID: <3ud8doLj5w1hhtW_j42ZG_Kr9q_aW0KrqylWYCJtTy4=.14f53525-fc20-46f7-b262-0ec64416285c@github.com> Hi, Could I have review of this Javadoc fix. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/6573/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6573&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276685 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6573.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6573/head:pull/6573 PR: https://git.openjdk.java.net/jdk/pull/6573 From mgronlun at openjdk.java.net Fri Nov 26 12:19:03 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 26 Nov 2021 12:19:03 GMT Subject: RFR: 8276685: Malformed Javadoc inline tags in JDK source in /jdk/management/jfr/RecordingInfo.java In-Reply-To: <3ud8doLj5w1hhtW_j42ZG_Kr9q_aW0KrqylWYCJtTy4=.14f53525-fc20-46f7-b262-0ec64416285c@github.com> References: <3ud8doLj5w1hhtW_j42ZG_Kr9q_aW0KrqylWYCJtTy4=.14f53525-fc20-46f7-b262-0ec64416285c@github.com> Message-ID: On Fri, 26 Nov 2021 10:45:48 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of this Javadoc fix. > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6573 From egahlin at openjdk.java.net Fri Nov 26 19:17:08 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 26 Nov 2021 19:17:08 GMT Subject: Integrated: 8276685: Malformed Javadoc inline tags in JDK source in /jdk/management/jfr/RecordingInfo.java In-Reply-To: <3ud8doLj5w1hhtW_j42ZG_Kr9q_aW0KrqylWYCJtTy4=.14f53525-fc20-46f7-b262-0ec64416285c@github.com> References: <3ud8doLj5w1hhtW_j42ZG_Kr9q_aW0KrqylWYCJtTy4=.14f53525-fc20-46f7-b262-0ec64416285c@github.com> Message-ID: On Fri, 26 Nov 2021 10:45:48 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of this Javadoc fix. > > Thanks > Erik This pull request has now been integrated. Changeset: b9eb532d Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/b9eb532de20be7c2c18a654a23dcc8dd66654049 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8276685: Malformed Javadoc inline tags in JDK source in /jdk/management/jfr/RecordingInfo.java Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/6573 From duke at openjdk.java.net Mon Nov 29 10:54:10 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 29 Nov 2021 10:54:10 GMT Subject: Integrated: 8275241: Unused ArrayList is created in RequestEngine.addHooks In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 07:48:10 GMT, Andrey Turbanov wrote: > Local `ArrayList` is created in a method `RequestEngine.addHooks`. Elements are added to it, but then content is unused. Seems leftovers from some refactoring. > Found by IntelliJ IDEA inspection "Mismatched query and update of collection" This pull request has now been integrated. Changeset: 37de4422 Author: Andrey Turbanov Committer: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/37de442269e8c14e0a112e26a8cbb63e12dec9e7 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8275241: Unused ArrayList is created in RequestEngine.addHooks Reviewed-by: egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/5629 From egahlin at openjdk.java.net Mon Nov 29 14:45:09 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 29 Nov 2021 14:45:09 GMT Subject: RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect [v4] In-Reply-To: References: <5m_Yf8JSkmKFMJ9c7bm7jltStp7egUG6TF05zn0OPVE=.b4abc90b-d623-422f-826d-38a39bd24bf8@github.com> Message-ID: On Tue, 26 Oct 2021 05:22:42 GMT, Yasumasa Suenaga wrote: >> This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949). >> I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java . >> >> I've tested this change with all jdk/jfr tests on Linux x64, and they works fine. >> @egahlin @mgronlun Can you run Mach5 tests with this change? > > Yasumasa Suenaga 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 six additional commits since the last revision: > > - Add dumppath to JFR.configure dcmd > - Add "\n" after printing exception > - Merge remote-tracking branch 'upstream/master' into JDK-8275375-2 > - Propagate IOException at setDumpPath() to the caller > - Refactoring setDumpPath related code > - 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6000 From duke at openjdk.java.net Tue Nov 30 07:27:27 2021 From: duke at openjdk.java.net (xpbob) Date: Tue, 30 Nov 2021 07:27:27 GMT Subject: RFR: 8277930: Add unsafe allocation event to jfr [v4] In-Reply-To: References: Message-ID: > Unsafe is used in many Java frameworks. > When the framework has a unsafe memory leak , there is no way to know what code is causing it. > Add unsafe allocation event to jfr. > Records the size and stack allocated. > This event is off by default xpbob has updated the pull request incrementally with one additional commit since the last revision: remove whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6591/files - new: https://git.openjdk.java.net/jdk/pull/6591/files/f883847f..790cc817 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6591&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6591&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6591/head:pull/6591 PR: https://git.openjdk.java.net/jdk/pull/6591 From duke at openjdk.java.net Tue Nov 30 08:00:11 2021 From: duke at openjdk.java.net (xpbob) Date: Tue, 30 Nov 2021 08:00:11 GMT Subject: RFR: 8277930: Add unsafe allocation event to jfr [v4] In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 07:27:27 GMT, xpbob wrote: >> Unsafe is used in many Java frameworks. >> When the framework has a unsafe memory leak , there is no way to know what code is causing it. >> Add unsafe allocation event to jfr. >> Records the size and stack allocated. >> This event is off by default > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > remove whitespace Thanks I added 3 events |event|stack|addr|size| |-|-|-|-| |Allocation|true|alloc|true| |Reallocate|true|before realloc,after realloc|true| |Free|true|free addr|false| ------------- PR: https://git.openjdk.java.net/jdk/pull/6591 From duke at openjdk.java.net Tue Nov 30 11:04:44 2021 From: duke at openjdk.java.net (xpbob) Date: Tue, 30 Nov 2021 11:04:44 GMT Subject: RFR: 8277930: Add unsafe allocation event to jfr [v5] In-Reply-To: References: Message-ID: > Unsafe is used in many Java frameworks. > When the framework has a unsafe memory leak , there is no way to know what code is causing it. > Add unsafe allocation event to jfr. > Records the size and stack allocated. > This event is off by default xpbob 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 five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8277930 - remove whitespace - add free and Reallocate event - Merge branch 'openjdk:master' into JDK-8277930 - 8277930: Add unsafe allocation event to jfr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6591/files - new: https://git.openjdk.java.net/jdk/pull/6591/files/790cc817..b09c744d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6591&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6591&range=03-04 Stats: 163 lines in 10 files changed: 58 ins; 83 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/6591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6591/head:pull/6591 PR: https://git.openjdk.java.net/jdk/pull/6591 From egahlin at openjdk.java.net Tue Nov 30 11:37:13 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 30 Nov 2021 11:37:13 GMT Subject: RFR: 8277930: Add unsafe allocation event to jfr [v5] In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 11:04:44 GMT, xpbob wrote: >> Unsafe is used in many Java frameworks. >> When the framework has a unsafe memory leak , there is no way to know what code is causing it. >> Add unsafe allocation event to jfr. >> Records the size and stack allocated. >> This event is off by default > > xpbob 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 five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8277930 > - remove whitespace > - add free and Reallocate event > - Merge branch 'openjdk:master' into JDK-8277930 > - 8277930: Add unsafe allocation event to jfr What about overhead (if JFR is disabled)? This looks like it could be a hot path for some applications. ------------- PR: https://git.openjdk.java.net/jdk/pull/6591 From mgronlun at openjdk.java.net Tue Nov 30 11:52:24 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 30 Nov 2021 11:52:24 GMT Subject: RFR: 8277194: applications/runthese/RunThese30M.java crashes with jfrSymbolTable.cpp:305 assert(_instance != null) Message-ID: <_lO_sT12EsGSDs5Rrx27T6uaWWzwm3u6UDj-6TCQ050=.d5e39d0e-9d16-436c-b409-07a7b9506d2e@github.com> Greetings, please help review this change set to add a missing enabled check for the event EventFinalizerStatistics, lack of which is causing problems when code not running a JFR recording is accessing uninitialized data as part of class unloading. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8277194 Changes: https://git.openjdk.java.net/jdk/pull/6611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277194 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6611/head:pull/6611 PR: https://git.openjdk.java.net/jdk/pull/6611