From dholmes at openjdk.org Fri Nov 1 12:47:29 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 12:47:29 GMT Subject: RFR: 8343177: JFR: Remove critical section for thread id assignment [v3] In-Reply-To: References: <430mnItIA1UjjtseRV4_duukmmJ5A8_NewyVG9oiGS8=.d810700f-4217-4d32-a235-c65a7ab88da8@github.com> Message-ID: On Thu, 31 Oct 2024 12:15:05 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> With Loom, JFR had to change the assignment of unique thread IDs to threads. For JavaThreads, a dependency exists on the threadObj before the thread ID can be determined and assigned. We currently have a lazy assignment scheme that assigns on first use. Several threads, such as thread iterators and sampling threads, can issue the first use. Hence, a critical section protects assignments. >> >> However, a critical section at this location makes it challenging to build robust signal handlers, for example, because we cannot read the thread ID. >> >> We can remove this critical section with careful rearrangements, ensuring threads are only assigned a thread ID in thread state _thread_new (a thread state that at least the JFR sampler and the JFR iterators exclude). >> >> The problem child is JNI attaching threads, created directly into state _thread_in_vm and added to the threads list before the creation and assignment of the threadObj. We can also manage this case by being careful when we sample such a thread, alternatively allowing for a thread ID of 0 or taking account of the 'attaching via jni' property. >> >> Testing: jdk_jfr Tier 1- 3, Stress testing >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > rename primordial to main thread Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21756#pullrequestreview-2410005294 From mgronlun at openjdk.org Fri Nov 1 13:31:29 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Nov 2024 13:31:29 GMT Subject: RFR: 8343177: JFR: Remove critical section for thread id assignment [v3] In-Reply-To: References: <430mnItIA1UjjtseRV4_duukmmJ5A8_NewyVG9oiGS8=.d810700f-4217-4d32-a235-c65a7ab88da8@github.com> Message-ID: On Fri, 1 Nov 2024 12:44:56 GMT, David Holmes wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> rename primordial to main thread > > Marked as reviewed by dholmes (Reviewer). Thanks @dholmes-ora for your review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21756#issuecomment-2451874805 From mgronlun at openjdk.org Fri Nov 1 14:54:33 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Nov 2024 14:54:33 GMT Subject: Integrated: 8343177: JFR: Remove critical section for thread id assignment In-Reply-To: <430mnItIA1UjjtseRV4_duukmmJ5A8_NewyVG9oiGS8=.d810700f-4217-4d32-a235-c65a7ab88da8@github.com> References: <430mnItIA1UjjtseRV4_duukmmJ5A8_NewyVG9oiGS8=.d810700f-4217-4d32-a235-c65a7ab88da8@github.com> Message-ID: On Tue, 29 Oct 2024 10:28:45 GMT, Markus Gr?nlund wrote: > Greetings, > > With Loom, JFR had to change the assignment of unique thread IDs to threads. For JavaThreads, a dependency exists on the threadObj before the thread ID can be determined and assigned. We currently have a lazy assignment scheme that assigns on first use. Several threads, such as thread iterators and sampling threads, can issue the first use. Hence, a critical section protects assignments. > > However, a critical section at this location makes it challenging to build robust signal handlers, for example, because we cannot read the thread ID. > > We can remove this critical section with careful rearrangements, ensuring threads are only assigned a thread ID in thread state _thread_new (a thread state that at least the JFR sampler and the JFR iterators exclude). > > The problem child is JNI attaching threads, created directly into state _thread_in_vm and added to the threads list before the creation and assignment of the threadObj. We can also manage this case by being careful when we sample such a thread, alternatively allowing for a thread ID of 0 or taking account of the 'attaching via jni' property. > > Testing: jdk_jfr Tier 1- 3, Stress testing > > Thanks > Markus This pull request has now been integrated. Changeset: 5995786d Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/5995786dbd69ed11dd1cacb2a3ac86e3e6f43ab7 Stats: 79 lines in 10 files changed: 46 ins; 13 del; 20 mod 8343177: JFR: Remove critical section for thread id assignment Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/21756 From dholmes at openjdk.org Mon Nov 4 02:47:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 02:47:39 GMT Subject: RFR: 8343177: JFR: Remove critical section for thread id assignment [v3] In-Reply-To: References: <430mnItIA1UjjtseRV4_duukmmJ5A8_NewyVG9oiGS8=.d810700f-4217-4d32-a235-c65a7ab88da8@github.com> Message-ID: On Fri, 1 Nov 2024 13:29:16 GMT, Markus Gr?nlund wrote: >> Marked as reviewed by dholmes (Reviewer). > > Thanks @dholmes-ora for your review. @mgronlun - two reviews required for hotspot changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21756#issuecomment-2453733328 From shade at openjdk.org Mon Nov 4 19:13:44 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Nov 2024 19:13:44 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v9] In-Reply-To: References: Message-ID: > While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). > > Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. > > I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. > > This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. > > Additional testing: > - [x] `jdk_jfr` pass by default > - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah - Disable Shenandoah-targeted test specially - Redo the whole thing by disabling Leak Prof with Shenandoah - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah - Just exclude the tests for Shenandoah - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah - Tighten up comments prose - Roman's review: more precise GC state check, more includes - ... and 3 more: https://git.openjdk.org/jdk/compare/23fa1a33...d47b1665 ------------- Changes: https://git.openjdk.org/jdk/pull/20328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20328&range=08 Stats: 67 lines in 34 files changed: 39 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/20328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20328/head:pull/20328 PR: https://git.openjdk.org/jdk/pull/20328 From tprinzing at openjdk.org Tue Nov 5 03:24:51 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 5 Nov 2024 03:24:51 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v2] In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: > Adds a JFR event for socket connect operations. > > Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: Added support for connection failure and non-blocking connections. If an exception is thrown while attempting a connection, the message from the exception is stored in the event. The start time of the initial connect call is stored and used when a finishConnect call is successful or an exception is thrown. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21528/files - new: https://git.openjdk.org/jdk/pull/21528/files/05227c9d..7113bd75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=00-01 Stats: 91 lines in 4 files changed: 44 ins; 14 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/21528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528 PR: https://git.openjdk.org/jdk/pull/21528 From shade at openjdk.org Tue Nov 5 09:08:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 5 Nov 2024 09:08:42 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v9] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 19:13:44 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Disable Shenandoah-targeted test specially > - Redo the whole thing by disabling Leak Prof with Shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Just exclude the tests for Shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Tighten up comments prose > - Roman's review: more precise GC state check, more includes > - ... and 3 more: https://git.openjdk.org/jdk/compare/23fa1a33...d47b1665 Local testing passes. Please re-review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2456610619 From egahlin at openjdk.org Tue Nov 5 10:00:33 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 5 Nov 2024 10:00:33 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v9] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 19:13:44 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Disable Shenandoah-targeted test specially > - Redo the whole thing by disabling Leak Prof with Shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Just exclude the tests for Shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Tighten up comments prose > - Roman's review: more precise GC state check, more includes > - ... and 3 more: https://git.openjdk.org/jdk/compare/23fa1a33...d47b1665 I'm not sure why all these tests are run with Shenandoah (or any specific GC). The purpose of these unit tests is to check the Leak Profiler implementation, for example, that the object age is written correctly or that array information is serialized properly. It doesn't matter which GC, compiler, etc. is being used. When the JFR tests were initially written, the purpose of the jtreg "jfr" tag was to filter out the JFR tests so they don't receive external flags. Since then, I think vm.flagless has been added. It may be more appropriate. If the interaction with a certain GC needs to be tested, it's better to write a dedicated test for that, like TestG1.java and TestZ.java. If such a test doesn't work, it can be put on the ProblemList. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2456731236 From shade at openjdk.org Tue Nov 5 10:11:30 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 5 Nov 2024 10:11:30 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v9] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 09:58:10 GMT, Erik Gahlin wrote: > I'm not sure why all these tests are run with Shenandoah (or any specific GC). It is common to run tests with specific VM options overridden/amended for extensive testing. For example, `make test TEST=jdk_jfr TEST_VM_OPTS=-XX:+UseShenandoahGC`. This is why OpenJDK test suites generally accept `@requires` filters that can test if we are running in a particular configuration the test is not supposed to work in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2456755843 From shade at openjdk.org Tue Nov 5 10:28:32 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 5 Nov 2024 10:28:32 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v9] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 19:13:44 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Disable Shenandoah-targeted test specially > - Redo the whole thing by disabling Leak Prof with Shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Just exclude the tests for Shenandoah > - Merge branch 'master' into JDK-8279016-jfr-leak-profiler-shenandoah > - Tighten up comments prose > - Roman's review: more precise GC state check, more includes > - ... and 3 more: https://git.openjdk.org/jdk/compare/23fa1a33...d47b1665 I can redo this for Shenandoah-specific problem lists, for sure. ZGC does GC-specific problem lists, Shenandoah can do some as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2456793615 From shade at openjdk.org Tue Nov 5 11:10:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 5 Nov 2024 11:10:14 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v10] In-Reply-To: References: Message-ID: > While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). > > Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. > > I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. > > This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. > > Additional testing: > - [x] `jdk_jfr` pass by default > - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Use Shenandoah ProblemLists ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20328/files - new: https://git.openjdk.org/jdk/pull/20328/files/d47b1665..2d1987b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20328&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20328&range=08-09 Stats: 115 lines in 34 files changed: 64 ins; 23 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/20328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20328/head:pull/20328 PR: https://git.openjdk.org/jdk/pull/20328 From shade at openjdk.org Tue Nov 5 11:10:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 5 Nov 2024 11:10:14 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v9] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 10:26:12 GMT, Aleksey Shipilev wrote: > I can redo this for Shenandoah-specific problem lists, for sure. ZGC does GC-specific problem lists, Shenandoah can do some as well. But we will always have to remember to add new LeakProfiler tests there. Did so, see new commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2456881779 From egahlin at openjdk.org Tue Nov 5 11:42:30 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 5 Nov 2024 11:42:30 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v10] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 11:10:14 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Use Shenandoah ProblemLists Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20328#pullrequestreview-2415386469 From mgronlun at openjdk.org Tue Nov 5 12:33:06 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 5 Nov 2024 12:33:06 GMT Subject: RFR: 8342105: JVM Crash when Jacoco and JFR are active Message-ID: Greetings, JFR hooking invocations of deprecated methods have a problem supporting Condy because these involve indirect invocations (via a bootstrap method) and do not have a reified bytecode invocation instruction (which gets support structures in the MDO). The bytecode for a condy invocation is ldc or fast_aload (when the bytecode is rewritten), and no MDO support structures are added for these. ConstantPool idx 0x55: ("Condy") #55 = Dynamic #0:#54 // #0:$jacocoData:Ljava/lang/Object; CONSTANT_Dynamic_info { u1 tag; u2 bootstrap_method_attr_index; [0] u2 name_and_type_index; [54] } For additional details, please take a look at the JIRA issue. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8342105 Changes: https://git.openjdk.org/jdk/pull/21902/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21902&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342105 Stats: 23 lines in 1 file changed: 20 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21902.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21902/head:pull/21902 PR: https://git.openjdk.org/jdk/pull/21902 From mgronlun at openjdk.org Tue Nov 5 13:15:56 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 5 Nov 2024 13:15:56 GMT Subject: RFR: 8342105: JVM Crash when Jacoco and JFR are active [v2] In-Reply-To: References: Message-ID: <07VxBHNpUVgYUAo5mGSRaEtngurJPFYzIk0cCkjq3BQ=.2b072e3b-06c9-40fb-9134-69dfa498a54b@github.com> > Greetings, > > JFR hooking invocations of deprecated methods have a problem supporting Condy because these involve indirect invocations (via a bootstrap method) and do not have a reified bytecode invocation instruction (which gets support structures in the MDO). > > The bytecode for a condy invocation is ldc or fast_aload (when the bytecode is rewritten), and no MDO support structures are added for these. > > ConstantPool idx 0x55: ("Condy") > > 55 = Dynamic 0:54 // 0:$jacocoData:Ljava/lang/Object; > > CONSTANT_Dynamic_info { > u1 tag; > u2 bootstrap_method_attr_index; [0] > u2 name_and_type_index; [54] > } > > For additional details, please take a look at the JIRA issue. > > Testing: jdk_jfr > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: add missing default case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21902/files - new: https://git.openjdk.org/jdk/pull/21902/files/f4749cec..ac59a84b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21902&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21902&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21902.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21902/head:pull/21902 PR: https://git.openjdk.org/jdk/pull/21902 From tprinzing at openjdk.org Tue Nov 5 16:48:14 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 5 Nov 2024 16:48:14 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v3] In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: > Adds a JFR event for socket connect operations. > > Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: improved exception names and handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21528/files - new: https://git.openjdk.org/jdk/pull/21528/files/7113bd75..a8898ffc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=01-02 Stats: 33 lines in 3 files changed: 9 ins; 8 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/21528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528 PR: https://git.openjdk.org/jdk/pull/21528 From alanb at openjdk.org Tue Nov 5 17:23:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Nov 2024 17:23:30 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v3] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Tue, 5 Nov 2024 16:48:14 GMT, Tim Prinzing wrote: >> Adds a JFR event for socket connect operations. >> >> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > improved exception names and handling Discussed with Tim as there are a number of issues that will need attention. A SocketConnectEvent should only be "offered" for connect events, not cases such as "already connected" or "socket closed". For SocketChannel there is also a socket adaptor (blockingConnect method) that will need to be updated. The non-blocking connect/finishConnect is complicated and there are several issues there. Finally, remoteAddress requires stateLock. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2457759513 From rkennke at openjdk.org Tue Nov 5 17:35:30 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Nov 2024 17:35:30 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v10] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 11:10:14 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Use Shenandoah ProblemLists Looks good to me, thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20328#pullrequestreview-2416296694 From tprinzing at openjdk.org Wed Nov 6 00:15:44 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 6 Nov 2024 00:15:44 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v4] In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: > Adds a JFR event for socket connect operations. > > Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21528/files - new: https://git.openjdk.org/jdk/pull/21528/files/a8898ffc..ce9d39e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=02-03 Stats: 76 lines in 2 files changed: 49 ins; 15 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/21528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528 PR: https://git.openjdk.org/jdk/pull/21528 From alanb at openjdk.org Wed Nov 6 08:05:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 08:05:36 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v4] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing wrote: >> Adds a JFR event for socket connect operations. >> >> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > suggested changes src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 2: > 1: /* > 2: * Copyright (c) 2016, 2023, Oracle and/or its affiliates. All rights reserved. I assume you didn't mean to change that. src/jdk.jfr/share/conf/jfr/profile.jfc line 741: > 739: true > 740: 10 ms > 741: In default.jfr the threshold for the socket events is 20ms, but 10ms in profile.jfc. Is that intentional? test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 106: > 104: > 105: try (SocketChannel sc = SocketChannel.open(ssc.getLocalAddress())) { > 106: addExpectedEvent(IOEvent.createSocketConnectEvent(sc.socket())); This is SocketChannel in blocking mode where the connect succeeds. There is also the non-blocking and where connect fails. In addition the connection can established with the socket adaptor. So 6 possible cases for SocketChannel if the test is expanded. test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 108: > 106: try (Socket s = new Socket()) { > 107: s.connect(ss.getLocalSocketAddress()); > 108: addExpectedEvent(IOEvent.createSocketConnectEvent(s)); This is Socket.connect success case, I assume we'll need a test for fail case too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830512546 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830516492 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830545551 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830537634 From alanb at openjdk.org Wed Nov 6 08:10:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 08:10:31 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v4] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing wrote: >> Adds a JFR event for socket connect operations. >> >> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > suggested changes The update in ce9d39e2 has the changes that I discussed with Tim yesterday. Specifically, it fixes several issues with the non-blocking case, only records an event if the connect method actually attempts to establish a connection, and fixes the socket adaptor. So I think this to NioSocketImpl and SocketChannelImpl are good now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2458949631 From shade at openjdk.org Wed Nov 6 15:11:34 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Nov 2024 15:11:34 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v10] In-Reply-To: References: Message-ID: <5z-PvTLk9E_v6GctWI5eFQvqmWE8JzR067d9t2F7qVA=.6c3835ef-64f8-4dfa-8708-e159a7f96c45@github.com> On Tue, 5 Nov 2024 11:10:14 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Use Shenandoah ProblemLists @mgronlun -- are you good with the current version? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2460016159 From mgronlun at openjdk.org Wed Nov 6 16:29:34 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 6 Nov 2024 16:29:34 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v10] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 11:10:14 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Use Shenandoah ProblemLists Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20328#pullrequestreview-2418848912 From mgronlun at openjdk.org Wed Nov 6 16:29:35 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 6 Nov 2024 16:29:35 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v10] In-Reply-To: References: Message-ID: <46r2aomzO7Wl6pg-RWl4Xq3YbzM5mwWPuJetSxS11DY=.0b834520-ddec-4789-9d55-639f9679ba59@github.com> On Wed, 6 Nov 2024 16:26:13 GMT, Markus Gr?nlund wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Shenandoah ProblemLists > > Marked as reviewed by mgronlun (Reviewer). > @mgronlun -- are you good with the current version? Ok. Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2460237237 From shade at openjdk.org Wed Nov 6 16:41:37 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Nov 2024 16:41:37 GMT Subject: RFR: 8279016: JFR Leak Profiler is broken with Shenandoah [v10] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 11:10:14 GMT, Aleksey Shipilev wrote: >> While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). >> >> Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. >> >> I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. >> >> This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. >> >> Additional testing: >> - [x] `jdk_jfr` pass by default >> - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Use Shenandoah ProblemLists Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20328#issuecomment-2460263678 From shade at openjdk.org Wed Nov 6 16:41:38 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Nov 2024 16:41:38 GMT Subject: Integrated: 8279016: JFR Leak Profiler is broken with Shenandoah In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 11:26:45 GMT, Aleksey Shipilev wrote: > While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)). > > Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64/src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp#L275-L280) sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. > > I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. > > This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. > > Additional testing: > - [x] `jdk_jfr` pass by default > - [x] `jdk_jfr` now passes with `-XX:+UseShenandoah` This pull request has now been integrated. Changeset: 0be7118b Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/0be7118b2f761b416ebf8cbb11473d51e80be409 Stats: 80 lines in 4 files changed: 80 ins; 0 del; 0 mod 8279016: JFR Leak Profiler is broken with Shenandoah Reviewed-by: egahlin, rkennke, mgronlun, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/20328 From tprinzing at openjdk.org Wed Nov 6 18:35:32 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 6 Nov 2024 18:35:32 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v4] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Wed, 6 Nov 2024 07:31:37 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: >> >> suggested changes > > src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 2: > >> 1: /* >> 2: * Copyright (c) 2016, 2023, Oracle and/or its affiliates. All rights reserved. > > I assume you didn't mean to change that. Not sure how that happened, but I'll fix it > test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 106: > >> 104: >> 105: try (SocketChannel sc = SocketChannel.open(ssc.getLocalAddress())) { >> 106: addExpectedEvent(IOEvent.createSocketConnectEvent(sc.socket())); > > This is SocketChannel in blocking mode where the connect succeeds. There is also the non-blocking and where connect fails. In addition the connection can established with the socket adaptor. So 6 possible cases for SocketChannel if the test is expanded. yes, testing still to be done > test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 108: > >> 106: try (Socket s = new Socket()) { >> 107: s.connect(ss.getLocalSocketAddress()); >> 108: addExpectedEvent(IOEvent.createSocketConnectEvent(s)); > > This is Socket.connect success case, I assume we'll need a test for fail case too. yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831527507 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831529879 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831529362 From dfuchs at openjdk.org Thu Nov 7 10:25:48 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 7 Nov 2024 10:25:48 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v4] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing wrote: >> Adds a JFR event for socket connect operations. >> >> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > suggested changes The code changes look reasonable to me. I had to re-read the documentation of `finishConnect` to get to that point. I mistakenly thought that this method was reserved for the fully non blocking case. I hadn't realised you could start connect() in non blocking mode and finish it in blocking mode... Thanks @AlanBateman for the thorough review of all these odd cases. ------------- PR Review: https://git.openjdk.org/jdk/pull/21528#pullrequestreview-2420545416 From shade at openjdk.org Thu Nov 7 11:08:11 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 11:08:11 GMT Subject: RFR: 8343754: Problemlist jdk/jfr/event/oldobject/TestShenandoah.java after JDK-8279016 Message-ID: See comment in [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). I overlooked the case when we just run with Shenandoah without explicitly specifying -XX:+UseShenandoahGC. The test should be disabled in that mode as well. Additional testing: - [x] Affected test is now skipped - [x] `jdk_jfr` out of the box, now passes - [x] `jdk_jfr` with `-XX:+UseShenandoahGC`, still passes ------------- Commit messages: - Also problemlist a generic test Changes: https://git.openjdk.org/jdk/pull/21947/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21947&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343754 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21947.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21947/head:pull/21947 PR: https://git.openjdk.org/jdk/pull/21947 From syan at openjdk.org Thu Nov 7 12:48:36 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 7 Nov 2024 12:48:36 GMT Subject: RFR: 8343742: Test TestShenandoah.java fails Could not find leaking object Message-ID: Hi all, Test `jdk/jfr/event/oldobject/TestShenandoah.java` run timed out after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), because of infinite loop of `Could not find leaking object, retrying...` In [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), this test has been Problemlisted by [ProblemList-shenandoah.txt ](https://github.com/openjdk/jdk/blame/master/test/jdk/ProblemList-shenandoah.txt#L52), because of the LeakProfiler tests not suitable for run with `-XX:+UseShenandoahGC` after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). But in the VM option `-XX:+UseShenandoahGC` set inside the test tag cause the Problemlist mechanism will not take effect. The problemlist only take effect when the VM option set from command line such as `make TEST JTREG="JAVA_OPTIONS=-XX:+UseShenandoahGC"`. So in this PR delete the VM option `-XX:+UseShenandoahGC` to make test run passed. The change has been verified locally, include: - [x] linux x64 release build - [x] linux x64 fastdebug build - [x] linux aarch64 release build - [x] linux aarch64 fastdebug build Test-fix only, no risk. ------------- Commit messages: - 8343742: Test TestShenandoah.java fails Could not find leaking object Changes: https://git.openjdk.org/jdk/pull/21951/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21951&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343742 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21951.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21951/head:pull/21951 PR: https://git.openjdk.org/jdk/pull/21951 From syan at openjdk.org Thu Nov 7 13:05:24 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 7 Nov 2024 13:05:24 GMT Subject: RFR: 8343742: Test TestShenandoah.java fails Could not find leaking object [v2] In-Reply-To: References: Message-ID: > Hi all, > Test `jdk/jfr/event/oldobject/TestShenandoah.java` run timed out after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), because of infinite loop of `Could not find leaking object, retrying...` > In [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), this test has been Problemlisted by [ProblemList-shenandoah.txt > ](https://github.com/openjdk/jdk/blame/master/test/jdk/ProblemList-shenandoah.txt#L52), because of the LeakProfiler tests not suitable for run with `-XX:+UseShenandoahGC` after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). > But in the VM option `-XX:+UseShenandoahGC` set inside the test tag cause the Problemlist mechanism will not take effect. The problemlist only take effect when the VM option set from command line such as `make TEST JTREG="JAVA_OPTIONS=-XX:+UseShenandoahGC"`. > So in this PR move Problemlist entry `jdk/jfr/event/oldobject/TestShenandoah.java` from `test/jdk/ProblemList-shenandoah.txt` to `test/jdk/ProblemList.txt` to make this test could by excluded normally. > The other optional solution is delete the VM option `-XX:+UseShenandoahGC` in test file to make test run passed. After [JDK-8342951](https://bugs.openjdk.org/browse/JDK-8342951) has been resolved, the change should be backouted. This PR choice the previous one solution. > > Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Move Problemlist entry jdk/jfr/event/oldobject/TestShenandoah.java from test/jdk/ProblemList-shenandoah.txt to test/jdk/ProblemList.txt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21951/files - new: https://git.openjdk.org/jdk/pull/21951/files/f54ed654..30a73e8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21951&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21951&range=00-01 Stats: 4 lines in 3 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21951.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21951/head:pull/21951 PR: https://git.openjdk.org/jdk/pull/21951 From shade at openjdk.org Thu Nov 7 13:24:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 13:24:42 GMT Subject: RFR: 8343742: Test TestShenandoah.java fails Could not find leaking object [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 13:05:24 GMT, SendaoYan wrote: >> Hi all, >> Test `jdk/jfr/event/oldobject/TestShenandoah.java` run timed out after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), because of infinite loop of `Could not find leaking object, retrying...` >> In [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), this test has been Problemlisted by [ProblemList-shenandoah.txt >> ](https://github.com/openjdk/jdk/blame/master/test/jdk/ProblemList-shenandoah.txt#L52), because of the LeakProfiler tests not suitable for run with `-XX:+UseShenandoahGC` after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). >> But in the VM option `-XX:+UseShenandoahGC` set inside the test tag cause the Problemlist mechanism will not take effect. The problemlist only take effect when the VM option set from command line such as `make TEST JTREG="JAVA_OPTIONS=-XX:+UseShenandoahGC"`. >> So in this PR move Problemlist entry `jdk/jfr/event/oldobject/TestShenandoah.java` from `test/jdk/ProblemList-shenandoah.txt` to `test/jdk/ProblemList.txt` to make this test could by excluded normally. >> The other optional solution is delete the VM option `-XX:+UseShenandoahGC` in test file to make test run passed. After [JDK-8342951](https://bugs.openjdk.org/browse/JDK-8342951) has been resolved, the change should be backouted. This PR choice the previous one solution. >> >> Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Move Problemlist entry jdk/jfr/event/oldobject/TestShenandoah.java from test/jdk/ProblemList-shenandoah.txt to test/jdk/ProblemList.txt Already here: https://github.com/openjdk/jdk/pull/21947 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21951#issuecomment-2462228896 From djelinski at openjdk.org Thu Nov 7 13:55:55 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 7 Nov 2024 13:55:55 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields Message-ID: This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. ------------- Commit messages: - Use correct accessors Changes: https://git.openjdk.org/jdk/pull/21952/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21952&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343140 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21952/head:pull/21952 PR: https://git.openjdk.org/jdk/pull/21952 From syan at openjdk.org Thu Nov 7 15:54:48 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 7 Nov 2024 15:54:48 GMT Subject: RFR: 8343742: Test TestShenandoah.java fails Could not find leaking object [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 13:05:24 GMT, SendaoYan wrote: >> Hi all, >> Test `jdk/jfr/event/oldobject/TestShenandoah.java` run timed out after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), because of infinite loop of `Could not find leaking object, retrying...` >> In [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), this test has been Problemlisted by [ProblemList-shenandoah.txt >> ](https://github.com/openjdk/jdk/blame/master/test/jdk/ProblemList-shenandoah.txt#L52), because of the LeakProfiler tests not suitable for run with `-XX:+UseShenandoahGC` after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). >> But in the VM option `-XX:+UseShenandoahGC` set inside the test tag cause the Problemlist mechanism will not take effect. The problemlist only take effect when the VM option set from command line such as `make TEST JTREG="JAVA_OPTIONS=-XX:+UseShenandoahGC"`. >> So in this PR move Problemlist entry `jdk/jfr/event/oldobject/TestShenandoah.java` from `test/jdk/ProblemList-shenandoah.txt` to `test/jdk/ProblemList.txt` to make this test could by excluded normally. >> The other optional solution is delete the VM option `-XX:+UseShenandoahGC` in test file to make test run passed. After [JDK-8342951](https://bugs.openjdk.org/browse/JDK-8342951) has been resolved, the change should be backouted. This PR choice the previous one solution. >> >> Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Move Problemlist entry jdk/jfr/event/oldobject/TestShenandoah.java from test/jdk/ProblemList-shenandoah.txt to test/jdk/ProblemList.txt > Already here: #21947 Close as duplicated ------------- PR Comment: https://git.openjdk.org/jdk/pull/21951#issuecomment-2462586477 From syan at openjdk.org Thu Nov 7 15:54:49 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 7 Nov 2024 15:54:49 GMT Subject: Withdrawn: 8343742: Test TestShenandoah.java fails Could not find leaking object In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 12:40:15 GMT, SendaoYan wrote: > Hi all, > Test `jdk/jfr/event/oldobject/TestShenandoah.java` run timed out after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), because of infinite loop of `Could not find leaking object, retrying...` > In [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016), this test has been Problemlisted by [ProblemList-shenandoah.txt > ](https://github.com/openjdk/jdk/blame/master/test/jdk/ProblemList-shenandoah.txt#L52), because of the LeakProfiler tests not suitable for run with `-XX:+UseShenandoahGC` after [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). > But in the VM option `-XX:+UseShenandoahGC` set inside the test tag cause the Problemlist mechanism will not take effect. The problemlist only take effect when the VM option set from command line such as `make TEST JTREG="JAVA_OPTIONS=-XX:+UseShenandoahGC"`. > So in this PR move Problemlist entry `jdk/jfr/event/oldobject/TestShenandoah.java` from `test/jdk/ProblemList-shenandoah.txt` to `test/jdk/ProblemList.txt` to make this test could by excluded normally. > The other optional solution is delete the VM option `-XX:+UseShenandoahGC` in test file to make test run passed. After [JDK-8342951](https://bugs.openjdk.org/browse/JDK-8342951) has been resolved, the change should be backouted. This PR choice the previous one solution. > > Test-fix only, no risk. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21951 From shade at openjdk.org Thu Nov 7 17:20:43 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 17:20:43 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 12:57:20 GMT, Daniel Jeli?ski wrote: > This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. > > The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. > > No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. Ouch, good find. src/hotspot/share/jfr/jni/jfrJavaSupport.cpp line 347: > 345: case T_SHORT: > 346: Unimplemented(); > 347: break; Why not implement these, while we are at it? ------------- PR Review: https://git.openjdk.org/jdk/pull/21952#pullrequestreview-2421678492 PR Review Comment: https://git.openjdk.org/jdk/pull/21952#discussion_r1833081878 From egahlin at openjdk.org Thu Nov 7 18:41:47 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 7 Nov 2024 18:41:47 GMT Subject: RFR: 8343754: Problemlist jdk/jfr/event/oldobject/TestShenandoah.java after JDK-8279016 In-Reply-To: References: Message-ID: <__Sx5FICVCdgyg5UCoEQHubhAuCiZcPb5PhL0jHB2qA=.f2d00a98-1223-4e36-86c5-24df8c2a693c@github.com> On Thu, 7 Nov 2024 10:46:06 GMT, Aleksey Shipilev wrote: > See comment in [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). I overlooked the case when we just run with Shenandoah without explicitly specifying -XX:+UseShenandoahGC. The test should be disabled in that mode as well. > > Additional testing: > - [x] Affected test is now skipped > - [x] `jdk_jfr` out of the box, now passes > - [x] `jdk_jfr` with `-XX:+UseShenandoahGC`, still passes Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21947#pullrequestreview-2421844510 From shade at openjdk.org Thu Nov 7 18:46:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 18:46:42 GMT Subject: RFR: 8343754: Problemlist jdk/jfr/event/oldobject/TestShenandoah.java after JDK-8279016 In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 10:46:06 GMT, Aleksey Shipilev wrote: > See comment in [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). I overlooked the case when we just run with Shenandoah without explicitly specifying -XX:+UseShenandoahGC. The test should be disabled in that mode as well. > > Additional testing: > - [x] Affected test is now skipped > - [x] `jdk_jfr` out of the box, now passes > - [x] `jdk_jfr` with `-XX:+UseShenandoahGC`, still passes Trivial, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21947#issuecomment-2462973236 From djelinski at openjdk.org Thu Nov 7 21:15:45 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 7 Nov 2024 21:15:45 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:17:34 GMT, Aleksey Shipilev wrote: >> This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. >> >> The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. >> >> No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. > > src/hotspot/share/jfr/jni/jfrJavaSupport.cpp line 347: > >> 345: case T_SHORT: >> 346: Unimplemented(); >> 347: break; > > Why not implement these, while we are at it? because it's more work, and we probably "Ain't Gonna Need It". The method is 6 years old, and is only used in one place. That being said, if you think these types might be useful in a predictable future, I can implement them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21952#discussion_r1833377658 From shade at openjdk.org Fri Nov 8 10:08:09 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Nov 2024 10:08:09 GMT Subject: Integrated: 8343754: Problemlist jdk/jfr/event/oldobject/TestShenandoah.java after JDK-8279016 In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 10:46:06 GMT, Aleksey Shipilev wrote: > See comment in [JDK-8279016](https://bugs.openjdk.org/browse/JDK-8279016). I overlooked the case when we just run with Shenandoah without explicitly specifying -XX:+UseShenandoahGC. The test should be disabled in that mode as well. > > Additional testing: > - [x] Affected test is now skipped > - [x] `jdk_jfr` out of the box, now passes > - [x] `jdk_jfr` with `-XX:+UseShenandoahGC`, still passes This pull request has now been integrated. Changeset: 0c281acf Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/0c281acfb4c87436096cb562d70f800dffa3671a Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8343754: Problemlist jdk/jfr/event/oldobject/TestShenandoah.java after JDK-8279016 Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/21947 From shade at openjdk.org Fri Nov 8 10:08:45 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Nov 2024 10:08:45 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 21:13:32 GMT, Daniel Jeli?ski wrote: >> src/hotspot/share/jfr/jni/jfrJavaSupport.cpp line 347: >> >>> 345: case T_SHORT: >>> 346: Unimplemented(); >>> 347: break; >> >> Why not implement these, while we are at it? > > because it's more work, and we probably "Ain't Gonna Need It". The method is 6 years old, and is only used in one place. > That being said, if you think these types might be useful in a predictable future, I can implement them. Let's implement them. As it stands in current mainline, these methods are "implemented", albeit incorrectly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21952#discussion_r1834065900 From nbenalla at openjdk.org Fri Nov 8 15:40:36 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 8 Nov 2024 15:40:36 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording Message-ID: Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. Notes: - I have also added an `@since` tag that was missing. - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) TIA ------------- Commit messages: - remove backticks - 8343780 Changes: https://git.openjdk.org/jdk/pull/21982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343780 Stats: 16 lines in 6 files changed: 1 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/21982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21982/head:pull/21982 PR: https://git.openjdk.org/jdk/pull/21982 From egahlin at openjdk.org Mon Nov 11 14:10:06 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 11 Nov 2024 14:10:06 GMT Subject: RFR: 8342105: JVM Crash when Jacoco and JFR are active [v2] In-Reply-To: <07VxBHNpUVgYUAo5mGSRaEtngurJPFYzIk0cCkjq3BQ=.2b072e3b-06c9-40fb-9134-69dfa498a54b@github.com> References: <07VxBHNpUVgYUAo5mGSRaEtngurJPFYzIk0cCkjq3BQ=.2b072e3b-06c9-40fb-9134-69dfa498a54b@github.com> Message-ID: On Tue, 5 Nov 2024 13:15:56 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> JFR hooking invocations of deprecated methods have a problem supporting Condy because these involve indirect invocations (via a bootstrap method) and do not have a reified bytecode invocation instruction (which gets support structures in the MDO). >> >> The bytecode for a condy invocation is ldc or fast_aload (when the bytecode is rewritten), and no MDO support structures are added for these. >> >> ConstantPool idx 0x55: ("Condy") >> >> 55 = Dynamic 0:54 // 0:$jacocoData:Ljava/lang/Object; >> >> CONSTANT_Dynamic_info { >> u1 tag; >> u2 bootstrap_method_attr_index; [0] >> u2 name_and_type_index; [54] >> } >> >> For additional details, please take a look at the JIRA issue. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > add missing default case Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21902#pullrequestreview-2427381283 From mgronlun at openjdk.org Mon Nov 11 14:41:08 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 11 Nov 2024 14:41:08 GMT Subject: Integrated: 8342105: JVM Crash when Jacoco and JFR are active In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 12:27:31 GMT, Markus Gr?nlund wrote: > Greetings, > > JFR hooking invocations of deprecated methods have a problem supporting Condy because these involve indirect invocations (via a bootstrap method) and do not have a reified bytecode invocation instruction (which gets support structures in the MDO). > > The bytecode for a condy invocation is ldc or fast_aload (when the bytecode is rewritten), and no MDO support structures are added for these. > > ConstantPool idx 0x55: ("Condy") > > 55 = Dynamic 0:54 // 0:$jacocoData:Ljava/lang/Object; > > CONSTANT_Dynamic_info { > u1 tag; > u2 bootstrap_method_attr_index; [0] > u2 name_and_type_index; [54] > } > > For additional details, please take a look at the JIRA issue. > > Testing: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: 0759224e Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/0759224edc9843d77b3eb0f121d724de826b634d Stats: 26 lines in 1 file changed: 23 ins; 0 del; 3 mod 8342105: JVM Crash when Jacoco and JFR are active Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/21902 From egahlin at openjdk.org Mon Nov 11 18:46:32 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 11 Nov 2024 18:46:32 GMT Subject: RFR: 8343946: JFR: Wildcard should only work with COUNT for 'jfr view' Message-ID: <3jrx-REgT2zu-m5VxXjyIaiD7V5pGfexL9l9EfG6KcE=.8fd932ad-ba68-4525-b973-894b69381aac@github.com> Could I have a review of a PR that fixes a query validation bug for 'jfr view'? When '*' is used as a field name with an aggregator function, the implementation defaults to using the 'startTime' field, resulting in the field expression COUNT(startTime). Unfortunately, this behavior allows the aggregate function to bypass validation. This issue can be fixed by checking against the actual text rather than the field name. The lack of validation led to incorrect numbers being used for the 'Threads' column in the contention-by-address view. Testing: jdk/jdk/jfr and manual inspection. Thanks, Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/22018/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22018&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343946 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22018/head:pull/22018 PR: https://git.openjdk.org/jdk/pull/22018 From mgronlun at openjdk.org Mon Nov 11 19:11:12 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 11 Nov 2024 19:11:12 GMT Subject: RFR: 8343946: JFR: Wildcard should only work with COUNT for 'jfr view' In-Reply-To: <3jrx-REgT2zu-m5VxXjyIaiD7V5pGfexL9l9EfG6KcE=.8fd932ad-ba68-4525-b973-894b69381aac@github.com> References: <3jrx-REgT2zu-m5VxXjyIaiD7V5pGfexL9l9EfG6KcE=.8fd932ad-ba68-4525-b973-894b69381aac@github.com> Message-ID: On Mon, 11 Nov 2024 17:22:58 GMT, Erik Gahlin wrote: > Could I have a review of a PR that fixes a query validation bug for 'jfr view'? > > When '*' is used as a field name with an aggregator function, the implementation defaults to using the 'startTime' field, resulting in the field expression COUNT(startTime). Unfortunately, this behavior allows the aggregate function to bypass validation. This issue can be fixed by checking against the actual text rather than the field name. > > The lack of validation led to incorrect numbers being used for the 'Threads' column in the contention-by-address view. > > Testing: jdk/jdk/jfr and manual inspection. > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22018#pullrequestreview-2427972982 From mgronlun at openjdk.org Mon Nov 11 19:30:03 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 11 Nov 2024 19:30:03 GMT Subject: RFR: 8338565: Test crashed: assert(is_path_empty()) failed: invariant Message-ID: Greetings, This adjustment removes an assert which is unnecessarily strong. Its ok to reuse the _path_buffer, because every use is a full overwrite, i.e. a clobber. Tests: jdk_jfr Thanks Markus ------------- Commit messages: - 8338565 Changes: https://git.openjdk.org/jdk/pull/22021/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338565 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22021/head:pull/22021 PR: https://git.openjdk.org/jdk/pull/22021 From egahlin at openjdk.org Tue Nov 12 15:33:18 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 12 Nov 2024 15:33:18 GMT Subject: RFR: 8338565: Test crashed: assert(is_path_empty()) failed: invariant In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 19:24:28 GMT, Markus Gr?nlund wrote: > Greetings, > > This adjustment removes an assert which is unnecessarily strong. > > Its ok to reuse the _path_buffer, because every use is a full overwrite, i.e. a clobber. > > Tests: jdk_jfr > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22021#pullrequestreview-2429942559 From egahlin at openjdk.org Tue Nov 12 15:38:29 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 12 Nov 2024 15:38:29 GMT Subject: Integrated: 8343946: JFR: Wildcard should only work with COUNT for 'jfr view' In-Reply-To: <3jrx-REgT2zu-m5VxXjyIaiD7V5pGfexL9l9EfG6KcE=.8fd932ad-ba68-4525-b973-894b69381aac@github.com> References: <3jrx-REgT2zu-m5VxXjyIaiD7V5pGfexL9l9EfG6KcE=.8fd932ad-ba68-4525-b973-894b69381aac@github.com> Message-ID: On Mon, 11 Nov 2024 17:22:58 GMT, Erik Gahlin wrote: > Could I have a review of a PR that fixes a query validation bug for 'jfr view'? > > When '*' is used as a field name with an aggregator function, the implementation defaults to using the 'startTime' field, resulting in the field expression COUNT(startTime). Unfortunately, this behavior allows the aggregate function to bypass validation. This issue can be fixed by checking against the actual text rather than the field name. > > The lack of validation led to incorrect numbers being used for the 'Threads' column in the contention-by-address view. > > Testing: jdk/jdk/jfr and manual inspection. > > Thanks > Erik This pull request has now been integrated. Changeset: e5eaa7f1 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/e5eaa7f1eb0cb072d02bc18e23b0daaee875b077 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8343946: JFR: Wildcard should only work with COUNT for 'jfr view' Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/22018 From mgronlun at openjdk.org Tue Nov 12 15:48:37 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 12 Nov 2024 15:48:37 GMT Subject: Integrated: 8338565: Test crashed: assert(is_path_empty()) failed: invariant In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 19:24:28 GMT, Markus Gr?nlund wrote: > Greetings, > > This adjustment removes an assert which is unnecessarily strong. > > Its ok to reuse the _path_buffer, because every use is a full overwrite, i.e. a clobber. > > Tests: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: 81752c4b Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/81752c4bcc384a8dd1e87b71a0de86877a0b661d Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8338565: Test crashed: assert(is_path_empty()) failed: invariant Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/22021 From djelinski at openjdk.org Tue Nov 12 16:49:15 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Nov 2024 16:49:15 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields [v2] In-Reply-To: References: Message-ID: > This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. > > The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. > > No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Implement write accessors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21952/files - new: https://git.openjdk.org/jdk/pull/21952/files/ea1a0062..639e57d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21952&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21952&range=00-01 Stats: 23 lines in 1 file changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21952/head:pull/21952 PR: https://git.openjdk.org/jdk/pull/21952 From shade at openjdk.org Tue Nov 12 17:39:26 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 12 Nov 2024 17:39:26 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields [v2] In-Reply-To: References: Message-ID: <2BBov6hpsXa-beRNWV2LVNmtURO8HWTzTifkVQVn1s4=.ed26055c-8300-403a-b789-65cbfe81669a@github.com> On Tue, 12 Nov 2024 16:49:15 GMT, Daniel Jeli?ski wrote: >> This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. >> >> The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. >> >> No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Implement write accessors Looks good to me, thanks! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21952#pullrequestreview-2430287154 From egahlin at openjdk.org Tue Nov 12 17:55:34 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 12 Nov 2024 17:55:34 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields [v2] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 16:49:15 GMT, Daniel Jeli?ski wrote: >> This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. >> >> The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. >> >> No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Implement write accessors Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21952#pullrequestreview-2430318886 From lmesnik at openjdk.org Tue Nov 12 22:36:54 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 12 Nov 2024 22:36:54 GMT Subject: RFR: 8344071: Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC Message-ID: Tests jdk/jfr/event/oldobject/TestObjectDescription.java jdk/jfr/event/oldobject/TestClassLoaderLeak.java fail with different GCs to get expected events. They pass with G1 GC so I don't want to problemlist them. However, they should test all GCs that support these events. Removed ZGC, because I expect that is Generational and should be also supported. The flagless should be removed when the main bugs are fixed. ------------- Commit messages: - Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC Changes: https://git.openjdk.org/jdk/pull/22050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344071 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22050/head:pull/22050 PR: https://git.openjdk.org/jdk/pull/22050 From alanb at openjdk.org Wed Nov 13 10:56:47 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Nov 2024 10:56:47 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v4] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing wrote: >> Adds a JFR event for socket connect operations. >> >> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > suggested changes @tprinzing Are you planning on all the tests? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2473184324 From mgronlun at openjdk.org Wed Nov 13 12:15:38 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 12:15:38 GMT Subject: RFR: 8344080: Return type mismatch for jfr_unregister_stack_filter Message-ID: Greetings, Tiny adjustment to function declaration. Test: jdk_jfr Thanks Markus ------------- Commit messages: - 8344080 Changes: https://git.openjdk.org/jdk/pull/22068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22068&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344080 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22068/head:pull/22068 PR: https://git.openjdk.org/jdk/pull/22068 From tschatzl at openjdk.org Wed Nov 13 12:48:47 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Nov 2024 12:48:47 GMT Subject: RFR: 8344080: Return type mismatch for jfr_unregister_stack_filter In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 12:11:18 GMT, Markus Gr?nlund wrote: > Greetings, > > Tiny adjustment to function declaration. > > Test: jdk_jfr > > Thanks > Markus lgtm and trivial enough. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22068#pullrequestreview-2433002303 From djelinski at openjdk.org Wed Nov 13 13:21:40 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 13 Nov 2024 13:21:40 GMT Subject: RFR: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields [v2] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 16:49:15 GMT, Daniel Jeli?ski wrote: >> This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. >> >> The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. >> >> No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Implement write accessors Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21952#issuecomment-2473596975 From djelinski at openjdk.org Wed Nov 13 13:29:00 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 13 Nov 2024 13:29:00 GMT Subject: Integrated: 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 12:57:20 GMT, Daniel Jeli?ski wrote: > This test fixes the accessor used by `read_boolean_field` to access boolean fields of the `jdk.jfr.internal.dcmd.Argument` record. It also fixes the read accessors for `short` and `char` types, and marks the write accessors for `boolean`, `short` and `char` as unimplemented. > > The existing accessor reads the boolean field as int. This results in unaligned access, and probably reads incorrect value on big-endian CPUs. > > No new tests. I'm sure a test would be useful, but I have no idea how to write one. Existing tier1-3 tests continue to pass. This pull request has now been integrated. Changeset: b72fe755 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/b72fe75533f1115076ec083faba56318156aba2a Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod 8343140: JfrJavaSupport uses the wrong accessors for sub-int fields Reviewed-by: shade, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/21952 From kbarrett at openjdk.org Wed Nov 13 14:02:22 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 13 Nov 2024 14:02:22 GMT Subject: RFR: 8344080: Return type mismatch for jfr_unregister_stack_filter In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 12:11:18 GMT, Markus Gr?nlund wrote: > Greetings, > > Tiny adjustment to function declaration. > > Test: jdk_jfr > > Thanks > Markus Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22068#pullrequestreview-2433300973 From mgronlun at openjdk.org Wed Nov 13 14:30:53 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 14:30:53 GMT Subject: RFR: 8344080: Return type mismatch for jfr_unregister_stack_filter In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 12:44:37 GMT, Thomas Schatzl wrote: >> Greetings, >> >> Tiny adjustment to function declaration. >> >> Test: jdk_jfr >> >> Thanks >> Markus > > lgtm and trivial enough. Thanks, @tschatzl and @kimbarrett for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22068#issuecomment-2473731665 From mgronlun at openjdk.org Wed Nov 13 14:30:55 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 14:30:55 GMT Subject: Integrated: 8344080: Return type mismatch for jfr_unregister_stack_filter In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 12:11:18 GMT, Markus Gr?nlund wrote: > Greetings, > > Tiny adjustment to function declaration. > > Test: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: a08d67c2 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/a08d67c2a9d0bbc6f38c6280efd19b60303eb5e8 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8344080: Return type mismatch for jfr_unregister_stack_filter Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/22068 From jjg at openjdk.org Wed Nov 13 18:11:11 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 13 Nov 2024 18:11:11 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Without looking in detail at the changes, this is indeed a welcome and long-overdue change! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474339519 From ihse at openjdk.org Wed Nov 13 18:11:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 13 Nov 2024 18:11:11 GMT Subject: RFR: 8344056: Use markdown format for man pages Message-ID: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. ------------- Commit messages: - Replace tabs with spaces - Remove logic for copying .1 man pages - Insert GPL header - Add missing Windows man pages for kerberos and accessibility - Replace generated troff man pages with markdown version Changes: https://git.openjdk.org/jdk/pull/22081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344056 Stats: 41443 lines in 65 files changed: 18943 ins; 22500 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From kevinw at openjdk.org Wed Nov 13 20:21:08 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 13 Nov 2024 20:21:08 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. I think this means the one-true-master copy of a man page is now the public .md file. All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes. (Which is great, I just didn't see it being explicitly said.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474701337 From cstein at openjdk.org Wed Nov 13 20:56:51 2024 From: cstein at openjdk.org (Christian Stein) Date: Wed, 13 Nov 2024 20:56:51 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. So glad to see progress here! https://github.com/openjdk/jdk/blob/1484153c1a092cefc20270b35aa1e508280843a4/test/langtools/jdk/javadoc/tool/CheckManPageOptions.java#L141 should read `return findRootDir().resolve("src/jdk.javadoc/share/man/javadoc.md");` now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474760888 From jjg at openjdk.org Wed Nov 13 21:21:32 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 13 Nov 2024 21:21:32 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 20:17:24 GMT, Kevin Walls wrote: > I think this means the one-true-master copy of a man page is now the public .md file. All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes. (Which is great, I just didn't see it being explicitly said.) Yes, related: Non-trivial updates to these pages should be approved in a CSR, maybe along with any code changes that may make such an update necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474804913 From dholmes at openjdk.org Wed Nov 13 21:35:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 13 Nov 2024 21:35:39 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Great to finally see this happen! Just one glitch with the GPL headers. Thanks src/java.base/share/man/java.md line 9: > 7: # published by the Free Software Foundation. Oracle designates this > 8: # particular file as subject to the "Classpath" exception as provided > 9: # by Oracle in the LICENSE file that accompanied this code. Documentation files should not have the Classpath exception. make/data/license-templates/gpl-header ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434474132 PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841189067 From cstein at openjdk.org Wed Nov 13 21:35:40 2024 From: cstein at openjdk.org (Christian Stein) Date: Wed, 13 Nov 2024 21:35:40 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. A missing `.1` to `.md` file extension change in `javadoc`'s manpage self-test `CheckManPageOptions.java` is causing the CI to fail. Details in https://github.com/openjdk/jdk/pull/22081#issuecomment-2474760888 ------------- Changes requested by cstein (Committer). PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434491865 From iris at openjdk.org Wed Nov 13 21:59:34 2024 From: iris at openjdk.org (Iris Clark) Date: Wed, 13 Nov 2024 21:59:34 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 21:27:02 GMT, David Holmes wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > src/java.base/share/man/java.md line 9: > >> 7: # published by the Free Software Foundation. Oracle designates this >> 8: # particular file as subject to the "Classpath" exception as provided >> 9: # by Oracle in the LICENSE file that accompanied this code. > > Documentation files should not have the Classpath exception. > > make/data/license-templates/gpl-header Agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841231909 From nbenalla at openjdk.org Thu Nov 14 01:28:15 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 14 Nov 2024 01:28:15 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v2] In-Reply-To: References: Message-ID: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > Notes: > - I have also added an `@since` tag that was missing. > - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) > > TIA Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag Revert "remove backticks" This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21982/files - new: https://git.openjdk.org/jdk/pull/21982/files/83afb011..c1615b31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=00-01 Stats: 6 lines in 5 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21982/head:pull/21982 PR: https://git.openjdk.org/jdk/pull/21982 From dfuchs at openjdk.org Thu Nov 14 09:05:42 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 14 Nov 2024 09:05:42 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. The jwebserver.md looks OK to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2435435938 From ihse at openjdk.org Thu Nov 14 11:11:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 11:11:54 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Fix CheckManPageOptions test - Remove classpath exception ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22081/files - new: https://git.openjdk.org/jdk/pull/22081/files/ffb41ba0..a8d4ea50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00-01 Stats: 106 lines in 36 files changed: 0 ins; 70 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From ihse at openjdk.org Thu Nov 14 11:12:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 11:12:52 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 21:55:53 GMT, Iris Clark wrote: >> src/java.base/share/man/java.md line 9: >> >>> 7: # published by the Free Software Foundation. Oracle designates this >>> 8: # particular file as subject to the "Classpath" exception as provided >>> 9: # by Oracle in the LICENSE file that accompanied this code. >> >> Documentation files should not have the Classpath exception. >> >> make/data/license-templates/gpl-header > > Agree. Yeah, sorry for that, and thanks for catching it. I just copied the header from a build file, since it was conveniently already formatted with the leading `#`. I just assumed that this was the pure GPL and did not check close enough to verify. But it turns out that most of the build system files actually have the classpath exception, which makes no sense. I've filed https://bugs.openjdk.org/browse/JDK-8344191 to deal with that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1842039722 From ihse at openjdk.org Thu Nov 14 12:28:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 12:28:23 GMT Subject: RFR: 8344191: Build code should not have classpath exception Message-ID: In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) ------------- Commit messages: - Update build tools, data and IDE support - Update makefiles, autoconf, shell scripts, properties files and configuration files Changes: https://git.openjdk.org/jdk/pull/22104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344191 Stats: 2054 lines in 555 files changed: 0 ins; 1118 del; 936 mod Patch: https://git.openjdk.org/jdk/pull/22104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104 PR: https://git.openjdk.org/jdk/pull/22104 From cstein at openjdk.org Thu Nov 14 12:31:46 2024 From: cstein at openjdk.org (Christian Stein) Date: Thu, 14 Nov 2024 12:31:46 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). A candidate for an ignore list as fixing it is out of scope of this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476233883 From ihse at openjdk.org Thu Nov 14 12:44:45 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 12:44:45 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 12:29:38 GMT, Christian Stein wrote: > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). *sigh* > A candidate for an ignore list as fixing it is out of scope of this PR? Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476258243 From duke at openjdk.org Thu Nov 14 13:34:44 2024 From: duke at openjdk.org (Abdelhak Zaaim) Date: Thu, 14 Nov 2024 13:34:44 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: <_LlSFeUxsE5NIZ1tl6Fx_PV0NiHyVfwlkYD-91GkfOQ=.a5f09f9e-6116-4f3b-8860-c1e21474e213@github.com> On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie wrote: > In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. > > I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. > > The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. > > This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/22104#pullrequestreview-2436096366 From jjg at openjdk.org Thu Nov 14 15:26:22 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 14 Nov 2024 15:26:22 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie wrote: > In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. > > I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. > > The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. > > This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2476698524 From stefank at openjdk.org Thu Nov 14 17:45:20 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 14 Nov 2024 17:45:20 GMT Subject: RFR: 8344071: Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 22:31:18 GMT, Leonid Mesnik wrote: > Tests > jdk/jfr/event/oldobject/TestObjectDescription.java > jdk/jfr/event/oldobject/TestClassLoaderLeak.java > fail with different GCs to get expected events. > > They pass with G1 GC so I don't want to problemlist them. > However, they should test all GCs that support these events. > > Removed ZGC, because I expect that is Generational and should be also supported. > > The flagless should be removed when the main bugs are fixed. Marked as reviewed by stefank (Reviewer). test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 44: > 42: * @key jfr > 43: * @requires vm.hasJFR > 44: * @requires vm.gc != "Z" & vm.gc != "Shenandoah" Why did you remove the exclusion of ZGC here and left Shenandoah? Isn't it better to leave the ZGC exclusion here? ------------- PR Review: https://git.openjdk.org/jdk/pull/22050#pullrequestreview-2436797285 PR Review Comment: https://git.openjdk.org/jdk/pull/22050#discussion_r1842648376 From lmesnik at openjdk.org Thu Nov 14 18:01:39 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 14 Nov 2024 18:01:39 GMT Subject: RFR: 8344071: Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 17:41:38 GMT, Stefan Karlsson wrote: >> Tests >> jdk/jfr/event/oldobject/TestObjectDescription.java >> jdk/jfr/event/oldobject/TestClassLoaderLeak.java >> fail with different GCs to get expected events. >> >> They pass with G1 GC so I don't want to problemlist them. >> However, they should test all GCs that support these events. >> >> Removed ZGC, because I expect that is Generational and should be also supported. >> >> The flagless should be removed when the main bugs are fixed. > > test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 44: > >> 42: * @key jfr >> 43: * @requires vm.hasJFR >> 44: * @requires vm.gc != "Z" & vm.gc != "Shenandoah" > > Why did you remove the exclusion of ZGC here and left Shenandoah? Isn't it better to leave the ZGC exclusion here? The ZGC is now generational, and the OldObjectSampler should work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22050#discussion_r1842668288 From lmesnik at openjdk.org Thu Nov 14 18:01:40 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 14 Nov 2024 18:01:40 GMT Subject: Integrated: 8344071: Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC In-Reply-To: References: Message-ID: <54iVQAo5_bgl4XSMUMPnsYKQteW4b0iZM3sevl6hvfY=.1e5008e6-883f-462a-a45a-0505b36ae45f@github.com> On Tue, 12 Nov 2024 22:31:18 GMT, Leonid Mesnik wrote: > Tests > jdk/jfr/event/oldobject/TestObjectDescription.java > jdk/jfr/event/oldobject/TestClassLoaderLeak.java > fail with different GCs to get expected events. > > They pass with G1 GC so I don't want to problemlist them. > However, they should test all GCs that support these events. > > Removed ZGC, because I expect that is Generational and should be also supported. > > The flagless should be removed when the main bugs are fixed. This pull request has now been integrated. Changeset: 2cbce1f0 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/2cbce1f0f19a308ce792b530bde0438bfe55531f Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod 8344071: Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC Reviewed-by: stefank ------------- PR: https://git.openjdk.org/jdk/pull/22050 From iris at openjdk.org Thu Nov 14 18:43:38 2024 From: iris at openjdk.org (Iris Clark) Date: Thu, 14 Nov 2024 18:43:38 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception Thanks for updating all the licenses to GPL. ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2436927254 From mgronlun at openjdk.org Thu Nov 14 19:07:07 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Nov 2024 19:07:07 GMT Subject: RFR: 8344161: Argument type mismatch for jfr_type_id Message-ID: Greetings, More signature adjustments. Thanks Markus ------------- Commit messages: - 8344161 Changes: https://git.openjdk.org/jdk/pull/22115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344161 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22115/head:pull/22115 PR: https://git.openjdk.org/jdk/pull/22115 From ihse at openjdk.org Fri Nov 15 00:10:24 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 00:10:24 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com> On Thu, 14 Nov 2024 15:23:35 GMT, Jonathan Gibbons wrote: > The policy has long been to use Classpath Exception in the src and make directories, but not in the test directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down. I did not know there was such a policy. My understanding is that the classpath exception only makes sense for java files that are distributed as part of the JDK. That `test` was excluded from classpath should therefore be a logical consequence that it is not distributed. And `src` is not generally using CPE; for instance, Hotspot does not have CPE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2477665315 From dholmes at openjdk.org Fri Nov 15 01:25:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 01:25:30 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception LGTM! ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2437489438 From kbarrett at openjdk.org Fri Nov 15 01:29:07 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 15 Nov 2024 01:29:07 GMT Subject: RFR: 8344161: Argument type mismatch for jfr_type_id In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 19:02:15 GMT, Markus Gr?nlund wrote: > Greetings, > > More signature adjustments. > > Thanks > Markus Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22115#pullrequestreview-2437491402 From dholmes at openjdk.org Fri Nov 15 01:29:49 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 01:29:49 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com> On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception > > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). > > _sigh_ > > > A candidate for an ignore list as fixing it is out of scope of this PR? > > Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix. I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2477764902 From stefank at openjdk.org Fri Nov 15 08:04:12 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 15 Nov 2024 08:04:12 GMT Subject: RFR: 8344071: Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 17:58:07 GMT, Leonid Mesnik wrote: >> test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 44: >> >>> 42: * @key jfr >>> 43: * @requires vm.hasJFR >>> 44: * @requires vm.gc != "Z" & vm.gc != "Shenandoah" >> >> Why did you remove the exclusion of ZGC here and left Shenandoah? Isn't it better to leave the ZGC exclusion here? > > The ZGC is now generational, and the OldObjectSampler should work. I don't know what the generational part has to do with it. The Old part in the name doesn't refer the young and old generation, just that an object is lingering in the system, which it also did for single gen ZGC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22050#discussion_r1843329273 From mgronlun at openjdk.org Fri Nov 15 13:41:57 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Nov 2024 13:41:57 GMT Subject: Integrated: 8344161: Argument type mismatch for jfr_type_id In-Reply-To: References: Message-ID: <0y--8o1MCaufg3JU6UNnXTfHzOeoaX1mRovI4DPsfcw=.fbd3c922-663a-4f14-9d99-dcab0aaf7c82@github.com> On Thu, 14 Nov 2024 19:02:15 GMT, Markus Gr?nlund wrote: > Greetings, > > More signature adjustments. > > Thanks > Markus This pull request has now been integrated. Changeset: a672138a Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/a672138aa7cb61c4f905de365628c0bbed6901ac Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8344161: Argument type mismatch for jfr_type_id Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/22115 From ihse at openjdk.org Fri Nov 15 14:46:33 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:46:33 GMT Subject: RFR: 8344056: Use markdown format for man pages [v3] In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix regexes in CheckManPageOptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22081/files - new: https://git.openjdk.org/jdk/pull/22081/files/a8d4ea50..dbef493e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=01-02 Stats: 12 lines in 1 file changed: 3 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From ihse at openjdk.org Fri Nov 15 14:46:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:46:34 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception The CheckManPageOptions test had regexps that were not up to date with the latest changes in the markdown file. I fixed those and now the test passes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479038178 From ihse at openjdk.org Fri Nov 15 14:46:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:46:34 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com> Message-ID: On Fri, 15 Nov 2024 01:25:43 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix CheckManPageOptions test >> - Remove classpath exception > >> > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). >> >> _sigh_ >> >> > A candidate for an ignore list as fixing it is out of scope of this PR? >> >> Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix. > > I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image. @dholmes-ora > I was expecting it to examine the .1 files in the JDK image. It's been like that since the test was created in https://bugs.openjdk.org/browse/JDK-8274211, so there is no change in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479042569 From ihse at openjdk.org Fri Nov 15 14:50:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:50:21 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: It's somewhat nicer to use \\s instead of space character in regex ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22081/files - new: https://git.openjdk.org/jdk/pull/22081/files/dbef493e..7cba61b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From cstein at openjdk.org Fri Nov 15 15:04:51 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 15 Nov 2024 15:04:51 GMT Subject: RFR: 8344056: Use markdown format for man pages [v3] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:46:33 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix regexes in CheckManPageOptions test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277: > 275: > 276: // In the defining areas, option names are represented as follows: > 277: // `OPTION` or `OPTION` `OPTION` or `OPTION` ... where's the difference? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843959156 From ihse at openjdk.org Fri Nov 15 15:11:46 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 15:11:46 GMT Subject: RFR: 8344056: Use markdown format for man pages [v3] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: <_OybV6gt9rVOlg2n8GG48jDzgFsqLQ6GLi4R5TvZWTI=.b1f68ebb-dcd5-4fe1-b001-21628221d218@github.com> On Fri, 15 Nov 2024 15:00:39 GMT, Christian Stein wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix regexes in CheckManPageOptions > > test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277: > >> 275: >> 276: // In the defining areas, option names are represented as follows: >> 277: // `OPTION` or `OPTION` > > `OPTION` or `OPTION` ... where's the difference? Some options have multiple variants displayed on a single row, like: `--classpath` or `-cp` This was handled in the troff format but not updated for markdown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843969778 From cstein at openjdk.org Fri Nov 15 16:04:19 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 15 Nov 2024 16:04:19 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > It's somewhat nicer to use \\s instead of space character in regex Marked as reviewed by cstein (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2439039366 From lmesnik at openjdk.org Sat Nov 16 02:53:54 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 16 Nov 2024 02:53:54 GMT Subject: RFR: 8344071: Mark some jdk/jfr/event/oldobject test flagless until they fixed to support all GC In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 07:59:40 GMT, Stefan Karlsson wrote: >> The ZGC is now generational, and the OldObjectSampler should work. > > I don't know what the generational part has to do with it. The Old part in the name doesn't refer the young and old generation, just that an object is lingering in the system, which it also did for single gen ZGC. Thanks, I copied your comments to the bug. It might be needed to run specific tests for Parallel/Serial GC like for ZGC so this will be just G1 only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22050#discussion_r1844887747 From dholmes at openjdk.org Sat Nov 16 12:24:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Sat, 16 Nov 2024 12:24:42 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com> References: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com> Message-ID: On Fri, 15 Nov 2024 00:07:07 GMT, Magnus Ihse Bursie wrote: > The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down. What policy is that? The Classpath exception is for executing classfiles. It is meaningless in any other context. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2480542305 From syan at openjdk.org Sun Nov 17 01:57:50 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 17 Nov 2024 01:57:50 GMT Subject: RFR: 8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless In-Reply-To: References: Message-ID: On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik wrote: > Test jdk/jfr/startupargs/TestStartDuration.java > checks duration, the time might be too small for stress options like Xcomp. > So it makes sense to mark it as flaglesss. Marked as reviewed by syan (Committer). We observed the same failure by [dragonwell17](https://github.com/dragonwell-project/dragonwell17/issues/171) ------------- PR Review: https://git.openjdk.org/jdk/pull/21237#pullrequestreview-2440836022 PR Comment: https://git.openjdk.org/jdk/pull/21237#issuecomment-2480886977 From syan at openjdk.org Sun Nov 17 02:27:37 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 17 Nov 2024 02:27:37 GMT Subject: RFR: 8344199: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved Message-ID: Hi all, The test `jdk/jfr/jvm/TestVirtualThreadExclusion.java` fails after [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383), before [JDK-8344199](https://bugs.openjdk.org/browse/JDK-8344199) been resolved, should we problemlist this test to make less CI noisy. ------------- Commit messages: - 8344199: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved Changes: https://git.openjdk.org/jdk/pull/22178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344199 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22178/head:pull/22178 PR: https://git.openjdk.org/jdk/pull/22178 From lmesnik at openjdk.org Sun Nov 17 03:09:43 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 17 Nov 2024 03:09:43 GMT Subject: RFR: 8344199: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 02:03:49 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/jvm/TestVirtualThreadExclusion.java` fails after [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383), before [JDK-8344199](https://bugs.openjdk.org/browse/JDK-8344199) been resolved, should we problemlist this test to make less CI noisy. Looks good and trivial. Please update bugid to JDK-8344349 ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22178#pullrequestreview-2440841722 Changes requested by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22178#pullrequestreview-2440841871 From syan at openjdk.org Sun Nov 17 03:24:46 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 17 Nov 2024 03:24:46 GMT Subject: RFR: 8344349: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 02:03:49 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/jvm/TestVirtualThreadExclusion.java` fails after [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383), before [JDK-8344199](https://bugs.openjdk.org/browse/JDK-8344199) been resolved, should we problemlist this test to make less CI noisy. Oops, the bugid has been up updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22178#issuecomment-2480908143 From lmesnik at openjdk.org Sun Nov 17 04:01:51 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 17 Nov 2024 04:01:51 GMT Subject: RFR: 8344349: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved In-Reply-To: References: Message-ID: <-D1WCwKpNM76updO-3AuZrQEBa9WuYf7Hn-X16WTP_Y=.4fe37fb8-fa05-45e7-ba88-a8a2f30e4902@github.com> On Sun, 17 Nov 2024 02:03:49 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/jvm/TestVirtualThreadExclusion.java` fails after [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383), before [JDK-8344199](https://bugs.openjdk.org/browse/JDK-8344199) been resolved, should we problemlist this test to make less CI noisy. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22178#pullrequestreview-2440845881 From syan at openjdk.org Sun Nov 17 14:48:42 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 17 Nov 2024 14:48:42 GMT Subject: RFR: 8344349: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 02:03:49 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/jvm/TestVirtualThreadExclusion.java` fails after [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383), before [JDK-8344199](https://bugs.openjdk.org/browse/JDK-8344199) been resolved, should we problemlist this test to make less CI noisy. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22178#issuecomment-2481302341 From iris at openjdk.org Mon Nov 18 01:35:07 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 18 Nov 2024 01:35:07 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > It's somewhat nicer to use \\s instead of space character in regex Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2441317522 From syan at openjdk.org Mon Nov 18 02:37:54 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 18 Nov 2024 02:37:54 GMT Subject: Integrated: 8344349: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 02:03:49 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/jvm/TestVirtualThreadExclusion.java` fails after [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383), before [JDK-8344199](https://bugs.openjdk.org/browse/JDK-8344199) been resolved, should we problemlist this test to make less CI noisy. This pull request has now been integrated. Changeset: a47d9ba9 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/a47d9ba98a1498425970613415ecb830f805a3be Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8344349: Problemlist jdk/jfr/jvm/TestVirtualThreadExclusion.java before JDK-8344199 resolved Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/22178 From ihse at openjdk.org Mon Nov 18 09:29:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 09:29:52 GMT Subject: Integrated: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: <_LM2L_tT9Q4OZvoeWztNyLUkzQcLPQIE_En639Pu_lA=.31310c87-64b4-4b97-bb0c-f044e312e9ef@github.com> On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. This pull request has now been integrated. Changeset: 475feb06 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/475feb064bb6b9dfd34fc52762e3e0ab825254ec Stats: 41386 lines in 66 files changed: 18876 ins; 22500 del; 10 mod 8344056: Use markdown format for man pages Reviewed-by: cstein, iris, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/22081 From jsjolen at openjdk.org Mon Nov 18 11:50:19 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Nov 2024 11:50:19 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 Message-ID: # Background With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. # The fix I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. ------------- Commit messages: - Add MemoryFileTracker support to NMTUsage Changes: https://git.openjdk.org/jdk/pull/22204/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343893 Stats: 40 lines in 5 files changed: 31 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22204/head:pull/22204 PR: https://git.openjdk.org/jdk/pull/22204 From jsjolen at openjdk.org Mon Nov 18 12:28:29 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Nov 2024 12:28:29 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v2] In-Reply-To: References: Message-ID: > # Background > > With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. > > # The fix > > I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Add include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22204/files - new: https://git.openjdk.org/jdk/pull/22204/files/7164f615..76f8bff4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22204/head:pull/22204 PR: https://git.openjdk.org/jdk/pull/22204 From jsjolen at openjdk.org Mon Nov 18 12:42:14 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Nov 2024 12:42:14 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v3] In-Reply-To: References: Message-ID: > # Background > > With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. > > # The fix > > I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Un-problemlist the test - Merge remote-tracking branch 'openjdk/master' into mft-jfr - Add include - Add MemoryFileTracker support to NMTUsage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22204/files - new: https://git.openjdk.org/jdk/pull/22204/files/76f8bff4..fcf5db52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=01-02 Stats: 171879 lines in 3514 files changed: 59750 ins; 100147 del; 11982 mod Patch: https://git.openjdk.org/jdk/pull/22204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22204/head:pull/22204 PR: https://git.openjdk.org/jdk/pull/22204 From mgronlun at openjdk.org Mon Nov 18 15:17:02 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Nov 2024 15:17:02 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 12:42:14 GMT, Johan Sj?len wrote: >> # Background >> >> With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. >> >> # The fix >> >> I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Un-problemlist the test > - Merge remote-tracking branch 'openjdk/master' into mft-jfr > - Add include > - Add MemoryFileTracker support to NMTUsage Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22204#pullrequestreview-2442912454 From lmesnik at openjdk.org Mon Nov 18 16:19:51 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 16:19:51 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 12:42:14 GMT, Johan Sj?len wrote: >> # Background >> >> With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. >> >> # The fix >> >> I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Un-problemlist the test > - Merge remote-tracking branch 'openjdk/master' into mft-jfr > - Add include > - Add MemoryFileTracker support to NMTUsage Changes requested by lmesnik (Reviewer). test/jdk/jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java line 47: > 45: * @modules jdk.jfr > 46: * jdk.management > 47: * @run main/othervm -XX:+UseZGC -XX:NativeMemoryTracking=summary -Xms16m -Xmx128m -XX:-UseLargePages -Xlog:gc jdk.jfr.event.runtime.TestNativeMemoryUsageEvents true It is not needed, we'll catch them anyway. But if you want to add separate run, please add it as a separate testcase and requires vm.gc.G1. So we have separate test results and can run tests with any GC. ------------- PR Review: https://git.openjdk.org/jdk/pull/22204#pullrequestreview-2443100829 PR Review Comment: https://git.openjdk.org/jdk/pull/22204#discussion_r1846881639 From jsjolen at openjdk.org Mon Nov 18 16:47:51 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Nov 2024 16:47:51 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 16:15:23 GMT, Leonid Mesnik wrote: > But if you want to add separate run, please add it as a separate testcase and requires vm.gc.G1. Sorry Leonid, could you help me out with writing this? I'm not very good at JTReg yet :). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22204#discussion_r1846925542 From lmesnik at openjdk.org Mon Nov 18 17:03:55 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 17:03:55 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v4] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 16:59:56 GMT, Johan Sj?len wrote: >> # Background >> >> With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. >> >> # The fix >> >> I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove ZGC run test Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22204#pullrequestreview-2443206355 From jsjolen at openjdk.org Mon Nov 18 17:03:57 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Nov 2024 17:03:57 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 12:42:14 GMT, Johan Sj?len wrote: >> # Background >> >> With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. >> >> # The fix >> >> I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Un-problemlist the test > - Merge remote-tracking branch 'openjdk/master' into mft-jfr > - Add include > - Add MemoryFileTracker support to NMTUsage Leonid convinced me that it's unnecessary to have the ZGC case for the test, so I removed it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22204#issuecomment-2483600906 From jsjolen at openjdk.org Mon Nov 18 17:03:54 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 18 Nov 2024 17:03:54 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v4] In-Reply-To: References: Message-ID: > # Background > > With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. > > # The fix > > I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Remove ZGC run test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22204/files - new: https://git.openjdk.org/jdk/pull/22204/files/fcf5db52..4a11a22a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22204/head:pull/22204 PR: https://git.openjdk.org/jdk/pull/22204 From eirbjo at openjdk.org Tue Nov 19 16:30:50 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 19 Nov 2024 16:30:50 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > It's somewhat nicer to use \\s instead of space character in regex Is the warning log when pandoc is not installed a bit loud? % make images Building target 'images' in configuration 'macosx-x86_64-server-release' Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Finished building target 'images' in configuration 'macosx-x86_64-server-release' ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2486187436 From gziemski at openjdk.org Tue Nov 19 16:52:57 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 19 Nov 2024 16:52:57 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v4] In-Reply-To: <4F4LrD_5Fps1mCX-B6ITv3UXzLLcJJPaSde0nZU0FkM=.471cfa79-a8c1-4c13-ae10-97b050bb8720@github.com> References: <4F4LrD_5Fps1mCX-B6ITv3UXzLLcJJPaSde0nZU0FkM=.471cfa79-a8c1-4c13-ae10-97b050bb8720@github.com> Message-ID: On Tue, 19 Nov 2024 16:41:00 GMT, Gerard Ziemski wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove ZGC run test > > src/hotspot/share/nmt/nmtUsage.cpp line 105: > >> 103: _vm_total.committed += vm->committed(); >> 104: }); >> 105: } > > I am missing something here, in memoryFileTracker.hpp you say: > > > // All memory is accounted as committed, there is no reserved memory. > // Any reserved memory is expected to exist in the VirtualMemoryTracker. > > > but here we use MFT to account for both reserved and committed? Ah, we actually do use VirtualMemory here to track the memory. Never mind! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22204#discussion_r1848714196 From gziemski at openjdk.org Tue Nov 19 16:52:56 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 19 Nov 2024 16:52:56 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v4] In-Reply-To: References: Message-ID: <4F4LrD_5Fps1mCX-B6ITv3UXzLLcJJPaSde0nZU0FkM=.471cfa79-a8c1-4c13-ae10-97b050bb8720@github.com> On Mon, 18 Nov 2024 17:03:54 GMT, Johan Sj?len wrote: >> # Background >> >> With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. >> >> # The fix >> >> I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove ZGC run test Just and observation - you used here the acronym `MFT` and it just jumped out at me, then I looked at `memoryFileTracker` and it feels inconsistent to me. Did we ever consider naming it `nativeMemoryFileTracker`? Then we would have `NMFT`, which extends `NMT` better, IMHO. Just something to keep in mind if we ever feel like cleaning up the names in `NMT` area. LGTM src/hotspot/share/nmt/nmtUsage.cpp line 105: > 103: _vm_total.committed += vm->committed(); > 104: }); > 105: } I am missing something here, in memoryFileTracker.hpp you say: // All memory is accounted as committed, there is no reserved memory. // Any reserved memory is expected to exist in the VirtualMemoryTracker. but here we use MFT to account for both reserved and committed? ------------- PR Review: https://git.openjdk.org/jdk/pull/22204#pullrequestreview-2446030052 Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22204#pullrequestreview-2446053916 PR Review Comment: https://git.openjdk.org/jdk/pull/22204#discussion_r1848701088 From nbenalla at openjdk.org Tue Nov 19 18:10:38 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 19 Nov 2024 18:10:38 GMT Subject: RFR: 8336041: Doccheck: the jfr command doesn't show the correct command-line options Message-ID: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> After [JDK-8344056](https://bugs.openjdk.org/browse/JDK-8344056), we can now easily fix these typos that caused errors when rendering the HTML. While I didn't find anything in the markdown spec mentioning escaping angle brackets, this [stackoverflow answer](https://meta.stackoverflow.com/questions/288707/how-do-you-show-words-surrounded-by-angle-brackets) says that we should use HTML entities for angle brackets. Otherwise the content inside `<>` is not shown. Doing so seems to fix the bug in the generated HTML. The output of the man pages is also broken (you can verify on your local machines as this bug exists exists in older JDKs) jfr metadata subcommand Use jfr metadata to display information about events, such as event names, categories and field layout within a flight recording file. The syntax is: jfr metadata [--categories ] [--events ] [] Before: Screenshot 2024-11-19 at 17 13 58 Screenshot 2024-11-19 at 17 13 46 Screenshot 2024-11-19 at 17 14 18 After: Screenshot 2024-11-19 at 17 25 22 Screenshot 2024-11-19 at 17 25 48 Screenshot 2024-11-19 at 18 33 29 Here is the diff in the HTML after the change --- build/macosx-aarch64/images/docs/specs/man/jfr.html 2024-11-19 17:08:08 +++ build/macosx-aarch64/images/test/docs/specs/man/jfr.html 2024-11-19 17:04:30 @@ -225,8 +225,7 @@

