From egahlin at openjdk.org Mon Aug 1 16:17:30 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 1 Aug 2022 16:17:30 GMT Subject: [jdk19] RFR: 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0' Message-ID: Could I have a review of change that fixes an intermittently test failure. The classes are garbage collected before they are being recorded by JFR. The fix is to add a hard reference to them. I also added a call to System.gc() to ensure the test is not sensitive to garbage collections. Testing: test/jdk/jdk/jfr/ and test/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk19/pull/158/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=158&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291524 Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk19/pull/158.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/158/head:pull/158 PR: https://git.openjdk.org/jdk19/pull/158 From hseigel at openjdk.org Tue Aug 2 14:35:06 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 2 Aug 2022 14:35:06 GMT Subject: [jdk19] RFR: 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0' In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 14:53:33 GMT, Erik Gahlin wrote: > Could I have a review of change that fixes an intermittent test failure. The classes are garbage collected before they are being recorded by JFR. The fix is to add a hard reference to them. I also added a call to System.gc() to ensure the test is not sensitive to garbage collections. > > Testing: test/jdk/jdk/jfr/ and test/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java > > Thanks > Erik Changes look good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk19/pull/158 From egahlin at openjdk.org Tue Aug 2 14:44:36 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 2 Aug 2022 14:44:36 GMT Subject: [jdk19] Integrated: 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0' In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 14:53:33 GMT, Erik Gahlin wrote: > Could I have a review of change that fixes an intermittent test failure. The classes are garbage collected before they are being recorded by JFR. The fix is to add a hard reference to them. I also added a call to System.gc() to ensure the test is not sensitive to garbage collections. > > Testing: test/jdk/jdk/jfr/ + 100 times test/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java > > Thanks > Erik This pull request has now been integrated. Changeset: 54c093ab Author: Erik Gahlin URL: https://git.openjdk.org/jdk19/commit/54c093ab0e71cfa80e62e54c5cb7aa12059e821b Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0' Reviewed-by: hseigel ------------- PR: https://git.openjdk.org/jdk19/pull/158 From dholmes at openjdk.org Wed Aug 3 00:19:22 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 00:19:22 GMT Subject: RFR: Merge jdk19 Message-ID: <2CCTZaFS6i35mR6AqKEqdGPhtsgieCwbblUspK8nWk8=.d5da1a39-4346-4dfc-897b-cc6dad2249ee@github.com> Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0' - 8291512: Snippetize modules API examples The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9720&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9720&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9720/files Stats: 33 lines in 6 files changed: 6 ins; 9 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9720.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9720/head:pull/9720 PR: https://git.openjdk.org/jdk/pull/9720 From dholmes at openjdk.org Wed Aug 3 05:13:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 05:13:42 GMT Subject: Withdrawn: Merge jdk19 In-Reply-To: <2CCTZaFS6i35mR6AqKEqdGPhtsgieCwbblUspK8nWk8=.d5da1a39-4346-4dfc-897b-cc6dad2249ee@github.com> References: <2CCTZaFS6i35mR6AqKEqdGPhtsgieCwbblUspK8nWk8=.d5da1a39-4346-4dfc-897b-cc6dad2249ee@github.com> Message-ID: On Wed, 3 Aug 2022 00:12:38 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9720 From dholmes at openjdk.org Wed Aug 3 05:19:01 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 05:19:01 GMT Subject: RFR: Merge jdk19 Message-ID: Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8291524: jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java Value not equal to 2, field='hiddenClassCount', value='0' - 8291512: Snippetize modules API examples The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9721&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9721&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9721/files Stats: 33 lines in 6 files changed: 6 ins; 9 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9721.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9721/head:pull/9721 PR: https://git.openjdk.org/jdk/pull/9721 From dholmes at openjdk.org Wed Aug 3 08:14:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Aug 2022 08:14:45 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 05:10:51 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 0971d346 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/0971d3464609bf4124df460ea73ff761d7e0f7b2 Stats: 33 lines in 6 files changed: 6 ins; 9 del; 18 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9721 From Matthew.Carter at microsoft.com Wed Aug 10 23:24:11 2022 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Wed, 10 Aug 2022 23:24:11 +0000 Subject: Proposal: should we add a 'clip' command to the jfr tool? In-Reply-To: References: Message-ID: Hi Erik I agree that adding clip to scrub would make the commend cumbersome even though it would be performant. Answering your questions: Is the purpose to reduce the size of the recording to be able to open it in JMC?? Answer: yes this is one of the benefits Divide the recording into smaller pieces, for example, at most 5 minutes each so they are more convenient to work with?? Answer: again yes, while I considered a 'slice' command here (slice into 10 pieces or slice into 6 minute clips, this can easily be achieved with some scripting once the clip functionality exists [and is in fact what I've done locally]); also the naming of the slices likely wouldn't satisfy everyone and so to keep it simple lets not try this Pick out a certain time interval, for example where you have an indication the application/JVM didn't respond? Answer: yes, here I used three parameters to the clip command, they can be used individually and also in combinations of two; start, end and length (these where specified in s(econds), m(inutes). h(ours) and can have negative values in order to 'clip to last 5 minutes' etc). Might make sense to also support datetime whilst more cumbersome to specify manully, can help automated clipping of JFR files based on an event time Is there a need to use this in combination with options to limit the size, similar to exist today with jcmd JFR.dump Answer: I feel that if you already have a JFR file then making it smaller should not present any issues; also asking for a clip of length N and then getting a clip of length N-m makes it hard to programmatically 'slice' a clip, i..e you'd have to account for the events in the new clip to understand where to make the next slice to avoid losing data One artifact of the implementation to support 'scrub' is that the duration of the JFR file doesn't change, at first I thought this would be an issue but i actually like it esp. when visualizing in JMC (you can see where the clip was in the original recording). Hopefully that answers your questions so far Thanks again Mat Sent from Outlook From: Erik Gahlin Sent: Monday, July 25, 2022 3:29 AM To: Mat Carter ; Erik Gahlin ; hotspot-jfr-dev at openjdk.java.net Subject: Re: Proposal: should we add a 'clip' command to the jfr tool? ? Hi Mat, I think there is a use case for removing events with respect to time. A common use case for the 'disassemble' command today is to reduce the size of the recording, but it's unintuitive and cumbersome to use as it is based on chunks. I think the capability can be included in the existing 'scrub' command, but I can also see the use case for a separate command if 'scrub' gets too many options so it's hard for users to discover and understand how to use it. Time-based filtering has been mentioned before: https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2022-February/003584.html Before discussing the implementation, it would be interesting to hear how you want to use it. Is the purpose to reduce the size of the recording to be able to open it in JMC??Divide the recording into smaller pieces, for example, at most 5 minutes each so they are more convenient to work with??Pick out a certain time interval, for example where you have an indication the application/JVM didn't respond? Is there a need to use this in combination with options to limit the size, similar to exist today with jcmd JFR.dump Thanks Erik From: Mat Carter Sent: Tuesday, July 12, 2022 10:12 PM To: Erik Gahlin ; hotspot-jfr-dev at openjdk.java.net Subject: Proposal: should we add a 'clip' command to the jfr tool? ? I'd like to propose that we add a command that filters based on time (clip perhaps) While working with large JFR files from jdk8 and jdk11 jvms I stumbled upon the 'jfr scrub' command that was introduced in 19. I used the 'jfr summary' to get a list of events and programmatically split the JFR into a JFR for each eventtype, but the data can still be unwieldy especially when converted to JSON. Given that 'jfr scrub' introduced the write(newJfrFile, predicate) method I wrote a java app to clip the JFR file based on a period of time (i hadn't seen the example in the JBS issue[1]), so now I can clip a JFR recording both horizontally (by events) and vertically (by time) and generate slices that are easier for JMC and other tools to parse (JMC would crash alot with large data) I took a stab at writing 'jfr clip' locally (based on scrub) and can share that in a new JBS issue if it's felt by this group that its a worthy addition to the jfr tool Again, I know that developers can write this themselves, but I feel it would be a nice convenience to have this in the jfr tool Alternatively, we could extend 'jfr scrub' to handle both event filters and a time region Cheers Mat [1]?https://bugs.openjdk.org/browse/JDK-8271585 [JDK-8271585] JFR: Scrub recording data - Java Bug System JDK; JDK-8271585; JFR: Scrub recording data. Log In. Export bugs.openjdk.org Sent from Outlook From: hotspot-jfr-dev on behalf of Erik Gahlin Sent: Tuesday, May 17, 2022 9:47 PM To: hotspot-jfr-dev at openjdk.java.net Subject: Integrated: 8286706: JFR: 'jfr scrub' should overwrite output ? On Mon, 16 May 2022 14:04:43 GMT, Erik Gahlin wrote: > Could I have a review of a change that makes the 'jfr scrub' overwrite the output file if it already exists. > > Testing: /test/jdk/jdk/jfr/tool? (Mac, Linux, Windows) > > Thanks > Erik This pull request has now been integrated. Changeset: ab144190 Author:??? Erik Gahlin URL:?????? https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fcommit%2Fab144190c9951f2a9a3acf30db4b570484d5f751&data=05%7C01%7Cmatthew.carter%40microsoft.com%7C6f907133f0514919728708da3889a4f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637884461083849921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zzPR1OA6evAeRWbmVBqXoOKgKb8wef7SVHZlxGF9xc4%3D&reserved=0 Stats:???? 35 lines in 2 files changed: 34 ins; 0 del; 1 mod 8286706: JFR: 'jfr scrub' should overwrite output Reviewed-by: mgronlun ------------- PR: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.java.net%2Fjdk%2Fpull%2F8728&data=05%7C01%7Cmatthew.carter%40microsoft.com%7C6f907133f0514919728708da3889a4f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637884461083849921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QZ1ptTTj5JDIcqDPmdmK4BWSqq3JLKHMzBhT%2BbrM%2FDs%3D&reserved=0 From sangheki at openjdk.org Thu Aug 11 16:41:59 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 11 Aug 2022 16:41:59 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time Message-ID: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Hi all, Could I have reviews to add new JFR event for GC CPU time? Currently only log message is available for CPU time (user, system, real). As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. The log message of CPU time is printed after GC is completed and tried to keep same. For G1, manually checked there is not difference. For test, I had to add an exception as GCCpuTime will be generated after GC end. Testing: tier 1 ~ 3 Thanks, Sangheon ------------- Commit messages: - Split G1FullGCMark - Add JFR event of GCCpuTime. Changes: https://git.openjdk.org/jdk/pull/9760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291753 Stats: 181 lines in 20 files changed: 136 ins; 11 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/9760.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9760/head:pull/9760 PR: https://git.openjdk.org/jdk/pull/9760 From egahlin at openjdk.org Thu Aug 11 19:34:55 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 11 Aug 2022 19:34:55 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time In-Reply-To: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Thu, 4 Aug 2022 23:58:02 GMT, Sangheon Kim wrote: > Hi all, > > Could I have reviews to add new JFR event for GC CPU time? > Currently only log message is available for CPU time (user, system, real). > As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. > The log message of CPU time is printed after GC is completed and tried to keep same. > > For G1, manually checked there is not difference. > > For test, I had to add an exception as GCCpuTime will be generated after GC end. > > Testing: tier 1 ~ 3 > > Thanks, > Sangheon Does this event doesn't provide CPU usage for ZGC and Shenandoah? ------------- PR: https://git.openjdk.org/jdk/pull/9760 From egahlin at openjdk.org Fri Aug 12 12:20:32 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 12 Aug 2022 12:20:32 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Fri, 12 Aug 2022 10:07:01 GMT, Sangheon Kim wrote: > No. This event is provided via GCTraceCPUTime class with GCTracer. And both ZGC and Shenanadoah are not using it. If you are suggesting to support all GCs, it is out of scope. It may be address as a separate enhancement. > Thanks for the information. Do you see any issues adding the event for those GCs (as a separate enhancement)? There are no limitation in the information the OS can provide (per thread) or how the GCs are implemented. The reason I am asking is because we want the design of the event to be future proof, so we don't end up with multiple GC CPU events. Users are likely to complain if the event is missing for some GCs. It seems like a very useful event, so I think the demand will be high for other GCs as well. Could you write in the event description which GCs that are supported? An alternative would be to write the CPU usage as a percentage, similar to the CPULoad and ThreadCPU event. It would be a periodic event emitted every second and tools could display a graph of where the system is spending time. It could perhaps be complemented with a Compiler CPU event, as a separate enhancement. ------------- PR: https://git.openjdk.org/jdk/pull/9760 From tschatzl at openjdk.org Fri Aug 12 12:29:13 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Aug 2022 12:29:13 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time In-Reply-To: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Thu, 4 Aug 2022 23:58:02 GMT, Sangheon Kim wrote: > Hi all, > > Could I have reviews to add new JFR event for GC CPU time? > Currently only log message is available for CPU time (user, system, real). > As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. > The log message of CPU time is printed after GC is completed and tried to keep same. > > For G1, manually checked there is not difference. > > For test, I had to add an exception as GCCpuTime will be generated after GC end. > > Testing: tier 1 ~ 3 > > Thanks, > Sangheon Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/shared/gcTraceTime.cpp line 93: > 91: } > 92: > 93: GCTraceCPUTime::GCTraceCPUTime() { GCTraceCPUTime(nullptr); } Suggestion: GCTraceCPUTime::GCTraceCPUTime() : GCTraceCPUTime(nullptr) { } The way the other constructor is called is wrong afaik. However if serial gc support were added, this constructor could be deleted. test/jdk/jdk/jfr/event/gc/detailed/TestGCCpuTimeEvent.java line 36: > 34: * @key jfr > 35: * @requires vm.hasJFR > 36: * @requires vm.gc == "G1" | vm.gc == null | vm.gc == "Parallel" Please also add support for serial gc, it provides tracer classes. Also I would consider blacklisting non-supporting collectors instead, i.e. ZGC, Shenandoah and Epsilon. That way the missing functionality is eventually found more easily, i.e. by searching for `!= ` instead of finding all tests that exclude that collector. Also since the test is only run with G1, it would be sufficient to just `@requires G1/null`. test/jdk/jdk/jfr/event/gc/detailed/TestGCCpuTimeEvent.java line 38: > 36: * @requires vm.gc == "G1" | vm.gc == null | vm.gc == "Parallel" > 37: * @library /test/lib /test/jdk > 38: * @run main/othervm -Xmx32m -XX:+UseG1GC jdk.jfr.event.gc.detailed.TestGCCpuTimeEvent I think you want separate tests like the `gc/Systemgc.java` test here. This will always run the test with G1 even when initially invoked with the intent to execute the serial gc test. test/jdk/jdk/jfr/event/gc/detailed/TestGCCpuTimeEvent.java line 56: > 54: for (int i = 0; i < 100; i++) { > 55: bytes = new byte[1024 * 1024]; > 56: } Please use Whitebox/WhiteBox.youngGC() to guarantee invocation of a GC. This test currently hinges on the compiler/interpreter not being too clever. ------------- PR: https://git.openjdk.org/jdk/pull/9760 From sangheki at openjdk.org Mon Aug 15 01:42:14 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Mon, 15 Aug 2022 01:42:14 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v2] In-Reply-To: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: > Hi all, > > Could I have reviews to add new JFR event for GC CPU time? > Currently only log message is available for CPU time (user, system, real). > As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. > The log message of CPU time is printed after GC is completed and tried to keep same. > > For G1, manually checked there is not difference. > > For test, I had to add an exception as GCCpuTime will be generated after GC end. > > Testing: tier 1 ~ 3 > > Thanks, > Sangheon Sangheon Kim has updated the pull request incrementally with one additional commit since the last revision: Add Serial GC support and split test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9760/files - new: https://git.openjdk.org/jdk/pull/9760/files/981c4479..2075927c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=00-01 Stats: 57 lines in 6 files changed: 34 ins; 8 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9760.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9760/head:pull/9760 PR: https://git.openjdk.org/jdk/pull/9760 From sangheki at openjdk.org Mon Aug 15 01:42:17 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Mon, 15 Aug 2022 01:42:17 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v2] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: <3SZQZg-HZJTnALamwdKeaG1YBdYgpJrMacouvMiZOok=.a020b70a-b274-435b-8d3b-4cf345c67b11@github.com> On Fri, 12 Aug 2022 12:06:10 GMT, Thomas Schatzl wrote: >> Sangheon Kim has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Serial GC support and split test. > > src/hotspot/share/gc/shared/gcTraceTime.cpp line 93: > >> 91: } >> 92: >> 93: GCTraceCPUTime::GCTraceCPUTime() { GCTraceCPUTime(nullptr); } > > Suggestion: > > GCTraceCPUTime::GCTraceCPUTime() : GCTraceCPUTime(nullptr) { } > > The way the other constructor is called is wrong afaik. However if serial gc support were added, this constructor could be deleted. Done. > test/jdk/jdk/jfr/event/gc/detailed/TestGCCpuTimeEvent.java line 36: > >> 34: * @key jfr >> 35: * @requires vm.hasJFR >> 36: * @requires vm.gc == "G1" | vm.gc == null | vm.gc == "Parallel" > > Please also add support for serial gc, it provides tracer classes. > Also I would consider blacklisting non-supporting collectors instead, i.e. ZGC, Shenandoah and Epsilon. That way the missing functionality is eventually found more easily, i.e. by searching for `!= ` instead of finding all tests that exclude that collector. > > Also since the test is only run with G1, it would be sufficient to just `@requires G1/null`. Added Serial GC support. Separated to serial, parallel and G1 tests. > test/jdk/jdk/jfr/event/gc/detailed/TestGCCpuTimeEvent.java line 38: > >> 36: * @requires vm.gc == "G1" | vm.gc == null | vm.gc == "Parallel" >> 37: * @library /test/lib /test/jdk >> 38: * @run main/othervm -Xmx32m -XX:+UseG1GC jdk.jfr.event.gc.detailed.TestGCCpuTimeEvent > > I think you want separate tests like the `gc/Systemgc.java` test here. This will always run the test with G1 even when initially invoked with the intent to execute the serial gc test. Done. > test/jdk/jdk/jfr/event/gc/detailed/TestGCCpuTimeEvent.java line 56: > >> 54: for (int i = 0; i < 100; i++) { >> 55: bytes = new byte[1024 * 1024]; >> 56: } > > Please use Whitebox/WhiteBox.youngGC() to guarantee invocation of a GC. This test currently hinges on the compiler/interpreter not being too clever. Done. ------------- PR: https://git.openjdk.org/jdk/pull/9760 From sangheki at openjdk.org Mon Aug 15 16:56:33 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Mon, 15 Aug 2022 16:56:33 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: <_IobOQue4P-WBeKXtxQ9m7BIHxVz1lhLT59rk-Mzk2Q=.1c8dd18b-c8b5-4d7f-bbb3-e3c593b68414@github.com> On Fri, 12 Aug 2022 12:18:10 GMT, Erik Gahlin wrote: > Do you see any issues adding the event for those GCs (as a separate enhancement)? There are no limitation in the information the OS can provide (per thread) or how the GCs are implemented. The reason I am asking is because we want the design of the event to be future proof, so we don't end up with multiple GC CPU events. Users are likely to complain if the event is missing for some GCs. It seems like a very useful event, so I think the demand will be high for other GCs as well. Could you write in the event description which GCs that are supported? I don't see any issues for other GCs. The only reason is that other GCs don't use the class. And I agree with you, so I filed "JDK-8292373 Add JFR event for GC CPU Time (other GCs)" for future enhancement. Updated the description as well. ------------- PR: https://git.openjdk.org/jdk/pull/9760 From suematsu.shinya at fujitsu.com Tue Aug 16 06:34:40 2022 From: suematsu.shinya at fujitsu.com (suematsu.shinya at fujitsu.com) Date: Tue, 16 Aug 2022 06:34:40 +0000 Subject: typo at ActiveRecordingEvent comment Message-ID: Hi, I?? new to jdk project. I found trivial typo at ActiveRecordingEvent comment. Does anyone create an issue? // commit(... , long, String, String, String, long, long, long, long, long) String should be 2 times. Thanks From egahlin at openjdk.org Tue Aug 16 10:45:34 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 16 Aug 2022 10:45:34 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v2] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Mon, 15 Aug 2022 01:42:14 GMT, Sangheon Kim wrote: >> Hi all, >> >> Could I have reviews to add new JFR event for GC CPU time? >> Currently only log message is available for CPU time (user, system, real). >> As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. >> The log message of CPU time is printed after GC is completed and tried to keep same. >> >> For G1, manually checked there is not difference. >> >> For test, I had to add an exception as GCCpuTime will be generated after GC end. >> >> Testing: tier 1 ~ 3 >> >> Thanks, >> Sangheon > > Sangheon Kim has updated the pull request incrementally with one additional commit since the last revision: > > Add Serial GC support and split test. src/hotspot/share/jfr/metadata/metadata.xml line 498: > 496: > 497: > 498: 499: thread="true" stackTrace="false" startTime="false"> > 500: > 501: Could you change the field type to "ulong", convert the value to nanoseconds and set contentType="nanos"? This will allow the output to be properly formatted, i.e. 23 ms, in the jfr-tool. You can also remove the mentioning of "in seconds" in the event description. The content type will allow tools to format the unit. I am also missing supported GCs in the event description. The description of gcId seems strange, which "object"? I think you can skip the description. The event has thread="true". Is data emitted per thread? If so, it may makes sense to aggregate for all threads. I think most user don't care about which thread the CPU was consumed. Otherwise, set thread="false". (If you want per thread for JVM engineers, I think the event name and label should reflect it is per thread and perhaps not enable it in the "detailed" configuration, not "normal", in .jfc files) ------------- PR: https://git.openjdk.org/jdk/pull/9760 From erik.gahlin at oracle.com Tue Aug 16 16:59:51 2022 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 16 Aug 2022 16:59:51 +0000 Subject: typo at ActiveRecordingEvent comment In-Reply-To: References: Message-ID: Hi, I created an issue: https://bugs.openjdk.org/browse/JDK-8292488 Cheers Erik ________________________________ From: hotspot-jfr-dev on behalf of suematsu.shinya at fujitsu.com Sent: Tuesday, August 16, 2022 8:34 AM To: 'hotspot-jfr-dev at openjdk.org' Subject: typo at ActiveRecordingEvent comment Hi, I?? new to jdk project. I found trivial typo at ActiveRecordingEvent comment. Does anyone create an issue? // commit(... , long, String, String, String, long, long, long, long, long) String should be 2 times. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangheki at openjdk.org Wed Aug 17 01:08:52 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Wed, 17 Aug 2022 01:08:52 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v3] In-Reply-To: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: > Hi all, > > Could I have reviews to add new JFR event for GC CPU time? > Currently only log message is available for CPU time (user, system, real). > As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. > The log message of CPU time is printed after GC is completed and tried to keep same. > > For G1, manually checked there is not difference. > > For test, I had to add an exception as GCCpuTime will be generated after GC end. > > Testing: tier 1 ~ 3 > > Thanks, > Sangheon Sangheon Kim has updated the pull request incrementally with one additional commit since the last revision: Reflect egahlin's comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9760/files - new: https://git.openjdk.org/jdk/pull/9760/files/2075927c..f4329777 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=01-02 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9760.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9760/head:pull/9760 PR: https://git.openjdk.org/jdk/pull/9760 From sangheki at openjdk.org Wed Aug 17 01:08:53 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Wed, 17 Aug 2022 01:08:53 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v2] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Tue, 16 Aug 2022 10:15:03 GMT, Erik Gahlin wrote: >> Sangheon Kim has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Serial GC support and split test. > > src/hotspot/share/jfr/metadata/metadata.xml line 498: > >> 496: >> 497: >> 498: > Could you change the name to "GCCPUTime". Other events uses capital letters in abbreviations. Renamed to "GCCPUTime". > src/hotspot/share/jfr/metadata/metadata.xml line 501: > >> 499: thread="true" stackTrace="false" startTime="false"> >> 500: >> 501: > > Could you change the field type to "ulong", convert the value to nanoseconds and set contentType="nanos"? This will allow the output to be properly formatted, i.e. 23 ms, in the jfr-tool. You can also remove the mentioning of "in seconds" in the event description. The content type will allow tools to format the unit. I am also missing supported GCs in the event description. > > The description of gcId seems strange, which "object"? I think you can skip the description. > > The event has thread="true". Is data emitted per thread? If so, it may makes sense to aggregate for all threads. I think most user don't care about which thread the CPU was consumed. Otherwise, set thread="false". > > (If you want per thread for JVM engineers, I think the event name and label should reflect it is per thread and perhaps not enable it in the "detailed" configuration, not "normal", in .jfc files) 1. Changed as you suggested. I had same idea but the original data is in seconds. And I wanted to use same unit as log message and avoid conversion. But as you said, the tool gets the benefit. 1-2. Added supported GCs in the description. 2. Removed description field of gcid. 3. Removed 'thread=true'. ------------- PR: https://git.openjdk.org/jdk/pull/9760 From suematsu.shinya at fujitsu.com Wed Aug 17 04:47:50 2022 From: suematsu.shinya at fujitsu.com (suematsu.shinya at fujitsu.com) Date: Wed, 17 Aug 2022 04:47:50 +0000 Subject: typo at ActiveRecordingEvent comment In-Reply-To: References: Message-ID: Hi, Thank you, Erik. I sent a pull request. Please let me know if there is anything missing. PR: https://github.com/openjdk/jdk/pull/9897 Thanks From: Erik Gahlin Sent: Wednesday, August 17, 2022 2:00 AM To: Suematsu, Shinya/?? ?? ; 'hotspot-jfr-dev at openjdk.org' Subject: Re: typo at ActiveRecordingEvent comment Hi, I created an issue: https://bugs.openjdk.org/browse/JDK-8292488 Cheers Erik ________________________________ From: hotspot-jfr-dev > on behalf of suematsu.shinya at fujitsu.com > Sent: Tuesday, August 16, 2022 8:34 AM To: 'hotspot-jfr-dev at openjdk.org' > Subject: typo at ActiveRecordingEvent comment Hi, I?? new to jdk project. I found trivial typo at ActiveRecordingEvent comment. Does anyone create an issue? // commit(... , long, String, String, String, long, long, long, long, long) String should be 2 times. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Aug 17 04:52:35 2022 From: duke at openjdk.org (chigiriki) Date: Wed, 17 Aug 2022 04:52:35 GMT Subject: RFR: 8292488: Incorrect comment in ActiveRecordingEvent Message-ID: please review this change. I checked the build succecfully just in case. No error occured. ------------- Commit messages: - 8292488: Incorrect comment in ActiveRecordingEvent Changes: https://git.openjdk.org/jdk/pull/9897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9897&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292488 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9897/head:pull/9897 PR: https://git.openjdk.org/jdk/pull/9897 From egahlin at openjdk.org Wed Aug 17 10:12:28 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 17 Aug 2022 10:12:28 GMT Subject: RFR: 8292488: JFR: Incorrect comment in ActiveRecordingEvent In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 04:45:48 GMT, chigiriki wrote: > please review this change. > I checked the build succecfully just in case. No error occured. Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9897 From rehn at openjdk.org Thu Aug 18 11:58:45 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 18 Aug 2022 11:58:45 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. Message-ID: Split TestNative into two different test, so native sampling can have a high frequency. ------------- Commit messages: - JFR test fixes Changes: https://git.openjdk.org/jdk/pull/9915/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9915&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292592 Stats: 210 lines in 3 files changed: 136 ins; 74 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9915.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9915/head:pull/9915 PR: https://git.openjdk.org/jdk/pull/9915 From egahlin at openjdk.org Thu Aug 18 12:22:25 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 18 Aug 2022 12:22:25 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. In-Reply-To: References: Message-ID: <3JjaOD_17QJsHbBTUkkqMltVC7BFCODAbwvEqHaA6RA=.1aedf17d-3e83-4ce2-bf6d-e62577945ed3@github.com> On Thu, 18 Aug 2022 10:51:57 GMT, Robbin Ehn wrote: > Split TestNative into two different test, so native sampling can have a high frequency. The new test uses jdk.ExecutionSample, not jdk.NativeMethodSample. This might be by design, but I thought I should mention it. ------------- PR: https://git.openjdk.org/jdk/pull/9915 From rehn at openjdk.org Thu Aug 18 12:28:21 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 18 Aug 2022 12:28:21 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. In-Reply-To: <3JjaOD_17QJsHbBTUkkqMltVC7BFCODAbwvEqHaA6RA=.1aedf17d-3e83-4ce2-bf6d-e62577945ed3@github.com> References: <3JjaOD_17QJsHbBTUkkqMltVC7BFCODAbwvEqHaA6RA=.1aedf17d-3e83-4ce2-bf6d-e62577945ed3@github.com> Message-ID: On Thu, 18 Aug 2022 12:19:54 GMT, Erik Gahlin wrote: > The new test uses jdk.ExecutionSample, not jdk.NativeMethodSample. This might be by design, but I thought I should mention it. Yes, you are correct @egahlin. If we are to not use a native library we have no reliable methods to call for native sample. (when using so low sample rate) Since the sampler issue with long sleep should be trigger by either sampled typed this was much better IMHO. ------------- PR: https://git.openjdk.org/jdk/pull/9915 From egahlin at openjdk.org Thu Aug 18 12:56:07 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 18 Aug 2022 12:56:07 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 10:51:57 GMT, Robbin Ehn wrote: > Split TestNative into two different test, so native sampling can have a high frequency. Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9915 From rehn at openjdk.org Thu Aug 18 12:56:08 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 18 Aug 2022 12:56:08 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. In-Reply-To: <3JjaOD_17QJsHbBTUkkqMltVC7BFCODAbwvEqHaA6RA=.1aedf17d-3e83-4ce2-bf6d-e62577945ed3@github.com> References: <3JjaOD_17QJsHbBTUkkqMltVC7BFCODAbwvEqHaA6RA=.1aedf17d-3e83-4ce2-bf6d-e62577945ed3@github.com> Message-ID: On Thu, 18 Aug 2022 12:19:54 GMT, Erik Gahlin wrote: >> Split TestNative into two different test, so native sampling can have a high frequency. > > The new test uses jdk.ExecutionSample, not jdk.NativeMethodSample. This might be by design, but I thought I should mention it. Thank you @egahlin ! ------------- PR: https://git.openjdk.org/jdk/pull/9915 From duke at openjdk.org Thu Aug 18 16:50:22 2022 From: duke at openjdk.org (chigiriki) Date: Thu, 18 Aug 2022 16:50:22 GMT Subject: Integrated: 8292488: JFR: Incorrect comment in ActiveRecordingEvent In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 04:45:48 GMT, chigiriki wrote: > please review this change. > I checked the build succecfully just in case. No error occured. This pull request has now been integrated. Changeset: 20a3cb7c Author: chigiriki Committer: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/20a3cb7ce348dabb71292d19a979a8c12cfe3c6d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8292488: JFR: Incorrect comment in ActiveRecordingEvent Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/9897 From shade at openjdk.org Fri Aug 19 13:27:45 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 Aug 2022 13:27:45 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 10:51:57 GMT, Robbin Ehn wrote: > Split TestNative into two different test, so native sampling can have a high frequency. Nit: not sure if all imports are needed, like `AtomicInteger`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9915 From rehn at openjdk.org Fri Aug 19 13:35:29 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 19 Aug 2022 13:35:29 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 13:24:35 GMT, Aleksey Shipilev wrote: >> Split TestNative into two different test, so native sampling can have a high frequency. > > Nit: not sure if all imports are needed, like `AtomicInteger`? @shipilev thank you! I'll fix that before push! ------------- PR: https://git.openjdk.org/jdk/pull/9915 From rehn at openjdk.org Fri Aug 19 16:07:08 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 19 Aug 2022 16:07:08 GMT Subject: RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling. [v2] In-Reply-To: References: Message-ID: > Split TestNative into two different test, so native sampling can have a high frequency. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixed includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9915/files - new: https://git.openjdk.org/jdk/pull/9915/files/4b19fef9..0605ef2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9915&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9915&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9915.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9915/head:pull/9915 PR: https://git.openjdk.org/jdk/pull/9915 From rehn at openjdk.org Fri Aug 19 16:08:36 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 19 Aug 2022 16:08:36 GMT Subject: Integrated: 8292592: JFR test TestNative is not reliable due to low rate of sampling. In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 10:51:57 GMT, Robbin Ehn wrote: > Split TestNative into two different test, so native sampling can have a high frequency. This pull request has now been integrated. Changeset: 45dec480 Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/45dec480ef6f1d5509f4afbbf414c69584ac252e Stats: 200 lines in 3 files changed: 126 ins; 74 del; 0 mod 8292592: JFR test TestNative is not reliable due to low rate of sampling. Reviewed-by: egahlin, shade ------------- PR: https://git.openjdk.org/jdk/pull/9915 From tschatzl at openjdk.org Mon Aug 22 09:35:27 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Aug 2022 09:35:27 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v3] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Wed, 17 Aug 2022 01:08:52 GMT, Sangheon Kim wrote: >> Hi all, >> >> Could I have reviews to add new JFR event for GC CPU time? >> Currently only log message is available for CPU time (user, system, real). >> As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. >> The log message of CPU time is printed after GC is completed and tried to keep same. >> >> For G1, manually checked there is not difference. >> >> For test, I had to add an exception as GCCpuTime will be generated after GC end. >> >> Testing: tier 1 ~ 3 >> >> Thanks, >> Sangheon > > Sangheon Kim has updated the pull request incrementally with one additional commit since the last revision: > > Reflect egahlin's comment Good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9760 From duke at openjdk.org Tue Aug 23 16:25:40 2022 From: duke at openjdk.org (duke) Date: Tue, 23 Aug 2022 16:25:40 GMT Subject: Withdrawn: 8288783: JFR: Error messages are confusing when options conflict in -XX:StartFlightRecording In-Reply-To: <87hLVKwlIH1L9Bdvb_gK0kA6fu_jSBhcRxOfqodha-o=.72705b7b-2db2-41ce-b23c-5ca4b266d20b@github.com> References: <87hLVKwlIH1L9Bdvb_gK0kA6fu_jSBhcRxOfqodha-o=.72705b7b-2db2-41ce-b23c-5ca4b266d20b@github.com> Message-ID: On Tue, 28 Jun 2022 05:50:38 GMT, Chihiro Ito wrote: > Could I have a review of PR that fixes incorrect error messages regarding of recording. > > The current message is very confusing. If a user types jcmd JFR.start name=abc name=def or java --XX:StartFlightRecording=name=abc,name=def, the error message says "Duplicates in diagnostic command arguments", but doesn't know what options are duplicated. > Furthermore, if a user specifies two or three duplicate parameters, the same logs will be output. > > It should say follows, > Option name can only be specified once with starting flight recording > Options name and disk can only be specified once with starting flight recording > Options name, disk and maxage can only be specified once with starting flight recording > This problem affects --XX:StartFlightRecording, jcmd JFR.start, JFR.stop, JFR.dump, JFR.check, and MBean. > > For other than start, the output is as follows, (example of dump) > Option name can only be specified once with dumping flight recording > > Testing: jdk/jdk/jfr > > Thanks > Chihiro This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9302 From sangheki at openjdk.org Wed Aug 31 14:53:04 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Wed, 31 Aug 2022 14:53:04 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v4] In-Reply-To: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: > Hi all, > > Could I have reviews to add new JFR event for GC CPU time? > Currently only log message is available for CPU time (user, system, real). > As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. > The log message of CPU time is printed after GC is completed and tried to keep same. > > For G1, manually checked there is not difference. > > For test, I had to add an exception as GCCpuTime will be generated after GC end. > > Testing: tier 1 ~ 3 > > Thanks, > Sangheon Sangheon Kim has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8291753-cpu-time - Reflect egahlin's comment - Add Serial GC support and split test. - Split G1FullGCMark - Add JFR event of GCCpuTime. ------------- Changes: https://git.openjdk.org/jdk/pull/9760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=03 Stats: 225 lines in 23 files changed: 163 ins; 12 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/9760.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9760/head:pull/9760 PR: https://git.openjdk.org/jdk/pull/9760