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 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: <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 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: #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 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:

jfr summary subcommand

`jfr summary` subcommand