Use jfr configure to configure a .jfc settings file.

The syntax is:

jfr configure [--interactive] [--verbose] [--input -<files>] [--output <file>] [option=value]* -[event-setting=value]*

+] [--output ] [option=value]* [event-setting=value]*

--interactive
@@ -272,8 +271,8 @@ such as event names, categories and field layout within a flight recording file.

The syntax is:

-

jfr metadata [--categories <filter>] [--events -<filter>] [<file>]

+

jfr metadata [--categories ] [--events ] +[]

--categories <filter>
@@ -292,8 +291,8 @@ Location of the recording file (.jfr)
-

If the <file> parameter is omitted, metadata from the JDK where -the 'jfr' tool is located will be used.

+

If the parameter is omitted, metadata from the JDK where the +'jfr' tool is located will be used.

jfr summary subcommand

Use jfr summary to print statistics for a recording. For example, a summary can illustrate the number of recorded events and how Here is the diff between the two troff files 213,214c213,214 < \f[V]jfr configure\f[R] [--interactive] [--verbose] [--input ] [--output < ] [option=value]* [event-setting=value]* --- > \f[V]jfr configure\f[R] [--interactive] [--verbose] [--input ] > [--output ] [option=value]* [event-setting=value]* 255c255,256 < \f[V]jfr metadata\f[R] [--categories ] [--events ] [] --- > \f[V]jfr metadata\f[R] [--categories ] [--events ] > [] 270c271 < If the parameter is omitted, metadata from the JDK where the --- > If the parameter is omitted, metadata from the JDK where the ------------- Commit messages: - use < html entity Changes: https://git.openjdk.org/jdk/pull/22247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336041 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22247/head:pull/22247 PR: https://git.openjdk.org/jdk/pull/22247 From jsjolen at openjdk.org Wed Nov 20 08:42:19 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 20 Nov 2024 08:42:19 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v4] In-Reply-To: References: <4F4LrD_5Fps1mCX-B6ITv3UXzLLcJJPaSde0nZU0FkM=.471cfa79-a8c1-4c13-ae10-97b050bb8720@github.com> Message-ID: On Tue, 19 Nov 2024 16:48:28 GMT, Gerard Ziemski wrote: >> src/hotspot/share/nmt/nmtUsage.cpp line 105: >> >>> 103: _vm_total.committed += vm->committed(); >>> 104: }); >>> 105: } >> >> I am missing something here, in memoryFileTracker.hpp you say: >> >> >> // All memory is accounted as committed, there is no reserved memory. >> // Any reserved memory is expected to exist in the VirtualMemoryTracker. >> >> >> but here we use MFT to account for both reserved and committed? > > Ah, we actually do use VirtualMemory here to track the memory. Never mind! Yeah, but it is actually 0 :). I wanted to future proof this code, if we ever do use `reserved` here. I'll assert that `reserved` is 0 with a good message, then we can fix the code if our assumptions change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22204#discussion_r1849851012 From dholmes at openjdk.org Wed Nov 20 11:55:19 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 11:55:19 GMT Subject: RFR: 8336041: Doccheck: the jfr command doesn't show the correct command-line options In-Reply-To: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> References: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> Message-ID: On Tue, 19 Nov 2024 16:26:45 GMT, Nizar Benalla wrote: > After [JDK-8344056](https://bugs.openjdk.org/browse/JDK-8344056), we can now easily fix these typos that caused errors when rendering the HTML. > > While I didn't find anything in the markdown spec mentioning escaping angle brackets, this [stackoverflow answer](https://meta.stackoverflow.com/questions/288707/how-do-you-show-words-surrounded-by-angle-brackets) says that we should use HTML entities for angle brackets. Otherwise the content inside `<>` is not shown. Doing so seems to fix the bug in the generated HTML. > > The output of the man pages is also broken (you can verify on your local machines as this bug exists exists in older JDKs) > > > jfr metadata subcommand > Use jfr metadata to display information about events, such as event names, categories and field layout within a flight recording file. > > The syntax is: > > jfr metadata [--categories ] [--events ] [] > > > Before: > > Screenshot 2024-11-19 at 17 13 58 > > Screenshot 2024-11-19 at 17 13 46 > > Screenshot 2024-11-19 at 17 14 18 > > After: > > Screenshot 2024-11-19 at 17 25 22 > Screenshot 2024-11-19 at 17 25 48 > Screenshot 2024-11-19 at 18 33 29 > > Here is the diff in the HTML after the change > > > --- build/macosx-aarch64/images/docs/specs/man/jfr.html 2024-11-19 17:08:08 > +++ build/macosx-aarch64/images/test/docs/specs/man/jfr.html 2024-11-19 17:04:30 > @@ -225,8 +225,7 @@ >

