From mgronlun at openjdk.org Thu Sep 1 20:46:03 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 1 Sep 2022 20:46:03 GMT Subject: RFR: 8293167: Memory leak in JfrThreadSampler if stackdepth is larger than default (64) Message-ID: Greetings, please help review this fix that address a memory leak in the JfrThreadSampler when using a stackdepth larger than default (64). Please see the JIRA issue for details. Testing: jdk_jfr, stress Thanks Markus ------------- Commit messages: - 8293167 Changes: https://git.openjdk.org/jdk/pull/10129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293167 Stats: 63 lines in 6 files changed: 33 ins; 3 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/10129.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10129/head:pull/10129 PR: https://git.openjdk.org/jdk/pull/10129 From jbachorik at openjdk.org Fri Sep 2 16:12:52 2022 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Fri, 2 Sep 2022 16:12:52 GMT Subject: RFR: 8293167: Memory leak in JfrThreadSampler if stackdepth is larger than default (64) In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 20:40:08 GMT, Markus Gr?nlund wrote: > Greetings, > > please help review this fix that address a memory leak in the JfrThreadSampler when using a stackdepth larger than default (64). > > Please see the JIRA issue for details. > > Testing: jdk_jfr, stress > > Thanks > Markus Looking good. I could find only one small error in a comment :) src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp line 37: > 35: // The queue instances are used by the load barrier to enqueue tagged Klass'es. > 36: static JfrTraceIdKlassQueue* _klass_queue = nullptr; // Generic for all Java threads. > 37: static JfrTraceIdKlassQueue* _sampler_klass_queue = nullptr; // Specialized for the Jfr Thread Sampler using use a larger buffer size. Suggestion: static JfrTraceIdKlassQueue* _sampler_klass_queue = nullptr; // Specialized for the Jfr Thread Sampler using a larger buffer size. ------------- Marked as reviewed by jbachorik (Reviewer). PR: https://git.openjdk.org/jdk/pull/10129 From mgronlun at openjdk.org Fri Sep 2 16:49:57 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 2 Sep 2022 16:49:57 GMT Subject: RFR: 8293167: Memory leak in JfrThreadSampler if stackdepth is larger than default (64) [v2] In-Reply-To: References: Message-ID: > Greetings, > > please help review this fix that address a memory leak in the JfrThreadSampler when using a stackdepth larger than default (64). > > Please see the JIRA issue for details. > > Testing: jdk_jfr, stress > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp Co-authored-by: Jaroslav Bachorik ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10129/files - new: https://git.openjdk.org/jdk/pull/10129/files/47c8af96..e14c1fa0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10129&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10129&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10129.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10129/head:pull/10129 PR: https://git.openjdk.org/jdk/pull/10129 From mgronlun at openjdk.org Fri Sep 2 16:49:58 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 2 Sep 2022 16:49:58 GMT Subject: RFR: 8293167: Memory leak in JfrThreadSampler if stackdepth is larger than default (64) [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 16:04:01 GMT, Jaroslav Bachorik wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp >> >> Co-authored-by: Jaroslav Bachorik > > src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp line 37: > >> 35: // The queue instances are used by the load barrier to enqueue tagged Klass'es. >> 36: static JfrTraceIdKlassQueue* _klass_queue = nullptr; // Generic for all Java threads. >> 37: static JfrTraceIdKlassQueue* _sampler_klass_queue = nullptr; // Specialized for the Jfr Thread Sampler using use a larger buffer size. > > Suggestion: > > static JfrTraceIdKlassQueue* _sampler_klass_queue = nullptr; // Specialized for the Jfr Thread Sampler using a larger buffer size. Thanks @jbachorik for noticing. ------------- PR: https://git.openjdk.org/jdk/pull/10129 From mgronlun at openjdk.org Mon Sep 5 09:13:28 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 5 Sep 2022 09:13:28 GMT Subject: RFR: 8293167: Memory leak in JfrThreadSampler if stackdepth is larger than default (64) [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 16:09:17 GMT, Jaroslav Bachorik wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp >> >> Co-authored-by: Jaroslav Bachorik > > Looking good. > I could find only one small error in a comment :) Thank you @jbachorik for reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/10129 From mgronlun at openjdk.org Mon Sep 5 09:15:50 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 5 Sep 2022 09:15:50 GMT Subject: Integrated: 8293167: Memory leak in JfrThreadSampler if stackdepth is larger than default (64) In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 20:40:08 GMT, Markus Gr?nlund wrote: > Greetings, > > please help review this fix that address a memory leak in the JfrThreadSampler when using a stackdepth larger than default (64). > > Please see the JIRA issue for details. > > Testing: jdk_jfr, stress > > Thanks > Markus This pull request has now been integrated. Changeset: 48b3ab02 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/48b3ab02f9339f97e49f775c9d5d3a598a158abf Stats: 63 lines in 6 files changed: 33 ins; 3 del; 27 mod 8293167: Memory leak in JfrThreadSampler if stackdepth is larger than default (64) Reviewed-by: jbachorik ------------- PR: https://git.openjdk.org/jdk/pull/10129 From ihse at openjdk.org Mon Sep 5 10:22:15 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Sep 2022 10:22:15 GMT Subject: Integrated: 8293355: JDK-8293167 included bad copyright header Message-ID: <62XWfb3abxreW1x5b53kpti354epsOXY6ZUXxgV2eQ4=.b037b577-e06b-4543-b34f-ee7c8a6888a3@github.com> This breaks CI testing in Oracle. ------------- Commit messages: - 8293355: JDK-8293167 included bad copyright header Changes: https://git.openjdk.org/jdk/pull/10162/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293355 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10162.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10162/head:pull/10162 PR: https://git.openjdk.org/jdk/pull/10162 From kbarrett at openjdk.org Mon Sep 5 10:22:15 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Sep 2022 10:22:15 GMT Subject: Integrated: 8293355: JDK-8293167 included bad copyright header In-Reply-To: <62XWfb3abxreW1x5b53kpti354epsOXY6ZUXxgV2eQ4=.b037b577-e06b-4543-b34f-ee7c8a6888a3@github.com> References: <62XWfb3abxreW1x5b53kpti354epsOXY6ZUXxgV2eQ4=.b037b577-e06b-4543-b34f-ee7c8a6888a3@github.com> Message-ID: On Mon, 5 Sep 2022 10:12:35 GMT, Magnus Ihse Bursie wrote: > This breaks CI testing in Oracle. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10162 From ihse at openjdk.org Mon Sep 5 10:22:16 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Sep 2022 10:22:16 GMT Subject: Integrated: 8293355: JDK-8293167 included bad copyright header In-Reply-To: <62XWfb3abxreW1x5b53kpti354epsOXY6ZUXxgV2eQ4=.b037b577-e06b-4543-b34f-ee7c8a6888a3@github.com> References: <62XWfb3abxreW1x5b53kpti354epsOXY6ZUXxgV2eQ4=.b037b577-e06b-4543-b34f-ee7c8a6888a3@github.com> Message-ID: On Mon, 5 Sep 2022 10:12:35 GMT, Magnus Ihse Bursie wrote: > This breaks CI testing in Oracle. This pull request has now been integrated. Changeset: 8df671c9 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/8df671c908d10b586540cc916a91e083c6098648 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8293355: JDK-8293167 included bad copyright header Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/10162 From dnsimon at openjdk.org Tue Sep 6 08:26:18 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 6 Sep 2022 08:26:18 GMT Subject: RFR: 8293403: JfrResolution::on_jvmci_resolution crashes when caller is null Message-ID: When the `caller` argument to `JfrResolution::on_jvmci_resolution` is null, the method should raise an `IllegalAccessError` instead of crashing with a SIGSEGV. ------------- Commit messages: - handle nullptr for caller argument in JfrResolution::on_jvmci_resolution Changes: https://git.openjdk.org/jdk/pull/10180/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293403 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10180.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10180/head:pull/10180 PR: https://git.openjdk.org/jdk/pull/10180 From asotona at openjdk.org Tue Sep 6 12:25:24 2022 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 6 Sep 2022 12:25:24 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v15] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - Merge branch 'openjdk:master' into JDK-8244681 - ... and 9 more: https://git.openjdk.org/jdk/compare/6a1e98cb...4a7ce942 ------------- Changes: https://git.openjdk.org/jdk/pull/8599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=14 Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From never at openjdk.org Tue Sep 6 15:04:56 2022 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 6 Sep 2022 15:04:56 GMT Subject: RFR: 8293403: JfrResolution::on_jvmci_resolution crashes when caller is null In-Reply-To: References: Message-ID: <9RknEpGMeVnx_Ht3TY1pLTvFbDHDEuMPcy9HWGvm3Ms=.c464d772-7135-4533-8c75-fa76809cc699@github.com> On Tue, 6 Sep 2022 08:18:31 GMT, Doug Simon wrote: > When the `caller` argument to `JfrResolution::on_jvmci_resolution` is null, the method should raise an `IllegalAccessError` instead of crashing with a SIGSEGV. Marked as reviewed by never (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10180 From dnsimon at openjdk.org Tue Sep 6 15:21:37 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 6 Sep 2022 15:21:37 GMT Subject: Integrated: 8293403: JfrResolution::on_jvmci_resolution crashes when caller is null In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 08:18:31 GMT, Doug Simon wrote: > When the `caller` argument to `JfrResolution::on_jvmci_resolution` is null, the method should raise an `IllegalAccessError` instead of crashing with a SIGSEGV. This pull request has now been integrated. Changeset: 7c96608d Author: Doug Simon URL: https://git.openjdk.org/jdk/commit/7c96608d9a2f3ea552b2daf1fe0772a0faac46c6 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod 8293403: JfrResolution::on_jvmci_resolution crashes when caller is null Reviewed-by: never ------------- PR: https://git.openjdk.org/jdk/pull/10180 From ayang at openjdk.org Wed Sep 7 16:15:11 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 7 Sep 2022 16:15:11 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v4] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: <7hFd7WV6R3dr3mT8L6A8WZevAtBLKHurlrAMgMy8cpA=.a70aa97d-14ea-4784-880b-0e4a14591a5f@github.com> On Wed, 31 Aug 2022 14:53:04 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 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. The rest look fine, but the inconsistency should be resolved IMO. src/hotspot/share/gc/g1/g1FullCollector.hpp line 70: > 68: G1FullGCMark() : _gc_id(), _cpu_time() { } > 69: }; > 70: I don't recall the exact reason for this, but I have a faint memory on having some discussion with its author. It's from https://bugs.openjdk.org/browse/JDK-8272651 Before this PR: [32.328s][info ][gc ] GC(47) Pause Young (Normal) (G1 Evacuation Pause) 1162M->1032M(3072M) 323.751ms [32.328s][info ][gc,cpu ] GC(47) User=3.22s Sys=0.00s Real=0.33s ... [35.221s][info ][gc ] GC(48) Pause Full (System.gc()) 1134M->660M(3072M) 2650.824ms [35.221s][info ][gc,cpu ] GC(48) User=23.97s Sys=1.49s Real=2.65s After this PR: [35.221s][info ][gc ] GC(48) Pause Full (System.gc()) 1134M->660M(3072M) 2650.824ms [35.221s][info ][gc,cpu ] GC(48) User=23.97s Sys=1.49s Real=2.65s ... [41.337s][info ][gc,cpu ] GC(49) User=27.86s Sys=1.58s Real=3.28s [41.337s][info ][gc ] GC(49) Pause Full (System.gc()) 1094M->660M(3072M) 3283.658ms Note that for Full-GC, the user/sys/real time is *before* GC-end, which is inconsistent with Young-GC. ------------- Changes requested by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9760 From sangheki at openjdk.org Thu Sep 8 00:04:11 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 8 Sep 2022 00:04:11 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v5] 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 two additional commits since the last revision: - Merge remote-tracking branch 'origin/8291753-cpu-time' into 8291753-cpu-time - Comment from albertnetymk ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9760/files - new: https://git.openjdk.org/jdk/pull/9760/files/229df2f2..d347ece1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=03-04 Stats: 23 lines in 3 files changed: 14 ins; 4 del; 5 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 Thu Sep 8 00:07:05 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 8 Sep 2022 00:07:05 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v5] In-Reply-To: <7hFd7WV6R3dr3mT8L6A8WZevAtBLKHurlrAMgMy8cpA=.a70aa97d-14ea-4784-880b-0e4a14591a5f@github.com> References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> <7hFd7WV6R3dr3mT8L6A8WZevAtBLKHurlrAMgMy8cpA=.a70aa97d-14ea-4784-880b-0e4a14591a5f@github.com> Message-ID: On Wed, 7 Sep 2022 16:11:50 GMT, Albert Mingkun Yang wrote: >> Sangheon Kim has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/8291753-cpu-time' into 8291753-cpu-time >> - Comment from albertnetymk > > src/hotspot/share/gc/g1/g1FullCollector.hpp line 70: > >> 68: G1FullGCMark() : _gc_id(), _cpu_time() { } >> 69: }; >> 70: > > I don't recall the exact reason for this, but I have a faint memory on having some discussion with its author. It's from https://bugs.openjdk.org/browse/JDK-8272651 > > Before this PR: > > [32.328s][info ][gc ] GC(47) Pause Young (Normal) (G1 Evacuation Pause) 1162M->1032M(3072M) 323.751ms > [32.328s][info ][gc,cpu ] GC(47) User=3.22s Sys=0.00s Real=0.33s > ... > [35.221s][info ][gc ] GC(48) Pause Full (System.gc()) 1134M->660M(3072M) 2650.824ms > [35.221s][info ][gc,cpu ] GC(48) User=23.97s Sys=1.49s Real=2.65s > > After this PR: > > > [35.221s][info ][gc ] GC(48) Pause Full (System.gc()) 1134M->660M(3072M) 2650.824ms > [35.221s][info ][gc,cpu ] GC(48) User=23.97s Sys=1.49s Real=2.65s > ... > [41.337s][info ][gc,cpu ] GC(49) User=27.86s Sys=1.58s Real=3.28s > [41.337s][info ][gc ] GC(49) Pause Full (System.gc()) 1094M->660M(3072M) 3283.658ms > > > Note that for Full-GC, the user/sys/real time is *before* GC-end, which is inconsistent with Young-GC. Yes, I agree with you and fixed. I was aware of this issue(and JDK-8272651) at the beginning so mentioned at the RFR above, but... ------------- PR: https://git.openjdk.org/jdk/pull/9760 From ayang at openjdk.org Thu Sep 8 09:15:44 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 8 Sep 2022 09:15:44 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v5] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Thu, 8 Sep 2022 00:04:11 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/8291753-cpu-time' into 8291753-cpu-time > - Comment from albertnetymk Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9760 From tschatzl at openjdk.org Thu Sep 8 18:16:55 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 8 Sep 2022 18:16:55 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v5] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: <-uV2ValBzJpEVnWEWriMrnyCJa6xTJkbAqbwOmtB32w=.699eedc9-e9a0-4ac9-80ea-37062cb84022@github.com> On Thu, 8 Sep 2022 00:04:11 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/8291753-cpu-time' into 8291753-cpu-time > - Comment from albertnetymk Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9760 From sangheki at openjdk.org Thu Sep 8 18:20:53 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 8 Sep 2022 18:20:53 GMT Subject: RFR: 8291753: Add JFR event for GC CPU Time [v5] In-Reply-To: References: <3r9dQ5HzRY5Mv4BsEaaQfXGp_oE30ILzU6sptPKoF8U=.4c3c96db-f511-44bb-8988-9b1779aeb607@github.com> Message-ID: On Thu, 8 Sep 2022 00:04:11 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/8291753-cpu-time' into 8291753-cpu-time > - Comment from albertnetymk Many thanks for the review, Thomas and Albert. ------------- PR: https://git.openjdk.org/jdk/pull/9760 From sangheki at openjdk.org Thu Sep 8 18:24:00 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 8 Sep 2022 18:24:00 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: 14eb5ad0 Author: Sangheon Kim URL: https://git.openjdk.org/jdk/commit/14eb5ad0dc987ffe3621f4eeeebeb6b5a2cd691b Stats: 218 lines in 23 files changed: 163 ins; 2 del; 53 mod 8291753: Add JFR event for GC CPU Time Reviewed-by: tschatzl, ayang ------------- PR: https://git.openjdk.org/jdk/pull/9760 From asotona at openjdk.org Wed Sep 14 11:10:15 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:10:15 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v16] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5 ------------- Changes: https://git.openjdk.org/jdk/pull/8599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15 Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From asotona at openjdk.org Wed Sep 14 11:25:38 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:25:38 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v16] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <7HAZTQI9U8tr8hrc3uRhkeAnZU4yjyjVDhTB2vXd00E=.69ffd410-c37e-45ec-b812-69bf4a2782ea@github.com> On Wed, 14 Sep 2022 11:10:15 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module > - Added man-page line about lossy-conversion lint > - Merge branch 'openjdk:master' into JDK-8244681 > - 8244681: Add a warning for possibly lossy conversion in compound assignments > re-enabled warnings for java.base, java.rmi and java.smartcardio > - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5 Please review also linked Release Note issue. Thanks, Adam ------------- PR: https://git.openjdk.org/jdk/pull/8599 From asotona at openjdk.org Wed Sep 14 11:35:03 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:35:03 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v17] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: re-enabled lossy-conversions warnings for jdk.hotspot.agent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8599/files - new: https://git.openjdk.org/jdk/pull/8599/files/4b78b1c5..0b93c284 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From coffeys at openjdk.org Wed Sep 14 17:13:11 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 14 Sep 2022 17:13:11 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event Message-ID: Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. ------------- Commit messages: - Track successful getInstance calls only - Merge branch 'master' into 8254711-jfr-jca - Refactor and use of static Event on - Merge branch 'master' into 8254711-jfr-jca - new test - Event iteration - Merge branch 'master' into 8254711-jfr-jca - JFR edits Changes: https://git.openjdk.org/jdk/pull/9657/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8254711 Stats: 305 lines in 8 files changed: 269 ins; 27 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9657.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9657/head:pull/9657 PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Wed Sep 14 17:13:11 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 14 Sep 2022 17:13:11 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. Reviewer request: @seanjmullan @egahlin ------------- PR: https://git.openjdk.org/jdk/pull/9657 From asotona at openjdk.org Thu Sep 15 10:12:53 2022 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 15 Sep 2022 10:12:53 GMT Subject: Integrated: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam This pull request has now been integrated. Changeset: aff5ff14 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/aff5ff14b208b3c2be93d7b4fab8b07c5be12f3e Stats: 438 lines in 13 files changed: 437 ins; 0 del; 1 mod 8244681: Add a warning for possibly lossy conversion in compound assignments 8293797: Release Note: Javac warns about type casts in compound assignments with possible lossy conversions Reviewed-by: erikj, prr ------------- PR: https://git.openjdk.org/jdk/pull/8599 From phh at openjdk.org Fri Sep 16 23:46:23 2022 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 16 Sep 2022 23:46:23 GMT Subject: RFR: 8293828: JFR: jfr/event/oldobject/TestClassLoaderLeak.java still fails when GC cycles are not happening Message-ID: Trivial change to get a test to run reliably on Shenandoah and ZGC. ------------- Commit messages: - 8293828: JFR: jfr/event/oldobject/TestClassLoaderLeak.java still fails when GC cycles are not happening Changes: https://git.openjdk.org/jdk/pull/10319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293828 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10319.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10319/head:pull/10319 PR: https://git.openjdk.org/jdk/pull/10319 From mullan at openjdk.org Mon Sep 19 12:18:43 2022 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 19 Sep 2022 12:18:43 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. Looks good. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.org/jdk/pull/9657 From jpai at openjdk.org Mon Sep 19 13:38:07 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 Sep 2022 13:38:07 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. The failures reported in the GitHub Actions job look related to this change - `jdk.jfr.event.metadata.TestDefaultConfigurations` test appears to be failing: java.lang.Exception: Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'default' Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'profile' at jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithErrors(TestDefaultConfigurations.java:115) at jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConfigurations.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125) at java.base/java.lang.Thread.run(Thread.java:1589) JavaTest Message: Test threw exception: java.lang.Exception: Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'default' Setting 'threshold' in event 'jdk.SecurityProviderService' was not configured in the configuration 'profile' src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32: > 30: > 31: import jdk.jfr.Event; > 32: import jdk.jfr.events.*; Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones? ------------- PR: https://git.openjdk.org/jdk/pull/9657 From egahlin at openjdk.org Mon Sep 19 13:45:09 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 19 Sep 2022 13:45:09 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. I noticed that the event is disabled by default. Is it because of concerns of too many events, or too much overhead? Or something else? I think we should strive to have events always on. Few users will take the time to learn about the event and enable it. Usage will probably drop by 99%, if not enabled by default. If concerns are performance related, there might be other event designs that could be used, for example, a periodic event that is always enabled. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From jpai at openjdk.org Mon Sep 19 14:29:52 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 Sep 2022 14:29:52 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. src/java.base/share/classes/java/security/Provider.java line 1293: > 1291: } > 1292: > 1293: if (s != null && SecurityProviderServiceEvent.isTurnedOn()) { Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null? ------------- PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Mon Sep 19 15:45:50 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Sep 2022 15:45:50 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> On Mon, 19 Sep 2022 14:25:55 GMT, Jaikiran Pai wrote: >> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. > > src/java.base/share/classes/java/security/Provider.java line 1293: > >> 1291: } >> 1292: >> 1293: if (s != null && SecurityProviderServiceEvent.isTurnedOn()) { > > Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null? I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order. > src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32: > >> 30: >> 31: import jdk.jfr.Event; >> 32: import jdk.jfr.events.*; > > Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones? This was formatted via IDE. Seems like you've a preference to use the more verbose import style. I'll revert this change. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Mon Sep 19 15:45:51 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Sep 2022 15:45:51 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> References: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> Message-ID: On Mon, 19 Sep 2022 15:27:05 GMT, Sean Coffey wrote: >> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 32: >> >>> 30: >>> 31: import jdk.jfr.Event; >>> 32: import jdk.jfr.events.*; >> >> Hello Sean, rest of the changes look fine to me, except this one. Was this an intentional change to use `*` import instead of the explicit ones? > > This was formatted via IDE. Seems like you've a preference to use the more verbose import style. I'll revert this change. Thanks for pointing out that test issue also. I missed it. I'll push a minor edit to correct. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Mon Sep 19 15:48:55 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Sep 2022 15:48:55 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. > This new event is disabled by default just like the other crypto related events that were added some time back (e.g. `TLSHandshakeEvent`). My assumption is that these events will be enabled for audit mode when one is interested in finding out what their crypto operations looks like. Periodic events are good but for such operations I think it's critical that we capture all such crypto calls to ensure that admins get a good picture of what's been used/called. Perhaps we can have a discussion about whether such JDK events should be on by default and work the issue via another JBS issue. `jdk.Deserialization` is another example of a JDK level event that's off by default. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From mullan at openjdk.org Mon Sep 19 15:55:46 2022 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 19 Sep 2022 15:55:46 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> References: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> Message-ID: On Mon, 19 Sep 2022 15:25:43 GMT, Sean Coffey wrote: >> src/java.base/share/classes/java/security/Provider.java line 1293: >> >>> 1291: } >>> 1292: >>> 1293: if (s != null && SecurityProviderServiceEvent.isTurnedOn()) { >> >> Would it be useful to generate an event even for the cases where a call to this method was made but no service was available and `null` was returned? The event perhaps could capture that there was no service found for such type/algorithm combination? That would help identify usages in applications where there might be fallbacks being used when this method returns null? > > I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order. Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Mon Sep 19 16:12:18 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Sep 2022 16:12:18 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2] In-Reply-To: References: Message-ID: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: update from review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9657/files - new: https://git.openjdk.org/jdk/pull/9657/files/aab692b2..e168152f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=00-01 Stats: 29 lines in 2 files changed: 28 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9657.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9657/head:pull/9657 PR: https://git.openjdk.org/jdk/pull/9657 From egahlin at openjdk.org Mon Sep 19 16:25:44 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 19 Sep 2022 16:25:44 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 15:46:46 GMT, Sean Coffey wrote: > This new event is disabled by default just like the other crypto related events that were added some time back (e.g. `TLSHandshakeEvent`). My assumption is that these events will be enabled for audit mode when one is interested in finding out what their crypto operations looks like. Periodic events are good but for such operations I think it's critical that we capture all such crypto calls to ensure that admins get a good picture of what's been used/called. I remember we had this discussion a few years back and maybe we need both? Some events for audits and some that can be detected by the JMC rules engine in a normal recording? Perhaps it's time to introduce a parameterized setting, similar to what we have for GC and compiler, where user can specify levels. From JDK 17, they can be specified on command line, i.e. $ java -XX:StartFlightRecording:security=off/normal/debug/audit This would lower the bar and make the events useful to more people. We can do this in another JBS issue. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From valeriep at openjdk.org Mon Sep 19 16:45:45 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 19 Sep 2022 16:45:45 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2] In-Reply-To: References: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> Message-ID: On Mon, 19 Sep 2022 15:52:08 GMT, Sean Mullan wrote: >> I had this as the original design actually. I'm not sure how interesting it would be to record such "no-service" type events. It would probably add 2-4 times the number of events for this event type to a typical recording, given that the framework iterates over the providers in preferential order. > > Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer. Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying. Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately? ------------- PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Mon Sep 19 16:58:43 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 19 Sep 2022 16:58:43 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2] In-Reply-To: References: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> Message-ID: On Mon, 19 Sep 2022 16:43:26 GMT, Valerie Peng wrote: >> Yes, I think this would generate too much noise and detract from the main motivation for these events, which is to help users analyze the security of algorithms that are being used by their applications at the JCE layer. > > Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying. > Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately? Let's stick to just recording events where a match on service and provider is made then. The expectation is that analysis would be done post recording. Probably best to reduce the runtime performance impact. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From valeriep at openjdk.org Mon Sep 19 17:39:47 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 19 Sep 2022 17:39:47 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey wrote: >> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > update from review comments The java.base part of changes look good. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.org/jdk/pull/9657 From jpai at openjdk.org Tue Sep 20 06:19:58 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 20 Sep 2022 06:19:58 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 16:12:18 GMT, Sean Coffey wrote: >> Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > update from review comments Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9657 From jpai at openjdk.org Tue Sep 20 06:19:58 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 20 Sep 2022 06:19:58 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v2] In-Reply-To: References: <5Mlk6TwFKLNBDKceYk-2u_ihr1MKZeZJ0xp-GHM-ZS4=.5d76df6c-3efe-42f0-821a-a7197840bc2f@github.com> Message-ID: On Mon, 19 Sep 2022 16:55:01 GMT, Sean Coffey wrote: >> Plus one regarding "too much noise". This event is at the Provider.getService() level and would reports all calls regardless the type and algorithm. Crypto services which supports the delayed provider selection may call Provider.getService() to query but may not use all available ones. So, even if the service is returned, it may not be actually used. Just saying. >> Does JFR events support filtering? Or is the expectation of this being a collection of usages and analyze is done separately? > > Let's stick to just recording events where a match on service and provider is made then. > > The expectation is that analysis would be done post recording. Probably best to reduce the runtime performance impact. Thank you for noting the reason, Sean. It's reasonable to only generate an event for a match. ------------- PR: https://git.openjdk.org/jdk/pull/9657 From tschatzl at openjdk.org Tue Sep 20 08:19:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Sep 2022 08:19:41 GMT Subject: RFR: 8293828: JFR: jfr/event/oldobject/TestClassLoaderLeak.java still fails when GC cycles are not happening In-Reply-To: References: Message-ID: <-grscWlgPkEZWorMGrL8kwO3TMfsZwjCKVCBDj55YEo=.d9263400-f2e3-4ef0-84e9-331ae0236e97@github.com> On Fri, 16 Sep 2022 23:38:16 GMT, Paul Hohensee wrote: > Trivial change to get a test to run reliably on Shenandoah and ZGC. I would have kind of preferred a solution that made sure that would have waited for completion of a gc using mxbeans or so, but this seems good enough for a test. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/10319 From tschatzl at openjdk.org Tue Sep 20 08:52:40 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 20 Sep 2022 08:52:40 GMT Subject: RFR: 8293828: JFR: jfr/event/oldobject/TestClassLoaderLeak.java still fails when GC cycles are not happening In-Reply-To: References: Message-ID: <-8sRwet7NPoY4TGmW3rRh_9YfYVEf4buMshOmqAI3n8=.83406963-bfae-46b7-b9bd-6d71bd63dcd3@github.com> On Fri, 16 Sep 2022 23:38:16 GMT, Paul Hohensee wrote: > Trivial change to get a test to run reliably on Shenandoah and ZGC. This change also looks trivial to me. ------------- PR: https://git.openjdk.org/jdk/pull/10319 From phh at openjdk.org Tue Sep 20 17:12:46 2022 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 20 Sep 2022 17:12:46 GMT Subject: RFR: 8293828: JFR: jfr/event/oldobject/TestClassLoaderLeak.java still fails when GC cycles are not happening In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 23:38:16 GMT, Paul Hohensee wrote: > Trivial change to get a test to run reliably on Shenandoah and ZGC. Pre-submit test failures appear to be infrastructure issues. ------------- PR: https://git.openjdk.org/jdk/pull/10319 From phh at openjdk.org Tue Sep 20 17:15:33 2022 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 20 Sep 2022 17:15:33 GMT Subject: Integrated: 8293828: JFR: jfr/event/oldobject/TestClassLoaderLeak.java still fails when GC cycles are not happening In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 23:38:16 GMT, Paul Hohensee wrote: > Trivial change to get a test to run reliably on Shenandoah and ZGC. This pull request has now been integrated. Changeset: 5002eaa5 Author: Paul Hohensee URL: https://git.openjdk.org/jdk/commit/5002eaa5cc7301b91a45f8c0f65b5943fea225d8 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8293828: JFR: jfr/event/oldobject/TestClassLoaderLeak.java still fails when GC cycles are not happening Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/10319 From coffeys at openjdk.org Wed Sep 21 15:22:17 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 21 Sep 2022 15:22:17 GMT Subject: RFR: 8254711: Add java.security.Provider.getService JFR Event [v3] In-Reply-To: References: Message-ID: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Correct Label annontation capitals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9657/files - new: https://git.openjdk.org/jdk/pull/9657/files/e168152f..31cedc3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9657&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9657.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9657/head:pull/9657 PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Thu Sep 22 13:57:48 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 22 Sep 2022 13:57:48 GMT Subject: Integrated: 8254711: Add java.security.Provider.getService JFR Event In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote: > Add a JFR Event for `java.security.Provider.getService(String type, String algorithm)` calls. This pull request has now been integrated. Changeset: bc2af47e Author: Sean Coffey URL: https://git.openjdk.org/jdk/commit/bc2af47e1e4e6e96020e03a60ce098ddd17f63ba Stats: 280 lines in 9 files changed: 271 ins; 1 del; 8 mod 8254711: Add java.security.Provider.getService JFR Event Reviewed-by: mullan, valeriep, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9657 From coffeys at openjdk.org Thu Sep 22 16:11:02 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 22 Sep 2022 16:11:02 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event Message-ID: New JFR event to record state of initial security properties. Debug output is also now added for these properties via -Djava.security.debug=properties ------------- Commit messages: - merge with master - Correct test bug ids - fix up imports - Add security debug test logic - Add JFR testcase - remove mirror event - 8292177 initial commit Changes: https://git.openjdk.org/jdk/pull/10394/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292177 Stats: 200 lines in 11 files changed: 196 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10394.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394 PR: https://git.openjdk.org/jdk/pull/10394 From egahlin at openjdk.org Tue Sep 27 15:16:15 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 27 Sep 2022 15:16:15 GMT Subject: RFR: 8291022: JFR: Reduce logging in ChunkHeader constructor Message-ID: Could I have review of change that removes some unnecessary and unreliable logging. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Remove traling whitepace - Initial Changes: https://git.openjdk.org/jdk/pull/9640/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9640&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291022 Stats: 16 lines in 1 file changed: 6 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9640.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9640/head:pull/9640 PR: https://git.openjdk.org/jdk/pull/9640 From mgronlun at openjdk.org Tue Sep 27 15:16:15 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 27 Sep 2022 15:16:15 GMT Subject: RFR: 8291022: JFR: Reduce logging in ChunkHeader constructor In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 14:48:31 GMT, Erik Gahlin wrote: > Could I have review of change that removes some unnecessary and unreliable logging. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9640 From mgronlun at openjdk.org Tue Sep 27 15:18:15 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 27 Sep 2022 15:18:15 GMT Subject: RFR: 8291021: JFR: Only one finished state in ChunkHeader class In-Reply-To: <0vIf7asb5YCGCpBMPDAJXMILlvZV0DIAImpV4KlrLsQ=.7db5f720-5b99-455a-8502-0b2cbddc50e7@github.com> References: <0vIf7asb5YCGCpBMPDAJXMILlvZV0DIAImpV4KlrLsQ=.7db5f720-5b99-455a-8502-0b2cbddc50e7@github.com> Message-ID: On Tue, 26 Jul 2022 13:50:21 GMT, Erik Gahlin wrote: > Could I have a review of PR that removes the field isFinished in the ChunkHeader class. It's sufficient with the finished field. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9639 From egahlin at openjdk.org Tue Sep 27 15:18:14 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 27 Sep 2022 15:18:14 GMT Subject: RFR: 8291021: JFR: Only one finished state in ChunkHeader class Message-ID: <0vIf7asb5YCGCpBMPDAJXMILlvZV0DIAImpV4KlrLsQ=.7db5f720-5b99-455a-8502-0b2cbddc50e7@github.com> Could I have a review of PR that removes the field isFinished in the ChunkHeader class. It's sufficient with the finished field. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/9639/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9639&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291021 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9639.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9639/head:pull/9639 PR: https://git.openjdk.org/jdk/pull/9639 From egahlin at openjdk.org Tue Sep 27 15:40:10 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 27 Sep 2022 15:40:10 GMT Subject: RFR: 8291428: JFR: 'jfr print' displays incorrect timestamps during DST Message-ID: <143MGh-jb87TroE4NNcs_jLFSSVci6ynPTyR4yB-tZk=.1508fe35-0c68-4c58-8749-59c3be5f45e7@github.com> Could I have a review of change that fixes incorrect timestamp during DST. For details see issue. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/9666/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9666&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291428 Stats: 18 lines in 5 files changed: 11 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9666.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9666/head:pull/9666 PR: https://git.openjdk.org/jdk/pull/9666 From mgronlun at openjdk.org Tue Sep 27 15:40:11 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 27 Sep 2022 15:40:11 GMT Subject: RFR: 8291428: JFR: 'jfr print' displays incorrect timestamps during DST In-Reply-To: <143MGh-jb87TroE4NNcs_jLFSSVci6ynPTyR4yB-tZk=.1508fe35-0c68-4c58-8749-59c3be5f45e7@github.com> References: <143MGh-jb87TroE4NNcs_jLFSSVci6ynPTyR4yB-tZk=.1508fe35-0c68-4c58-8749-59c3be5f45e7@github.com> Message-ID: On Wed, 27 Jul 2022 22:58:54 GMT, Erik Gahlin wrote: > Could I have a review of change that fixes incorrect timestamp during DST. For details see issue. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9666 From mullan at openjdk.org Tue Sep 27 20:35:21 2022 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 27 Sep 2022 20:35:21 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey wrote: > New JFR event to record state of initial security properties. > > Debug output is also now added for these properties via -Djava.security.debug=properties src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312: > 310: } > 311: > 312: private static void emitInitialSecurityProperties() { Is the `Security` class loaded and have the properties always been populated at this point? ProtectionDomain` doesn't reference the `Security` class AFAICT. src/jdk.jfr/share/conf/jfr/default.jfc line 713: > 711: > 712: > 713: true The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though. ------------- PR: https://git.openjdk.org/jdk/pull/10394 From jpai at openjdk.org Wed Sep 28 07:10:22 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 28 Sep 2022 07:10:22 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey wrote: > New JFR event to record state of initial security properties. > > Debug output is also now added for these properties via -Djava.security.debug=properties Hello Sean, > Debug output is also now added for these properties via -Djava.security.debug=properties Looking at the existing code upstream, it appears that the value `properties` is already recognized for `java.security.debug` system property. So it's not something this PR is introducing/proposing. However, the documentation for this system property doesn't seem to be listing that as a value https://docs.oracle.com/en/java/javase/19/security/troubleshooting-security.html. Do you think that documentation would need to be addressed (as a separate issue)? ------------- PR: https://git.openjdk.org/jdk/pull/10394 From coffeys at openjdk.org Wed Sep 28 10:09:41 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 28 Sep 2022 10:09:41 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 20:29:31 GMT, Sean Mullan wrote: >> New JFR event to record state of initial security properties. >> >> Debug output is also now added for these properties via -Djava.security.debug=properties > > src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312: > >> 310: } >> 311: >> 312: private static void emitInitialSecurityProperties() { > > Is the `Security` class loaded and have the properties always been populated at this point? ProtectionDomain` doesn't reference the `Security` class AFAICT. Good catch. JFR does load the Security class [1] via other dependencies but we shouldn't depend on that. I'll add a null check here. If Security class hasn't been loaded, then we shouldn't record any events. [1] java.lang.Throwable at java.base/java.security.Security.(Security.java:73) at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57) at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48) at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72) at java.base/sun.security.util.SecurityProperties.(SecurityProperties.java:36) at java.base/sun.security.util.FilePermCompat.(FilePermCompat.java:43) at java.base/java.security.AccessControlContext.(AccessControlContext.java:270) at java.base/java.security.AccessController.createWrapper(AccessController.java:649) at java.base/java.security.AccessController.doPrivileged(AccessController.java:461) at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261) at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331) at jdk.jfr/jdk.jfr.internal.SecuritySupport.(SecuritySupport.java:80) at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46) at jdk.jfr/jdk.jfr.internal.JVMSupport.(JVMSupport.java:41) at jdk.jfr/jdk.jfr.internal.Logger.(Logger.java:41) at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75) > src/jdk.jfr/share/conf/jfr/default.jfc line 713: > >> 711: >> 712: >> 713: true > > The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though. Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment. ------------- PR: https://git.openjdk.org/jdk/pull/10394 From coffeys at openjdk.org Wed Sep 28 10:16:22 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 28 Sep 2022 10:16:22 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: References: Message-ID: > New JFR event to record state of initial security properties. > > Debug output is also now added for these properties via -Djava.security.debug=properties Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Null check on Properties ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10394/files - new: https://git.openjdk.org/jdk/pull/10394/files/5343a056..aed938d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10394.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394 PR: https://git.openjdk.org/jdk/pull/10394 From coffeys at openjdk.org Wed Sep 28 10:16:24 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 28 Sep 2022 10:16:24 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 07:06:30 GMT, Jaikiran Pai wrote: > Hello Sean, > > > Debug output is also now added for these properties via -Djava.security.debug=properties > > Looking at the existing code upstream, it appears that the value `properties` is already recognized for `java.security.debug` system property. So it's not something this PR is introducing/proposing. However, the documentation for this system property doesn't seem to be listing that as a value https://docs.oracle.com/en/java/javase/19/security/troubleshooting-security.html. Do you think that documentation would need to be addressed (as a separate issue)? Good point Jai. It's a rarely used property value I guess, but it would be exposed via the "all" debug value option as per test. I suspect there may be other such properties also. I'll log a JBS issue to track this and to have security/docs team discuss. ------------- PR: https://git.openjdk.org/jdk/pull/10394 From mullan at openjdk.org Wed Sep 28 12:30:23 2022 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 28 Sep 2022 12:30:23 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: References: Message-ID: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> On Wed, 28 Sep 2022 10:06:54 GMT, Sean Coffey wrote: >> src/jdk.jfr/share/conf/jfr/default.jfc line 713: >> >>> 711: >>> 712: >>> 713: true >> >> The other security related events are not enabled by default. Is this one enabled because it is only generated once? It seems it may still have some startup overhead because AFAIU it forces a load of security properties even if they are never accessed? Perhaps I don't fully understand how this event works though. > > Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. > > We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment. Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right? ------------- PR: https://git.openjdk.org/jdk/pull/10394 From mgronlun at openjdk.org Wed Sep 28 12:42:11 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 28 Sep 2022 12:42:11 GMT Subject: RFR: 8293864: Kitchensink24HStress.java fails with SIGSEGV in JfrCheckpointManager::lease Message-ID: Greetings, With [JDK-8289692](https://bugs.openjdk.org/browse/JDK-8289692), a need arose to introduce a mutex mechanism for the buffers on the global list to prevent the JFR Recorder Thread from resetting buffers currently in use. The introduced mutex mechanism was adequate as far as preventing the race condition. However, its protective characteristic was overemphasized, leading to the mistake of introducing a release, or removal, operation onto a current epoch list, as part of periodic flushing. The problem is that although the callback operations are safe, the underlying list type used with the global mspace does not allow for concurrent excision of nodes. The crash occurs because a thread attempts to dereference the next pointer to traverse a node that is excised and deleted after the thread loaded it. I have reviewed how to handle better the introduction of virtual threads and their checkpoint data. I have concluded that the best way is to preserve the old system (pre-Loom) as much as possible, keeping the global and thread-local mspaces as before. Instead, an additional mspace dedicated solely to virtual threads is introduced. This categorization preserves the matching of operations against the underlying list infrastructure. It also provides flexibility in handling virtual threads distinct from regular, or "carrier", threads. The separate mspace of virtual threads is more dynamic as it does not need to preallocate buffers, a memory win for systems not using virtual threads. Also, the sizes of the different buffer types can be better controlled. With this restructuring, there are no longer any list concurrency issues; hence the mutex mechanism introduced with [JDK-8289692](https://bugs.openjdk.org/browse/JDK-8289692) becomes obsolete. Applying a release operation for the current epoch list, of the global mspace, as part of flushing is a broken invariant and is therefore removed. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - 8293864 Changes: https://git.openjdk.org/jdk/pull/10467/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10467&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293864 Stats: 217 lines in 9 files changed: 100 ins; 33 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/10467.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10467/head:pull/10467 PR: https://git.openjdk.org/jdk/pull/10467 From coffeys at openjdk.org Wed Sep 28 12:54:19 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 28 Sep 2022 12:54:19 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> References: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> Message-ID: On Wed, 28 Sep 2022 12:26:49 GMT, Sean Mullan wrote: >> Yes - the thinking here is that since this is a one time event, we can have it enabled. It's similar to the InitialSystemProperty event. >> >> We won't force loading of Security properties/class. We shouldn't at least. If no security properties are read in at time of JFR event commit, then we should have no InitialSecurityProperty events. See below/next comment. > > Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right? Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level) ------------- PR: https://git.openjdk.org/jdk/pull/10394 From mullan at openjdk.org Wed Sep 28 16:36:15 2022 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 28 Sep 2022 16:36:15 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: References: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> Message-ID: On Wed, 28 Sep 2022 12:52:02 GMT, Sean Coffey wrote: >> Ok, just so I understand, you want to make sure that if JFR is started after the security properties have already been read, then they are still recorded, right? > > Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level) How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled. ------------- PR: https://git.openjdk.org/jdk/pull/10394 From coffeys at openjdk.org Thu Sep 29 10:04:18 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 29 Sep 2022 10:04:18 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: References: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> Message-ID: On Wed, 28 Sep 2022 16:32:17 GMT, Sean Mullan wrote: >> Correct - this type of event period (beginChunk) will fire once when the JFR recording is begun. It should capture Security Properties (if java.security.Security is loaded) for any recording, no matter when it might begin or end. Similar to how InitialSystemProperty is captured (but that's implemented at native/VM level) > > How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled. As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. @egahlin - would you have a preference on this ? ------------- PR: https://git.openjdk.org/jdk/pull/10394 From egahlin at openjdk.org Thu Sep 29 11:43:11 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 29 Sep 2022 11:43:11 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: References: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> Message-ID: On Thu, 29 Sep 2022 10:02:05 GMT, Sean Coffey wrote: >> How does it capture the event if JFR was started before the security properties were read? I would think you still need some additional code in Security.java to record the properties if the event is enabled. > > As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. > @egahlin - would you have a preference on this ? With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data. That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories? If the event triggers class loading, it might make sense to check if the event is enabled first. ------------- PR: https://git.openjdk.org/jdk/pull/10394 From coffeys at openjdk.org Thu Sep 29 15:14:28 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 29 Sep 2022 15:14:28 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: References: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> Message-ID: <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com> On Thu, 29 Sep 2022 11:41:02 GMT, Erik Gahlin wrote: >> As per yesterday's stack trace, JFR triggers loading of the Security class - so your scenario won't arise with current state. We could include the new Event with period of `endChunk `instead of `beingChunk `setting. That should ensure the properties are only captured when the JFR recording is exiting. >> @egahlin - would you have a preference on this ? > > With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data. > > That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories? > > If the event triggers class loading, it might make sense to check if the event is enabled first. Thanks @egahlin - maybe we can leave it at beginChunk setting then. I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. `ProtectionDomain ` is a very early class to initialize [1] (initPhase2) Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps [2] - the JMX thread starts after about 3 seconds of runtime. Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test. If JFR is on, then Security class is already being loaded, even without this patch [3] [1] at java.base/java.security.ProtectionDomain.(ProtectionDomain.java:64) at java.base/java.lang.ClassLoader.(ClassLoader.java:316) at java.base/java.lang.ClassLoader.(ClassLoader.java:431) at java.base/java.security.SecureClassLoader.(SecureClassLoader.java:113) at java.base/jdk.internal.loader.BuiltinClassLoader.(BuiltinClassLoader.java:194) at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.(ClassLoaders.java:135) at java.base/jdk.internal.loader.ClassLoaders.(ClassLoaders.java:79) at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120) at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266) at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174) at java.base/java.lang.System.initPhase2(System.java:2214) [2] at java.base/java.security.Security.(Security.java:73) at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93) at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90) at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) at java.base/sun.net.InetAddressCachePolicy.(InetAddressCachePolicy.java:89) at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005) at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658) at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524) at java.base/java.net.InetAddress.getByName(InetAddress.java:1413) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531) at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317) [3] at java.base/java.security.Security.(Security.java:73) at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57) at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48) at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72) at java.base/sun.security.util.SecurityProperties.(SecurityProperties.java:36) at java.base/sun.security.util.FilePermCompat.(FilePermCompat.java:43) at java.base/java.security.AccessControlContext.(AccessControlContext.java:270) at java.base/java.security.AccessController.createWrapper(AccessController.java:649) at java.base/java.security.AccessController.doPrivileged(AccessController.java:461) at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261) at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331) at jdk.jfr/jdk.jfr.internal.SecuritySupport.(SecuritySupport.java:80) at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46) at jdk.jfr/jdk.jfr.internal.JVMSupport.(JVMSupport.java:41) at jdk.jfr/jdk.jfr.internal.Logger.(Logger.java:41) at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75) ------------- PR: https://git.openjdk.org/jdk/pull/10394 From egahlin at openjdk.org Thu Sep 29 20:53:57 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 29 Sep 2022 20:53:57 GMT Subject: RFR: 8294151: JFR: Unclear exception message when dumping stopped in memory recording Message-ID: Hi Could I have a review of a change that updates the specification for the Recording::dump(Path) method and the exception message if the method fails. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/10488/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10488&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294151 Stats: 48 lines in 4 files changed: 38 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10488.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10488/head:pull/10488 PR: https://git.openjdk.org/jdk/pull/10488 From egahlin at openjdk.org Thu Sep 29 23:36:01 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 29 Sep 2022 23:36:01 GMT Subject: RFR: 8294242: JFR: jfr print doesn't handle infinite duration well Message-ID: <0rXgqAHzaAnC3KxR7_Dc77eY8cJUcFLxMEI0HrOH1ec=.99a48433-f1e1-4509-9281-a245bf826035@github.com> Hi, Could I have review of a fix that improves the output of the jfr tool when there are event values that are infinite Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/10497/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10497&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294242 Stats: 35 lines in 5 files changed: 30 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10497.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10497/head:pull/10497 PR: https://git.openjdk.org/jdk/pull/10497 From egahlin at openjdk.org Fri Sep 30 12:08:28 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 Sep 2022 12:08:28 GMT Subject: RFR: 8294242: JFR: jfr print doesn't handle infinite duration well [v2] In-Reply-To: <0rXgqAHzaAnC3KxR7_Dc77eY8cJUcFLxMEI0HrOH1ec=.99a48433-f1e1-4509-9281-a245bf826035@github.com> References: <0rXgqAHzaAnC3KxR7_Dc77eY8cJUcFLxMEI0HrOH1ec=.99a48433-f1e1-4509-9281-a245bf826035@github.com> Message-ID: > Hi, > > Could I have review of a fix that improves the output of the jfr tool when there are event values that are infinite > > Testing: jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Revert change from other PR that was accidentally added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10497/files - new: https://git.openjdk.org/jdk/pull/10497/files/a761649d..23255054 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10497&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10497&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10497.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10497/head:pull/10497 PR: https://git.openjdk.org/jdk/pull/10497 From egahlin at openjdk.org Fri Sep 30 12:24:49 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 Sep 2022 12:24:49 GMT Subject: RFR: 8292336: JFR: Warn users if -XX:StartFlightRecording:disk=false is specified with maxage or maxsize Message-ID: Hi, Could I have a review of PR that adds a warning message if maxage or maxsize is set when disk = false. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/10508/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10508&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292336 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10508.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10508/head:pull/10508 PR: https://git.openjdk.org/jdk/pull/10508 From egahlin at openjdk.org Fri Sep 30 12:29:01 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 Sep 2022 12:29:01 GMT Subject: RFR: 8293099: JFR: Typo in TestRemoteDump.java Message-ID: Could I have a review of this test fix. Testing: jdk/jdk/jfr/jmx/TestRemoteDump.java Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/10509/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10509&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293099 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10509.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10509/head:pull/10509 PR: https://git.openjdk.org/jdk/pull/10509 From mgronlun at openjdk.org Fri Sep 30 12:31:20 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 30 Sep 2022 12:31:20 GMT Subject: RFR: 8294151: JFR: Unclear exception message when dumping stopped in memory recording In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 13:50:49 GMT, Erik Gahlin wrote: > Hi > > > Could I have a review of a change that updates the specification for the Recording::dump(Path) method and the exception message if the method fails. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10488 From mgronlun at openjdk.org Fri Sep 30 12:48:20 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 30 Sep 2022 12:48:20 GMT Subject: RFR: 8292336: JFR: Warn users if -XX:StartFlightRecording:disk=false is specified with maxage or maxsize In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 12:10:31 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of PR that adds a warning message if maxage or maxsize is set when disk = false. > > Testing: jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10508 From mgronlun at openjdk.org Fri Sep 30 12:48:47 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 30 Sep 2022 12:48:47 GMT Subject: RFR: 8294242: JFR: jfr print doesn't handle infinite duration well [v2] In-Reply-To: References: <0rXgqAHzaAnC3KxR7_Dc77eY8cJUcFLxMEI0HrOH1ec=.99a48433-f1e1-4509-9281-a245bf826035@github.com> Message-ID: On Fri, 30 Sep 2022 12:08:28 GMT, Erik Gahlin wrote: >> Hi, >> >> Could I have review of a fix that improves the output of the jfr tool when there are event values that are infinite >> >> Testing: jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Revert change from other PR that was accidentally added Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10497 From mgronlun at openjdk.org Fri Sep 30 12:50:12 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 30 Sep 2022 12:50:12 GMT Subject: RFR: 8293099: JFR: Typo in TestRemoteDump.java In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 12:16:04 GMT, Erik Gahlin wrote: > Could I have a review of this test fix. > > Testing: jdk/jdk/jfr/jmx/TestRemoteDump.java > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10509 From egahlin at openjdk.org Fri Sep 30 13:13:34 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 Sep 2022 13:13:34 GMT Subject: Integrated: 8291021: JFR: Only one finished state in ChunkHeader class In-Reply-To: <0vIf7asb5YCGCpBMPDAJXMILlvZV0DIAImpV4KlrLsQ=.7db5f720-5b99-455a-8502-0b2cbddc50e7@github.com> References: <0vIf7asb5YCGCpBMPDAJXMILlvZV0DIAImpV4KlrLsQ=.7db5f720-5b99-455a-8502-0b2cbddc50e7@github.com> Message-ID: On Tue, 26 Jul 2022 13:50:21 GMT, Erik Gahlin wrote: > Could I have a review of PR that removes the field isFinished in the ChunkHeader class. It's sufficient with the finished field. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: c2ce43cb Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/c2ce43cbb07284419f6d511a2ac78fa53aca095e Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8291021: JFR: Only one finished state in ChunkHeader class Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/9639 From egahlin at openjdk.org Fri Sep 30 16:34:33 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 Sep 2022 16:34:33 GMT Subject: Integrated: 8291022: JFR: Reduce logging in ChunkHeader constructor In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 14:48:31 GMT, Erik Gahlin wrote: > Could I have review of change that removes some unnecessary and unreliable logging. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 1d26c4b1 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/1d26c4b1496cd95510b13e3dba7345a796fbc61c Stats: 16 lines in 1 file changed: 6 ins; 2 del; 8 mod 8291022: JFR: Reduce logging in ChunkHeader constructor Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/9640 From egahlin at openjdk.org Fri Sep 30 17:37:27 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 Sep 2022 17:37:27 GMT Subject: Integrated: 8291428: JFR: 'jfr print' displays incorrect timestamps during DST In-Reply-To: <143MGh-jb87TroE4NNcs_jLFSSVci6ynPTyR4yB-tZk=.1508fe35-0c68-4c58-8749-59c3be5f45e7@github.com> References: <143MGh-jb87TroE4NNcs_jLFSSVci6ynPTyR4yB-tZk=.1508fe35-0c68-4c58-8749-59c3be5f45e7@github.com> Message-ID: On Wed, 27 Jul 2022 22:58:54 GMT, Erik Gahlin wrote: > Could I have a review of change that fixes incorrect timestamp during DST. For details see issue. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 48674d4f Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/48674d4f363900abd625350b32236de406d45d7a Stats: 18 lines in 5 files changed: 11 ins; 0 del; 7 mod 8291428: JFR: 'jfr print' displays incorrect timestamps during DST Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/9666 From mullan at openjdk.org Fri Sep 30 19:36:23 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 30 Sep 2022 19:36:23 GMT Subject: RFR: 8292177: InitialSecurityProperty JFR event [v2] In-Reply-To: <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com> References: <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com> <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com> Message-ID: On Thu, 29 Sep 2022 15:12:06 GMT, Sean Coffey wrote: >> With event streaming, beginChunk is usually to prefer. Otherwise, a client that monitors the JVM must wait until the first chunk rotation to get the data. >> >> That said, we want startup to be quick. There should probably be a common parameter, i.e. security=off/normal/audit/trace, that handles enablement for all security events. I don't know how expensive this event is and where it would fit among those categories? >> >> If the event triggers class loading, it might make sense to check if the event is enabled first. > > Thanks @egahlin - maybe we can leave it at beginChunk setting then. > > I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). > > This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. > > `ProtectionDomain ` is a very early class to initialize [1] (initPhase2) > > Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps [2] - the JMX thread starts after about 3 seconds of runtime. > > Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test. > > If JFR is on, then Security class is already being loaded, even without this patch [3] > > [1] > > at java.base/java.security.ProtectionDomain.(ProtectionDomain.java:64) > at java.base/java.lang.ClassLoader.(ClassLoader.java:316) > at java.base/java.lang.ClassLoader.(ClassLoader.java:431) > at java.base/java.security.SecureClassLoader.(SecureClassLoader.java:113) > at java.base/jdk.internal.loader.BuiltinClassLoader.(BuiltinClassLoader.java:194) > at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.(ClassLoaders.java:135) > at java.base/jdk.internal.loader.ClassLoaders.(ClassLoaders.java:79) > at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120) > at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266) > at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174) > at java.base/java.lang.System.initPhase2(System.java:2214) > > > [2] > > at java.base/java.security.Security.(Security.java:73) > at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93) > at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) > at java.base/sun.net.InetAddressCachePolicy.(InetAddressCachePolicy.java:89) > at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005) > at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658) > at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524) > at java.base/java.net.InetAddress.getByName(InetAddress.java:1413) > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531) > at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317) > > > [3] > > > at java.base/java.security.Security.(Security.java:73) > at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57) > at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48) > at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72) > at java.base/sun.security.util.SecurityProperties.(SecurityProperties.java:36) > at java.base/sun.security.util.FilePermCompat.(FilePermCompat.java:43) > at java.base/java.security.AccessControlContext.(AccessControlContext.java:270) > at java.base/java.security.AccessController.createWrapper(AccessController.java:649) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:461) > at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261) > at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331) > at jdk.jfr/jdk.jfr.internal.SecuritySupport.(SecuritySupport.java:80) > at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46) > at jdk.jfr/jdk.jfr.internal.JVMSupport.(JVMSupport.java:41) > at jdk.jfr/jdk.jfr.internal.Logger.(Logger.java:41) > at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75) When support for the SM is removed, the dependency on `AccessController.doPrivileged` will be removed and there may no longer be a JFR dependency on loading the `Security` class. So, it is ok for now, but a solution that doesn't depend on this might be better in the long run. ------------- PR: https://git.openjdk.org/jdk/pull/10394