From github.com+5010047+kelthuzadx at openjdk.java.net Tue Jan 5 02:55:04 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Tue, 5 Jan 2021 02:55:04 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording Message-ID: Hi all, May I please have a review for this minor patch? It simplifies the use of subcommand `metadata` of jfr tool. Recording file is no longer mandatory, users can directly use `jfr metadata` to output JDK builtin meta information. As JDK-8256156 mentioned, it also supports events and categories filters: $ jfr metadata $ jfr metadata recording.jfr # compatible $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr $ jfr metadata --categories GC,Detailed $ jfr metadata --categories GC,Detailed recording.jfr ------------- Commit messages: - Allow jfr tool to show metadata without a recording Changes: https://git.openjdk.java.net/jdk/pull/1904/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256156 Stats: 151 lines in 5 files changed: 131 ins; 8 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1904/head:pull/1904 PR: https://git.openjdk.java.net/jdk/pull/1904 From egahlin at openjdk.java.net Tue Jan 5 11:58:07 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 5 Jan 2021 11:58:07 GMT Subject: [jdk16] RFR: 8257906: JFR: RecordingStream leaks memory Message-ID: Backport of JDK-8258478: JFR: RecordingStream leaks memory ------------- Commit messages: - initial Changes: https://git.openjdk.java.net/jdk16/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=81&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257906 Stats: 55 lines in 4 files changed: 52 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk16/pull/81 From mgronlun at openjdk.java.net Tue Jan 5 13:00:58 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 5 Jan 2021 13:00:58 GMT Subject: [jdk16] RFR: 8257906: JFR: RecordingStream leaks memory In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:52:27 GMT, Erik Gahlin wrote: > Backport of JDK-8258478: JFR: RecordingStream leaks memory Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/81 From egahlin at openjdk.java.net Tue Jan 5 13:42:59 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 5 Jan 2021 13:42:59 GMT Subject: [jdk16] Integrated: 8257906: JFR: RecordingStream leaks memory In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 11:52:27 GMT, Erik Gahlin wrote: > Backport of JDK-8258478: JFR: RecordingStream leaks memory This pull request has now been integrated. Changeset: bbc2e951 Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk16/commit/bbc2e951 Stats: 55 lines in 4 files changed: 52 ins; 1 del; 2 mod 8257906: JFR: RecordingStream leaks memory Reviewed-by: mgronlun Backport-of: 3c6648501589bf36945340cb1e82c833ebd7485d ------------- PR: https://git.openjdk.java.net/jdk16/pull/81 From egahlin at openjdk.java.net Tue Jan 5 20:27:05 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 5 Jan 2021 20:27:05 GMT Subject: [jdk16] RFR: 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count Message-ID: Hi, Could I have review of a test fix? Tests fails intermittently, most likely due to JFR not able to keep up with the high event rate. Purpose of the test is not to stress JFR, so events are now only emitted from one thread. I also changed the assert, so it is easier to see how much off the count is. Tested by running it 100 times without failure. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk16/pull/87/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=87&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250903 Stats: 14 lines in 1 file changed: 0 ins; 9 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/87/head:pull/87 PR: https://git.openjdk.java.net/jdk16/pull/87 From mgronlun at openjdk.java.net Wed Jan 6 18:59:03 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 6 Jan 2021 18:59:03 GMT Subject: [jdk16] RFR: 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 20:20:43 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of a test fix? > > Tests fails intermittently, most likely due to JFR not able to keep up with the high event rate. Purpose of the test is not to stress JFR, so events are now only emitted from one thread. I also changed the assert, so it is easier to see how much off the count is. > > Tested by running it 100 times without failure. > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). test/jdk/jdk/jfr/javaagent/EventEmitterAgent.java line 38: > 36: import jdk.test.lib.jfr.EventNames; > 37: > 38: // Java agent that emits in multiple threads Update this comment? ------------- PR: https://git.openjdk.java.net/jdk16/pull/87 From github.com+3854321+carterkozak at openjdk.java.net Thu Jan 7 04:25:03 2021 From: github.com+3854321+carterkozak at openjdk.java.net (Carter Kozak) Date: Thu, 7 Jan 2021 04:25:03 GMT Subject: RFR: 8259354 Fix race condition in AbstractEventStream.nextThreadName Message-ID: The result of `AtomicLong.incrementAndGet()` is used rather than incrementing the long and reading its value separately. The previous approach allowed for the static counter to be incremented several times before any caller read the value, resulting in several callers with the same value. ------------- Commit messages: - 8259354: Fix race condition in AbstractEventStream.nextThreadName Changes: https://git.openjdk.java.net/jdk/pull/1871/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1871&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259354 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1871.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1871/head:pull/1871 PR: https://git.openjdk.java.net/jdk/pull/1871 From egahlin at openjdk.java.net Thu Jan 7 04:25:03 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 7 Jan 2021 04:25:03 GMT Subject: RFR: 8259354 Fix race condition in AbstractEventStream.nextThreadName In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 21:11:33 GMT, Carter Kozak wrote: > The result of `AtomicLong.incrementAndGet()` is used rather than > incrementing the long and reading its value separately. The > previous approach allowed for the static counter to be incremented > several times before any caller read the value, resulting in > several callers with the same value. Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1871 From github.com+3854321+carterkozak at openjdk.java.net Thu Jan 7 04:25:04 2021 From: github.com+3854321+carterkozak at openjdk.java.net (Carter Kozak) Date: Thu, 7 Jan 2021 04:25:04 GMT Subject: RFR: 8259354 Fix race condition in AbstractEventStream.nextThreadName In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 21:11:33 GMT, Carter Kozak wrote: > The result of `AtomicLong.incrementAndGet()` is used rather than > incrementing the long and reading its value separately. The > previous approach allowed for the static counter to be incremented > several times before any caller read the value, resulting in > several callers with the same value. Hello @egahlin, it looks like you were involved with the original implementation. Is there any chance you could help me with the ticket and review process for this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/1871 From egahlin at openjdk.java.net Thu Jan 7 04:25:04 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 7 Jan 2021 04:25:04 GMT Subject: RFR: 8259354 Fix race condition in AbstractEventStream.nextThreadName In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 03:46:45 GMT, Erik Gahlin wrote: >> The result of `AtomicLong.incrementAndGet()` is used rather than >> incrementing the long and reading its value separately. The >> previous approach allowed for the static counter to be incremented >> several times before any caller read the value, resulting in >> several callers with the same value. > > Marked as reviewed by egahlin (Reviewer). I created a tricket: https://bugs.openjdk.java.net/browse/JDK-8259354 Have you run the tests in test/jdk/jdk/jfr? ------------- PR: https://git.openjdk.java.net/jdk/pull/1871 From github.com+3854321+carterkozak at openjdk.java.net Thu Jan 7 04:34:56 2021 From: github.com+3854321+carterkozak at openjdk.java.net (Carter Kozak) Date: Thu, 7 Jan 2021 04:34:56 GMT Subject: RFR: 8259354 Fix race condition in AbstractEventStream.nextThreadName In-Reply-To: References: Message-ID: <80nuZsrO0HFY8cHGkx4TU030GsLjy_BLAS0Wz2Q_1LY=.09346ef0-6e66-4f8e-ad48-34eefae64c1e@github.com> On Thu, 7 Jan 2021 04:00:26 GMT, Erik Gahlin wrote: >> Marked as reviewed by egahlin (Reviewer). > > I created a tricket: > > https://bugs.openjdk.java.net/browse/JDK-8259354 > > Have you run the tests in test/jdk/jdk/jfr? Thank you, I've updated the commit message with the ticket information. > Have you run the tests in test/jdk/jdk/jfr? Yes, all tests pass. ------------- PR: https://git.openjdk.java.net/jdk/pull/1871 From egahlin at openjdk.java.net Thu Jan 7 06:13:56 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 7 Jan 2021 06:13:56 GMT Subject: RFR: 8259354 Fix race condition in AbstractEventStream.nextThreadName In-Reply-To: <80nuZsrO0HFY8cHGkx4TU030GsLjy_BLAS0Wz2Q_1LY=.09346ef0-6e66-4f8e-ad48-34eefae64c1e@github.com> References: <80nuZsrO0HFY8cHGkx4TU030GsLjy_BLAS0Wz2Q_1LY=.09346ef0-6e66-4f8e-ad48-34eefae64c1e@github.com> Message-ID: On Thu, 7 Jan 2021 04:31:42 GMT, Carter Kozak wrote: >> I created a tricket: >> >> https://bugs.openjdk.java.net/browse/JDK-8259354 >> >> Have you run the tests in test/jdk/jdk/jfr? > > Thank you, I've updated the commit message with the ticket information. > >> Have you run the tests in test/jdk/jdk/jfr? > > Yes, all tests pass. Thanks for you contribution! ------------- PR: https://git.openjdk.java.net/jdk/pull/1871 From github.com+3854321+carterkozak at openjdk.java.net Thu Jan 7 06:13:57 2021 From: github.com+3854321+carterkozak at openjdk.java.net (Carter Kozak) Date: Thu, 7 Jan 2021 06:13:57 GMT Subject: Integrated: 8259354 Fix race condition in AbstractEventStream.nextThreadName In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 21:11:33 GMT, Carter Kozak wrote: > The result of `AtomicLong.incrementAndGet()` is used rather than > incrementing the long and reading its value separately. The > previous approach allowed for the static counter to be incremented > several times before any caller read the value, resulting in > several callers with the same value. This pull request has now been integrated. Changeset: 81c06242 Author: Carter Kozak Committer: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/81c06242 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8259354: Fix race condition in AbstractEventStream.nextThreadName Reviewed-by: egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/1871 From egahlin at openjdk.java.net Thu Jan 7 12:25:12 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 7 Jan 2021 12:25:12 GMT Subject: [jdk16] RFR: 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I have review of a test fix? > > Tests fails intermittently, most likely due to JFR not able to keep up with the high event rate. Purpose of the test is not to stress JFR, so events are now only emitted from one thread. I also changed the assert, so it is easier to see how much off the count is. > > Tested by running it 100 times without failure. > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Update comment ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/87/files - new: https://git.openjdk.java.net/jdk16/pull/87/files/5271aab2..4bb65d1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=87&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=87&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/87/head:pull/87 PR: https://git.openjdk.java.net/jdk16/pull/87 From egahlin at openjdk.java.net Thu Jan 7 12:25:12 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 7 Jan 2021 12:25:12 GMT Subject: [jdk16] RFR: 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count [v2] In-Reply-To: References: Message-ID: <-10LYba7q4IPpgGC3wHaLv4wn2WXYwnkxsSLa-uOmR0=.aa6811f1-a243-49f6-811d-b9f14e882004@github.com> On Wed, 6 Jan 2021 18:55:29 GMT, Markus Gr?nlund wrote: >> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment > > test/jdk/jdk/jfr/javaagent/EventEmitterAgent.java line 38: > >> 36: import jdk.test.lib.jfr.EventNames; >> 37: >> 38: // Java agent that emits in multiple threads > > Update this comment? Fixed ------------- PR: https://git.openjdk.java.net/jdk16/pull/87 From egahlin at openjdk.java.net Thu Jan 7 12:25:13 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 7 Jan 2021 12:25:13 GMT Subject: [jdk16] Integrated: 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 20:20:43 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of a test fix? > > Tests fails intermittently, most likely due to JFR not able to keep up with the high event rate. Purpose of the test is not to stress JFR, so events are now only emitted from one thread. I also changed the assert, so it is easier to see how much off the count is. > > Tested by running it 100 times without failure. > > Thanks > Erik This pull request has now been integrated. Changeset: 4a478b8a Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk16/commit/4a478b8a Stats: 15 lines in 1 file changed: 0 ins; 9 del; 6 mod 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk16/pull/87 From qingfeng.yy at alibaba-inc.com Fri Jan 8 02:13:21 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Fri, 08 Jan 2021 10:13:21 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODI1NjE1NjogSkZSOiBBbGxvdyAnamZyJyB0b29sIHRvIHNob3cgbWV0YWRh?= =?UTF-8?B?dGEgd2l0aG91dCBhIHJlY29yZGluZw==?= In-Reply-To: References: Message-ID: <8109c571-5454-44a9-971c-51c363301c6c.qingfeng.yy@alibaba-inc.com> Happy New Year. Can anyone help reviewing this patch? ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 ------------------------------------------------------------------ From:Yang Yi Send Time:2021 Jan. 5 (Tue.) 10:55 To:hotspot-jfr-dev Subject:RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording Hi all, May I please have a review for this minor patch? It simplifies the use of subcommand `metadata` of jfr tool. Recording file is no longer mandatory, users can directly use `jfr metadata` to output JDK builtin meta information. As JDK-8256156 mentioned, it also supports events and categories filters: $ jfr metadata $ jfr metadata recording.jfr # compatible $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr $ jfr metadata --categories GC,Detailed $ jfr metadata --categories GC,Detailed recording.jfr ------------- Commit messages: - Allow jfr tool to show metadata without a recording Changes: https://git.openjdk.java.net/jdk/pull/1904/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256156 Stats: 151 lines in 5 files changed: 131 ins; 8 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1904/head:pull/1904 PR: https://git.openjdk.java.net/jdk/pull/1904 From egahlin at openjdk.java.net Fri Jan 8 04:28:59 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 8 Jan 2021 04:28:59 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording In-Reply-To: References: Message-ID: On Tue, 29 Dec 2020 07:44:36 GMT, Yang Yi wrote: > Hi all, > > May I please have a review for this minor patch? > > It simplifies the use of subcommand `metadata` of jfr tool. Recording > file is no longer mandatory, users can directly use `jfr metadata` to > output JDK builtin meta information. As JDK-8256156 mentioned, it also > supports events and categories filters: > $ jfr metadata > $ jfr metadata recording.jfr # compatible > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr > $ jfr metadata --categories GC,Detailed > $ jfr metadata --categories GC,Detailed recording.jfr src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 200: > 198: prettyWriter.flush(true); > 199: } > 200: } catch (Exception e) { This error handling seems inadequate. If there is IOException, it still makes sense to get proper message, and not a stack trace src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 183: > 181: } > 182: if (foundEventFilter) { > 183: if (acceptedEvents.contains(type.getName())) { I would expect filtering for the metadata command to work like the 'print' command (accepting acronyms, wildcards etc.) src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 211: > 209: String[] categories = categoryAnno.value(); > 210: for (String category : categories) { > 211: if (categoryNames.contains(category)) { I would expect filtering for the metadata command to work like the 'print' command (wildcards etc.) src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 231: > 229: return tmp; > 230: } catch (Exception e) { > 231: // ignored since recording file for jfr metadata is optional Inadequate error handling. If there is something wrong with the file (permission etc) I like to know it, and not get the event types for the current JVM. test/jdk/jdk/jfr/tool/TestMetadata.java line 94: > 92: } > 93: } > 94: List eventTypes = TypeLibrary.getInstance().getTypes(); I think it would be better to use public API (FlightRecorder.getEventTypes()) instead of calling internals. src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 107: > 105: } > 106: > 107: @Override I think ine would like to get similar help as for the ''print' command when it comes to filtering. ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 8 09:34:09 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 8 Jan 2021 09:34:09 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording [v2] In-Reply-To: References: Message-ID: > Hi all, > > May I please have a review for this minor patch? > > It simplifies the use of subcommand `metadata` of jfr tool. Recording > file is no longer mandatory, users can directly use `jfr metadata` to > output JDK builtin meta information. As JDK-8256156 mentioned, it also > supports events and categories filters: > $ jfr metadata > $ jfr metadata recording.jfr # compatible > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr > $ jfr metadata --categories GC,Detailed > $ jfr metadata --categories GC,Detailed recording.jfr Yang Yi 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: Allow jfr tool to show metadata without a recording ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1904/files - new: https://git.openjdk.java.net/jdk/pull/1904/files/ca42a73a..b3c2ea58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=00-01 Stats: 378 lines in 6 files changed: 202 ins; 141 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1904/head:pull/1904 PR: https://git.openjdk.java.net/jdk/pull/1904 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 8 09:52:09 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 8 Jan 2021 09:52:09 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording [v3] In-Reply-To: References: Message-ID: <7QK8f5n84MwiIqeOjmjDheqDZdqTipiHNuBTTSaJiaU=.b4825803-b7f6-48df-b34c-85b3d9866079@github.com> > Hi all, > > May I please have a review for this minor patch? > > It simplifies the use of subcommand `metadata` of jfr tool. Recording > file is no longer mandatory, users can directly use `jfr metadata` to > output JDK builtin meta information. As JDK-8256156 mentioned, it also > supports events and categories filters: > $ jfr metadata > $ jfr metadata recording.jfr # compatible > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr > $ jfr metadata --categories GC,Detailed > $ jfr metadata --categories GC,Detailed recording.jfr Yang Yi 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: Allow jfr tool to show metadata without a recording ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1904/files - new: https://git.openjdk.java.net/jdk/pull/1904/files/b3c2ea58..81a61405 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=01-02 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1904/head:pull/1904 PR: https://git.openjdk.java.net/jdk/pull/1904 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 8 10:08:06 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 8 Jan 2021 10:08:06 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording [v4] In-Reply-To: References: Message-ID: > Hi all, > > May I please have a review for this minor patch? > > It simplifies the use of subcommand `metadata` of jfr tool. Recording > file is no longer mandatory, users can directly use `jfr metadata` to > output JDK builtin meta information. As JDK-8256156 mentioned, it also > supports events and categories filters: > $ jfr metadata > $ jfr metadata recording.jfr # compatible > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr > $ jfr metadata --categories GC,Detailed > $ jfr metadata --categories GC,Detailed recording.jfr Yang Yi 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: Allow jfr tool to show metadata without a recording ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1904/files - new: https://git.openjdk.java.net/jdk/pull/1904/files/81a61405..d43684e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1904&range=02-03 Stats: 19 lines in 2 files changed: 12 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1904/head:pull/1904 PR: https://git.openjdk.java.net/jdk/pull/1904 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 8 10:08:07 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 8 Jan 2021 10:08:07 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording In-Reply-To: References: Message-ID: <93mX8mx_d2lQSIAmAKcNmWRDLTG1DmEX9VcHXcJlgsY=.e2d3849c-58c2-401a-8f5e-a1d2169e276a@github.com> On Tue, 29 Dec 2020 07:44:36 GMT, Yang Yi wrote: > Hi all, > > May I please have a review for this minor patch? > > It simplifies the use of subcommand `metadata` of jfr tool. Recording > file is no longer mandatory, users can directly use `jfr metadata` to > output JDK builtin meta information. As JDK-8256156 mentioned, it also > supports events and categories filters: > $ jfr metadata > $ jfr metadata recording.jfr # compatible > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd > $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr > $ jfr metadata --categories GC,Detailed > $ jfr metadata --categories GC,Detailed recording.jfr @egahlin Hi Erik, I have updated my patch according to your review comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 8 10:08:10 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 8 Jan 2021 10:08:10 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording [v4] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 04:15:05 GMT, Erik Gahlin wrote: >> Yang Yi 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: >> >> Allow jfr tool to show metadata without a recording > > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 200: > >> 198: prettyWriter.flush(true); >> 199: } >> 200: } catch (Exception e) { > > This error handling seems inadequate. If there is IOException, it still makes sense to get proper message, and not a stack trace Fixed > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 183: > >> 181: } >> 182: if (foundEventFilter) { >> 183: if (acceptedEvents.contains(type.getName())) { > > I would expect filtering for the metadata command to work like the 'print' command (accepting acronyms, wildcards etc.) Added. > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 211: > >> 209: String[] categories = categoryAnno.value(); >> 210: for (String category : categories) { >> 211: if (categoryNames.contains(category)) { > > I would expect filtering for the metadata command to work like the 'print' command (wildcards etc.) Added. > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 241: > > > Inadequate error handling. If there is something wrong with the file (permission etc) I like to know it, and not get the event types for the current JVM. It would not swallow the exception now. > test/jdk/jdk/jfr/tool/TestMetadata.java line 94: > >> 92: } >> 93: } >> 94: List eventTypes = TypeLibrary.getInstance().getTypes(); > > I think it would be better to use public API (FlightRecorder.getEventTypes()) instead of calling internals. Changed. > src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java line 110: > >> 108: public List getOptionSyntax() { >> 109: List list = new ArrayList<>(); >> 110: list.add("[--categories ]"); > > I think ine would like to get similar help as for the ''print' command when it comes to filtering. Added. ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From egahlin at openjdk.java.net Fri Jan 8 10:42:55 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 8 Jan 2021 10:42:55 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording In-Reply-To: <93mX8mx_d2lQSIAmAKcNmWRDLTG1DmEX9VcHXcJlgsY=.e2d3849c-58c2-401a-8f5e-a1d2169e276a@github.com> References: <93mX8mx_d2lQSIAmAKcNmWRDLTG1DmEX9VcHXcJlgsY=.e2d3849c-58c2-401a-8f5e-a1d2169e276a@github.com> Message-ID: On Fri, 8 Jan 2021 10:04:58 GMT, Yang Yi wrote: >> Hi all, >> >> May I please have a review for this minor patch? >> >> It simplifies the use of subcommand `metadata` of jfr tool. Recording >> file is no longer mandatory, users can directly use `jfr metadata` to >> output JDK builtin meta information. As JDK-8256156 mentioned, it also >> supports events and categories filters: >> $ jfr metadata >> $ jfr metadata recording.jfr # compatible >> $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd >> $ jfr metadata --events jdk.ThreadStart,jdk.ThreadEnd recording.jfr >> $ jfr metadata --categories GC,Detailed >> $ jfr metadata --categories GC,Detailed recording.jfr > > @egahlin Hi Erik, I have updated my patch according to your review comments. You need to add a CSR as well to the bug report, where the syntax etc. is described. https://bugs.openjdk.java.net/browse/JDK-8205517 Do you have a JIRA account? ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 8 11:52:54 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 8 Jan 2021 11:52:54 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording In-Reply-To: References: <93mX8mx_d2lQSIAmAKcNmWRDLTG1DmEX9VcHXcJlgsY=.e2d3849c-58c2-401a-8f5e-a1d2169e276a@github.com> Message-ID: <-FO81DUPZRkbDNrHru0yn0clNG9pGiRQ_4zL8H1iRFY=.768d9c79-312c-4657-b57d-1bc7b58d4472@github.com> On Fri, 8 Jan 2021 10:40:34 GMT, Erik Gahlin wrote: >> @egahlin Hi Erik, I have updated my patch according to your review comments. > > You need to add a CSR as well to the bug report, where the syntax etc. is described. > > https://bugs.openjdk.java.net/browse/JDK-8205517 > > Do you have a JIRA account? I don't have an account. I just ask my colleague to help to create a CSR on behalf of me, it has been referred to original JDK bug. ------------- CSR: https://bugs.openjdk.java.net/browse/JDK-8259479 ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From egahlin at openjdk.java.net Fri Jan 8 12:04:57 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 8 Jan 2021 12:04:57 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording In-Reply-To: <-FO81DUPZRkbDNrHru0yn0clNG9pGiRQ_4zL8H1iRFY=.768d9c79-312c-4657-b57d-1bc7b58d4472@github.com> References: <93mX8mx_d2lQSIAmAKcNmWRDLTG1DmEX9VcHXcJlgsY=.e2d3849c-58c2-401a-8f5e-a1d2169e276a@github.com> <-FO81DUPZRkbDNrHru0yn0clNG9pGiRQ_4zL8H1iRFY=.768d9c79-312c-4657-b57d-1bc7b58d4472@github.com> Message-ID: On Fri, 8 Jan 2021 11:50:10 GMT, Yang Yi wrote: >> You need to add a CSR as well to the bug report, where the syntax etc. is described. >> >> https://bugs.openjdk.java.net/browse/JDK-8205517 >> >> Do you have a JIRA account? > > I don't have an account. I just ask my colleague to help to create a CSR on behalf of me, it has been referred to original JDK bug. > > ------------- > CSR: https://bugs.openjdk.java.net/browse/JDK-8259479 Thanks. I will make some changes and review it later today. ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From egahlin at openjdk.java.net Fri Jan 8 16:39:54 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 8 Jan 2021 16:39:54 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording In-Reply-To: References: <93mX8mx_d2lQSIAmAKcNmWRDLTG1DmEX9VcHXcJlgsY=.e2d3849c-58c2-401a-8f5e-a1d2169e276a@github.com> <-FO81DUPZRkbDNrHru0yn0clNG9pGiRQ_4zL8H1iRFY=.768d9c79-312c-4657-b57d-1bc7b58d4472@github.com> Message-ID: On Fri, 8 Jan 2021 12:01:58 GMT, Erik Gahlin wrote: >> I don't have an account. I just ask my colleague to help to create a CSR on behalf of me, it has been referred to original JDK bug. >> >> ------------- >> CSR: https://bugs.openjdk.java.net/browse/JDK-8259479 > > Thanks. I will make some changes and review it later today. I have reviewed the CSR, you can finalize it. Once approved, I will go over the code and do a final review. Please ping me if I forget. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From ysuenaga at openjdk.java.net Tue Jan 12 07:01:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 12 Jan 2021 07:01:57 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: On Mon, 21 Dec 2020 01:33:58 GMT, Yasumasa Suenaga wrote: >> I think there is a use case for getting an event when an OOM occurs, but the long term plan is to change so that a jdk.JavaErrorThrow is emitted when the exception is thrown, not when the object is allocated. When that is fixed, it will take care of OOME automatically - at all places. I think it is confusing for users to not get an event at every OOME and users/customers will file bugs. > > @egahlin OOME from JVM will not be reported because they are instantiated at JVM init stage and are kept in `Universe`, so they cannot be handled in `ThrowableTracer::traceError`. > We can trace OOMEs which are happened in Java code at `ThrowableTracer::traceError`. However I'm not sure where the event should be handled in. > > For sake of simply, I want to add `jdk.OutOfMemoryError` event to `jdk.jfr` module as a Java class, and I want to emit it from `ThrowableTracer::traceError`, however it duplicates with a definition in JVM. > OTOH we can implement to emit event from `ThrowableTracer::traceError` via `JVM` class, however need to add API to emit events with arbitrary arguments. `Universe` holds some of throwable objects such as `NullPointerException`, `VirtualMachineError`. They could be lost in flight record. This problem is not only for OOME. So I think we need to track all `Throwable` objects in `Exceptions::_throw()` in HotSpot instead of bytecode injection. `ThrowableTracer` has a counter to track num of throwing (`numThrowables`) which is used in `ExceptionStatisticsEvent`, so we also need to track it in HotSpot. I want to hear opinions about it before making changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From stefank at openjdk.java.net Tue Jan 12 10:12:59 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 12 Jan 2021 10:12:59 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 04:59:28 GMT, Kim Barrett wrote: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC I think this looks good. I have a few comments that I would like to get addressed, but they are not blockers if you want to proceed with what you have. src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 35: > 33: > 34: // Base class for OopStorageSet{Strong,Weak}ParState. > 35: template While reviewing this, it was not immediately obvious what T represent. EnumRange uses the name StorageId, maybe use the same here? src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 52: > 50: > 51: NONCOPYABLE(OopStorageSetParState); > 52: }; We tend to put the member variables at the top of classes. I don't think ParState needs to be public, and this could be changed to: template class OopStorageSetParState { using ParState = OopStorage::ParState; ValueObjArray().size()> _par_states; public: ParState* par_state(T id) const { return _par_states.at(checked_cast(EnumRange().index(id))); } protected: OopStorageSetParState() : _par_states(OopStorageSet::Range().begin()) {} ~OopStorageSetParState() = default; private: NONCOPYABLE(OopStorageSetParState); }; src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 58: > 56: class OopStorageSetStrongParState > 57: : public OopStorageSetParState > 58: { We usually keep the `{` on the same line. src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 68: > 66: class OopStorageSetWeakParState > 67: : public OopStorageSetParState > 68: { Same comment as above. src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp line 36: > 34: > 35: template > 36: template Other places in the file uses `template <` so the usage of `template<` makes the code inconsistent. src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: > 35: class WeakProcessorTimes { > 36: public: > 37: using StorageId = OopStorageSet::WeakId; Could be private. test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp line 48: > 46: > 47: template > 48: static void check_iterator(OopStorageSet::Iterator it, All the functions you changed are named `_iterator` and tested OopStorageSet::Iterator. Now the name is the same, but instead they test the Range facility. I think these functions should be renamed. Alternatively, we keep the tests for the OopStorageSet::Iterator and create a new set for the Range? ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1862 From jaroslav.bachorik at datadoghq.com Tue Jan 12 14:34:53 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 12 Jan 2021 15:34:53 +0100 Subject: A followup for JDK-8258414 (OldObjectSample event usability) Message-ID: Helo, I would like to pick up the thread from the JIRA to pre-discuss the possible course of action here. As I've already mentioned in JIRA the performance hit was significantly reduced with the stacktrace hashcode fix coming in the upcoming updates. Unfortunately, it does not solve the gigantic recording size - at >100MB per recording (1 minute) we must turn off OldObjectSample event stacktrace collection for our customers :( The reason is that the stacktrace is collected for all OldObjectSample event instantiations and it is never removed from the constant pool even if there are no events referring to it. Unfortunately, the option of delaying the stacktrace collection only after a successful try-lock will only reduce the overhead thanks to limiting the number of collections but, eventually, the constant pool will grow significantly if we are to keep the limit of the most recent N old object samples. Employing throttling, on the other hand, will guarantee that only used stacktraces will be in the constant pool - at the price of not being able to get N most recent events as the events would be randomly distributed across a time period. At this point I am trying to understand the importance of having 'most recent' events vs. a sampled event set. If most recent events are required and inevitable we will have to come up with a way to purge unused entries from the stacktrace constant pool. Thanks and looking for feedback! -JB- From jbachorik at openjdk.java.net Tue Jan 12 17:00:11 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 12 Jan 2021 17:00:11 GMT Subject: [jdk16] RFR: 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Message-ID: 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() ------------- Commit messages: - Backport a06cea50a5ea04fb0399d7ea3f6a2a20d9b4d254 Changes: https://git.openjdk.java.net/jdk16/pull/111/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=111&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258396 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/111.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/111/head:pull/111 PR: https://git.openjdk.java.net/jdk16/pull/111 From egahlin at openjdk.java.net Tue Jan 12 21:59:56 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 12 Jan 2021 21:59:56 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: On Tue, 12 Jan 2021 06:59:37 GMT, Yasumasa Suenaga wrote: >> @egahlin OOME from JVM will not be reported because they are instantiated at JVM init stage and are kept in `Universe`, so they cannot be handled in `ThrowableTracer::traceError`. >> We can trace OOMEs which are happened in Java code at `ThrowableTracer::traceError`. However I'm not sure where the event should be handled in. >> >> For sake of simply, I want to add `jdk.OutOfMemoryError` event to `jdk.jfr` module as a Java class, and I want to emit it from `ThrowableTracer::traceError`, however it duplicates with a definition in JVM. >> OTOH we can implement to emit event from `ThrowableTracer::traceError` via `JVM` class, however need to add API to emit events with arbitrary arguments. > > `Universe` holds some of throwable objects such as `NullPointerException`, `VirtualMachineError`. They could be lost in flight record. This problem is not only for OOME. > > So I think we need to track all `Throwable` objects in `Exceptions::_throw()` in HotSpot instead of bytecode injection. > `ThrowableTracer` has a counter to track num of throwing (`numThrowables`) which is used in `ExceptionStatisticsEvent`, so we also need to track it in HotSpot. > > I want to hear opinions about it before making changes. The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From ysuenaga at openjdk.java.net Wed Jan 13 11:10:22 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Jan 2021 11:10:22 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError [v2] In-Reply-To: References: Message-ID: > OOM on Metaspace would be reported in `MetaspaceOOM` JFR event, however other OOM (e.g. Java heap) would not be reported. > > It is useful if JFR reports OOMs. 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 three additional commits since the last revision: - Move JavaErrorThrow and JavaExceptionThrow into HotSpot - Merge remote-tracking branch 'upstream/master' into JDK-8256916 - 8256916: Add JFR event for OutOfMemoryError ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1403/files - new: https://git.openjdk.java.net/jdk/pull/1403/files/8f8799d6..7601b2f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1403&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1403&range=00-01 Stats: 122944 lines in 3018 files changed: 71590 ins; 25940 del; 25414 mod Patch: https://git.openjdk.java.net/jdk/pull/1403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1403/head:pull/1403 PR: https://git.openjdk.java.net/jdk/pull/1403 From markus.gronlund at oracle.com Wed Jan 13 12:26:41 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 13 Jan 2021 04:26:41 -0800 (PST) Subject: A followup for JDK-8258414 (OldObjectSample event usability) In-Reply-To: References: Message-ID: Hi, Just to have some common background on this discussion: The event jdk.OldObjectSample is the outward manifestation of the JFR memory leak profiler, the subsystem for tracking memory leaks by taking samples of memory allocations (objects). The profiler keeps the sampled objects in a small priority queue and stand in tight collaboration with the GCs (as the samples can be reclaimed at any time). When we introduced the memory leak profiling subsystem, it did impose new challenges to JFR: this is mainly because the lifetimes of an object allocation sample can, and most likely will, span across JFR epochs (chunks), which are boundaries for metadata / constant pools for all other events in JFR. The tricky problem is how to efficiently and minimally save metadata for jdk.OldObjectSample events across epoch / chunk boundaries. This is a harder problem that one might think at first ? the problem reduces to the fact that after the object sample has been taken, any external reference could already have been unloaded by the JVM. To support all of this, there is a lot of special handling in place for jdk.OldObjectSample: 1. Metadata / constant tracking use a separate tag category, the ?leakp? tag bit in the traceid field. 2. The hash of the stacktrace is saved to the sampled object representation upon creation, in order to, later at the epoch / chunk boundary, if the object is not CG:ed, perform a reverse lookup to transform the metadata associated with the stacktrace into binary large objects (blobs in the JFR binary file format) to be installed to the sampled objects. These blobs are reference counted to let the serialized metadata (now in blob form) be released if / when the sampled object is reclaimed by the GC. There are multiple blobs needed for each surviving sample objects, each corresponding to the metadata part needed to fully resolve the sampled object ?post? epoch / chunk rotation. There are blobs for the thread and thread group, the stacktrace and the transitive constant set (class, method, clds, packages, modules etc? As for configuration, in the JDK, we only enable stacktraces for jdk.OldObjectSample in the profile.jfc ? and the reason for this is mainly the size overheads being talked about here. The way it is currently done, with jdk.OldObjectSample candidates taking a stacktrace before being selected by the memory leak profiler, is an optimization based on the profile.jfc configuration: In profile.jfc, also memory allocation tracking events jdk.ObjectAllocationInNewTLAB and jdk.ObjectAllocationOutsideTLAB is, or at least was up to JDK 16, enabled with stacktraces turned on. There is an optimization in place that share the stacktrace id for all the three memory allocation events at the common allocation site, based on the assumption that they are enabled together as a unit in profile.jfc. Of course, the memory allocation events are known to be very high traffic and will cause a lot of data, just the sheer number of events produced, and if stacktraces are added to this, the associated metadata can be huge as well. The shortcomings of the existing memory allocation events and there being no means to control the data amount produced is what lead to the introduction of event throttling as per https://bugs.openjdk.java.net/browse/JDK-8257602. With JDK-8257602, the old memory allocation events (jdk.ObjectAllocationInNewTLAB and jdk.ObjectAllocationOutsideTLAB) have been disabled in profile.jfc, and the memory allocation tracing functionality has been replaced with a new, now throttled, jdk.ObjectAllocationSample event. So, with JDK-8257602, a basic premise is no longer valid (that a stacktrace will unconditionally be taken at the site), so we need to update the immediate environment affected by this, most notably the jdk.OldObjectSample and its stacktraces. Granted, this is also a problem that exist when custom profiles is used, where arbitrary event configurations are possible. I will also like to state, from the start, that there is work planned for stacktraces in general ? this involves the way they are captured, processed as well as represented - so things will be changing in this area. For the sake of discussion, let?s talk about ways this can be done better with the existing situation. Jaroslav wrote: ?Employing throttling, on the other hand, will guarantee that only used stacktraces will be in the constant pool - at the price of not being able to get N most recent events as the events would be randomly distributed across a time period.? I don?t think throttling will solve this problem ? the reason being the volatile nature of the sampled object candidates, as they can be reclaimed by the GC at any time ? when they are, they are removed from the priority queue but their stacktraces would still be in the ?constant pool?. For that to work, there would need to be some kind of reference counting scheme back to the just produced stacktrace ? but not only that, since also methods have been tagged for use, a pruning approach would also need to de-tag constants ? but an invariant in the JFR system is that no de-tags happen in the same epoch. What I can think of that might be feasible without too much invention is something like this: 1. Add a separate stacktrace table, only to be used by jdk.OldObjectSample events. Sample candidates register their stacktraces into this table as before, outside the try_lock(). 2. When a stacktrace is being generated for insertion, do _not_ tag the methods at the point (as is done today). Save the stacktrace hash as before to the sample candidate. 3. At chunk rotation, inspect all the surviving sample candidates and perform a reverse lookup (just like today), but do it against this new stacktrace table. 4. At the point of creating the stacktrace blob, set the ?leakp? tag for methods in the trace (just like is done today). 5. The constant pool serialization (JFR type set) then saves ?leakp? tagged constants and installs a constant pool metadata blob to the surviving candidates (just like today). Note that this new stacktrace table is not serialized wholesale (as is done with the regular stacktrace table) - it is only used to hold the stacktraces to, eventually maybe, be transformed into blobs for surviving candidates. Some details need be tuned: for example, there needs to be some logic added back to deoptimize parts of the object sample checkpoint serialization process (it currently skips parts as it relies on the current rotation to serialize for the most recent candidates). The main drawbacks are the lack of stacktrace re-use between ObjectAllocationSample and OldObjectSample, but maybe something smart can be done to enable it, and somewhat more complexity added to an already complex situation. Thanks Markus -----Original Message----- From: Jaroslav Bachor?k Sent: den 12 januari 2021 15:35 To: hotspot-jfr-dev Cc: Florian David ; Marcus Hirt Subject: A followup for JDK-8258414 (OldObjectSample event usability) Helo, I would like to pick up the thread from the JIRA to pre-discuss the possible course of action here. As I've already mentioned in JIRA the performance hit was significantly reduced with the stacktrace hashcode fix coming in the upcoming updates. Unfortunately, it does not solve the gigantic recording size - at >100MB per recording (1 minute) we must turn off OldObjectSample event stacktrace collection for our customers :( The reason is that the stacktrace is collected for all OldObjectSample event instantiations and it is never removed from the constant pool even if there are no events referring to it. Unfortunately, the option of delaying the stacktrace collection only after a successful try-lock will only reduce the overhead thanks to limiting the number of collections but, eventually, the constant pool will grow significantly if we are to keep the limit of the most recent N old object samples. Employing throttling, on the other hand, will guarantee that only used stacktraces will be in the constant pool - at the price of not being able to get N most recent events as the events would be randomly distributed across a time period. At this point I am trying to understand the importance of having 'most recent' events vs. a sampled event set. If most recent events are required and inevitable we will have to come up with a way to purge unused entries from the stacktrace constant pool. Thanks and looking for feedback! -JB- From ysuenaga at openjdk.java.net Wed Jan 13 14:16:02 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Jan 2021 14:16:02 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> On Tue, 12 Jan 2021 21:45:32 GMT, Erik Gahlin wrote: > The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. I updated PR. Could you review? Windows build on GitHub Actions failed, but it is not caused by this PR (due to configure error). I removed bytecode injection to hook c'tor of `Error` and `Exception`. JavaErrorThrown and JavaExceptionThrown would be thrown from HotSpot. And also number of thrown is counted at HotSpot, so I added new JNI function to get it, it is used for ExceptionStatistics event. > One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. I added a function call which emits JavaErrorThrown and/or JavaExceptionThrown around `Exceptions::log_exception()` call. It is not completely solution for your concern, but we can hook most of throwable objects like unified logging. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From ysuenaga at openjdk.java.net Wed Jan 13 14:29:02 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 13 Jan 2021 14:29:02 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Wed, 13 Jan 2021 14:13:30 GMT, Yasumasa Suenaga wrote: >> The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. >> >> One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. > >> The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. > > I updated PR. Could you review? > Windows build on GitHub Actions failed, but it is not caused by this PR (due to configure error). > > I removed bytecode injection to hook c'tor of `Error` and `Exception`. JavaErrorThrown and JavaExceptionThrown would be thrown from HotSpot. And also number of thrown is counted at HotSpot, so I added new JNI function to get it, it is used for ExceptionStatistics event. > >> One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. > > I added a function call which emits JavaErrorThrown and/or JavaExceptionThrown around `Exceptions::log_exception()` call. It is not completely solution for your concern, but we can hook most of throwable objects like unified logging. This PR passed all tests in jdk/jfr on Linux x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From egahlin at openjdk.java.net Wed Jan 13 18:28:11 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 13 Jan 2021 18:28:11 GMT Subject: [jdk16] RFR: 8253505: JFR: onFlush invoked out of order with a sorted event stream Message-ID: Hi, Could I have a review of a fix that makes sure EventStream::onFlush is always called after events in a segment has been pushed. Testing jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Missing metadata callback - Initial Changes: https://git.openjdk.java.net/jdk16/pull/116/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=116&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253505 Stats: 75 lines in 6 files changed: 27 ins; 23 del; 25 mod Patch: https://git.openjdk.java.net/jdk16/pull/116.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/116/head:pull/116 PR: https://git.openjdk.java.net/jdk16/pull/116 From denghui.ddh at alibaba-inc.com Thu Jan 14 04:08:13 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 14 Jan 2021 12:08:13 +0800 Subject: =?UTF-8?B?V2hhdCBpcyB0aGUgY3VycmVudCBwcm9ncmVzcyBvZiBKREstODI0OTg1OShKRlI6IE1ldGhv?= =?UTF-8?B?ZCB0cmFjaW5nKQ==?= Message-ID: <9d1983a7-5086-4ea1-b29d-8c76ca2710cd.denghui.ddh@alibaba-inc.com> Hi team, Our customers want to use JFR to track method calls and I noticed that the community already has the same issue(8249859), so we want to know if anyone is implementing this feature, if not, we are happy to try to implement it Thanks, Denghui From jaroslav.bachorik at datadoghq.com Thu Jan 14 09:13:55 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 14 Jan 2021 10:13:55 +0100 Subject: A followup for JDK-8258414 (OldObjectSample event usability) In-Reply-To: References: Message-ID: Hi Markus, Thanks for the really exhaustive write up! It is very useful to have all the small details summarized in one place. On Wed, Jan 13, 2021 at 1:26 PM Markus Gronlund wrote: > > Hi, > > Just to have some common background on this discussion: > > The event jdk.OldObjectSample is the outward manifestation of the JFR memory leak profiler, the subsystem for tracking memory leaks by taking samples of memory allocations (objects). The profiler keeps the sampled objects in a small priority queue and stand in tight collaboration with the GCs (as the samples can be reclaimed at any time). When we introduced the memory leak profiling subsystem, it did impose new challenges to JFR: this is mainly because the lifetimes of an object allocation sample can, and most likely will, span across JFR epochs (chunks), which are boundaries for metadata / constant pools for all other events in JFR. > The tricky problem is how to efficiently and minimally save metadata for jdk.OldObjectSample events across epoch / chunk boundaries. This is a harder problem that one might think at first ? the problem reduces to the fact that after the object sample has been taken, any external reference could already have been unloaded by the JVM. > > To support all of this, there is a lot of special handling in place for jdk.OldObjectSample: > > 1. Metadata / constant tracking use a separate tag category, the ?leakp? tag bit in the traceid field. > 2. The hash of the stacktrace is saved to the sampled object representation upon creation, in order to, later at the epoch / chunk boundary, if the object is not CG:ed, perform a reverse lookup to transform the metadata associated with the stacktrace into binary large objects (blobs in the JFR binary file format) to be installed to the sampled objects. These blobs are reference counted to let the serialized metadata (now in blob form) be released if / when the sampled object is reclaimed by the GC. There are multiple blobs needed for each surviving sample objects, each corresponding to the metadata part needed to fully resolve the sampled object ?post? epoch / chunk rotation. There are blobs for the thread and thread group, the stacktrace and the transitive constant set (class, method, clds, packages, modules etc? > > As for configuration, in the JDK, we only enable stacktraces for jdk.OldObjectSample in the profile.jfc ? and the reason for this is mainly the size overheads being talked about here. > > The way it is currently done, with jdk.OldObjectSample candidates taking a stacktrace before being selected by the memory leak profiler, is an optimization based on the profile.jfc configuration: > In profile.jfc, also memory allocation tracking events jdk.ObjectAllocationInNewTLAB and jdk.ObjectAllocationOutsideTLAB is, or at least was up to JDK 16, enabled with stacktraces turned on. > There is an optimization in place that share the stacktrace id for all the three memory allocation events at the common allocation site, based on the assumption that they are enabled together as a unit in profile.jfc. > Of course, the memory allocation events are known to be very high traffic and will cause a lot of data, just the sheer number of events produced, and if stacktraces are added to this, the associated metadata can be huge as well. > The shortcomings of the existing memory allocation events and there being no means to control the data amount produced is what lead to the introduction of event throttling as per https://bugs.openjdk.java.net/browse/JDK-8257602. With JDK-8257602, the old memory allocation events (jdk.ObjectAllocationInNewTLAB and jdk.ObjectAllocationOutsideTLAB) have been disabled in profile.jfc, and the memory allocation tracing functionality has been replaced with a new, now throttled, jdk.ObjectAllocationSample event. > So, with JDK-8257602, a basic premise is no longer valid (that a stacktrace will unconditionally be taken at the site), so we need to update the immediate environment affected by this, most notably the jdk.OldObjectSample and its stacktraces. Granted, this is also a problem that exist when custom profiles is used, where arbitrary event configurations are possible. > > I will also like to state, from the start, that there is work planned for stacktraces in general ? this involves the way they are captured, processed as well as represented - so things will be changing in this area. > > For the sake of discussion, let?s talk about ways this can be done better with the existing situation. > > Jaroslav wrote: > ?Employing throttling, on the other hand, will guarantee that only used stacktraces will be in the constant pool - at the price of not being able to get N most recent events as the events would be randomly distributed across a time period.? > > I don?t think throttling will solve this problem ? the reason being the volatile nature of the sampled object candidates, as they can be reclaimed by the GC at any time ? when they are, they are removed from the priority queue but their stacktraces would still be in the ?constant pool?. For that to work, there would need to be some kind of reference counting scheme back to the just produced stacktrace ? but not only that, since also methods have been tagged for use, a pruning approach would also need to de-tag constants ? but an invariant in the JFR system is that no de-tags happen in the same epoch. Yeah, I was a bit afraid this was going to be the case - things more complex than they seem to be on the first look. > > What I can think of that might be feasible without too much invention is something like this: > > 1. Add a separate stacktrace table, only to be used by jdk.OldObjectSample events. Sample candidates register their stacktraces into this table as before, outside the try_lock(). > 2. When a stacktrace is being generated for insertion, do _not_ tag the methods at the point (as is done today). Save the stacktrace hash as before to the sample candidate. > 3. At chunk rotation, inspect all the surviving sample candidates and perform a reverse lookup (just like today), but do it against this new stacktrace table. > 4. At the point of creating the stacktrace blob, set the ?leakp? tag for methods in the trace (just like is done today). > 5. The constant pool serialization (JFR type set) then saves ?leakp? tagged constants and installs a constant pool metadata blob to the surviving candidates (just like today). > > Note that this new stacktrace table is not serialized wholesale (as is done with the regular stacktrace table) - it is only used to hold the stacktraces to, eventually maybe, be transformed into blobs for surviving candidates. This sounds 'doable' - I was also pondering the idea of a 'side-table' for those stacktraces but was not sure it was appropriate. With the extra details you provided this seems to be very feasible. > > Some details need be tuned: for example, there needs to be some logic added back to deoptimize parts of the object sample checkpoint serialization process (it currently skips parts as it relies on the current rotation to serialize for the most recent candidates). > The main drawbacks are the lack of stacktrace re-use between ObjectAllocationSample and OldObjectSample, but maybe something smart can be done to enable it, and somewhat more complexity added to an already complex situation. `more complexity added to an already complex situation` is a very nice summary :) Thanks for the food for thought! -JB- > > Thanks > Markus > > -----Original Message----- > From: Jaroslav Bachor?k > Sent: den 12 januari 2021 15:35 > To: hotspot-jfr-dev > Cc: Florian David ; Marcus Hirt > Subject: A followup for JDK-8258414 (OldObjectSample event usability) > > Helo, > > I would like to pick up the thread from the JIRA to pre-discuss the possible course of action here. > > As I've already mentioned in JIRA the performance hit was significantly reduced with the stacktrace hashcode fix coming in the upcoming updates. Unfortunately, it does not solve the gigantic recording size - at >100MB per recording (1 minute) we must turn off OldObjectSample event stacktrace collection for our customers :( > > The reason is that the stacktrace is collected for all OldObjectSample event instantiations and it is never removed from the constant pool even if there are no events referring to it. > > Unfortunately, the option of delaying the stacktrace collection only after a successful try-lock will only reduce the overhead thanks to limiting the number of collections but, eventually, the constant pool will grow significantly if we are to keep the limit of the most recent N old object samples. > > Employing throttling, on the other hand, will guarantee that only used stacktraces will be in the constant pool - at the price of not being able to get N most recent events as the events would be randomly distributed across a time period. > > At this point I am trying to understand the importance of having 'most recent' events vs. a sampled event set. If most recent events are required and inevitable we will have to come up with a way to purge unused entries from the stacktrace constant pool. > > Thanks and looking for feedback! > > -JB- From github.com+5010047+kelthuzadx at openjdk.java.net Thu Jan 14 11:55:13 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Thu, 14 Jan 2021 11:55:13 GMT Subject: RFR: 8259774: samplethreads option does not work for jfr thread sampler Message-ID: Hi, Please help review this minor change that lets the JFR option `samplethreads` works. In the current implementation, no matter whether `samplethreads` option is turned on or off, it will not affect thread sampling. The sampler completely ignores it. This patch will address this problem and let the sampler aware of this option. ------------- Commit messages: - 8259774: samplethreads option does not work for jfr thread sampler Changes: https://git.openjdk.java.net/jdk/pull/2079/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2079&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259774 Stats: 97 lines in 2 files changed: 96 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2079.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2079/head:pull/2079 PR: https://git.openjdk.java.net/jdk/pull/2079 From egahlin at openjdk.java.net Thu Jan 14 14:43:04 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Jan 2021 14:43:04 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Wed, 13 Jan 2021 14:26:39 GMT, Yasumasa Suenaga wrote: >>> The right way to do this is to emit the event when the exception is thrown and I think it must happen inside the VM. >> >> I updated PR. Could you review? >> Windows build on GitHub Actions failed, but it is not caused by this PR (due to configure error). >> >> I removed bytecode injection to hook c'tor of `Error` and `Exception`. JavaErrorThrown and JavaExceptionThrown would be thrown from HotSpot. And also number of thrown is counted at HotSpot, so I added new JNI function to get it, it is used for ExceptionStatistics event. >> >>> One problem is that the C2 compiler can eliminate the throw if it can prove the it can't be seen. That is the reason, we ended up with the current implementation many years ago. It was complicated to implement in the VM. >> >> I added a function call which emits JavaErrorThrown and/or JavaExceptionThrown around `Exceptions::log_exception()` call. It is not completely solution for your concern, but we can hook most of throwable objects like unified logging. > > This PR passed all tests in jdk/jfr on Linux x64. I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From github.com+5010047+kelthuzadx at openjdk.java.net Thu Jan 14 14:45:23 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Thu, 14 Jan 2021 14:45:23 GMT Subject: RFR: 8259774: samplethreads option does not work for jfr thread sampler [v2] In-Reply-To: References: Message-ID: > Hi, > > Please help review this minor change that lets the JFR option > `samplethreads` works. > > In the current implementation, no matter whether `samplethreads` > option is turned on or off, it will not affect thread sampling. > The sampler completely ignores it. This patch will address this > problem and let the sampler aware of this option. Yang Yi 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: 8259774: samplethreads option does not work for jfr thread sampler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2079/files - new: https://git.openjdk.java.net/jdk/pull/2079/files/cfae38db..310f3d14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2079&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2079&range=00-01 Stats: 27 lines in 3 files changed: 21 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2079.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2079/head:pull/2079 PR: https://git.openjdk.java.net/jdk/pull/2079 From erik.gahlin at oracle.com Thu Jan 14 15:17:16 2021 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 14 Jan 2021 16:17:16 +0100 Subject: What is the current progress of JDK-8249859(JFR: Method tracing) In-Reply-To: <9d1983a7-5086-4ea1-b29d-8c76ca2710cd.denghui.ddh@alibaba-inc.com> References: <9d1983a7-5086-4ea1-b29d-8c76ca2710cd.denghui.ddh@alibaba-inc.com> Message-ID: Hi Denghui, We want to finish cheaper stack traces and parameterized event configuration first [1]. I know Markus is looking at cheaper stack traces now, and my plan is to look into parameterized event configuration and event logging for JDK 17. No guarantees though. I think a large part of the feature is the usability aspect. We also need to make sure it is performant and secure. Thanks Erik [1] https://bugs.openjdk.java.net/browse/JDK-8249859 > On 14 Jan 2021, at 05:08, Denghui Dong wrote: > > Hi team, > > Our customers want to use JFR to track method calls and I noticed that the community already has the same issue(8249859), > so we want to know if anyone is implementing this feature, if not, we are happy to try to implement it > > Thanks, > Denghui From egahlin at openjdk.java.net Thu Jan 14 15:46:03 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Jan 2021 15:46:03 GMT Subject: RFR: 8259774: samplethreads option does not work for jfr thread sampler In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 11:50:09 GMT, Yang Yi wrote: > Hi, > > Please help review this minor change that lets the JFR option > `samplethreads` works. > > In the current implementation, no matter whether `samplethreads` > option is turned on or off, it will not affect thread sampling. > The sampler completely ignores it. This patch will address this > problem and let the sampler aware of this option. The samplethreads option was added in 7u40 as an easy way to disable method profiling. This was when the feature was new and we had spurious crashes when walking thread stacks. It allowed us to disable the features in our test infrastructure. We later fixed the issue. If we get a crash, we have a crash handlar that will allow us to continue. We kept the flag for a few releases, as a workaround for customers if they would run into issues. AFAIK, this has never been the case? The flag should really be removed. Could be it is still there because it has not yet gone through deprecation process. ------------- PR: https://git.openjdk.java.net/jdk/pull/2079 From mukilesh.sethu at gmail.com Thu Jan 14 16:45:42 2021 From: mukilesh.sethu at gmail.com (Mukilesh Sethu) Date: Thu, 14 Jan 2021 16:45:42 +0000 Subject: Potential optimizations on management of stack traces In-Reply-To: References: Message-ID: Hey, Thank you for the response. It makes sense. In the meantime do you recommend any mitigation steps? I was thinking of trying the following, 1. Reduce the sample set by disabling and enabling the events in a cyclic fashion. (I don't expect any overhead but concerned about the value of data) 2. Set `maxchunksize` to a lower value to rotate the disk frequently thereby clearing the stack repository frequently. (Expecting overhead due to frequent rotations) Both would definitely have an impact but I would like to try it out and check if it is something we can live with. Thanks, Mukilesh On Thu, Dec 17, 2020 at 9:40 AM Erik Gahlin wrote: > Hi Mukilesh, > > Short term plan is to look into using the stack watermark barrier > mechanism introduced with JEP 376: ZGC: Concurrent Thread-Stack Processing > [1]. > > We believe the cost of walking (and comparing) the whole stack can be > avoided in many cases. Instead of walking 100 frames, it might be > sufficient to walk 5 if we can prove the stack has not been popped beyond a > 5 frame watermark. To make this work efficiently, the JFR stack data > structure and hashing algorithm need to be changed. We believe it is best > to implement/investigate this before doing other optimizations. > > There are also ways we can reduce the cost of the method lookup that we > have not yet looked into. > > Cheers > Erik > > [1] https://openjdk.java.net/jeps/376 > > > On 16 Dec 2020, at 18:47, Mukilesh Sethu > wrote: > > > > Hey, > > > > We saw similar overhead with allocation events as mentioned in this > thread ( > > > https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-July/001605.html > ) > > and we did see some improvements with the fix on hashing algorithm but > > still the overhead was quite high. > > > > I was curious about your thoughts on further optimizing it ? Are there > any > > plans for it ? I think new allocation event gives full control to the > > consumers so that it can be fine tuned as per their requirements but max > > cap would still be the same. > > > > I had few optimizations in my mind but please correct me if I am wrong > here > > because I am very much new to this codebase, > > > > 1. Strip locking - As per my understanding, stack traces collected by JFR > > are stored in a fixed size global table where each entry is a linked > list. > > Index to global table is determined by hash code of stack trace. One of > the > > main reasons for the overhead is the global lock acquired when the table > is > > updated. This includes comparing stack traces to avoid duplicates. > > > > Potential optimization: Can we maintain a lock for each entry in the > table > > so that they can be updated independently. > > > > Caveat: Clearing table could be quite tricky. > > > > 2. Can we take advantage of the fact new stack traces are added to the > > beginning of the linked list and no individual stack trace from an entry > > would be deleted independently ? We could have a workflow like, > > > > - read last `n` stacktraces from an entry, where `n` is the current size > of > > the linked list( `next` of these stacktraces are never changed). > > - compare it with existing stack trace. > > - if present, early return > > - take lock > > - compare with first m-n stacktraces, where `m` is the new size of the > > linked list. > > - if present, early return > > - else update. > > - unlock > > > > Caveat: Clearing table could be quite tricky here as well. But I believe > it > > can be handled as a special case considering it doesn't happen quite > often. > > > > Please let me know your thoughts. > > > > Thanks, > > Mukilesh > > From markus.gronlund at oracle.com Thu Jan 14 17:49:48 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 14 Jan 2021 09:49:48 -0800 (PST) Subject: Potential optimizations on management of stack traces In-Reply-To: References: Message-ID: <8480a24d-8345-47b0-bf74-339fdad07e9c@default> Hi Mukilesh, You might be interested in taking a look at and maybe trying out https://bugs.openjdk.java.net/browse/JDK-8258826 . The PR code should be working, at least last time I checked (before X-mas). Thanks Markus -----Original Message----- From: Mukilesh Sethu Sent: den 14 januari 2021 17:46 To: Erik Gahlin Cc: hotspot-jfr-dev at openjdk.java.net Subject: Re: Potential optimizations on management of stack traces Hey, Thank you for the response. It makes sense. In the meantime do you recommend any mitigation steps? I was thinking of trying the following, 1. Reduce the sample set by disabling and enabling the events in a cyclic fashion. (I don't expect any overhead but concerned about the value of data) 2. Set `maxchunksize` to a lower value to rotate the disk frequently thereby clearing the stack repository frequently. (Expecting overhead due to frequent rotations) Both would definitely have an impact but I would like to try it out and check if it is something we can live with. Thanks, Mukilesh On Thu, Dec 17, 2020 at 9:40 AM Erik Gahlin wrote: > Hi Mukilesh, > > Short term plan is to look into using the stack watermark barrier > mechanism introduced with JEP 376: ZGC: Concurrent Thread-Stack > Processing [1]. > > We believe the cost of walking (and comparing) the whole stack can be > avoided in many cases. Instead of walking 100 frames, it might be > sufficient to walk 5 if we can prove the stack has not been popped > beyond a > 5 frame watermark. To make this work efficiently, the JFR stack data > structure and hashing algorithm need to be changed. We believe it is > best to implement/investigate this before doing other optimizations. > > There are also ways we can reduce the cost of the method lookup that > we have not yet looked into. > > Cheers > Erik > > [1] https://openjdk.java.net/jeps/376 > > > On 16 Dec 2020, at 18:47, Mukilesh Sethu > wrote: > > > > Hey, > > > > We saw similar overhead with allocation events as mentioned in this > thread ( > > > https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-July/0016 > 05.html > ) > > and we did see some improvements with the fix on hashing algorithm > > but still the overhead was quite high. > > > > I was curious about your thoughts on further optimizing it ? Are > > there > any > > plans for it ? I think new allocation event gives full control to > > the consumers so that it can be fine tuned as per their requirements > > but max cap would still be the same. > > > > I had few optimizations in my mind but please correct me if I am > > wrong > here > > because I am very much new to this codebase, > > > > 1. Strip locking - As per my understanding, stack traces collected > > by JFR are stored in a fixed size global table where each entry is a > > linked > list. > > Index to global table is determined by hash code of stack trace. One > > of > the > > main reasons for the overhead is the global lock acquired when the > > table > is > > updated. This includes comparing stack traces to avoid duplicates. > > > > Potential optimization: Can we maintain a lock for each entry in the > table > > so that they can be updated independently. > > > > Caveat: Clearing table could be quite tricky. > > > > 2. Can we take advantage of the fact new stack traces are added to > > the beginning of the linked list and no individual stack trace from > > an entry would be deleted independently ? We could have a workflow > > like, > > > > - read last `n` stacktraces from an entry, where `n` is the current > > size > of > > the linked list( `next` of these stacktraces are never changed). > > - compare it with existing stack trace. > > - if present, early return > > - take lock > > - compare with first m-n stacktraces, where `m` is the new size of > > the linked list. > > - if present, early return > > - else update. > > - unlock > > > > Caveat: Clearing table could be quite tricky here as well. But I > > believe > it > > can be handled as a special case considering it doesn't happen quite > often. > > > > Please let me know your thoughts. > > > > Thanks, > > Mukilesh > > From mgronlun at openjdk.java.net Thu Jan 14 17:51:09 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Jan 2021 17:51:09 GMT Subject: RFR: 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors Message-ID: Greetings, please review this changeset to let JFR work in situations where the VM is built with -fno-elide-constructors. The original means to interface with the JfrVersionSystem employed handles, but to work correctly, the handles relied on Return Value Optimization (RVO), which was a lazy assumption on my part. The handles will now employ copy-and-swap for reference counting. Testing: jdk_jfr with (and without) build option -fno-elide-constructors Thanks to Kim Barrett for filing this issue. Thank you Markus ------------- Commit messages: - 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors Changes: https://git.openjdk.java.net/jdk/pull/2083/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2083&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259036 Stats: 215 lines in 5 files changed: 74 ins; 98 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/2083.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2083/head:pull/2083 PR: https://git.openjdk.java.net/jdk/pull/2083 From egahlin at openjdk.java.net Thu Jan 14 18:55:19 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Jan 2021 18:55:19 GMT Subject: [jdk16] RFR: 8253505: JFR: onFlush invoked out of order with a sorted event stream [v2] In-Reply-To: References: Message-ID: <_9HIKwD5GwgWdpgPFDmsRPCbuagpdgDynjqxUt6qOus=.df427679-5523-479b-ae81-093ee24ad3e6@github.com> > Hi, > > Could I have a review of a fix that makes sure EventStream::onFlush is always called after events in a segment has been pushed. > > Testing jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/116/files - new: https://git.openjdk.java.net/jdk16/pull/116/files/32fc2570..ca047662 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=116&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=116&range=00-01 Stats: 7 lines in 2 files changed: 3 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/116.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/116/head:pull/116 PR: https://git.openjdk.java.net/jdk16/pull/116 From mgronlun at openjdk.java.net Thu Jan 14 21:22:05 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Jan 2021 21:22:05 GMT Subject: [jdk16] RFR: 8253505: JFR: onFlush invoked out of order with a sorted event stream [v2] In-Reply-To: <_9HIKwD5GwgWdpgPFDmsRPCbuagpdgDynjqxUt6qOus=.df427679-5523-479b-ae81-093ee24ad3e6@github.com> References: <_9HIKwD5GwgWdpgPFDmsRPCbuagpdgDynjqxUt6qOus=.df427679-5523-479b-ae81-093ee24ad3e6@github.com> Message-ID: On Thu, 14 Jan 2021 18:55:19 GMT, Erik Gahlin wrote: >> Hi, >> >> Could I have a review of a fix that makes sure EventStream::onFlush is always called after events in a segment has been pushed. >> >> Testing jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/116 From egahlin at openjdk.java.net Thu Jan 14 21:29:10 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Jan 2021 21:29:10 GMT Subject: [jdk16] Integrated: 8253505: JFR: onFlush invoked out of order with a sorted event stream In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 17:20:22 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of a fix that makes sure EventStream::onFlush is always called after events in a segment has been pushed. > > Testing jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 4307fa68 Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk16/commit/4307fa68 Stats: 79 lines in 6 files changed: 29 ins; 25 del; 25 mod 8253505: JFR: onFlush invoked out of order with a sorted event stream Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk16/pull/116 From egahlin at openjdk.java.net Fri Jan 15 00:06:08 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 15 Jan 2021 00:06:08 GMT Subject: [jdk16] RFR: 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 16:53:43 GMT, Jaroslav Bachorik wrote: > 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/111 From denghui.ddh at alibaba-inc.com Fri Jan 15 02:23:33 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 15 Jan 2021 10:23:33 +0800 Subject: =?UTF-8?B?UmU6IFdoYXQgaXMgdGhlIGN1cnJlbnQgcHJvZ3Jlc3Mgb2YgSkRLLTgyNDk4NTkoSkZSOiBN?= =?UTF-8?B?ZXRob2QgdHJhY2luZyk=?= In-Reply-To: References: <9d1983a7-5086-4ea1-b29d-8c76ca2710cd.denghui.ddh@alibaba-inc.com>, Message-ID: Thank you for the response. Parameterized event configuration will make JFR more flexible, looking forward to this feature:) Denghui ------------------------------------------------------------------ From:Erik Gahlin Send Time:2021?1?14?(???) 23:17 To:???(??) Cc:hotspot-jfr-dev Subject:Re: What is the current progress of JDK-8249859(JFR: Method tracing) Hi Denghui, We want to finish cheaper stack traces and parameterized event configuration first [1]. I know Markus is looking at cheaper stack traces now, and my plan is to look into parameterized event configuration and event logging for JDK 17. No guarantees though. I think a large part of the feature is the usability aspect. We also need to make sure it is performant and secure. Thanks Erik [1] https://bugs.openjdk.java.net/browse/JDK-8249859 > On 14 Jan 2021, at 05:08, Denghui Dong wrote: > > Hi team, > > Our customers want to use JFR to track method calls and I noticed that the community already has the same issue(8249859), > so we want to know if anyone is implementing this feature, if not, we are happy to try to implement it > > Thanks, > Denghui From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 15 02:31:03 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 15 Jan 2021 02:31:03 GMT Subject: RFR: 8259774: samplethreads option does not work for jfr thread sampler In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 15:40:32 GMT, Erik Gahlin wrote: >> Hi, >> >> Please help review this minor change that lets the JFR option >> `samplethreads` works. >> >> In the current implementation, no matter whether `samplethreads` >> option is turned on or off, it will not affect thread sampling. >> The sampler completely ignores it. This patch will address this >> problem and let the sampler aware of this option. > > The samplethreads option was added in 7u40 as an easy way to disable method profiling. > > This was when the feature was new and we had spurious crashes when walking thread stacks. It allowed us to disable the features in our test infrastructure. We later fixed the issue. If we get a crash, we have a crash handlar that will allow us to continue. We kept the flag for a few releases, as a workaround for customers if they would run into issues. AFAIK, this has never been the case? > > The flag should really be removed. Could be it is still there because it has not yet gone through deprecation process. Thanks to your explanation, it makes sense. I have some ideas about this option. I noticed that the current implementation of thread sampling is to traverse threads from ThreadsList and do sampling. The consequence of this is that the sampling event in the recording file becomes very confusing, and it is difficult for users to find what they expect. If the user expects to know the callings of a certain thread in a period, this is impossible, because the sampling event of this thread is not continuous. So I wonder if there is a way for users to specify the thread they want to sample, for example: $ jstack // get thread id that expectes to know $ jcmd pid JFR.configure samplethreads= ------------- PR: https://git.openjdk.java.net/jdk/pull/2079 From ddong at openjdk.java.net Fri Jan 15 02:48:15 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 15 Jan 2021 02:48:15 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall Message-ID: 8259808: Add JFR event to detect GC locker stall ------------- Commit messages: - 8259808: Add JFR event to detect GC locker stall Changes: https://git.openjdk.java.net/jdk/pull/2088/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259808 Stats: 191 lines in 9 files changed: 191 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ysuenaga at openjdk.java.net Fri Jan 15 03:08:03 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 15 Jan 2021 03:08:03 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Thu, 14 Jan 2021 14:40:34 GMT, Erik Gahlin wrote: > I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. I agree with you the problem is also with C2, however current JFR implementation has also problem in exception events - they hook throwing exceptions lesser than unified logging. It should be fixed. As you can see in this PR, to move throwing events into HotSpot makes big change, so I think it is worth to work now without solving the problem with C2. (We will be able to make lesser change when we want to solve the problem with C2 later.) So I hope other JFR folks review this PR if you are busy. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From ddong at openjdk.java.net Fri Jan 15 03:17:03 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 15 Jan 2021 03:17:03 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 02:42:20 GMT, Denghui Dong wrote: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. For the test purpose, I add two Whitebox methods to lock/unlock critical. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From egahlin at openjdk.java.net Fri Jan 15 04:28:04 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 15 Jan 2021 04:28:04 GMT Subject: RFR: 8259774: samplethreads option does not work for jfr thread sampler In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 02:28:21 GMT, Yang Yi wrote: >> The samplethreads option was added in 7u40 as an easy way to disable method profiling. >> >> This was when the feature was new and we had spurious crashes when walking thread stacks. It allowed us to disable the features in our test infrastructure. We later fixed the issue. If we get a crash, we have a crash handlar that will allow us to continue. We kept the flag for a few releases, as a workaround for customers if they would run into issues. AFAIK, this has never been the case? >> >> The flag should really be removed. Could be it is still there because it has not yet gone through deprecation process. > > Thanks to your explanation, it makes sense. I have some ideas about this option. I noticed that the current implementation of thread sampling is to traverse threads from ThreadsList and do sampling. The consequence of this is that the sampling event in the recording file becomes very confusing, and it is difficult for users to find what they expect. If the user expects to know the callings of a certain thread in a period, this is impossible, because the sampling event of this thread is not continuous. So I wonder if there is a way for users to specify the thread they want to sample, for example: > $ jstack > // get thread id that expectes to know > $ jcmd pid JFR.configure samplethreads= There is no way to specify the thread. It is possible to reduce the period to 1 ms to increase the number samples. It might help to troubleshoot the issue, but it will also create lots of additional events for all threads. We have thought about adding per thread capabilities, like filtering or recording all events for a particular thread, but the main obstacle has been how to configure such a system. Plan is to simplify event configuration on command line and then see what features it will "unlock". ------------- PR: https://git.openjdk.java.net/jdk/pull/2079 From mgronlun at openjdk.java.net Fri Jan 15 10:02:07 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Jan 2021 10:02:07 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Fri, 15 Jan 2021 03:05:40 GMT, Yasumasa Suenaga wrote: >> I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. > >> I don't have time to look at this now, I need to fix some high priority issues for JDK 16, but the problem is with C2. Several people have looked at this before. > > I agree with you the problem is also with C2, however current JFR implementation has also problem in exception events - they hook throwing exceptions lesser than unified logging. It should be fixed. > > As you can see in this PR, to move throwing events into HotSpot makes big change, so I think it is worth to work now without solving the problem with C2. > (We will be able to make lesser change when we want to solve the problem with C2 later.) > > So I hope other JFR folks review this PR if you are busy. As you say: "move throwing events into HotSpot makes big change" - I agree and Erik has already stated that many have tried already to make this kind of change, but attempts have faltered because the impact / disruptions are unclear. Do you fully understand the consequences of how it will change the way users work with exceptions in JFR? If C2 optimizations now start to remove exception sites that were previously reported? I understand and appreciate the ambition, and I acknowledge the existing mechanisms has drawbacks (known for a long time) but reworking how exceptions are reported is a big project. Such a project should also involve exception throttling - and throttling might pose additional constraints / opportunities that need to be considered. Modifying this subsystem is a sensitive undertaking and should solve the fundamental and already known problems before it is to be endorsed and for the disruption to end user motivated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From mgronlun at openjdk.java.net Fri Jan 15 14:45:19 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Jan 2021 14:45:19 GMT Subject: [jdk16] RFR: 8259574: SIGSEGV in BFSClosure::closure_impl Message-ID: Greetings, please help review this small adjustment to get the JFR Memory Leak Profiler working again. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8259574: SIGSEGV in BFSClosure::closure_impl Changes: https://git.openjdk.java.net/jdk16/pull/125/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=125&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259574 Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/125.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/125/head:pull/125 PR: https://git.openjdk.java.net/jdk16/pull/125 From jbachorik at openjdk.java.net Fri Jan 15 15:15:12 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 15 Jan 2021 15:15:12 GMT Subject: [jdk16] Integrated: 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 16:53:43 GMT, Jaroslav Bachorik wrote: > 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() This pull request has now been integrated. Changeset: e85892bf Author: Jaroslav Bachorik URL: https://git.openjdk.java.net/jdk16/commit/e85892bf Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Reviewed-by: egahlin Backport-of: a06cea50a5ea04fb0399d7ea3f6a2a20d9b4d254 ------------- PR: https://git.openjdk.java.net/jdk16/pull/111 From stefank at openjdk.java.net Fri Jan 15 15:20:10 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 15 Jan 2021 15:20:10 GMT Subject: [jdk16] RFR: 8259574: SIGSEGV in BFSClosure::closure_impl In-Reply-To: References: Message-ID: <3zfmfbT636RDd-DeN7NC0CNANjKP7Ot4AJ5ZSwkf-ds=.5d0f7553-583d-4f35-be4e-73c0e29e01cb@github.com> On Fri, 15 Jan 2021 14:39:57 GMT, Markus Gr?nlund wrote: > Greetings, > > please help review this small adjustment to get the JFR Memory Leak Profiler working again. > > Testing: jdk_jfr > > Thanks > Markus The chains/ changes look good. I don't know why jfrEmergencyDump.cpp was changed, so that has not been reviewed by me. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/125 From mgronlun at openjdk.java.net Fri Jan 15 15:27:06 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Jan 2021 15:27:06 GMT Subject: [jdk16] RFR: 8259574: SIGSEGV in BFSClosure::closure_impl In-Reply-To: <3zfmfbT636RDd-DeN7NC0CNANjKP7Ot4AJ5ZSwkf-ds=.5d0f7553-583d-4f35-be4e-73c0e29e01cb@github.com> References: <3zfmfbT636RDd-DeN7NC0CNANjKP7Ot4AJ5ZSwkf-ds=.5d0f7553-583d-4f35-be4e-73c0e29e01cb@github.com> Message-ID: On Fri, 15 Jan 2021 15:17:23 GMT, Stefan Karlsson wrote: >> Greetings, >> >> please help review this small adjustment to get the JFR Memory Leak Profiler working again. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > The chains/ changes look good. I don't know why jfrEmergencyDump.cpp was changed, so that has not been reviewed by me. @stefank thank you. The change to jfrEmergencyDump.cpp is done (and is also overdue) because in this case, it is the VMThread that crashes and attempts to issue the jfr emergency dump. ------------- PR: https://git.openjdk.java.net/jdk16/pull/125 From egahlin at openjdk.java.net Fri Jan 15 15:32:05 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 15 Jan 2021 15:32:05 GMT Subject: [jdk16] RFR: 8259574: SIGSEGV in BFSClosure::closure_impl In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 14:39:57 GMT, Markus Gr?nlund wrote: > Greetings, > > please help review this small adjustment to get the JFR Memory Leak Profiler working again. > > Testing: jdk_jfr > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/125 From kbarrett at openjdk.java.net Sat Jan 16 15:40:31 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 16 Jan 2021 15:40:31 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v2] In-Reply-To: References: Message-ID: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into wpp4 - stefank review - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. ------------- Changes: https://git.openjdk.java.net/jdk/pull/1862/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=01 Stats: 1042 lines in 25 files changed: 400 ins; 465 del; 177 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862 From kim.barrett at oracle.com Sat Jan 16 15:42:44 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 16 Jan 2021 10:42:44 -0500 Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: References: Message-ID: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> > On Jan 12, 2021, at 5:12 AM, Stefan Karlsson wrote: > > On Tue, 22 Dec 2020 04:59:28 GMT, Kim Barrett wrote: > >> Please review this change which eliminates the WeakProcessorPhase class. >> >> The OopStorageSet class is changed to provide scoped enums for the different >> categories: StrongId, WeakId, and Id (for the union of strong and weak). >> An accessor is provided for obtaining the storage corresponding to a >> category value. >> >> Various other enumerator ranges, array sizes and indices, and iterations are >> derived directly from the corresponding OopStorageSet category's enum range. >> >> Iteration over a category of enumerators can be done via EnumIterator. The >> iteration over storage objects makes use of that enum iteration, rather than >> having a bespoke implementation. Some use-cases need iteration of the >> enumerators, with storage lookup from the enumerator; other use-cases just >> need the storage objects. >> >> Testing: >> mach5 tier1-6 >> Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > I think this looks good. I have a few comments that I would like to get addressed, but they are not blockers if you want to proceed with what you have. Thanks. > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 35: > >> 33: >> 34: // Base class for OopStorageSet{Strong,Weak}ParState. >> 35: template > > While reviewing this, it was not immediately obvious what T represent. EnumRange uses the name StorageId, maybe use the same here? T -> StorageId -- done. > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 52: > >> 50: >> 51: NONCOPYABLE(OopStorageSetParState); >> 52: }; > > We tend to put the member variables at the top of classes. I don't think ParState needs to be public, and this could be changed to: > [?] Having a public function whose type signature involves identifiers that can't be used by clients, particularly for the return type, is problematic. Personally, I intensely dislike the typical HotSpot ordering, but go along anyway if there's not a direct reason not to, as there is here. (The HotSpot ordering also happens to be contrary to every style guide I've ever seen discuss the subject, and those style guides give good reasons that are the basis of my dislike.) Options are (1) drop the type alias and write out the type, (2) have multiple public sections, (3) put the public stuff first. I prefer (3). Though I went with (2) in weakProcessorTimes.hpp, to reduce the code churn for this PR. > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 58: > >> 56: class OopStorageSetStrongParState >> 57: : public OopStorageSetParState >> 58: { > > We usually keep the `{` on the same line. We also usually put the base class on the same line as the class, but that made the lines longer than I like, hence the line break there. Having the open brace at the end of the base class line then makes the distinction between the base class part and the members more subtle than I liked; I think the brace placement I used helps with that. (All this is a long-winded way of saying that the formatting here is intentional, attempting to make the code easier to parse by eye.) > src/hotspot/share/gc/shared/oopStorageSetParState.hpp line 68: > >> 66: class OopStorageSetWeakParState >> 67: : public OopStorageSetParState >> 68: { > > Same comment as above. > > src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp line 36: > >> 34: >> 35: template >> 36: template > > Other places in the file uses `template <` so the usage of `template<` makes the code inconsistent. Yeah, sorry, I try to be consistent with nearby code but failed here; fixed. FWIW, HotSpot uses both, and there doesn't seem to be a consensus in the wider C++ community. The C++ Standard uses both! My default has always been no-space, and having a space there bugs me a little, but not enough to argue over. > src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: > >> 35: class WeakProcessorTimes { >> 36: public: >> 37: using StorageId = OopStorageSet::WeakId; > > Could be private. Here too I think public functions whose type signatures involve identifiers that can't be used by clients is problematic. But I renamed it from StorageId to WeakId; looking at it again, the more generic name seems counterproductive here. > test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp line 48: > >> 46: >> 47: template >> 48: static void check_iterator(OopStorageSet::Iterator it, > > All the functions you changed are named `_iterator` and tested OopStorageSet::Iterator. Now the name is the same, but instead they test the Range facility. I think these functions should be renamed. Alternatively, we keep the tests for the OopStorageSet::Iterator and create a new set for the Range? What's being tested is iteration, so "iterator" => "iteration? throughout seems better. > Marked as reviewed by stefank (Reviewer). Thanks for reviewing. > PR: https://git.openjdk.java.net/jdk/pull/1862 From mgronlun at openjdk.java.net Sun Jan 17 15:18:09 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sun, 17 Jan 2021 15:18:09 GMT Subject: RFR: 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Message-ID: Greetings, please help review this small adjustment. Full details in the bug. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Changes: https://git.openjdk.java.net/jdk/pull/2116/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2116&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249245 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2116.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2116/head:pull/2116 PR: https://git.openjdk.java.net/jdk/pull/2116 From egahlin at openjdk.java.net Sun Jan 17 15:27:06 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sun, 17 Jan 2021 15:27:06 GMT Subject: RFR: 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: On Sun, 17 Jan 2021 15:10:46 GMT, Markus Gr?nlund wrote: > Greetings, > > please help review this small adjustment. Full details in the bug. > > Testing: jdk_jfr, stress testing > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2116 From ddong at openjdk.java.net Mon Jan 18 02:53:37 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 02:53:37 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 03:14:10 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Greetings, please help review this patch:) Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From stefank at openjdk.java.net Mon Jan 18 08:12:47 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 18 Jan 2021 08:12:47 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 02:42:20 GMT, Denghui Dong wrote: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Not a review, but a few comments about what probably needs to be cleaned up before a proper review starts. src/hotspot/share/gc/shared/gcLocker.cpp line 186: > 184: _stall_count = 0; > 185: } > 186: #endif This adds a fair amount of noise and hides the actual GCLocker logic, IMHO. Could you somehow encapsulate this code and the other INCLUDE_JFR above into a class and make single-line calls perform these functions? src/hotspot/share/jfr/metadata/metadata.xml line 1080: > 1078: > 1079: > 1080: You add this between two Shenandoah events. Could you put it somewhere where it's not splitting up a group of events? src/hotspot/share/prims/whitebox.cpp line 44: > 42: #include "gc/shared/genArguments.hpp" > 43: #include "gc/shared/genCollectedHeap.hpp" > 44: #include "gc/shared/gcLocker.inline.hpp" Sort includes. src/hotspot/share/gc/shared/gcLocker.cpp line 112: > 110: #if INCLUDE_JFR > 111: if (EventGCLocker::is_enabled()) { > 112: _needs_gc_start_timestamp = JfrTicks::now(); Do you really need to use JfrTicks instead of Ticks here? If not, could you remove all references and includes of JfrTicks? We usually use pass in Ticks when we send JFR events. src/hotspot/share/utilities/ticks.hpp line 241: > 239: friend class GCTimerTest; > 240: friend class CompilerEvent; > 241: friend class GCLocker; I don't think this should be needed. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From mgronlun at openjdk.java.net Mon Jan 18 10:25:44 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Jan 2021 10:25:44 GMT Subject: [jdk16] Integrated: 8259574: SIGSEGV in BFSClosure::closure_impl In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 14:39:57 GMT, Markus Gr?nlund wrote: > Greetings, > > please help review this small adjustment to get the JFR Memory Leak Profiler working again. > > Testing: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: cd25bf2e Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk16/commit/cd25bf2e Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod 8259574: SIGSEGV in BFSClosure::closure_impl Reviewed-by: stefank, egahlin ------------- PR: https://git.openjdk.java.net/jdk16/pull/125 From tschatzl at openjdk.java.net Mon Jan 18 10:34:51 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 18 Jan 2021 10:34:51 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jan 2021 15:40:31 GMT, Kim Barrett wrote: >> Please review this change which eliminates the WeakProcessorPhase class. >> >> The OopStorageSet class is changed to provide scoped enums for the different >> categories: StrongId, WeakId, and Id (for the union of strong and weak). >> An accessor is provided for obtaining the storage corresponding to a >> category value. >> >> Various other enumerator ranges, array sizes and indices, and iterations are >> derived directly from the corresponding OopStorageSet category's enum range. >> >> Iteration over a category of enumerators can be done via EnumIterator. The >> iteration over storage objects makes use of that enum iteration, rather than >> having a bespoke implementation. Some use-cases need iteration of the >> enumerators, with storage lookup from the enumerator; other use-cases just >> need the storage objects. >> >> Testing: >> mach5 tier1-6 >> Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into wpp4 > - stefank review > - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Marked as reviewed by tschatzl (Reviewer). src/hotspot/share/gc/shared/oopStorageSet.cpp line 2: > 1: /* > 2: * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved. It's 2021 by now, I suggest to update these before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1862 From kim.barrett at oracle.com Mon Jan 18 10:41:38 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 Jan 2021 05:41:38 -0500 Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> References: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> Message-ID: <39C4F5B9-FA6C-4E5C-95A3-2A1F7C1299B3@oracle.com> > On Jan 16, 2021, at 10:42 AM, Kim Barrett wrote: > >> On Jan 12, 2021, at 5:12 AM, Stefan Karlsson wrote: >> src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: >> >>> 35: class WeakProcessorTimes { >>> 36: public: >>> 37: using StorageId = OopStorageSet::WeakId; >> >> Could be private. > > Here too I think public functions whose type signatures involve identifiers > that can't be used by clients is problematic. But I renamed it from > StorageId to WeakId; looking at it again, the more generic name seems > counterproductive here. After thinking about this some more, I?m going to see what it looks like to just eliminate the type alias entirely. From ddong at openjdk.java.net Mon Jan 18 13:55:06 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 13:55:06 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: Refactor based on comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/b68814f3..c36d4f96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=00-01 Stats: 94 lines in 6 files changed: 55 ins; 36 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Mon Jan 18 13:55:07 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 13:55:07 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 08:10:10 GMT, Stefan Karlsson wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor based on comments > > Not a review, but a few comments about what probably needs to be cleaned up before a proper review starts. Refactored. Testing: jdk/jfr all passed. > src/hotspot/share/gc/shared/gcLocker.cpp line 186: > >> 184: _stall_count = 0; >> 185: } >> 186: #endif > > This adds a fair amount of noise and hides the actual GCLocker logic, IMHO. Could you somehow encapsulate this code and the other INCLUDE_JFR above into a class and make single-line calls perform these functions? good idea. updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Mon Jan 18 14:00:42 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 18 Jan 2021 14:00:42 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: <0GQ4f8N7Ddv0bpiazsnfPydzLYN1gZdhHu42U3ZpMMc=.3dd4d732-c24a-4166-9d00-0b8e7e4b03e0@github.com> On Mon, 18 Jan 2021 08:04:38 GMT, Stefan Karlsson wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor based on comments > > src/hotspot/share/utilities/ticks.hpp line 241: > >> 239: friend class GCTimerTest; >> 240: friend class CompilerEvent; >> 241: friend class GCLocker; > > I don't think this should be needed. Fixed. > src/hotspot/share/gc/shared/gcLocker.cpp line 112: > >> 110: #if INCLUDE_JFR >> 111: if (EventGCLocker::is_enabled()) { >> 112: _needs_gc_start_timestamp = JfrTicks::now(); > > Do you really need to use JfrTicks instead of Ticks here? If not, could you remove all references and includes of JfrTicks? We usually use pass in Ticks when we send JFR events. Fixed. > src/hotspot/share/prims/whitebox.cpp line 44: > >> 42: #include "gc/shared/genArguments.hpp" >> 43: #include "gc/shared/genCollectedHeap.hpp" >> 44: #include "gc/shared/gcLocker.inline.hpp" > > Sort includes. Fixed. > src/hotspot/share/jfr/metadata/metadata.xml line 1080: > >> 1078: >> 1079: >> 1080: > > You add this between two Shenandoah events. Could you put it somewhere where it's not splitting up a group of events? Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From kbarrett at openjdk.java.net Mon Jan 18 15:08:12 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Jan 2021 15:08:12 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v3] In-Reply-To: References: Message-ID: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: - update copyrights - remove type aliases for OopStorageSet::WeakId ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1862/files - new: https://git.openjdk.java.net/jdk/pull/1862/files/3a4d5b78..ebe50e35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=01-02 Stats: 48 lines in 17 files changed: 6 ins; 8 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862 From kim.barrett at oracle.com Mon Jan 18 15:10:22 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 Jan 2021 10:10:22 -0500 Subject: RFR: 8256814: WeakProcessorPhases may be redundant In-Reply-To: <39C4F5B9-FA6C-4E5C-95A3-2A1F7C1299B3@oracle.com> References: <33C0F891-C26A-4B41-B85A-84627676071D@oracle.com> <39C4F5B9-FA6C-4E5C-95A3-2A1F7C1299B3@oracle.com> Message-ID: <9D910C33-7007-46B3-8638-93CC65E267FC@oracle.com> > On Jan 18, 2021, at 5:41 AM, Kim Barrett wrote: > >> On Jan 16, 2021, at 10:42 AM, Kim Barrett wrote: >> >>> On Jan 12, 2021, at 5:12 AM, Stefan Karlsson wrote: >>> src/hotspot/share/gc/shared/weakProcessorTimes.hpp line 37: >>> >>>> 35: class WeakProcessorTimes { >>>> 36: public: >>>> 37: using StorageId = OopStorageSet::WeakId; >>> >>> Could be private. >> >> Here too I think public functions whose type signatures involve identifiers >> that can't be used by clients is problematic. But I renamed it from >> StorageId to WeakId; looking at it again, the more generic name seems >> counterproductive here. > > After thinking about this some more, I?m going to see what it looks like to just > eliminate the type alias entirely. Done. The type alias didn?t really add much, just shortening some a few uses and signatures, not really enough to justify adding it. I also updated the copyrights for 2021. From mgronlun at openjdk.java.net Mon Jan 18 16:17:49 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Jan 2021 16:17:49 GMT Subject: Integrated: 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: On Sun, 17 Jan 2021 15:10:46 GMT, Markus Gr?nlund wrote: > Greetings, > > please help review this small adjustment. Full details in the bug. > > Testing: jdk_jfr, stress testing > > Thanks > Markus This pull request has now been integrated. Changeset: 061ffc47 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/061ffc47 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/2116 From rkennke at openjdk.java.net Mon Jan 18 18:23:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 18 Jan 2021 18:23:47 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v3] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 15:08:12 GMT, Kim Barrett wrote: >> Please review this change which eliminates the WeakProcessorPhase class. >> >> The OopStorageSet class is changed to provide scoped enums for the different >> categories: StrongId, WeakId, and Id (for the union of strong and weak). >> An accessor is provided for obtaining the storage corresponding to a >> category value. >> >> Various other enumerator ranges, array sizes and indices, and iterations are >> derived directly from the corresponding OopStorageSet category's enum range. >> >> Iteration over a category of enumerators can be done via EnumIterator. The >> iteration over storage objects makes use of that enum iteration, rather than >> having a bespoke implementation. Some use-cases need iteration of the >> enumerators, with storage lookup from the enumerator; other use-cases just >> need the storage objects. >> >> Testing: >> mach5 tier1-6 >> Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - update copyrights > - remove type aliases for OopStorageSet::WeakId Changes look good to me! I also ran some tests with Shenandoah and they look good too! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1862 From ysuenaga at openjdk.java.net Tue Jan 19 01:37:49 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 19 Jan 2021 01:37:49 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> <_zddsYkBbuHo_AfH3Ld3jnBUID7EnOvIhjwK2qm67sw=.3ad67eeb-8a25-4cae-80cf-d34b73d65723@github.com> Message-ID: On Fri, 15 Jan 2021 09:59:08 GMT, Markus Gr?nlund wrote: > As you say: "move throwing events into HotSpot makes big change" - I agree and Erik has already stated that many have tried already to make this kind of change, but attempts have faltered because the impact / disruptions are unclear. Do you fully understand the consequences of how it will change the way users work with exceptions in JFR? If C2 optimizations now start to remove exception sites that were previously reported? I believe the user who hooks JavaErrorThrow event wants to know the occurrence of OOME. Let's think about the user who want to restart the system automatically if the fatal error happens. The user defines OOME as an event that should be restarted and monitored by remote recording. If JavaErrorThrow event for OOME cannot be hooked, it is meaningless. I understand all `Throwable` s cannot be hooked due to C2 optimization, but most of them should be hooked. They should be hooked as well as unified logging at least, and we can do it like this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From ddong at openjdk.java.net Tue Jan 19 06:56:10 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 19 Jan 2021 06:56:10 GMT Subject: RFR: 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes Message-ID: Could I have a review of this small fix? In the current implementation, ChunkInputStream#available only returns the available size of the current stream, which is strange for the user. ------------- Commit messages: - 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes Changes: https://git.openjdk.java.net/jdk/pull/2138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2138&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259956 Stats: 96 lines in 2 files changed: 84 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2138/head:pull/2138 PR: https://git.openjdk.java.net/jdk/pull/2138 From egahlin at openjdk.java.net Tue Jan 19 12:50:38 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Jan 2021 12:50:38 GMT Subject: RFR: 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 06:50:21 GMT, Denghui Dong wrote: > Could I have a review of this small fix? > > In the current implementation, ChunkInputStream#available only returns the available size of the current stream, which is strange for the user. Hi Denghui, Looks reasonable, but I will do a proper review of this and your other PRs once everything is set for JDK 16. Erik ------------- PR: https://git.openjdk.java.net/jdk/pull/2138 From egahlin at openjdk.java.net Tue Jan 19 15:17:56 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Jan 2021 15:17:56 GMT Subject: RFR: 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 17:16:16 GMT, Markus Gr?nlund wrote: > Greetings, > > please review this changeset to let JFR work in situations where the VM is built with -fno-elide-constructors. > > The original means to interface with the JfrVersionSystem employed handles, but to work correctly, the handles relied on Return Value Optimization (RVO), which was a lazy assumption on my part. > > The handles will now employ copy-and-swap for reference counting. > > Testing: jdk_jfr with (and without) build option -fno-elide-constructors > > Thanks to Kim Barrett @kimbarrett for filing this issue. > > Thank you > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2083 From mgronlun at openjdk.java.net Tue Jan 19 15:30:40 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Jan 2021 15:30:40 GMT Subject: Integrated: 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 17:16:16 GMT, Markus Gr?nlund wrote: > Greetings, > > please review this changeset to let JFR work in situations where the VM is built with -fno-elide-constructors. > > The original means to interface with the JfrVersionSystem employed handles, but to work correctly, the handles relied on Return Value Optimization (RVO), which was a lazy assumption on my part. > > The handles will now employ copy-and-swap for reference counting. > > Testing: jdk_jfr with (and without) build option -fno-elide-constructors > > Thanks to Kim Barrett @kimbarrett for filing this issue. > > Thank you > Markus This pull request has now been integrated. Changeset: 5cfb36e7 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/5cfb36e7 Stats: 215 lines in 5 files changed: 74 ins; 98 del; 43 mod 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors Reviewed-by: egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/2083 From mgronlun at openjdk.java.net Tue Jan 19 17:00:04 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Jan 2021 17:00:04 GMT Subject: Integrated: 8259995: Missing comma to separate years in copyright header Message-ID: Greetings, please review this adjustment to the copyright headers. Thanks Markus ------------- Commit messages: - 8259995: Missing comma to separate years in copyright header Changes: https://git.openjdk.java.net/jdk/pull/2149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259995 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2149/head:pull/2149 PR: https://git.openjdk.java.net/jdk/pull/2149 From egahlin at openjdk.java.net Tue Jan 19 17:00:04 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Jan 2021 17:00:04 GMT Subject: Integrated: 8259995: Missing comma to separate years in copyright header In-Reply-To: References: Message-ID: <0TFRXKLDmI1gGEdLjzsneBPtHxcGwzan5MgXInjRmsc=.ada50af7-f3a5-4ac4-9b7f-9ccf42cd4831@github.com> On Tue, 19 Jan 2021 16:50:25 GMT, Markus Gr?nlund wrote: > Greetings, > > please review this adjustment to the copyright headers. > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2149 From mgronlun at openjdk.java.net Tue Jan 19 17:00:04 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Jan 2021 17:00:04 GMT Subject: Integrated: 8259995: Missing comma to separate years in copyright header In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 16:50:25 GMT, Markus Gr?nlund wrote: > Greetings, > > please review this adjustment to the copyright headers. > > Thanks > Markus This pull request has now been integrated. Changeset: 5d8861b0 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/5d8861b0 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8259995: Missing comma to separate years in copyright header Reviewed-by: egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/2149 From coffeys at openjdk.java.net Tue Jan 19 17:59:55 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Tue, 19 Jan 2021 17:59:55 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code Message-ID: Correction of NPE and updating of test cases. Minor refactoring of test library also. ------------- Commit messages: - 8255348: NPE in PKIXCertPathValidator event logging code Changes: https://git.openjdk.java.net/jdk/pull/2150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2150&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255348 Stats: 83 lines in 6 files changed: 60 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2150/head:pull/2150 PR: https://git.openjdk.java.net/jdk/pull/2150 From ddong at openjdk.java.net Wed Jan 20 03:42:51 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 20 Jan 2021 03:42:51 GMT Subject: RFR: 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 12:48:00 GMT, Erik Gahlin wrote: > Hi Denghui, > > Looks reasonable, but I will do a proper review of this and your other PRs once everything is set for JDK 16. > > Erik okay, thanks :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2138 From github.com+5010047+kelthuzadx at openjdk.java.net Wed Jan 20 05:38:51 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Wed, 20 Jan 2021 05:38:51 GMT Subject: RFR: 8259774: samplethreads option does not work for jfr thread sampler In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 04:25:20 GMT, Erik Gahlin wrote: >> Thanks to your explanation, it makes sense. I have some ideas about this option. I noticed that the current implementation of thread sampling is to traverse threads from ThreadsList and do sampling. The consequence of this is that the sampling event in the recording file becomes very confusing, and it is difficult for users to find what they expect. If the user expects to know the callings of a certain thread in a period, this is impossible, because the sampling event of this thread is not continuous. So I wonder if there is a way for users to specify the thread they want to sample, for example: >> $ jstack >> // get thread id that expectes to know >> $ jcmd pid JFR.configure samplethreads= > > There is no way to specify the thread. > > It is possible to reduce the period to 1 ms to increase the number samples. It might help to troubleshoot the issue, but it will also create lots of additional events for all threads. We have thought about adding per thread capabilities, like filtering or recording all events for a particular thread, but the main obstacle has been how to configure such a system. > > Plan is to simplify event configuration on command line and then see what features it will "unlock". Based on @egahlin 's comment and @mgronlun 's comment on JBS: > I think this request should be transformed into deprecating and removing the "samplethreads" option. It was introduced in 7u40 as an opt-out because thread sampling was new and incomplete. [mgronlun] > The flag should really be removed. Could be it is still there because it has not yet gone through deprecation process. [egahlin] I'm glad to deprecate this option, but I don?t know if it?s appropriate for me to do this deprecation work, i.e, will it break your existing deprecating process if I try to deprecate this option right now? ------------- PR: https://git.openjdk.java.net/jdk/pull/2079 From mullan at openjdk.java.net Thu Jan 21 19:47:43 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 21 Jan 2021 19:47:43 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code In-Reply-To: References: Message-ID: On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: > Correction of NPE and updating of test cases. Minor refactoring of test library also. src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 248: > 246: int anchorCertId = 0; > 247: X509Certificate trustedCert = anchor.getTrustedCert(); > 248: if (trustedCert != null) { You could use the `anchorCert` variable which was set earlier instead of calling `getTrustedCert()` again. src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 251: > 249: anchorCertId = trustedCert.hashCode(); > 250: } else { > 251: if (anchor.getCAPublicKey() != null) { Per the TrustAnchor API, you can't create a TrustAnchor with a null public key, so I don't think you need this check. ------------- PR: https://git.openjdk.java.net/jdk/pull/2150 From github.com+5010047+kelthuzadx at openjdk.java.net Fri Jan 22 08:41:49 2021 From: github.com+5010047+kelthuzadx at openjdk.java.net (Yang Yi) Date: Fri, 22 Jan 2021 08:41:49 GMT Subject: RFR: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording In-Reply-To: References: <93mX8mx_d2lQSIAmAKcNmWRDLTG1DmEX9VcHXcJlgsY=.e2d3849c-58c2-401a-8f5e-a1d2169e276a@github.com> <-FO81DUPZRkbDNrHru0yn0clNG9pGiRQ_4zL8H1iRFY=.768d9c79-312c-4657-b57d-1bc7b58d4472@github.com> Message-ID: On Fri, 8 Jan 2021 16:37:14 GMT, Erik Gahlin wrote: >> Thanks. I will make some changes and review it later today. > > I have reviewed the CSR, you can finalize it. > > Once approved, I will go over the code and do a final review. Please ping me if I forget. > > Thanks Hi @egahlin , can you help finalize [this CSR](https://bugs.openjdk.java.net/browse/JDK-8259479)? Joe Darcy requests some changes and he changes the status from FINALIZED to PROVISIONAL, I have refined it according to Joe Darcy's suggestion, it seems you need to review and finalize it again before Joe Darcy's CSR review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1904 From sjohanss at openjdk.java.net Fri Jan 22 09:37:53 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 22 Jan 2021 09:37:53 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:55:06 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > Refactor based on comments Some comments. src/hotspot/share/gc/shared/gcTraceSend.cpp line 354: > 352: > 353: void GCLockerTracer::start_gc_locker(const jint jni_lock_count) { > 354: assert(SafepointSynchronize::is_at_safepoint(), "sanity"); Maybe add assertions that `_jni_lock_count` and `_stall_count` is 0 to ensure this is not called multiple times for a single event. src/hotspot/share/gc/shared/gcTraceSend.cpp line 369: > 367: void GCLockerTracer::report_gc_locker() { > 368: Ticks zero; > 369: if (_needs_gc_start_timestamp != zero) { Why is this needed? src/hotspot/share/gc/shared/gcTraceSend.cpp line 372: > 370: EventGCLocker event(UNTIMED); > 371: if (event.should_commit()) { > 372: event.set_starttime(_needs_gc_start_timestamp); Shouldn't you also set the endtime using `event.set_endtime(...)`? src/hotspot/share/gc/shared/gcTraceSend.cpp line 378: > 376: } > 377: _needs_gc_start_timestamp = zero; > 378: _stall_count = 0; Any reason to not clear `_jni_lock_count`? It would be needed for the assert suggested above. ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From sean.coffey at oracle.com Fri Jan 22 13:13:55 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 22 Jan 2021 13:13:55 +0000 Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code In-Reply-To: References: Message-ID: <2195f270-b3d9-f92d-35ec-e83e3c93b883@oracle.com> Thanks for the comments Sean. Code updated. https://github.com/openjdk/jdk/pull/2150/commits/8a344a85303297f17a6e75e7c1f423c2d16c451a regards, Sean. On 21/01/2021 19:47, Sean Mullan wrote: > On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: > >> Correction of NPE and updating of test cases. Minor refactoring of test library also. > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 248: > >> 246: int anchorCertId = 0; >> 247: X509Certificate trustedCert = anchor.getTrustedCert(); >> 248: if (trustedCert != null) { > You could use the `anchorCert` variable which was set earlier instead of calling `getTrustedCert()` again. > > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 251: > >> 249: anchorCertId = trustedCert.hashCode(); >> 250: } else { >> 251: if (anchor.getCAPublicKey() != null) { > Per the TrustAnchor API, you can't create a TrustAnchor with a null public key, so I don't think you need this check. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2150 From coffeys at openjdk.java.net Fri Jan 22 13:15:17 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 22 Jan 2021 13:15:17 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code [v2] In-Reply-To: References: Message-ID: > Correction of NPE and updating of test cases. Minor refactoring of test library also. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Sean Mullan review update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2150/files - new: https://git.openjdk.java.net/jdk/pull/2150/files/a59dd592..8a344a85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2150&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2150&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2150/head:pull/2150 PR: https://git.openjdk.java.net/jdk/pull/2150 From kbarrett at openjdk.java.net Fri Jan 22 13:17:05 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 13:17:05 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v4] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 10:09:51 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into wpp4 >> - update copyrights >> - remove type aliases for OopStorageSet::WeakId >> - Merge branch 'master' into wpp4 >> - stefank review >> - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. > > I think this looks good. I have a few comments that I would like to get addressed, but they are not blockers if you want to proceed with what you have. Thanks @stefank , @tschatzl , @rkennke for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1862 From kbarrett at openjdk.java.net Fri Jan 22 13:17:05 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 13:17:05 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant [v4] In-Reply-To: References: Message-ID: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into wpp4 - update copyrights - remove type aliases for OopStorageSet::WeakId - Merge branch 'master' into wpp4 - stefank review - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. ------------- Changes: https://git.openjdk.java.net/jdk/pull/1862/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=03 Stats: 1052 lines in 25 files changed: 398 ins; 465 del; 189 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862 From kbarrett at openjdk.java.net Fri Jan 22 13:17:08 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Jan 2021 13:17:08 GMT Subject: Integrated: 8256814: WeakProcessorPhases may be redundant In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 04:59:28 GMT, Kim Barrett wrote: > Please review this change which eliminates the WeakProcessorPhase class. > > The OopStorageSet class is changed to provide scoped enums for the different > categories: StrongId, WeakId, and Id (for the union of strong and weak). > An accessor is provided for obtaining the storage corresponding to a > category value. > > Various other enumerator ranges, array sizes and indices, and iterations are > derived directly from the corresponding OopStorageSet category's enum range. > > Iteration over a category of enumerators can be done via EnumIterator. The > iteration over storage objects makes use of that enum iteration, rather than > having a bespoke implementation. Some use-cases need iteration of the > enumerators, with storage lookup from the enumerator; other use-cases just > need the storage objects. > > Testing: > mach5 tier1-6 > Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC This pull request has now been integrated. Changeset: 7ed8ba1c Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/7ed8ba1c Stats: 1052 lines in 25 files changed: 398 ins; 465 del; 189 mod 8256814: WeakProcessorPhases may be redundant Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Reviewed-by: stefank, tschatzl, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/1862 From ddong at openjdk.java.net Fri Jan 22 13:31:11 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 22 Jan 2021 13:31:11 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 09:17:45 GMT, Stefan Johansson wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor based on comments > > src/hotspot/share/gc/shared/gcTraceSend.cpp line 354: > >> 352: >> 353: void GCLockerTracer::start_gc_locker(const jint jni_lock_count) { >> 354: assert(SafepointSynchronize::is_at_safepoint(), "sanity"); > > Maybe add assertions that `_jni_lock_count` and `_stall_count` is 0 to ensure this is not called multiple times for a single event. Makes sense. Added. > src/hotspot/share/gc/shared/gcTraceSend.cpp line 369: > >> 367: void GCLockerTracer::report_gc_locker() { >> 368: Ticks zero; >> 369: if (_needs_gc_start_timestamp != zero) { > > Why is this needed? Because we can't assume that EventGCLocker is enabled when GC locker is started, in another word, at the beginning and end of the GC locker, whether EventGCLocker is enabled may be inconsistent. So check here if _needs_gc_start_timestamp is not zero, if it is not 0, it needs to reset _needs_gc_start_timestamp regardless of whether the event will be sent. > src/hotspot/share/gc/shared/gcTraceSend.cpp line 372: > >> 370: EventGCLocker event(UNTIMED); >> 371: if (event.should_commit()) { >> 372: event.set_starttime(_needs_gc_start_timestamp); > > Shouldn't you also set the endtime using `event.set_endtime(...)`? endtime will be set in event.commit() > src/hotspot/share/gc/shared/gcTraceSend.cpp line 378: > >> 376: } >> 377: _needs_gc_start_timestamp = zero; >> 378: _stall_count = 0; > > Any reason to not clear `_jni_lock_count`? It would be needed for the assert suggested above. There is no special reason, just to save memory access. It's okay for me to reset it. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Fri Jan 22 13:31:09 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 22 Jan 2021 13:31:09 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v3] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: add assertions and reset _jni_lock_count ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/c36d4f96..41641d8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=01-02 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Fri Jan 22 13:33:53 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 22 Jan 2021 13:33:53 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 09:35:04 GMT, Stefan Johansson wrote: > Some comments. Thanks for the review :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From mullan at openjdk.java.net Fri Jan 22 14:41:50 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 22 Jan 2021 14:41:50 GMT Subject: RFR: 8255348: NPE in PKIXCertPathValidator event logging code [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 13:15:17 GMT, Sean Coffey wrote: >> Correction of NPE and updating of test cases. Minor refactoring of test library also. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Sean Mullan review update Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2150 From coffeys at openjdk.java.net Fri Jan 22 15:34:41 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 22 Jan 2021 15:34:41 GMT Subject: Integrated: 8255348: NPE in PKIXCertPathValidator event logging code In-Reply-To: References: Message-ID: <2hqGUlO6rON1q2LX8p86ol_YA1BsSvDLV2oxtgQMsuo=.a3b4a0e7-cf57-47d7-a393-929c8a3a1091@github.com> On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: > Correction of NPE and updating of test cases. Minor refactoring of test library also. This pull request has now been integrated. Changeset: 18eb6d9e Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/18eb6d9e Stats: 77 lines in 6 files changed: 53 ins; 2 del; 22 mod 8255348: NPE in PKIXCertPathValidator event logging code Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/2150 From sjohanss at openjdk.java.net Sat Jan 23 15:19:40 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Sat, 23 Jan 2021 15:19:40 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 13:25:12 GMT, Denghui Dong wrote: >> src/hotspot/share/gc/shared/gcTraceSend.cpp line 369: >> >>> 367: void GCLockerTracer::report_gc_locker() { >>> 368: Ticks zero; >>> 369: if (_needs_gc_start_timestamp != zero) { >> >> Why is this needed? > > Because we can't assume that EventGCLocker is enabled when GC locker is started, in another word, at the beginning and end of the GC locker, whether EventGCLocker is enabled may be inconsistent. > > So check here if _needs_gc_start_timestamp is not zero, if it is not 0, it needs to reset _needs_gc_start_timestamp regardless of whether the event will be sent. Ok, so instead of sending an incomplete event you want to skip it? That might be correct but in that case I would prefer adding a helper `GCLockerTracer::is_started()`, that checks if the timestamp is set. That would make the intention more clear I think. This helper could assert that the event is enabled and it could also be used in `inc_stall_count()` since that one won't have any effect if the event is not "started". What do you think about that? ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Sun Jan 24 01:48:57 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sun, 24 Jan 2021 01:48:57 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: add GCLockerTracer::is_started() that makes the logic more clear ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/41641d8a..85987c58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=02-03 Stats: 13 lines in 2 files changed: 8 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Sun Jan 24 01:52:42 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sun, 24 Jan 2021 01:52:42 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:16:40 GMT, Stefan Johansson wrote: >> Because we can't assume that EventGCLocker is enabled when GC locker is started, in another word, at the beginning and end of the GC locker, whether EventGCLocker is enabled may be inconsistent. >> >> So check here if _needs_gc_start_timestamp is not zero, if it is not 0, it needs to reset _needs_gc_start_timestamp regardless of whether the event will be sent. > > Ok, so instead of sending an incomplete event you want to skip it? That might be correct but in that case I would prefer adding a helper `GCLockerTracer::is_started()`, that checks if the timestamp is set. That would make the intention more clear I think. This helper could assert that the event is enabled and it could also be used in `inc_stall_count()` since that one won't have any effect if the event is not "started". What do you think about that? Good idea. Updated. But I didn't add the assertion that makes sure the event is enabled, because it may be disabled between GCLockerTracer::start_gc_locker and GCLockerTracer::inc_stall_count(). ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From sjohanss at openjdk.java.net Mon Jan 25 18:13:45 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 25 Jan 2021 18:13:45 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: <_sVYAZQIiJSDJlj5QO29F6uF0k2V0ApDtlFuMwVLkwA=.d34f9b7e-a6f5-4131-9299-2e570cf3cf04@github.com> On Sun, 24 Jan 2021 01:48:57 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > add GCLockerTracer::is_started() that makes the logic more clear I think this looks good now but please await a second reviewer. I took if for a spin in out internal testing and tier1-2 looks ok as well as the JFR tests. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From tschatzl at openjdk.java.net Tue Jan 26 09:52:43 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 26 Jan 2021 09:52:43 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Sun, 24 Jan 2021 01:48:57 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > add GCLockerTracer::is_started() that makes the logic more clear Changes requested by tschatzl (Reviewer). test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 34: > 32: import sun.hotspot.WhiteBox; > 33: > 34: /** This block should be the first thing in the test after the copyright notice. test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 116: > 114: ts[i] = new Thread(() -> { > 115: STALL_COUNT_SIGNAL.countDown(); > 116: for (int j = 0; j < LOOP; j++) { Since the test already uses WhiteBox, please use whitebox to trigger a gc instead of this dodgy method. src/hotspot/share/gc/shared/gcLocker.cpp line 101: > 99: verify_critical_count(); > 100: _needs_gc = true; > 101: GCLockerTracer::start_gc_locker(_jni_lock_count); Not really convinced that passing `_jni_lock_count` here gives a lot of information: this is the number of threads in a critical section at the point of the first thread needing a gc. It's probably better than nothing. At least this information should be added to the description of the event (if that is possible). test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 2: > 1: /* > 2: * Copyright (c) 2021 Alibaba Group Holding Limited. All Rights Reserved. Would it be possible to keep with the general format of copyright messages in other code, i.e. "Copyright (c) , . ..."? I.e. if possible please add a comma after the year. src/hotspot/share/jfr/metadata/metadata.xml line 1095: > 1093: > 1094: > 1095: Please add descriptions to the fields as mentioned above. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Tue Jan 26 11:06:57 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 26 Jan 2021 11:06:57 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v5] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: Add descriptions and fix the format problem ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/85987c58..a5d0e0a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=03-04 Stats: 23 lines in 2 files changed: 11 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Tue Jan 26 11:07:00 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 26 Jan 2021 11:07:00 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:42:59 GMT, Thomas Schatzl wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> add GCLockerTracer::is_started() that makes the logic more clear > > src/hotspot/share/gc/shared/gcLocker.cpp line 101: > >> 99: verify_critical_count(); >> 100: _needs_gc = true; >> 101: GCLockerTracer::start_gc_locker(_jni_lock_count); > > Not really convinced that passing `_jni_lock_count` here gives a lot of information: this is the number of threads in a critical section at the point of the first thread needing a gc. It's probably better than nothing. At least this information should be added to the description of the event (if that is possible). I think this field can be used to judge whether there are many threads that are often in a critical section, but I am not sure if it really helps to analyze the problem., and just as you said, it's better than nothing. An appropriate description of this field has been added. > test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 116: > >> 114: ts[i] = new Thread(() -> { >> 115: STALL_COUNT_SIGNAL.countDown(); >> 116: for (int j = 0; j < LOOP; j++) { > > Since the test already uses WhiteBox, please use whitebox to trigger a gc instead of this dodgy method. Triggering a GC is not enough, I hope these threads could be stall by the GC locker(call GCLocker::stall_until_clear) so that a correct assertion of the number of stall count could be added. I think it could not be done by WhiteBox::youngGC/fullGC, please correct me if I'm wrong. > src/hotspot/share/jfr/metadata/metadata.xml line 1095: > >> 1093: >> 1094: >> 1095: > > Please add descriptions to the fields as mentioned above. added > test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021 Alibaba Group Holding Limited. All Rights Reserved. > > Would it be possible to keep with the general format of copyright messages in other code, i.e. "Copyright (c) , . ..."? I.e. if possible please add a comma after the year. Fixed. > test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 34: > >> 32: import sun.hotspot.WhiteBox; >> 33: >> 34: /** > > This block should be the first thing in the test after the copyright notice. Fixed. But I notice that there are many other tests that didn't comply with this rule. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From jbachorik at openjdk.java.net Tue Jan 26 13:42:50 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 26 Jan 2021 13:42:50 GMT Subject: RFR: 8247471: Enhance CPU load events with the actual elapsed CPU time Message-ID: A continuation of an RFR thread started last year - https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-June/001533.html This change adds the raw CPU time value to CPU load events (per-thread and per-process as well). The CPU time value is already known and used to calculate the load so adding it to the events does not incur any extra overhead while making it much easier for the end users to eg. aggregate and compare the active execution time per time period without the detailed knowledge how JFR computes and normalizes the CPU load. ------------- Commit messages: - Fix wording and remove unnecessary debug output - Fix jcheck - Merge branch 'master' into 8247471_cpuload_with_time - 8247471: Enhance CPU load events with the actual elapsed CPU time Changes: https://git.openjdk.java.net/jdk/pull/2186/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2186&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247471 Stats: 543 lines in 11 files changed: 238 ins; 205 del; 100 mod Patch: https://git.openjdk.java.net/jdk/pull/2186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2186/head:pull/2186 PR: https://git.openjdk.java.net/jdk/pull/2186 From jaroslav.bachorik at datadoghq.com Tue Jan 26 14:02:49 2021 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 26 Jan 2021 15:02:49 +0100 Subject: [discussion] 8242220: Capture JFR stack trace and thread other than the one the event is committed on Message-ID: Hello, I would like to start a discussion about the prototype PR: https://github.com/openjdk/jdk/pull/2238 allowing to commit an event on a custom Java thread. The reasons for this are explained in the PR but for an easier jumpstart I am attaching the PR description here: --- This is an early prototype of an enhanced Event.commit(thread) method which allows committing a JFR event on a custom java thread. This would allow, for example, having a scheduled 'sampling' thread generating events and filling them up with shared aggregation data and then committing them on behalf of a 'sampled' thread. Committing an event on the given thread means that the event will be associated with that particular thread, will receive the stack trace of that thread at that particular moment and, internally, will be written out using that thread's thread-local structures. The association is on 'best-effort' basis as the target thread may be terminated and gone by the time the event is committed and in that case the event will be committed on the caller thread and will be missing the stacktrace data. The change is rather trivial - extend the Event API to provide commit(Thread) method and then use thread-local handshake to fill in the stacktrace details of the indicated thread. The code changes are, however, more extensive as all the supporting classes need to be also aware of the new Event method. As already mentioned this is a very early prototype of this particular functionality. I am aware that finalizing this will take much more work but at least for DataDog this feature is quite useful and starting the discussion about it with a concrete piece of code seems to be the right way to go. --- Looking forward to hearing back on this topic! Cheers, -JB- From egahlin at openjdk.java.net Tue Jan 26 16:56:43 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 26 Jan 2021 16:56:43 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v5] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 11:06:57 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > Add descriptions and fix the format problem Marked as reviewed by egahlin (Reviewer). src/hotspot/share/jfr/metadata/metadata.xml line 1094: > 1092: > 1093: > 1094: I would suggest changing this to: "The number of Java threads in a critical section when the GC locker is started" "The number of Java threads stalled by the GC locker" src/hotspot/share/jfr/metadata/metadata.xml line 1093: > 1091: > 1092: > 1093: "GC Locker Information" is not very useful. Remove the description completely or provide more information. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Wed Jan 27 02:25:01 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 27 Jan 2021 02:25:01 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v5] In-Reply-To: References: Message-ID: <1a-o8CEtmWfhrp2K9gzs8pqgt_ISmH8BEivGEqS4Rlo=.d16eda2f-b559-4083-a16e-25a1dd0d325a@github.com> On Tue, 26 Jan 2021 16:49:37 GMT, Erik Gahlin wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> Add descriptions and fix the format problem > > src/hotspot/share/jfr/metadata/metadata.xml line 1094: > >> 1092: >> 1093: >> 1094: > > I would suggest changing this to: > > "The number of Java threads in a critical section when the GC locker is started" > "The number of Java threads stalled by the GC locker" changed. > src/hotspot/share/jfr/metadata/metadata.xml line 1093: > >> 1091: >> 1092: >> 1093: > > "GC Locker Information" is not very useful. Remove the description completely or provide more information. removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Wed Jan 27 02:25:00 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 27 Jan 2021 02:25:00 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v6] In-Reply-To: References: Message-ID: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: improve descriptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2088/files - new: https://git.openjdk.java.net/jdk/pull/2088/files/a5d0e0a3..7efac60f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2088&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2088/head:pull/2088 PR: https://git.openjdk.java.net/jdk/pull/2088 From sjohanss at openjdk.java.net Wed Jan 27 14:34:40 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 27 Jan 2021 14:34:40 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 09:50:02 GMT, Thomas Schatzl wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> add GCLockerTracer::is_started() that makes the logic more clear > > Changes requested by tschatzl (Reviewer). Since @tschatzl requested changes yesterday I will wait for him to sponsor this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From tschatzl at openjdk.java.net Wed Jan 27 15:31:43 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Jan 2021 15:31:43 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 11:03:15 GMT, Denghui Dong wrote: >> test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java line 116: >> >>> 114: ts[i] = new Thread(() -> { >>> 115: STALL_COUNT_SIGNAL.countDown(); >>> 116: for (int j = 0; j < LOOP; j++) { >> >> Since the test already uses WhiteBox, please use whitebox to trigger a gc instead of this dodgy method. > > Triggering a GC is not enough, I hope these threads could be stalled by the GC locker(call GCLocker::stall_until_clear) so that a correct assertion of the number of stall count could be added. > I think it could not be done by WhiteBox::youngGC/fullGC, please correct me if I'm wrong. I agree, although this is more a theoretical concern since it's not checked. Let's keep this for now as is though. ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From tschatzl at openjdk.java.net Wed Jan 27 15:31:42 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Jan 2021 15:31:42 GMT Subject: RFR: 8259808: Add JFR event to detect GC locker stall [v6] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 02:25:00 GMT, Denghui Dong wrote: >> GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. >> >> For the test purpose, I add two Whitebox methods to lock/unlock critical. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > improve descriptions Looks good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Wed Jan 27 15:31:46 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 27 Jan 2021 15:31:46 GMT Subject: Integrated: 8259808: Add JFR event to detect GC locker stall In-Reply-To: References: Message-ID: <0jX_KfLI5gBLg8Ew1dRZnDcMpwWMB-xysSIoARaCE_w=.144f412d-4b8f-4dc6-bc64-b2d23607ec90@github.com> On Fri, 15 Jan 2021 02:42:20 GMT, Denghui Dong wrote: > GC locker will stall the operation of GC, resulting in some Java threads can not continue to run until GC locker is released, thus affecting the response time of the application. Add a JFR event to report this information is helpful to detect this issue. > > For the test purpose, I add two Whitebox methods to lock/unlock critical. This pull request has now been integrated. Changeset: 311a0a91 Author: Denghui Dong Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/311a0a91 Stats: 224 lines in 10 files changed: 224 ins; 0 del; 0 mod 8259808: Add JFR event to detect GC locker stall Reviewed-by: sjohanss, tschatzl, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/2088 From ddong at openjdk.java.net Thu Jan 28 05:56:00 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 28 Jan 2021 05:56:00 GMT Subject: RFR: 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes [v2] In-Reply-To: References: Message-ID: > Could I have a review of this small fix? > > In the current implementation, ChunkInputStream#available only returns the available size of the current stream, which is strange for the user. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: fix format problem ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2138/files - new: https://git.openjdk.java.net/jdk/pull/2138/files/6e0cedc2..00f59e89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2138&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2138&range=00-01 Stats: 15 lines in 1 file changed: 7 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2138/head:pull/2138 PR: https://git.openjdk.java.net/jdk/pull/2138 From ddong at openjdk.java.net Thu Jan 28 17:01:52 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 28 Jan 2021 17:01:52 GMT Subject: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) Message-ID: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> hi, Could I have a review of this fix? If we run the following code snippet, will get a crash class JFRDemo { public static void main(String[] args) { Recording r = new Recording(); r.enable("MyEvent"); r.start(); MyEvent event = new MyEvent(); event.begin(); event.clazz = long.class; event.commit(); } } @Enabled(true) @StackTrace(true) @Registered(true) @Name("MyEvent") class MyEvent extends Event { @Label("Class") public Class clazz; } ------------- Commit messages: - 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) Changes: https://git.openjdk.java.net/jdk/pull/2295/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260589 Stats: 138 lines in 3 files changed: 138 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2295/head:pull/2295 PR: https://git.openjdk.java.net/jdk/pull/2295 From egahlin at openjdk.java.net Thu Jan 28 23:27:53 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 28 Jan 2021 23:27:53 GMT Subject: [jdk16] RFR: 8257215: JFR: TestRotate.java fails intermittently Message-ID: Hi, Could I have review of an intermittent product issue. It happens about 1 out of 300 the test is run. By design, chunk files that have been parsed are deleted. Problem is that the filename could be reused, which causes issues. This happens on the server, where the files are read before they are transfered over the network, and on the client when chunks are read from the local repository. The logic for creating the chunk file names is now in a separate class (ChunkFilename) so it can be shared by server and client. Another problem was the clock source being used when purging files. It was not always the same as when timestamp was taken from the chunk. Testing: Ran TestRotate.java 2100 times without failure Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Cleaning up - Improve chunk filename - Initial Changes: https://git.openjdk.java.net/jdk16/pull/131/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=131&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257215 Stats: 226 lines in 14 files changed: 141 ins; 56 del; 29 mod Patch: https://git.openjdk.java.net/jdk16/pull/131.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/131/head:pull/131 PR: https://git.openjdk.java.net/jdk16/pull/131 From ddong at openjdk.java.net Fri Jan 29 01:49:57 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 29 Jan 2021 01:49:57 GMT Subject: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) [v2] In-Reply-To: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> References: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> Message-ID: > hi, > > Could I have a review of this fix? > > If we run the following code snippet, will get a crash > class JFRDemo { > public static void main(String[] args) { > Recording r = new Recording(); > r.enable("MyEvent"); > r.start(); > > MyEvent event = new MyEvent(); > event.begin(); > event.clazz = long.class; > event.commit(); > } > } > > @Enabled(true) > @StackTrace(true) > @Registered(true) > @Name("MyEvent") > class MyEvent extends Event { > > @Label("Class") > public Class clazz; > } Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: clean doc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2295/files - new: https://git.openjdk.java.net/jdk/pull/2295/files/d2d7477a..0ba1623c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2295/head:pull/2295 PR: https://git.openjdk.java.net/jdk/pull/2295 From ddong at openjdk.java.net Fri Jan 29 08:48:57 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 29 Jan 2021 08:48:57 GMT Subject: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) [v3] In-Reply-To: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> References: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> Message-ID: > hi, > > Could I have a review of this fix? > > If we run the following code snippet, will get a crash > class JFRDemo { > public static void main(String[] args) { > Recording r = new Recording(); > r.enable("MyEvent"); > r.start(); > > MyEvent event = new MyEvent(); > event.begin(); > event.clazz = long.class; > event.commit(); > } > } > > class MyEvent extends Event { > > @Label("Class") > public Class clazz; > } Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: improve patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2295/files - new: https://git.openjdk.java.net/jdk/pull/2295/files/0ba1623c..811690c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2295&range=01-02 Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2295/head:pull/2295 PR: https://git.openjdk.java.net/jdk/pull/2295 From egahlin at openjdk.java.net Fri Jan 29 13:06:03 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 29 Jan 2021 13:06:03 GMT Subject: [jdk16] RFR: 8257215: JFR: Events dropped when streaming over a chunk rotation [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I have review of an intermittent product issue. It happens about 1 out of 300 the test is run. > > By design, chunk files that have been parsed are deleted. Problem is that the filename could be reused, which causes issues. This happens on the server, where the files are read before they are transfered over the network, and on the client when chunks are read from the local repository. > > The logic for creating the chunk file names is now in a separate class (ChunkFilename) so it can be shared by server and client. Another problem was the clock source being used when purging files. It was not always the same as when timestamp was taken from the chunk. > > Testing: Ran TestRotate.java 2100 times without failure > > Testing: jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Removed unused code ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/131/files - new: https://git.openjdk.java.net/jdk16/pull/131/files/20bb01d7..33825ab0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=131&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=131&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/131.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/131/head:pull/131 PR: https://git.openjdk.java.net/jdk16/pull/131 From mgronlun at openjdk.java.net Fri Jan 29 13:16:41 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 29 Jan 2021 13:16:41 GMT Subject: [jdk16] RFR: 8257215: JFR: Events dropped when streaming over a chunk rotation [v2] In-Reply-To: References: Message-ID: <4cowPyZtoyBC_wW2OwFSSsJ1ULLWT0Ip66PCoCsd6hw=.2f29b8ae-c30d-4c4d-8745-c187a96dceac@github.com> On Fri, 29 Jan 2021 13:06:03 GMT, Erik Gahlin wrote: >> Hi, >> >> Could I have review of an intermittent product issue. It happens about 1 out of 300 the test is run. >> >> By design, chunk files that have been parsed are deleted. Problem is that the filename could be reused, which causes issues. This happens on the server, where the files are read before they are transfered over the network, and on the client when chunks are read from the local repository. >> >> The logic for creating the chunk file names is now in a separate class (ChunkFilename) so it can be shared by server and client. Another problem was the clock source being used when purging files. It was not always the same as when timestamp was taken from the chunk. >> >> Testing: Ran TestRotate.java 2100 times without failure >> >> Testing: jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused code Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/131 From ddong at openjdk.java.net Sun Jan 31 13:33:51 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sun, 31 Jan 2021 13:33:51 GMT Subject: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) In-Reply-To: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> References: <7Jps9Sq1KlTAc3TUYWGzD23tkuzO_DR0Jah1JMHE_JI=.20407a00-1795-46c8-a7e3-c3225636ccd6@github.com> Message-ID: On Thu, 28 Jan 2021 16:55:41 GMT, Denghui Dong wrote: > hi, > > Could I have a review of this fix? > > If we run the following code snippet, will get a crash > class JFRDemo { > public static void main(String[] args) { > Recording r = new Recording(); > r.enable("MyEvent"); > r.start(); > > MyEvent event = new MyEvent(); > event.begin(); > event.clazz = long.class; > event.commit(); > } > } > > class MyEvent extends Event { > > @Label("Class") > public Class clazz; > } Add some information to facilitate this issue to be reviewed more easily. We will get a crash if we run the above code,, and the stack trace is as follows: Stack: [0x00007fa12b2f3000,0x00007fa12b3f4000], sp=0x00007fa12b3f2790, free space=1021k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x89d649] JfrTraceIdLoadBarrier::load(_jclass*)+0x39 V [libjvm.so+0x86090e] jfr_class_id+0x7e j jdk.jfr.internal.JVM.getClassIdNonIntrinsic(Ljava/lang/Class;)J+0 jdk.jfr j jdk.jfr.internal.EventWriter.putClass(Ljava/lang/Class;)V+14 jdk.jfr j jdk.jfr.internal.handlers.EventHandler1699_1612098965420-78137.write(JJLjava/lang/Class;)V+35 jdk.jfr j MyEvent.commit()V+73 j JFRCrashTest.main([Ljava/lang/String;)V+39 v ~StubRoutines::call_stub V [libjvm.so+0x82aef5] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x2d5 V [libjvm.so+0x8be315] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.0] [clone .constprop.1]+0x345 V [libjvm.so+0x8c0b3f] jni_CallStaticVoidMethod+0x12f C [libjli.so+0x4647] JavaMain+0xd27 C [libjli.so+0x8079] ThreadJavaMain+0x9 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j jdk.jfr.internal.JVM.getClassIdNonIntrinsic(Ljava/lang/Class;)J+0 jdk.jfr j jdk.jfr.internal.EventWriter.putClass(Ljava/lang/Class;)V+14 jdk.jfr j jdk.jfr.internal.handlers.EventHandler1699_1612098965420-78137.write(JJLjava/lang/Class;)V+35 jdk.jfr j MyEvent.commit()V+73 j JFRCrashTest.main([Ljava/lang/String;)V+39 v ~StubRoutines::call_stub The root cause is that basic types, including void, do not have corresponding Klass objects inside the virtual machine, so call java_lang_Class::as_Klass will return NULL and crash in JfrTraceIdLoadBarrier::load finally. My solution is adding two serializers, one for the names of basic types, and one for basic types. I am not sure about the setting of the class loader is right or not, I currently set it to 0 directly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2295