Use jfr configure to configure a .jfc settings file.

>

The syntax is:

>

jfr configure [--interactive] [--verbose] [--input > -<files>] [--output <file>] [option=value]* > -[event-setting=value]*

> +] [--output ] [option=value]* [event-setting=value]*

>
>
--interactive
>
> @@ -272,8 +271,8 @@ > such as event names, categories and field layout within a flight > ... I would like to understand why it is necessary to do this. I cannot find any documentation to say that `<` must be escaped or replaced by HTML symbolic reference `<` in markdown sources. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22247#issuecomment-2488384558 From ihse at openjdk.org Wed Nov 20 16:24:30 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 20 Nov 2024 16:24:30 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Tue, 19 Nov 2024 16:27:54 GMT, Eirik Bj?rsn?s wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> It's somewhat nicer to use \\s instead of space character in regex > > Is the warning log when pandoc is not installed a bit loud? > > > % make images > Building target 'images' in configuration 'macosx-x86_64-server-release' > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Finished building target 'images' in configuration 'macosx-x86_64-server-release' @eirbjo Yes, that was not intentional. https://bugs.openjdk.org/browse/JDK-8344559. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2489029819 From syan at openjdk.org Thu Nov 21 02:04:17 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 21 Nov 2024 02:04:17 GMT Subject: RFR: 8342285: Mark jdk/jfr/api/event/TestIsEnabledMultiple.java as intermittent In-Reply-To: <9PmTWNTrVALhYlnl0bhItkrpBf76WRI7u9HLrWpUd4U=.b45e8d38-47dc-469a-92ef-9af4eeb7046a@github.com> References: <9PmTWNTrVALhYlnl0bhItkrpBf76WRI7u9HLrWpUd4U=.b45e8d38-47dc-469a-92ef-9af4eeb7046a@github.com> Message-ID: On Wed, 23 Oct 2024 15:44:37 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/api/event/TestIsEnabledMultiple.java` has been observed intermittent failure several times. I think we should mark this test as intermittent failure. Trivial fix, no risk. Hi, this is trivial change, can anyone take look this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21666#issuecomment-2489909626 From syan at openjdk.org Thu Nov 21 08:23:22 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 21 Nov 2024 08:23:22 GMT Subject: RFR: 8342285: Mark jdk/jfr/api/event/TestIsEnabledMultiple.java as intermittent In-Reply-To: <9PmTWNTrVALhYlnl0bhItkrpBf76WRI7u9HLrWpUd4U=.b45e8d38-47dc-469a-92ef-9af4eeb7046a@github.com> References: <9PmTWNTrVALhYlnl0bhItkrpBf76WRI7u9HLrWpUd4U=.b45e8d38-47dc-469a-92ef-9af4eeb7046a@github.com> Message-ID: <0UXUARpo5BGy3_oPEO3-gp5aj8lI0rpkkLK6wA8L9ac=.7554b01c-3e29-4a16-abd4-cf275ba18452@github.com> On Wed, 23 Oct 2024 15:44:37 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/api/event/TestIsEnabledMultiple.java` has been observed intermittent failure several times. I think we should mark this test as intermittent failure. Trivial fix, no risk. I think it's not quite strong necessary to merge this PR, sorry for the interrupt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21666#issuecomment-2490352520 From syan at openjdk.org Thu Nov 21 08:23:22 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 21 Nov 2024 08:23:22 GMT Subject: Withdrawn: 8342285: Mark jdk/jfr/api/event/TestIsEnabledMultiple.java as intermittent In-Reply-To: <9PmTWNTrVALhYlnl0bhItkrpBf76WRI7u9HLrWpUd4U=.b45e8d38-47dc-469a-92ef-9af4eeb7046a@github.com> References: <9PmTWNTrVALhYlnl0bhItkrpBf76WRI7u9HLrWpUd4U=.b45e8d38-47dc-469a-92ef-9af4eeb7046a@github.com> Message-ID: On Wed, 23 Oct 2024 15:44:37 GMT, SendaoYan wrote: > Hi all, > The test `jdk/jfr/api/event/TestIsEnabledMultiple.java` has been observed intermittent failure several times. I think we should mark this test as intermittent failure. Trivial fix, no risk. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21666 From jsjolen at openjdk.org Thu Nov 21 10:32:37 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 21 Nov 2024 10:32:37 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v5] In-Reply-To: References: Message-ID: <7PuTo9ji4sPWhgqfwHoNulvhwKh-edPg_PYcG6RdCuc=.d4b989a4-7123-4f02-80bc-f05313e87e27@github.com> > # Background > > With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. > > # The fix > > I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Do not add reserved memory. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22204/files - new: https://git.openjdk.org/jdk/pull/22204/files/4a11a22a..ef9a0511 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22204/head:pull/22204 PR: https://git.openjdk.org/jdk/pull/22204 From jsjolen at openjdk.org Thu Nov 21 10:32:37 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 21 Nov 2024 10:32:37 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v4] In-Reply-To: References: <4F4LrD_5Fps1mCX-B6ITv3UXzLLcJJPaSde0nZU0FkM=.471cfa79-a8c1-4c13-ae10-97b050bb8720@github.com> Message-ID: On Wed, 20 Nov 2024 08:39:31 GMT, Johan Sj?len wrote: >> Ah, we actually do use VirtualMemory here to track the memory. Never mind! > > Yeah, but it is actually 0 :). I wanted to future proof this code, if we ever do use `reserved` here. I'll assert that `reserved` is 0 with a good message, then we can fix the code if our assumptions change. Sorry, I was pretty confused here. We need to remove the reserved additions, otherwise we double-account reserved memory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22204#discussion_r1851785179 From gziemski at openjdk.org Thu Nov 21 15:32:16 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 21 Nov 2024 15:32:16 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v5] In-Reply-To: <7PuTo9ji4sPWhgqfwHoNulvhwKh-edPg_PYcG6RdCuc=.d4b989a4-7123-4f02-80bc-f05313e87e27@github.com> References: <7PuTo9ji4sPWhgqfwHoNulvhwKh-edPg_PYcG6RdCuc=.d4b989a4-7123-4f02-80bc-f05313e87e27@github.com> Message-ID: On Thu, 21 Nov 2024 10:32:37 GMT, Johan Sj?len wrote: >> # Background >> >> With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. >> >> # The fix >> >> I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Do not add reserved memory. That matches the comments from `src/hotspot/share/nmt/memoryFileTracker.hpp` I've seen the issue of overcounting pop-up couple of times recently - can we write a test that checks and would have caught the issue we ran into just here? ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22204#pullrequestreview-2451845562 From jsjolen at openjdk.org Fri Nov 22 08:58:21 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 22 Nov 2024 08:58:21 GMT Subject: RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 [v5] In-Reply-To: <7PuTo9ji4sPWhgqfwHoNulvhwKh-edPg_PYcG6RdCuc=.d4b989a4-7123-4f02-80bc-f05313e87e27@github.com> References: <7PuTo9ji4sPWhgqfwHoNulvhwKh-edPg_PYcG6RdCuc=.d4b989a4-7123-4f02-80bc-f05313e87e27@github.com> Message-ID: <1IOLe7jbHgKB4R4GUPZRH3KgBnGVH5QE3qHnKV3TTjA=.8405fe2a-e473-4255-89fe-deb45d479a58@github.com> On Thu, 21 Nov 2024 10:32:37 GMT, Johan Sj?len wrote: >> # Background >> >> With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. >> >> # The fix >> >> I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Do not add reserved memory. Cheers Gerard. I'm not entirely sure of how to write a test for catching this, if you have any ideas that'd be great. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22204#issuecomment-2493228546 From jsjolen at openjdk.org Fri Nov 22 08:58:22 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 22 Nov 2024 08:58:22 GMT Subject: Integrated: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 11:44:41 GMT, Johan Sj?len wrote: > # Background > > With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. > > # The fix > > I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. This pull request has now been integrated. Changeset: 2ea0364b Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/2ea0364b6e3f10977f7b607d239c29ee616a8f7c Stats: 40 lines in 5 files changed: 29 ins; 6 del; 5 mod 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 Reviewed-by: gziemski, mgronlun, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/22204 From duke at openjdk.org Fri Nov 22 13:11:25 2024 From: duke at openjdk.org (Stig =?UTF-8?B?RMO4c3Npbmc=?=) Date: Fri, 22 Nov 2024 13:11:25 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling Message-ID: The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. ------------- Commit messages: - Adjust object sampler span handling Changes: https://git.openjdk.org/jdk/pull/19334/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19334&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341427 Stats: 27 lines in 2 files changed: 21 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19334.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19334/head:pull/19334 PR: https://git.openjdk.org/jdk/pull/19334 From duke at openjdk.org Fri Nov 22 13:11:25 2024 From: duke at openjdk.org (Stig =?UTF-8?B?RMO4c3Npbmc=?=) Date: Fri, 22 Nov 2024 13:11:25 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Tue, 21 May 2024 18:37:35 GMT, Stig D?ssing wrote: > The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. > > Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. > > When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. > > When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. cc @egahlin, as per this thread https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2024-May/006264.html Master currently does not compile, so I checked that these changes can at least build when applied to the jdk-23+23 tag. Maybe you can give me a hint about which tests to run, the full tier-1 set takes a long time, and showed a few failures for me, even with no change to the code? Employer: Crowdstrike Anything I can do to speed up the OCA check? The agreement for my employer seems like it was approved a while ago, as it's listed on https://oca.opensource.oracle.com/?ojr=contrib-list. Yes, done ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2123227089 PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2383436078 PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2414676572 PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2493609410 From egahlin at openjdk.org Fri Nov 22 13:11:26 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 22 Nov 2024 13:11:26 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Tue, 21 May 2024 18:37:35 GMT, Stig D?ssing wrote: > The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. > > Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. > > When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. > > When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. I created a small program with a constant memory leak, and I observed that the samples were fewer at the end. I will try your patch and see if it fixes the issue once the OCA clears. I filed a bug to track the issue: https://bugs.openjdk.org/browse/JDK-8341427 If you change the title of the PR to "8341427: JFR: Adjust object sampler span handling" they will be connected. I tried your change and it seems to fix the problem. Could you move the PR to review state, so it will be sent out on the JFR mailing list and a webrev will be generated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2388918276 PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2492581829 From robilad at openjdk.org Fri Nov 22 13:11:26 2024 From: robilad at openjdk.org (Dalibor Topic) Date: Fri, 22 Nov 2024 13:11:26 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Tue, 21 May 2024 18:37:35 GMT, Stig D?ssing wrote: > The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. > > Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. > > When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. > > When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. I've pinged the OCA signatory at your company again to verify your account is going to be contributing on their behalf. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2442011921 From duke at openjdk.org Fri Nov 22 13:11:26 2024 From: duke at openjdk.org (Stig =?UTF-8?B?RMO4c3Npbmc=?=) Date: Fri, 22 Nov 2024 13:11:26 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 16:07:11 GMT, Dalibor Topic wrote: >> The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. >> >> Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. >> >> When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. >> >> When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. > > I've pinged the OCA signatory at your company again to verify your account is going to be contributing on their behalf. @robilad Thanks. He forwarded it to my corporate email, and I've replied to your email from that corporate address, which I hope covers this verification. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2444809787 From duke at openjdk.org Fri Nov 22 13:11:27 2024 From: duke at openjdk.org (Stig =?UTF-8?B?RMO4c3Npbmc=?=) Date: Fri, 22 Nov 2024 13:11:27 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Wed, 2 Oct 2024 15:07:55 GMT, Erik Gahlin wrote: >> The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. >> >> Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. >> >> When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. >> >> When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. > > I created a small program with a constant memory leak, and I observed that the samples were fewer at the end. I will try your patch and see if it fixes the issue once the OCA clears. > > I filed a bug to track the issue: > https://bugs.openjdk.org/browse/JDK-8341427 > > If you change the title of the PR to "8341427: JFR: Adjust object sampler span handling" they will be connected. @egahlin For when you have time to look at this again, the OCA stuff should be handled now (thanks Dalibor) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2476486720 From egahlin at openjdk.org Fri Nov 22 13:11:27 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 22 Nov 2024 13:11:27 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 12:07:54 GMT, Stig D?ssing wrote: > Yes, done I think there is a space missing in the title, try "8341427: JFR: Adjust object sampler span handling". ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2493723361 From egahlin at openjdk.org Fri Nov 22 13:22:24 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 22 Nov 2024 13:22:24 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Tue, 21 May 2024 18:37:35 GMT, Stig D?ssing wrote: > The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. > > Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. > > When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. > > When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. I can sponsor this change. ------------- Marked as reviewed by egahlin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19334#pullrequestreview-2454436865 From duke at openjdk.org Fri Nov 22 13:50:18 2024 From: duke at openjdk.org (duke) Date: Fri, 22 Nov 2024 13:50:18 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: <5rGLc9Qq44FDm5CTdu3-k381_N_pFeFtgir6gDkxaMY=.a872a095-5c2b-45f0-ac17-9ba84ace21c6@github.com> On Tue, 21 May 2024 18:37:35 GMT, Stig D?ssing wrote: > The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. > > Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. > > When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. > > When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. @srdo Your change (at version 376f04756e42cd08aaab42d9bfd2e0e3d9c2b660) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2493808927 From duke at openjdk.org Fri Nov 22 14:56:19 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Fri, 22 Nov 2024 14:56:19 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: On Tue, 21 May 2024 18:37:35 GMT, Stig D?ssing wrote: > The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. > > Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. > > When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. > > When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. Just a question, when a node is removed, why is the span pushed onto the younger neighbor? Wouldn't be better to emphasize the older neighbor since they've survived longer (and so are more likely to be a leak)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2493941166 From egahlin at openjdk.org Fri Nov 22 15:21:20 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 22 Nov 2024 15:21:20 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: <6fh6GMcgEg1AHYhVdSiVbrDoGeNPbpomqjhhyTs_3CA=.a5ca937e-9555-4ba6-bd0c-809ffc3d1319@github.com> On Fri, 22 Nov 2024 14:53:14 GMT, Robert Toyonaga wrote: > Just a question, when a node is removed, why is the span pushed onto the younger neighbor? Wouldn't be better to emphasize the older neighbor since they've survived longer (and so are more likely to be a leak)?' My thinking was that if it is removed, it's like it was never sampled. It would be as if the TLAB size were larger, and the span belongs to the next sample in time. I have a vague memory that the span at some point was split into younger and older samples, but I didn't go with that solution. Let me think about it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2493995110 From duke at openjdk.org Fri Nov 22 15:34:21 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Fri, 22 Nov 2024 15:34:21 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: <6fh6GMcgEg1AHYhVdSiVbrDoGeNPbpomqjhhyTs_3CA=.a5ca937e-9555-4ba6-bd0c-809ffc3d1319@github.com> References: <6fh6GMcgEg1AHYhVdSiVbrDoGeNPbpomqjhhyTs_3CA=.a5ca937e-9555-4ba6-bd0c-809ffc3d1319@github.com> Message-ID: On Fri, 22 Nov 2024 15:18:14 GMT, Erik Gahlin wrote: > My thinking was that if it is removed, it's like it was never sampled. It would be as if the TLAB size were larger, and the span belongs to the next sample in time Thanks for the explanation. Ok I see what you mean. It think splitting it evenly to both makes sense as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2494030422 From duke at openjdk.org Fri Nov 22 15:56:16 2024 From: duke at openjdk.org (Stig =?UTF-8?B?RMO4c3Npbmc=?=) Date: Fri, 22 Nov 2024 15:56:16 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: <6fh6GMcgEg1AHYhVdSiVbrDoGeNPbpomqjhhyTs_3CA=.a5ca937e-9555-4ba6-bd0c-809ffc3d1319@github.com> Message-ID: On Fri, 22 Nov 2024 15:31:33 GMT, Robert Toyonaga wrote: >>> Just a question, when a node is removed, why is the span pushed onto the younger neighbor? Wouldn't be better to emphasize the older neighbor since they've survived longer (and so are more likely to be a leak)?' >> >> My thinking was that if it is removed, it's like it was never sampled. It would be as if the TLAB size were larger, and the span belongs to the next sample in time. I have a vague memory that the span at some point was split into younger and older samples, but I didn't go with that solution. >> >> Let me think about it. > >> My thinking was that if it is removed, it's like it was never sampled. It would be as if the TLAB size were larger, and the span belongs to the next sample in time > > Thanks for the explanation. Ok I see what you mean. It think splitting it evenly to both makes sense as well. @roberttoyonaga Background thread describing how I understand this algorithm to be intended to work https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2024-May/006255.html The goal is to get samples evenly spread over the entire allocation timeline. My understanding is that we want samples to account for the span "to their left" on the allocation timeline. A fresh sample will cover the span between itself and the previous sample. By giving the span of a removed sample to the younger neighbor, we get the spans adjusted as if we never had the removed sample. That's not the case if we give the span to the older neighbor or split the span between the two neighbors. A small example: Sample 1 (span 0...10) Sample 2 (span 10...20) Sample 3 (span 20...30) If we add another sample at byte 40 on the timeline and drop sample 2, I think we'd like to get this: Sample 1 (0...10) Sample 3 (10...30) Sample 4 (30...40) The spans of the samples are accurately representing which span of "time" on the allocation timeline the sample represents. In this case we'd be very likely to want to keep sample 3 because it covers a large span. If we split the span instead, we'd get Sample 1 (0...15) Sample 3 (15...30) Sample 4 (30...40) Sample 1 now claims to represent 0...15 on the timeline, even though the sample was actually created before the end of that interval. I think the effect this could have is to allow older samples an advantage in being kept, which might skew which samples we keep toward older samples, which causes the distribution of samples over the timeline to be uneven. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2494079382 From tprinzing at openjdk.org Fri Nov 22 20:32:50 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Fri, 22 Nov 2024 20:32:50 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: > Adds a JFR event for socket connect operations. > > Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: Added more tests for socket connect events. - SocketAdapter connect - SocketAdapter connect with exception - Socket connect with exception - SocketChannel connect with exception - SocketChannel non-blocking connect - SocketChannel non-blocking connect with exception ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21528/files - new: https://git.openjdk.org/jdk/pull/21528/files/ce9d39e2..13f81570 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=03-04 Stats: 177 lines in 5 files changed: 162 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/21528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528 PR: https://git.openjdk.org/jdk/pull/21528 From alanb at openjdk.org Sat Nov 23 10:03:43 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 23 Nov 2024 10:03:43 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> Message-ID: <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> On Fri, 22 Nov 2024 20:32:50 GMT, Tim Prinzing wrote: >> Adds a JFR event for socket connect operations. >> >> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > Added more tests for socket connect events. > > - SocketAdapter connect > - SocketAdapter connect with exception > - Socket connect with exception > - SocketChannel connect with exception > - SocketChannel non-blocking connect > - SocketChannel non-blocking connect with exception Thanks for the update, it's good to have tests for the 8 possible cases that might record a SocketConnect event. If you have the energy for it, we could also add tests to check that a SocketConnect is not recorded for cases where the connect method fails for other reasons, e.g. already connected, Socket closed, ... but only if you want. src/java.base/share/classes/jdk/internal/event/SocketConnectEvent.java line 37: > 35: * {@code jdk.jfr.events.SocketConnectEvent } where the metadata for the event is > 36: * provided with annotations. Some of the methods are replaced by generated > 37: * methods when jfr is enabled. Note that the order of the arguments of the In passing, there is a mix of "JFR" and "jfr" through-out, I assume you want "JFR" everywhere. src/java.base/share/classes/jdk/internal/event/SocketConnectEvent.java line 51: > 49: > 50: /** > 51: * Actually commit an event. The implementation is generated automatically. I assume "Actually" should be removed, this method commits an event. src/jdk.jfr/share/classes/jdk/jfr/events/SocketConnectEvent.java line 38: > 36: @Label("Socket Connect") > 37: @Category("Java Application") > 38: @Description("Connecting a socket") I wonder if we can improve on this description. The event is recorded when a connection is established or cannot be established so it's more like "Socket Connection". test/jdk/jdk/jfr/event/io/IOHelper.java line 135: > 133: } > 134: > 135: public static void checkConnectionEventException(RecordedEvent event, IOException ioe) { I assume this should checkConnectEventException. test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 157: > 155: while (! sc.finishConnect()) { > 156: Thread.sleep(1); > 157: } The connect method returns true if the connection is established, you should only need to poll finishConnect if the connection is not established immediately. Using a sleep is okay here (although 1ms is very low) and I'm guessing you've done this to avoid using a Selector. test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 216: > 214: } catch (IOException ioe) { > 215: // we expect this > 216: connectException = ioe; I think you'll need to adjust the try-catch to only set connectException if the connect or finishConnect methods fails. If the open or configureBlocking fails then connectException should not be set, instead the test should fail. ------------- PR Review: https://git.openjdk.org/jdk/pull/21528#pullrequestreview-2456365810 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855145320 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855145369 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855145935 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855146240 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855150781 PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855151098 From duke at openjdk.org Sat Nov 23 16:01:24 2024 From: duke at openjdk.org (Stig =?UTF-8?B?RMO4c3Npbmc=?=) Date: Sat, 23 Nov 2024 16:01:24 GMT Subject: Integrated: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: Message-ID: <_iTVSwze5-cyfNhaZggjU-QUWaWdv9LMRvnyi1LiTeE=.acd75f8a-4681-40ca-be32-f3423a5c6436@github.com> On Tue, 21 May 2024 18:37:35 GMT, Stig D?ssing wrote: > The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. > > Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. > > When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. > > When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. This pull request has now been integrated. Changeset: 822a1554 Author: Stig Rohde D?ssing Committer: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/822a1554cb059580ab76bae7963827146b8f5aee Stats: 27 lines in 2 files changed: 21 ins; 4 del; 2 mod 8341427: JFR: Adjust object sampler span handling Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/19334 From egahlin at openjdk.org Sun Nov 24 23:20:15 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Sun, 24 Nov 2024 23:20:15 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> Message-ID: On Sat, 23 Nov 2024 08:02:42 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: >> >> Added more tests for socket connect events. >> >> - SocketAdapter connect >> - SocketAdapter connect with exception >> - Socket connect with exception >> - SocketChannel connect with exception >> - SocketChannel non-blocking connect >> - SocketChannel non-blocking connect with exception > > src/jdk.jfr/share/classes/jdk/jfr/events/SocketConnectEvent.java line 38: > >> 36: @Label("Socket Connect") >> 37: @Category("Java Application") >> 38: @Description("Connecting a socket") > > I wonder if we can improve on this description. The event is recorded when a connection is established or cannot be established so it's more like "Socket Connection". As I understand it, the event succeeds if exceptionMessage is null. Perhaps this should be made more explicit with a failed field. Alternatively, there could be two events: one for success and one for failure. What is the typical duration of a failed event? If it is above 10-20 ms, two events might not be as useful since all failures will be recorded anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855573527 From egahlin at openjdk.org Sun Nov 24 23:57:21 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Sun, 24 Nov 2024 23:57:21 GMT Subject: RFR: 8341427: JFR: Adjust object sampler span handling In-Reply-To: References: <6fh6GMcgEg1AHYhVdSiVbrDoGeNPbpomqjhhyTs_3CA=.a5ca937e-9555-4ba6-bd0c-809ffc3d1319@github.com> Message-ID: <4XS7e2sxKaxzsg4OAYfincp84tJ3R9Mb8ewt_nJtC3U=.7bc454cb-ccc2-486e-9fae-a01ddb861a6b@github.com> On Fri, 22 Nov 2024 15:53:14 GMT, Stig D?ssing wrote: >>> My thinking was that if it is removed, it's like it was never sampled. It would be as if the TLAB size were larger, and the span belongs to the next sample in time >> >> Thanks for the explanation. Ok I see what you mean. It think splitting it evenly to both makes sense as well. > > @roberttoyonaga > > Background thread describing how I understand this algorithm to be intended to work https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2024-May/006255.html > > The goal is to get samples evenly spread over the entire allocation timeline. My understanding is that we want samples to account for the span "to their left" on the allocation timeline. A fresh sample will cover the span between itself and the previous sample. > > By giving the span of a removed sample to the younger neighbor, we get the spans adjusted as if we never had the removed sample. > > That's not the case if we give the span to the older neighbor or split the span between the two neighbors. > > A small example: > > Sample 1 (span 0...10) > Sample 2 (span 10...20) > Sample 3 (span 20...30) > > If we add another sample at byte 40 on the timeline and drop sample 2, I think we'd like to get this: > > Sample 1 (0...10) > Sample 3 (10...30) > Sample 4 (30...40) > > The spans of the samples are accurately representing which span of "time" on the allocation timeline the sample represents. In this case we'd be very likely to want to keep sample 3 because it covers a large span. > > If we split the span instead, we'd get > > Sample 1 (0...15) > Sample 3 (15...30) > Sample 4 (30...40) > > Sample 1 now claims to represent 0...15 on the timeline, even though the sample was actually created before the end of that interval. I think the effect this could have is to allow older samples an advantage in being kept, which might skew which samples we keep toward older samples, which causes the distribution of samples over the timeline to be uneven. > > Edit: > What I'm getting at is that if the goal is to keep evenly distributed samples over the allocation timeline, then sample 3 should be preferred over sample 1 when future samples arrive, and if we split the span, it won't be. > > When more samples arrive, I think it is better to keep a sample taken at byte 30 (sample 3) than to keep a sample taken at byte 10 (sample 1), if we're going for an even distribution of the samples. @srdo Thanks for you contribution! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19334#issuecomment-2496406805 From alanb at openjdk.org Mon Nov 25 07:57:22 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 25 Nov 2024 07:57:22 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> Message-ID: <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> On Sun, 24 Nov 2024 23:15:02 GMT, Erik Gahlin wrote: > Perhaps this should be made more explicit with a failed field. Alternatively, there could be two events: one for success and one for failure. What is the typical duration of a failed event? If it is above 10-20 ms, two events might not be as useful since all failures will be recorded anyway. If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856011185 From egahlin at openjdk.org Mon Nov 25 11:02:19 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 25 Nov 2024 11:02:19 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> Message-ID: On Mon, 25 Nov 2024 07:54:34 GMT, Alan Bateman wrote: > If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded. If it's immediate, a potential Socket Connection Failure event could overflow the buffers and we can't have it with threshold = 0s. Otherwise, it might be interesting to have something like: `$ jfr view socket-connection-failures recording.jfr` to see a complete list of failures per host/port and then have: `$ jfr view slow-socket-connections recording.jfr` to find which ones are slow, i.e. more than 10-20 ms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856393748 From alanb at openjdk.org Mon Nov 25 12:03:16 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 25 Nov 2024 12:03:16 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> Message-ID: On Mon, 25 Nov 2024 10:59:35 GMT, Erik Gahlin wrote: >>> Perhaps this should be made more explicit with a failed field. Alternatively, there could be two events: one for success and one for failure. What is the typical duration of a failed event? If it is above 10-20 ms, two events might not be as useful since all failures will be recorded anyway. >> >> If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded. > >> If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded. > > If it's immediate, a potential Socket Connection Failure event could overflow the buffers and we can't have it with threshold = 0s. Otherwise, it might be interesting to have something like: > > `$ jfr view socket-connection-failures recording.jfr` > > to see a complete list of failures per host/port and then have: > > `$ jfr view slow-socket-connections recording.jfr` > > to find which ones are slow, i.e. more than 10-20 ms. Having a view for connect failures that doesn't require exceptions=all could be useful. Does this mean two events, one an instant event for the failures, the other a duration event for the connections that are slow to establish? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856496052 From egahlin at openjdk.org Mon Nov 25 13:26:23 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 25 Nov 2024 13:26:23 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> Message-ID: <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com> On Mon, 25 Nov 2024 12:00:52 GMT, Alan Bateman wrote: >>> If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded. >> >> If it's immediate, a potential Socket Connection Failure event could overflow the buffers and we can't have it with threshold = 0s. Otherwise, it might be interesting to have something like: >> >> `$ jfr view socket-connection-failures recording.jfr` >> >> to see a complete list of failures per host/port and then have: >> >> `$ jfr view slow-socket-connections recording.jfr` >> >> to find which ones are slow, i.e. more than 10-20 ms. > > Having a view for connect failures that doesn't require exceptions=all could be useful. Does this mean two events, one an instant event for the failures, the other a duration event for the connections that are slow to establish? A connection failure introduces a latency in the application, so probably best to have such an event durational as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856610190 From nbenalla at openjdk.org Tue Nov 26 16:01:40 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 26 Nov 2024 16:01:40 GMT Subject: RFR: 8336041: Doccheck: the jfr command doesn't show the correct command-line options In-Reply-To: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> References: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> Message-ID: On Tue, 19 Nov 2024 16:26:45 GMT, Nizar Benalla wrote: > After [JDK-8344056](https://bugs.openjdk.org/browse/JDK-8344056), we can now easily fix these typos that caused errors when rendering the HTML. > > While I didn't find anything in the markdown spec mentioning escaping angle brackets, this [stackoverflow answer](https://meta.stackoverflow.com/questions/288707/how-do-you-show-words-surrounded-by-angle-brackets) says that we should use HTML entities for angle brackets. Otherwise the content inside `<>` is not shown. Doing so seems to fix the bug in the generated HTML. > > The output of the man pages is also broken (you can verify on your local machines as this bug exists exists in older JDKs) > > > jfr metadata subcommand > Use jfr metadata to display information about events, such as event names, categories and field layout within a flight recording file. > > The syntax is: > > jfr metadata [--categories ] [--events ] [] > > > Before: > > Screenshot 2024-11-19 at 17 13 58 > > Screenshot 2024-11-19 at 17 13 46 > > Screenshot 2024-11-19 at 17 14 18 > > After: > > Screenshot 2024-11-19 at 17 25 22 > Screenshot 2024-11-19 at 17 25 48 > Screenshot 2024-11-19 at 18 33 29 > > Here is the diff in the HTML after the change > > > --- build/macosx-aarch64/images/docs/specs/man/jfr.html 2024-11-19 17:08:08 > +++ build/macosx-aarch64/images/test/docs/specs/man/jfr.html 2024-11-19 17:04:30 > @@ -225,8 +225,7 @@ >

Use jfr configure to configure a .jfc settings file.

>

The syntax is:

>

jfr configure [--interactive] [--verbose] [--input > -<files>] [--output <file>] [option=value]* > -[event-setting=value]*

> +] [--output ] [option=value]* [event-setting=value]*

>
>
--interactive
>
> @@ -272,8 +271,8 @@ > such as event names, categories and field layout within a flight > ... It seems that the left angle bracket character is used to denote the start of HTML tags, if you want to use the literal `<` character, you need to escape it as an entity and use `<` https://daringfireball.net/projects/markdown/syntax#autoescape FWIW typing `Hello .` in a github comment render as `Hello.` Screenshot 2024-11-26 at 16 57 21 Screenshot 2024-11-26 at 16 57 42 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22247#issuecomment-2501242677 From dholmes at openjdk.org Fri Nov 29 00:55:48 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Nov 2024 00:55:48 GMT Subject: RFR: 8336041: Doccheck: the jfr command doesn't show the correct command-line options In-Reply-To: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> References: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> Message-ID: On Tue, 19 Nov 2024 16:26:45 GMT, Nizar Benalla wrote: > After [JDK-8344056](https://bugs.openjdk.org/browse/JDK-8344056), we can now easily fix these typos that caused errors when rendering the HTML. > > While I didn't find anything in the markdown spec mentioning escaping angle brackets, this [stackoverflow answer](https://meta.stackoverflow.com/questions/288707/how-do-you-show-words-surrounded-by-angle-brackets) says that we should use HTML entities for angle brackets. Otherwise the content inside `<>` is not shown. Doing so seems to fix the bug in the generated HTML. > > The output of the man pages is also broken (you can verify on your local machines as this bug exists exists in older JDKs) > > > jfr metadata subcommand > Use jfr metadata to display information about events, such as event names, categories and field layout within a flight recording file. > > The syntax is: > > jfr metadata [--categories ] [--events ] [] > > > Before: > > Screenshot 2024-11-19 at 17 13 58 > > Screenshot 2024-11-19 at 17 13 46 > > Screenshot 2024-11-19 at 17 14 18 > > After: > > Screenshot 2024-11-19 at 17 25 22 > Screenshot 2024-11-19 at 17 25 48 > Screenshot 2024-11-19 at 18 33 29 > > Here is the diff in the HTML after the change > > > --- build/macosx-aarch64/images/docs/specs/man/jfr.html 2024-11-19 17:08:08 > +++ build/macosx-aarch64/images/test/docs/specs/man/jfr.html 2024-11-19 17:04:30 > @@ -225,8 +225,7 @@ >

Use jfr configure to configure a .jfc settings file.

>

The syntax is:

>

jfr configure [--interactive] [--verbose] [--input > -<files>] [--output <file>] [option=value]* > -[event-setting=value]*

> +] [--output ] [option=value]* [event-setting=value]*

>
>
--interactive
>
> @@ -272,8 +271,8 @@ > such as event names, categories and field layout within a flight > ... Thanks for that info @nizarbenalla . It does make me wonder however whether perhaps we should be using code blocks for these syntax fragments so that they do get auto-escaped? But that can be a future enhancement. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22247#pullrequestreview-2468911458 From cstein at openjdk.org Fri Nov 29 11:04:39 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 29 Nov 2024 11:04:39 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 01:28:15 GMT, Nizar Benalla wrote: >> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. >> >> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. >> >> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. >> >> Notes: >> - I have also added an `@since` tag that was missing. >> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag > > Revert "remove backticks" > > This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217. Two nits: - Copyright notice in `Recording.java` needs a 2024 - A missing line in a test file test/jdk/tools/sincechecker/modules/jdk.jlink/JdkJlinkCheckSince.java line 29: > 27: * @summary Test for `@since` in jdk.jlink module > 28: * @library /test/lib /test/jdk/tools/sincechecker > 29: * @run main SinceChecker jdk.jlink Missing "last" line? Suggestion: * @run main SinceChecker jdk.jlink */ ------------- Changes requested by cstein (Committer). PR Review: https://git.openjdk.org/jdk/pull/21982#pullrequestreview-2469661625 PR Review Comment: https://git.openjdk.org/jdk/pull/21982#discussion_r1863349800 From nbenalla at openjdk.org Fri Nov 29 11:11:39 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 29 Nov 2024 11:11:39 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v2] In-Reply-To: References: Message-ID: <2yGr9-6Mbe6jkcyVLT5fLPJl4JbIhMYFzbYdpXBysmc=.0c6af900-4ae6-4462-8a8c-c30ae2c74de7@github.com> On Fri, 29 Nov 2024 11:00:15 GMT, Christian Stein wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag >> >> Revert "remove backticks" >> >> This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217. > > test/jdk/tools/sincechecker/modules/jdk.jlink/JdkJlinkCheckSince.java line 29: > >> 27: * @summary Test for `@since` in jdk.jlink module >> 28: * @library /test/lib /test/jdk/tools/sincechecker >> 29: * @run main SinceChecker jdk.jlink > > Missing "last" line? > Suggestion: > > * @run main SinceChecker jdk.jlink > */ You're right. Will update, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21982#discussion_r1863360287 From nbenalla at openjdk.org Fri Nov 29 12:20:02 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 29 Nov 2024 12:20:02 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v3] In-Reply-To: References: Message-ID: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > Notes: > - I have also added an `@since` tag that was missing. > - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) > > TIA Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - add missing line in jtreg comment - Merge remote-tracking branch 'upstream/master' into add-since-test-tools - Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag Revert "remove backticks" This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217. - remove backticks - 8343780 add jtreg tests and add a missing @since ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21982/files - new: https://git.openjdk.org/jdk/pull/21982/files/c1615b31..83800e26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=01-02 Stats: 237279 lines in 4642 files changed: 89602 ins; 128967 del; 18710 mod Patch: https://git.openjdk.org/jdk/pull/21982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21982/head:pull/21982 PR: https://git.openjdk.org/jdk/pull/21982 From cstein at openjdk.org Fri Nov 29 12:20:02 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 29 Nov 2024 12:20:02 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v3] In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 12:16:54 GMT, Nizar Benalla wrote: >> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. >> >> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. >> >> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. >> >> Notes: >> - I have also added an `@since` tag that was missing. >> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) >> >> TIA > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - add missing line in jtreg comment > - Merge remote-tracking branch 'upstream/master' into add-since-test-tools > - Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag > > Revert "remove backticks" > > This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217. > - remove backticks > - 8343780 > add jtreg tests and add a missing @since Looks good to me. ------------- Marked as reviewed by cstein (Committer). PR Review: https://git.openjdk.org/jdk/pull/21982#pullrequestreview-2469790976 From nbenalla at openjdk.org Fri Nov 29 12:20:03 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 29 Nov 2024 12:20:03 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v2] In-Reply-To: <2yGr9-6Mbe6jkcyVLT5fLPJl4JbIhMYFzbYdpXBysmc=.0c6af900-4ae6-4462-8a8c-c30ae2c74de7@github.com> References: <2yGr9-6Mbe6jkcyVLT5fLPJl4JbIhMYFzbYdpXBysmc=.0c6af900-4ae6-4462-8a8c-c30ae2c74de7@github.com> Message-ID: On Fri, 29 Nov 2024 11:08:57 GMT, Nizar Benalla wrote: >> test/jdk/tools/sincechecker/modules/jdk.jlink/JdkJlinkCheckSince.java line 29: >> >>> 27: * @summary Test for `@since` in jdk.jlink module >>> 28: * @library /test/lib /test/jdk/tools/sincechecker >>> 29: * @run main SinceChecker jdk.jlink >> >> Missing "last" line? >> Suggestion: >> >> * @run main SinceChecker jdk.jlink >> */ > > You're right. Will update, thanks. The copyright year was fixed after a merge. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21982#discussion_r1863433475 From egahlin at openjdk.org Fri Nov 29 12:58:42 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 29 Nov 2024 12:58:42 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v3] In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 12:20:02 GMT, Nizar Benalla wrote: >> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. >> >> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. >> >> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. >> >> Notes: >> - I have also added an `@since` tag that was missing. >> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) >> >> TIA > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - add missing line in jtreg comment > - Merge remote-tracking branch 'upstream/master' into add-since-test-tools > - Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag > > Revert "remove backticks" > > This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217. > - remove backticks > - 8343780 > add jtreg tests and add a missing @since JFR change looks good. ------------- Marked as reviewed by egahlin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21982#pullrequestreview-2469867274 From nbenalla at openjdk.org Fri Nov 29 14:11:43 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 29 Nov 2024 14:11:43 GMT Subject: RFR: 8336041: Doccheck: the jfr command doesn't show the correct command-line options In-Reply-To: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> References: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> Message-ID: On Tue, 19 Nov 2024 16:26:45 GMT, Nizar Benalla wrote: > After [JDK-8344056](https://bugs.openjdk.org/browse/JDK-8344056), we can now easily fix these typos that caused errors when rendering the HTML. > > While I didn't find anything in the markdown spec mentioning escaping angle brackets, this [stackoverflow answer](https://meta.stackoverflow.com/questions/288707/how-do-you-show-words-surrounded-by-angle-brackets) says that we should use HTML entities for angle brackets. Otherwise the content inside `<>` is not shown. Doing so seems to fix the bug in the generated HTML. > > The output of the man pages is also broken (you can verify on your local machines as this bug exists exists in older JDKs) > > > jfr metadata subcommand > Use jfr metadata to display information about events, such as event names, categories and field layout within a flight recording file. > > The syntax is: > > jfr metadata [--categories ] [--events ] [] > > > Before: > > Screenshot 2024-11-19 at 17 13 58 > > Screenshot 2024-11-19 at 17 13 46 > > Screenshot 2024-11-19 at 17 14 18 > > After: > > Screenshot 2024-11-19 at 17 25 22 > Screenshot 2024-11-19 at 17 25 48 > Screenshot 2024-11-19 at 18 33 29 > > Here is the diff in the HTML after the change > > > --- build/macosx-aarch64/images/docs/specs/man/jfr.html 2024-11-19 17:08:08 > +++ build/macosx-aarch64/images/test/docs/specs/man/jfr.html 2024-11-19 17:04:30 > @@ -225,8 +225,7 @@ >

Use jfr configure to configure a .jfc settings file.

>

The syntax is:

>

jfr configure [--interactive] [--verbose] [--input > -<files>] [--output <file>] [option=value]* > -[event-setting=value]*

> +] [--output ] [option=value]* [event-setting=value]*

>
>
--interactive
>
> @@ -272,8 +271,8 @@ > such as event names, categories and field layout within a flight > ... Using code blocks or other tools such as a markdown viewer when updating these files could help avoid such bugs. This specific bug was detected automatically by a test (experimental, not yet in the JDK) because the generated HTML was broken, so good tests can help prevent these problems. I'll issue the `integrate` command in a few hours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22247#issuecomment-2507893211 From nbenalla at openjdk.org Fri Nov 29 18:29:40 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 29 Nov 2024 18:29:40 GMT Subject: Integrated: 8336041: Doccheck: the jfr command doesn't show the correct command-line options In-Reply-To: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> References: <4Hjl8a0Z78d2cUhY1l1ebnO59A2vGiMfUzPNs3PEEXY=.c000c7fc-5257-4289-8461-4b4c0f1e18be@github.com> Message-ID: On Tue, 19 Nov 2024 16:26:45 GMT, Nizar Benalla wrote: > After [JDK-8344056](https://bugs.openjdk.org/browse/JDK-8344056), we can now easily fix these typos that caused errors when rendering the HTML. > > While I didn't find anything in the markdown spec mentioning escaping angle brackets, this [stackoverflow answer](https://meta.stackoverflow.com/questions/288707/how-do-you-show-words-surrounded-by-angle-brackets) says that we should use HTML entities for angle brackets. Otherwise the content inside `<>` is not shown. Doing so seems to fix the bug in the generated HTML. > > The output of the man pages is also broken (you can verify on your local machines as this bug exists exists in older JDKs) > > > jfr metadata subcommand > Use jfr metadata to display information about events, such as event names, categories and field layout within a flight recording file. > > The syntax is: > > jfr metadata [--categories ] [--events ] [] > > > Before: > > Screenshot 2024-11-19 at 17 13 58 > > Screenshot 2024-11-19 at 17 13 46 > > Screenshot 2024-11-19 at 17 14 18 > > After: > > Screenshot 2024-11-19 at 17 25 22 > Screenshot 2024-11-19 at 17 25 48 > Screenshot 2024-11-19 at 18 33 29 > > Here is the diff in the HTML after the change > > > --- build/macosx-aarch64/images/docs/specs/man/jfr.html 2024-11-19 17:08:08 > +++ build/macosx-aarch64/images/test/docs/specs/man/jfr.html 2024-11-19 17:04:30 > @@ -225,8 +225,7 @@ >

Use jfr configure to configure a .jfc settings file.

>

The syntax is:

>

jfr configure [--interactive] [--verbose] [--input > -<files>] [--output <file>] [option=value]* > -[event-setting=value]*

> +] [--output ] [option=value]* [event-setting=value]*

>
>
--interactive
>
> @@ -272,8 +271,8 @@ > such as event names, categories and field layout within a flight > ... This pull request has now been integrated. Changeset: 029ace0a Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/029ace0a1b2ff4f14965037eb56414c5c6168096 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8336041: Doccheck: the jfr command doesn't show the correct command-line options Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/22247 From nbenalla at openjdk.org Fri Nov 29 18:53:52 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 29 Nov 2024 18:53:52 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v4] In-Reply-To: References: Message-ID: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > Notes: > - I have also added an `@since` tag that was missing. > - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) > > TIA Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: add a missing \@since tag to RecordingStream.onMetadata ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21982/files - new: https://git.openjdk.org/jdk/pull/21982/files/83800e26..091fb283 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21982/head:pull/21982 PR: https://git.openjdk.org/jdk/pull/21982 From nbenalla at openjdk.org Fri Nov 29 18:53:55 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 29 Nov 2024 18:53:55 GMT Subject: RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording [v3] In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 12:20:02 GMT, Nizar Benalla wrote: >> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. >> >> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. >> >> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. >> >> Notes: >> - I have also added an `@since` tag that was missing. >> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) >> >> TIA > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - add missing line in jtreg comment > - Merge remote-tracking branch 'upstream/master' into add-since-test-tools > - Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag > > Revert "remove backticks" > > This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217. > - remove backticks > - 8343780 > add jtreg tests and add a missing @since Added one last trivial change, an `@since 16` to `RecordingStream.onMetadata` which was added in [JDK-8248564](https://bugs.openjdk.org/browse/JDK-8248564). `{@inheritdoc}` is implicit and is not needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21982#issuecomment-2508340431