From azafari at openjdk.org Sun Jun 1 06:53:58 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Sun, 1 Jun 2025 06:53:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v33] In-Reply-To: References: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> Message-ID: On Fri, 30 May 2025 17:37:47 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> visualizations added. 1st try. > > src/hotspot/share/nmt/vmatree.hpp line 249: > >> 247: }; >> 248: >> 249: enum Operation {Release, Reserve, Commit, Uncommit, Invalid}; > > Can we drop `Invalid` and simplify the code? > > ``` > enum Operation {Release, Reserve, Commit, Uncommit}; > struct RequestInfo { > position A, B; > StateType _op; > MemTag tag; > SIndex callstack; > bool use_tag_inplace; > Operation op() const { > return > _op == StateType::Reserved && !use_tag_inplace ? Operation::Reserve : > _op == StateType::Committed ? Operation::Commit : > _op == StateType::Reserved && use_tag_inplace ? Operation::Uncommit : > Operation::Release; > } > > size_t op_to_index() const { > return > _op == StateType::Reserved && !use_tag_inplace ? 1 : > _op == StateType::Committed ? 2 : > _op == StateType::Reserved && use_tag_inplace ? 3 : > 0; > } We need some invalid checking in the impl of register_mapping. How do we detect and report invalid values then? > test/hotspot/gtest/nmt/test_vmatree.cpp line 3211: > >> 3209: // 1 2 3 4 5 >> 3210: // 012345678901234567890123456789012345678901234567890 >> 3211: // rrrrrrrrrr..........rrrrrrrrrr > > What is this comment supposed to show? > > I cleaned up, some comments and created a branch https://github.com/openjdk/jdk/compare/master...gerard-ziemski:jdk:gerard-8351661 in case you want to see it. In the branch you sent the link, almost all of the new format comments are removed. Is that correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2118810649 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2118809808 From dholmes at openjdk.org Mon Jun 2 03:54:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Jun 2025 03:54:57 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: References: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> Message-ID: On Fri, 30 May 2025 09:28:56 GMT, Anton Artemov wrote: >> In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3 > > Thanks @pchilano, I agree that the refactoring I proposed is adding an extra layer. What you propose is moving the functionality to JavaThread. I think we need to come to an agreement on where it should belong to. @dholmes-ora do you have an opinion on that? @toxaart All the suspend/resume code used to live in JavaThread so we are coming full-circle. :) I don't quite recall the path that led to it being taken out of JavaThread. No objections from me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2928623550 From dholmes at openjdk.org Mon Jun 2 04:55:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Jun 2025 04:55:52 GMT Subject: RFR: 8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64 In-Reply-To: References: Message-ID: On Fri, 30 May 2025 19:57:37 GMT, Chris Plummer wrote: > Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed. > > Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes. Thanks for fixing this. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25556#pullrequestreview-2886708994 From eosterlund at openjdk.org Mon Jun 2 07:31:54 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 2 Jun 2025 07:31:54 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Fri, 30 May 2025 09:40:21 GMT, Andrew Haley wrote: > > > It would surely be better if this evil were expunged from JDK 21 as well, lest it also confuse a backporter. > > > > > > Maybe a "here be dragons" warning would suffice. > > If you add the following comment above every call to `do_oop_store()` I'll approve this patch: > > `// Clobbers: r10, r11, r3` Hmm yes that feels like a good compromise. I added the comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2929209038 From eosterlund at openjdk.org Mon Jun 2 07:48:39 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 2 Jun 2025 07:48:39 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent [v2] In-Reply-To: References: Message-ID: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Add comment about clobbered registers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25483/files - new: https://git.openjdk.org/jdk/pull/25483/files/44f7e092..c9440f68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25483&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25483&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25483/head:pull/25483 PR: https://git.openjdk.org/jdk/pull/25483 From shade at openjdk.org Mon Jun 2 08:25:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 08:25:00 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund wrote: >> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. >> >> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. >> >> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about clobbered registers Well, since we are introducing the hunks near `do_oop_store`-s, and thus extending the scope of the patch. At this point, we can just inline `do_oop_store` (and maybe `do_oop_load`?), like Andrew initially suggested. This will also match what RISC-V already did: https://github.com/openjdk/jdk/commit/c5a1543ee3e68775f09ca29fb07efd9aebfdb33e ------------- PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2887283595 From azafari at openjdk.org Mon Jun 2 08:27:36 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 2 Jun 2025 08:27:36 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker [v2] In-Reply-To: References: Message-ID: > Renamed usage of 'category' for 'MemTag' cases. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: user-facing terms remained as 'category' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25226/files - new: https://git.openjdk.org/jdk/pull/25226/files/b7666c38..05ca64d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25226&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25226&range=00-01 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25226/head:pull/25226 PR: https://git.openjdk.org/jdk/pull/25226 From azafari at openjdk.org Mon Jun 2 08:27:36 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 2 Jun 2025 08:27:36 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker In-Reply-To: References: Message-ID: On Fri, 30 May 2025 12:16:07 GMT, Johan Sj?len wrote: > Can we use `category` as the term for any user-facing things? I'm thinking output from tooling, input options, docs, etc. Thanks for this nice point. User-facing terms reverted back to category. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-2929397073 From eosterlund at openjdk.org Mon Jun 2 08:56:56 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 2 Jun 2025 08:56:56 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund wrote: >> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. >> >> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. >> >> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about clobbered registers > Well, since we are introducing the hunks near `do_oop_store`-s, and thus extending the scope of the patch. At this point, we can just inline `do_oop_store` (and maybe `do_oop_load`?), like Andrew initially suggested. This will also match what RISC-V already did: [c5a1543](https://github.com/openjdk/jdk/commit/c5a1543ee3e68775f09ca29fb07efd9aebfdb33e) RISC-V doesn't really have the backporting until JDK 8 problem. I'd really like to make that cosmetic change in the next follow-up PR instead, as previously discussed. The comments hold true all the way back to JDK 8 and don't change the logic, so I can go along with that. And I'd rather take the risk of getting some comment wrong on the way back to JDK 8, than fiddling with the guts of all this unrelated code, that has changed substantially since back then. Does that sound okay? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2929515436 From aph at openjdk.org Mon Jun 2 09:06:59 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 2 Jun 2025 09:06:59 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund wrote: >> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. >> >> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. >> >> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about clobbered registers Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2887436174 From shade at openjdk.org Mon Jun 2 09:11:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 09:11:55 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund wrote: >> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. >> >> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. >> >> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about clobbered registers For me, straight-up inlining: __ store_heap_oop(dst, val, r10, r11, r3, decorators); ...conveys the similar message as `// Clobbers: r10, r11, r3`. But I shall not quibble. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2887454204 From azafari at openjdk.org Mon Jun 2 09:15:00 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 2 Jun 2025 09:15:00 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v33] In-Reply-To: References: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> Message-ID: On Sun, 1 Jun 2025 06:49:39 GMT, Afshin Zafari wrote: >> test/hotspot/gtest/nmt/test_vmatree.cpp line 3211: >> >>> 3209: // 1 2 3 4 5 >>> 3210: // 012345678901234567890123456789012345678901234567890 >>> 3211: // rrrrrrrrrr..........rrrrrrrrrr >> >> What is this comment supposed to show? >> >> I cleaned up, some comments and created a branch https://github.com/openjdk/jdk/compare/master...gerard-ziemski:jdk:gerard-8351661 in case you want to see it. > > The comment is removed. > > In the branch you sent the link, almost all of the new format comments are removed. Is that correct? The extra grabage-like comments are all removed. They came after running a script for putting comments in the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2120528237 From duke at openjdk.org Mon Jun 2 09:24:35 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 2 Jun 2025 09:24:35 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v3] In-Reply-To: References: Message-ID: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov 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 11 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8265754 - Merge remote-tracking branch 'origin/master' into JDK-8265754 - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Refactoring to static methods. - 8265754: Fixed indentation. - 8265754: Fixed indentation - 8265754: Fixed indentation and lost newline. - 8265754: Fixed whitespaces errors. - 8265754: More work. - Merge remote-tracking branch 'origin/master' into JDK-8265754 - ... and 1 more: https://git.openjdk.org/jdk/compare/a08f1c1d...3b0fffab ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/0ee1abf2..3b0fffab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=01-02 Stats: 51935 lines in 783 files changed: 26618 ins; 15706 del; 9611 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From duke at openjdk.org Mon Jun 2 09:39:54 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 2 Jun 2025 09:39:54 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> References: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> Message-ID: <9lLuwDnA6g2x7expvCqvt8XaolPYHz5KBwdpJMEVqQ0=.7081023e-b5f7-4bc7-817b-6e46dcec2374@github.com> On Wed, 28 May 2025 18:36:05 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov 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 10 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - 8265754: Refactoring to static methods. >> - 8265754: Fixed indentation. >> - 8265754: Fixed indentation >> - 8265754: Fixed indentation and lost newline. >> - 8265754: Fixed whitespaces errors. >> - 8265754: More work. >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - 8265754: Refactoring suspend/resume in the HandshakeState away > > In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3 @pchilano Do you expect to have any performance impact of having an indirection layer? Since we found out that the suspend/resume code used to belong to JavaThread and then was moved out of there for (some) reason, I do not see a good explanation of why one should bring it back there. JavaThread class is already huge and from maintainability perspective I think it is better to have the suspend/resume API separated. At the same time it is clearly not a part of `HandshakeState`. An option might be, if I understand correctly, to do a less straightforward refactoring as suggested above, i.e. without giving `HandshakeState` lock access to `HandshakeSuspender`. I do not yet know if it is doable. Would be a compromise approach? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2929698192 From eosterlund at openjdk.org Mon Jun 2 10:11:53 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 2 Jun 2025 10:11:53 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund wrote: >> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. >> >> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. >> >> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about clobbered registers Thanks for the reviews everyone! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2929825222 From azafari at openjdk.org Mon Jun 2 10:42:34 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 2 Jun 2025 10:42:34 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v34] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: old format comments are removed. Redundant tests are removed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/14bfe06f..b68495bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=32-33 Stats: 1523 lines in 1 file changed: 94 ins; 1361 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Mon Jun 2 11:56:58 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 2 Jun 2025 11:56:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 19:44:18 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a missed change in test. > > For this case: > > > {// Check committing into a reserved region inherits the call stacks > VMATree::RegionData call_stack_test(si_1, mtTest); > VMATree::RegionData call_stack_none(si_2, mtNone); > VMATree::RegionData call_stack_nmt(si_2, mtNMT); > Tree tree; > tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree > tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region > tree.print_timeline_on(); > } > > > I know that we are passing `true` for `use_tag_inplace` here, but it just does not feel right to get this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Test (committed) > C - Test (reserved) > . - None (free/released) > > > I was expecting this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Native Memory Tracking (committed) > C - Test (reserved) > . - None (free/released) > > > I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter? @gerard-ziemski and @jdksjolen, new commit is ready for another round of reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2930318938 From eosterlund at openjdk.org Mon Jun 2 12:28:58 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 2 Jun 2025 12:28:58 GMT Subject: Integrated: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. This pull request has now been integrated. Changeset: 83b15da2 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/83b15da2eb3cb6c8937f517c9b75eaa9eeece314 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent Reviewed-by: shade, aph, fbredberg ------------- PR: https://git.openjdk.org/jdk/pull/25483 From cstein at openjdk.org Mon Jun 2 13:52:15 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 2 Jun 2025 13:52:15 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment Message-ID: Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): Use the number sign `#` in the argument file to identify comments. All characters following the `#` are ignored until the end of line. There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. ------------- Commit messages: - 8357862: Java argument file is parsed unexpectedly with trailing comment Changes: https://git.openjdk.org/jdk/pull/25589/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25589&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357862 Stats: 26 lines in 2 files changed: 23 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25589/head:pull/25589 PR: https://git.openjdk.org/jdk/pull/25589 From cstein at openjdk.org Mon Jun 2 13:52:16 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 2 Jun 2025 13:52:16 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein wrote: > Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. > > The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): > > Use the number sign `#` in the argument file to identify comments. > All characters following the `#` are ignored until the end of line. > > There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. src/java.base/share/native/libjli/args.c line 276: > 274: } > 275: pctx->cptr = nextc + 1; > 276: return token; This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121214111 From pchilanomate at openjdk.org Mon Jun 2 14:24:10 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 2 Jun 2025 14:24:10 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: > Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. > > The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Add WhiteBox back + typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25496/files - new: https://git.openjdk.org/jdk/pull/25496/files/2fc8d84c..c65e036b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25496&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25496&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25496.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25496/head:pull/25496 PR: https://git.openjdk.org/jdk/pull/25496 From pchilanomate at openjdk.org Mon Jun 2 14:24:13 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 2 Jun 2025 14:24:13 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 07:11:36 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Add WhiteBox back + typo > > test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 53: > >> 51: ClassLoader cl = ClassUnloadCommon.newClassLoader(); >> 52: Class c = cl.loadClass("test.Empty"); >> 53: // Causes class test.Emtpy to be linked, which triggers the > > Suggestion: > > // Causes class test.Empty to be linked, which triggers the Fixed. > test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 66: > >> 64: Collections.addAll(argsList, args); >> 65: Collections.addAll(argsList, "-Xmn8m"); >> 66: Collections.addAll(argsList, "-Xbootclasspath/a:."); > > Without use of `WhiteBox`, you don't need this. And this is probably what caused the class to be loaded by the boot-loader instead of the custom loader as expected. But the use of WB is needed by `ClassUnloadCommon` and these instructions are present to ensure it works - as added by JDK-8289184. Added back the use of `WhiteBox`. As to `test.Empty`, it was always loaded by the `app` classloader regardless of `-Xbootclasspath/a:.`, i.e that?s only needed for loading `WhiteBox`. The issue was the missing `test.class.path` property. Class `test.Empty` resides in directory `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/classes/0/runtime/logging/classes/test/` but the process?s current working directory?is `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/scratch/0`, so setting the custom classloader classpath as `.` meant it wasn?t able to find it. So we ended up delegating to the parent classloader (`app`) which already had the correct directories in the classpath. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2121295912 PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2121299488 From nbenalla at openjdk.org Mon Jun 2 14:46:15 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 2 Jun 2025 14:46:15 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Revert "feedback: never bump ASM version" This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=05 Stats: 1824 lines in 59 files changed: 1734 ins; 16 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From shade at openjdk.org Mon Jun 2 14:52:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 14:52:54 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation In-Reply-To: References: Message-ID: On Sat, 31 May 2025 00:30:09 GMT, Calvin Cheung wrote: > If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. > To avoid the exception, this fix is not to start the management agent when creating an AOT cache. > > Passed tiers 1 - 4 testing. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2888787180 From nbenalla at openjdk.org Mon Jun 2 14:52:55 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 2 Jun 2025 14:52:55 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b I have bumped the ASM version in [0dbdde7](https://github.com/openjdk/jdk/pull/25008/commits/0dbdde7bf6a0343acca74b284a8114c60919dd25) because various HotSpot tests use ASM fail under JDK 26 without this change. This can be rolled back later after [JDK-8356548](https://bugs.openjdk.org/browse/JDK-8356548) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931105555 From pchilanomate at openjdk.org Mon Jun 2 15:01:29 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 2 Jun 2025 15:01:29 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> Message-ID: On Thu, 29 May 2025 22:47:40 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58: >> >>> 56: output.shouldNotContain("java.lang.ClassFormatError"); >>> 57: output.shouldHaveExitValue(1); >>> 58: if (Thread.currentThread().isVirtual()) { >> >> Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual. >> >> FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works. > > Yes, the the main is executed in virtual thread and also it runs all forked processes with wrapper that run main in virtual thread. > The another, might be more clear solution would to check it with > `static final boolean vthreadMode = "Virtual".equals(System.getProperty("test.thread.factory"));` > > or even make library method for this in the future. Yes, this check looks a bit better. How about checking that on the child's VM args directly to avoid assumptions between parent/child? `boolean vthreadMode = pb.command().toString().contains("test.thread.factory=Virtual");` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2121415781 From nbenalla at openjdk.org Mon Jun 2 15:05:54 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 2 Jun 2025 15:05:54 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: <-CUDiWjPLN2ywVxx5RQWUpmsjgkPLb0AmtnLi3MACP4=.d2aebd91-1220-4a2a-acf2-fb3dc953d908@github.com> On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b There were no API changes in JDK 25 build 25. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931159736 From gziemski at openjdk.org Mon Jun 2 15:07:00 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 2 Jun 2025 15:07:00 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v34] In-Reply-To: References: Message-ID: <8sr5gvYZaYz_EbxnE_vWOxD-PIrKwfCU6e37BNY18tI=.d7d64ab7-f13d-483e-ad0b-6ea4c6c66852@github.com> On Mon, 2 Jun 2025 10:42:34 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > old format comments are removed. Redundant tests are removed. src/hotspot/share/nmt/vmatree.cpp line 116: > 114: const int op_index = req.op_to_index(); > 115: const Operation op = req.op(); > 116: assert(op != Operation::Invalid && op_index >= 0 && op_index < 4, "should be"); RE: "op_index >= 0 && op_index < 4" Can we use the class constants here, instead of hardcoding to int values? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2121439751 From gziemski at openjdk.org Mon Jun 2 15:07:01 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 2 Jun 2025 15:07:01 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v33] In-Reply-To: References: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> Message-ID: On Sun, 1 Jun 2025 06:51:22 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/vmatree.hpp line 249: >> >>> 247: }; >>> 248: >>> 249: enum Operation {Release, Reserve, Commit, Uncommit, Invalid}; >> >> Can we drop `Invalid` and simplify the code? >> >> ``` >> enum Operation {Release, Reserve, Commit, Uncommit}; >> struct RequestInfo { >> position A, B; >> StateType _op; >> MemTag tag; >> SIndex callstack; >> bool use_tag_inplace; >> Operation op() const { >> return >> _op == StateType::Reserved && !use_tag_inplace ? Operation::Reserve : >> _op == StateType::Committed ? Operation::Commit : >> _op == StateType::Reserved && use_tag_inplace ? Operation::Uncommit : >> Operation::Release; >> } >> >> size_t op_to_index() const { >> return >> _op == StateType::Reserved && !use_tag_inplace ? 1 : >> _op == StateType::Committed ? 2 : >> _op == StateType::Reserved && use_tag_inplace ? 3 : >> 0; >> } > > We need some invalid checking in the impl of register_mapping. How do we detect and report invalid values then? There is no way an `Operation` can be set `Invalid`, unless we start with a default value, and in this case, instead of `Invalid` we can (should?) be using `Release`, which really does represent the default value. This is the opposite of my other argument about nmtNone, where I think we could use another value to tell apart default never-set from don't care :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2121434114 From matsaave at openjdk.org Mon Jun 2 15:11:29 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 2 Jun 2025 15:11:29 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless Message-ID: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. ------------- Commit messages: - Disabled ZGC on all subtests - 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless Changes: https://git.openjdk.org/jdk/pull/25591/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25591&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345347 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25591/head:pull/25591 PR: https://git.openjdk.org/jdk/pull/25591 From vromero at openjdk.org Mon Jun 2 15:12:53 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 2 Jun 2025 15:12:53 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment In-Reply-To: References: Message-ID: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com> On Mon, 2 Jun 2025 13:48:23 GMT, Christian Stein wrote: >> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. >> >> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): >> >> Use the number sign `#` in the argument file to identify comments. >> All characters following the `#` are ignored until the end of line. >> >> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. > > src/java.base/share/native/libjli/args.c line 276: > >> 274: } >> 275: pctx->cptr = nextc + 1; >> 276: return token; > > This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted? right I agree that if there is common code we should extract it in a helper method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121454132 From stefank at openjdk.org Mon Jun 2 15:27:51 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 2 Jun 2025 15:27:51 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: <4MH6Hg4tHenfGii_PwxPKbCzWR4d8rntWkho97jxmn0=.7aef9234-f457-479e-b65e-3bc5bda08284@github.com> On Mon, 2 Jun 2025 14:39:55 GMT, Matias Saavedra Silva wrote: > Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. We already have this property that is used for some tests: @requires vm.cds.write.archived.java.heap Should this be used here instead of explicitly excluding ZGC? This property boils down to: // If an incompatible VM options is found, return a text message that explains why static const char* check_options_incompatible_with_dumping_heap() { #if INCLUDE_CDS_JAVA_HEAP if (!UseCompressedClassPointers) { return "UseCompressedClassPointers must be true"; } // Almost all GCs support heap region dump, except ZGC (so far). if (UseZGC) { return "ZGC is not supported"; } return nullptr; #else return "JVM not configured for writing Java heap objects"; #endif } ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2888935605 From vromero at openjdk.org Mon Jun 2 15:37:52 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 2 Jun 2025 15:37:52 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein wrote: > Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. > > The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): > > Use the number sign `#` in the argument file to identify comments. > All characters following the `#` are ignored until the end of line. > > There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. the fact that not including a space between the comment and the previous element created havoc seems to indicate that the scanner is pretty fragile and could break again in the future. We should probably file a follow up to make this code more reliable ------------- PR Comment: https://git.openjdk.org/jdk/pull/25589#issuecomment-2931287541 From cstein at openjdk.org Mon Jun 2 15:43:50 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 2 Jun 2025 15:43:50 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 15:35:34 GMT, Vicente Romero wrote: > the fact that not including a space between the comment and the previous element created havoc seems to indicate that the scanner is pretty fragile and could break again in the future. We should probably file a follow up to make this code more reliable Yes, seems reasonable. My initial solution was to try to make use of the shared [CommandLine](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java) class, but the parsing of the launcher is too early in the game. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25589#issuecomment-2931306833 From rkennke at openjdk.org Mon Jun 2 15:49:02 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 2 Jun 2025 15:49:02 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) Message-ID: Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. ------------- Commit messages: - 8355319: Update Manpage for Compact Object Headers (Production) Changes: https://git.openjdk.org/jdk/pull/25491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355319 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25491/head:pull/25491 PR: https://git.openjdk.org/jdk/pull/25491 From rkennke at openjdk.org Mon Jun 2 15:49:02 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 2 Jun 2025 15:49:02 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke wrote: > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. @coleenp should this be sent to any mailing list? The Skara bot has not assigned it to any list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2931194656 From pchilanomate at openjdk.org Mon Jun 2 15:58:58 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 2 Jun 2025 15:58:58 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> References: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> Message-ID: On Wed, 28 May 2025 18:36:05 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov 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 10 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - 8265754: Refactoring to static methods. >> - 8265754: Fixed indentation. >> - 8265754: Fixed indentation >> - 8265754: Fixed indentation and lost newline. >> - 8265754: Fixed whitespaces errors. >> - 8265754: More work. >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - 8265754: Refactoring suspend/resume in the HandshakeState away > > In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3 > @pchilano Do you expect to have any performance impact of having an indirection layer? > No concern about performance, just where the code should be for better design and simplicity. > Since we found out that the suspend/resume code used to belong to JavaThread and then was moved out of there for (some) reason, I do not see a good explanation of why one should bring it back there. JavaThread class is already huge and from maintainability perspective I think it is better to have the suspend/resume API separated. At the same time it is clearly not a part of `HandshakeState`. > The reason is the interaction with the `HandshakeState` lock. Before, each `JavaThread` had a suspend/resume monitor (`_SR_lock`), but now we are directly using the one from the `HandshakeState` since that?s what the `JavaThread` is holding already when suspending. > An option might be, if I understand correctly, to do a less straightforward refactoring as suggested above, i.e. without giving `HandshakeState` lock access to `HandshakeSuspender`. I do not yet know if it is doable. Would be a compromise approach? > The issue is that you would have to keep those methods that need access to it in `HandshakeState`. > Another option is to keep things in `HandhshakeSuspender` and give it access to the `HandshakeState `lock , but move `_suspended`/`_async_suspend_handshake` in the suspender. Then, methods should no longer be static, and the suspender itself would be owned by JavaThread, similarly to `HandshakeState `instance. > That sounds better. I would personally leave it in `JavaThread` but encapsulating the implementation like that in a new class looks good too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2931371874 From cstein at openjdk.org Mon Jun 2 16:06:50 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 2 Jun 2025 16:06:50 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment In-Reply-To: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com> References: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com> Message-ID: <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com> On Mon, 2 Jun 2025 15:08:49 GMT, Vicente Romero wrote: >> src/java.base/share/native/libjli/args.c line 276: >> >>> 274: } >>> 275: pctx->cptr = nextc + 1; >>> 276: return token; >> >> This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted? > > right I agree that if there is common code we should extract it in a helper method Or the handling of `#` can be merged with the previous case ... somehow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121594206 From jiangli at openjdk.org Mon Jun 2 16:00:56 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 2 Jun 2025 16:00:56 GMT Subject: RFR: 8357632: CDS test failures on static JDK In-Reply-To: References: Message-ID: On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou wrote: > Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. > > The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. > > It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. > > Testing: > Tested the affected tests locally on static-jdk. > https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. @calvinccheung @shipilev Could you please review the fix? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2931379145 From matsaave at openjdk.org Mon Jun 2 16:41:07 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 2 Jun 2025 16:41:07 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v2] In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: > Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Stefan comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25591/files - new: https://git.openjdk.org/jdk/pull/25591/files/3e41fdef..9ef0863f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25591&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25591&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25591/head:pull/25591 PR: https://git.openjdk.org/jdk/pull/25591 From matsaave at openjdk.org Mon Jun 2 16:41:07 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 2 Jun 2025 16:41:07 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v2] In-Reply-To: <4MH6Hg4tHenfGii_PwxPKbCzWR4d8rntWkho97jxmn0=.7aef9234-f457-479e-b65e-3bc5bda08284@github.com> References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> <4MH6Hg4tHenfGii_PwxPKbCzWR4d8rntWkho97jxmn0=.7aef9234-f457-479e-b65e-3bc5bda08284@github.com> Message-ID: On Mon, 2 Jun 2025 15:25:12 GMT, Stefan Karlsson wrote: > We already have this property that is used for some tests: > > ``` > @requires vm.cds.write.archived.java.heap > ``` > > Should this be used here instead of explicitly excluding ZGC? > > This property boils down to: > > ``` > // If an incompatible VM options is found, return a text message that explains why > static const char* check_options_incompatible_with_dumping_heap() { > #if INCLUDE_CDS_JAVA_HEAP > if (!UseCompressedClassPointers) { > return "UseCompressedClassPointers must be true"; > } > > // Almost all GCs support heap region dump, except ZGC (so far). > if (UseZGC) { > return "ZGC is not supported"; > } > > return nullptr; > #else > return "JVM not configured for writing Java heap objects"; > #endif > } > ``` I forgot this existed, thanks for pointing it out! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25591#issuecomment-2931529934 From ccheung at openjdk.org Mon Jun 2 16:50:14 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 2 Jun 2025 16:50:14 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation [v2] In-Reply-To: References: Message-ID: > If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. > To avoid the exception, this fix is not to start the management agent when creating an AOT cache. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision: - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java Co-authored-by: Aleksey Shipil?v - place the new test in a new file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25562/files - new: https://git.openjdk.org/jdk/pull/25562/files/abeb7b6f..e694a720 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25562&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25562&range=00-01 Stats: 75 lines in 2 files changed: 64 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25562/head:pull/25562 PR: https://git.openjdk.org/jdk/pull/25562 From shade at openjdk.org Mon Jun 2 16:50:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 2 Jun 2025 16:50:14 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:46:51 GMT, Calvin Cheung wrote: >> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. >> To avoid the exception, this fix is not to start the management agent when creating an AOT cache. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java > > Co-authored-by: Aleksey Shipil?v > - place the new test in a new file Marked as reviewed by shade (Reviewer). Marked as reviewed by shade (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java line 44: > 42: public class ManagementAgent { > 43: public static void main(String... args) throws Exception { > 44: SimpleCDSAppTester.of("HelloAOTCache-with-manangment-agent") Suggestion: SimpleCDSAppTester.of("HelloAOTCache-with-management-agent") ------------- PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2889202582 PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2889216659 PR Review Comment: https://git.openjdk.org/jdk/pull/25562#discussion_r2121669853 From iklam at openjdk.org Mon Jun 2 16:50:14 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 2 Jun 2025 16:50:14 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:46:51 GMT, Calvin Cheung wrote: >> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. >> To avoid the exception, this fix is not to start the management agent when creating an AOT cache. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java > > Co-authored-by: Aleksey Shipil?v > - place the new test in a new file LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2889210530 From ccheung at openjdk.org Mon Jun 2 16:50:14 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 2 Jun 2025 16:50:14 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation In-Reply-To: References: Message-ID: On Sat, 31 May 2025 00:30:09 GMT, Calvin Cheung wrote: > If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. > To avoid the exception, this fix is not to start the management agent when creating an AOT cache. > > Passed tiers 1 - 4 testing. After discussion with Ioi offline, I've move the new test to a new file `aotCache/ManagementAgent.java`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25562#issuecomment-2931541114 From phh at openjdk.org Mon Jun 2 16:53:52 2025 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 2 Jun 2025 16:53:52 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke wrote: > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2889236068 From iklam at openjdk.org Mon Jun 2 16:55:05 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 2 Jun 2025 16:55:05 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element In-Reply-To: References: Message-ID: <3ryl7wuwna7opBPceC3bznDWxJ5PcgDItddehrCp0HI=.9bd191da-f574-4926-bbcd-29c6d99c5b0d@github.com> On Thu, 22 May 2025 09:48:11 GMT, David Holmes wrote: >> When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. >> >> The bug happens because `ClasspathStream` does not correctly omit the empty elements at the beginning of the classpath. >> >> I also improved the logs to help debugging classpath mismatches when using the AOT cache. > > This sounds like a bug in `-cp` parsing to me! Thanks @dholmes-ora @calvinccheung for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25372#issuecomment-2931572656 From ccheung at openjdk.org Mon Jun 2 16:55:08 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 2 Jun 2025 16:55:08 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation [v2] In-Reply-To: References: Message-ID: On Sat, 31 May 2025 01:05:22 GMT, Vladimir Kozlov wrote: >> Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java >> >> Co-authored-by: Aleksey Shipil?v >> - place the new test in a new file > > Good. Thank you @vnkozlov @shipilev @iklam ------------- PR Comment: https://git.openjdk.org/jdk/pull/25562#issuecomment-2931569924 From iklam at openjdk.org Mon Jun 2 16:55:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 2 Jun 2025 16:55:06 GMT Subject: Integrated: 8356308: Assert with -Xlog:class+path when classpath has an empty element In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:28:16 GMT, Ioi Lam wrote: > When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. > > The bug happens because `ClasspathStream` does not correctly omit the empty elements at the beginning of the classpath. > > I also improved the logs to help debugging classpath mismatches when using the AOT cache. This pull request has now been integrated. Changeset: bce2bd24 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/bce2bd24ef64e71d895bbf4d91693b30a285746b Stats: 149 lines in 7 files changed: 114 ins; 11 del; 24 mod 8356308: Assert with -Xlog:class+path when classpath has an empty element Reviewed-by: dholmes, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/25372 From ccheung at openjdk.org Mon Jun 2 16:55:09 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 2 Jun 2025 16:55:09 GMT Subject: Integrated: 8352187: Don't start management agent during AOT cache creation In-Reply-To: References: Message-ID: On Sat, 31 May 2025 00:30:09 GMT, Calvin Cheung wrote: > If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. > To avoid the exception, this fix is not to start the management agent when creating an AOT cache. > > Passed tiers 1 - 4 testing. This pull request has now been integrated. Changeset: 8b6a11f7 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/8b6a11f7e05ee0cece798c5ff6646bddbee04900 Stats: 80 lines in 2 files changed: 73 ins; 0 del; 7 mod 8352187: Don't start management agent during AOT cache creation Reviewed-by: shade, iklam, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25562 From ccheung at openjdk.org Mon Jun 2 16:55:54 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 2 Jun 2025 16:55:54 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v2] In-Reply-To: References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Mon, 2 Jun 2025 16:41:07 GMT, Matias Saavedra Silva wrote: >> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Stefan comment LGTM. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2889243196 From iveresov at openjdk.org Mon Jun 2 17:58:15 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 2 Jun 2025 17:58:15 GMT Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag) Message-ID: Remove unnecessary no throw ------------- Commit messages: - Remove unnessesary nothrow Changes: https://git.openjdk.org/jdk/pull/25596/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25596&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358283 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25596.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25596/head:pull/25596 PR: https://git.openjdk.org/jdk/pull/25596 From kvn at openjdk.org Mon Jun 2 18:20:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 2 Jun 2025 18:20:51 GMT Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag) In-Reply-To: References: Message-ID: <7cEPkB3RSInsElJHCKjLinZNFktQRGaXt0hOmn7Srno=.b79769db-ef89-4f2d-9b6b-5ef5e5769c20@github.com> On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov wrote: > Remove unnecessary no throw Please, run our testing before integration. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25596#pullrequestreview-2889482857 From cjplummer at openjdk.org Mon Jun 2 19:09:57 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 2 Jun 2025 19:09:57 GMT Subject: RFR: 8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64 In-Reply-To: References: Message-ID: On Fri, 30 May 2025 19:57:37 GMT, Chris Plummer wrote: > Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed. > > Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes. Thank you for the reviews David and Sandao! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25556#issuecomment-2932084298 From cjplummer at openjdk.org Mon Jun 2 19:09:58 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 2 Jun 2025 19:09:58 GMT Subject: Integrated: 8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64 In-Reply-To: References: Message-ID: On Fri, 30 May 2025 19:57:37 GMT, Chris Plummer wrote: > Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed. > > Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes. This pull request has now been integrated. Changeset: 5243f385 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/5243f3851b0345b874ff51ea3a07e82f73741546 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64 Reviewed-by: syan, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25556 From coleenp at openjdk.org Mon Jun 2 20:25:51 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 2 Jun 2025 20:25:51 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: <8fEZlbiG4Ch3GtdFD_Bac4Xd2WUh00ujxDQZKuFYQ_k=.46f69672-6885-43c7-a5b2-0df1af358e51@github.com> On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke wrote: > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2889827516 From dholmes at openjdk.org Mon Jun 2 21:45:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Jun 2025 21:45:51 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. >> >> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add WhiteBox back + typo test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 56: > 54: Class c = cl.loadClass(className); > 55: cl = null; c = null; > 56: ClassUnloadCommon.triggerUnloading(); So the unloading is not part of this test? Are we just using the ClassUnloadCommon utility as a convenient way to get an additional classloader involved? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2122215783 From pchilanomate at openjdk.org Mon Jun 2 22:47:53 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 2 Jun 2025 22:47:53 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 21:43:11 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Add WhiteBox back + typo > > test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 56: > >> 54: Class c = cl.loadClass(className); >> 55: cl = null; c = null; >> 56: ClassUnloadCommon.triggerUnloading(); > > So the unloading is not part of this test? Are we just using the ClassUnloadCommon utility as a convenient way to get an additional classloader involved? Yes, the unloading part is not needed. Before this patch, the only line needed was `ClassLoader cl = ClassUnloadCommon.newClassLoader();`. That would already trigger the constraint we checked for in the parent. But it doesn't work for virtual threads, so I changed it to check for a constraint on the created `ClassUnloadCommonClassLoader` instead to avoid dependencies on previously executed code like with the `app` classloader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2122286788 From dholmes at openjdk.org Tue Jun 3 00:34:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jun 2025 00:34:52 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke wrote: > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. Changes requested by dholmes (Reviewer). src/java.base/share/man/java.md line 1026: > 1024: : Enables compact object headers. By default, this option is disabled. > 1025: Enabling this option reduces memory footprint in the Java heap by > 1026: 4 bytes per object (on average). The options are (with 3 exceptions) in alphabetical order - please move this to where the other `UseXXX` flags are. This does not explain at all why someone would want to use, or not use, COH. What are the trade-offs for turning it on? Please explain the usage. ------------- PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2890254926 PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2122379295 From dholmes at openjdk.org Tue Jun 3 00:44:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jun 2025 00:44:51 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. >> >> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add WhiteBox back + typo Okay. This test really has me puzzled as to what it was trying to test, but that isn't your doing. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25496#pullrequestreview-2890268037 From qxing at openjdk.org Tue Jun 3 01:37:54 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Tue, 3 Jun 2025 01:37:54 GMT Subject: RFR: 8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream` In-Reply-To: References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> Message-ID: On Thu, 29 May 2025 18:54:09 GMT, Calvin Cheung wrote: >> In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration. > > Looks good. @calvinccheung @iklam Thank you for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25518#issuecomment-2933066645 From duke at openjdk.org Tue Jun 3 01:37:54 2025 From: duke at openjdk.org (duke) Date: Tue, 3 Jun 2025 01:37:54 GMT Subject: RFR: 8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream` In-Reply-To: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> Message-ID: On Thu, 29 May 2025 08:09:14 GMT, Qizheng Xing wrote: > In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration. @MaxXSoft Your change (at version 7165322d735e83c7c6f8d647b282b59139ea72ca) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25518#issuecomment-2933067884 From qxing at openjdk.org Tue Jun 3 03:13:56 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Tue, 3 Jun 2025 03:13:56 GMT Subject: Integrated: 8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream` In-Reply-To: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> Message-ID: <3Drpn9VbtlX8Rw_Cm30hh5sdoRMWz_o-0zCmKAnbig4=.ce8e8ca4-47f5-46f2-9e03-2e5e6b6c6980@github.com> On Thu, 29 May 2025 08:09:14 GMT, Qizheng Xing wrote: > In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration. This pull request has now been integrated. Changeset: c96803dc Author: Qizheng Xing Committer: Ioi Lam URL: https://git.openjdk.org/jdk/commit/c96803dc8b480427bca5b1c6b8c4e8693bc90b92 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod 8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream` Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.org/jdk/pull/25518 From kbarrett at openjdk.org Tue Jun 3 04:10:50 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 3 Jun 2025 04:10:50 GMT Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag) In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov wrote: > Remove unnecessary no throw Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25596#pullrequestreview-2890544108 From stefank at openjdk.org Tue Jun 3 06:11:52 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 3 Jun 2025 06:11:52 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v2] In-Reply-To: References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Mon, 2 Jun 2025 16:41:07 GMT, Matias Saavedra Silva wrote: >> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Stefan comment Looks good! ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2890821652 From rkennke at openjdk.org Tue Jun 3 07:04:55 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 3 Jun 2025 07:04:55 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 00:32:35 GMT, David Holmes wrote: >> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. > > src/java.base/share/man/java.md line 1026: > >> 1024: : Enables compact object headers. By default, this option is disabled. >> 1025: Enabling this option reduces memory footprint in the Java heap by >> 1026: 4 bytes per object (on average). > > The options are (with 3 exceptions) in alphabetical order - please move this to where the other `UseXXX` flags are. > > This does not explain at all why someone would want to use, or not use, COH. What are the trade-offs for turning it on? Please explain the usage. I put it there because @coleenp said in the JBS issue: "Since UseCompactObjectHeaders seems more useful than some of the other options in the list (except the JFR and NMT options), I think it should go first." - I can move it down, though. I don't know what you mean by 'This does not explain at all why someone would want to use, or not use, COH' - I explain right there "Enabling this option reduces memory footprint in the Java heap by 4 bytes per object (on average)." Is this not enough? There is no trade-off (loss of performance or any such issue would be considered a bug, tbh). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2122911362 From dholmes at openjdk.org Tue Jun 3 07:42:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jun 2025 07:42:51 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 07:02:18 GMT, Roman Kennke wrote: >> src/java.base/share/man/java.md line 1026: >> >>> 1024: : Enables compact object headers. By default, this option is disabled. >>> 1025: Enabling this option reduces memory footprint in the Java heap by >>> 1026: 4 bytes per object (on average). >> >> The options are (with 3 exceptions) in alphabetical order - please move this to where the other `UseXXX` flags are. >> >> This does not explain at all why someone would want to use, or not use, COH. What are the trade-offs for turning it on? Please explain the usage. > > I put it there because @coleenp said in the JBS issue: "Since UseCompactObjectHeaders seems more useful than some of the other options in the list (except the JFR and NMT options), I think it should go first." - I can move it down, though. > > I don't know what you mean by 'This does not explain at all why someone would want to use, or not use, COH' - I explain right there "Enabling this option reduces memory footprint in the Java heap by 4 bytes per object (on average)." Is this not enough? There is no trade-off (loss of performance or any such issue would be considered a bug, tbh). If the flag is off by default but apparently only has the benefit of reducing footprint, then the reader will wonder why it is off by default. At the moment this reads like we have a flag that will benefit everyone and yet we expect them to turn it on themselves because for some reason we chose not to. If this is really a no-lose situation we can say something like I did in the Release Note JBS issue i.e. something like "this is a good thing to do but still under evaluation so is off by default for now". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2122998105 From rkennke at openjdk.org Tue Jun 3 08:03:50 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 3 Jun 2025 08:03:50 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 07:40:35 GMT, David Holmes wrote: >> I put it there because @coleenp said in the JBS issue: "Since UseCompactObjectHeaders seems more useful than some of the other options in the list (except the JFR and NMT options), I think it should go first." - I can move it down, though. >> >> I don't know what you mean by 'This does not explain at all why someone would want to use, or not use, COH' - I explain right there "Enabling this option reduces memory footprint in the Java heap by 4 bytes per object (on average)." Is this not enough? There is no trade-off (loss of performance or any such issue would be considered a bug, tbh). > > If the flag is off by default but apparently only has the benefit of reducing footprint, then the reader will wonder why it is off by default. At the moment this reads like we have a flag that will benefit everyone and yet we expect them to turn it on themselves because for some reason we chose not to. If this is really a no-lose situation we can say something like I did in the Release Note JBS issue i.e. something like "this is a good thing to do but still under evaluation so is off by default for now". Yes this is really a bit odd. 'Still under evaluation' is also weird considering that we just removed the 'experimental' status, which basically saying 'still under evaluation'. Anyway, I will adopt your wording from the release note and move the text down as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2123054321 From syan at openjdk.org Tue Jun 3 08:12:03 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 3 Jun 2025 08:12:03 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v2] In-Reply-To: References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Mon, 2 Jun 2025 16:41:07 GMT, Matias Saavedra Silva wrote: >> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Stefan comment test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java line 29: > 27: * @summary Test Loading of default archives in all configurations > 28: * @requires vm.cds > 29: * @requires vm.cds.write.archived.java.heap Should we update the copyright year from `2024` to `2024, 2025` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25591#discussion_r2123077288 From alanb at openjdk.org Tue Jun 3 09:41:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Jun 2025 09:41:59 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:50:14 GMT, Calvin Cheung wrote: >> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. >> To avoid the exception, this fix is not to start the management agent when creating an AOT cache. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java > > Co-authored-by: Aleksey Shipil?v > - place the new test in a new file > this fix is not to start the management agent when creating an AOT cache. I think this is good. The initial processing of -Dcom.sun.management will add the jdk.management.agent module to the root set so the set of modules when creating the AOT cache will be the same as runtime, even through the JMX agent isn't started. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25562#issuecomment-2934387476 From rkennke at openjdk.org Tue Jun 3 09:49:41 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 3 Jun 2025 09:49:41 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v2] In-Reply-To: References: Message-ID: <5xhgFtWdz6wuiOiO5SHE_grRpqPvEP3x9Ox4LBgx7IA=.2b1bac77-9c23-4f96-bed2-0a35ba7d0275@github.com> > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move text down and add a note about future plans to enable by default ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25491/files - new: https://git.openjdk.org/jdk/pull/25491/files/d189f600..3ffeaaee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25491&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25491&range=00-01 Stats: 14 lines in 1 file changed: 9 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25491/head:pull/25491 PR: https://git.openjdk.org/jdk/pull/25491 From azafari at openjdk.org Tue Jun 3 09:58:58 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 3 Jun 2025 09:58:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v34] In-Reply-To: <8sr5gvYZaYz_EbxnE_vWOxD-PIrKwfCU6e37BNY18tI=.d7d64ab7-f13d-483e-ad0b-6ea4c6c66852@github.com> References: <8sr5gvYZaYz_EbxnE_vWOxD-PIrKwfCU6e37BNY18tI=.d7d64ab7-f13d-483e-ad0b-6ea4c6c66852@github.com> Message-ID: <7X_9DmBjEwctV2MXSQVkFLTi4wrp2ZtjYjHSSLVrWKY=.491f1118-82e8-428e-9752-11278959d02d@github.com> On Mon, 2 Jun 2025 15:04:41 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> old format comments are removed. Redundant tests are removed. > > src/hotspot/share/nmt/vmatree.cpp line 116: > >> 114: const int op_index = req.op_to_index(); >> 115: const Operation op = req.op(); >> 116: assert(op != Operation::Invalid && op_index >= 0 && op_index < 4, "should be"); > > RE: "op_index >= 0 && op_index < 4" > Can we use the class constants here, instead of hardcoding to int values? The constant values are index and I intentionally name the variable as `op_index`. Since the index is used for accessing elements of an array later, the range of valid values are checked, `0` and the size of the array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2123330373 From azafari at openjdk.org Tue Jun 3 10:18:47 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 3 Jun 2025 10:18:47 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v35] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: invalid -> release. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/b68495bd..176629bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=33-34 Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From nbenalla at openjdk.org Tue Jun 3 11:14:36 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 3 Jun 2025 11:14:36 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into jdk.8355746 - Problemlist JavaBaseCheckSince - Revert "feedback: never bump ASM version" This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=06 Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Tue Jun 3 11:14:37 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 3 Jun 2025 11:14:37 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: References: Message-ID: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com> On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2934728105 From duke at openjdk.org Tue Jun 3 11:19:07 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 3 Jun 2025 11:19:07 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v4] In-Reply-To: References: Message-ID: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov has updated the pull request incrementally with six additional commits since the last revision: - 8265754: Refactoring. - 8265754: Refactoring. - 8265754: Refactoring. - 8265754: Refactoring. - 8265754: Refactoring. - 8265754: Refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/3b0fffab..2f6a26d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=02-03 Stats: 113 lines in 5 files changed: 20 ins; 34 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From duke at openjdk.org Tue Jun 3 11:19:07 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 3 Jun 2025 11:19:07 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: References: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> Message-ID: <4xBAv1XcsxmagkgcP6KyD6lW3-n6vyIDpmvcU0dyaa4=.8a020e6d-1f9a-4fe6-b6b9-0194aa420112@github.com> On Mon, 2 Jun 2025 15:56:32 GMT, Patricio Chilano Mateo wrote: >> In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3 > >> @pchilano Do you expect to have any performance impact of having an indirection layer? >> > No concern about performance, just where the code should be for better design and simplicity. > >> Since we found out that the suspend/resume code used to belong to JavaThread and then was moved out of there for (some) reason, I do not see a good explanation of why one should bring it back there. JavaThread class is already huge and from maintainability perspective I think it is better to have the suspend/resume API separated. At the same time it is clearly not a part of `HandshakeState`. >> > The reason is the interaction with the `HandshakeState` lock. Before, each `JavaThread` had a suspend/resume monitor (`_SR_lock`), but now we are directly using the one from the `HandshakeState` since that?s what the `JavaThread` is holding already when suspending. > >> An option might be, if I understand correctly, to do a less straightforward refactoring as suggested above, i.e. without giving `HandshakeState` lock access to `HandshakeSuspender`. I do not yet know if it is doable. Would be a compromise approach? >> > The issue is that you would have to keep those methods that need access to it in `HandshakeState`. > >> Another option is to keep things in `HandhshakeSuspender` and give it access to the `HandshakeState `lock , but move `_suspended`/`_async_suspend_handshake` in the suspender. Then, methods should no longer be static, and the suspender itself would be owned by JavaThread, similarly to `HandshakeState `instance. >> > That sounds better. I would personally leave it in `JavaThread` but encapsulating the implementation like that in a new class looks good too. @pchilano I refactored the code, please take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2934752961 From duke at openjdk.org Tue Jun 3 11:24:39 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 3 Jun 2025 11:24:39 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v5] In-Reply-To: References: Message-ID: <5v5EYlx2v0r3jZot9wGYcig_nFC1MpXczWyyIRJhSdQ=.9f44cbaf-bdc8-4a88-8157-5b7acebff9f1@github.com> > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8265754: Refactoring. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/2f6a26d4..425ec18e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From sgehwolf at openjdk.org Tue Jun 3 11:54:52 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Jun 2025 11:54:52 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available In-Reply-To: References: Message-ID: On Thu, 22 May 2025 09:06:15 GMT, Casper Norrbin wrote: > Hi everyone, > > This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data. > > The new parameters are: > > - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time. > > - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed. > > - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems. > > Testing: > - All container tests under `/test/hotspot/jtreg/containers/` > - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied. This looks fine to me. One suggestion as I think the cpu usage might be 0 and greater. src/hotspot/os/linux/os_linux.cpp line 2494: > 2492: st->print("cpu_usage_in_micros: "); > 2493: if (j > 0) { > 2494: st->print_cr(JLONG_FORMAT, j); Suggestion: if (j >= 0) { st->print_cr(JLONG_FORMAT, j); ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25388#pullrequestreview-2891786092 PR Review Comment: https://git.openjdk.org/jdk/pull/25388#discussion_r2123443807 From coleenp at openjdk.org Tue Jun 3 12:07:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 3 Jun 2025 12:07:53 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v2] In-Reply-To: <5xhgFtWdz6wuiOiO5SHE_grRpqPvEP3x9Ox4LBgx7IA=.2b1bac77-9c23-4f96-bed2-0a35ba7d0275@github.com> References: <5xhgFtWdz6wuiOiO5SHE_grRpqPvEP3x9Ox4LBgx7IA=.2b1bac77-9c23-4f96-bed2-0a35ba7d0275@github.com> Message-ID: On Tue, 3 Jun 2025 09:49:41 GMT, Roman Kennke wrote: >> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move text down and add a note about future plans to enable by default I didn't realize they were in alphabetical order, so maybe someone will scroll down and see this option. The last paragraph sounds odd and whilst is a weird word. Maybe simply adding a sentence to the main block like, "This option may become the default in a future release." ------------- PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2892047473 From coleenp at openjdk.org Tue Jun 3 12:21:55 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 3 Jun 2025 12:21:55 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. >> >> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add WhiteBox back + typo Looks good, thank you for fixing this test! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25496#pullrequestreview-2892085800 From coleenp at openjdk.org Tue Jun 3 12:21:56 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 3 Jun 2025 12:21:56 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 22:44:58 GMT, Patricio Chilano Mateo wrote: >> test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 56: >> >>> 54: Class c = cl.loadClass(className); >>> 55: cl = null; c = null; >>> 56: ClassUnloadCommon.triggerUnloading(); >> >> So the unloading is not part of this test? Are we just using the ClassUnloadCommon utility as a convenient way to get an additional classloader involved? > > Yes, the unloading part is not needed. Before this patch, the only line needed was `ClassLoader cl = ClassUnloadCommon.newClassLoader();`. That would already trigger the constraint we checked for in the parent. But it doesn't work for virtual threads, so I changed it to check for a constraint on the created `ClassUnloadCommonClassLoader` instead to avoid dependencies on previously executed code like with the `app` classloader. I think we added the class unloading so that we can see the -Xlog output for that. But it's not reliable enough so we might have removed it. This is fine to remove it. >> test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 66: >> >>> 64: Collections.addAll(argsList, args); >>> 65: Collections.addAll(argsList, "-Xmn8m"); >>> 66: Collections.addAll(argsList, "-Xbootclasspath/a:."); >> >> Without use of `WhiteBox`, you don't need this. And this is probably what caused the class to be loaded by the boot-loader instead of the custom loader as expected. But the use of WB is needed by `ClassUnloadCommon` and these instructions are present to ensure it works - as added by JDK-8289184. > > Added back the use of `WhiteBox`. As to `test.Empty`, it was always loaded by the `app` classloader regardless of `-Xbootclasspath/a:.`, i.e that?s only needed for loading `WhiteBox`. The issue was the missing `test.class.path` property. Class `test.Empty` resides in directory `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/classes/0/runtime/logging/classes/test/` but the process?s current working directory?is `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/scratch/0`, so setting the custom classloader classpath as `.` meant it wasn?t able to find it. So we ended up delegating to the parent classloader (`app`) which already had the correct directories in the classpath. Good work figuring that out. yes, ClassUnloadCommon needs this because it uses WhiteBox for class unloading. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2123643517 PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2123640939 From rkennke at openjdk.org Tue Jun 3 12:55:38 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 3 Jun 2025 12:55:38 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v3] In-Reply-To: References: Message-ID: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com> > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Refine text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25491/files - new: https://git.openjdk.org/jdk/pull/25491/files/3ffeaaee..2e96057d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25491&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25491&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25491/head:pull/25491 PR: https://git.openjdk.org/jdk/pull/25491 From coleenp at openjdk.org Tue Jun 3 13:03:56 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 3 Jun 2025 13:03:56 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v3] In-Reply-To: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com> References: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com> Message-ID: On Tue, 3 Jun 2025 12:55:38 GMT, Roman Kennke wrote: >> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Refine text Approve again. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2892257447 From rkennke at openjdk.org Tue Jun 3 13:17:58 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 3 Jun 2025 13:17:58 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v3] In-Reply-To: References: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com> Message-ID: <7IzWhcHrNIJhARy1OewtjiUZvf0Okzz6943Pk3lwjBA=.7aff950a-07d7-4f76-8fdc-62d7721b121f@github.com> On Tue, 3 Jun 2025 13:01:29 GMT, Coleen Phillimore wrote: > Approve again. Thanks! I'll wait for @dholmes-ora to also approve it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2935180820 From kevinw at openjdk.org Tue Jun 3 14:13:53 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 3 Jun 2025 14:13:53 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov wrote: > The fix turns on streaming output for attach operations. > Change in HotSpotVirtualMachine.java sets attach client property. > Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM). > > Testing: tier1..tier8 src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 66: > 64: String s = VM.getSavedProperty("jdk.attach.allowAttachSelf"); > 65: ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s); > 66: // For now the default is false. Shall we remove the comment? It was not obvious whether it applied to the code above, or below. 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25192#discussion_r2123964340 From matsaave at openjdk.org Tue Jun 3 15:22:55 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 3 Jun 2025 15:22:55 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v2] In-Reply-To: References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Tue, 3 Jun 2025 08:08:49 GMT, SendaoYan wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Stefan comment > > test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java line 29: > >> 27: * @summary Test Loading of default archives in all configurations >> 28: * @requires vm.cds >> 29: * @requires vm.cds.write.archived.java.heap > > Should we update the copyright year from `2024` to `2024, 2025` Do I need to update the Red Hat copyright as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25591#discussion_r2124215598 From matsaave at openjdk.org Tue Jun 3 15:31:37 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 3 Jun 2025 15:31:37 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v3] In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: > Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Updated copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25591/files - new: https://git.openjdk.org/jdk/pull/25591/files/9ef0863f..12c5a5df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25591&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25591&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25591/head:pull/25591 PR: https://git.openjdk.org/jdk/pull/25591 From iveresov at openjdk.org Tue Jun 3 15:33:57 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 3 Jun 2025 15:33:57 GMT Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag) In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov wrote: > Remove unnecessary no throw Testing was good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25596#issuecomment-2935992831 From iveresov at openjdk.org Tue Jun 3 15:33:57 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 3 Jun 2025 15:33:57 GMT Subject: Integrated: 8358283: Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag) In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov wrote: > Remove unnecessary no throw This pull request has now been integrated. Changeset: 01f01b6f Author: Igor Veresov URL: https://git.openjdk.org/jdk/commit/01f01b6f7b8a2f0dbe940bffd567ff2b46732787 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8358283: Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag) Reviewed-by: kvn, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/25596 From pchilanomate at openjdk.org Tue Jun 3 16:16:01 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 3 Jun 2025 16:16:01 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. >> >> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Add WhiteBox back + typo Thanks for the reviews David and Coleen! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25496#issuecomment-2936164319 From pchilanomate at openjdk.org Tue Jun 3 16:16:03 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 3 Jun 2025 16:16:03 GMT Subject: Integrated: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: References: Message-ID: On Wed, 28 May 2025 14:42:10 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. > > The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 16e120b0 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/16e120b00842e340401b6930354edfb1515f6ca4 Stats: 13 lines in 2 files changed: 5 ins; 3 del; 5 mod 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/25496 From lmesnik at openjdk.org Tue Jun 3 16:37:52 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 3 Jun 2025 16:37:52 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v3] In-Reply-To: References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Tue, 3 Jun 2025 15:31:37 GMT, Matias Saavedra Silva wrote: >> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2893297395 From dcubed at openjdk.org Tue Jun 3 18:44:37 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 3 Jun 2025 18:44:37 GMT Subject: Integrated: 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java Message-ID: A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms. ------------- Commit messages: - 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java Changes: https://git.openjdk.org/jdk/pull/25626/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25626&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358539 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25626.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25626/head:pull/25626 PR: https://git.openjdk.org/jdk/pull/25626 From ayang at openjdk.org Tue Jun 3 18:44:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 3 Jun 2025 18:44:37 GMT Subject: Integrated: 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25626#pullrequestreview-2893678505 From bpb at openjdk.org Tue Jun 3 18:44:37 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 3 Jun 2025 18:44:37 GMT Subject: Integrated: 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms. Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25626#pullrequestreview-2893679060 From dcubed at openjdk.org Tue Jun 3 18:44:37 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 3 Jun 2025 18:44:37 GMT Subject: Integrated: 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 18:39:29 GMT, Albert Mingkun Yang wrote: >> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms. > > Marked as reviewed by ayang (Reviewer). @albertnetymk and @bplb - Thanks for the lightning fast reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25626#issuecomment-2936702783 From dcubed at openjdk.org Tue Jun 3 18:44:37 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 3 Jun 2025 18:44:37 GMT Subject: Integrated: 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms. This pull request has now been integrated. Changeset: e984fa79 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/e984fa7997dda922708edf556d1839b866e44e55 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java Reviewed-by: ayang, bpb ------------- PR: https://git.openjdk.org/jdk/pull/25626 From amenkov at openjdk.org Tue Jun 3 18:52:53 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 3 Jun 2025 18:52:53 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default [v2] In-Reply-To: References: Message-ID: > The fix turns on streaming output for attach operations. > Change in HotSpotVirtualMachine.java sets attach client property. > Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM). > > Testing: tier1..tier8 Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: removed comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25192/files - new: https://git.openjdk.org/jdk/pull/25192/files/076e6e86..1bda79ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25192&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25192&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25192.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25192/head:pull/25192 PR: https://git.openjdk.org/jdk/pull/25192 From amenkov at openjdk.org Tue Jun 3 18:52:54 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 3 Jun 2025 18:52:54 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 14:10:52 GMT, Kevin Walls wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> removed comment > > src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 66: > >> 64: String s = VM.getSavedProperty("jdk.attach.allowAttachSelf"); >> 65: ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s); >> 66: // For now the default is false. > > Shall we remove the comment? It was not obvious whether it applied to the code above, or below. 8-) Yes, it's obsoleted. Removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25192#discussion_r2124652335 From sspitsyn at openjdk.org Tue Jun 3 19:44:17 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 3 Jun 2025 19:44:17 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default [v2] In-Reply-To: References: Message-ID: <7N47_nU8XdHQWJ80QYjApknoFywVnUBNe6arK8eJdtU=.ebf43bc4-a80b-4463-8b0d-eeebb38965de@github.com> On Tue, 3 Jun 2025 18:52:53 GMT, Alex Menkov wrote: >> The fix turns on streaming output for attach operations. >> Change in HotSpotVirtualMachine.java sets attach client property. >> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM). >> >> Testing: tier1..tier8 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > removed comment Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25192#pullrequestreview-2893864149 From kevinw at openjdk.org Tue Jun 3 20:16:17 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 3 Jun 2025 20:16:17 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 18:52:53 GMT, Alex Menkov wrote: >> The fix turns on streaming output for attach operations. >> Change in HotSpotVirtualMachine.java sets attach client property. >> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM). >> >> Testing: tier1..tier8 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > removed comment thanks Alex. Apologies for looking at this so late 8-) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25192#pullrequestreview-2893995465 From amenkov at openjdk.org Tue Jun 3 20:51:25 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 3 Jun 2025 20:51:25 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default [v2] In-Reply-To: <7N47_nU8XdHQWJ80QYjApknoFywVnUBNe6arK8eJdtU=.ebf43bc4-a80b-4463-8b0d-eeebb38965de@github.com> References: <7N47_nU8XdHQWJ80QYjApknoFywVnUBNe6arK8eJdtU=.ebf43bc4-a80b-4463-8b0d-eeebb38965de@github.com> Message-ID: On Tue, 3 Jun 2025 19:41:50 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> removed comment > > Marked as reviewed by sspitsyn (Reviewer). Thank for the review @sspitsyn and @kevinjwalls ------------- PR Comment: https://git.openjdk.org/jdk/pull/25192#issuecomment-2937141735 From amenkov at openjdk.org Tue Jun 3 20:51:26 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 3 Jun 2025 20:51:26 GMT Subject: Integrated: 8354460: Streaming output for attach API should be turned on by default In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov wrote: > The fix turns on streaming output for attach operations. > Change in HotSpotVirtualMachine.java sets attach client property. > Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM). > > Testing: tier1..tier8 This pull request has now been integrated. Changeset: da49fa5e Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/da49fa5e15b137c086ad8fd438bf448da42121cb Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod 8354460: Streaming output for attach API should be turned on by default Reviewed-by: sspitsyn, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/25192 From dholmes at openjdk.org Tue Jun 3 20:58:22 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Jun 2025 20:58:22 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v3] In-Reply-To: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com> References: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com> Message-ID: On Tue, 3 Jun 2025 12:55:38 GMT, Roman Kennke wrote: >> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Refine text I still find it an uninformative piece of documentation I'm afraid. It just begs the question "why isn't this on by default now?". The fact we haven't turned it on means we are still evaluating it. The move from experimental to product just means we are increasing the scope of the evaluation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2937169017 From matsaave at openjdk.org Tue Jun 3 22:49:17 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 3 Jun 2025 22:49:17 GMT Subject: RFR: 8350029: Illegal invokespecial interface not caught by verification In-Reply-To: References: Message-ID: On Fri, 30 May 2025 06:31:43 GMT, David Holmes wrote: > As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check. > > The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering. > > Testing: > - new test case > - tiers 1-3 > > Thanks The changes make sense and look good to me! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25538#pullrequestreview-2894313447 From dholmes at openjdk.org Wed Jun 4 01:12:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jun 2025 01:12:20 GMT Subject: RFR: 8350029: Illegal invokespecial interface not caught by verification In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 22:46:20 GMT, Matias Saavedra Silva wrote: >> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check. >> >> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering. >> >> Testing: >> - new test case >> - tiers 1-3 >> >> Thanks > > The changes make sense and look good to me! Thanks for the review @matias9927 ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25538#issuecomment-2937940091 From syan at openjdk.org Wed Jun 4 01:37:23 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 4 Jun 2025 01:37:23 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v2] In-Reply-To: References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Tue, 3 Jun 2025 15:20:01 GMT, Matias Saavedra Silva wrote: >> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java line 29: >> >>> 27: * @summary Test Loading of default archives in all configurations >>> 28: * @requires vm.cds >>> 29: * @requires vm.cds.write.archived.java.heap >> >> Should we update the copyright year from `2024` to `2024, 2025` > > Do I need to update the Red Hat copyright as well? Maybe not need I think ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25591#discussion_r2125250303 From rkennke at openjdk.org Wed Jun 4 06:08:09 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 4 Jun 2025 06:08:09 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v3] In-Reply-To: References: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com> Message-ID: On Tue, 3 Jun 2025 20:56:00 GMT, David Holmes wrote: > I still find it an uninformative piece of documentation I'm afraid. It just begs the question "why isn't this on by default now?". The fact we haven't turned it on means we are still evaluating it. The move from experimental to product just means we are increasing the scope of the evaluation. I restored the explanatory paragraph with slightly rephrased wording, and also added a note about performance in the first part. I hope it's good now? Otherwise please suggest changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2938689671 From rkennke at openjdk.org Wed Jun 4 06:08:09 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 4 Jun 2025 06:08:09 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v4] In-Reply-To: References: Message-ID: > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Refine text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25491/files - new: https://git.openjdk.org/jdk/pull/25491/files/2e96057d..78ffb12a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25491&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25491&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25491/head:pull/25491 PR: https://git.openjdk.org/jdk/pull/25491 From duke at openjdk.org Wed Jun 4 10:57:47 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 4 Jun 2025 10:57:47 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v6] In-Reply-To: References: Message-ID: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8265754: Refactoring into separate file. - 8265754: Refactoring. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/425ec18e..93b87cfa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=04-05 Stats: 407 lines in 7 files changed: 229 ins; 168 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From duke at openjdk.org Wed Jun 4 11:04:28 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 4 Jun 2025 11:04:28 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v7] In-Reply-To: References: Message-ID: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8265754: Fixed typo. - 8265754: Fixing spaces. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/93b87cfa..4c984b2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=05-06 Stats: 7 lines in 3 files changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From cnorrbin at openjdk.org Wed Jun 4 11:33:03 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 4 Jun 2025 11:33:03 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data. > > The new parameters are: > > - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time. > > - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed. > > - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems. > > Testing: > - All container tests under `/test/hotspot/jtreg/containers/` > - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: update cpu usage to use >= Co-authored-by: Severin Gehwolf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25388/files - new: https://git.openjdk.org/jdk/pull/25388/files/cd113cba..878327c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25388&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25388&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25388/head:pull/25388 PR: https://git.openjdk.org/jdk/pull/25388 From cnorrbin at openjdk.org Wed Jun 4 11:33:03 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 4 Jun 2025 11:33:03 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:52:11 GMT, Severin Gehwolf wrote: > This looks fine to me. One suggestion as I think the cpu usage might be 0 and greater. Thank you for reviewing! Have changed the check to use `>=` instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25388#issuecomment-2939664463 From sgehwolf at openjdk.org Wed Jun 4 12:49:43 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 4 Jun 2025 12:49:43 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 11:33:03 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data. >> >> The new parameters are: >> >> - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time. >> >> - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed. >> >> - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems. >> >> Testing: >> - All container tests under `/test/hotspot/jtreg/containers/` >> - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > update cpu usage to use >= > > Co-authored-by: Severin Gehwolf Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25388#pullrequestreview-2896597343 From duke at openjdk.org Wed Jun 4 13:17:45 2025 From: duke at openjdk.org (snake66) Date: Wed, 4 Jun 2025 13:17:45 GMT Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64 Message-ID: This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp. ------------- Commit messages: - Add ucontext accessors for *BSD on Aarch64 - Remove unused define in os_bsd_aarch64.cpp Changes: https://git.openjdk.org/jdk/pull/25640/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25640&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358593 Stats: 29 lines in 1 file changed: 27 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25640.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25640/head:pull/25640 PR: https://git.openjdk.org/jdk/pull/25640 From matsaave at openjdk.org Wed Jun 4 14:19:00 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 4 Jun 2025 14:19:00 GMT Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless [v3] In-Reply-To: References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Tue, 3 Jun 2025 15:31:37 GMT, Matias Saavedra Silva wrote: >> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright Thank you for the reviews @sendaoYan, @lmesnik, @calvinccheung, and @stefank! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25591#issuecomment-2940210365 From matsaave at openjdk.org Wed Jun 4 14:19:02 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 4 Jun 2025 14:19:02 GMT Subject: Integrated: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com> Message-ID: On Mon, 2 Jun 2025 14:39:55 GMT, Matias Saavedra Silva wrote: > Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing. This pull request has now been integrated. Changeset: a2723d91 Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/a2723d91dfba2850e3070083fa94dc3fecc46a00 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless Reviewed-by: lmesnik, stefank, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/25591 From pavel.rappo at gmail.com Wed Jun 4 17:17:54 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 4 Jun 2025 18:17:54 +0100 Subject: Can nanoTime be non-monotonic? Message-ID: I was reading a book that refers to this 2015 post claiming that nanoTime can be non-monotonic: https://steveloughran.blogspot.com/2015/09/time-on-multi-core-multi-socket-servers.html In fact, I'm not sure what the claim actually is, as the author is a bit vague. It's unclear whether they say that they have actually observed it, or they just strongly suspect that it's possible. Has non-monotonicity ever been observed by hotspot developers? Can it be observed on a modern hardware + JVM? Thanks, -Pavel From pchilanomate at openjdk.org Wed Jun 4 20:02:56 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 4 Jun 2025 20:02:56 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> Message-ID: <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com> On Thu, 29 May 2025 07:28:11 GMT, David Holmes wrote: >> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: >> >> >> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: >> public static void main(String[] args) >> or a JavaFX application class must extend javafx.application.Application >> >> >> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses >> `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: >> >> >> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) >> at java.base/java.lang.Class.getMethod(Class.java:2166) >> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) >> >> >> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. >> >> Thanks, >> Patricio > > test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58: > >> 56: output.shouldNotContain("java.lang.ClassFormatError"); >> 57: output.shouldHaveExitValue(1); >> 58: if (Thread.currentThread().isVirtual()) { > > Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual. > > FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works. @dholmes-ora @lmesnik are you okay with my suggestion above? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2127344064 From darcy at openjdk.org Wed Jun 4 20:13:56 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 4 Jun 2025 20:13:56 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2897980100 From coleenp at openjdk.org Wed Jun 4 20:14:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 4 Jun 2025 20:14:52 GMT Subject: RFR: 8350029: Illegal invokespecial interface not caught by verification In-Reply-To: References: Message-ID: On Fri, 30 May 2025 06:31:43 GMT, David Holmes wrote: > As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check. > > The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering. > > Testing: > - new test case > - tiers 1-3 > > Thanks Looks good, apart from a couple of file format errors that jcheck doesn't apparently catch. test/hotspot/jtreg/runtime/verifier/invokespecial/UseInterfaceMethodRef.jasm line 37: > 35: return; > 36: } > 37: } end of file is funny here. test/hotspot/jtreg/runtime/verifier/invokespecial/UseMethodRef.jasm line 37: > 35: return; > 36: } > 37: } end of file also broken here. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25538#pullrequestreview-2897978478 PR Review Comment: https://git.openjdk.org/jdk/pull/25538#discussion_r2127359997 PR Review Comment: https://git.openjdk.org/jdk/pull/25538#discussion_r2127360392 From iris at openjdk.org Wed Jun 4 20:37:51 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 4 Jun 2025 20:37:51 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: <35K5iPJmI7-SaswDGvLtPKD87st1QJcFgfka38TsImQ=.b8f56c80-d2c6-4282-8b85-eca97880dfe0@github.com> On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898034878 From kcr at openjdk.org Wed Jun 4 20:37:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 20:37:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v6] In-Reply-To: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com> References: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com> Message-ID: <_Vfw9XCw0xZe8UevwOD5UOW4dZHoT2VzKC4_PT5nIGI=.9f6c8119-c437-49b1-90f5-740793992c20@github.com> On Tue, 3 Jun 2025 11:10:30 GMT, Nizar Benalla wrote: > I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind. What is your plan for addressing this? In its current state, that problem list entry will prevent integration. If you intend to integrate this PR with that test problem listed, you will need to file a new bug and use that bug ID in the problem list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2941383168 From kcr at openjdk.org Wed Jun 4 20:46:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 20:46:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 test/jdk/ProblemList.txt line 843: > 841: # jdk_since_checks > 842: > 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127408934 From dholmes at openjdk.org Wed Jun 4 21:13:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jun 2025 21:13:43 GMT Subject: RFR: 8350029: Illegal invokespecial interface not caught by verification [v2] In-Reply-To: References: Message-ID: > As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check. > > The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering. > > Testing: > - new test case > - tiers 1-3 > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix new-line at end-of-file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25538/files - new: https://git.openjdk.org/jdk/pull/25538/files/1540b0aa..d3f540cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25538&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25538&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25538/head:pull/25538 PR: https://git.openjdk.org/jdk/pull/25538 From dholmes at openjdk.org Wed Jun 4 21:13:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jun 2025 21:13:44 GMT Subject: RFR: 8350029: Illegal invokespecial interface not caught by verification [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 20:12:40 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix new-line at end-of-file > > Looks good, apart from a couple of file format errors that jcheck doesn't apparently catch. Thanks for the review @coleenp . I have fixed the new-line at end-of-file issue in the jasm files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25538#issuecomment-2941484385 From nbenalla at openjdk.org Wed Jun 4 21:36:52 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 4 Jun 2025 21:36:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 20:44:12 GMT, Kevin Rushforth wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge branch 'master' into jdk.8355746 >> - Problemlist JavaBaseCheckSince >> - Revert "feedback: never bump ASM version" >> >> This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. >> - Merge branch 'master' into jdk.8355746 >> - Merge branch 'master' into jdk.8355746 >> - Merge branch 'master' into jdk.8355746 >> - Update --release 25 symbol information for JDK 25 build 24 >> The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ >> - Merge branch 'master' into jdk.8355746 >> - problem list some failing tests >> - Merge branch 'master' into jdk.8355746 >> - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 > > test/jdk/ProblemList.txt line 843: > >> 841: # jdk_since_checks >> 842: >> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all > > You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list. Will update this in a couple of hours. Thanks Kevin. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127478174 From kcr at openjdk.org Wed Jun 4 21:51:52 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Jun 2025 21:51:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v7] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into jdk.8355746 > - Problemlist JavaBaseCheckSince > - Revert "feedback: never bump ASM version" > > This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496 test/jdk/ProblemList.txt line 843: > 841: # jdk_since_checks > 842: > 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all Suggestion: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8358627 generic-all @nizarbenalla Per our offline discussion, I created [JDK-8358627](https://bugs.openjdk.org/browse/JDK-8358627) to track this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127497730 From jaromir.hamala at gmail.com Wed Jun 4 22:16:01 2025 From: jaromir.hamala at gmail.com (Jaromir Hamala) Date: Thu, 5 Jun 2025 00:16:01 +0200 Subject: Can nanoTime be non-monotonic? In-Reply-To: References: Message-ID: A few years ago, I was wondering the same, so I did some research and wrote a blog: https://www.javaadvent.com/2019/12/measuring-time-from-java-to-kernel-and-back.html tl;dr: you should be good. tsc is sync'ed across cores since Nehalem On Wed, Jun 4, 2025 at 7:48?PM Pavel Rappo wrote: > I was reading a book that refers to this 2015 post claiming that > nanoTime can be non-monotonic: > > https://steveloughran.blogspot.com/2015/09/time-on-multi-core-multi-socket-servers.html > > In fact, I'm not sure what the claim actually is, as the author is a > bit vague. It's unclear whether they say that they have actually > observed it, or they just strongly suspect that it's possible. > > Has non-monotonicity ever been observed by hotspot developers? Can it > be observed on a modern hardware + JVM? > > Thanks, > -Pavel > -- ?Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.? Antoine de Saint Exup?ry -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleenp at openjdk.org Wed Jun 4 22:44:51 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 4 Jun 2025 22:44:51 GMT Subject: RFR: 8350029: Illegal invokespecial interface not caught by verification [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 21:13:43 GMT, David Holmes wrote: >> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check. >> >> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering. >> >> Testing: >> - new test case >> - tiers 1-3 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix new-line at end-of-file Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25538#pullrequestreview-2898283076 From nbenalla at openjdk.org Wed Jun 4 23:01:14 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 4 Jun 2025 23:01:14 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v8] In-Reply-To: References: Message-ID: <0wD_TZCgYfWRZurWBE_yoLoNtP7xlUUUPxJ3Stqi5Cs=.42b298e3-bbd7-4d9e-bdfd-ae9176ffc9b5@github.com> > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - use a different bug ID to problemlist `kevinrushforth ` - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Problemlist JavaBaseCheckSince - Revert "feedback: never bump ASM version" This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5. - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - ... and 12 more: https://git.openjdk.org/jdk/compare/5b27e9c2...09df3b66 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=07 Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Wed Jun 4 23:09:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 4 Jun 2025 23:09:08 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v9] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25008/files - new: https://git.openjdk.org/jdk/pull/25008/files/09df3b66..9929da7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From iris at openjdk.org Wed Jun 4 23:56:52 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 4 Jun 2025 23:56:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v9] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 23:09:08 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898378068 From dholmes at openjdk.org Thu Jun 5 00:38:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jun 2025 00:38:58 GMT Subject: Integrated: 8350029: Illegal invokespecial interface not caught by verification In-Reply-To: References: Message-ID: On Fri, 30 May 2025 06:31:43 GMT, David Holmes wrote: > As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check. > > The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering. > > Testing: > - new test case > - tiers 1-3 > > Thanks This pull request has now been integrated. Changeset: 8f8b367a Author: David Holmes URL: https://git.openjdk.org/jdk/commit/8f8b367ae3c9afca3581f6aced7f9855ef0d541d Stats: 263 lines in 8 files changed: 209 ins; 1 del; 53 mod 8350029: Illegal invokespecial interface not caught by verification Reviewed-by: coleenp, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/25538 From syan at openjdk.org Thu Jun 5 02:54:49 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 5 Jun 2025 02:54:49 GMT Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com> References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com> Message-ID: On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik wrote: > Test > scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797 > that causes test failure. > > The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. > I am removing it just to avoid spending time for anyone who can run test and observe this failure. Does this PR remove the file `test/hotspot/jtreg/applications/scimark/Scimark.java` or remove the directory `test/hotspot/jtreg/applications/scimark` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25316#issuecomment-2942579847 From dholmes at openjdk.org Thu Jun 5 03:52:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jun 2025 03:52:49 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com> Message-ID: On Wed, 4 Jun 2025 20:00:09 GMT, Patricio Chilano Mateo wrote: >> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58: >> >>> 56: output.shouldNotContain("java.lang.ClassFormatError"); >>> 57: output.shouldHaveExitValue(1); >>> 58: if (Thread.currentThread().isVirtual()) { >> >> Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual. >> >> FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works. > > @dholmes-ora @lmesnik are you okay with my suggestion above? As long as `command()` returns the information reliably (could it be set via an env-var instead?) then it seems reasonable to check the child process directly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2127883503 From pchilanomate at openjdk.org Thu Jun 5 04:43:47 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 5 Jun 2025 04:43:47 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: > Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: > > > Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: > public static void main(String[] args) > or a JavaFX application class must extend javafx.application.Application > > > The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses > `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: > > > [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) > at java.base/java.lang.Class.getMethod(Class.java:2166) > at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) > > > The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Check vthread case on child's VM command ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25509/files - new: https://git.openjdk.org/jdk/pull/25509/files/0c39d822..73c1ad2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25509&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25509&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25509/head:pull/25509 PR: https://git.openjdk.org/jdk/pull/25509 From pchilanomate at openjdk.org Thu Jun 5 04:43:48 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 5 Jun 2025 04:43:48 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com> Message-ID: <-5JjT6htJXex0OODLO0eVntppX-Vj5pEWU8Pvm4GoGA=.5eecb2d6-8566-4722-a56a-43eac62fb518@github.com> On Thu, 5 Jun 2025 03:50:29 GMT, David Holmes wrote: >> @dholmes-ora @lmesnik are you okay with my suggestion above? > > As long as `command()` returns the information reliably (could it be set via an env-var instead?) then it seems reasonable to check the child process directly. Yes, it?s the full command executed when running the child. If running with the main thread as virtual thread `-Dtest.thread.factory=Virtual` will be included in the command, as added by `ProcessTools.addTestThreadFactoryArgs`. In that case we run `ProcessTools.main` and pass the test name as argument. For this test `pb.command().toString()` would be something like: [/home/xyz/open/build/linux-x64/images/jdk/bin/java, -cp, ..., -Duser.language=en, -Duser.country=US, -Dtest.thread.factory=Virtual, jdk.test.lib.process.ProcessTools, Virtual, emptynumbootstrapmethods1] ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2127933457 From david.holmes at oracle.com Thu Jun 5 05:08:21 2025 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Jun 2025 15:08:21 +1000 Subject: Can nanoTime be non-monotonic? In-Reply-To: References: Message-ID: <25e92600-28f1-4678-9276-a09664dc6c69@oracle.com> Hi Pavel, On 5/06/2025 3:17 am, Pavel Rappo wrote: > I was reading a book that refers to this 2015 post claiming that > nanoTime can be non-monotonic: > https://steveloughran.blogspot.com/2015/09/time-on-multi-core-multi-socket-servers.html > > In fact, I'm not sure what the claim actually is, as the author is a > bit vague. It's unclear whether they say that they have actually > observed it, or they just strongly suspect that it's possible. The article is mainly referring to the unreliable use of the TSC for the nanoTime clock on x86 architecture. This has been mostly addressed at the hardware level with frequency-invariant TSC, better coordination across cores/processors etc. Though virtualization still messes things up from time to time. > Has non-monotonicity ever been observed by hotspot developers? Can it > be observed on a modern hardware + JVM? Yes it has been observed many times over the years on different OS, different hardware, and importantly different virtualization technologies. At different times all of the virtualization technologies have "broken" the system clocks in one way or another. Hotspot relies on the operating system to provide a well behaved clock source for nanoTime (and for other timing related functionality). Luckily for us the OS clock source support is much better today than 2015 (and much much better than in 2006 when I wrote my blog article on this topic :) [1] ), and the OS tends to deal with many (but not all virtualization issues). At different times we have had logic in hotspot to ensure that nanoTime (really the underlying javaTimeNanos in the VM) does not go backwards, but with poorly behaving clocks even that has issues as it can cause time to appear to freeze until we catch up. Currently only the implementation for macOS has a check to stop time from going backwards (I don't recall the history on that one). Cheers, David [1] https://web.archive.org/web/20160308031939/https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks > Thanks, > -Pavel From dholmes at openjdk.org Thu Jun 5 05:15:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jun 2025 05:15:57 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: >> >> >> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: >> public static void main(String[] args) >> or a JavaFX application class must extend javafx.application.Application >> >> >> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses >> `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: >> >> >> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) >> at java.base/java.lang.Class.getMethod(Class.java:2166) >> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) >> >> >> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Check vthread case on child's VM command This seems reasonable to me, but please confirm with @lmesnik that this property is actually set via the command-line args and not an environment variable (or other indirect means). Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2898895476 From duke at openjdk.org Thu Jun 5 07:49:37 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 5 Jun 2025 07:49:37 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v8] In-Reply-To: References: Message-ID: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov 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 25 additional commits since the last revision: - 8265754: Added a comment. - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Fixed build problem - 8265754: Fixed typo. - 8265754: Fixing spaces. - 8265754: Refactoring into separate file. - 8265754: Refactoring. - 8265754: Refactoring. - 8265754: Refactoring. - 8265754: Refactoring. - ... and 15 more: https://git.openjdk.org/jdk/compare/b18dbfea...c07b29ea ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/4c984b2e..c07b29ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=06-07 Stats: 18166 lines in 446 files changed: 15049 ins; 1382 del; 1735 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From mbaesken at openjdk.org Thu Jun 5 08:01:50 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Jun 2025 08:01:50 GMT Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too low values Message-ID: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> Currently os::Bsd::available_memory() returns on macOS `vmstat.free_count * os::vm_page_size();` But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories There is a bit of additional information here https://developer.apple.com/forums/thread/118867 that confirms that free memory / free_count is only a fraction of what is available. There is also some info here https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB containing this relevant info : "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them." and also about purgeable memory at https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1 ------------- Commit messages: - JDK-8357570 Changes: https://git.openjdk.org/jdk/pull/25657/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25657&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357570 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25657.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25657/head:pull/25657 PR: https://git.openjdk.org/jdk/pull/25657 From aph at openjdk.org Thu Jun 5 08:32:51 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 5 Jun 2025 08:32:51 GMT Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64 In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 12:58:57 GMT, snake66 wrote: > This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp. That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK. It's nice to see someone fixing things for BSD systems. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25640#pullrequestreview-2899355731 From duke at openjdk.org Thu Jun 5 08:48:37 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 5 Jun 2025 08:48:37 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v9] In-Reply-To: References: Message-ID: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8265754: Changed handshakee to target. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/c07b29ea..272b0293 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=07-08 Stats: 22 lines in 2 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From sspitsyn at openjdk.org Thu Jun 5 08:52:52 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 5 Jun 2025 08:52:52 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: >> >> >> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: >> public static void main(String[] args) >> or a JavaFX application class must extend javafx.application.Application >> >> >> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses >> `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: >> >> >> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) >> at java.base/java.lang.Class.getMethod(Class.java:2166) >> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) >> >> >> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Check vthread case on child's VM command Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2899415498 From duke at openjdk.org Thu Jun 5 09:25:35 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Thu, 5 Jun 2025 09:25:35 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens Message-ID: The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation. This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer. I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation. ------------- Commit messages: - Update test/lib/jdk/test/lib/process/OutputBuffer.java - Initial working solution Changes: https://git.openjdk.org/jdk/pull/25587/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25587&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356438 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25587.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25587/head:pull/25587 PR: https://git.openjdk.org/jdk/pull/25587 From liach at openjdk.org Thu Jun 5 09:25:35 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 5 Jun 2025 09:25:35 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 11:54:10 GMT, Alice Pellegrini wrote: > The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation. > This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer. > > I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation. test/lib/jdk/test/lib/process/OutputBuffer.java line 150: > 148: this.p = p; > 149: logProgress("Gathering output"); > 150: boolean verbose = Boolean.valueOf(System.getProperty("outputanalyzer.verbose", "false")); Suggestion: boolean verbose = Boolean.getBoolean("outputanalyzer.verbose"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2121483594 From duke at openjdk.org Thu Jun 5 09:36:37 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Thu, 5 Jun 2025 09:36:37 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: References: Message-ID: > The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation. > This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer. > > I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation. Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print - Update test/lib/jdk/test/lib/process/OutputBuffer.java Co-authored-by: Chen Liang - Initial working solution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25587/files - new: https://git.openjdk.org/jdk/pull/25587/files/db559d20..7cfbec22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25587&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25587&range=00-01 Stats: 20245 lines in 457 files changed: 17183 ins; 1318 del; 1744 mod Patch: https://git.openjdk.org/jdk/pull/25587.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25587/head:pull/25587 PR: https://git.openjdk.org/jdk/pull/25587 From duke at openjdk.org Thu Jun 5 09:43:50 2025 From: duke at openjdk.org (snake66) Date: Thu, 5 Jun 2025 09:43:50 GMT Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64 In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 08:30:27 GMT, Andrew Haley wrote: > That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK. Thanks a lot for the review! My main concern is to not break OSX at this point. > It's nice to see someone fixing things for BSD systems. It's part of a long journey, but hopefully we can get all the changes upstreamed at some point. This patch helps reduce the out-of-tree patches we have for now. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2943476942 From duke at openjdk.org Thu Jun 5 10:01:53 2025 From: duke at openjdk.org (duke) Date: Thu, 5 Jun 2025 10:01:53 GMT Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64 In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 12:58:57 GMT, snake66 wrote: > This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp. @snake66 Your change (at version c189e74c9bebc4f661572576e2f4d8d1035d8f76) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2943539159 From mli at openjdk.org Thu Jun 5 11:17:39 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 5 Jun 2025 11:17:39 GMT Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log message Message-ID: Hi, Can you help to review this patch? AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr" But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added. Some warning message above is: "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)" Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log. Thanks! ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/25658/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25658&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358685 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25658/head:pull/25658 PR: https://git.openjdk.org/jdk/pull/25658 From dholmes at openjdk.org Thu Jun 5 13:06:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jun 2025 13:06:55 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v4] In-Reply-To: References: Message-ID: <_vOTNksT3C8ub01teyiw4VhhxoqsVMZiwqKq4P13Qzw=.f347d3a2-0258-4487-b0f1-b620221523bc@github.com> On Wed, 4 Jun 2025 06:08:09 GMT, Roman Kennke wrote: >> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Refine text That works for me. Thanls. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2900253736 From dholmes at openjdk.org Thu Jun 5 13:13:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jun 2025 13:13:52 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: References: Message-ID: <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com> On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote: >> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation. >> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer. >> >> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation. > > Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print > - Update test/lib/jdk/test/lib/process/OutputBuffer.java > > Co-authored-by: Chen Liang > - Initial working solution I'm not sure I really understand the proposal here. To where is the output going "as it happens"? If you use OutputAnalyzer correctly then on failure all output to stdout and stderr is printed via reportDiagnosticSummary. Could you give a concrete example of a test with a problem and how this change fixes it? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2944254033 From duke at openjdk.org Thu Jun 5 13:51:50 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Thu, 5 Jun 2025 13:51:50 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com> References: <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com> Message-ID: On Thu, 5 Jun 2025 13:11:39 GMT, David Holmes wrote: > To where is the output going "as it happens"? If the `outputanalyzer.verbose` flag is set, the output is going to be printed to the console, in addition to being stored in the buffer > If you use OutputAnalyzer correctly then on failure all output to stdout and stderr is printed via reportDiagnosticSummary. Could you give a concrete example of a test with a problem and how this change fixes it? As far as I understand, the creator of the issue would like debugging to be easier; they'd like, while debugging (so having paused) the execution of a test, to be able to see the output of whatever tool is wrapper by `OutputBuffer` in the console, **before** hitting the failure, looking at the output so far in the console, while being able to examine the state of the program being debugged. As far as an example, I defer to the poster @mpdonova in case they have a more concrete example. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2944467386 From lmesnik at openjdk.org Thu Jun 5 14:57:52 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 5 Jun 2025 14:57:52 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: <0HEaPhtvRcMJovgWBGSV7ywLP5OHkDEakO9igLML18w=.a9252a57-0e68-4ab0-aba6-383f3154c6b5@github.com> On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: >> >> >> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: >> public static void main(String[] args) >> or a JavaFX application class must extend javafx.application.Application >> >> >> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses >> `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: >> >> >> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) >> at java.base/java.lang.Class.getMethod(Class.java:2166) >> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) >> >> >> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Check vthread case on child's VM command I think to add support in test library to find the mode. So I'll replace checks along the test code test.thread.factory with library method later. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2900688005 From mdonovan at openjdk.org Thu Jun 5 15:00:56 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 5 Jun 2025 15:00:56 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote: >> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation. >> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer. >> >> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation. > > Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print > - Update test/lib/jdk/test/lib/process/OutputBuffer.java > > Co-authored-by: Chen Liang > - Initial working solution test/lib/jdk/test/lib/process/OutputBuffer.java line 150: > 148: this.p = p; > 149: logProgress("Gathering output"); > 150: boolean verbose = Boolean.getBoolean("outputanalyzer.verbose"); Putting a system property at this level of the code kind of hides the functionality. An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2129066907 From rkennke at openjdk.org Thu Jun 5 15:02:01 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 5 Jun 2025 15:02:01 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v4] In-Reply-To: <_vOTNksT3C8ub01teyiw4VhhxoqsVMZiwqKq4P13Qzw=.f347d3a2-0258-4487-b0f1-b620221523bc@github.com> References: <_vOTNksT3C8ub01teyiw4VhhxoqsVMZiwqKq4P13Qzw=.f347d3a2-0258-4487-b0f1-b620221523bc@github.com> Message-ID: <8s3CRFAS0G2tc5ZdgefdjueZD_o6liZ3XiMBx0wT9AY=.86280e0d-a69d-4782-becf-65882e725bb8@github.com> On Thu, 5 Jun 2025 13:03:58 GMT, David Holmes wrote: > That works for me. Thanls. Great, thank you! @coleenp still good for you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2944897556 From pchilanomate at openjdk.org Thu Jun 5 15:04:56 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 5 Jun 2025 15:04:56 GMT Subject: Integrated: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: On Wed, 28 May 2025 19:31:17 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: > > > Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: > public static void main(String[] args) > or a JavaFX application class must extend javafx.application.Application > > > The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses > `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: > > > [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) > at java.base/java.lang.Class.getMethod(Class.java:2166) > at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) > > > The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. > > Thanks, > Patricio This pull request has now been integrated. Changeset: c59e44a7 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/c59e44a7aa2aeff0823830b698d524523b996650 Stats: 16 lines in 2 files changed: 12 ins; 3 del; 1 mod 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual Reviewed-by: lmesnik, dholmes, sspitsyn, syan ------------- PR: https://git.openjdk.org/jdk/pull/25509 From pchilanomate at openjdk.org Thu Jun 5 15:04:55 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 5 Jun 2025 15:04:55 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual [v2] In-Reply-To: References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: <9O0XROuy5gDTNkb4H_OpHLW4m1MHEKFZp-NVdd84K-w=.a22aff6c-bc37-4cd9-ba04-975605530453@github.com> On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: >> >> >> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: >> public static void main(String[] args) >> or a JavaFX application class must extend javafx.application.Application >> >> >> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses >> `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: >> >> >> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) >> at java.base/java.lang.Class.getMethod(Class.java:2166) >> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) >> >> >> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Check vthread case on child's VM command Thanks everyone for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25509#issuecomment-2944905681 From iklam at openjdk.org Thu Jun 5 15:13:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 5 Jun 2025 15:13:50 GMT Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log message In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 11:12:30 GMT, Hamlin Li wrote: > Hi, > > Can you help to review this patch? > AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr" > But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added. > > Some warning message above is: > "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)" > > Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly. > > Thanks! LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25658#pullrequestreview-2900745642 From shade at openjdk.org Thu Jun 5 15:50:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 5 Jun 2025 15:50:50 GMT Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log message In-Reply-To: References: Message-ID: <2PlHhIe5OhddHV69toGz4qQXy0le8k0lUtByf3q8pc0=.fd0d3689-3c0f-4474-aa6b-8187d28971a1@github.com> On Thu, 5 Jun 2025 11:12:30 GMT, Hamlin Li wrote: > Hi, > > Can you help to review this patch? > AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr" > But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added. > > Some warning message above is: > "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)" > > Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly. > > Thanks! Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25658#pullrequestreview-2900869160 From nbenalla at openjdk.org Thu Jun 5 16:03:58 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 5 Jun 2025 16:03:58 GMT Subject: Integrated: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: <-TeQIT9Gmt8CLUcMmPfOQzcPTIGyMpqqVsuEloBx6x8=.55986278-6168-4eff-9784-d91ed7768650@github.com> On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla wrote: > Get JDK 26 underway. This pull request has now been integrated. Changeset: af87035b Author: Nizar Benalla Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/af87035b713f8bfe05a007a4d4670cefc6a6aaf2 Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod 8355746: Start of release updates for JDK 26 8355748: Add SourceVersion.RELEASE_26 8355751: Add source 26 and target 26 to javac Co-authored-by: Joe Darcy Reviewed-by: iris, coleenp, darcy ------------- PR: https://git.openjdk.org/jdk/pull/25008 From iklam at openjdk.org Fri Jun 6 03:51:37 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 6 Jun 2025 03:51:37 GMT Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 Message-ID: CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js. ------------- Commit messages: - 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 Changes: https://git.openjdk.org/jdk/pull/25667/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25667&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357591 Stats: 72 lines in 34 files changed: 0 ins; 72 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25667/head:pull/25667 PR: https://git.openjdk.org/jdk/pull/25667 From duke at openjdk.org Fri Jun 6 08:20:00 2025 From: duke at openjdk.org (snake66) Date: Fri, 6 Jun 2025 08:20:00 GMT Subject: Integrated: 8358593: Add ucontext accessors for *BSD on Aarch64 In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 12:58:57 GMT, snake66 wrote: > This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp. This pull request has now been integrated. Changeset: 65fda5c0 Author: Harald Eilertsen Committer: Andrew Haley URL: https://git.openjdk.org/jdk/commit/65fda5c02aeb1832bc88dc83ee8465cd8ad89179 Stats: 29 lines in 1 file changed: 27 ins; 2 del; 0 mod 8358593: Add ucontext accessors for *BSD on Aarch64 Co-authored-by: Greg Lewis Co-authored-by: Kurt Miller Reviewed-by: aph ------------- PR: https://git.openjdk.org/jdk/pull/25640 From ktakakuri at openjdk.org Fri Jun 6 08:21:08 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Fri, 6 Jun 2025 08:21:08 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v8] In-Reply-To: References: Message-ID: > To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. > I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. > After this fix, I verified that the test passed. > > https://github.com/openjdk/jdk/pull/22142 > I refer to this fix. > tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. > > Thanks. Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23536/files - new: https://git.openjdk.org/jdk/pull/23536/files/b2d8284b..363c5a39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=06-07 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23536/head:pull/23536 PR: https://git.openjdk.org/jdk/pull/23536 From ktakakuri at openjdk.org Fri Jun 6 08:21:08 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Fri, 6 Jun 2025 08:21:08 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v7] In-Reply-To: References: <20TRpLYXGNXfc4ppAfGQysrYBJWBwV4iK4tPTk8MiTM=.08e71de3-4b53-4735-9742-9e87ef05bfa4@github.com> Message-ID: On Thu, 8 May 2025 10:35:22 GMT, David Holmes wrote: >> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: >> >> 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform > > test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 72: > >> 70: System.getenv("WINDIR") != null ? new File(System.getenv ("WINDIR")) : >> 71: null; >> 72: String systemDirW = new File(systemRoot, "System32").getPath(); > > If `SystemRoot` is null this will just throw `NullPointerException`. You should check for null and throw a more meaningful exception I'm sorry for being extremely late. According to the [API documentation](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#%3Cinit%3E(java.io.File,java.lang.String)) , it seems that NullPointerException is not thrown even if parent(systemRoot) is null. However, I believe that a null check is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2131740823 From clanger at openjdk.org Fri Jun 6 11:00:59 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 6 Jun 2025 11:00:59 GMT Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too low values In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> Message-ID: <-Xzby9ixx_ilXsC5VYTqrbG5XlLf9Ig7eH-JlZPpeoE=.33941345-7c45-4a63-bfff-a49e70d70f9b@github.com> On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken wrote: > Currently os::Bsd::available_memory() returns on macOS > `vmstat.free_count * os::vm_page_size();` > But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories > There is a bit of additional information here https://developer.apple.com/forums/thread/118867 > that confirms that free memory / free_count is only a fraction of what is available. > > There is also some info here > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB > containing this relevant info : > "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them." > > and also about purgeable memory at > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1 Looking at the linked documentation this seems to make sense, although I have no means to check plausibility. Maybe the comment before os::Bsd::available_memory could be modified/weakened a little bit because with the updated gathering it might be of some more use now... ? ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25657#pullrequestreview-2904580999 From mli at openjdk.org Fri Jun 6 14:01:54 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 6 Jun 2025 14:01:54 GMT Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log message In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 15:10:51 GMT, Ioi Lam wrote: >> Hi, >> >> Can you help to review this patch? >> AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr" >> But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added. >> >> Some warning message above is: >> "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)" >> >> Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly. >> >> Thanks! > > LGTM Thank you @iklam @shipilev for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25658#issuecomment-2949357340 From mli at openjdk.org Fri Jun 6 14:01:54 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 6 Jun 2025 14:01:54 GMT Subject: Integrated: 8358685: [TEST] AOTLoggingTag.java failed with missing log message In-Reply-To: References: Message-ID: <3pprVkm8iLcGVsPbUpeZr0O7qP-Jk6RhZwv9dPHNqqQ=.27ef010e-4f94-4e41-af10-e8eefca90450@github.com> On Thu, 5 Jun 2025 11:12:30 GMT, Hamlin Li wrote: > Hi, > > Can you help to review this patch? > AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr" > But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added. > > Some warning message above is: > "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)" > > Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly. > > Thanks! This pull request has now been integrated. Changeset: 9658cecd Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/9658cecde34a6e9cd39656d21a4ae8bc42da5956 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod 8358685: [TEST] AOTLoggingTag.java failed with missing log message Reviewed-by: iklam, shade ------------- PR: https://git.openjdk.org/jdk/pull/25658 From ccheung at openjdk.org Fri Jun 6 16:40:25 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 6 Jun 2025 16:40:25 GMT Subject: RFR: 8358799: Refactor os::jvm_path() Message-ID: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. Passed tiers 1 - 3 tests. However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. ------------- Commit messages: - 8358799: Refactor os::jvm_path() Changes: https://git.openjdk.org/jdk/pull/25675/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25675&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358799 Stats: 293 lines in 4 files changed: 82 ins; 211 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25675/head:pull/25675 PR: https://git.openjdk.org/jdk/pull/25675 From jiangli at openjdk.org Fri Jun 6 19:03:49 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 6 Jun 2025 19:03:49 GMT Subject: RFR: 8357632: CDS test failures on static JDK In-Reply-To: References: Message-ID: <6SqIq4AyBPM50gxQoPlquoIO89ydrBfnc_dfEStbcNk=.ff4fa1c3-c128-43a7-bf0e-0221c435dc8c@github.com> On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou wrote: > Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. > > The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. > > It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. > > Testing: > Tested the affected tests locally on static-jdk. > https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. Friendly ping, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2950258698 From ccheung at openjdk.org Fri Jun 6 19:25:53 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 6 Jun 2025 19:25:53 GMT Subject: RFR: 8357632: CDS test failures on static JDK In-Reply-To: References: Message-ID: On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou wrote: > Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. > > The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. > > It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. > > Testing: > Tested the affected tests locally on static-jdk. > https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. Looks good. Thanks! ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25516#pullrequestreview-2905953462 From duke at openjdk.org Fri Jun 6 20:48:01 2025 From: duke at openjdk.org (Mohamed Issa) Date: Fri, 6 Jun 2025 20:48:01 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic Message-ID: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags. ------------- Commit messages: - Fix assertion failures for libm math intrinsics that don't have shared runtime implementations Changes: https://git.openjdk.org/jdk/pull/25680/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358556 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25680/head:pull/25680 PR: https://git.openjdk.org/jdk/pull/25680 From duke at openjdk.org Fri Jun 6 20:48:01 2025 From: duke at openjdk.org (Mohamed Issa) Date: Fri, 6 Jun 2025 20:48:01 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Fri, 6 Jun 2025 20:40:49 GMT, Mohamed Issa wrote: > This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags. @dholmes-ora Does this fix the _-XX:-InlineIntrinsics_ assertion failures when running CubeRootTests.java and HyperbolicTests.java? I couldn't reproduce those, but I could reproduce the one with `java -XX:-UseLibmIntrinsic -version`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2950752859 From duke at openjdk.org Fri Jun 6 21:10:11 2025 From: duke at openjdk.org (Mohamed Issa) Date: Fri, 6 Jun 2025 21:10:11 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v2] In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: > This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags. Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Move UseLibmIntrinsic flag to x86 portion of code base to avoid build breaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25680/files - new: https://git.openjdk.org/jdk/pull/25680/files/21cda33d..c11f54e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=00-01 Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25680/head:pull/25680 PR: https://git.openjdk.org/jdk/pull/25680 From sviswanathan at openjdk.org Fri Jun 6 23:03:50 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 6 Jun 2025 23:03:50 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v2] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Fri, 6 Jun 2025 21:10:11 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Move UseLibmIntrinsic flag to x86 portion of code base to avoid build breaks src/hotspot/share/classfile/vmIntrinsics.cpp line 263: > 261: switch (id) { > 262: case vmIntrinsics::_dtanh: > 263: case vmIntrinsics::_dcbrt: You could also move _floatToFloat16 and _float16ToFloat to here from the switch below to make it consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133035942 From jiangli at openjdk.org Fri Jun 6 23:15:51 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 6 Jun 2025 23:15:51 GMT Subject: RFR: 8357632: CDS test failures on static JDK In-Reply-To: References: Message-ID: <8wttXy_J0jZpDKDEStSxXt1rNzBmkF8BAz9w_vix3pA=.c5a0fa63-ae0b-4d33-bc25-a2a9dc72b37b@github.com> On Fri, 6 Jun 2025 19:22:47 GMT, Calvin Cheung wrote: >> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. >> >> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. >> >> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. >> >> Testing: >> Tested the affected tests locally on static-jdk. >> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. > > Looks good. Thanks! @calvinccheung Thanks for the review! Can I have a second review for the PR, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2951175735 From duke at openjdk.org Fri Jun 6 23:33:05 2025 From: duke at openjdk.org (Mohamed Issa) Date: Fri, 6 Jun 2025 23:33:05 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v3] In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: > This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags. Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Re-structure logic to avoid reliance on UseLibmIntrinsic flag as others could be used later on ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25680/files - new: https://git.openjdk.org/jdk/pull/25680/files/c11f54e1..8dadb41c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=01-02 Stats: 35 lines in 2 files changed: 10 ins; 21 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25680/head:pull/25680 PR: https://git.openjdk.org/jdk/pull/25680 From duke at openjdk.org Fri Jun 6 23:33:05 2025 From: duke at openjdk.org (Mohamed Issa) Date: Fri, 6 Jun 2025 23:33:05 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v2] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Fri, 6 Jun 2025 22:58:24 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Move UseLibmIntrinsic flag to x86 portion of code base to avoid build breaks > > src/hotspot/share/classfile/vmIntrinsics.cpp line 263: > >> 261: switch (id) { >> 262: case vmIntrinsics::_dtanh: >> 263: case vmIntrinsics::_dcbrt: > > You could also move _floatToFloat16 and _float16ToFloat to here from the switch below to make it consistent. Ok, I moved them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133072865 From sviswanathan at openjdk.org Fri Jun 6 23:43:50 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 6 Jun 2025 23:43:50 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v3] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Fri, 6 Jun 2025 23:33:05 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Re-structure logic to avoid reliance on UseLibmIntrinsic flag as others could be used later on src/hotspot/share/classfile/vmIntrinsics.cpp line 319: > 317: case vmIntrinsics::_dtanh: > 318: case vmIntrinsics::_dcbrt: > 319: if (!InlineMathNatives) return true; Ah, looks like you missed !InlineIntrinsic check here: if (!InlineMathNatives || !InlineIntrinsics) return true; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133077192 From duke at openjdk.org Sat Jun 7 00:57:25 2025 From: duke at openjdk.org (Mohamed Issa) Date: Sat, 7 Jun 2025 00:57:25 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v4] In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: > This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Add extra check for InlineIntrinscs flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25680/files - new: https://git.openjdk.org/jdk/pull/25680/files/8dadb41c..b887243c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25680/head:pull/25680 PR: https://git.openjdk.org/jdk/pull/25680 From duke at openjdk.org Sat Jun 7 01:01:02 2025 From: duke at openjdk.org (Mohamed Issa) Date: Sat, 7 Jun 2025 01:01:02 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v3] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: <_Ymsgw5KNgELRZ3j9iH4ayCyVZn1O8erwAp20HuDs8Q=.a8c44f8e-5888-4f1a-9a74-c955cb7f508a@github.com> On Fri, 6 Jun 2025 23:41:27 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-structure logic to avoid reliance on UseLibmIntrinsic flag as others could be used later on > > src/hotspot/share/classfile/vmIntrinsics.cpp line 319: > >> 317: case vmIntrinsics::_dtanh: >> 318: case vmIntrinsics::_dcbrt: >> 319: if (!InlineMathNatives) return true; > > Ah, looks like you missed !InlineIntrinsic check here: > if (!InlineMathNatives || !InlineIntrinsics) return true; Yes, I was thinking to fall through to the cases below, but I missed the break statement. It's clearer with the extra check anyway, so I added it in now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133135956 From duke at openjdk.org Sun Jun 8 20:22:58 2025 From: duke at openjdk.org (snake66) Date: Sun, 8 Jun 2025 20:22:58 GMT Subject: RFR: 8358799: Refactor os::jvm_path() In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung wrote: > The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. > > Passed tiers 1 - 3 tests. > However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. Not a reviewer or anything, but I'm all for this change. It will help my BSD porting efforts as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25675#issuecomment-2954260065 From dholmes at openjdk.org Mon Jun 9 00:42:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 00:42:14 GMT Subject: RFR: 8355792: Remove expired flags in JDK 26 Message-ID: Please review these trivial start-of-release updates in relation to expired flags: - the expired flag table is updated to remove entries for expired flags (2 this time) - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) Thanks ------------- Commit messages: - 8355792: Remove expired flags in JDK 26 Changes: https://git.openjdk.org/jdk/pull/25686/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25686&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355792 Stats: 66 lines in 2 files changed: 2 ins; 63 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25686/head:pull/25686 PR: https://git.openjdk.org/jdk/pull/25686 From dholmes at openjdk.org Mon Jun 9 02:08:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 02:08:45 GMT Subject: RFR: 8346237: Obsolete the UseOprofile flag Message-ID: The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code. Testing: - tiers 1-3 sanity Thanks ------------- Commit messages: - 8346237: Obsolete the UseOprofile flag Changes: https://git.openjdk.org/jdk/pull/25687/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25687&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346237 Stats: 60 lines in 5 files changed: 3 ins; 55 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25687/head:pull/25687 PR: https://git.openjdk.org/jdk/pull/25687 From dholmes at openjdk.org Mon Jun 9 03:42:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 03:42:00 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v8] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 08:21:08 GMT, Kazuhisa Takakuri wrote: >> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. >> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. >> After this fix, I verified that the test passed. >> >> https://github.com/openjdk/jdk/pull/22142 >> I refer to this fix. >> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. >> >> Thanks. > > Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: > > 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform Thanks for update. Nothing further from me. As we are passed RDP1 this will get commited into JDK 26, but as a test fix it is also eligible to be backported to JDK 25 if you chose. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-2908848940 From dholmes at openjdk.org Mon Jun 9 04:06:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 04:06:55 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote: >> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation. >> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer. >> >> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation. > > Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print > - Update test/lib/jdk/test/lib/process/OutputBuffer.java > > Co-authored-by: Chen Liang > - Initial working solution Given jtreg buffers everything anyway, does this even help the outlined usecase? To be blunt if I were debugging the process launched via ProcessTools, I'd be doing that directly without jtreg and the test libraries getting in the way. That said the proposed change doesn't seem to cause any harm so I'm not totally against it. Just not sure how effective it actually is, nor the best way for the person running the test to turn it on. test/lib/jdk/test/lib/process/OutputBuffer.java line 150: > 148: this.p = p; > 149: logProgress("Gathering output"); > 150: boolean verbose = Boolean.getBoolean("outputanalyzer.verbose"); "verbose" is not really the right word here either. This does not change the amount of output only where it also gets sent to, and that is hard-wired to stdout/err so the name should reflect that e.g. `printToStdStreams` ? I'm not at all sure how to expose this to the top-level API's though. ------------- PR Review: https://git.openjdk.org/jdk/pull/25587#pullrequestreview-2908864741 PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2134992541 From dholmes at openjdk.org Mon Jun 9 04:06:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 04:06:56 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 14:58:40 GMT, Matthew Donovan wrote: >> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print >> - Update test/lib/jdk/test/lib/process/OutputBuffer.java >> >> Co-authored-by: Chen Liang >> - Initial working solution > > test/lib/jdk/test/lib/process/OutputBuffer.java line 150: > >> 148: this.p = p; >> 149: logProgress("Gathering output"); >> 150: boolean verbose = Boolean.getBoolean("outputanalyzer.verbose"); > > Putting a system property at this level of the code kind of hides the functionality. > > An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests. But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2134994847 From dholmes at openjdk.org Mon Jun 9 04:40:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 04:40:50 GMT Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam wrote: > CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js. LGTM Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25667#pullrequestreview-2908897771 From dholmes at openjdk.org Mon Jun 9 04:46:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 04:46:00 GMT Subject: RFR: 8357632: CDS test failures on static JDK In-Reply-To: References: Message-ID: On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou wrote: > Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. > > The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. > > It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. > > Testing: > Tested the affected tests locally on static-jdk. > https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. Seems reasonable. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25516#pullrequestreview-2908903210 From dholmes at openjdk.org Mon Jun 9 05:15:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 05:15:58 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Fri, 6 Jun 2025 20:45:32 GMT, Mohamed Issa wrote: > @dholmes-ora Does this fix the _-XX:-InlineIntrinsics_ assertion failures when running CubeRootTests.java and HyperbolicTests.java? I couldn't reproduce those, but I could reproduce the one with `java -XX:-UseLibmIntrinsic -version`. Yes it does - thanks. Though I'm still unclear why only a couple of these math intrinsics are affected by `-XX:-InineIntrinsics` ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2954654449 From dholmes at openjdk.org Mon Jun 9 05:18:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 05:18:54 GMT Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64 In-Reply-To: References: Message-ID: <-21kRnEDwCp11EeJB-9Qt_mYQjxJqQJSvNrQfUWZzps=.110eb6aa-521c-4d0b-b6e4-c91ed9a6be11@github.com> On Thu, 5 Jun 2025 09:41:04 GMT, snake66 wrote: >> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK. >> >> It's nice to see someone fixing things for BSD systems. > >> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK. > > Thanks a lot for the review! My main concern is to not break OSX at this point. > >> It's nice to see someone fixing things for BSD systems. > > It's part of a long journey, but hopefully we can get all the changes upstreamed at some point. This patch helps reduce the out-of-tree patches we have for now. :) @snake66 and @theRealAph please remember that non-trivial hotspot changes require two reviews. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2954659840 From dholmes at openjdk.org Mon Jun 9 05:35:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 05:35:51 GMT Subject: RFR: 8358799: Refactor os::jvm_path() In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung wrote: > The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. > > Passed tiers 1 - 3 tests. > However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. Good idea but I think we can go further. Thanks src/hotspot/os/posix/os_posix.cpp line 1099: > 1097: return; > 1098: } > 1099: #endif // AIX Given both chunks use `os::realpath` and otherwise only differ in error handling around `realpath`, I think you can reduce this further. E.g. something like char* fname; #ifdef AIX Dl_info dlinfo; int ret = dladdr(CAST_FROM_FN_PTR(void *, os::jvm_path), &dlinfo); assert(ret != 0, "cannot locate libjvm"); fname = dlinfo.dli_fname; #else char dli_fname[MAXPATHLEN]; dli_fname[0] = '\0'; bool ret = dll_address_to_library_name( CAST_FROM_FN_PTR(address, os::jvm_path), dli_fname, sizeof(dli_fname), nullptr); assert(ret, "cannot locate libjvm"); fname = dli_fname; #endif char* rp = nullprtr; ... I would also be asking the AIX folk if there is a reason they use `dladdr` directly instead of `os::dll_address_to_library_name`? ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25675#pullrequestreview-2908958390 PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2135057338 From duke at openjdk.org Mon Jun 9 06:43:01 2025 From: duke at openjdk.org (snake66) Date: Mon, 9 Jun 2025 06:43:01 GMT Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64 In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 09:41:04 GMT, snake66 wrote: >> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK. >> >> It's nice to see someone fixing things for BSD systems. > >> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK. > > Thanks a lot for the review! My main concern is to not break OSX at this point. > >> It's nice to see someone fixing things for BSD systems. > > It's part of a long journey, but hopefully we can get all the changes upstreamed at some point. This patch helps reduce the out-of-tree patches we have for now. :) > @snake66 and @theRealAph please remember that non-trivial hotspot changes require two reviews. Thanks. Aye, thanks for pointing that out. I'll remember next time! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2954821182 From duke at openjdk.org Mon Jun 9 06:48:49 2025 From: duke at openjdk.org (Mohamed Issa) Date: Mon, 9 Jun 2025 06:48:49 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: <8tX9TnkpkilsmgNU0JuZ6M7NP-4fuXlqeYKW2Vo8zAc=.10bf1eb8-667d-4402-854d-2e38fd94159b@github.com> On Mon, 9 Jun 2025 05:13:12 GMT, David Holmes wrote: > > @dholmes-ora Does this fix the _-XX:-InlineIntrinsics_ assertion failures when running CubeRootTests.java and HyperbolicTests.java? I couldn't reproduce those, but I could reproduce the one with `java -XX:-UseLibmIntrinsic -version`. > > Yes it does - thanks. Though I'm still unclear why only a couple of these math intrinsics are affected by `-XX:-InineIntrinsics` ?? The unaffected math intrinsics (_dsin_, _dcos_, _dexp_, ...) can fall back to alternate C++ implementations in the shared runtime when the stubs aren't generated by `-XX:-InlineIntrinsics` or `-XX:-UseLibmIntrinsic`. This isn't the case for the _dtanh_ and _dcbrt_ intrinsics. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2954835770 From aph at openjdk.org Mon Jun 9 09:13:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 9 Jun 2025 09:13:16 GMT Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64 In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 06:39:52 GMT, snake66 wrote: > > @snake66 and @theRealAph please remember that non-trivial hotspot changes require two reviews. Thanks. > > Aye, thanks for pointing that out. I'll remember next time! Was my fault, not yours. I suppose it wasn't quite trivial enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2955166351 From jsjolen at openjdk.org Mon Jun 9 10:06:50 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 9 Jun 2025 10:06:50 GMT Subject: RFR: 8358799: Refactor os::jvm_path() In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung wrote: > The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. > > Passed tiers 1 - 3 tests. > However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. src/hotspot/os/posix/os_posix.cpp line 1084: > 1082: assert(ret != 0, "cannot locate libjvm"); > 1083: char* rp = os::realpath((char *)dlinfo.dli_fname, buf, buflen); > 1084: assert(rp != nullptr, "error in realpath(): maybe the 'path' argument is too long?"); Pre-existing: We should return if `ret == 0` and `rp == nullptr`, not continue as if it didn't fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2135405198 From me at xdark.dev Sun Jun 8 18:29:33 2025 From: me at xdark.dev (me at xdark.dev) Date: Sun, 08 Jun 2025 21:29:33 +0300 Subject: AbstractInterpreter::is_not_reached wrongfully assumes reachability for invokedynamic Message-ID: <955a583d795914024aaa0d78ef35e274@xdark.dev> Greetings, Since JDK-8301995 [1], the code to in AbstractInterpreter::is_not_reached(...) for invokedynamic looks like this: ``` case Bytecodes::_invokedynamic: { assert(invoke_bc.has_index_u4(code), "sanity"); int method_index = invoke_bc.get_index_u4(code); return cpool->resolved_indy_entry_at(method_index)->is_resolved(); } ``` Is this a bug? Before the change, the code looked like this: ``` case Bytecodes::_invokedynamic: { assert(invoke_bc.has_index_u4(code), "sanity"); int method_index = invoke_bc.get_index_u4(code); return cpool->invokedynamic_cp_cache_entry_at(method_index)->is_f1_null(); } ``` The comment for this method says: ``` // Return true if the interpreter can prove that the given bytecode has // not yet been executed (in Java semantics, not in actual operation). ``` Shouldn't the is_resolved check be negated? The code is two years old since this change, and it seems like a regression. I'm unable to submit a patch if that is the case, so, if this is a bug, It would be great if someone would fix this. Thanks! Links: ------ [1] https://bugs.openjdk.org/browse/JDK-8301995 -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleenp at openjdk.org Mon Jun 9 11:54:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Jun 2025 11:54:49 GMT Subject: RFR: 8355792: Remove expired flags in JDK 26 In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 00:37:29 GMT, David Holmes wrote: > Please review these trivial start-of-release updates in relation to expired flags: > > - the flag table is updated to remove entries for expired flags (2 this time) > - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) > > Thanks Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25686#pullrequestreview-2909834539 From coleenp at openjdk.org Mon Jun 9 12:02:51 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Jun 2025 12:02:51 GMT Subject: RFR: 8346237: Obsolete the UseOprofile flag In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 02:03:37 GMT, David Holmes wrote: > The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code. > > Testing: > - tiers 1-3 sanity > > Thanks This comes from JDK-6265868. Nice to remove this. Looks like we obsoleted this code a long time ago. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25687#pullrequestreview-2909850997 From dholmes at openjdk.org Mon Jun 9 12:10:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 12:10:51 GMT Subject: RFR: 8346237: Obsolete the UseOprofile flag In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 11:59:44 GMT, Coleen Phillimore wrote: >> The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > This comes from JDK-6265868. Nice to remove this. Looks like we obsoleted this code a long time ago. Thanks for the review @coleenp ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25687#issuecomment-2955605247 From dholmes at openjdk.org Mon Jun 9 12:12:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 12:12:50 GMT Subject: RFR: 8355792: Remove expired flags in JDK 26 In-Reply-To: References: Message-ID: <0Tw0V0EDT1xcyI7lFEntJ7pswQxb_Uk7LKIhE1hBsSA=.88936a7c-e41f-4bb3-8d2e-b79bd4edb872@github.com> On Mon, 9 Jun 2025 11:51:52 GMT, Coleen Phillimore wrote: >> Please review these trivial start-of-release updates in relation to expired flags: >> >> - the flag table is updated to remove entries for expired flags (2 this time) >> - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) >> >> Thanks > > Looks good. Thanks for the review @coleenp ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25686#issuecomment-2955607760 From jsjolen at openjdk.org Mon Jun 9 14:05:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 9 Jun 2025 14:05:41 GMT Subject: RFR: 8355298: Increase timeout for StressAsyncUL Message-ID: Hi, Running async UL with stalling mode enabled is very slow if your buffer is very small. This turns out to become an issue on slow machines, where we run the risk of the test timing out. The ticket's suggestion (and title) is to increase the timeout. I think that it'd be fine to reduce the logging level to 'debug' instead, thus reducing the time required to run the test. Obviously, if we go with this solution then the ticket name and description must be adjusted. ------------- Commit messages: - Decrease number of logs Changes: https://git.openjdk.org/jdk/pull/25695/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25695&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355298 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25695/head:pull/25695 PR: https://git.openjdk.org/jdk/pull/25695 From kvn at openjdk.org Mon Jun 9 14:33:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 9 Jun 2025 14:33:53 GMT Subject: RFR: 8355792: Remove expired flags in JDK 26 In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 00:37:29 GMT, David Holmes wrote: > Please review these trivial start-of-release updates in relation to expired flags: > > - the flag table is updated to remove entries for expired flags (2 this time) > - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) > > Thanks Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25686#pullrequestreview-2910264916 From kvn at openjdk.org Mon Jun 9 14:35:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 9 Jun 2025 14:35:51 GMT Subject: RFR: 8346237: Obsolete the UseOprofile flag In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 02:03:37 GMT, David Holmes wrote: > The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code. > > Testing: > - tiers 1-3 sanity > > Thanks Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25687#pullrequestreview-2910271058 From jiangli at openjdk.org Mon Jun 9 16:11:03 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 9 Jun 2025 16:11:03 GMT Subject: RFR: 8357632: CDS test failures on static JDK In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 04:43:34 GMT, David Holmes wrote: >> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. >> >> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. >> >> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. >> >> Testing: >> Tested the affected tests locally on static-jdk. >> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. > > Seems reasonable. > > Thanks. @dholmes-ora Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2956240660 From jiangli at openjdk.org Mon Jun 9 16:11:03 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 9 Jun 2025 16:11:03 GMT Subject: Integrated: 8357632: CDS test failures on static JDK In-Reply-To: References: Message-ID: On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou wrote: > Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. > > The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. > > It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. > > Testing: > Tested the affected tests locally on static-jdk. > https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. This pull request has now been integrated. Changeset: cae1fd33 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/cae1fd3385e0635beeac34a2287627e556155783 Stats: 31 lines in 3 files changed: 17 ins; 13 del; 1 mod 8357632: CDS test failures on static JDK Reviewed-by: ccheung, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25516 From pchilanomate at openjdk.org Mon Jun 9 16:34:01 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 9 Jun 2025 16:34:01 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v9] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 08:48:37 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8265754: Changed handshakee to target. src/hotspot/share/runtime/handshake.hpp line 187: > 185: > 186: bool suspend(bool register_vthread_SR); > 187: bool resume(bool register_vthread_SR); We should also remove the class and friend declarations for `ThreadSelfSuspensionHandshake` and `SuspendThreadHandshake`. src/hotspot/share/runtime/suspendResumeManager.hpp line 27: > 25: #ifndef SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP > 26: #define SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP > 27: We need to add `class SuspendThreadHandshake;` and `class ThreadSelfSuspensionHandshake;` here (currently relying on the declarations in handshake.hpp). src/hotspot/share/runtime/suspendResumeManager.hpp line 37: > 35: > 36: public: > 37: SuspendResumeManager(JavaThread* thread, Monitor* state_lock); Maybe this should also be private given that `JavaThread` is a friend already? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2136016839 PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2136025270 PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2136029358 From kvn at openjdk.org Mon Jun 9 16:55:52 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 9 Jun 2025 16:55:52 GMT Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam wrote: > CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js. Fix it here too (used by aotCode/ tests) https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482 ------------- PR Review: https://git.openjdk.org/jdk/pull/25667#pullrequestreview-2910657100 From kvn at openjdk.org Mon Jun 9 17:01:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 9 Jun 2025 17:01:54 GMT Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam wrote: > CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25667#pullrequestreview-2910668967 From kvn at openjdk.org Mon Jun 9 17:01:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 9 Jun 2025 17:01:55 GMT Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 16:53:38 GMT, Vladimir Kozlov wrote: > Fix it here too (used by aotCode/ tests) https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482 Actually no. We do not want to run these tests with Graal for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25667#issuecomment-2956365431 From ihse at openjdk.org Mon Jun 9 17:50:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 17:50:52 GMT Subject: RFR: 8358799: Refactor os::jvm_path() In-Reply-To: References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Mon, 9 Jun 2025 05:33:14 GMT, David Holmes wrote: >> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. >> >> Passed tiers 1 - 3 tests. >> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. > > src/hotspot/os/posix/os_posix.cpp line 1099: > >> 1097: return; >> 1098: } >> 1099: #endif // AIX > > Given both chunks use `os::realpath` and otherwise only differ in error handling around `realpath`, I think you can reduce this further. E.g. something like > > char* fname; > #ifdef AIX > Dl_info dlinfo; > int ret = dladdr(CAST_FROM_FN_PTR(void *, os::jvm_path), &dlinfo); > assert(ret != 0, "cannot locate libjvm"); > fname = dlinfo.dli_fname; > #else > char dli_fname[MAXPATHLEN]; > dli_fname[0] = '\0'; > bool ret = dll_address_to_library_name( > CAST_FROM_FN_PTR(address, os::jvm_path), > dli_fname, sizeof(dli_fname), nullptr); > assert(ret, "cannot locate libjvm"); > fname = dli_fname; > #endif > char* rp = nullprtr; > ... > > > I would also be asking the AIX folk if there is a reason they use `dladdr` directly instead of `os::dll_address_to_library_name`? AIX is very different in this regard. There is a hand-crafted partial implementation of `dladdr` in `src/hotspot/os/aix/porting_aix.cpp`. I'm not sure this is the reason, just pointing out that this is a typical weakness of AIX where it differs from other unix systems wrt to `dladdr`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2136188895 From sviswanathan at openjdk.org Mon Jun 9 18:34:52 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 9 Jun 2025 18:34:52 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v4] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Sat, 7 Jun 2025 00:57:25 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Add extra check for InlineIntrinscs flag src/hotspot/share/classfile/vmIntrinsics.cpp line 319: > 317: case vmIntrinsics::_dtanh: > 318: case vmIntrinsics::_dcbrt: > 319: if (!InlineMathNatives || !InlineIntrinsics) return true; You also need to add check for UseLibmIntrinsic here: #ifdef AMD64 if (!UseLibmIntrinsic) return true; #endif ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2136250496 From duke at openjdk.org Mon Jun 9 20:42:55 2025 From: duke at openjdk.org (Mohamed Issa) Date: Mon, 9 Jun 2025 20:42:55 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v5] In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: > This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Include check for UseLibmIntrinsic flag but restrict to x86 platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25680/files - new: https://git.openjdk.org/jdk/pull/25680/files/b887243c..aff9ca09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=03-04 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25680/head:pull/25680 PR: https://git.openjdk.org/jdk/pull/25680 From duke at openjdk.org Mon Jun 9 20:42:56 2025 From: duke at openjdk.org (Mohamed Issa) Date: Mon, 9 Jun 2025 20:42:56 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v4] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Mon, 9 Jun 2025 18:31:47 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Add extra check for InlineIntrinscs flag > > src/hotspot/share/classfile/vmIntrinsics.cpp line 319: > >> 317: case vmIntrinsics::_dtanh: >> 318: case vmIntrinsics::_dcbrt: >> 319: if (!InlineMathNatives || !InlineIntrinsics) return true; > > You also need to add check for UseLibmIntrinsic here: > #ifdef AMD64 > if (!UseLibmIntrinsic) return true; > #endif Added ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2136471294 From sviswanathan at openjdk.org Mon Jun 9 20:49:32 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 9 Jun 2025 20:49:32 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v5] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Mon, 9 Jun 2025 20:42:55 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Include check for UseLibmIntrinsic flag but restrict to x86 platforms Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25680#pullrequestreview-2911328752 From dholmes at openjdk.org Mon Jun 9 21:01:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 21:01:44 GMT Subject: RFR: 8346237: Obsolete the UseOprofile flag In-Reply-To: References: Message-ID: <7cX6wNSS_ze3bSOXL22dFH1o0EnIkJ8jw6w2sAUBEdc=.e795a413-7cc5-452e-9427-5ad045c13bca@github.com> On Mon, 9 Jun 2025 14:33:27 GMT, Vladimir Kozlov wrote: >> The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > Good. Thanks for the review @vnkozlov ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25687#issuecomment-2957019040 From dholmes at openjdk.org Mon Jun 9 21:01:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 21:01:32 GMT Subject: RFR: 8355792: Remove expired flags in JDK 26 In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 14:31:34 GMT, Vladimir Kozlov wrote: >> Please review these trivial start-of-release updates in relation to expired flags: >> >> - the flag table is updated to remove entries for expired flags (2 this time) >> - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) >> >> Thanks > > Good. Thanks for the review @vnkozlov ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25686#issuecomment-2957020476 From dholmes at openjdk.org Mon Jun 9 21:01:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 21:01:44 GMT Subject: Integrated: 8346237: Obsolete the UseOprofile flag In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 02:03:37 GMT, David Holmes wrote: > The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code. > > Testing: > - tiers 1-3 sanity > > Thanks This pull request has now been integrated. Changeset: ef45c815 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/ef45c8154cea2ec910788d3c19e91d3eed75708e Stats: 60 lines in 5 files changed: 3 ins; 55 del; 2 mod 8346237: Obsolete the UseOprofile flag Reviewed-by: coleenp, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25687 From dholmes at openjdk.org Mon Jun 9 21:10:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 21:10:48 GMT Subject: RFR: 8355792: Remove expired flags in JDK 26 [v2] In-Reply-To: References: Message-ID: > Please review these trivial start-of-release updates in relation to expired flags: > > - the flag table is updated to remove entries for expired flags (2 this time) > - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) > > Thanks David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8355792-expired-flags - 8355792: Remove expired flags in JDK 26 ------------- Changes: https://git.openjdk.org/jdk/pull/25686/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25686&range=01 Stats: 68 lines in 2 files changed: 2 ins; 65 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25686/head:pull/25686 PR: https://git.openjdk.org/jdk/pull/25686 From iklam at openjdk.org Mon Jun 9 21:57:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 9 Jun 2025 21:57:31 GMT Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 16:58:08 GMT, Vladimir Kozlov wrote: >> Fix it here too (used by aotCode/ tests) >> https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482 > >> Fix it here too (used by aotCode/ tests) https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482 > > Actually no. We do not want to run these tests with Graal for now. Thanks @vnkozlov @dholmes-ora for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25667#issuecomment-2957123781 From iklam at openjdk.org Mon Jun 9 21:57:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 9 Jun 2025 21:57:32 GMT Subject: Integrated: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam wrote: > CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js. This pull request has now been integrated. Changeset: d186dacd Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/d186dacdb7b91dc9a28b703ce3c8ea007fc450b6 Stats: 72 lines in 34 files changed: 0 ins; 72 del; 0 mod 8357591: Re-enable CDS test cases for jvmci after JDK-8345826 Reviewed-by: dholmes, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25667 From coleenp at openjdk.org Mon Jun 9 22:14:33 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Jun 2025 22:14:33 GMT Subject: RFR: 8355792: Remove expired flags in JDK 26 [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 21:10:48 GMT, David Holmes wrote: >> Please review these trivial start-of-release updates in relation to expired flags: >> >> - the flag table is updated to remove entries for expired flags (2 this time) >> - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into 8355792-expired-flags > - 8355792: Remove expired flags in JDK 26 Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25686#pullrequestreview-2911478853 From dholmes at openjdk.org Mon Jun 9 22:28:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jun 2025 22:28:32 GMT Subject: Integrated: 8355792: Remove expired flags in JDK 26 In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 00:37:29 GMT, David Holmes wrote: > Please review these trivial start-of-release updates in relation to expired flags: > > - the flag table is updated to remove entries for expired flags (2 this time) > - the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26) > > Thanks This pull request has now been integrated. Changeset: bcf86070 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/bcf860703dc0244fef1d380cb7323282de76970c Stats: 68 lines in 2 files changed: 2 ins; 65 del; 1 mod 8355792: Remove expired flags in JDK 26 Reviewed-by: coleenp, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25686 From syan at openjdk.org Tue Jun 10 00:41:37 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 10 Jun 2025 00:41:37 GMT Subject: RFR: 8358799: Refactor os::jvm_path() [v2] In-Reply-To: References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Mon, 9 Jun 2025 19:01:57 GMT, Calvin Cheung wrote: >> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. >> >> Passed tiers 1 - 3 tests. >> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. > > Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review comments from @dholmes-ora and @jdksjolen > - Merge branch 'master' into 8358799-refactor-jvm-path > - 8358799: Refactor os::jvm_path() src/hotspot/os/posix/os_posix.cpp line 1071: > 1069: assert(false, "must use a large-enough buffer"); > 1070: buf[0] = '\0'; > 1071: return; Do we need release the memory of `buf` before return, such like free(buf); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2136714406 From duke at openjdk.org Tue Jun 10 00:53:23 2025 From: duke at openjdk.org (Mohamed Issa) Date: Tue, 10 Jun 2025 00:53:23 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6] In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: > This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25680/files - new: https://git.openjdk.org/jdk/pull/25680/files/aff9ca09..fa21605f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25680&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25680.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25680/head:pull/25680 PR: https://git.openjdk.org/jdk/pull/25680 From ccheung at openjdk.org Tue Jun 10 01:31:31 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 10 Jun 2025 01:31:31 GMT Subject: RFR: 8358799: Refactor os::jvm_path() [v2] In-Reply-To: References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Tue, 10 Jun 2025 00:39:06 GMT, SendaoYan wrote: >> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - review comments from @dholmes-ora and @jdksjolen >> - Merge branch 'master' into 8358799-refactor-jvm-path >> - 8358799: Refactor os::jvm_path() > > src/hotspot/os/posix/os_posix.cpp line 1071: > >> 1069: assert(false, "must use a large-enough buffer"); >> 1070: buf[0] = '\0'; >> 1071: return; > > Do we need release the memory of `buf` before return, such like > > > free(buf); No, because the caller of the function still references `buf` after the function returns, e.g. in `os::init_system_properties_values()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2136751058 From duke at openjdk.org Tue Jun 10 03:54:27 2025 From: duke at openjdk.org (Mohamed Issa) Date: Tue, 10 Jun 2025 03:54:27 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v5] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Mon, 9 Jun 2025 20:47:01 GMT, Sandhya Viswanathan wrote: > Looks good to me. @sviswa7 I had to make some more changes to cover the _linux-x64-hs-zero_ build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2957600031 From duke at openjdk.org Tue Jun 10 07:43:28 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 10 Jun 2025 07:43:28 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v10] In-Reply-To: References: Message-ID: <34u9bhO_tpy_1IsaqU5VsoKbD7M3nFt9HsKuO3fW_8E=.8c5ce31c-0015-44c6-897a-b73339b332cb@github.com> > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov 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 27 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Changed handshakee to target. - 8265754: Added a comment. - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Fixed build problem - 8265754: Fixed typo. - 8265754: Fixing spaces. - 8265754: Refactoring into separate file. - 8265754: Refactoring. - 8265754: Refactoring. - ... and 17 more: https://git.openjdk.org/jdk/compare/d5575c1a...8d24cd75 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/272b0293..8d24cd75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=08-09 Stats: 11155 lines in 390 files changed: 7807 ins; 2524 del; 824 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From duke at openjdk.org Tue Jun 10 07:52:29 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Tue, 10 Jun 2025 07:52:29 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: References: Message-ID: <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com> On Mon, 9 Jun 2025 04:03:28 GMT, David Holmes wrote: >> test/lib/jdk/test/lib/process/OutputBuffer.java line 150: >> >>> 148: this.p = p; >>> 149: logProgress("Gathering output"); >>> 150: boolean verbose = Boolean.getBoolean("outputanalyzer.verbose"); >> >> Putting a system property at this level of the code kind of hides the functionality. >> >> An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests. > > But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ?? To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command)` git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l 351 Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about) I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2137161838 From cstein at openjdk.org Tue Jun 10 08:18:34 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 10 Jun 2025 08:18:34 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment In-Reply-To: <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com> References: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com> <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com> Message-ID: On Mon, 2 Jun 2025 16:03:49 GMT, Christian Stein wrote: >> right I agree that if there is common code we should extract it in a helper method > > Or the handling of `#` can be merged with the previous case ... somehow. Extracting a method wouldn't really simplify the code, as many local variables are in play. Merging the cases also ends up in more if-else constructs in the case block that counter-act readability. So, perhaps, the duplication is goog-enough here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2137227216 From duke at openjdk.org Tue Jun 10 08:40:53 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 10 Jun 2025 08:40:53 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: References: Message-ID: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8265754: Addressed reviewers comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/8d24cd75..1d34f5ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=09-10 Stats: 9 lines in 2 files changed: 3 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From duke at openjdk.org Tue Jun 10 08:40:53 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 10 Jun 2025 08:40:53 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 16:13:18 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265754: Addressed reviewers comments. > > src/hotspot/share/runtime/handshake.hpp line 187: > >> 185: >> 186: bool suspend(bool register_vthread_SR); >> 187: bool resume(bool register_vthread_SR); > > We should also remove the class and friend declarations for `ThreadSelfSuspensionHandshake` > and `SuspendThreadHandshake`. Right, those classes now have nothing to do with this file. Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2137276716 From duke at openjdk.org Tue Jun 10 08:40:53 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 10 Jun 2025 08:40:53 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v9] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 16:18:42 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265754: Changed handshakee to target. > > src/hotspot/share/runtime/suspendResumeManager.hpp line 27: > >> 25: #ifndef SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP >> 26: #define SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP >> 27: > > We need to add `class SuspendThreadHandshake;` and `class ThreadSelfSuspensionHandshake;` here (currently relying on the declarations in handshake.hpp). Addressed in the latest commit. > src/hotspot/share/runtime/suspendResumeManager.hpp line 37: > >> 35: >> 36: public: >> 37: SuspendResumeManager(JavaThread* thread, Monitor* state_lock); > > Maybe this should also be private given that `JavaThread` is a friend already? Makes sense. Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2137277127 PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2137277820 From azafari at openjdk.org Tue Jun 10 11:29:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 10 Jun 2025 11:29:42 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly Message-ID: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> The problem here stems from the following facts: 1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. 2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order. 3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above. So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue). Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings. Tests: linux-x64: runtime/NMT jtreg tests passed linux-aarch64: tier1 to tier3 passed ------------- Commit messages: - 8356228: NMT does not record reserved memory base address correctly Changes: https://git.openjdk.org/jdk/pull/25719/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25719&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356228 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25719/head:pull/25719 PR: https://git.openjdk.org/jdk/pull/25719 From dholmes at openjdk.org Tue Jun 10 12:08:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jun 2025 12:08:32 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> References: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> Message-ID: On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8265754: Addressed reviewers comments. I am okay with this refactoring. I will let you and Patricio iron out any further wrinkles. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2913266110 From cnorrbin at openjdk.org Tue Jun 10 12:39:38 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 10 Jun 2025 12:39:38 GMT Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code Message-ID: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> Hi everyone, #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function. ------------- Commit messages: - Remove PerfDataSamplingInterval constraint check Changes: https://git.openjdk.org/jdk/pull/25722/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25722&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358891 Stats: 13 lines in 2 files changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25722.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25722/head:pull/25722 PR: https://git.openjdk.org/jdk/pull/25722 From dholmes at openjdk.org Tue Jun 10 13:01:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jun 2025 13:01:29 GMT Subject: RFR: 8358799: Refactor os::jvm_path() [v2] In-Reply-To: References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Tue, 10 Jun 2025 01:29:06 GMT, Calvin Cheung wrote: >> src/hotspot/os/posix/os_posix.cpp line 1071: >> >>> 1069: assert(false, "must use a large-enough buffer"); >>> 1070: buf[0] = '\0'; >>> 1071: return; >> >> Do we need release the memory of `buf` before return, such like >> >> >> free(buf); > > No, because the caller of the function still references `buf` after the function returns, e.g. in `os::init_system_properties_values()`. More specifically, `buf` is owned by the caller and we have no idea what it is so we have no business "releasing" it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2137839159 From coleenp at openjdk.org Tue Jun 10 13:04:13 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 10 Jun 2025 13:04:13 GMT Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace' Message-ID: Make the fatal error a log warning and return. The metaspace commit accounting is done after this return. Tested with this always returning here, and it seems okay. Tested with this change tier 1-4 and 8. ------------- Commit messages: - 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace' Changes: https://git.openjdk.org/jdk/pull/25720/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25720&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357662 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25720.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25720/head:pull/25720 PR: https://git.openjdk.org/jdk/pull/25720 From dholmes at openjdk.org Tue Jun 10 13:04:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Jun 2025 13:04:32 GMT Subject: RFR: 8358799: Refactor os::jvm_path() [v2] In-Reply-To: References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Mon, 9 Jun 2025 19:01:57 GMT, Calvin Cheung wrote: >> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. >> >> Passed tiers 1 - 3 tests. >> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. > > Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review comments from @dholmes-ora and @jdksjolen > - Merge branch 'master' into 8358799-refactor-jvm-path > - 8358799: Refactor os::jvm_path() I'd still like some input from AIX folk on whether we can do better here, but in lieu of that this seems good enough to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25675#pullrequestreview-2913479876 From pchilanomate at openjdk.org Tue Jun 10 15:35:32 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 10 Jun 2025 15:35:32 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> References: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> Message-ID: On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8265754: Addressed reviewers comments. Looks good to me, thanks! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2914125850 From sviswanathan at openjdk.org Tue Jun 10 15:49:30 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 10 Jun 2025 15:49:30 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: <5nYyGDNyp9M_8i6SrURSf4kfyrxQLu6Ct6Av7RgAKqA=.a8df5cd6-ad3c-4045-ab7b-9839be52c670@github.com> On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail Changes look good. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25680#pullrequestreview-2914172623 From jsjolen at openjdk.org Tue Jun 10 16:06:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 10 Jun 2025 16:06:30 GMT Subject: RFR: 8358799: Refactor os::jvm_path() [v2] In-Reply-To: References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: <-USP59DTPiIjC9kWa0lNg2tiS7oFP6omWyC4u9y_nS0=.ceabe825-5d31-4714-8d2b-814a9efbd14f@github.com> On Mon, 9 Jun 2025 19:01:57 GMT, Calvin Cheung wrote: >> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. >> >> Passed tiers 1 - 3 tests. >> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. > > Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review comments from @dholmes-ora and @jdksjolen > - Merge branch 'master' into 8358799-refactor-jvm-path > - 8358799: Refactor os::jvm_path() I'm also OK with this. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25675#pullrequestreview-2914232919 From ccheung at openjdk.org Tue Jun 10 16:23:37 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 10 Jun 2025 16:23:37 GMT Subject: RFR: 8358799: Refactor os::jvm_path() [v2] In-Reply-To: References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: On Tue, 10 Jun 2025 13:01:33 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - review comments from @dholmes-ora and @jdksjolen >> - Merge branch 'master' into 8358799-refactor-jvm-path >> - 8358799: Refactor os::jvm_path() > > I'd still like some input from AIX folk on whether we can do better here, but in lieu of that this seems good enough to me. > > Thanks Thanks @dholmes-ora @jdksjolen for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25675#issuecomment-2959903451 From ccheung at openjdk.org Tue Jun 10 16:23:38 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 10 Jun 2025 16:23:38 GMT Subject: Integrated: 8358799: Refactor os::jvm_path() In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com> Message-ID: <3nE5B4ckBR8GX_pj1TrWnWTVz_R6Oa_2J-wuUmimUwo=.47ed92c3-ddda-4fe6-a0a5-840d4c341170@github.com> On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung wrote: > The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp. > > Passed tiers 1 - 3 tests. > However, tests were not run on the aix platform since it is not one of the Oracle supported platforms. This pull request has now been integrated. Changeset: 500a3a2d Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/500a3a2d0af0a3f7cf58b909bbbc2aa25926d8b4 Stats: 300 lines in 4 files changed: 89 ins; 211 del; 0 mod 8358799: Refactor os::jvm_path() Reviewed-by: dholmes, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/25675 From kvn at openjdk.org Tue Jun 10 16:36:30 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 10 Jun 2025 16:36:30 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail Please, do not push until we review and test it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2959932766 From sviswanathan at openjdk.org Tue Jun 10 16:36:30 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 10 Jun 2025 16:36:30 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Tue, 10 Jun 2025 16:31:23 GMT, Vladimir Kozlov wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail > > Please, do not push until we review and test it. Thanks @vnkozlov, we will look forward to your testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2959937875 From kvn at openjdk.org Tue Jun 10 17:01:31 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 10 Jun 2025 17:01:31 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail I submitted testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2960000360 From mdoerr at openjdk.org Tue Jun 10 18:57:02 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 10 Jun 2025 18:57:02 GMT Subject: RFR: 8359165: AIX build broken after 8358799 Message-ID: This fixes the build. ------------- Commit messages: - 8359165: AIX build broken after 8358799 Changes: https://git.openjdk.org/jdk/pull/25734/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25734&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359165 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25734/head:pull/25734 PR: https://git.openjdk.org/jdk/pull/25734 From mdoerr at openjdk.org Tue Jun 10 18:57:02 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 10 Jun 2025 18:57:02 GMT Subject: RFR: 8359165: AIX build broken after 8358799 In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 18:52:16 GMT, Martin Doerr wrote: > This fixes the build. @JoKern65: Please check if the code is still correct after https://github.com/openjdk/jdk/commit/500a3a2d0af0a3f7cf58b909bbbc2aa25926d8b4. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25734#issuecomment-2960290542 From gziemski at openjdk.org Tue Jun 10 19:05:39 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 10 Jun 2025 19:05:39 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v35] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 10:18:47 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > invalid -> release. LGTM, thanks for your patience and all the work! ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2914760453 From mdoerr at openjdk.org Tue Jun 10 19:23:30 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 10 Jun 2025 19:23:30 GMT Subject: RFR: 8359165: AIX build broken after 8358799 In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 18:52:16 GMT, Martin Doerr wrote: > This fixes the build. @varada1110: You may as well want to take a look if the refactored code is still correct. (This PR is a P1 build fix.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25734#issuecomment-2960352222 From mdoerr at openjdk.org Tue Jun 10 19:46:10 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 10 Jun 2025 19:46:10 GMT Subject: RFR: 8359165: AIX build broken after 8358799 [v2] In-Reply-To: References: Message-ID: > This fixes the build. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Improve constness. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25734/files - new: https://git.openjdk.org/jdk/pull/25734/files/3bcb5277..667d307a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25734&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25734&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25734/head:pull/25734 PR: https://git.openjdk.org/jdk/pull/25734 From gziemski at openjdk.org Tue Jun 10 19:52:27 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 10 Jun 2025 19:52:27 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly In-Reply-To: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> Message-ID: <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com> On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari wrote: > The problem here stems from the following facts: > 1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. > 2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order. > 3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above. > > So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue). > > Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings. > > Tests: > linux-x64: runtime/NMT jtreg tests passed > linux-aarch64: tier1 to tier3 passed src/hotspot/share/cds/archiveBuilder.cpp line 346: > 344: // During an aligned reserve, some extra sub-regions of the memory region may be released due to alignment requirements. > 345: // NMT will ignore releasing sub-regions (i.e., contained in other regions) that have mtClassShared tags. > 346: MemTracker::record_virtual_memory_tag(rs, mtClassShared); Is it possible to capture this logic in a test, so we can always check for this behavior? Where in the code do we release and check for the special case of `mtClassShared`? I'm not 100% sure I understand why we have to first reserve with `mtNone` and only then change it to `mtClassShared`. Why can't we reserve with `mtClassShared` right from the start? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2138658913 From ccheung at openjdk.org Tue Jun 10 22:33:38 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 10 Jun 2025 22:33:38 GMT Subject: RFR: 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1 Message-ID: One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`. Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description. ------------- Commit messages: - 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1 Changes: https://git.openjdk.org/jdk/pull/25737/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25737&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357382 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25737/head:pull/25737 PR: https://git.openjdk.org/jdk/pull/25737 From kbarrett at openjdk.org Wed Jun 11 01:14:39 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 11 Jun 2025 01:14:39 GMT Subject: RFR: 8359165: AIX build broken after 8358799 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 19:46:10 GMT, Martin Doerr wrote: >> This fixes the build. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve constness. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25734#pullrequestreview-2915369045 From duke at openjdk.org Wed Jun 11 07:29:31 2025 From: duke at openjdk.org (duke) Date: Wed, 11 Jun 2025 07:29:31 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> References: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> Message-ID: <8tVGOT8BT3v9vEil8CNXdwWKrdPv8xVbHUABinhgTqc=.0a06daca-0a34-4a55-a557-82548fd3a88a@github.com> On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8265754: Addressed reviewers comments. @toxaart Your change (at version 1d34f5ad466f07c2c7ec5a4c00ba93a3b5eb66be) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2961542506 From jkern at openjdk.org Wed Jun 11 07:58:29 2025 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 11 Jun 2025 07:58:29 GMT Subject: RFR: 8359165: AIX build broken after 8358799 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 19:46:10 GMT, Martin Doerr wrote: >> This fixes the build. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve constness. Yes, your fix should repair the regression after 500a3a2. That was the only thing I found in this commit. With your fix it should work again for AIX. ------------- Marked as reviewed by jkern (Committer). PR Review: https://git.openjdk.org/jdk/pull/25734#pullrequestreview-2916054731 From cstein at openjdk.org Wed Jun 11 08:30:18 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 11 Jun 2025 08:30:18 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment [v2] In-Reply-To: References: Message-ID: > Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. > > The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): > > Use the number sign `#` in the argument file to identify comments. > All characters following the `#` are ignored until the end of line. > > There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Extract shared function to compute current token ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25589/files - new: https://git.openjdk.org/jdk/pull/25589/files/21afeb37..bea8cc79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25589&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25589&range=00-01 Stats: 31 lines in 1 file changed: 13 ins; 14 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25589/head:pull/25589 PR: https://git.openjdk.org/jdk/pull/25589 From mdoerr at openjdk.org Wed Jun 11 08:31:42 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 11 Jun 2025 08:31:42 GMT Subject: RFR: 8359165: AIX build broken after 8358799 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 19:46:10 GMT, Martin Doerr wrote: >> This fixes the build. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve constness. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25734#issuecomment-2961706305 From mdoerr at openjdk.org Wed Jun 11 08:31:43 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 11 Jun 2025 08:31:43 GMT Subject: Integrated: 8359165: AIX build broken after 8358799 In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 18:52:16 GMT, Martin Doerr wrote: > This fixes the build. This pull request has now been integrated. Changeset: 56ce70c5 Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/56ce70c5dfe1ecaf371d462d4198765d4a86db3c Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8359165: AIX build broken after 8358799 Reviewed-by: kbarrett, jkern ------------- PR: https://git.openjdk.org/jdk/pull/25734 From cstein at openjdk.org Wed Jun 11 08:35:29 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 11 Jun 2025 08:35:29 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment [v2] In-Reply-To: References: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com> <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com> Message-ID: <7Es28Ts_GeDSE5WMTb6XPEy7OnT71Wouv07AGrlMSwA=.734b2270-d85d-4b26-ac3f-a6bdcb1a2d17@github.com> On Tue, 10 Jun 2025 08:15:58 GMT, Christian Stein wrote: >> Or the handling of `#` can be merged with the previous case ... somehow. > > Extracting a method wouldn't really simplify the code, as many local variables are in play. > > Merging the cases also ends up in more if-else constructs in the case block that counter-act readability. > > So, perhaps, the duplication is goog-enough here? Created an internal shared function in https://github.com/openjdk/jdk/pull/25589/commits/bea8cc7905541e339ed30d0618e70ab6db7b6da6 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139538469 From stefank at openjdk.org Wed Jun 11 08:58:31 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jun 2025 08:58:31 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly In-Reply-To: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> Message-ID: On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari wrote: > NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order. The special-case handling of CDS in NMT breaks abstractions and has caused a number of bugs. I'm worried that trying to workaround this special-case code makes the code even more susceptible for future bugs. So, therefore I'm interested to here about the planes you have to replace the NMT implementation with a tree. Isn't that going to remove the CDS special-case code and maybe be even solve this issue without the need for this fix? If not, feel free to ignore my comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25719#issuecomment-2961794111 From stefank at openjdk.org Wed Jun 11 09:11:30 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jun 2025 09:11:30 GMT Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace' In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore wrote: > Make the fatal error a log warning and return. The metaspace commit accounting is done after this return. Tested with this always returning here, and it seems okay. Tested with this change tier 1-4 and 8. I'm not sure this is safe. Could you explain how you come to the conclusion that failing to uncommit shouldn't be considered fatal? If the failure mode really is that we failed to split the memory mapping then I don't think we can be sure that the OS left the memory reservation the way the JVM has book keeped it. In other situations like this we have found that this could lead to other threads allocating into memory that another sub-system thinks that it has reserved (and owns), which can lead to various memory corruption issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2961842406 From azafari at openjdk.org Wed Jun 11 11:09:35 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 11 Jun 2025 11:09:35 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly In-Reply-To: <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com> References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com> Message-ID: <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com> On Tue, 10 Jun 2025 19:49:57 GMT, Gerard Ziemski wrote: > Is it possible to capture this logic in a test, so we can always check for this behavior? Work on it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2139856485 From azafari at openjdk.org Wed Jun 11 11:12:30 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 11 Jun 2025 11:12:30 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly In-Reply-To: <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com> References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com> <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com> Message-ID: On Wed, 11 Jun 2025 11:06:55 GMT, Afshin Zafari wrote: >> src/hotspot/share/cds/archiveBuilder.cpp line 346: >> >>> 344: // During an aligned reserve, some extra sub-regions of the memory region may be released due to alignment requirements. >>> 345: // NMT will ignore releasing sub-regions (i.e., contained in other regions) that have mtClassShared tags. >>> 346: MemTracker::record_virtual_memory_tag(rs, mtClassShared); >> >> Is it possible to capture this logic in a test, so we can always check for this behavior? >> >> Where in the code do we release and check for the special case of `mtClassShared`? >> >> I'm not 100% sure I understand why we have to first reserve with `mtNone` and only then change it to `mtClassShared`. Why can't we reserve with `mtClassShared` right from the start? > >> Is it possible to capture this logic in a test, so we can always check for this behavior? > > Work on it. > Where in the code do we release and check for the special case of `mtClassShared`? In `virtualMemoryTracker.cpp, remove_released_region(adddress, size)` in an `if` block as this: if (reserved_rgn->mem_tag() == mtClassShared) { if (reserved_rgn->contain_region(addr, size)) { // This is an unmapped CDS region, which is part of the reserved shared // memory region. // See special handling in VirtualMemoryTracker::add_reserved_region also. return true; } if (size > reserved_rgn->size()) { // This is from release the whole region spanning from archive space to class space, // so we release them altogether. ReservedMemoryRegion class_rgn(addr + reserved_rgn->size(), (size - reserved_rgn->size())); ReservedMemoryRegion* cls_rgn = _reserved_regions->find(class_rgn); assert(cls_rgn != nullptr, "Class space region not recorded?"); assert(cls_rgn->mem_tag() == mtClass, "Must be class mem tag"); remove_released_region(reserved_rgn); remove_released_region(cls_rgn); return true; } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2139864313 From coleenp at openjdk.org Wed Jun 11 11:29:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Jun 2025 11:29:29 GMT Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace' In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore wrote: > Make the fatal error a log warning and return. The metaspace commit accounting is done after this return. Tested with this always returning here, and it seems okay. Tested with this change tier 1-4 and 8. If pd_uncommit_memory fails, it returns a boolean. If this is unsafe, shouldn't pd_uncommit_memory have a fatal error? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2962314988 From azafari at openjdk.org Wed Jun 11 11:41:29 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 11 Jun 2025 11:41:29 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly In-Reply-To: References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com> <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com> Message-ID: On Wed, 11 Jun 2025 11:10:06 GMT, Afshin Zafari wrote: >>> Is it possible to capture this logic in a test, so we can always check for this behavior? >> >> Work on it. > >> Where in the code do we release and check for the special case of `mtClassShared`? > > In `virtualMemoryTracker.cpp, remove_released_region(adddress, size)` in an `if` block as this: > > if (reserved_rgn->mem_tag() == mtClassShared) { > if (reserved_rgn->contain_region(addr, size)) { > // This is an unmapped CDS region, which is part of the reserved shared > // memory region. > // See special handling in VirtualMemoryTracker::add_reserved_region also. > return true; > } > > if (size > reserved_rgn->size()) { > // This is from release the whole region spanning from archive space to class space, > // so we release them altogether. > ReservedMemoryRegion class_rgn(addr + reserved_rgn->size(), > (size - reserved_rgn->size())); > ReservedMemoryRegion* cls_rgn = _reserved_regions->find(class_rgn); > assert(cls_rgn != nullptr, "Class space region not recorded?"); > assert(cls_rgn->mem_tag() == mtClass, "Must be class mem tag"); > remove_released_region(reserved_rgn); > remove_released_region(cls_rgn); > return true; > } > } > I'm not 100% sure I understand why we have to first reserve with `mtNone` and only then change it to `mtClassShared`. Why can't we reserve with `mtClassShared` right from the start? The sequence is as follows: _All the reserve/release operations here are from `os::` namespace and therefore will call NMT tracking API_ 1- CDS requests for reserving `S` bytes at address `Base` with alignment `A` and memTag `M`. 2- Due to OS alignment limitations regarding `A`, new base `XBase` to be used with new size `XS`. Read X as extra here. 3- Do instead, reserve `XS` bytes at `XBase`. 4- If succeeds, memory would be like `<--s1---><----S----><----s2--->`, where `XS = s1 + S + s2` and `XBase + s1 == Base` 5- Release extra parts `s1` and `s2`. 6- request at step 1 above is fulfilled now. If at step 1, the memTag `M` is `mtClassShared` , the releases at step 5 will be ignored by NMT. Which means that there are regions in NMT lists that are actually released (at os level) but NMT takes them still as reserved. Therefore, further reservations by os at those regions (e.g., for stack) will intersect with existing NMT regions and the NMT assertions fail. So the memTag is to be `mtNone` to bypass/avoid the NMT ignore branch. If we want to track the new memory region as belongs to CDS, we need to set the memTag of the region to `mtClassShared` with the corresponding `MemTracker` API.(as is done here in this PR) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2139917194 From duke at openjdk.org Wed Jun 11 11:44:29 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 11 Jun 2025 11:44:29 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 08:30:18 GMT, Christian Stein wrote: >> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. >> >> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): >> >> Use the number sign `#` in the argument file to identify comments. >> All characters following the `#` are ignored until the end of line. >> >> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Extract shared function to compute current token test/jdk/tools/launcher/ArgFileSyntax.java line 177: > 175: }, > 176: { // multiple args in one line and comments without preceding whitespace > 177: { "-Xmx32m -XshowSettings#COMMENT 1", First case feels like a duplicate of the test at line 73. What's different? Maybe this case should just live next to that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139921427 From cstein at openjdk.org Wed Jun 11 12:04:33 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 11 Jun 2025 12:04:33 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 11:41:41 GMT, David Beaumont wrote: >> Christian Stein has updated the pull request incrementally with one additional commit since the last revision: >> >> Extract shared function to compute current token > > test/jdk/tools/launcher/ArgFileSyntax.java line 177: > >> 175: }, >> 176: { // multiple args in one line and comments without preceding whitespace >> 177: { "-Xmx32m -XshowSettings#COMMENT 1", > > First case feels like a duplicate of the test at line 73. What's different? > Maybe this case should just live next to that? It only _feels_ so. Mind the gap(s) before the `#` number signs in the test at line 73: they were and are still supported. This fix and test now ensures that comments without gaps (read: whitespace) are supported. > Maybe this case should just live next to that? The location of the new test data is next to another "whitespace-related" use-case. So, it's also related. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139957273 From duke at openjdk.org Wed Jun 11 12:45:54 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 11 Jun 2025 12:45:54 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v12] In-Reply-To: References: Message-ID: <05reBLJRa6h9U7KCNqZtao-6oCB689hF-DjsMyTgOKo=.40105ae6-073a-44b4-b20e-8be084f455ef@github.com> > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8265754: Fixed date in copyright comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/1d34f5ad..00a9faaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=10-11 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From coleenp at openjdk.org Wed Jun 11 12:45:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Jun 2025 12:45:54 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v12] In-Reply-To: <05reBLJRa6h9U7KCNqZtao-6oCB689hF-DjsMyTgOKo=.40105ae6-073a-44b4-b20e-8be084f455ef@github.com> References: <05reBLJRa6h9U7KCNqZtao-6oCB689hF-DjsMyTgOKo=.40105ae6-073a-44b4-b20e-8be084f455ef@github.com> Message-ID: On Wed, 11 Jun 2025 12:43:15 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8265754: Fixed date in copyright comment. Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2916974124 From coleenp at openjdk.org Wed Jun 11 12:45:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Jun 2025 12:45:54 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> References: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> Message-ID: On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8265754: Addressed reviewers comments. Just needs a copyright fix. src/hotspot/share/runtime/suspendResumeManager.cpp line 2: > 1: /* > 2: * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. src/hotspot/share/runtime/suspendResumeManager.hpp line 2: > 1: /* > 2: * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2916964481 PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140025045 PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140024252 From duke at openjdk.org Wed Jun 11 12:45:54 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 11 Jun 2025 12:45:54 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: References: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> Message-ID: On Wed, 11 Jun 2025 12:38:06 GMT, Coleen Phillimore wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265754: Addressed reviewers comments. > > src/hotspot/share/runtime/suspendResumeManager.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Addressed in the latest commit. > src/hotspot/share/runtime/suspendResumeManager.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140030245 PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140030001 From duke at openjdk.org Wed Jun 11 12:45:56 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 11 Jun 2025 12:45:56 GMT Subject: Integrated: 8265754: Move suspend/resume API from HandshakeState In-Reply-To: References: Message-ID: On Fri, 23 May 2025 08:24:34 GMT, Anton Artemov wrote: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. This pull request has now been integrated. Changeset: 42ab8fcf Author: Anton Artemov Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/42ab8fcfb98eacb2d93f59c012360a99a16e5450 Stats: 393 lines in 6 files changed: 234 ins; 152 del; 7 mod 8265754: Move suspend/resume API from HandshakeState Reviewed-by: coleenp, dholmes, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/25407 From mdoerr at openjdk.org Wed Jun 11 12:56:27 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 11 Jun 2025 12:56:27 GMT Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too low values In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> Message-ID: <3GIKiPAcY6CABfp1c2husazPDd_dFAtAC4EnpYkC2ao=.bafe633b-3dde-4578-accf-7a63eec3d9a9@github.com> On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken wrote: > Currently os::Bsd::available_memory() returns on macOS > `vmstat.free_count * os::vm_page_size();` > But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories > There is a bit of additional information here https://developer.apple.com/forums/thread/118867 > that confirms that free memory / free_count is only a fraction of what is available. > > There is also some info here > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB > containing this relevant info : > "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them." > > and also about purgeable memory at > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1 LGTM. But I'm not a memory management expert. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25657#pullrequestreview-2917025968 From lucy at openjdk.org Wed Jun 11 13:25:31 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 11 Jun 2025 13:25:31 GMT Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too low values In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> Message-ID: On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken wrote: > Currently os::Bsd::available_memory() returns on macOS > `vmstat.free_count * os::vm_page_size();` > But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories > There is a bit of additional information here https://developer.apple.com/forums/thread/118867 > that confirms that free memory / free_count is only a fraction of what is available. > > There is also some info here > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB > containing this relevant info : > "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them." > > and also about purgeable memory at > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1 LGTM. The cited documentation suggests the fix is ok. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25657#pullrequestreview-2917141081 From mbaesken at openjdk.org Wed Jun 11 13:35:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Jun 2025 13:35:40 GMT Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too low values In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> Message-ID: On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken wrote: > Currently os::Bsd::available_memory() returns on macOS > `vmstat.free_count * os::vm_page_size();` > But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories > There is a bit of additional information here https://developer.apple.com/forums/thread/118867 > that confirms that free memory / free_count is only a fraction of what is available. > > There is also some info here > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB > containing this relevant info : > "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them." > > and also about purgeable memory at > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1 Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25657#issuecomment-2962728277 From mbaesken at openjdk.org Wed Jun 11 13:35:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 11 Jun 2025 13:35:41 GMT Subject: Integrated: 8357570: [macOS] os::Bsd::available_memory() might return too low values In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com> Message-ID: On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken wrote: > Currently os::Bsd::available_memory() returns on macOS > `vmstat.free_count * os::vm_page_size();` > But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories > There is a bit of additional information here https://developer.apple.com/forums/thread/118867 > that confirms that free memory / free_count is only a fraction of what is available. > > There is also some info here > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB > containing this relevant info : > "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them." > > and also about purgeable memory at > https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1 This pull request has now been integrated. Changeset: 7d7fc693 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/7d7fc69355e6f5421cf09f93290270bb16d13182 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8357570: [macOS] os::Bsd::available_memory() might return too low values Reviewed-by: clanger, mdoerr, lucy ------------- PR: https://git.openjdk.org/jdk/pull/25657 From stefank at openjdk.org Wed Jun 11 16:55:30 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jun 2025 16:55:30 GMT Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace' In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore wrote: > Make the fatal error a log warning and return. The metaspace commit accounting is done after this return. Tested with this always returning here, and it seems okay. Tested with this change tier 1-4 and 8. I think we should have a fatal error. I argue for that here: https://github.com/openjdk/jdk/pull/24084#issuecomment-2755656985 (You will likely have to read surrounding comments to get the context of that discussion) There was an action item in there to create a bug report for this. I'm fine to be proven wrong w.r.t. this but I think there needs to be some very convincing argument to prove that the OS leaves the JVM in a safe state when we hit the various error parts in the kernel that returns ENOMEM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2963531582 From vromero at openjdk.org Wed Jun 11 17:02:28 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 11 Jun 2025 17:02:28 GMT Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing comment [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 08:30:18 GMT, Christian Stein wrote: >> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. >> >> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): >> >> Use the number sign `#` in the argument file to identify comments. >> All characters following the `#` are ignored until the end of line. >> >> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Extract shared function to compute current token lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25589#pullrequestreview-2918023875 From iklam at openjdk.org Wed Jun 11 17:12:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 11 Jun 2025 17:12:30 GMT Subject: RFR: 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1 In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 22:28:41 GMT, Calvin Cheung wrote: > One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`. > > Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25737#pullrequestreview-2918061492 From kvn at openjdk.org Wed Jun 11 17:23:30 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 11 Jun 2025 17:23:30 GMT Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6] In-Reply-To: References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: <7zH3dpVRh0CApiUlhYRpHOe1EBMTixBKuNcxv_icngI=.406cf55f-287a-4b58-a8ca-dc9e680a98cf@github.com> On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa wrote: >> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail My testing passed ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25680#pullrequestreview-2918098117 From kvn at openjdk.org Wed Jun 11 17:28:27 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 11 Jun 2025 17:28:27 GMT Subject: RFR: 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1 In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 22:28:41 GMT, Calvin Cheung wrote: > One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`. > > Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25737#pullrequestreview-2918111133 From duke at openjdk.org Wed Jun 11 17:49:33 2025 From: duke at openjdk.org (Mohamed Issa) Date: Wed, 11 Jun 2025 17:49:33 GMT Subject: Integrated: 8358556: Assert when running with -XX:-UseLibmIntrinsic In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com> Message-ID: On Fri, 6 Jun 2025 20:40:49 GMT, Mohamed Issa wrote: > This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_. This pull request has now been integrated. Changeset: ef4cbec6 Author: Mohamed Issa Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/ef4cbec6fba77fd84b328d333f8592c6eedf1a2d Stats: 19 lines in 2 files changed: 13 ins; 2 del; 4 mod 8358556: Assert when running with -XX:-UseLibmIntrinsic Reviewed-by: sviswanathan, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25680 From ccheung at openjdk.org Wed Jun 11 18:13:32 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 11 Jun 2025 18:13:32 GMT Subject: RFR: 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1 In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 17:10:10 GMT, Ioi Lam wrote: >> One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`. >> >> Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description. > > LGTM @iklam @vnkozlov Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25737#issuecomment-2963735644 From ccheung at openjdk.org Wed Jun 11 18:13:33 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 11 Jun 2025 18:13:33 GMT Subject: Integrated: 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1 In-Reply-To: References: Message-ID: <5r5chuNab6LeYavdukooa2uGK3XW9ipc8Jg4vdoa1xQ=.f7e5a01d-8b77-41da-a4ca-e1faae8163e6@github.com> On Tue, 10 Jun 2025 22:28:41 GMT, Calvin Cheung wrote: > One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`. > > Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description. This pull request has now been integrated. Changeset: 42915821 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/429158218b52964ad1e79ba9d2fa5618d6b3398e Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1 Reviewed-by: iklam, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25737 From gziemski at openjdk.org Wed Jun 11 19:12:28 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 11 Jun 2025 19:12:28 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker [v2] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 08:27:36 GMT, Afshin Zafari wrote: >> Renamed usage of 'category' for 'MemTag' cases. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > user-facing terms remained as 'category' Need to fix the test `runtime/NMT/MallocLimitTest.java#compiler-limit-oom` Just in case, can you run MACH5 tier1-3 ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-2963885339 From syan at openjdk.org Thu Jun 12 02:10:33 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 12 Jun 2025 02:10:33 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited In-Reply-To: References: Message-ID: On Tue, 6 May 2025 14:06:54 GMT, Jan Kratochvil wrote: > When running the testcase in a VM with 16GB RAM it fails as systemd limits DefaultTasksMax based on available RAM. > > > test/hotspot/jtreg/containers/docker/TestPids.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.083s][trace][os,container] Maximum number of tasks is: 19128 > > > DefaultTasksMax=28776 for RAM 24576MB > DefaultTasksMax=19128 for RAM 16384MB > DefaultTasksMax=1088 for RAM 1024MB > > The testcase expects DefaultTasksMax>=20000. test/hotspot/jtreg/containers/docker/TestPids.java line 103: > 101: > 102: private static String runSystemctlShow() throws IOException { > 103: ProcessBuilder pb = new ProcessBuilder("systemctl", "show", "--property=DefaultTasksMax"); On windows-cygwin, there is no `systemctl` command. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25067#discussion_r2141412173 From iklam at openjdk.org Thu Jun 12 02:53:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 12 Jun 2025 02:53:15 GMT Subject: RFR: 8355556: JVM crash because archived method handle intrinsics are not restored Message-ID: `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from ``). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used. In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline. However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`. Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25). Thanks to @iwanowww for providing the fix! ------------- Commit messages: - 8355556: JVM crash because archived method handle intrinsics are not restored Changes: https://git.openjdk.org/jdk/pull/25766/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25766&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355556 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25766.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25766/head:pull/25766 PR: https://git.openjdk.org/jdk/pull/25766 From syan at openjdk.org Thu Jun 12 09:00:38 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 12 Jun 2025 09:00:38 GMT Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com> References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com> Message-ID: On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik wrote: > Test > scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797 > that causes test failure. > > The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. > I am removing it just to avoid spending time for anyone who can run test and observe this failure. LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/25316#pullrequestreview-2920150175 From azafari at openjdk.org Thu Jun 12 09:23:24 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 12 Jun 2025 09:23:24 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker [v3] In-Reply-To: References: Message-ID: > Renamed usage of 'category' for 'MemTag' cases. Afshin Zafari 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: - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag - fixed a missed test. - user-facing terms remained as 'category' - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25226/files - new: https://git.openjdk.org/jdk/pull/25226/files/05ca64d3..85cfb2b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25226&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25226&range=01-02 Stats: 154841 lines in 2417 files changed: 93346 ins; 43674 del; 17821 mod Patch: https://git.openjdk.org/jdk/pull/25226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25226/head:pull/25226 PR: https://git.openjdk.org/jdk/pull/25226 From adinn at openjdk.org Thu Jun 12 09:28:31 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 12 Jun 2025 09:28:31 GMT Subject: RFR: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam wrote: > `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from ``). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used. > > In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline. > > However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`. > > Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25). > > Thanks to @iwanowww for providing the fix! Looks good. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25766#pullrequestreview-2920252641 From duke at openjdk.org Thu Jun 12 09:44:38 2025 From: duke at openjdk.org (duke) Date: Thu, 12 Jun 2025 09:44:38 GMT Subject: Withdrawn: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu wrote: > The UnsafeOps JMH benchmark fails with the following error: > > ``` > java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > ``` > > Since this micro-benchmark is created for `sun.misc.Unsafe` rather than > `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. > > Note that even it will raise "proprietary API" warnings after this > patch, it is acceptable because the relevant APIs are bound for removal > for the integrity of the platform. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23686 From azafari at openjdk.org Thu Jun 12 09:51:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 12 Jun 2025 09:51:13 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v36] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit - invalid -> release. - old format comments are removed. Redundant tests are removed. - visualizations added. 1st try. - 'rd*' ->'rd__cs' - Johan's comments. - some comments changed - fixed a missed change in test. - impl of new visualization in one test case, for getting feedback. - a merge glitch - ... and 29 more: https://git.openjdk.org/jdk/compare/3f0fef2c...cff9eeb4 ------------- Changes: https://git.openjdk.org/jdk/pull/24028/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=35 Stats: 2113 lines in 6 files changed: 1845 ins; 81 del; 187 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Thu Jun 12 10:12:28 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 12 Jun 2025 10:12:28 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly In-Reply-To: References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> Message-ID: On Wed, 11 Jun 2025 08:55:30 GMT, Stefan Karlsson wrote: > > NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order. > > The special-case handling of CDS in NMT breaks abstractions and has caused a number of bugs. I'm worried that trying to workaround this special-case code makes the code even more susceptible for future bugs. So, therefore I'm interested to here about the planes you have to replace the NMT implementation with a tree. Isn't that going to remove the CDS special-case code and maybe be even solve this issue without the need for this fix? If not, feel free to ignore my comment. In the new implementation of NMT with tree, there will be no special-case handling neither for CDS nor for any other memory types. Thanks for bringing this up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25719#issuecomment-2965999494 From duke at openjdk.org Thu Jun 12 11:28:35 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 11:28:35 GMT Subject: Withdrawn: 8359110: Log accumulated GC and process CPU time upon VM exit In-Reply-To: References: Message-ID: <24ib50kFQIUcwJ1BlMmQPdDDZI2wDSV0aHdR1_ratQE=.7c283605-89a7-491b-802b-86958b78e801@github.com> On Tue, 10 Jun 2025 13:24:37 GMT, Jonas Norlinder wrote: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25724 From duke at openjdk.org Thu Jun 12 12:32:46 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 12:32:46 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit Message-ID: Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. [1.500s][info ][gc] GC CPU cost: 1.75% Additionally, detailed information may be retrieved with `-Xlog:gc=trace` [1.500s][trace][gc] Process CPU time: 4.945370s [1.500s][trace][gc] GC CPU time: 0.086382s [1.500s][info ][gc] GC CPU cost: 1.75% ------------- Commit messages: - Add elapsed_process_vtime - Log GC vtime on VM exit Changes: https://git.openjdk.org/jdk/pull/25779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359110 Stats: 212 lines in 22 files changed: 206 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Thu Jun 12 12:32:46 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 12:32:46 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder wrote: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% This PR is ready for review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966510906 From mdoerr at openjdk.org Thu Jun 12 12:53:31 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 12 Jun 2025 12:53:31 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v2] In-Reply-To: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com> References: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com> Message-ID: On Thu, 12 Jun 2025 02:01:47 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with two additional commits since the last revision: > > - ... and stale code > - removed stale comment I appreciate this PR. I like using the nmethod entry barrier and getting rid of not-entrant patching. I have some change requests. In addition, we can get rid of much more code. I've put my proposal in a Commit: https://github.com/TheRealMDoerr/jdk/commit/4aed569dc353c254a2f4de2d387208a0a1323990 Please take a look! src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 246: > 244: ConditionalMutexLocker ml(NMethodEntryBarrier_lock, !NMethodEntryBarrier_lock->owned_by_self(), Mutex::_no_safepoint_check_flag); > 245: int value = guard_value(nm) | not_entrant; > 246: set_guard_value(nm, value); Same here. src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 153: > 151: // Code cache unloading needs to know about on-stack nmethods. Arm the nmethods to get > 152: // mark_as_maybe_on_stack() callbacks when they are used again. > 153: _bs->arm(nm); This breaks the Shenandoah build. `arm` is private. src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 116: > 114: value |= not_entrant; > 115: } > 116: set_guard_value(nm, value); We can avoid redundant patching since we have the lock: Only update if the value is not already there. This happens quite often. ------------- Changes requested by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2920990811 PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142655962 PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142641974 PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142654627 From jsjolen at openjdk.org Thu Jun 12 12:59:42 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 12 Jun 2025 12:59:42 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v36] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 09:51:13 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit > - invalid -> release. > - old format comments are removed. Redundant tests are removed. > - visualizations added. 1st try. > - 'rd*' ->'rd__cs' > - Johan's comments. > - some comments changed > - fixed a missed change in test. > - impl of new visualization in one test case, for getting feedback. > - a merge glitch > - ... and 29 more: https://git.openjdk.org/jdk/compare/3f0fef2c...cff9eeb4 Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2921035723 From duke at openjdk.org Thu Jun 12 13:35:51 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 13:35:51 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v2] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Remove unused bool - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/4eaa6e1f..dbf314c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=00-01 Stats: 125 lines in 5 files changed: 101 ins; 23 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Thu Jun 12 13:35:52 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 13:35:52 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder wrote: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Refactored code per @kstefanj suggestions ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966727348 From tschatzl at openjdk.org Thu Jun 12 13:42:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 12 Jun 2025 13:42:28 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused bool > - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966768048 From tschatzl at openjdk.org Thu Jun 12 13:53:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 12 Jun 2025 13:53:28 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused bool > - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1498: > 1496: _cr->threads_do(&cl); > 1497: _cm->threads_do(&cl); > 1498: _workers->threads_do(&cl); There is `CollectedHeap::gc_threads_do()` (in general, for all collectors) to iterate over GC threads. Please use that. It may allow putting all that code into `CollectedHeap` used by all collectors too. ------------- PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2921251009 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2142799289 From tschatzl at openjdk.org Thu Jun 12 13:56:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 12 Jun 2025 13:56:28 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 13:39:56 GMT, Thomas Schatzl wrote: > Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message. Also reduces the amount of parsing needed in scripts etc. (I.e. three regexps vs. one). These three values are not really too much to digest for human readers. Another problem seems to be the large amount of digits after the comma for the times; maybe use a different time scale (ms/us). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966846342 From azafari at openjdk.org Thu Jun 12 14:11:40 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 12 Jun 2025 14:11:40 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 19:44:18 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a missed change in test. > > For this case: > > > {// Check committing into a reserved region inherits the call stacks > VMATree::RegionData call_stack_test(si_1, mtTest); > VMATree::RegionData call_stack_none(si_2, mtNone); > VMATree::RegionData call_stack_nmt(si_2, mtNMT); > Tree tree; > tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree > tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region > tree.print_timeline_on(); > } > > > I know that we are passing `true` for `use_tag_inplace` here, but it just does not feel right to get this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Test (committed) > C - Test (reserved) > . - None (free/released) > > > I was expecting this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Native Memory Tracking (committed) > C - Test (reserved) > . - None (free/released) > > > I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter? Thank you @gerard-ziemski and @jdksjolen for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2966962304 From kvn at openjdk.org Thu Jun 12 14:29:40 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 12 Jun 2025 14:29:40 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit Message-ID: We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter. Record used compiler type in archive and check it when using archive. Tested with tiers which use Graal. ------------- Commit messages: - 8358738: AOT cache created without graal jit should not be used with graal jit Changes: https://git.openjdk.org/jdk/pull/25782/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25782&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358738 Stats: 36 lines in 2 files changed: 36 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25782.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25782/head:pull/25782 PR: https://git.openjdk.org/jdk/pull/25782 From tschatzl at openjdk.org Thu Jun 12 14:33:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 12 Jun 2025 14:33:29 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused bool > - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection src/hotspot/share/gc/shared/collectedHeap.cpp line 234: > 232: cost = 100 * gc_vtime / process_vtime; > 233: } > 234: log_info(gc)("GC CPU cost: %2.2f%%", cost); I would prefer "usage" instead of "cost". The former seems to be more neutral. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2142928706 From duke at openjdk.org Thu Jun 12 14:40:27 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 14:40:27 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 13:53:29 GMT, Thomas Schatzl wrote: > Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message. Thank you for sharing your concern. I'm OK with putting the CPU times currently in trace into the `exit` tag but I strongly believe we should keep the `[1.500s][info ][gc] GC CPU cost: 1.75%` as is. I discussed the `exit` tag option with @kstefanj but I thought that hiding the nominal values in the trace level would suffice, but can change that if we think that is preferable. I think that exposing this number at `-Xlog:gc`-level may be an important tool for users to understand that they may running with too small heap. We expose a lot of way for users to understand the memory footprint, but not too much about the CPU footprint. Putting this number behind `exit` may increase the risk that the typical user will not discover it. Adding one line at the end while at the same time logging information about each GC cycle does not clutter the message log IMO. Another option could be to not log the nominal values at all. If one have the percentage and measure process CPU time with e.g. perf one could calculate it yourself anyways. What do you think about that? > > Another problem seems to be the large amount of digits after the comma for the times; maybe use a different time scale (ms/us). Thanks for pointing that out, I will fix that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2967112195 From azafari at openjdk.org Thu Jun 12 14:49:43 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 12 Jun 2025 14:49:43 GMT Subject: Integrated: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 10:20:49 GMT, Afshin Zafari wrote: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. This pull request has now been integrated. Changeset: fae9c7a3 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/fae9c7a3f04f85aeb9e03c5c9c15fda6405ee989 Stats: 2113 lines in 6 files changed: 1845 ins; 81 del; 187 mod 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations Reviewed-by: gziemski, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/24028 From duke at openjdk.org Thu Jun 12 15:25:08 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 15:25:08 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage - Remove unnecessary assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/dbf314c7..aeb4ad04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=01-02 Stats: 84 lines in 9 files changed: 17 ins; 62 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Thu Jun 12 15:31:31 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 12 Jun 2025 15:31:31 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage > - Remove unnecessary assert FYI; I removed nominal logging ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2967302296 From gziemski at openjdk.org Thu Jun 12 15:41:39 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 12 Jun 2025 15:41:39 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker [v3] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 09:23:24 GMT, Afshin Zafari wrote: >> Renamed usage of 'category' for 'MemTag' cases. > > Afshin Zafari 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: > > - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag > - fixed a missed test. > - user-facing terms remained as 'category' > - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker There is still a problem with GHA test, but I think this is MACH5, so when that passes and maybe MACH tier1-3, we're good. Thanks! ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25226#pullrequestreview-2921731560 From gziemski at openjdk.org Thu Jun 12 15:42:34 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 12 Jun 2025 15:42:34 GMT Subject: RFR: 8356228: NMT does not record reserved memory base address correctly In-Reply-To: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com> Message-ID: On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari wrote: > The problem here stems from the following facts: > 1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. > 2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order. > 3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above. > > So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue). > > Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings. > > Tests: > linux-x64: runtime/NMT jtreg tests passed > linux-aarch64: tier1 to tier3 passed Do we need to bother with this fix then? Should we wait for the VMATree and just verify? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25719#issuecomment-2967341763 From dlong at openjdk.org Thu Jun 12 19:54:45 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 12 Jun 2025 19:54:45 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v3] In-Reply-To: References: Message-ID: > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. Dean Long has updated the pull request incrementally with six additional commits since the last revision: - more cleanup - more TheRealMDoerr suggestions - TheRealMDoerr suggestions - remove trailing space - Fix Shenandoah build - more cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25764/files - new: https://git.openjdk.org/jdk/pull/25764/files/0780d156..0950fc5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=01-02 Stats: 330 lines in 25 files changed: 10 ins; 304 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764 PR: https://git.openjdk.org/jdk/pull/25764 From dlong at openjdk.org Thu Jun 12 19:57:28 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 12 Jun 2025 19:57:28 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v2] In-Reply-To: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com> References: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com> Message-ID: On Thu, 12 Jun 2025 02:01:47 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with two additional commits since the last revision: > > - ... and stale code > - removed stale comment Thanks @TheRealMDoer for the suggestions, I incorporated all of them, however for shenandoahCodeRoots.cpp I decided to make arm() public, so the caller code doesn't need to know about the magic value 0. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2967999465 From mdoerr at openjdk.org Thu Jun 12 20:08:31 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 12 Jun 2025 20:08:31 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v2] In-Reply-To: References: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com> Message-ID: <15r53QUpAANeu3oucJCrmg3BOqTksEQK24cppfHjQow=.b5848d6f-0bfe-43ce-a4d8-29d57d91e873@github.com> On Thu, 12 Jun 2025 19:54:28 GMT, Dean Long wrote: > Thanks @TheRealMDoer for the suggestions, I incorporated all of them, however for shenandoahCodeRoots.cpp I decided to make arm() public, so the caller code doesn't need to know about the magic value 0. Excellent! Thank you! I'll take another look over it and run tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2968024418 From iklam at openjdk.org Thu Jun 12 21:17:28 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 12 Jun 2025 21:17:28 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 14:24:25 GMT, Vladimir Kozlov wrote: > We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter. > > Record used compiler type in archive and check it when using archive. > > Tested with tiers which use Graal. Looks good. Suggestions for code clean up and inline comments. src/hotspot/share/cds/filemap.cpp line 1956: > 1954: } else if (CompilerConfig::is_c1_enabled()) { > 1955: compiler_type = CompilerType::compiler_c1; > 1956: } This block of code should be put in a method in CompilerConfig to avoid duplication. src/hotspot/share/cds/filemap.cpp line 1958: > 1956: } > 1957: CompilerType archive_compiler_type = CompilerType(_compiler_type); > 1958: // JVMCI compiler loads additional jdk.internal.vm.ci module, Since [JDK-8345826](https://github.com/openjdk/jdk/commit/81536830ed096005c4f09ab446238ce50989cea9), the jdk.internal.vm.ci module is no longer added when libgraal is used. I think you can remove this line from the comments. Incompatible module options are checked elsewhere in modules.cpp. ------------- Changes requested by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2922663464 PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2143663959 PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2143668954 From kvn at openjdk.org Thu Jun 12 22:02:43 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 12 Jun 2025 22:02:43 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit [v2] In-Reply-To: References: Message-ID: > We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter. > > Record used compiler type in archive and check it when using archive. > > Tested with tiers which use Graal. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25782/files - new: https://git.openjdk.org/jdk/pull/25782/files/3a8c8e5b..20c80da8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25782&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25782&range=00-01 Stats: 33 lines in 3 files changed: 15 ins; 15 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25782.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25782/head:pull/25782 PR: https://git.openjdk.org/jdk/pull/25782 From kvn at openjdk.org Thu Jun 12 22:02:46 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 12 Jun 2025 22:02:46 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit [v2] In-Reply-To: References: Message-ID: <0GS7REZue3eNAQ7om2zJowRf1aH9gPgPAAGJ3V-4kg4=.08e18105-edb6-4465-98a2-d8422b99174e@github.com> On Thu, 12 Jun 2025 21:14:22 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > Looks good. Suggestions for code clean up and inline comments. Thank you, @iklam, for review. I addressed your comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25782#issuecomment-2968275950 From iklam at openjdk.org Thu Jun 12 22:23:27 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 12 Jun 2025 22:23:27 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 22:02:43 GMT, Vladimir Kozlov wrote: >> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter. >> >> Record used compiler type in archive and check it when using archive. >> >> Tested with tiers which use Graal. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2922796507 From vlivanov at openjdk.org Fri Jun 13 04:48:28 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 13 Jun 2025 04:48:28 GMT Subject: RFR: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam wrote: > `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from ``). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used. > > In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline. > > However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`. > > Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25). > > Thanks to @iwanowww for providing the fix! Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25766#pullrequestreview-2923402355 From shade at openjdk.org Fri Jun 13 09:27:27 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jun 2025 09:27:27 GMT Subject: RFR: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam wrote: > `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from ``). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used. > > In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline. > > However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`. > > Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25). > > Thanks to @iwanowww for providing the fix! Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25766#pullrequestreview-2924017465 From shade at openjdk.org Fri Jun 13 09:50:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jun 2025 09:50:28 GMT Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> Message-ID: On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin wrote: > Hi everyone, > > #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function. Looks fine to me, thanks. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25722#pullrequestreview-2924115292 From azafari at openjdk.org Fri Jun 13 10:09:34 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 13 Jun 2025 10:09:34 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker [v3] In-Reply-To: References: Message-ID: <4oPITwdrPA1B0KKbkl6MSuyo-yjgje5yK3lQc40tEJ0=.9567be7c-2a8e-41ee-93b9-557a7cdbe750@github.com> On Thu, 12 Jun 2025 09:23:24 GMT, Afshin Zafari wrote: >> Renamed usage of 'category' for 'MemTag' cases. > > Afshin Zafari 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: > > - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag > - fixed a missed test. > - user-facing terms remained as 'category' > - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker GHA test failure is due to disable to load/build JTREG. not related to this change. Mach5 tiers 1-3 passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-2969829446 From tschatzl at openjdk.org Fri Jun 13 10:21:22 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 13 Jun 2025 10:21:22 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage > - Remove unnecessary assert The string deduplication thread, which is to some degree also a GC helper thread, is not considered here. Not sure if it should, slightly tending to add it. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 164: > 162: > 163: void ParallelScavengeHeap::stop() { > 164: log_gc_vtime(); I think in OO-fashion, instead of adding the `log_gc_vtime()` call everywhere, it should be called in the super-class method and the others defer to it. src/hotspot/share/gc/serial/serialHeap.cpp line 153: > 151: > 152: double SerialHeap::elapsed_gc_vtime() { > 153: return (double) Universe::heap()->vm_vtime() / NANOSECS_PER_SEC; This specialization does not seem necessary. Serial GC also has `gc_threads_do()`, which does nothing, as expected. src/hotspot/share/gc/shared/collectedHeap.cpp line 239: > 237: double gc_vtime = elapsed_gc_vtime(); > 238: > 239: if (process_vtime == -1 || gc_vtime == -1) return; I would prefer to add braces to avoid overlooking this return statement in this context. src/hotspot/share/gc/z/zCollectedHeap.cpp line 123: > 121: Atomic::add(&_vtime, os::thread_cpu_time(thread)); > 122: } > 123: } Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete. The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result. src/hotspot/share/gc/z/zCollectedHeap.cpp line 130: > 128: ZVCPUThreadClosure cl; > 129: gc_threads_do(&cl); > 130: return (double)(cl.vtime() + Universe::heap()->vm_vtime()) / NANOSECS_PER_SEC; Taking the comment about missing ZGC threads into account, it seems `elapsed_gc_vtime()` can be implemented without any need of overrides in `CollectedHeap`. src/hotspot/share/runtime/vmOperation.hpp line 171: > 169: virtual bool evaluate_at_safepoint() const { return true; } > 170: > 171: virtual bool operation_is_gc() const { return false; } This method seems to be never read anywhere. Is this correct? src/hotspot/share/runtime/vmThread.cpp line 282: > 280: > 281: EventExecuteVMOperation event; > 282: VTimeScope vTimeScope(this); Not sure if it is the intent of this change to put all VM operations into the "GC" bucket, particularly because of the log message indicating so. I would prefer if really only GC operations would be counted here; `VTimeScope` does not use `operation_is_gc()` either, so I am not sure about the intention here. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2921860873 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144665083 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144669651 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2143164063 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144687225 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144693093 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144695741 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2143169291 From tschatzl at openjdk.org Fri Jun 13 10:28:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 13 Jun 2025 10:28:29 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com> On Thu, 12 Jun 2025 15:28:25 GMT, Jonas Norlinder wrote: > FYI; I removed nominal logging Okay, these can be re-added if needed. I also see your point about that this is just one message at VM exit, so we do not need the "exit" label. I would prefer if it had, so I won't insist on it given that others do not mind either. It would fit the purpose of the `exit` label perfectly though. The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time. I.e. if there is need to monitor it, only printing it at the end seems insufficient, as that kind of monitoring is continuous. It helps benchmarking though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969876711 From duke at openjdk.org Fri Jun 13 10:50:38 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 10:50:38 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com> References: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com> Message-ID: On Fri, 13 Jun 2025 10:25:22 GMT, Thomas Schatzl wrote: > The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time. I disagree, it is equally important as reporting pre and post compaction heap usage like we do now with -Xlog:gc. Users who are not experts in GC may underestimate the CPU cost of GC at a given heap max. Even experts in academia tend to run with too small heap. I maintain my position that adding it at the end is crucial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969922344 From duke at openjdk.org Fri Jun 13 10:50:39 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 10:50:39 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: <1rWshKBN5OE7MVryOUpeH2aOo4cbVLaZpbj7H8WCr9Q=.201e4fb8-50b6-466c-b863-1081bf034e9e@github.com> On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage > - Remove unnecessary assert Additionally, if we want to we can also add capabilities to track it continuously with JFR and/or MXBeans. But that may introduce a performance penalty as sampling may not be free so I want to still keep logging it at the end as a base case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969931470 From tschatzl at openjdk.org Fri Jun 13 11:21:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 13 Jun 2025 11:21:30 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com> Message-ID: <_rAjyUhvY8figCunG0eUdqNQyZoRTnJz-RUTkv8KJR0=.32329766-3198-4b9f-8399-34ffd90a9dce@github.com> On Fri, 13 Jun 2025 10:45:15 GMT, Jonas Norlinder wrote: > > The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time. > > I disagree, it is equally important as reporting pre and post compaction heap usage like we do now with -Xlog:gc. Users who are not experts in GC may underestimate the CPU cost of GC at a given heap max. Even experts in academia tend to run with too small heap. I maintain my position that adding it at the end is crucial. I do not disagree about the usefulness of the message (it is - I even liked the nominal output), I only somewhat disagree about making a message purposefully printed at VM exit, to state the cpu usage at exit, not having the "exit" label. (Regarding the nominal logging: my points were that I thought it was a waste to use three messages, and the presentation format) We do not need to agree on everything 100%. > Additionally, if we want to we can also add capabilities to track it continuously with JFR and/or MXBeans. But that may introduce a performance penalty as sampling may not be free so I want to still keep logging it at the end as a base case. That's fine. Fwiw, there has even been interest from me (https://bugs.openjdk.org/browse/JDK-8349476) about regularly printing these statistics at even higher detail. However as far as I understand, there are jstat/perf counters already for that, and they are in use (in industry). There is the jcmd command (even before that) that prints per-thread cpu usage for some time now - one could filter out the interesting threads manually... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2970035555 From shade at openjdk.org Fri Jun 13 11:37:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jun 2025 11:37:43 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic Message-ID: A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. Additional testing: - [x] Linux x86_64 server fastdebug, `runtime/cds` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/25799/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25799&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359436 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25799.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25799/head:pull/25799 PR: https://git.openjdk.org/jdk/pull/25799 From mdoerr at openjdk.org Fri Jun 13 11:57:35 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 13 Jun 2025 11:57:35 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v3] In-Reply-To: References: Message-ID: <0jwlIB4VebRh3dORUSPdbmmE4YWS1Z6t_Ax8ni0_tpg=.f9dd6d19-1c97-43d7-acb2-ad575b61d433@github.com> On Thu, 12 Jun 2025 19:54:45 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with six additional commits since the last revision: > > - more cleanup > - more TheRealMDoerr suggestions > - TheRealMDoerr suggestions > - remove trailing space > - Fix Shenandoah build > - more cleanup LGTM, now. I think `is_sigill_not_entrant` should also be removed completely: https://github.com/TheRealMDoerr/jdk/commit/f61f54a40ad0b952ba8c0a668675b3f315f83a95 I've run tests on some platforms, but will run on more. @offamitkumar, @RealFYang, @bulasevich: You may also want to check your platforms. @fisk: You may want to take a look at the nmethod entry barrier changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2924552667 From duke at openjdk.org Fri Jun 13 12:02:40 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 12:02:40 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 16:21:12 GMT, Thomas Schatzl wrote: >> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage >> - Remove unnecessary assert > > src/hotspot/share/runtime/vmThread.cpp line 282: > >> 280: >> 281: EventExecuteVMOperation event; >> 282: VTimeScope vTimeScope(this); > > Not sure if it is the intent of this change to put all VM operations into the "GC" bucket, particularly because of the log message indicating so. I would prefer if really only GC operations would be counted here; `VTimeScope` does not use `operation_is_gc()` either, so I am not sure about the intention here. Ouch, thanks for catching this! My intention to use `operation_is_gc()` got lost during code refactoring. `VTimeScope` are supposed to call `os::thread_cpu_time` minimum amount of times needed and update VM cpu time tracking used by hsperf counters and the CPU time tracking this patch adds for GC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144945218 From duke at openjdk.org Fri Jun 13 12:54:34 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 12:54:34 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 10:04:18 GMT, Thomas Schatzl wrote: >> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage >> - Remove unnecessary assert > > src/hotspot/share/gc/z/zCollectedHeap.cpp line 123: > >> 121: Atomic::add(&_vtime, os::thread_cpu_time(thread)); >> 122: } >> 123: } > > Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete. > The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result. I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in: ZDirector ZDriverMajor ZDriverMinor ZStat ZUncommitter#0 ZWorkerYoung#0 ZWorkerYoung#1 ZWorkerYoung#2 ZWorkerYoung#3 ZWorkerOld#0 ZWorkerOld#1 ZWorkerOld#2 ZWorkerOld#3 This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145029576 From ayang at openjdk.org Fri Jun 13 13:07:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 13 Jun 2025 13:07:45 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 12:51:40 GMT, Jonas Norlinder wrote: >> src/hotspot/share/gc/z/zCollectedHeap.cpp line 123: >> >>> 121: Atomic::add(&_vtime, os::thread_cpu_time(thread)); >>> 122: } >>> 123: } >> >> Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete. >> The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result. > > I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in: > > > ZDirector > ZDriverMajor > ZDriverMinor > ZStat > ZUncommitter#0 > ZWorkerYoung#0 > ZWorkerYoung#1 > ZWorkerYoung#2 > ZWorkerYoung#3 > ZWorkerOld#0 > ZWorkerOld#1 > ZWorkerOld#2 > ZWorkerOld#3 > > > This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work. Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145051424 From kvn at openjdk.org Fri Jun 13 13:30:33 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jun 2025 13:30:33 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev wrote: > once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. Why do you need to change it then? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970396352 From duke at openjdk.org Fri Jun 13 14:40:30 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 14:40:30 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 09:55:38 GMT, Thomas Schatzl wrote: >> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage >> - Remove unnecessary assert > > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 164: > >> 162: >> 163: void ParallelScavengeHeap::stop() { >> 164: log_gc_vtime(); > > I think in OO-fashion, instead of adding the `log_gc_vtime()` call everywhere, it should be called in the super-class method and the others defer to it. Just wanna double-check that I understood your suggestion. Are you suggesting that we should rather add calls to `CollectedHeap::stop()` at the beginning of the specialization? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145239880 From ccheung at openjdk.org Fri Jun 13 15:18:43 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 13 Jun 2025 15:18:43 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 22:02:43 GMT, Vladimir Kozlov wrote: >> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter. >> >> Record used compiler type in archive and check it when using archive. >> >> Tested with tiers which use Graal. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments Looks good. I have one question. src/hotspot/share/cds/filemap.cpp line 1952: > 1950: (compiler_type == CompilerType::compiler_none); > 1951: if (!intepreter_is_used && > 1952: jvmci_compiler_is_enabled != (archive_compiler_type == CompilerType::compiler_jvmci)) { Does it mean we allow different compiler type during assembly phase and production phase? e.g. assembly phase using c1, production phase using c2? ------------- PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2925191023 PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2145312369 From shade at openjdk.org Fri Jun 13 15:52:35 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jun 2025 15:52:35 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 13:27:43 GMT, Vladimir Kozlov wrote: > > once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Why do you need to change it then? Because in JDK 25, I can see people experimenting with this option, or even turning it on. It is inconvenient to turn on diagnostic option for production use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970804695 From kvn at openjdk.org Fri Jun 13 15:53:31 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jun 2025 15:53:31 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 15:15:26 GMT, Calvin Cheung wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > Looks good. I have one question. Thank you @calvinccheung for review. > src/hotspot/share/cds/filemap.cpp line 1952: > >> 1950: (compiler_type == CompilerType::compiler_none); >> 1951: if (!intepreter_is_used && >> 1952: jvmci_compiler_is_enabled != (archive_compiler_type == CompilerType::compiler_jvmci)) { > > Does it mean we allow different compiler type during assembly phase and production phase? e.g. assembly phase using c1, production phase using c2? Yes. By default we have both with TieredCompilation. But we can switch it off (C2 only) or use TieredStopAtLevel=1 (C1 only). When they are mixed (one phase use only C1 and an other C2) we simple will not load AOT nmethods because corresponding compiler's runtime stubs will not be created so we can't use AOT nmethods referencing these stubs. But nothing in code generation or methods profiling prevents us from mixing them. On other hand Graal creates different profiling data and additional nmethod's metadata. So we can't use such data with other JIT compilers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25782#issuecomment-2970809429 PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2145398615 From kvn at openjdk.org Fri Jun 13 16:00:29 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jun 2025 16:00:29 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev wrote: > A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". > > I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` When AOT code caching is integrated do you plan to move it back to diagnostic? As you said - it does not make sense to touch it. But then people will be confused if in JDK 25 and 26 they are different. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970826963 From duke at openjdk.org Fri Jun 13 16:01:35 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 16:01:35 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 13:04:35 GMT, Albert Mingkun Yang wrote: >> I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in: >> >> >> ZDirector >> ZDriverMajor >> ZDriverMinor >> ZStat >> ZUncommitter#0 >> ZWorkerYoung#0 >> ZWorkerYoung#1 >> ZWorkerYoung#2 >> ZWorkerYoung#3 >> ZWorkerOld#0 >> ZWorkerOld#1 >> ZWorkerOld#2 >> ZWorkerOld#3 >> >> >> This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work. > > Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi. FWIW; I confirmed with @stefank that `_runtime_workers` shoud not be accounted for GC CPU time for ZGC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145419752 From iklam at openjdk.org Fri Jun 13 16:15:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 13 Jun 2025 16:15:00 GMT Subject: RFR: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 09:25:50 GMT, Andrew Dinn wrote: >> `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from ``). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used. >> >> In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline. >> >> However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`. >> >> Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25). >> >> Thanks to @iwanowww for providing the fix! > > Looks good. Thanks @adinn @iwanowww @shipilev for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25766#issuecomment-2970861716 From iklam at openjdk.org Fri Jun 13 16:15:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 13 Jun 2025 16:15:00 GMT Subject: Integrated: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam wrote: > `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from ``). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used. > > In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline. > > However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`. > > Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25). > > Thanks to @iwanowww for providing the fix! This pull request has now been integrated. Changeset: 366650a4 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8355556: JVM crash because archived method handle intrinsics are not restored Reviewed-by: adinn, vlivanov, shade ------------- PR: https://git.openjdk.org/jdk/pull/25766 From ccheung at openjdk.org Fri Jun 13 16:16:34 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 13 Jun 2025 16:16:34 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 22:02:43 GMT, Vladimir Kozlov wrote: >> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter. >> >> Record used compiler type in archive and check it when using archive. >> >> Tested with tiers which use Graal. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments Marked as reviewed by ccheung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2925397901 From ccheung at openjdk.org Fri Jun 13 16:16:35 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 13 Jun 2025 16:16:35 GMT Subject: RFR: 8358738: AOT cache created without graal jit should not be used with graal jit [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 15:50:02 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/cds/filemap.cpp line 1952: >> >>> 1950: (compiler_type == CompilerType::compiler_none); >>> 1951: if (!intepreter_is_used && >>> 1952: jvmci_compiler_is_enabled != (archive_compiler_type == CompilerType::compiler_jvmci)) { >> >> Does it mean we allow different compiler type during assembly phase and production phase? e.g. assembly phase using c1, production phase using c2? > > Yes. By default we have both with TieredCompilation. But we can switch it off (C2 only) or use TieredStopAtLevel=1 (C1 only). When they are mixed (one phase use only C1 and an other C2) we simple will not load AOT nmethods because corresponding compiler's runtime stubs will not be created so we can't use AOT nmethods referencing these stubs. But nothing in code generation or methods profiling prevents us from mixing them. > > On other hand Graal creates different profiling data and additional nmethod's metadata. So we can't use such data with other JIT compilers. Thanks for the explanations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2145446449 From kvn at openjdk.org Fri Jun 13 16:22:43 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jun 2025 16:22:43 GMT Subject: Integrated: 8358738: AOT cache created without graal jit should not be used with graal jit In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 14:24:25 GMT, Vladimir Kozlov wrote: > We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter. > > Record used compiler type in archive and check it when using archive. > > Tested with tiers which use Graal. This pull request has now been integrated. Changeset: 12a0dd03 Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/12a0dd03b89cc3bf7f9d32b17eb41ff2bf687536 Stats: 36 lines in 4 files changed: 36 ins; 0 del; 0 mod 8358738: AOT cache created without graal jit should not be used with graal jit Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/25782 From shade at openjdk.org Fri Jun 13 17:07:39 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jun 2025 17:07:39 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 15:57:27 GMT, Vladimir Kozlov wrote: > When AOT code caching is integrated do you plan to move it back to diagnostic? As you said - it does not make sense to touch it. Right. I think we would need to move it back to diagnostic once AOT code compilation would land. It would also reflect the status of the feature: in JDK 25, it is sensible to flip it back and forth as experimental performance flag; past that, the only sensible behavior is "on", and you only turn it off to diagnose bugs. What I am trying to achieve with this PR: users in JDK 25 should not be unlocking diagnostic flags for their performance needs. At most, they need to unlock experimental ones. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970984311 From duke at openjdk.org Fri Jun 13 17:08:00 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 17:08:00 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v4] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Replace calls to log_gc_vtime with super-class method calls - Add bug fix after refactor and fixes for review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/aeb4ad04..dec5b8ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=02-03 Stats: 25 lines in 11 files changed: 3 ins; 6 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Fri Jun 13 17:14:35 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 17:14:35 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 10:17:17 GMT, Thomas Schatzl wrote: > The string deduplication thread, which is to some degree also a GC helper thread, is not considered here. Not sure if it should, slightly tending to add it. I can see arguments for both ways, but do not have a strong opinion. Unless someone object I will add it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2970995550 From shade at openjdk.org Fri Jun 13 17:17:29 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jun 2025 17:17:29 GMT Subject: RFR: 8355298: Increase timeout for StressAsyncUL In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 14:01:17 GMT, Johan Sj?len wrote: > Hi, > > Running async UL with stalling mode enabled is very slow if your buffer is very small. This turns out to become an issue on slow machines, where we run the risk of the test timing out. > > The ticket's suggestion (and title) is to increase the timeout. I think that it'd be fine to reduce the logging level to 'debug' instead, thus reducing the time required to run the test. > > Obviously, if we go with this solution then the ticket name and description must be adjusted. I think it is fine to switch to `debug`, if that indeed produces much fewer messages, while still testing the stalling mode. ------------- PR Review: https://git.openjdk.org/jdk/pull/25695#pullrequestreview-2925570815 From kvn at openjdk.org Fri Jun 13 17:18:30 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jun 2025 17:18:30 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev wrote: > A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". > > I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` Okay. Then why not do this change in JDK 25 branch only and don't touch JDK 26? You would need approval for JDK 25: https://openjdk.org/jeps/3#Late-Enhancement-Request-Process ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2971001482 From shade at openjdk.org Fri Jun 13 17:18:31 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 13 Jun 2025 17:18:31 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: <-V-JrwlZRvHgbO2-fFwiVt2yavoeOi00LHYQ24P-bEs=.041c81b2-c00e-4555-9ea1-95b2c421d021@github.com> On Fri, 13 Jun 2025 17:13:52 GMT, Vladimir Kozlov wrote: > Okay. Then why not do this change in JDK 25 branch only and don't touch JDK 26? Are we 100% sure AOT code cache would land in JDK 26? I don't think we can make that bet yet :) This is why it is for both mainline and JDK 25. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2971005378 From kvn at openjdk.org Fri Jun 13 17:31:37 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jun 2025 17:31:37 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev wrote: > A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". > > I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` Okay, let's go with this. Don't forget to request approval for JDK 25. Trivial. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2925631848 From kvn at openjdk.org Fri Jun 13 17:31:38 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 13 Jun 2025 17:31:38 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: <-V-JrwlZRvHgbO2-fFwiVt2yavoeOi00LHYQ24P-bEs=.041c81b2-c00e-4555-9ea1-95b2c421d021@github.com> References: <-V-JrwlZRvHgbO2-fFwiVt2yavoeOi00LHYQ24P-bEs=.041c81b2-c00e-4555-9ea1-95b2c421d021@github.com> Message-ID: On Fri, 13 Jun 2025 17:15:53 GMT, Aleksey Shipilev wrote: > > Okay. Then why not do this change in JDK 25 branch only and don't touch JDK 26? > > Are we 100% sure AOT code cache would land in JDK 26? I don't think we can make that bet yet :) This is why it is for both mainline and JDK 25. That is the plan but we can't promise officially. "When it is ready". ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2971046938 From dlong at openjdk.org Fri Jun 13 19:18:19 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 13 Jun 2025 19:18:19 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. Dean Long has updated the pull request incrementally with one additional commit since the last revision: remove is_sigill_not_entrant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25764/files - new: https://git.openjdk.org/jdk/pull/25764/files/0950fc5e..c1ebde09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=02-03 Stats: 23 lines in 6 files changed: 0 ins; 22 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764 PR: https://git.openjdk.org/jdk/pull/25764 From duke at openjdk.org Fri Jun 13 20:11:04 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 13 Jun 2025 20:11:04 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Add CPU time tracking for string deduplication to log_gc_vtime ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/dec5b8ba..895f3747 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=03-04 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From syan at openjdk.org Sat Jun 14 01:01:43 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 14 Jun 2025 01:01:43 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev wrote: > A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". > > I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2926932034 From mdoerr at openjdk.org Sat Jun 14 11:10:38 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Sat, 14 Jun 2025 11:10:38 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com> On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove is_sigill_not_entrant Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2928005394 From eosterlund at openjdk.org Mon Jun 16 00:59:31 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 16 Jun 2025 00:59:31 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove is_sigill_not_entrant Thanks for doing this! I have been wanting something like this for a while too and it looks great. I have some comments though... src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 109: > 107: } > 108: > 109: void ZBarrierSetNMethod::arm_with(nmethod* nm, int value) { I don't usually comment on names, but could we call this guard_with instead? We tried to stop saying "arm" about things used also for disarming and we have (hopefully) been consistent about calling that "guard" instead. src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114: > 112: // Preserve the sticky bit > 113: if (is_not_entrant(nm)) { > 114: value |= not_entrant; Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant? If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier. ------------- PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2930412450 PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2148888954 PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2148891702 From iklam at openjdk.org Mon Jun 16 02:04:27 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 16 Jun 2025 02:04:27 GMT Subject: [jdk25] RFR: 8355556: JVM crash because archived method handle intrinsics are not restored Message-ID: Hi all, This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev. Thanks! ------------- Commit messages: - Backport 366650a438d046f3da5b490c42e37faaf3a9abc5 Changes: https://git.openjdk.org/jdk/pull/25815/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25815&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355556 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25815.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25815/head:pull/25815 PR: https://git.openjdk.org/jdk/pull/25815 From dholmes at openjdk.org Mon Jun 16 04:36:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jun 2025 04:36:42 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11] In-Reply-To: References: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com> Message-ID: On Wed, 11 Jun 2025 12:40:40 GMT, Anton Artemov wrote: >> src/hotspot/share/runtime/suspendResumeManager.cpp line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved. >> >> Suggestion: >> >> * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > Addressed in the latest commit. We have had this raised a number of times recently. When you refactor code into a new file the copyright years for the new file are taken from the oldest dates in the original files. It is an approximation as you don't know exactly when the refactored code was first added, but you don't just give it the current year. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2149025086 From dholmes at openjdk.org Mon Jun 16 07:43:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jun 2025 07:43:32 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Add CPU time tracking for string deduplication to log_gc_vtime This seems reasonable though I'm unclear on some details. Could you give a high-level description of what times we capture for what threads and when, and the calculations involved. Thanks. Some minor style nits. src/hotspot/share/gc/shared/vtimeScope.hpp line 38: > 36: > 37: public: > 38: VTimeScope(VMThread *thread, bool operation_is_gc); Suggestion: VTimeScope(VMThread* thread, bool operation_is_gc); src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 32: > 30: #include "runtime/os.hpp" > 31: > 32: inline VTimeScope::VTimeScope(VMThread *thread, bool operation_is_gc) Suggestion: inline VTimeScope::VTimeScope(VMThread* thread, bool operation_is_gc) This style nit needs fixing in a few places. src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 35: > 33: : _start(0), _enabled(os::is_thread_cpu_time_supported()), > 34: _gcLogging(operation_is_gc && (log_is_enabled(Info, gc) || log_is_enabled(Info, gc, cpu))), > 35: _thread((Thread*)thread) { Cast should not be necessary ------------- PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2930801029 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153155 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153527 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153897 From amitkumar at openjdk.org Mon Jun 16 08:29:34 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 16 Jun 2025 08:29:34 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove is_sigill_not_entrant Just FYI, s390 build is broken with this change: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117 # assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration # # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) # Problematic frame: # V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e # # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086) # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # stack trace: Stack: [0x000003ff9e580000,0x000003ff9e680000], sp=0x000003ff9e67b068, free space=1004k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e (barrierSetNMethod.cpp:196) v ~StubRoutines::method_entry_barrier 0x000003ff9050cd18 J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048] j sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base j sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base j java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base j jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base j jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base j jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base j java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base j java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base .... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2975564797 From tschatzl at openjdk.org Mon Jun 16 08:34:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 16 Jun 2025 08:34:31 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: <8JpTGtXweaka2sBESSAKeOHqdsd-DrnLj7oF0XiZ0GI=.c8212dfd-a4ee-41a4-bf83-848c87bbd7ba@github.com> On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Add CPU time tracking for string deduplication to log_gc_vtime Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 166: > 164: CollectedHeap::stop(); > 165: } > 166: There is no need to override this method if the only thing it does is calling the super class method. src/hotspot/share/gc/serial/serialHeap.cpp line 151: > 149: CollectedHeap::stop(); > 150: } > 151: There is no need to override this method if the only thing it does is calling the super class method. src/hotspot/share/gc/shared/collectedHeap.hpp line 245: > 243: > 244: // Stop any onging concurrent work and prepare for exit. > 245: virtual void stop() { log_gc_vtime(); } Please move this implementation into the `.cpp` file to avoid making the `.hpp` file more complicated than needed. It's not performance sensitive at all (or if you really think this is required, into the `.inline.hpp` file). src/hotspot/share/gc/shared/collectedHeap.hpp line 258: > 256: _vm_vtime += time; > 257: } > 258: Probably better to move into `.inline.hpp` file too. ------------- PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2930986521 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149271551 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149272195 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149350924 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149352267 From tschatzl at openjdk.org Mon Jun 16 08:34:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 16 Jun 2025 08:34:31 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 15:59:05 GMT, Jonas Norlinder wrote: >> Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi. > > FWIW; I confirmed with @stefank that `_runtime_workers` shoud not be accounted for GC CPU time for ZGC. But then runtime tasks performed by the GC worker threads when using them for runtime work is differently counted towards those GCs that do this sharing/shadowing. I looked a bit what they are doing, after JDK-8329488 they are only used by heap inspection and heap dumping. Which seems to be solely GC related task, so I kind of think they should be counted against GC. At least make the accounting uniform across collectors. So one option is duplicating these workers in G1/Parallel too, and fix https://bugs.openjdk.org/browse/JDK-8277394. Since we can't share GC workers and these "runtime workers" any more due to this change, the safepoint workers management should probably be moved to `CollectedHeap`, and they shouldn't be advertised as general purpose workers everyone can hook into. Or just let ZGC's `_runtime_threads` also count towards GC time. After all both of these VM operations are `VM_GC_Operations`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149337356 From duke at openjdk.org Mon Jun 16 09:03:32 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 16 Jun 2025 09:03:32 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 06:37:42 GMT, David Holmes wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Add CPU time tracking for string deduplication to log_gc_vtime > > src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 35: > >> 33: : _start(0), _enabled(os::is_thread_cpu_time_supported()), >> 34: _gcLogging(operation_is_gc && (log_is_enabled(Info, gc) || log_is_enabled(Info, gc, cpu))), >> 35: _thread((Thread*)thread) { > > Cast should not be necessary Not casting requires adding `#include "runtime/vmThread.hpp"`. Will add that since that seems to be preferred. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149417216 From duke at openjdk.org Mon Jun 16 09:19:32 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 16 Jun 2025 09:19:32 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Add CPU time tracking for string deduplication to log_gc_vtime src/hotspot/share/runtime/vmThread.cpp line 278: > 276: PerfTraceTime vm_op_timer(perf_accumulated_vm_operation_time()); > 277: HOTSPOT_VMOPS_BEGIN( > 278: (char *) op->name(), strlen(op->name()), @dholmes-ora given that I'm editing `VMThread::evaluate_operation` and your comments about code style - do you want me to also change this type cast to `(char*)` to align with the preferred style? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149450013 From shade at openjdk.org Mon Jun 16 09:22:33 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 16 Jun 2025 09:22:33 GMT Subject: [jdk25] RFR: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 01:59:16 GMT, Ioi Lam wrote: > Hi all, > > This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev. > > Thanks! Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25815#pullrequestreview-2931282671 From schernyshev at openjdk.org Mon Jun 16 09:50:48 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 16 Jun 2025 09:50:48 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac Message-ID: Hi all, I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged. Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root. Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output. The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_/ files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders///T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories(). The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java and create .attach files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_, which is in the target process's temp directory, exactly where it expects to see the .java in return on sending SIGQUIT to the target VM. Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_ folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the and to the JVM being attached to. The patch is tested against the range of macOS versions, the earliest version tested is 10.13 High Sierra (as 11u backport), the latest version tested is 15.5 Sequoia. Testing: - jtreg hotspot/jdk tier1 passed - jtreg tier2, tier3 no regresstions - gtest:all passed [1] https://github.com/apple-oss-distributions/Libc/blob/Libc-997.90.3/darwin/_dirhelper.c#L210 ------------- Commit messages: - 8319589: Attach from root to a user java process not supported in Mac Changes: https://git.openjdk.org/jdk/pull/25824/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319589 Stats: 255 lines in 8 files changed: 241 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824 PR: https://git.openjdk.org/jdk/pull/25824 From syan at openjdk.org Mon Jun 16 10:02:15 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 16 Jun 2025 10:02:15 GMT Subject: RFR: 8359207: Remove redundant runtime/signal/TestSigusr2.java Message-ID: Hi all, The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux and macos. Thus this test will is always skipped indeed. So I want to removed this test. Test-fix only, no rsik. ------------- Commit messages: - 8359207: Remove redundant runtime/signal/TestSigusr2.java Changes: https://git.openjdk.org/jdk/pull/25825/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25825&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359207 Stats: 43 lines in 2 files changed: 0 ins; 41 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25825/head:pull/25825 PR: https://git.openjdk.org/jdk/pull/25825 From duke at openjdk.org Mon Jun 16 11:25:16 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 16 Jun 2025 11:25:16 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v6] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Remove explicit super call and minor fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/895f3747..effaeede Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=04-05 Stats: 41 lines in 10 files changed: 14 ins; 17 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Mon Jun 16 11:31:51 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 16 Jun 2025 11:31:51 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v7] In-Reply-To: References: Message-ID: <8LJedORsD5AZ49XAf3_JjzbYhOa_HVvB0PMUWyI7m5s=.3cf83050-ed44-4516-96e1-ea87a97ae9fa@github.com> > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Only sample if needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/effaeede..2ac00321 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Mon Jun 16 11:52:28 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 16 Jun 2025 11:52:28 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 07:40:27 GMT, David Holmes wrote: > This seems reasonable though I'm unclear on some details. Could you give a > high-level description of what times we capture for what threads and when, and > the calculations involved. Thanks. What threads: * All GC threads e.g. director thread, sample threads, worker threads, driver threads (except for ZGC where I currently exclude the "runtime" threads which we may decide to change, see @tschatzl comments above) * The VM thread, but only include VM operations related to GC * The string deduplication thread What times: * CPU time for all the threads above * CPU time for the entire process When: * VM thread: - If VM operation is GC and `-Xlog:gc` or more is enabled, sample `start`, and `end` CPU time for the GC operation. Add `end - start` to `gc_vm_vtime`. * GC threads: - If `-Xlog:gc` or more is enabled, sample all GC threads and store the CPU time sum to `gc_threads_vtime` during VM exit. * String deduplication thread: - If string deduplication is enabled and if `-Xlog:gc` or more is enabled sample CPU time during VM exit for that thread and store to `string_deduplication_vtime` * Process: - If `-Xlog:gc` or more is enabled, sample the CPU time for the entire process Log accumulated CPU time `gc_threads_vtime + gc_vm_vtime + string_deduplication_vtime` as a percentage of the total process CPU time. We sample the total process CPU time with the new method `os::elapsed_process_vtime`. It should be noted from the above that calling elapsed_gc_vtime assumes that -Xlog:gc or more is enabled. If one breaks this assumption the GC CPU time will not include VM thread and may be horribly wrong (e.g. if one runs Serial). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2976252452 From azafari at openjdk.org Mon Jun 16 12:06:31 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 16 Jun 2025 12:06:31 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v40] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: - changes after merge - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - fixes after merge with master. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - more reviews. - review comments applied - test cases for doing reserve or commit the same region twice. - style, some cleanup, VMT and regionsTree circular dep resolved - removed UseFlagInPlace test. - ... and 76 more: https://git.openjdk.org/jdk/compare/3a188726...e303ee7c ------------- Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=39 Stats: 1426 lines in 26 files changed: 555 ins; 557 del; 314 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From duke at openjdk.org Mon Jun 16 12:50:17 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 16 Jun 2025 12:50:17 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v8] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: operation_is_gc -> is_gc_operation per @stefank suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/2ac00321..b20c9740 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=06-07 Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From mdoerr at openjdk.org Mon Jun 16 13:59:29 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 16 Jun 2025 13:59:29 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 08:26:38 GMT, Amit Kumar wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> remove is_sigill_not_entrant > > Just FYI, s390 build is broken with this change: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117 > # assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > # Problematic frame: > # V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e > # > # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086) > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > > stack trace: > > Stack: [0x000003ff9e580000,0x000003ff9e680000], sp=0x000003ff9e67b068, free space=1004k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e (barrierSetNMethod.cpp:196) > v ~StubRoutines::method_entry_barrier 0x000003ff9050cd18 > J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048] > j sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base > j sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base > j java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base > j jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base > j jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base > j jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base > j java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base > j java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base > .... @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2976308103 From mdoerr at openjdk.org Mon Jun 16 13:59:30 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 16 Jun 2025 13:59:30 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove is_sigill_not_entrant Seems like arm32 has the same issue: https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199 The init value shouldn't have the sticky bit set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2976766766 From amitkumar at openjdk.org Mon Jun 16 15:07:29 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 16 Jun 2025 15:07:29 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 08:26:38 GMT, Amit Kumar wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> remove is_sigill_not_entrant > > Just FYI, s390 build is broken with this change: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117 > # assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > # Problematic frame: > # V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e > # > # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086) > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > > stack trace: > > Stack: [0x000003ff9e580000,0x000003ff9e680000], sp=0x000003ff9e67b068, free space=1004k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e (barrierSetNMethod.cpp:196) > v ~StubRoutines::method_entry_barrier 0x000003ff9050cd18 > J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048] > j sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base > j sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base > j java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base > j jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base > j jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base > j jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base > j java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base > j java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base > .... > @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0. Thank you Martin for the suggestion. @dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp index e78906708af..2d663061aec 100644 --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp @@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes // Compare to current patched value: - __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val) + __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val) // Conditional Jump __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp index d3f6540a3ea..bb1d9ce6037 100644 --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp @@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator { // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier)); - __ z_ltr(Z_R0_scratch, Z_RET); + __ z_ltr(Z_RET, Z_RET); // VM-Call Epilogue __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false); ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2977015369 From coleenp at openjdk.org Mon Jun 16 18:02:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 16 Jun 2025 18:02:29 GMT Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace' In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore wrote: > Make the fatal error a log warning and return. The metaspace commit accounting is done after this return. Tested with this always returning here, and it seems okay. Tested with this change tier 1-4 and 8. I don't see any evidence of a bug filed to examine whether uncommit failures should always/never/sometimes be a fatal error. As the code is now, it's up to the caller, which is a situation that could go badly wrong if the caller guesses wrong. I'd rather it always be a fatal error inside our os code that does uncommit in the cases that would corrupt memory. If that's the case. This metaspace uncommit is a case that seems like it could fail and the memory simply isn't returned as we'd wished. Who knows whether memory is corrupted here or not. I'd like the OS layer of code to tell me that. Not really sure what to do about this other than close it as WNF. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2977532489 From duke at openjdk.org Mon Jun 16 21:15:29 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 16 Jun 2025 21:15:29 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v8] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 12:50:17 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > operation_is_gc -> is_gc_operation per @stefank suggestion > After all both of these VM operations are VM_GC_Operations. @tschatzl Thanks for pointing that out, that's an excellent point! Your comment caused me to reflect over that I have currently defined all operations as GC operations if they inherit from `VM_GC_Sync_Operation`. However the following should probably not be strictly counted as a GC activity: `VM_GC_HeapInspection`, `VM_PopulateDynamicDumpSharedSpace`, `VM_Verify`, `VM_PopulateDumpSharedSpace`. I will update the PR. > So one option is duplicating these workers in G1/Parallel too, and fix https://bugs.openjdk.org/browse/JDK-8277394. Thanks for the suggestion, I agree that we should do that to fix the root issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2978167405 From dcubed at openjdk.org Mon Jun 16 21:38:27 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 16 Jun 2025 21:38:27 GMT Subject: RFR: 8359207: Remove redundant runtime/signal/TestSigusr2.java In-Reply-To: References: Message-ID: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com> On Mon, 16 Jun 2025 09:56:47 GMT, SendaoYan wrote: > Hi all, > > The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik. Thumbs up on the code changes. "redundant" implies that the functionality is tested elsewhere. I have changed the bug's synopsis from: Remove redundant runtime/signal/TestSigusr2.java to: Remove runtime/signal/TestSigusr2.java since it is always skipped which I think is more accurate. I wonder if `SIGUSR2` was only useful on Solaris. Please use "/issue JDK-8359207" as the easiest way to sync the PR title with the synopsis. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25825#pullrequestreview-2933584282 PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2978224302 PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2978226019 From dlong at openjdk.org Mon Jun 16 23:34:43 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 16 Jun 2025 23:34:43 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v5] In-Reply-To: References: Message-ID: > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. Dean Long has updated the pull request incrementally with one additional commit since the last revision: s390 fix courtesy of Amit Kumar ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25764/files - new: https://git.openjdk.org/jdk/pull/25764/files/c1ebde09..a7d784b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764 PR: https://git.openjdk.org/jdk/pull/25764 From dlong at openjdk.org Mon Jun 16 23:34:43 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 16 Jun 2025 23:34:43 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 15:04:23 GMT, Amit Kumar wrote: >> Just FYI, s390 build is broken with this change: >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117 >> # assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration >> # >> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) >> # Problematic frame: >> # V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e >> # >> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086) >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> # >> >> >> stack trace: >> >> Stack: [0x000003ff9e580000,0x000003ff9e680000], sp=0x000003ff9e67b068, free space=1004k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e (barrierSetNMethod.cpp:196) >> v ~StubRoutines::method_entry_barrier 0x000003ff9050cd18 >> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048] >> j sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base >> j sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base >> j java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base >> j jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base >> j jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base >> j jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base >> j java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base >> j java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base >> .... > >> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0. > > Thank you Martin for the suggestion. > > @dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; > > > diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp > index e78906708af..2d663061aec 100644 > --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp > +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp > @@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { > __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes > > // Compare to current patched value: > - __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val) > + __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val) > > // Conditional Jump > __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes > diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp > index d3f6540a3ea..bb1d9ce6037 100644 > --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp > +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp > @@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator { > > // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) > __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier)); > - __ z_ltr(Z_R0_scratch, Z_RET); > + __ z_ltr(Z_RET, Z_RET); > > // VM-Call Epilogue > __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false); Thanks @offamitkumar. Could you explain the `__ z_ltr(Z_R0_scratch, Z_RET);` change, for my curiosity? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978470825 From dlong at openjdk.org Mon Jun 16 23:39:08 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 16 Jun 2025 23:39:08 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v6] In-Reply-To: References: Message-ID: > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. Dean Long has updated the pull request incrementally with one additional commit since the last revision: arm32 fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25764/files - new: https://git.openjdk.org/jdk/pull/25764/files/a7d784b2..c98f3864 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764 PR: https://git.openjdk.org/jdk/pull/25764 From dlong at openjdk.org Mon Jun 16 23:39:08 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 16 Jun 2025 23:39:08 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com> On Mon, 16 Jun 2025 13:56:30 GMT, Martin Doerr wrote: > Seems like arm32 has the same issue: > > https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199 > > The init value shouldn't have the sticky bit set. Thanks, I pushed a potential fix for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978476161 From dlong at openjdk.org Mon Jun 16 23:45:57 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 16 Jun 2025 23:45:57 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v7] In-Reply-To: References: Message-ID: > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. Dean Long has updated the pull request incrementally with one additional commit since the last revision: rename arm_with to guard_with ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25764/files - new: https://git.openjdk.org/jdk/pull/25764/files/c98f3864..3ac6dec0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=05-06 Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764 PR: https://git.openjdk.org/jdk/pull/25764 From dlong at openjdk.org Mon Jun 16 23:45:57 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 16 Jun 2025 23:45:57 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 00:48:40 GMT, Erik ?sterlund wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> remove is_sigill_not_entrant > > src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 109: > >> 107: } >> 108: >> 109: void ZBarrierSetNMethod::arm_with(nmethod* nm, int value) { > > I don't usually comment on names, but could we call this guard_with instead? We tried to stop saying "arm" about things used also for disarming and we have (hopefully) been consistent about calling that "guard" instead. Good suggestion. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2151070290 From dlong at openjdk.org Tue Jun 17 00:05:30 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 17 Jun 2025 00:05:30 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 00:54:48 GMT, Erik ?sterlund wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> remove is_sigill_not_entrant > > src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114: > >> 112: // Preserve the sticky bit >> 113: if (is_not_entrant(nm)) { >> 114: value |= not_entrant; > > Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant? > > If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier. If I understand your concern correctly, there is no race. The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section. After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way. And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2151084557 From dlong at openjdk.org Tue Jun 17 00:13:30 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 17 Jun 2025 00:13:30 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com> References: <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com> Message-ID: On Sat, 14 Jun 2025 09:23:33 GMT, Martin Doerr wrote: > Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance. For ZGC I am using a per-nmethod lock: ZLocker locker(ZNMethod::lock_for_nmethod(nm)); I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this. One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978525224 From david.holmes at oracle.com Tue Jun 17 02:36:45 2025 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Jun 2025 12:36:45 +1000 Subject: AbstractInterpreter::is_not_reached wrongfully assumes reachability for invokedynamic In-Reply-To: <955a583d795914024aaa0d78ef35e274@xdark.dev> References: <955a583d795914024aaa0d78ef35e274@xdark.dev> Message-ID: <11f148b6-c514-4147-afbb-df1a5b8eada0@oracle.com> FYI: https://bugs.openjdk.org/browse/JDK-8359057 David On 9/06/2025 4:29 am, me at xdark.dev wrote: > > Greetings, > Since JDK-8301995 , the > code to in AbstractInterpreter::is_not_reached(...) for invokedynamic > looks like this: > ``` > ? ? ? case Bytecodes::_invokedynamic: { > ? ? ? ? assert(invoke_bc.has_index_u4(code), "sanity"); > ? ? ? ? int method_index = invoke_bc.get_index_u4(code); > ? ? ? ? return cpool->resolved_indy_entry_at(method_index)->is_resolved(); > ? ? ? } > ``` > Is this a bug? Before the change, the code looked like this: > ``` > ? ? ? case Bytecodes::_invokedynamic: { > ? ? ? ? assert(invoke_bc.has_index_u4(code), "sanity"); > ? ? ? ? int method_index = invoke_bc.get_index_u4(code); > ? ? ? ? return > cpool->invokedynamic_cp_cache_entry_at(method_index)->is_f1_null(); > ? ? ? } > ``` > The comment for this method says: > ``` > // Return true if the interpreter can prove that the given bytecode has > // not yet been executed (in Java semantics, not in actual operation). > ``` > Shouldn't the is_resolved check be negated? The code is two years old > since this change, and it seems like a regression. I'm unable to > submit a patch if that is the case, so, if this is a bug, It would be > great if someone would fix this. > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syan at openjdk.org Tue Jun 17 02:46:28 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 17 Jun 2025 02:46:28 GMT Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is always skipped In-Reply-To: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com> References: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com> Message-ID: <9YWxsDF37yy-L-ZuDgMq0-9qahrgtXBfu5M_aWtoqK0=.fe58d62b-640c-4754-9e41-19f7f3ec9892@github.com> On Mon, 16 Jun 2025 21:34:28 GMT, Daniel D. Daugherty wrote: >> Hi all, >> >> The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik. > > Please use "/issue JDK-8359207" as the easiest way to sync the PR title with the synopsis. Thanks for the correction and review @dcubed-ojdk ------------- PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2978745676 From amitkumar at openjdk.org Tue Jun 17 03:46:33 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 17 Jun 2025 03:46:33 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: <-0Y5IM8MHOmPZpTHRGKK5hnBLA5TyRV871YLJ1XnSAI=.027d1976-faf5-40f7-a7d0-fa05d6b986b4@github.com> On Mon, 16 Jun 2025 15:04:23 GMT, Amit Kumar wrote: >> Just FYI, s390 build is broken with this change: >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117 >> # assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration >> # >> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) >> # Problematic frame: >> # V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e >> # >> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086) >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> # >> >> >> stack trace: >> >> Stack: [0x000003ff9e580000,0x000003ff9e680000], sp=0x000003ff9e67b068, free space=1004k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x40b196] BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e (barrierSetNMethod.cpp:196) >> v ~StubRoutines::method_entry_barrier 0x000003ff9050cd18 >> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048] >> j sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base >> j sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base >> j java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base >> j jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base >> j jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base >> j jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base >> j java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base >> j java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base >> .... > >> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0. > > Thank you Martin for the suggestion. > > @dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; > > > diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp > index e78906708af..2d663061aec 100644 > --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp > +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp > @@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { > __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes > > // Compare to current patched value: > - __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val) > + __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val) > > // Conditional Jump > __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes > diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp > index d3f6540a3ea..bb1d9ce6037 100644 > --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp > +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp > @@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator { > > // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) > __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier)); > - __ z_ltr(Z_R0_scratch, Z_RET); > + __ z_ltr(Z_RET, Z_RET); > > // VM-Call Epilogue > __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false); > Thanks @offamitkumar. Could you explain the `__ z_ltr(Z_R0_scratch, Z_RET);` change, for my curiosity? Thanks. `ltr` instruction stands for "load and test" (32 bit). Initially we were loading the value from `Z_RET` to `Z_R0_scratch` and then it will be compared against 0. But in this case there is no requirement of loading the value in Z_R0, as it's not being used further. So we can load the value again in `Z_RET` and the compare it against 0. There is nothing wrong in previous solution, it's just killing Z_R0 for nothing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978824615 From iklam at openjdk.org Tue Jun 17 04:39:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 17 Jun 2025 04:39:33 GMT Subject: [jdk25] RFR: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 09:19:56 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev. >> >> Thanks! > > Marked as reviewed by shade (Reviewer). Thanks @shipilev for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25815#issuecomment-2978906549 From iklam at openjdk.org Tue Jun 17 04:39:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 17 Jun 2025 04:39:33 GMT Subject: [jdk25] Integrated: 8355556: JVM crash because archived method handle intrinsics are not restored In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 01:59:16 GMT, Ioi Lam wrote: > Hi all, > > This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev. > > Thanks! This pull request has now been integrated. Changeset: 75370018 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/753700182dfd0d0f4c22067f4e9aa77c138540a7 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8355556: JVM crash because archived method handle intrinsics are not restored Reviewed-by: shade Backport-of: 366650a438d046f3da5b490c42e37faaf3a9abc5 ------------- PR: https://git.openjdk.org/jdk/pull/25815 From dholmes at openjdk.org Tue Jun 17 04:54:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 04:54:32 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac In-Reply-To: References: Message-ID: <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com> On Mon, 16 Jun 2025 09:46:11 GMT, Sergey Chernyshev wrote: > Hi all, > > I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux. > > This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged. > > Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root. > > Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output. > > The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_/ files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders///T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories(). > > The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java and create .attach files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_, which is in the target process's temp directory, exactly where it expects to see the .java in return on sending SIGQUIT to the target VM. > > Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_ folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the and to the JVM being attached to. > > The pa... src/hotspot/os/posix/perfMemory_posix.cpp line 133: > 131: // > 132: > 133: #ifdef __APPLE__ This is a bit too much non-posix code in the posix file IMO. I'd rather see a `MACOS_ONLY` call later on to something defined in `os_bsd.cpp` for macOS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2151315769 From dholmes at openjdk.org Tue Jun 17 05:49:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 05:49:31 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 09:17:05 GMT, Jonas Norlinder wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Add CPU time tracking for string deduplication to log_gc_vtime > > src/hotspot/share/runtime/vmThread.cpp line 278: > >> 276: PerfTraceTime vm_op_timer(perf_accumulated_vm_operation_time()); >> 277: HOTSPOT_VMOPS_BEGIN( >> 278: (char *) op->name(), strlen(op->name()), > > @dholmes-ora given that I'm editing `VMThread::evaluate_operation` and your comments about code style - do you want me to also change this type cast to `(char*)` to align with the preferred style? Please do. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2151372297 From dholmes at openjdk.org Tue Jun 17 05:59:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 05:59:30 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 11:49:56 GMT, Jonas Norlinder wrote: > What threads: ... Thanks for that. Once the details have stabilized I suggest adding this summary of operation to the JBS issue as well. I will let GC folk do the formal reviews/approvals here, but this looks quite reasonable to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2979038213 From dholmes at openjdk.org Tue Jun 17 05:59:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 05:59:31 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v8] In-Reply-To: References: Message-ID: <9L-KW83n2k0foCwz6l7a2p5mMqkhrY6eigZL9FyRscU=.b8528248-522f-421d-8eae-184261a387d7@github.com> On Mon, 16 Jun 2025 12:50:17 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > operation_is_gc -> is_gc_operation per @stefank suggestion src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 29: > 27: #include "logging/log.hpp" > 28: #include "memory/universe.hpp" > 29: #include "runtime/vmThread.hpp" Nit: if you put this in the .hpp file you can do away with the forward decl for VMThread that is in there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2151383344 From dholmes at openjdk.org Tue Jun 17 06:16:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 06:16:28 GMT Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is always skipped In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 09:56:47 GMT, SendaoYan wrote: > Hi all, > > The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik. LGTM2. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25825#pullrequestreview-2934260769 From dholmes at openjdk.org Tue Jun 17 06:16:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 06:16:29 GMT Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is always skipped In-Reply-To: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com> References: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com> Message-ID: <9dqpkeFuR93-ZwLXC_ckQCsq0x6uSM0xHl4_Bp216Z8=.d0f9e5e4-b564-4b1e-b923-49207841b331@github.com> On Mon, 16 Jun 2025 21:33:38 GMT, Daniel D. Daugherty wrote: > I wonder if `SIGUSR2` was only useful on Solaris. IIRC only testable on Solaris because there we had a special dedicated signal for suspend/resume. On all the *X platforms SIGUSR2 is used as SR_signum, and so can't be tested by this test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2979071810 From dholmes at openjdk.org Tue Jun 17 06:22:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 06:22:28 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: References: Message-ID: <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com> On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev wrote: > A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". > > I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` Are there no tests that enable this flag and so would need updating to unlock it correctly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2979086278 From ktakakuri at openjdk.org Tue Jun 17 07:54:35 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Tue, 17 Jun 2025 07:54:35 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v8] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 08:21:08 GMT, Kazuhisa Takakuri wrote: >> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. >> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. >> After this fix, I verified that the test passed. >> >> https://github.com/openjdk/jdk/pull/22142 >> I refer to this fix. >> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. >> >> Thanks. > > Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: > > 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2979316887 From mbaesken at openjdk.org Tue Jun 17 08:21:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 17 Jun 2025 08:21:38 GMT Subject: RFR: 8359423: Improve error message in case of missing jsa shared archive Message-ID: In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present, we get this message/error : Error occurred during initialization of VM Unable to use shared archive. The error message could be a little improved, e.g. telling what jsa file is not present . For example ./images/jdk/bin/java -Xshare:on -version [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed Error occurred during initialization of VM Unable to use shared archive (unrecoverable archive loading error). ------------- Commit messages: - JDK-8359423 Changes: https://git.openjdk.org/jdk/pull/25846/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25846&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359423 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25846.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25846/head:pull/25846 PR: https://git.openjdk.org/jdk/pull/25846 From shade at openjdk.org Tue Jun 17 08:32:32 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 08:32:32 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com> References: <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com> Message-ID: <7M5JVZlsjRQF27BMbg9mLXdG2CkltFIWz8Oklyb0tBs=.5b10c3ac-89d8-4ba0-9bb3-1632d3f51563@github.com> On Tue, 17 Jun 2025 06:19:59 GMT, David Holmes wrote: > Are there no tests that enable this flag and so would need updating to unlock it correctly? Yeah, there are no tests for this flag. The flag was a late Leyden addition, and it defaults to `true` in Leyden/premain, so we know it performs well enough. But for mainline, we should really have a sanity test, let me do it here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2979434585 From shade at openjdk.org Tue Jun 17 08:53:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 08:53:16 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic In-Reply-To: <7M5JVZlsjRQF27BMbg9mLXdG2CkltFIWz8Oklyb0tBs=.5b10c3ac-89d8-4ba0-9bb3-1632d3f51563@github.com> References: <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com> <7M5JVZlsjRQF27BMbg9mLXdG2CkltFIWz8Oklyb0tBs=.5b10c3ac-89d8-4ba0-9bb3-1632d3f51563@github.com> Message-ID: On Tue, 17 Jun 2025 08:29:33 GMT, Aleksey Shipilev wrote: > Yeah, there are no tests for this flag. The flag was a late Leyden addition, and it defaults to `true` in Leyden/premain, so we know it performs well enough. But for mainline, we should really have a sanity test, let me do it here. Added a sanity test. Passes Linux x86_64 server fastdebug/release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2979494614 From shade at openjdk.org Tue Jun 17 08:53:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 08:53:16 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v2] In-Reply-To: References: Message-ID: > A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". > > I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25799/files - new: https://git.openjdk.org/jdk/pull/25799/files/c00fef1b..c62f367f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25799&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25799&range=00-01 Stats: 101 lines in 1 file changed: 101 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25799.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25799/head:pull/25799 PR: https://git.openjdk.org/jdk/pull/25799 From azafari at openjdk.org Tue Jun 17 10:17:06 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 17 Jun 2025 10:17:06 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com> > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixes to a few failures. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/e303ee7c..815092d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=40 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=39-40 Stats: 49 lines in 6 files changed: 19 ins; 13 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From aturbanov at openjdk.org Tue Jun 17 10:22:27 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 17 Jun 2025 10:22:27 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 09:46:11 GMT, Sergey Chernyshev wrote: > Hi all, > > I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux. > > This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged. > > Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root. > > Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output. > > The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_/ files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders///T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories(). > > The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java and create .attach files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_, which is in the target process's temp directory, exactly where it expects to see the .java in return on sending SIGQUIT to the target VM. > > Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_ folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the and to the JVM being attached to. > > The pa... src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 242: > 240: for (String dir : platformSupport.getTemporaryDirectories(pid)) { > 241: Path fullPath = Path.of(dir, HSPERFDATA_PREFIX + user, String.valueOf(pid)); > 242: if(Files.exists(fullPath)) { Suggestion: if (Files.exists(fullPath)) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2151898308 From mdoerr at openjdk.org Tue Jun 17 12:52:34 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 17 Jun 2025 12:52:34 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com> References: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com> Message-ID: On Mon, 16 Jun 2025 23:35:43 GMT, Dean Long wrote: > > Seems like arm32 has the same issue: > > https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199 > > > > The init value shouldn't have the sticky bit set. > > Thanks, I pushed a potential fix for that. Unfortunately, 0xBEAFDEAD also has the MSB set. Shouldn't we better use 0 like on all other platforms? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2980261201 From dholmes at openjdk.org Tue Jun 17 13:01:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jun 2025 13:01:28 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v2] In-Reply-To: References: Message-ID: <_Ce1MuI4HkjVyZQh8qxL154B-EwBd4BuioSFiYI4nIQ=.557e82a2-65d9-498f-a95e-fea92264194b@github.com> On Tue, 17 Jun 2025 08:53:16 GMT, Aleksey Shipilev wrote: >> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". >> >> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `runtime/cds` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Test Sanity test seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2935569664 From syan at openjdk.org Tue Jun 17 13:52:36 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 17 Jun 2025 13:52:36 GMT Subject: Integrated: 8359207: Remove runtime/signal/TestSigusr2.java since it is always skipped In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 09:56:47 GMT, SendaoYan wrote: > Hi all, > > The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik. This pull request has now been integrated. Changeset: 51877f56 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/51877f568ba84a8ec7721656571c90c5eb952eb3 Stats: 43 lines in 2 files changed: 0 ins; 41 del; 2 mod 8359207: Remove runtime/signal/TestSigusr2.java since it is always skipped Reviewed-by: dcubed, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25825 From syan at openjdk.org Tue Jun 17 13:52:35 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 17 Jun 2025 13:52:35 GMT Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is always skipped In-Reply-To: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com> References: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com> Message-ID: On Mon, 16 Jun 2025 21:34:28 GMT, Daniel D. Daugherty wrote: >> Hi all, >> >> The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik. > > Please use "/issue JDK-8359207" as the easiest way to sync the PR title with the synopsis. Thanks @dcubed-ojdk @dholmes-ora for the correction and reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2980463950 From cstein at openjdk.org Tue Jun 17 14:03:38 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 17 Jun 2025 14:03:38 GMT Subject: Integrated: 8357862: Java argument file is parsed unexpectedly with trailing comment In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein wrote: > Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign. > > The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files): > > Use the number sign `#` in the argument file to identify comments. > All characters following the `#` are ignored until the end of line. > > There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters. This pull request has now been integrated. Changeset: 21b72dea Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/21b72dea7805357b3644161d1a158c52f49d0e6e Stats: 40 lines in 2 files changed: 29 ins; 7 del; 4 mod 8357862: Java argument file is parsed unexpectedly with trailing comment Co-authored-by: Stuart Marks Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/25589 From jsjolen at openjdk.org Tue Jun 17 14:04:48 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 17 Jun 2025 14:04:48 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41] In-Reply-To: <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com> Message-ID: On Tue, 17 Jun 2025 10:17:06 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes to a few failures. LGTM! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2935814156 From kvn at openjdk.org Tue Jun 17 14:59:31 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 17 Jun 2025 14:59:31 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 08:53:16 GMT, Aleksey Shipilev wrote: >> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". >> >> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `runtime/cds` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Test May be modify `aotProfile/AOTProfileFlags.java` instead. test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCompileEagerly.java line 1: > 1: /* There is `aotProfile` directory for training data testing. test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCompileEagerly.java line 27: > 25: > 26: /* > 27: * @test Missing ` * @bug 8359436` ------------- PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2936031765 PR Review Comment: https://git.openjdk.org/jdk/pull/25799#discussion_r2152492526 PR Review Comment: https://git.openjdk.org/jdk/pull/25799#discussion_r2152487114 From eastigeevich at openjdk.org Tue Jun 17 15:49:28 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 17 Jun 2025 15:49:28 GMT Subject: RFR: 8359423: Improve error message in case of missing jsa shared archive In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 08:17:19 GMT, Matthias Baesken wrote: > In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present, > we get this message/error : > > > Error occurred during initialization of VM > Unable to use shared archive. > > > The error message could be a little improved, e.g. telling what jsa file is not present . > For example > > > ./images/jdk/bin/java -Xshare:on -version > [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed > Error occurred during initialization of VM > Unable to use shared archive (unrecoverable archive loading error). src/hotspot/share/cds/metaspaceShared.cpp line 1388: > 1386: } > 1387: if (RequireSharedSpaces && has_failed) { > 1388: MetaspaceShared::unrecoverable_loading_error("Unable to map shared spaces, but they were required"); If you want the message to be more specific, you might need to add whether the failed loading was dynamic or static. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25846#discussion_r2152609002 From eastigeevich at openjdk.org Tue Jun 17 16:08:27 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 17 Jun 2025 16:08:27 GMT Subject: RFR: 8359423: Improve error message in case of missing jsa shared archive In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 08:17:19 GMT, Matthias Baesken wrote: > In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present, > we get this message/error : > > > Error occurred during initialization of VM > Unable to use shared archive. > > > The error message could be a little improved, e.g. telling what jsa file is not present . > For example > > > ./images/jdk/bin/java -Xshare:on -version > [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed > Error occurred during initialization of VM > Unable to use shared archive (unrecoverable archive loading error). src/hotspot/share/cds/metaspaceShared.cpp line 1274: > 1272: vm_exit_during_initialization("Unable to use AOT cache.", nullptr); > 1273: } else { > 1274: vm_exit_during_initialization("Unable to use shared archive (unrecoverable archive loading error).", nullptr); Who not to use message here instead of 'unrecoverable archive loading error'? The default message is 'unrecoverable error'. The default message can be updated to 'unrecoverable archive loading error'. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25846#discussion_r2152647530 From gziemski at openjdk.org Tue Jun 17 16:46:48 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 17 Jun 2025 16:46:48 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41] In-Reply-To: <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com> Message-ID: On Tue, 17 Jun 2025 10:17:06 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes to a few failures. Small changes (copyright years) and one question, otherwise LGTM. Nice! Marked as reviewed by gziemski (Reviewer). src/hotspot/share/nmt/regionsTree.cpp line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Copyright year src/hotspot/share/nmt/regionsTree.hpp line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Copyright year test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 259: > 257: static void test_add_committed_region_overlapping() { > 258: RegionsTree* rtree = VirtualMemoryTracker::Instance::tree(); > 259: rtree->tree().remove_all(); Why are we calling `remove_all()` right after we create the tree? ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2936231261 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2936387120 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2152711203 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2152711676 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2152621722 From coleenp at openjdk.org Tue Jun 17 17:18:38 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 17 Jun 2025 17:18:38 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper Message-ID: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. Tested with test. ------------- Commit messages: - 8359707: Add classfile modification code to RedefineClassHelper Changes: https://git.openjdk.org/jdk/pull/25857/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359707 Stats: 98 lines in 2 files changed: 53 ins; 43 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From mdonovan at openjdk.org Tue Jun 17 17:36:31 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 17 Jun 2025 17:36:31 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com> References: <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com> Message-ID: On Tue, 10 Jun 2025 07:47:29 GMT, Alice Pellegrini wrote: >> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ?? > > To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command}` > > > git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l > 351 > > > Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about) > > > I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg > > --- > > That said, if there are multiple OutputAnalyzers going in a single test, then it makes perfect sense to have (or at least use) a constructor argument > But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? I'm not sure if I completely understand your question. A lot of tests use the `test.debug` system property to enable more verbose test output. It's enabled when someone runs the test e.g., `jtreg -Dtest.debug=true ...` As you pointed out, a lot of tests may not care if the subprocess's output is cached or not, but for those that do, having to specify a second property could be onerous and using the same `test.debug` property inside OutputBuffer could result in unexpected output. If the OutputAnalyzer ctor took a boolean , a test could enable (or not) with something like `new OutputAnalyzer(childProc, Boolean.getBoolean("test.debug"))` > I'm not sure adding additional parameters also to that code is an ideal solution, There are two constructors that take Process objects as arguments. I was thinking that you could overload them to take the extra argument. public OutputAnalyzer(Process process, Charset cs, boolean flushOutput) public OutputAnalyzer(Process process, boolean flushOutput) None of the existing tests would be affected and those tests that could benefit from inline output could specify it as needed. You're right that the use of OutputAnalyzer is usually indirect so that would cause some other code to be changed as well, but it only has to change when it becomes necessary to enable it. (And it can be updated in the same way i.e., overloading the methods to take an extra argument.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2152810288 From dlong at openjdk.org Tue Jun 17 20:55:29 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 17 Jun 2025 20:55:29 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com> Message-ID: <87D1GHpnuO66YKnlxRh6JOlp7AZoZxhLBDbCpUG230A=.9119d110-62ba-4083-9a85-9bf78f5b462b@github.com> On Tue, 17 Jun 2025 12:50:18 GMT, Martin Doerr wrote: > > > Seems like arm32 has the same issue: > > > https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199 > > > > > > The init value shouldn't have the sticky bit set. > > > > > > Thanks, I pushed a potential fix for that. > > Unfortunately, 0xBEAFDEAD also has the MSB set. Shouldn't we better use 0 like on all other platforms? Oops, I was tripped up trying to be clever. Yes, I'm fine with using 0. I'll fix it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2981800170 From dlong at openjdk.org Tue Jun 17 20:59:46 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 17 Jun 2025 20:59:46 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v8] In-Reply-To: References: Message-ID: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. Dean Long has updated the pull request incrementally with one additional commit since the last revision: 2nd try at arm fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25764/files - new: https://git.openjdk.org/jdk/pull/25764/files/3ac6dec0..3e306dde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764 PR: https://git.openjdk.org/jdk/pull/25764 From sspitsyn at openjdk.org Tue Jun 17 22:33:28 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 17 Jun 2025 22:33:28 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Tue, 17 Jun 2025 17:11:01 GMT, Coleen Phillimore wrote: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. This looks reasonable. I've posted one nit suggestion. test/lib/RedefineClassHelper.java line 104: > 102: */ > 103: > 104: public static byte[] replaceAllStrings(ClassLoader loader, String oldString, String newString) throws Exception { Nit: I'd suggest to rename parameters: `oldString` => `oldClassName` `newString` => `newClassName` Alternatively, it is possible to pass bytecodes buffer instead of class loader and keep `oldString` and `newString` as before. ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2937246161 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2153274007 From dholmes at openjdk.org Wed Jun 18 04:43:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 18 Jun 2025 04:43:29 GMT Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2] In-Reply-To: References: Message-ID: <_aliNvujYU-gs7CUS7oB8VPK595xV4OLnd82vJwYTIY=.6b041c7e-3907-4217-b8ef-a59404ac0a08@github.com> On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote: >> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation. >> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer. >> >> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation. > > Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print > - Update test/lib/jdk/test/lib/process/OutputBuffer.java > > Co-authored-by: Chen Liang > - Initial working solution > A lot of tests use the test.debug system property to enable more verbose test output. It's enabled when someone runs the test e.g., jtreg -Dtest.debug=true ... I see a few tests that do that, nearly all of which are network tests. It is not something I was familiar with. But it doesn't seem right to me that a particular test would use that property to change the behaviour of `OutputAnalyzer`. I also don't think the test should have to opt-in to this kind of behaviour rather than it being directly controlled by the person running the tests. To that end I would see `OutputAnalyzer` examining a specific property, e.g. `OutputAnalyzer.printToStdStreams` to control this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2982650756 From mdoerr at openjdk.org Wed Jun 18 08:33:37 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 18 Jun 2025 08:33:37 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v8] In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> References: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> Message-ID: On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > 2nd try at arm fix Recent changes look good. Thanks! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2938255719 From yzheng at openjdk.org Wed Jun 18 08:51:03 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 18 Jun 2025 08:51:03 GMT Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled Message-ID: When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message: Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed. This PR skips reporting loading error when CDS and AOT loggings are disabled. ------------- Commit messages: - CDS and AOT can cause buffer truncation warning even when logging is disabled Changes: https://git.openjdk.org/jdk/pull/25866/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25866&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358686 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25866/head:pull/25866 PR: https://git.openjdk.org/jdk/pull/25866 From azafari at openjdk.org Wed Jun 18 09:04:36 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 18 Jun 2025 09:04:36 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v42] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/815092d2..ac151586 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=41 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=40-41 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From dnsimon at openjdk.org Wed Jun 18 09:07:29 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 18 Jun 2025 09:07:29 GMT Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng wrote: > When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message: > > Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed. > > This PR skips reporting loading error when CDS and AOT loggings are disabled. LGTM ------------- Marked as reviewed by dnsimon (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25866#pullrequestreview-2938374154 From jsjolen at openjdk.org Wed Jun 18 09:10:49 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 18 Jun 2025 09:10:49 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v42] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Wed, 18 Jun 2025 09:04:36 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > copyright years Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2938381625 From azafari at openjdk.org Wed Jun 18 09:10:51 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 18 Jun 2025 09:10:51 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com> Message-ID: <00eARElwnxkitXuqWa5uDdul1WafVU6fUGcmnIOJIV4=.7d9fc71c-be40-468d-8f14-adb98f4e3eb6@github.com> On Tue, 17 Jun 2025 16:37:22 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixes to a few failures. > > src/hotspot/share/nmt/regionsTree.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. > > Copyright year Done. > src/hotspot/share/nmt/regionsTree.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. > > Copyright year Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2154077488 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2154077012 From azafari at openjdk.org Wed Jun 18 09:14:47 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 18 Jun 2025 09:14:47 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com> Message-ID: On Tue, 17 Jun 2025 15:53:04 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixes to a few failures. > > test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 259: > >> 257: static void test_add_committed_region_overlapping() { >> 258: RegionsTree* rtree = VirtualMemoryTracker::Instance::tree(); >> 259: rtree->tree().remove_all(); > > Why are we calling `remove_all()` right after we create the tree? We are not creating the tree here. We just retrieve it from the Instance of VMT. Since the tree is also visible to other tests (it is static and not created per test), any changes in other tests will be visible here by this test. This is not as expected in the design of the tests (tests assume that tree is empty at the beginning of the test). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2154087590 From azafari at openjdk.org Wed Jun 18 09:20:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 18 Jun 2025 09:20:09 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v43] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits: - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - copyright years - fixes to a few failures. - changes after merge - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - fixes after merge with master. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - more reviews. - review comments applied - ... and 79 more: https://git.openjdk.org/jdk/compare/2b94b70e...66ddc675 ------------- Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=42 Stats: 1459 lines in 27 files changed: 571 ins; 567 del; 321 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From eosterlund at openjdk.org Wed Jun 18 11:36:30 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jun 2025 11:36:30 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 00:02:29 GMT, Dean Long wrote: >> src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114: >> >>> 112: // Preserve the sticky bit >>> 113: if (is_not_entrant(nm)) { >>> 114: value |= not_entrant; >> >> Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant? >> >> If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier. > > If I understand your concern correctly, there is no race. The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section. After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way. > And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level. My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code. Does that make sense? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2154370247 From azafari at openjdk.org Wed Jun 18 11:40:54 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 18 Jun 2025 11:40:54 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Tue, 25 Feb 2025 15:40:54 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> reviews applied. > > How would I go about verifying the performance gain? You mentioned previously that you wrote a microbenchmark for testing this? Thanks for reviews @gerard-ziemski and @jdksjolen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2983833167 From azafari at openjdk.org Wed Jun 18 11:40:56 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 18 Jun 2025 11:40:56 GMT Subject: Integrated: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari wrote: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. This pull request has now been integrated. Changeset: 547ce030 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/547ce0301684fdebe95ce2e8e195a019bcefe493 Stats: 1459 lines in 27 files changed: 571 ins; 567 del; 321 mod 8337217: Port VirtualMemoryTracker to use VMATree Reviewed-by: jsjolen, gziemski ------------- PR: https://git.openjdk.org/jdk/pull/20425 From coleenp at openjdk.org Wed Jun 18 11:52:17 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 18 Jun 2025 11:52:17 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add a byte buffer version and rename parameters. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/3654034f..6bc1ca59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=00-01 Stats: 23 lines in 1 file changed: 13 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From coleenp at openjdk.org Wed Jun 18 11:52:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 18 Jun 2025 11:52:18 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <9JI9OF3xPXV3uMSXT4Upg7lQCPgfSy32jCd8T7Z62rU=.89eb5211-0b7e-4b80-98f0-aecea4e6365c@github.com> On Tue, 17 Jun 2025 22:29:24 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a byte buffer version and rename parameters. > > test/lib/RedefineClassHelper.java line 104: > >> 102: */ >> 103: >> 104: public static byte[] replaceAllStrings(ClassLoader loader, String oldString, String newString) throws Exception { > > Nit: I'd suggest to rename parameters: > `oldString` => `oldClassName` > `newString` => `newClassName` > > Alternatively, it is possible to pass bytecodes buffer instead of class loader and keep `oldString` and `newString` as before. I wanted this code to also read bytecodes off the disk and not the caller do that either. The code for getBytecodes or very similar is duplicated all over the tests also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2154384879 From coleenp at openjdk.org Wed Jun 18 11:52:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 18 Jun 2025 11:52:18 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: <9JI9OF3xPXV3uMSXT4Upg7lQCPgfSy32jCd8T7Z62rU=.89eb5211-0b7e-4b80-98f0-aecea4e6365c@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <9JI9OF3xPXV3uMSXT4Upg7lQCPgfSy32jCd8T7Z62rU=.89eb5211-0b7e-4b80-98f0-aecea4e6365c@github.com> Message-ID: On Wed, 18 Jun 2025 11:41:09 GMT, Coleen Phillimore wrote: >> test/lib/RedefineClassHelper.java line 104: >> >>> 102: */ >>> 103: >>> 104: public static byte[] replaceAllStrings(ClassLoader loader, String oldString, String newString) throws Exception { >> >> Nit: I'd suggest to rename parameters: >> `oldString` => `oldClassName` >> `newString` => `newClassName` >> >> Alternatively, it is possible to pass bytecodes buffer instead of class loader and keep `oldString` and `newString` as before. > > I wanted this code to also read bytecodes off the disk and not the caller do that either. The code for getBytecodes or very similar is duplicated all over the tests also. I can add a byte buffer version though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2154398739 From jsjolen at openjdk.org Wed Jun 18 12:16:38 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 18 Jun 2025 12:16:38 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker [v3] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 09:23:24 GMT, Afshin Zafari wrote: >> Renamed usage of 'category' for 'MemTag' cases. > > Afshin Zafari 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: > > - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag > - fixed a missed test. > - user-facing terms remained as 'category' > - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker Marked as reviewed by jsjolen (Reviewer). test/hotspot/jtreg/runtime/NMT/MallocLimitTest.java line 3: > 1: /* > 2: * Copyright (c) 2022 SAP SE. All rights reserved. > 3: * Copyright (c) 2022, 2025, Oracle and/or its affiliates. All rights reserved. Revert this copyright notice. ------------- PR Review: https://git.openjdk.org/jdk/pull/25226#pullrequestreview-2938961864 PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2154444880 From jwilhelm at openjdk.org Wed Jun 18 12:59:30 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 18 Jun 2025 12:59:30 GMT Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> Message-ID: On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin wrote: > Hi everyone, > > #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function. Looks good to me. ------------- Marked as reviewed by jwilhelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25722#pullrequestreview-2939108367 From cnorrbin at openjdk.org Wed Jun 18 14:01:43 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 18 Jun 2025 14:01:43 GMT Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> Message-ID: On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin wrote: > Hi everyone, > > #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25722#issuecomment-2984338348 From cnorrbin at openjdk.org Wed Jun 18 14:01:43 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 18 Jun 2025 14:01:43 GMT Subject: Integrated: 8358891: Remove the PerfDataSamplingIntervalFunc code In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com> Message-ID: <-yjwc87ksQ3nPpufDK2uuKpRYtkHgsFDYB5hHs6h40I=.455c89e4-c5ef-45b9-aa9d-b6abdfddceb8@github.com> On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin wrote: > Hi everyone, > > #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function. This pull request has now been integrated. Changeset: cf789258 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/cf78925859dd2640b3c2500fc6be8b5bb308d96e Stats: 13 lines in 2 files changed: 0 ins; 13 del; 0 mod 8358891: Remove the PerfDataSamplingIntervalFunc code Reviewed-by: shade, jwilhelm ------------- PR: https://git.openjdk.org/jdk/pull/25722 From schernyshev at openjdk.org Wed Jun 18 16:40:53 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 18 Jun 2025 16:40:53 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v2] In-Reply-To: References: Message-ID: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com> > Hi all, > > I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux. > > This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged. > > Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root. > > Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output. > > The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_/ files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders///T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories(). > > The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java and create .attach files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_, which is in the target process's temp directory, exactly where it expects to see the .java in return on sending SIGQUIT to the target VM. > > Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_ folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the and to the JVM being attached to. > > The pa... Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Co-authored-by: Andrey Turbanov - addressed review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25824/files - new: https://git.openjdk.org/jdk/pull/25824/files/9fd3781d..779a1b35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=00-01 Stats: 155 lines in 4 files changed: 79 ins; 74 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824 PR: https://git.openjdk.org/jdk/pull/25824 From schernyshev at openjdk.org Wed Jun 18 16:40:53 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 18 Jun 2025 16:40:53 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v2] In-Reply-To: <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com> References: <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com> Message-ID: On Tue, 17 Jun 2025 04:51:58 GMT, David Holmes wrote: >> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> >> Co-authored-by: Andrey Turbanov >> - addressed review comments > > src/hotspot/os/posix/perfMemory_posix.cpp line 133: > >> 131: // >> 132: >> 133: #ifdef __APPLE__ > > This is a bit too much non-posix code in the posix file IMO. I'd rather see a `MACOS_ONLY` call later on to something defined in `os_bsd.cpp` for macOS. Thanks @dholmes-ora , I moved the function to `os_bsd.cpp` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2155061182 From dcubed at openjdk.org Wed Jun 18 18:01:34 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 18 Jun 2025 18:01:34 GMT Subject: RFR: 8319589: Attach from root to a user java process not supported in Mac [v2] In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com> References: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com> Message-ID: On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev wrote: >> Hi all, >> >> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux. >> >> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged. >> >> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root. >> >> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output. >> >> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_/ files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders///T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories(). >> >> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java and create .attach files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_, which is in the target process's temp directory, exactly where it expects to see the .java in return on sending SIGQUIT to the target VM. >> >> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_ folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the and to the ... > > Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > > Co-authored-by: Andrey Turbanov > - addressed review comments For macOS questions, I usually ping Gerard (@gerard-ziemski). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-2985227813 From mdoerr at openjdk.org Wed Jun 18 19:59:29 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 18 Jun 2025 19:59:29 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v8] In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> References: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> Message-ID: <7dqmRsrYN1O1zVQSYvFbVpmjSSABHnw7dL8QXSkrOtE=.eceed621-7482-436e-a999-73b6d2611616@github.com> On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > 2nd try at arm fix Unfortunately, there's a merge conflict, now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2985526434 From mdoerr at openjdk.org Wed Jun 18 19:59:30 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 18 Jun 2025 19:59:30 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 11:34:02 GMT, Erik ?sterlund wrote: >> If I understand your concern correctly, there is no race. The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section. After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way. >> And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level. > > My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code. > Does that make sense? Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155390909 From iklam at openjdk.org Wed Jun 18 20:23:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 18 Jun 2025 20:23:29 GMT Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng wrote: > When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message: > > Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed. > > This PR skips reporting loading error when CDS and AOT loggings are disabled. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25866#pullrequestreview-2940556792 From eosterlund at openjdk.org Wed Jun 18 20:28:29 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 Jun 2025 20:28:29 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 19:56:27 GMT, Martin Doerr wrote: >> My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code. >> Does that make sense? > > Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier. Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155434971 From dlong at openjdk.org Thu Jun 19 00:22:30 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 19 Jun 2025 00:22:30 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 20:25:44 GMT, Erik ?sterlund wrote: >> Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier. > > Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think? I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand. Arming the barrier is not guaranteed to be visible until there is a safepoint. Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155757120 From azafari at openjdk.org Thu Jun 19 09:19:30 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 19 Jun 2025 09:19:30 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr Message-ID: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> The test expects that two disjunct regions are reserved but checked it incompletely. It is fixed by reserving a region with triple required size and then released the middle part. Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. Tested local linux-x64-debug. ------------- Commit messages: - 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr Changes: https://git.openjdk.org/jdk/pull/25894/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25894&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359959 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25894.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25894/head:pull/25894 PR: https://git.openjdk.org/jdk/pull/25894 From dholmes at openjdk.org Thu Jun 19 12:31:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jun 2025 12:31:44 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: On Thu, 19 Jun 2025 09:14:14 GMT, Afshin Zafari wrote: > The test expects that two disjunct regions are reserved but checked it incompletely. > It is fixed by reserving a region with triple required size and then released the middle part. > > Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. > > Tested local linux-x64-debug. test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 65: > 63: > 64: // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for > 65: // this test, we want to see two disjunct mappings. The comment no longer seems quite accurate. test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 66: > 64: // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for > 65: // this test, we want to see two disjunct mappings. > 66: if ((addr2 == addr1 + reserveSize) || (addr2 + reserveSize == addr1)) { Suggestion: if ((addr2 == addr1 + reserveSize) || (addr2 == addr1 - reserveSize)) { I find this formulation somewhat clearer in indicating `addr2` is adjacent after, or adjacent before `addr1`. test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 72: > 70: > 71: wb.NMTReleaseMemory(addr1, reserveSize); > 72: wb.NMTReleaseMemory(addr2, reserveSize); Just to be clear we are only releasing the original mappings to keep things consistent? And we could do this before reserving the new three region mapping - right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156896654 PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156894465 PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156901328 From azafari at openjdk.org Thu Jun 19 12:50:20 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 19 Jun 2025 12:50:20 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v2] In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: > The test expects that two disjunct regions are reserved but checked it incompletely. > It is fixed by reserving a region with triple required size and then released the middle part. > > Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. > > Tested local linux-x64-debug. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: another approach. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25894/files - new: https://git.openjdk.org/jdk/pull/25894/files/d24755a5..5c90d0a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25894&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25894&range=00-01 Stats: 18 lines in 1 file changed: 10 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25894.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25894/head:pull/25894 PR: https://git.openjdk.org/jdk/pull/25894 From azafari at openjdk.org Thu Jun 19 12:55:28 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 19 Jun 2025 12:55:28 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v2] In-Reply-To: References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: On Thu, 19 Jun 2025 12:24:12 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> another approach. > > test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 66: > >> 64: // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for >> 65: // this test, we want to see two disjunct mappings. >> 66: if ((addr2 == addr1 + reserveSize) || (addr2 + reserveSize == addr1)) { > > Suggestion: > > if ((addr2 == addr1 + reserveSize) || (addr2 == addr1 - reserveSize)) { > > I find this formulation somewhat clearer in indicating `addr2` is adjacent after, or adjacent before `addr1`. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156959698 From azafari at openjdk.org Thu Jun 19 13:03:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 19 Jun 2025 13:03:02 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v3] In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: > The test expects that two disjunct regions are reserved but checked it incompletely. > It is fixed by reserving a region with triple required size and then released the middle part. > > Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. > > Tested local linux-x64-debug. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: reviews ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25894/files - new: https://git.openjdk.org/jdk/pull/25894/files/5c90d0a0..55795425 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25894&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25894&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25894.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25894/head:pull/25894 PR: https://git.openjdk.org/jdk/pull/25894 From azafari at openjdk.org Thu Jun 19 13:03:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 19 Jun 2025 13:03:02 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v3] In-Reply-To: References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: On Thu, 19 Jun 2025 12:25:26 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> reviews > > test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 65: > >> 63: >> 64: // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for >> 65: // this test, we want to see two disjunct mappings. > > The comment no longer seems quite accurate. Updated. > test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 72: > >> 70: >> 71: wb.NMTReleaseMemory(addr1, reserveSize); >> 72: wb.NMTReleaseMemory(addr2, reserveSize); > > Just to be clear we are only releasing the original mappings to keep things consistent? And we could do this before reserving the new three region mapping - right? Not applicable in new approach. PR description is updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156967720 PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156968098 From duke at openjdk.org Thu Jun 19 13:18:38 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 19 Jun 2025 13:18:38 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation Message-ID: [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. Proposed changes in the shared class hierarchy: // VM_Operation // VM_Heap_Sync_Operation // VM_GC_Operation // VM_GC_Collect_Operation // VM_SerialGCCollect // VM_ParallelGCCollect // VM_CollectForAllocation // VM_SerialCollectForAllocation // VM_ParallelCollectForAllocation // VM_CollectForMetadataAllocation // VM_GC_Service_Operation // VM_GC_HeapInspection // VM_Verify // VM_PopulateDynamicDumpSharedSpace // VM_PopulateDumpSharedSpace Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot more overrides..._ ------------- Commit messages: - Add comment about is_gc_operation in base class - Align to ZGC styling - Reorganize GC VM operations and implement is_gc_operation Changes: https://git.openjdk.org/jdk/pull/25896/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25896&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360024 Stats: 80 lines in 12 files changed: 44 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/25896.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25896/head:pull/25896 PR: https://git.openjdk.org/jdk/pull/25896 From yzheng at openjdk.org Thu Jun 19 15:52:34 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 19 Jun 2025 15:52:34 GMT Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng wrote: > When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message: > > Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed. > > This PR skips reporting loading error when CDS and AOT loggings are disabled. Thanks for the reviews! Passed tier1-3 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25866#issuecomment-2987088457 From yzheng at openjdk.org Thu Jun 19 15:52:34 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 19 Jun 2025 15:52:34 GMT Subject: Integrated: 8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng wrote: > When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message: > > Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed. > > This PR skips reporting loading error when CDS and AOT loggings are disabled. This pull request has now been integrated. Changeset: 2e3bdec9 Author: Yudi Zheng URL: https://git.openjdk.org/jdk/commit/2e3bdec9857c64b307737ac7afed58170125cca9 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled Reviewed-by: dnsimon, iklam ------------- PR: https://git.openjdk.org/jdk/pull/25866 From dholmes at openjdk.org Thu Jun 19 23:08:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jun 2025 23:08:28 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v3] In-Reply-To: References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: <4iDObr9QhghdmSQ9Vp-p1q8InjVsYRmTdWQe0tly388=.51b8b3a5-c0b0-4afa-8360-db594682bb68@github.com> On Thu, 19 Jun 2025 13:03:02 GMT, Afshin Zafari wrote: >> The test expects that two disjunct regions are reserved but checked it incompletely. >> It is fixed by reserving a new (third) region with the required size and then released the middle region among these three regions. >> In Windows, it is not possible/valid to release middle regions. Either a whole region or a region that has the same end-address with the whole region can be released. IOW, only 'release the whole' or 'release from address A up to the end' are valid. >> >> Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. >> >> Tested local linux-x64-debug. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > reviews Okay - I think I follow that. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25894#pullrequestreview-2944169350 From dholmes at openjdk.org Fri Jun 20 04:43:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jun 2025 04:43:27 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 11:26:26 GMT, Jonas Norlinder wrote: > [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. > > Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. > > Proposed changes in the shared class hierarchy: > > > // VM_Operation > // VM_Heap_Sync_Operation > // VM_GC_Operation > // VM_GC_Collect_Operation > // VM_SerialGCCollect > // VM_ParallelGCCollect > // VM_CollectForAllocation > // VM_SerialCollectForAllocation > // VM_ParallelCollectForAllocation > // VM_CollectForMetadataAllocation > // VM_GC_Service_Operation > // VM_GC_HeapInspection > // VM_Verify > // VM_PopulateDynamicDumpSharedSpace > // VM_PopulateDumpSharedSpace > > > Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". > > ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. > > The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. > > _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot... This looks quite reasonable to me. Obviously GC folk get final approval. One minor nit. src/hotspot/share/gc/shared/gcVMOperations.hpp line 188: > 186: GCCause::_heap_inspection /* GC Cause */, > 187: 0 /* total full collections, dummy, ignored */, > 188: request_full_gc), _out(out), _full_gc(request_full_gc), Please re-align the arguments. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25896#pullrequestreview-2944528759 PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2158024854 From mdoerr at openjdk.org Fri Jun 20 09:01:29 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 20 Jun 2025 09:01:29 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v8] In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> References: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> Message-ID: On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > 2nd try at arm fix > > Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance. > > For ZGC I am using a per-nmethod lock: ZLocker locker(ZNMethod::lock_for_nmethod(nm)); Ah, right. So, ZGC should be fine. > I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this. I have tried some SPEC benchmarks with G1 on PPC64, but couldn't observe a regression. (If there is one, it was below noise.) > One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint. I guess the most critical scenario is when many Java threads need to disarm a large number of nmethod entry barriers. That doesn't happen at a safepoint. Not sure if other scenarios are worth optimizing by this idea. I guess this PR is ok as it is. Maybe other reviewers have more comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2990348628 From alanb at openjdk.org Fri Jun 20 09:30:30 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Jun 2025 09:30:30 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v8] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 07:52:20 GMT, Kazuhisa Takakuri wrote: > @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it? Sure, just have some drive by comments, switching to cp437 should be okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2990468037 From alanb at openjdk.org Fri Jun 20 09:30:32 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Jun 2025 09:30:32 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v8] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 08:21:08 GMT, Kazuhisa Takakuri wrote: >> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. >> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. >> After this fix, I verified that the test passed. >> >> https://github.com/openjdk/jdk/pull/22142 >> I refer to this fix. >> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. >> >> Thanks. > > Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: > > 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 75: > 73: throw new RuntimeException("SystemRoot or WINDIR environment variable is not set."); > 74: } > 75: String systemDirW = new File(systemRoot, "System32").getPath(); A drive-by comment is that you could remove the duplicate calls to getenv and just use a simple Path resolve. e.g. String systemRoot = System.getenv("SystemRoot"); if (systemRoot == null) { systemRoot = System.getenv("WINDIR"); if (systemRoot == null) { // throw } } String system32 = Path.of(systemRoot, "System32").toString(); test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 80: > 78: command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;" + systemDirW + ";" + systemDirW + "\\wbem", "&&")); > 79: command.addAll(List.of("chcp", "437", ">nul", "2>&1", "&&")); > 80: command.add(systeminfoPath); I assume it would be more correct to say that it switches the active code page to cp437, the default code page for US english. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2158463587 PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2158469970 From mli at openjdk.org Fri Jun 20 09:33:08 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 20 Jun 2025 09:33:08 GMT Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu Message-ID: Hi, Can you help to review this patch? CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk. These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu. Thanks! ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/25913/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25913&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360090 Stats: 9 lines in 4 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25913/head:pull/25913 PR: https://git.openjdk.org/jdk/pull/25913 From duke at openjdk.org Fri Jun 20 09:38:56 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 20 Jun 2025 09:38:56 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v2] In-Reply-To: References: Message-ID: > [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. > > Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. > > Proposed changes in the shared class hierarchy: > > > // VM_Operation > // VM_Heap_Sync_Operation > // VM_GC_Operation > // VM_GC_Collect_Operation > // VM_SerialGCCollect > // VM_ParallelGCCollect > // VM_CollectForAllocation > // VM_SerialCollectForAllocation > // VM_ParallelCollectForAllocation > // VM_CollectForMetadataAllocation > // VM_GC_Service_Operation > // VM_GC_HeapInspection > // VM_Verify > // VM_PopulateDynamicDumpSharedSpace > // VM_PopulateDumpSharedSpace > > > Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". > > ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. > > The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. > > _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot... Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Re-align arguments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25896/files - new: https://git.openjdk.org/jdk/pull/25896/files/7c8e6d81..7faaf506 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25896&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25896&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25896.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25896/head:pull/25896 PR: https://git.openjdk.org/jdk/pull/25896 From duke at openjdk.org Fri Jun 20 09:38:56 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Fri, 20 Jun 2025 09:38:56 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 04:40:40 GMT, David Holmes wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-align arguments > > This looks quite reasonable to me. Obviously GC folk get final approval. > > One minor nit. Thanks for the review @dholmes-ora. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25896#issuecomment-2990502655 From coleenp at openjdk.org Fri Jun 20 11:55:09 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Jun 2025 11:55:09 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace Message-ID: This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: [490166] static void java.lang.String.() [490166] 13 18 putstatic 613 [490166] 14 21 return [490166] static void java.lang.System.() [490166] 15 0 invokestatic 471 [490166] 16 3 aconst_null [490166] 17 4 putstatic 474 Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. Also ran tier1-4. ------------- Commit messages: - 8295851: Do not use ttyLock in BytecodeTracer::trace Changes: https://git.openjdk.org/jdk/pull/25915/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295851 Stats: 67 lines in 2 files changed: 36 ins; 13 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/25915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25915/head:pull/25915 PR: https://git.openjdk.org/jdk/pull/25915 From coleenp at openjdk.org Fri Jun 20 12:52:09 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Jun 2025 12:52:09 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v2] In-Reply-To: References: Message-ID: <_i8ghcYb1qY-t2GkyUqA1391jLwmpiblGC9hvWlC9ZE=.680cc4c0-df2d-4c8d-a1ee-3857748b6f0a@github.com> > This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: > > [490166] static void java.lang.String.() > [490166] 13 18 putstatic 613 > [490166] 14 21 return > > [490166] static void java.lang.System.() > [490166] 15 0 invokestatic 471 > [490166] 16 3 aconst_null > [490166] 17 4 putstatic 474 > > Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. > Also ran tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Put back include osthread.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25915/files - new: https://git.openjdk.org/jdk/pull/25915/files/29b71ba5..0e4421be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25915/head:pull/25915 PR: https://git.openjdk.org/jdk/pull/25915 From coleenp at openjdk.org Fri Jun 20 13:22:35 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Jun 2025 13:22:35 GMT Subject: Withdrawn: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace' In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore wrote: > Make the fatal error a log warning and return. The metaspace commit accounting is done after this return. Tested with this always returning here, and it seems okay. Tested with this change tier 1-4 and 8. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25720 From coleenp at openjdk.org Fri Jun 20 13:29:42 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Jun 2025 13:29:42 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: > This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: > > [490166] static void java.lang.String.() > [490166] 13 18 putstatic 613 > [490166] 14 21 return > > [490166] static void java.lang.System.() > [490166] 15 0 invokestatic 471 > [490166] 16 3 aconst_null > [490166] 17 4 putstatic 474 > > Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. > Also ran tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Put back include osthread.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25915/files - new: https://git.openjdk.org/jdk/pull/25915/files/0e4421be..5cdc5e11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25915/head:pull/25915 PR: https://git.openjdk.org/jdk/pull/25915 From gziemski at openjdk.org Fri Jun 20 16:56:31 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 20 Jun 2025 16:56:31 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 11:33:03 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data. >> >> The new parameters are: >> >> - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time. >> >> - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed. >> >> - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems. >> >> Testing: >> - All container tests under `/test/hotspot/jtreg/containers/` >> - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > update cpu usage to use >= > > Co-authored-by: Severin Gehwolf LGTM, though I did have one feedback. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 431: > 429: return (jlong)cpu_usage / 1000; > 430: } > 431: Why don't we report the original value in nanos, if it is available? This is new API, so no-one is using this yet, right? ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25388#pullrequestreview-2946799576 PR Review Comment: https://git.openjdk.org/jdk/pull/25388#discussion_r2159367227 From dcubed at openjdk.org Fri Jun 20 19:39:37 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 20 Jun 2025 19:39:37 GMT Subject: RFR: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java Message-ID: A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms. Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely integrate until next week and I want to reduce the noise for the weekend. ------------- Commit messages: - 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java Changes: https://git.openjdk.org/jdk/pull/25919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25919&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360143 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25919/head:pull/25919 PR: https://git.openjdk.org/jdk/pull/25919 From rriggs at openjdk.org Fri Jun 20 19:39:37 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 20 Jun 2025 19:39:37 GMT Subject: RFR: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 19:32:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms. > > Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely > integrate until next week and I want to reduce the noise for the weekend. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25919#pullrequestreview-2947125441 From dcubed at openjdk.org Fri Jun 20 19:56:31 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 20 Jun 2025 19:56:31 GMT Subject: RFR: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 19:35:49 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms. >> >> Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely >> integrate until next week and I want to reduce the noise for the weekend. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the lightning fast review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25919#issuecomment-2992640662 From dcubed at openjdk.org Fri Jun 20 19:56:31 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 20 Jun 2025 19:56:31 GMT Subject: Integrated: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 19:32:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms. > > Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely > integrate until next week and I want to reduce the noise for the weekend. This pull request has now been integrated. Changeset: d627282f Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/d627282f0c42c340db3b8b71121274b91638e09b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/25919 From dcubed at openjdk.org Fri Jun 20 19:58:29 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 20 Jun 2025 19:58:29 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v3] In-Reply-To: References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: On Thu, 19 Jun 2025 13:03:02 GMT, Afshin Zafari wrote: >> The test expects that two disjunct regions are reserved but checked it incompletely. >> It is fixed by reserving a new (third) region with the required size and then released the middle region among these three regions. >> In Windows, it is not possible/valid to release middle regions. Either a whole region or a region that has the same end-address with the whole region can be released. IOW, only 'release the whole' or 'release from address A up to the end' are valid. >> >> Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. >> >> Tested local linux-x64-debug. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > reviews @afshin-zafari - I have ProblemListed this test on all platforms to reduce any noise over the weekend. Please remember to resync your repo and remove the ProblemListing as part of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25894#issuecomment-2992646103 From sspitsyn at openjdk.org Fri Jun 20 20:52:29 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 20 Jun 2025 20:52:29 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Wed, 18 Jun 2025 11:52:17 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a byte buffer version and rename parameters. Thank you for the update! Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2947255421 From lmesnik at openjdk.org Fri Jun 20 21:40:28 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 20 Jun 2025 21:40:28 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com> On Wed, 18 Jun 2025 11:52:17 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a byte buffer version and rename parameters. Changes requested by lmesnik (Reviewer). test/lib/RedefineClassHelper.java line 68: > 66: > 67: private static byte[] getBytecodes(ClassLoader loader, String name) throws Exception { > 68: InputStream is = loader.getResourceAsStream(name + ".class"); I think this should be try(InputStream is = loader.getResourceAsStream(name + ".class");) { ... ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2947314649 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2159689305 From kbarrett at openjdk.org Mon Jun 23 02:09:50 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 23 Jun 2025 02:09:50 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string Message-ID: Please review this fix for the format directive when printing ULLONG_MAX by TestArguments.atojulong gtest. Instead of using JULONG_FORMAT, which might not be the proper type (though sized properly), use "%llu" to avoid potential warning. Also changed the test_arguments.cpp file to use os::snprintf instead of jio_snprintf, and improved checking the results of those calls. Testing: mach5 tier1 ------------- Commit messages: - fix test_arguments.cpp Changes: https://git.openjdk.org/jdk/pull/25927/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25927&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360178 Stats: 11 lines in 1 file changed: 4 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25927/head:pull/25927 PR: https://git.openjdk.org/jdk/pull/25927 From dholmes at openjdk.org Mon Jun 23 05:50:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jun 2025 05:50:27 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 13:29:42 GMT, Coleen Phillimore wrote: >> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: >> >> [490166] static void java.lang.String.() >> [490166] 13 18 putstatic 613 >> [490166] 14 21 return >> >> [490166] static void java.lang.System.() >> [490166] 15 0 invokestatic 471 >> [490166] 16 3 aconst_null >> [490166] 17 4 putstatic 474 >> >> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. >> Also ran tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Put back include osthread.hpp src/hotspot/share/interpreter/bytecodeTracer.cpp line 182: > 180: // the method has changed. If this method is redefined and removed, that's ok because the method passed in won't match, and > 181: // this will print that one. > 182: static Method* _current_method = nullptr; And if we are calling `trace_interpreter` from multiple threads they will each stomp on this shared global field. Sorry I can't see how some form of locking is not needed here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2160763661 From dholmes at openjdk.org Mon Jun 23 07:47:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jun 2025 07:47:30 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 02:05:29 GMT, Kim Barrett wrote: > Please review this fix for the format directive when printing ULLONG_MAX by > TestArguments.atojulong gtest. Instead of using JULONG_FORMAT, which might not > be the proper type (though sized properly), use "%llu" to avoid potential > warning. > > Also changed the test_arguments.cpp file to use os::snprintf instead of > jio_snprintf, and improved checking the results of those calls. > > Testing: mach5 tier1 The change to "%llu", would be trivial, but the rest seems a bit superfluous. test/hotspot/gtest/runtime/test_arguments.cpp line 32: > 30: #include > 31: > 32: #include "unittest.hpp" Is there a rule/guideline that says this should be placed here? test/hotspot/gtest/runtime/test_arguments.cpp line 51: > 49: char buf[1024]; > 50: int ret = os::snprintf(buf, sizeof(buf), "%s=%s", name, value); > 51: if ((ret > 0) && ((size_t)ret < sizeof(buf))) { `jio_snprintf` already handled the buffer-too-small case by returning -1. I don't see the reason for changing the test to use `os::snprintf` when arguments.cpp uses `jio_snprintf`. test/hotspot/gtest/runtime/test_arguments.cpp line 63: > 61: int ret = os::snprintf(ullong_max, sizeof(ullong_max), "%llu", ULLONG_MAX); > 62: ASSERT_LT(0, ret); > 63: ASSERT_LT(ret, (int)sizeof(ullong_max)); This is just a sanity check right? Maximum uint64_t has 20 digits. ------------- PR Review: https://git.openjdk.org/jdk/pull/25927#pullrequestreview-2948976151 PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2160914674 PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2160929332 PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2160920953 From tschatzl at openjdk.org Mon Jun 23 08:01:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 23 Jun 2025 08:01:49 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v2] In-Reply-To: References: Message-ID: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com> On Fri, 20 Jun 2025 09:38:56 GMT, Jonas Norlinder wrote: >> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. >> >> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. >> >> Proposed changes in the shared class hierarchy: >> >> >> // VM_Operation >> // VM_Heap_Sync_Operation >> // VM_GC_Operation >> // VM_GC_Collect_Operation >> // VM_SerialGCCollect >> // VM_ParallelGCCollect >> // VM_CollectForAllocation >> // VM_SerialCollectForAllocation >> // VM_ParallelCollectForAllocation >> // VM_CollectForMetadataAllocation >> // VM_GC_Service_Operation >> // VM_GC_HeapInspection >> // VM_Verify >> // VM_PopulateDynamicDumpSharedSpace >> // VM_PopulateDumpSharedSpace >> >> >> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". >> >> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. >> >> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. >> >> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it... > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Re-align arguments lgtm, but since the comment typos cause re-reviews, requesting changes. src/hotspot/share/gc/shared/gcVMOperations.hpp line 47: > 45: // VM_CollectForAllocation > 46: // VM_SerialCollectForAllocation > 47: // VM_ParallelCollectForAllocation Suggestion: // e.g. VM_SerialGCCollector // VM_CollectForAllocation // e.g. VM_SerialCollectForAllocation This is not a real suggestion, but this hierarchy isn't complete, and I am not sure we should make it complete. Since we already skip Z/G1/Shenandoah operations here, I do not really see that Serial/Parallel specific operations should be here either. Or maybe explicitly state Serial/Parallel vm ops as examples here as suggested above, but that does not look right either. However this is kind of unrelated to this PR :) src/hotspot/share/runtime/vmOperation.hpp line 164: > 162: > 163: // VMOp_Type may belong to a category of operation > 164: // Override is_XX_operation() appropriately in subclasses Suggestion: // VMOp_Type may belong to a category of the operation. // Override is_XX_operation() appropriately in subclasses. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25896#pullrequestreview-2949032479 PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2160960642 PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2160950023 From azafari at openjdk.org Mon Jun 23 08:50:18 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 23 Jun 2025 08:50:18 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v4] In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: > The test expects that two disjunct regions are reserved but checked it incompletely. > It is fixed by reserving a new (third) region with the required size and then released the middle region among these three regions. > In Windows, it is not possible/valid to release middle regions. Either a whole region or a region that has the same end-address with the whole region can be released. IOW, only 'release the whole' or 'release from address A up to the end' are valid. > > Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. > > Tested local linux-x64-debug. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - removed from ProblemList - Merge remote-tracking branch 'origin/master' into _8359959_adjacent_reserves - reviews - another approach. - 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25894/files - new: https://git.openjdk.org/jdk/pull/25894/files/55795425..bbd834cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25894&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25894&range=02-03 Stats: 2328 lines in 125 files changed: 1854 ins; 221 del; 253 mod Patch: https://git.openjdk.org/jdk/pull/25894.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25894/head:pull/25894 PR: https://git.openjdk.org/jdk/pull/25894 From cnorrbin at openjdk.org Mon Jun 23 10:09:34 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 23 Jun 2025 10:09:34 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available [v2] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 16:47:56 GMT, Gerard Ziemski wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> update cpu usage to use >= >> >> Co-authored-by: Severin Gehwolf > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 431: > >> 429: return (jlong)cpu_usage / 1000; >> 430: } >> 431: > > Why don't we report the original value in nanos, if it is available? > > This is new API, so no-one is using this yet, right? I centered it around cgroup v2, which only reports the usage in micros. Cgroup v1 is deprecated for most systems so shouldn't really be used. It made more sense to use micros instead of padding the value most will see with a bunch of zeros. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25388#discussion_r2161223525 From duke at openjdk.org Mon Jun 23 10:18:10 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 23 Jun 2025 10:18:10 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v2] In-Reply-To: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com> References: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com> Message-ID: On Mon, 23 Jun 2025 07:58:56 GMT, Thomas Schatzl wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-align arguments > > lgtm, but since the comment typos cause re-reviews, requesting changes. Thanks for the review @tschatzl, I fixed the typo. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25896#issuecomment-2995818445 From duke at openjdk.org Mon Jun 23 10:18:10 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 23 Jun 2025 10:18:10 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v3] In-Reply-To: References: Message-ID: > [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. > > Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. > > Proposed changes in the shared class hierarchy: > > > // VM_Operation > // VM_Heap_Sync_Operation > // VM_GC_Operation > // VM_GC_Collect_Operation > // VM_SerialGCCollect > // VM_ParallelGCCollect > // VM_CollectForAllocation > // VM_SerialCollectForAllocation > // VM_ParallelCollectForAllocation > // VM_CollectForMetadataAllocation > // VM_GC_Service_Operation > // VM_GC_HeapInspection > // VM_Verify > // VM_PopulateDynamicDumpSharedSpace > // VM_PopulateDumpSharedSpace > > > Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". > > ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. > > The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. > > _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot... Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fix typo Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25896/files - new: https://git.openjdk.org/jdk/pull/25896/files/7faaf506..546ad943 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25896&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25896&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25896.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25896/head:pull/25896 PR: https://git.openjdk.org/jdk/pull/25896 From duke at openjdk.org Mon Jun 23 10:22:29 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 23 Jun 2025 10:22:29 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v2] In-Reply-To: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com> References: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com> Message-ID: On Mon, 23 Jun 2025 07:56:57 GMT, Thomas Schatzl wrote: >> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-align arguments > > src/hotspot/share/gc/shared/gcVMOperations.hpp line 47: > >> 45: // VM_CollectForAllocation >> 46: // VM_SerialCollectForAllocation >> 47: // VM_ParallelCollectForAllocation > > Suggestion: > > // e.g. VM_SerialGCCollector > // VM_CollectForAllocation > // e.g. VM_SerialCollectForAllocation > > > This is not a real suggestion, but this hierarchy isn't complete, and I am not sure we should make it complete. Since we already skip Z/G1/Shenandoah operations here, I do not really see that Serial/Parallel specific operations should be here either. > > Or maybe explicitly state Serial/Parallel vm ops as examples here as suggested above, but that does not look right either. > > However this is kind of unrelated to this PR :) Given that the comment was wrong to begin with, i.e. `VM_PopulateDynamicDumpSharedSpace` was under `VM_GC_Operation` but actually it inherited from `VM_GC_Sync_Operation`, we migh consider removing the comment? But as you say, this discussion belong in another PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2161248592 From tschatzl at openjdk.org Mon Jun 23 10:32:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 23 Jun 2025 10:32:29 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v3] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 10:18:10 GMT, Jonas Norlinder wrote: >> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. >> >> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. >> >> Proposed changes in the shared class hierarchy: >> >> >> // VM_Operation >> // VM_Heap_Sync_Operation >> // VM_GC_Operation >> // VM_GC_Collect_Operation >> // VM_SerialGCCollect >> // VM_ParallelGCCollect >> // VM_CollectForAllocation >> // VM_SerialCollectForAllocation >> // VM_ParallelCollectForAllocation >> // VM_CollectForMetadataAllocation >> // VM_GC_Service_Operation >> // VM_GC_HeapInspection >> // VM_Verify >> // VM_PopulateDynamicDumpSharedSpace >> // VM_PopulateDumpSharedSpace >> >> >> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". >> >> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. >> >> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. >> >> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it... > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25896#pullrequestreview-2949538397 From coleenp at openjdk.org Mon Jun 23 11:55:27 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 23 Jun 2025 11:55:27 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 05:47:29 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Put back include osthread.hpp > > src/hotspot/share/interpreter/bytecodeTracer.cpp line 182: > >> 180: // the method has changed. If this method is redefined and removed, that's ok because the method passed in won't match, and >> 181: // this will print that one. >> 182: static Method* _current_method = nullptr; > > And if we are calling `trace_interpreter` from multiple threads they will each stomp on this shared global field. Sorry I can't see how some form of locking is not needed here. If multiple threads change the value of _current_method, the method printing will print the method name again. That's a benign race. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2161434683 From duke at openjdk.org Mon Jun 23 12:19:35 2025 From: duke at openjdk.org (duke) Date: Mon, 23 Jun 2025 12:19:35 GMT Subject: RFR: 8360024: Reorganize GC VM operations and implement is_gc_operation [v3] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 10:18:10 GMT, Jonas Norlinder wrote: >> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. >> >> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. >> >> Proposed changes in the shared class hierarchy: >> >> >> // VM_Operation >> // VM_Heap_Sync_Operation >> // VM_GC_Operation >> // VM_GC_Collect_Operation >> // VM_SerialGCCollect >> // VM_ParallelGCCollect >> // VM_CollectForAllocation >> // VM_SerialCollectForAllocation >> // VM_ParallelCollectForAllocation >> // VM_CollectForMetadataAllocation >> // VM_GC_Service_Operation >> // VM_GC_HeapInspection >> // VM_Verify >> // VM_PopulateDynamicDumpSharedSpace >> // VM_PopulateDumpSharedSpace >> >> >> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". >> >> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. >> >> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. >> >> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it... > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo > > Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com> @JonasNorlinder Your change (at version 546ad94372c0cc06e1fd7127c89ef682d90ae800) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25896#issuecomment-2996268758 From coleenp at openjdk.org Mon Jun 23 12:46:33 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 23 Jun 2025 12:46:33 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com> Message-ID: <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com> On Fri, 20 Jun 2025 21:35:33 GMT, Leonid Mesnik wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a byte buffer version and rename parameters. > > test/lib/RedefineClassHelper.java line 68: > >> 66: >> 67: private static byte[] getBytecodes(ClassLoader loader, String name) throws Exception { >> 68: InputStream is = loader.getResourceAsStream(name + ".class"); > > I think this should be > try(InputStream is = loader.getResourceAsStream(name + ".class");) { > ... getBytecodes propagates the exception from getResourceAsStream. If I catch IOException (?), what should it do? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2161533545 From eosterlund at openjdk.org Mon Jun 23 12:49:41 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 23 Jun 2025 12:49:41 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v8] In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> References: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> Message-ID: On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > 2nd try at arm fix Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2949966322 From eosterlund at openjdk.org Mon Jun 23 12:49:41 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 23 Jun 2025 12:49:41 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 00:20:05 GMT, Dean Long wrote: >> Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think? > > I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand. Arming the barrier is not guaranteed to be visible until there is a safepoint. Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming. Okay. I would have preferred to not enter the nmethod when we evaluate the guard bits under the lock that protects it and see that it's supposed to be not entrant. But I won't argue for it further if you prefer not to change that. Other than that, I think this looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2161540372 From duke at openjdk.org Mon Jun 23 12:52:33 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 23 Jun 2025 12:52:33 GMT Subject: Integrated: 8360024: Reorganize GC VM operations and implement is_gc_operation In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 11:26:26 GMT, Jonas Norlinder wrote: > [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC. > > Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation. > > Proposed changes in the shared class hierarchy: > > > // VM_Operation > // VM_Heap_Sync_Operation > // VM_GC_Operation > // VM_GC_Collect_Operation > // VM_SerialGCCollect > // VM_ParallelGCCollect > // VM_CollectForAllocation > // VM_SerialCollectForAllocation > // VM_ParallelCollectForAllocation > // VM_CollectForMetadataAllocation > // VM_GC_Service_Operation > // VM_GC_HeapInspection > // VM_Verify > // VM_PopulateDynamicDumpSharedSpace > // VM_PopulateDumpSharedSpace > > > Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity". > > ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`. > > The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component. > > _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot... This pull request has now been integrated. Changeset: c748d358 Author: Jonas Norlinder Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/c748d358b2569928fb5a03722987c93762c30145 Stats: 84 lines in 12 files changed: 44 ins; 0 del; 40 mod 8360024: Reorganize GC VM operations and implement is_gc_operation Reviewed-by: tschatzl, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25896 From duke at openjdk.org Mon Jun 23 13:12:28 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 23 Jun 2025 13:12:28 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v9] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Remove incorrect is_gc_operation call after rebase - More clean up, remove virtual - Fixes after feedback from @stefank - Remove extra whitespace - operation_is_gc -> is_gc_operation per @stefank suggestion - Only sample if needed - Remove explicit super call and minor fixes - Add CPU time tracking for string deduplication to log_gc_vtime - Replace calls to log_gc_vtime with super-class method calls - Add bug fix after refactor and fixes for review - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48 ------------- Changes: https://git.openjdk.org/jdk/pull/25779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=08 Stats: 233 lines in 15 files changed: 223 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Mon Jun 23 13:23:29 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 23 Jun 2025 13:23:29 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v9] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 13:12:28 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Remove incorrect is_gc_operation call after rebase > - More clean up, remove virtual > - Fixes after feedback from @stefank > - Remove extra whitespace > - operation_is_gc -> is_gc_operation per @stefank suggestion > - Only sample if needed > - Remove explicit super call and minor fixes > - Add CPU time tracking for string deduplication to log_gc_vtime > - Replace calls to log_gc_vtime with super-class method calls > - Add bug fix after refactor and fixes for review > - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48 Changes: * Fixes after feedback from @stefank * Re-based on master so that the integration of [JDK-8360024](https://bugs.openjdk.org/browse/JDK-8360024) is included (apologies for the force-push) * Removed conditional sampling per @tschatzl request While CPU time may be slightly incorrect if heap dumping or heap inspection occurs, the risk is small that the number would be skewed in a significant way and we have a plan on how to mitigate with that going forward, therefore I suggest we can go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2996481626 From ayang at openjdk.org Mon Jun 23 14:10:34 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 23 Jun 2025 14:10:34 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v9] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 13:12:28 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Remove incorrect is_gc_operation call after rebase > - More clean up, remove virtual > - Fixes after feedback from @stefank > - Remove extra whitespace > - operation_is_gc -> is_gc_operation per @stefank suggestion > - Only sample if needed > - Remove explicit super call and minor fixes > - Add CPU time tracking for string deduplication to log_gc_vtime > - Replace calls to log_gc_vtime with super-class method calls > - Add bug fix after refactor and fixes for review > - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48 src/hotspot/share/gc/shared/collectedHeap.hpp line 245: > 243: > 244: // Stop any onging concurrent work and prepare for exit. > 245: virtual void stop(); I find it a bit odd to call `log_gc_vtime` inside this method, given the comment and its name. I wonder if `print_tracing_info` can be used instead, which is invoked before exit as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2161728711 From duke at openjdk.org Mon Jun 23 14:19:32 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 23 Jun 2025 14:19:32 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v9] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 14:07:56 GMT, Albert Mingkun Yang wrote: >> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Remove incorrect is_gc_operation call after rebase >> - More clean up, remove virtual >> - Fixes after feedback from @stefank >> - Remove extra whitespace >> - operation_is_gc -> is_gc_operation per @stefank suggestion >> - Only sample if needed >> - Remove explicit super call and minor fixes >> - Add CPU time tracking for string deduplication to log_gc_vtime >> - Replace calls to log_gc_vtime with super-class method calls >> - Add bug fix after refactor and fixes for review >> - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48 > > src/hotspot/share/gc/shared/collectedHeap.hpp line 245: > >> 243: >> 244: // Stop any onging concurrent work and prepare for exit. >> 245: virtual void stop(); > > I find it a bit odd to call `log_gc_vtime` inside this method, given the comment and its name. I wonder if `print_tracing_info` can be used instead, which is invoked before exit as well. I think it makes sense. We want to log the total GC CPU time before exiting. The latest point we can do that is right before we terminate threads, which we do in when we call `ConcurrentGCThread::stop`. I am open for any suggestions to rename `log_gc_vtime` in case that would help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2161749278 From lmesnik at openjdk.org Mon Jun 23 15:51:31 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 23 Jun 2025 15:51:31 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Wed, 18 Jun 2025 11:52:17 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a byte buffer version and rename parameters. Changes requested by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2950620500 From lmesnik at openjdk.org Mon Jun 23 15:51:32 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 23 Jun 2025 15:51:32 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com> <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com> Message-ID: <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com> On Mon, 23 Jun 2025 12:43:28 GMT, Coleen Phillimore wrote: >> test/lib/RedefineClassHelper.java line 68: >> >>> 66: >>> 67: private static byte[] getBytecodes(ClassLoader loader, String name) throws Exception { >>> 68: InputStream is = loader.getResourceAsStream(name + ".class"); >> >> I think this should be >> try(InputStream is = loader.getResourceAsStream(name + ".class");) { >> ... > > getBytecodes propagates the exception from getResourceAsStream. If I catch IOException (?), what should it do? I didn't thought about this, but I think that's ok. I just propose to closed stream, not changing the exception handling. The try(InputStream is = loader.getResourceAsStream(name + ".class");) { InputStream is = loader.getResourceAsStream(name + ".class"); byte[] buf = is.readAllBytes(); System.out.println("sizeof(" + name + ".class) == " + buf.length); return buf; } has completely the same workflow, just closing stream so we don't have any resource leak. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2161944047 From stefank at openjdk.org Mon Jun 23 19:00:39 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 23 Jun 2025 19:00:39 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v9] In-Reply-To: References: Message-ID: <_FhdGlOiiWqN_Jpx_7kJZgamyXtgQTUw54t1w38SjxY=.609da7e0-39f9-4525-9836-b56a71c488f6@github.com> On Mon, 23 Jun 2025 14:17:05 GMT, Jonas Norlinder wrote: >> src/hotspot/share/gc/shared/collectedHeap.hpp line 245: >> >>> 243: >>> 244: // Stop any onging concurrent work and prepare for exit. >>> 245: virtual void stop(); >> >> I find it a bit odd to call `log_gc_vtime` inside this method, given the comment and its name. I wonder if `print_tracing_info` can be used instead, which is invoked before exit as well. > > I think it makes sense. We want to log the total GC CPU time before exiting. The latest point we can do that is right before we terminate threads, which we do in when we call `ConcurrentGCThread::stop`. I am open for any suggestions to rename `log_gc_vtime` in case that would help. I'd also prefer to see a small adjustment here. With this change all GCs have to add a back call to `CollectedHeap::stop()`. I think it makes the could a tiny bit less clean. I wonder if an alternative could be to split `CollectedHeap::stop()` into two functions: virtual void CollectedHeap::stop() = 0; // Now pure virtual void CollectedHeap::before_exit() { // Log GC CPU usage. log_gc_vtime(); // Stop any on-going concurrent work and prepare for exit. stop(); } And revert the added calls to `CollectedHeap::stop()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2162341225 From dlong at openjdk.org Mon Jun 23 19:12:29 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 23 Jun 2025 19:12:29 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 12:47:07 GMT, Erik ?sterlund wrote: >> I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand. Arming the barrier is not guaranteed to be visible until there is a safepoint. Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming. > > Okay. I would have preferred to not enter the nmethod when we evaluate the guard bits under the lock that protects it and see that it's supposed to be not entrant. But I won't argue for it further if you prefer not to change that. Other than that, I think this looks good. I think it's OK if there is a race to have a point of no return, and if one thread gets there first, it wins, and we don't need to check again. It's tempting to want to do an extra check when we disarm under the lock, but then it would need a comment explaining why we do it, even though the make_not_entrant could come in right after and we would miss it. And we have already done the work of healing the oops by this point. Finally, I like the encapsulation that only nmethod_stub_entry_barrier needs to know about not_entrant, and nmethod_entry_barrier doesn't need to know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2162359865 From dlong at openjdk.org Mon Jun 23 19:18:31 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 23 Jun 2025 19:18:31 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v8] In-Reply-To: References: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com> Message-ID: On Fri, 20 Jun 2025 08:58:39 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> 2nd try at arm fix > >> > Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance. >> >> For ZGC I am using a per-nmethod lock: ZLocker locker(ZNMethod::lock_for_nmethod(nm)); > > Ah, right. So, ZGC should be fine. > >> I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this. > > I have tried some SPEC benchmarks with G1 on PPC64, but couldn't observe a regression. (If there is one, it was below noise.) > >> One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint. > > I guess the most critical scenario is when many Java threads need to disarm a large number of nmethod entry barriers. That doesn't happen at a safepoint. Not sure if other scenarios are worth optimizing by this idea. > > I guess this PR is ok as it is. Maybe other reviewers have more comments. @TheRealMDoerr @fisk @offamitkumar Thanks again everyone for the reviews and contributions. I think this is ready to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2997672327 From dlong at openjdk.org Mon Jun 23 19:26:11 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 23 Jun 2025 19:26:11 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into 8358821-patch-verified-entry - 2nd try at arm fix - rename arm_with to guard_with - arm32 fix - s390 fix courtesy of Amit Kumar - remove is_sigill_not_entrant - more cleanup - more TheRealMDoerr suggestions - TheRealMDoerr suggestions - remove trailing space - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c ------------- Changes: https://git.openjdk.org/jdk/pull/25764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=08 Stats: 603 lines in 43 files changed: 97 ins; 459 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/25764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764 PR: https://git.openjdk.org/jdk/pull/25764 From mdoerr at openjdk.org Mon Jun 23 19:26:11 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 23 Jun 2025 19:26:11 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: <3NeAP1nLxZGaY1zq8RfpkCy3L3KYXNyjN6Eg1vS1DRE=.e43394f9-33f6-48af-937c-48062b6b8125@github.com> On Mon, 23 Jun 2025 19:22:45 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8358821-patch-verified-entry > - 2nd try at arm fix > - rename arm_with to guard_with > - arm32 fix > - s390 fix courtesy of Amit Kumar > - remove is_sigill_not_entrant > - more cleanup > - more TheRealMDoerr suggestions > - TheRealMDoerr suggestions > - remove trailing space > - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2951288332 From coleenp at openjdk.org Mon Jun 23 20:44:19 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 23 Jun 2025 20:44:19 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v3] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use try-with-resources ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/6bc1ca59..ed342127 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From coleenp at openjdk.org Mon Jun 23 20:44:19 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 23 Jun 2025 20:44:19 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com> <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com> <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com> Message-ID: On Mon, 23 Jun 2025 15:47:40 GMT, Leonid Mesnik wrote: >> getBytecodes propagates the exception from getResourceAsStream. If I catch IOException (?), what should it do? > > I didn't thought about this, but I think that's ok. I just propose to closed stream, not changing the exception handling. The > > try(InputStream is = loader.getResourceAsStream(name + ".class");) { > InputStream is = loader.getResourceAsStream(name + ".class"); > byte[] buf = is.readAllBytes(); > System.out.println("sizeof(" + name + ".class) == " + buf.length); > return buf; > } > > has completely the same workflow, just closing stream so we don't have any resource leak. Oh so this try is a try-with-resources and it'll close the stream? It compiles without a catch clause. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162492123 From lmesnik at openjdk.org Mon Jun 23 20:47:28 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 23 Jun 2025 20:47:28 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com> <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com> <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com> Message-ID: On Mon, 23 Jun 2025 20:39:34 GMT, Coleen Phillimore wrote: >> I didn't thought about this, but I think that's ok. I just propose to closed stream, not changing the exception handling. The >> >> try(InputStream is = loader.getResourceAsStream(name + ".class");) { >> InputStream is = loader.getResourceAsStream(name + ".class"); >> byte[] buf = is.readAllBytes(); >> System.out.println("sizeof(" + name + ".class) == " + buf.length); >> return buf; >> } >> >> has completely the same workflow, just closing stream so we don't have any resource leak. > > Oh so this try is a try-with-resources and it'll close the stream? It compiles without a catch clause. yes, only change is that stream is closed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162502439 From coleenp at openjdk.org Mon Jun 23 20:57:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 23 Jun 2025 20:57:31 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com> <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com> <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com> Message-ID: On Mon, 23 Jun 2025 20:45:13 GMT, Leonid Mesnik wrote: >> Oh so this try is a try-with-resources and it'll close the stream? It compiles without a catch clause. > > yes, only change is that stream is closed. That's really cool. Thanks for the suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162515881 From coleenp at openjdk.org Mon Jun 23 20:59:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 23 Jun 2025 20:59:29 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 11:52:46 GMT, Coleen Phillimore wrote: >> src/hotspot/share/interpreter/bytecodeTracer.cpp line 182: >> >>> 180: // the method has changed. If this method is redefined and removed, that's ok because the method passed in won't match, and >>> 181: // this will print that one. >>> 182: static Method* _current_method = nullptr; >> >> And if we are calling `trace_interpreter` from multiple threads they will each stomp on this shared global field. Sorry I can't see how some form of locking is not needed here. > > If multiple threads change the value of _current_method, the method printing will print the method name again. That's a benign race. So actually this wasn't more racy than what was there in this respect. You could change the global method before taking the ttyLock and for multiple threads, this would claim that the current method had changed. The old code also had shared state for BytecodeTracer. Now this uses a local instance, which can then print the bytecode at the given location. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2162519648 From amenkov at openjdk.org Mon Jun 23 21:20:31 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 23 Jun 2025 21:20:31 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Wed, 18 Jun 2025 11:52:17 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a byte buffer version and rename parameters. test/lib/RedefineClassHelper.java line 87: > 85: } > 86: return 0; > 87: } I understand, that this is copy of the old code, but this method does not look good. - it would be better to return -1 if the string not found (0 is valid offset) - calculation of the buf's upper bound is incorrect when offset > 0 I'd suggest to update it to something like (not tested, also need to update callers to compare with -1) private static int getStringIndex(String needle, byte[] buf, int offset) { byte[] needleArray = needle.getBytes(StandardCharsets.US_ASCII); for (int i = offset; i < buf.length - needleArray.length; i++) if (Arrays.equals(buf, offset, offset + needleArray.length, needleArray, 0, needleArray.length)) { return offset; } } return -1; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162549862 From lmesnik at openjdk.org Mon Jun 23 21:59:29 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 23 Jun 2025 21:59:29 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v3] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <0tYBhgIF7gWzR1G84utYNsG6iWE69rUc099IxNsXqcU=.dc36e9e0-e3d8-4507-8119-7308d1c02cf9@github.com> On Mon, 23 Jun 2025 20:44:19 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use try-with-resources Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2951635049 From dholmes at openjdk.org Tue Jun 24 02:53:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jun 2025 02:53:33 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 20:56:46 GMT, Coleen Phillimore wrote: >> If multiple threads change the value of _current_method, the method printing will print the method name again. That's a benign race. > > So actually this wasn't more racy than what was there in this respect. You could change the global method before taking the ttyLock and for multiple threads, this would claim that the current method had changed. The old code also had shared state for BytecodeTracer. Now this uses a local instance, which can then print the bytecode at the given location. So the old code (mis)used a shared `ByteCodeTracer` instance, and the new code gives each use a local `ByteCodeTracer` but seeds it from the global shared field. So I agree the level of raciness seems unchanged. But printing an unrelated method name still seems a bad thing to do. ?? BTW it is also very confusing to give the global variable the same name as the private field in `ByteCodeTracer`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2162858904 From dholmes at openjdk.org Tue Jun 24 02:53:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jun 2025 02:53:32 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 13:29:42 GMT, Coleen Phillimore wrote: >> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: >> >> [490166] static void java.lang.String.() >> [490166] 13 18 putstatic 613 >> [490166] 14 21 return >> >> [490166] static void java.lang.System.() >> [490166] 15 0 invokestatic 471 >> [490166] 16 3 aconst_null >> [490166] 17 4 putstatic 474 >> >> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. >> Also ran tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Put back include osthread.hpp Changes requested by dholmes (Reviewer). src/hotspot/share/interpreter/bytecodeTracer.cpp line 186: > 184: void BytecodeTracer::trace_interpreter(const methodHandle& method, address bcp, uintptr_t tos, uintptr_t tos2, outputStream* st) { > 185: if (TraceBytecodes && BytecodeCounter::counter_value() >= TraceBytecodesAt) { > 186: BytecodePrinter printer(_current_method); You need a `Atomic::load_acquire` here to pair with the `Atomic::release_store` below. ------------- PR Review: https://git.openjdk.org/jdk/pull/25915#pullrequestreview-2952022500 PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2162859385 From fyang at openjdk.org Tue Jun 24 03:24:38 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 24 Jun 2025 03:24:38 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8358821-patch-verified-entry > - 2nd try at arm fix > - rename arm_with to guard_with > - arm32 fix > - s390 fix courtesy of Amit Kumar > - remove is_sigill_not_entrant > - more cleanup > - more TheRealMDoerr suggestions > - TheRealMDoerr suggestions > - remove trailing space > - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2998661809 From azafari at openjdk.org Tue Jun 24 07:57:05 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 24 Jun 2025 07:57:05 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken Message-ID: The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block. Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release} ------------- Commit messages: - 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken Changes: https://git.openjdk.org/jdk/pull/25950/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25950&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360048 Stats: 27 lines in 1 file changed: 19 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25950/head:pull/25950 PR: https://git.openjdk.org/jdk/pull/25950 From jsjolen at openjdk.org Tue Jun 24 09:06:33 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jun 2025 09:06:33 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v4] In-Reply-To: References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: On Mon, 23 Jun 2025 08:50:18 GMT, Afshin Zafari wrote: >> The test expects that two disjunct regions are reserved but checked it incompletely. >> It is fixed by reserving a new (third) region with the required size and then released the middle region among these three regions. >> In Windows, it is not possible/valid to release middle regions. Either a whole region or a region that has the same end-address with the whole region can be released. IOW, only 'release the whole' or 'release from address A up to the end' are valid. >> >> Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. >> >> Tested local linux-x64-debug. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - removed from ProblemList > - Merge remote-tracking branch 'origin/master' into _8359959_adjacent_reserves > - reviews > - another approach. > - 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr Thanks! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25894#pullrequestreview-2952852846 From jsjolen at openjdk.org Tue Jun 24 09:07:29 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jun 2025 09:07:29 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken In-Reply-To: References: Message-ID: <15_X0322QFPeu_AT2RupUGKBp9BsUCPijorpkrctlz8=.c35cb51c-83c2-4816-a278-cdd6dc4144a9@github.com> On Tue, 24 Jun 2025 07:52:38 GMT, Afshin Zafari wrote: > The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block. > > Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release} It would be good if we could remove the dependency on the global instance in the source code and create new VMT's for each test. That would make the tests less brittle. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25950#pullrequestreview-2952858818 From azafari at openjdk.org Tue Jun 24 11:20:33 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 24 Jun 2025 11:20:33 GMT Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr [v4] In-Reply-To: <4iDObr9QhghdmSQ9Vp-p1q8InjVsYRmTdWQe0tly388=.51b8b3a5-c0b0-4afa-8360-db594682bb68@github.com> References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> <4iDObr9QhghdmSQ9Vp-p1q8InjVsYRmTdWQe0tly388=.51b8b3a5-c0b0-4afa-8360-db594682bb68@github.com> Message-ID: On Thu, 19 Jun 2025 23:05:54 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - removed from ProblemList >> - Merge remote-tracking branch 'origin/master' into _8359959_adjacent_reserves >> - reviews >> - another approach. >> - 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr > > Okay - I think I follow that. > > Thanks Thank you for reviews, @dholmes-ora and @jdksjolen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25894#issuecomment-2999920012 From azafari at openjdk.org Tue Jun 24 11:20:34 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 24 Jun 2025 11:20:34 GMT Subject: Integrated: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com> Message-ID: On Thu, 19 Jun 2025 09:14:14 GMT, Afshin Zafari wrote: > The test expects that two disjunct regions are reserved but checked it incompletely. > It is fixed by reserving a new (third) region with the required size and then released the middle region among these three regions. > In Windows, it is not possible/valid to release middle regions. Either a whole region or a region that has the same end-address with the whole region can be released. IOW, only 'release the whole' or 'release from address A up to the end' are valid. > > Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers. > > Tested local linux-x64-debug. This pull request has now been integrated. Changeset: f5201ac1 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/f5201ac117fa66638f36cec3bc5f5059b37f2860 Stats: 22 lines in 2 files changed: 15 ins; 1 del; 6 mod 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr Reviewed-by: jsjolen, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25894 From coleenp at openjdk.org Tue Jun 24 12:10:32 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jun 2025 12:10:32 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com> On Mon, 23 Jun 2025 21:18:09 GMT, Alex Menkov wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a byte buffer version and rename parameters. > > test/lib/RedefineClassHelper.java line 87: > >> 85: } >> 86: return 0; >> 87: } > > I understand, that this is copy of the old code, but this method does not look good. > - it would be better to return -1 if the string not found (0 is valid offset) > - calculation of the buf's upper bound is incorrect when offset > 0 > I'd suggest to update it to something like (not tested, also need to update callers to compare with -1) > > > private static int getStringIndex(String needle, byte[] buf, int offset) { > byte[] needleArray = needle.getBytes(StandardCharsets.US_ASCII); > for (int i = offset; i < buf.length - needleArray.length; i++) > if (Arrays.equals(buf, offset, offset + needleArray.length, > needleArray, 0, needleArray.length)) { > return offset; > } > } > return -1; > } I did copy this code. I was hoping instead of class byte modifications that someone would suggest a Classfile API way to modify the class file bytes. @liach ? That way the class names don't have to be the same length. Above seems better code but I have to debug it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2163791674 From coleenp at openjdk.org Tue Jun 24 12:19:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jun 2025 12:19:31 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 02:50:12 GMT, David Holmes wrote: >> So actually this wasn't more racy than what was there in this respect. You could change the global method before taking the ttyLock and for multiple threads, this would claim that the current method had changed. The old code also had shared state for BytecodeTracer. Now this uses a local instance, which can then print the bytecode at the given location. > > So the old code (mis)used a shared `ByteCodeTracer` instance, and the new code gives each use a local `ByteCodeTracer` but seeds it from the global shared field. So I agree the level of raciness seems unchanged. > > But printing an unrelated method name still seems a bad thing to do. ?? > > BTW it is also very confusing to give the global variable the same name as the private field in `ByteCodeTracer`. It would print the right name it would just print it again. Say: t1 printing M1 so prints the name t1 aload t1 astore t2 printing M2 method name t2 getfield t1 < continues printing M1 but method name was changed to M2> prints M1 method name t1 invokevirtual ... The thread id is printed before each line. Using this with multiple threads is not ideal for getting information clearly but that's not what people do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2163825644 From coleenp at openjdk.org Tue Jun 24 12:30:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jun 2025 12:30:11 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: References: Message-ID: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> > This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: > > [490166] static void java.lang.String.() > [490166] 13 18 putstatic 613 > [490166] 14 21 return > > [490166] static void java.lang.System.() > [490166] 15 0 invokestatic 471 > [490166] 16 3 aconst_null > [490166] 17 4 putstatic 474 > > Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. > Also ran tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Some renaming and more comments and a load_acquire. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25915/files - new: https://git.openjdk.org/jdk/pull/25915/files/5cdc5e11..fa938107 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=02-03 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25915/head:pull/25915 PR: https://git.openjdk.org/jdk/pull/25915 From coleenp at openjdk.org Tue Jun 24 12:30:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jun 2025 12:30:11 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 02:50:52 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Put back include osthread.hpp > > src/hotspot/share/interpreter/bytecodeTracer.cpp line 186: > >> 184: void BytecodeTracer::trace_interpreter(const methodHandle& method, address bcp, uintptr_t tos, uintptr_t tos2, outputStream* st) { >> 185: if (TraceBytecodes && BytecodeCounter::counter_value() >= TraceBytecodesAt) { >> 186: BytecodePrinter printer(_current_method); > > You need a `Atomic::load_acquire` here to pair with the `Atomic::release_store` below. ok, added and changed the name of current_method, and added comments. Hope it helps. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2163855972 From gziemski at openjdk.org Tue Jun 24 13:11:29 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 24 Jun 2025 13:11:29 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 07:52:38 GMT, Afshin Zafari wrote: > The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block. > > Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release} Marked as reviewed by gziemski (Reviewer). test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 452: > 450: MemTracker::NmtVirtualMemoryLocker nvml; > 451: rtree = VirtualMemoryTracker::Instance::tree(); > 452: rtree->tree().remove_all(); I think I asked about this before - can we do remove_all in the constructor to avoid this 2 line repeating pattern? Otherwise looks good, can you please check the GHA test failures on Windows? ------------- PR Review: https://git.openjdk.org/jdk/pull/25950#pullrequestreview-2953768666 PR Review Comment: https://git.openjdk.org/jdk/pull/25950#discussion_r2163961744 From jsjolen at openjdk.org Tue Jun 24 13:29:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jun 2025 13:29:30 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 13:08:25 GMT, Gerard Ziemski wrote: >> The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block. >> >> Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release} > > test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 452: > >> 450: MemTracker::NmtVirtualMemoryLocker nvml; >> 451: rtree = VirtualMemoryTracker::Instance::tree(); >> 452: rtree->tree().remove_all(); > > I think I asked about this before - can we do remove_all in the constructor to avoid this 2 line repeating pattern? > > Otherwise looks good, can you please check the GHA test failures on Windows? I don't think that's the right way to go. I think it's better if we can avoid using the global instance, and not change the code of the VMT in order to appease the tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25950#discussion_r2164009678 From azafari at openjdk.org Tue Jun 24 14:52:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 24 Jun 2025 14:52:09 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken [v2] In-Reply-To: References: Message-ID: > The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block. > > Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release} Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: local VMT vs static one. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25950/files - new: https://git.openjdk.org/jdk/pull/25950/files/461a00ed..51600cdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25950&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25950&range=00-01 Stats: 141 lines in 5 files changed: 18 ins; 36 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/25950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25950/head:pull/25950 PR: https://git.openjdk.org/jdk/pull/25950 From kbarrett at openjdk.org Tue Jun 24 15:23:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 24 Jun 2025 15:23:45 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string [v2] In-Reply-To: References: Message-ID: > Please review this fix for the format directive when printing ULLONG_MAX by > TestArguments.atojulong gtest. Instead of using JULONG_FORMAT, which might not > be the proper type (though sized properly), use "%llu" to avoid potential > warning. > > Also changed the test_arguments.cpp file to use os::snprintf instead of > jio_snprintf, and improved checking the results of those calls. > > Testing: mach5 tier1 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: back out jio_snprintf => os::snprintf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25927/files - new: https://git.openjdk.org/jdk/pull/25927/files/2bde7b43..3ca9157a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25927&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25927&range=00-01 Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25927/head:pull/25927 PR: https://git.openjdk.org/jdk/pull/25927 From kbarrett at openjdk.org Tue Jun 24 15:23:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 24 Jun 2025 15:23:45 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string [v2] In-Reply-To: References: Message-ID: <4A6Ljz9XnOGYKdnDcBJyzsAGY28kv5LVBCZXO1i07r0=.ba6c78dd-28a5-45a5-b367-f3ab7257dfe2@github.com> On Mon, 23 Jun 2025 07:31:29 GMT, David Holmes wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> back out jio_snprintf => os::snprintf > > test/hotspot/gtest/runtime/test_arguments.cpp line 32: > >> 30: #include >> 31: >> 32: #include "unittest.hpp" > > Is there a rule/guideline that says this should be placed here? The unittest.hpp include is clearly improperly ordered, so should be moved. The question is, where to. It's very common for it to be the last include. And the header itself suggests it is supposed to be last: https://github.com/openjdk/jdk/blob/0514cee6c884b6d31735551b8a3ce7a2be661094/test/hotspot/gtest/unittest.hpp#L46-L47 My recollection is that there used to be documentation (possibly internal or preliminatry during development of gtest support) that it needed to be last. But that doesn't seem to have made it into the public documentation. It was left out of the style guide include order rules because it was still under discussion / investigation. > test/hotspot/gtest/runtime/test_arguments.cpp line 51: > >> 49: char buf[1024]; >> 50: int ret = os::snprintf(buf, sizeof(buf), "%s=%s", name, value); >> 51: if ((ret > 0) && ((size_t)ret < sizeof(buf))) { > > `jio_snprintf` already handled the buffer-too-small case by returning -1. I don't see the reason for changing the test to use `os::snprintf` when arguments.cpp uses `jio_snprintf`. @coleenp and I have been discussing JDK-8198918, including `jio_snprintf`, and wanting to move away from it, at least in VM code. Since this change is in preparation for that issue, I included a bit of "cleanup". But yeah, that should probably wait for further discussion. I've backed out the changes related to that. > test/hotspot/gtest/runtime/test_arguments.cpp line 63: > >> 61: int ret = os::snprintf(ullong_max, sizeof(ullong_max), "%llu", ULLONG_MAX); >> 62: ASSERT_LT(0, ret); >> 63: ASSERT_LT(ret, (int)sizeof(ullong_max)); > > This is just a sanity check right? Maximum uint64_t has 20 digits. Backed out - see other reply. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2164307139 PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2164307055 PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2164308328 From liach at openjdk.org Tue Jun 24 15:59:32 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 24 Jun 2025 15:59:32 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com> Message-ID: On Tue, 24 Jun 2025 12:07:53 GMT, Coleen Phillimore wrote: >> test/lib/RedefineClassHelper.java line 87: >> >>> 85: } >>> 86: return 0; >>> 87: } >> >> I understand, that this is copy of the old code, but this method does not look good. >> - it would be better to return -1 if the string not found (0 is valid offset) >> - calculation of the buf's upper bound is incorrect when offset > 0 >> I'd suggest to update it to something like (not tested, also need to update callers to compare with -1) >> >> >> private static int getStringIndex(String needle, byte[] buf, int offset) { >> byte[] needleArray = needle.getBytes(StandardCharsets.US_ASCII); >> for (int i = offset; i < buf.length - needleArray.length; i++) >> if (Arrays.equals(buf, offset, offset + needleArray.length, >> needleArray, 0, needleArray.length)) { >> return offset; >> } >> } >> return -1; >> } > > I did copy this code. I was hoping instead of class byte modifications that someone would suggest a Classfile API way to modify the class file bytes. @liach ? That way the class names don't have to be the same length. Above seems better code but I have to debug it now. `jdk.internal.classfile.components` has a `ClassRemapper` that may serve this purpose. It updates all internal names and occurrences in descriptors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2164386948 From dlong at openjdk.org Tue Jun 24 16:16:36 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 24 Jun 2025 16:16:36 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com> On Tue, 24 Jun 2025 03:21:39 GMT, Fei Yang wrote: >> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8358821-patch-verified-entry >> - 2nd try at arm fix >> - rename arm_with to guard_with >> - arm32 fix >> - s390 fix courtesy of Amit Kumar >> - remove is_sigill_not_entrant >> - more cleanup >> - more TheRealMDoerr suggestions >> - TheRealMDoerr suggestions >> - remove trailing space >> - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c > > Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc. Thanks @RealFYang. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3001102616 From eosterlund at openjdk.org Tue Jun 24 16:43:35 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 24 Jun 2025 16:43:35 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8358821-patch-verified-entry > - 2nd try at arm fix > - rename arm_with to guard_with > - arm32 fix > - s390 fix courtesy of Amit Kumar > - remove is_sigill_not_entrant > - more cleanup > - more TheRealMDoerr suggestions > - TheRealMDoerr suggestions > - remove trailing space > - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2954594316 From eosterlund at openjdk.org Tue Jun 24 16:43:35 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 24 Jun 2025 16:43:35 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 19:10:03 GMT, Dean Long wrote: > I think it's OK if there is a race to have a point of no return, and if one thread gets there first, it wins, and we don't need to check again. It's tempting to want to do an extra check when we disarm under the lock, but then it would need a comment explaining why we do it, even though the make_not_entrant could come in right after and we would miss it. And we have already done the work of healing the oops by this point. Finally, I like the encapsulation that only nmethod_stub_entry_barrier needs to know about not_entrant, and nmethod_entry_barrier doesn't need to know. Fair enough! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2164467913 From gziemski at openjdk.org Tue Jun 24 16:44:31 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 24 Jun 2025 16:44:31 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken [v2] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 13:27:15 GMT, Johan Sj?len wrote: >> test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 452: >> >>> 450: MemTracker::NmtVirtualMemoryLocker nvml; >>> 451: rtree = VirtualMemoryTracker::Instance::tree(); >>> 452: rtree->tree().remove_all(); >> >> I think I asked about this before - can we do remove_all in the constructor to avoid this 2 line repeating pattern? >> >> Otherwise looks good, can you please check the GHA test failures on Windows? > > I don't think that's the right way to go. I think it's better if we can avoid using the global instance, and not change the code of the VMT in order to appease the tests. Sure, I suggested the easiest fix I could think of, but doing it this way is even better! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25950#discussion_r2164469900 From coleenp at openjdk.org Tue Jun 24 21:24:30 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Jun 2025 21:24:30 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v4] In-Reply-To: References: Message-ID: <0MG5jjekeLzIPKH1k_L_tIsAw01FRnkTeg9T79sONAY=.f99bfc55-dd73-4dcc-b1f8-f591af845f66@github.com> On Wed, 4 Jun 2025 06:08:09 GMT, Roman Kennke wrote: >> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Refine text The updated text looks good. Sorry for the delay. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2955386796 From dholmes at openjdk.org Tue Jun 24 23:46:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jun 2025 23:46:37 GMT Subject: RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump Message-ID: We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. The simple fix is to only walk JavaThreads. Testing - tier 5 JFR tests - selected tests with JFR explicitly enabled - tier 1-3 (sanity) Thanks ------------- Commit messages: - 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump Changes: https://git.openjdk.org/jdk/pull/25963/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25963&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358645 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25963.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25963/head:pull/25963 PR: https://git.openjdk.org/jdk/pull/25963 From dholmes at openjdk.org Wed Jun 25 02:48:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 02:48:28 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: On Tue, 24 Jun 2025 12:30:11 GMT, Coleen Phillimore wrote: >> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: >> >> [490166] static void java.lang.String.() >> [490166] 13 18 putstatic 613 >> [490166] 14 21 return >> >> [490166] static void java.lang.System.() >> [490166] 15 0 invokestatic 471 >> [490166] 16 3 aconst_null >> [490166] 17 4 putstatic 474 >> >> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. >> Also ran tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some renaming and more comments and a load_acquire. Okay I finally realized the strange way in which this code works. You could use a ThreadLocal for the current method being printed. But I'm okay with the current changes. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25915#pullrequestreview-2956114028 From dholmes at openjdk.org Wed Jun 25 04:16:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 04:16:28 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string [v2] In-Reply-To: References: Message-ID: <7fSFRzcnTVA_BenqAk3LzqzL8tK-VVCDqISK3V5HsvY=.37cb3b6f-555d-44d1-8439-bb0f0ed44b0b@github.com> On Tue, 24 Jun 2025 15:23:45 GMT, Kim Barrett wrote: >> Please review this fix for the format directive when printing ULLONG_MAX by >> TestArguments.atojulong gtest. Instead of using JULONG_FORMAT, which might not >> be the proper type (though sized properly), use "%llu" to avoid potential >> warning. >> >> Also changed the test_arguments.cpp file to use os::snprintf instead of >> jio_snprintf, and improved checking the results of those calls. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > back out jio_snprintf => os::snprintf Good - and now trivial. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25927#pullrequestreview-2956424786 From dholmes at openjdk.org Wed Jun 25 04:16:29 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 04:16:29 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string [v2] In-Reply-To: <4A6Ljz9XnOGYKdnDcBJyzsAGY28kv5LVBCZXO1i07r0=.ba6c78dd-28a5-45a5-b367-f3ab7257dfe2@github.com> References: <4A6Ljz9XnOGYKdnDcBJyzsAGY28kv5LVBCZXO1i07r0=.ba6c78dd-28a5-45a5-b367-f3ab7257dfe2@github.com> Message-ID: On Tue, 24 Jun 2025 15:19:17 GMT, Kim Barrett wrote: >> test/hotspot/gtest/runtime/test_arguments.cpp line 32: >> >>> 30: #include >>> 31: >>> 32: #include "unittest.hpp" >> >> Is there a rule/guideline that says this should be placed here? > > The unittest.hpp include is clearly improperly ordered, so should be moved. > The question is, where to. It's very common for it to be the last include. > And the header itself suggests it is supposed to be last: > https://github.com/openjdk/jdk/blob/0514cee6c884b6d31735551b8a3ce7a2be661094/test/hotspot/gtest/unittest.hpp#L46-L47 > > My recollection is that there used to be documentation (possibly internal or > preliminatry during development of gtest support) that it needed to be last. > But that doesn't seem to have made it into the public documentation. It was > left out of the style guide include order rules because it was still under > discussion / investigation. We should try to get that documented as this arose in another PR last week. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2165668338 From sspitsyn at openjdk.org Wed Jun 25 05:32:36 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 25 Jun 2025 05:32:36 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com> Message-ID: <1WAK-jwxvbp541uQys8DQvX0XdWJU4qp6LkqwiqJYvM=.e4adb6be-e910-4639-8836-45eac9037ab3@github.com> On Tue, 24 Jun 2025 15:56:49 GMT, Chen Liang wrote: >> I did copy this code. I was hoping instead of class byte modifications that someone would suggest a Classfile API way to modify the class file bytes. @liach ? That way the class names don't have to be the same length. Above seems better code but I have to debug it now. > > `jdk.internal.classfile.components` has a `ClassRemapper` that may serve this purpose. It updates all internal names and occurrences in descriptors. BTW, I've also noticed this issue with returning 0 but forgot to post my question. This suggestion from Alex looks good to me, at least, if the `ClassRemapper` is tricky to borrow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2165816599 From dholmes at openjdk.org Wed Jun 25 08:00:06 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 08:00:06 GMT Subject: RFR: 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings Message-ID: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> The test creates a `String` with `Integer.MAX_VALUE/2 + 1` characters, where the character encodes as two bytes in UTF-8. That way we test when the UTF-8 length is greater than `Integer.MAX_VALUE`. However, when compact strings are disabled the maximum length of a `String`, in characters, is `Integer.MAX_VALUE/2` so the test throws a (synthetic) OOME. The fix I chose was to change the test so that we create a slightly shorter `String` (that will always fit regardless of the compact-strings setting) but to fill it with a character that encodes to three bytes in UTF-8. Hence we still test that the UTF-8 length exceeds `Integer.MAX_LENGTH`. Tested on Windows x64, Linux x64 and Aarch64, macOS x64 and Aarch64; on release and fastdebug builds. Thanks ------------- Commit messages: - 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings Changes: https://git.openjdk.org/jdk/pull/25970/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25970&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360255 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25970.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25970/head:pull/25970 PR: https://git.openjdk.org/jdk/pull/25970 From rkennke at openjdk.org Wed Jun 25 08:11:41 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 25 Jun 2025 08:11:41 GMT Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production) [v4] In-Reply-To: References: Message-ID: <1msWTJ5J_T0pbSY9rOU08cyr5QGtiRCCA7lVRn70Ne8=.359d19db-1f9b-4f70-b846-ecb74f052f78@github.com> On Wed, 4 Jun 2025 06:08:09 GMT, Roman Kennke wrote: >> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Refine text Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-3003794406 From rkennke at openjdk.org Wed Jun 25 08:11:41 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 25 Jun 2025 08:11:41 GMT Subject: Integrated: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: <37DOCBJKr2BCOpqGS17rMSYDgWV0-DdG-73UjYE2EzI=.bbd57120-07fa-411b-b2f6-fb252cfc8bd0@github.com> On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke wrote: > Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'. This pull request has now been integrated. Changeset: 75ce44aa Author: Roman Kennke URL: https://git.openjdk.org/jdk/commit/75ce44aa84ebf0f48dd73b98f2bf2d6077473ed1 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8355319: Update Manpage for Compact Object Headers (Production) Reviewed-by: coleenp, dholmes, phh ------------- PR: https://git.openjdk.org/jdk/pull/25491 From ktakakuri at openjdk.org Wed Jun 25 08:18:19 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Wed, 25 Jun 2025 08:18:19 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v8] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 09:27:43 GMT, Alan Bateman wrote: >> @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it? > >> @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it? > > Sure, just have some drive by comments, switching to cp437 should be okay. @AlanBateman Thank you for the suggested fixes. I modified the code as such. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-3003813567 From ktakakuri at openjdk.org Wed Jun 25 08:18:19 2025 From: ktakakuri at openjdk.org (Kazuhisa Takakuri) Date: Wed, 25 Jun 2025 08:18:19 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v9] In-Reply-To: References: Message-ID: > To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. > I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. > After this fix, I verified that the test passed. > > https://github.com/openjdk/jdk/pull/22142 > I refer to this fix. > tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. > > Thanks. Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23536/files - new: https://git.openjdk.org/jdk/pull/23536/files/363c5a39..3490e658 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23536&range=07-08 Stats: 11 lines in 1 file changed: 3 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23536/head:pull/23536 PR: https://git.openjdk.org/jdk/pull/23536 From cnorrbin at openjdk.org Wed Jun 25 08:35:34 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 25 Jun 2025 08:35:34 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 11:33:03 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data. >> >> The new parameters are: >> >> - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time. >> >> - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed. >> >> - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems. >> >> Testing: >> - All container tests under `/test/hotspot/jtreg/containers/` >> - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > update cpu usage to use >= > > Co-authored-by: Severin Gehwolf Thank you for the reviews. With no objections, I'll go ahead and integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25388#issuecomment-3003873827 From cnorrbin at openjdk.org Wed Jun 25 08:35:35 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 25 Jun 2025 08:35:35 GMT Subject: Integrated: 8356868: Not all cgroup parameters are made available In-Reply-To: References: Message-ID: On Thu, 22 May 2025 09:06:15 GMT, Casper Norrbin wrote: > Hi everyone, > > This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data. > > The new parameters are: > > - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time. > > - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed. > > - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems. > > Testing: > - All container tests under `/test/hotspot/jtreg/containers/` > - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied. This pull request has now been integrated. Changeset: 850bc203 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/850bc20306e5101d164566f9a8687707492b296b Stats: 163 lines in 10 files changed: 148 ins; 0 del; 15 mod 8356868: Not all cgroup parameters are made available Reviewed-by: sgehwolf, gziemski ------------- PR: https://git.openjdk.org/jdk/pull/25388 From fbredberg at openjdk.org Wed Jun 25 08:42:27 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 25 Jun 2025 08:42:27 GMT Subject: RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 23:43:05 GMT, David Holmes wrote: > We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. > > The simple fix is to only walk JavaThreads. > > Testing > - tier 5 JFR tests > - selected tests with JFR explicitly enabled > - tier 1-3 (sanity) > > Thanks Looks good to me. ------------- Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/25963#pullrequestreview-2957231798 From shade at openjdk.org Wed Jun 25 08:50:32 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 25 Jun 2025 08:50:32 GMT Subject: RFR: 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings In-Reply-To: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> References: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> Message-ID: On Wed, 25 Jun 2025 07:54:16 GMT, David Holmes wrote: > The test creates a `String` with `Integer.MAX_VALUE/2 + 1` characters, where the character encodes as two bytes in UTF-8. That way we test when the UTF-8 length is greater than `Integer.MAX_VALUE`. However, when compact strings are disabled the maximum length of a `String`, in characters, is `Integer.MAX_VALUE/2` so the test throws a (synthetic) OOME. > > The fix I chose was to change the test so that we create a slightly shorter `String` (that will always fit regardless of the compact-strings setting) but to fill it with a character that encodes to three bytes in UTF-8. Hence we still test that the UTF-8 length exceeds `Integer.MAX_LENGTH`. > > Tested on Windows x64, Linux x64 and Aarch64, macOS x64 and Aarch64; on release and fastdebug builds. > > Thanks Cute trick. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25970#pullrequestreview-2957264613 From dholmes at openjdk.org Wed Jun 25 09:07:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 09:07:28 GMT Subject: RFR: 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings In-Reply-To: References: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> Message-ID: <3R_BPSohBP1lNbD-4rq54Ythjv-jjJP6_TQU9DJVRf4=.228ef232-aa08-4a09-88ef-3f59e4b67902@github.com> On Wed, 25 Jun 2025 08:47:37 GMT, Aleksey Shipilev wrote: >> The test creates a `String` with `Integer.MAX_VALUE/2 + 1` characters, where the character encodes as two bytes in UTF-8. That way we test when the UTF-8 length is greater than `Integer.MAX_VALUE`. However, when compact strings are disabled the maximum length of a `String`, in characters, is `Integer.MAX_VALUE/2` so the test throws a (synthetic) OOME. >> >> The fix I chose was to change the test so that we create a slightly shorter `String` (that will always fit regardless of the compact-strings setting) but to fill it with a character that encodes to three bytes in UTF-8. Hence we still test that the UTF-8 length exceeds `Integer.MAX_LENGTH`. >> >> Tested on Windows x64, Linux x64 and Aarch64, macOS x64 and Aarch64; on release and fastdebug builds. >> >> Thanks > > Cute trick. Looks fine. Thanks for the review @shipilev ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25970#issuecomment-3003999200 From dholmes at openjdk.org Wed Jun 25 09:08:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 09:08:27 GMT Subject: RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 08:39:41 GMT, Fredrik Bredberg wrote: >> We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. >> >> The simple fix is to only walk JavaThreads. >> >> Testing >> - tier 5 JFR tests >> - selected tests with JFR explicitly enabled >> - tier 1-3 (sanity) >> >> Thanks > > Looks good to me. Thanks for the review @fbredber ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25963#issuecomment-3004004507 From shade at openjdk.org Wed Jun 25 09:11:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 25 Jun 2025 09:11:28 GMT Subject: RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 23:43:05 GMT, David Holmes wrote: > We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. > > The simple fix is to only walk JavaThreads. > > Testing > - tier 5 JFR tests > - selected tests with JFR explicitly enabled > - tier 1-3 (sanity) > > Thanks OK, this makes sense. I would probably phrase the comment to capture exactly the race we try to avoid. E.g.: "We can only trust _threads_list_ptr when it is not actively updated. This is only guaranteed when we are inspecting a JavaThread and we are at safepoint, or if any thread inspects itself." This also raises a minor question if null-checking `_threads_list_ptr` in `EnableThreadSMRStatistics` block above is benign. Looks like it, but maybe we want to move that block under the safepoint/thread check as well. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25963#pullrequestreview-2957340492 From mdoerr at openjdk.org Wed Jun 25 09:52:37 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 25 Jun 2025 09:52:37 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8358821-patch-verified-entry > - 2nd try at arm fix > - rename arm_with to guard_with > - arm32 fix > - s390 fix courtesy of Amit Kumar > - remove is_sigill_not_entrant > - more cleanup > - more TheRealMDoerr suggestions > - TheRealMDoerr suggestions > - remove trailing space > - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c src/hotspot/share/gc/shared/barrierSetNMethod.hpp line 52: > 50: > 51: public: > 52: BarrierSetNMethod() : _current_phase(initial) {} @fisk: The initial value doesn't match our initialization in the nmethod entry barrier code were we use 0. That causes all new nmethods to run through the barrier code when they are called for the first time. I think that is unnecessary and it slows down the startup a bit. All oops should already be correct after the nmethod got installed. And for ZGC, we call `nmethod_patch_barriers` in `ZNMethod::register_nmethod`. So, I don't see any need to execute the barrier code. We could change the initialization to use `_current_phase`. Do you agree? Should I file a new JBS issue? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2166306862 From mdoerr at openjdk.org Wed Jun 25 09:59:34 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 25 Jun 2025 09:59:34 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 09:49:25 GMT, Martin Doerr wrote: >> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8358821-patch-verified-entry >> - 2nd try at arm fix >> - rename arm_with to guard_with >> - arm32 fix >> - s390 fix courtesy of Amit Kumar >> - remove is_sigill_not_entrant >> - more cleanup >> - more TheRealMDoerr suggestions >> - TheRealMDoerr suggestions >> - remove trailing space >> - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c > > src/hotspot/share/gc/shared/barrierSetNMethod.hpp line 52: > >> 50: >> 51: public: >> 52: BarrierSetNMethod() : _current_phase(initial) {} > > @fisk: The initial value doesn't match our initialization in the nmethod entry barrier code were we use 0. That causes all new nmethods to run through the barrier code when they are called for the first time. I think that is unnecessary and it slows down the startup a bit. All oops should already be correct after the nmethod got installed. And for ZGC, we call `nmethod_patch_barriers` in `ZNMethod::register_nmethod`. So, I don't see any need to execute the barrier code. We could change the initialization to use `_current_phase`. Do you agree? Should I file a new JBS issue? In other words, I think `disarm(nm);` is missing for some GCs. ZGC has it in `ZNMethod::register_nmethod`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2166322229 From shade at openjdk.org Wed Jun 25 10:13:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 25 Jun 2025 10:13:49 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v3] In-Reply-To: References: Message-ID: > A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". > > I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `runtime/cds` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Add bug line - Merge branch 'master' into JDK-8359436-aot-diagnostic - Merge branch 'master' into JDK-8359436-aot-diagnostic - Test - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25799/files - new: https://git.openjdk.org/jdk/pull/25799/files/c62f367f..6b84ae34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25799&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25799&range=01-02 Stats: 30773 lines in 831 files changed: 17260 ins; 9201 del; 4312 mod Patch: https://git.openjdk.org/jdk/pull/25799.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25799/head:pull/25799 PR: https://git.openjdk.org/jdk/pull/25799 From shade at openjdk.org Wed Jun 25 10:13:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 25 Jun 2025 10:13:49 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 14:57:18 GMT, Vladimir Kozlov wrote: > May be modify `aotProfile/AOTProfileFlags.java` instead. Would prefer to have it in separate file, for the occasion we remove/modify the flag later. > test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCompileEagerly.java line 1: > >> 1: /* > > There is `aotProfile` directory for training data testing. I think the connection to training data is not very direct with this flag, so I'll keep it in generic folder. > test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCompileEagerly.java line 27: > >> 25: >> 26: /* >> 27: * @test > > Missing ` * @bug 8359436` Added, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-3004206955 PR Review Comment: https://git.openjdk.org/jdk/pull/25799#discussion_r2166348984 PR Review Comment: https://git.openjdk.org/jdk/pull/25799#discussion_r2166347752 From rkennke at openjdk.org Wed Jun 25 10:56:37 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 25 Jun 2025 10:56:37 GMT Subject: [jdk25] RFR: 8355319: Update Manpage for Compact Object Headers (Production) Message-ID: Hi all, This pull request contains a backport of commit [75ce44aa](https://github.com/openjdk/jdk/commit/75ce44aa84ebf0f48dd73b98f2bf2d6077473ed1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Roman Kennke on 25 Jun 2025 and was reviewed by Coleen Phillimore, David Holmes and Paul Hohensee. Thanks! ------------- Commit messages: - Backport 75ce44aa84ebf0f48dd73b98f2bf2d6077473ed1 Changes: https://git.openjdk.org/jdk/pull/25974/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25974&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355319 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25974/head:pull/25974 PR: https://git.openjdk.org/jdk/pull/25974 From dholmes at openjdk.org Wed Jun 25 12:09:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 12:09:28 GMT Subject: RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 09:09:05 GMT, Aleksey Shipilev wrote: >> We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. >> >> The simple fix is to only walk JavaThreads. >> >> Testing >> - tier 5 JFR tests >> - selected tests with JFR explicitly enabled >> - tier 1-3 (sanity) >> >> Thanks > > OK, this makes sense. I would probably phrase the comment to capture exactly the race we try to avoid. Something in vicinity of: > > "We can only trust the list contents when the list is not actively updated. This is only guaranteed when we are inspecting a JavaThread and we are at safepoint, or if any thread inspects itself." > > This also raises a minor question if null-checking `_threads_list_ptr` in `EnableThreadSMRStatistics` block above is benign. Looks like it, but maybe we want to move that block under the safepoint/thread check as well. Thanks for the review @shipilev . > This also raises a minor question if null-checking _threads_list_ptr in EnableThreadSMRStatistics block above is benign. Yes it is benign. Reading the pointer will either return null or not but we don't use that pointer. The subsequent read of the count field will either return 0 or not. But I think for a NJT we will never see a nested TLH count anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25963#issuecomment-3004533148 From kbarrett at openjdk.org Wed Jun 25 12:56:35 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 25 Jun 2025 12:56:35 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string [v2] In-Reply-To: References: <4A6Ljz9XnOGYKdnDcBJyzsAGY28kv5LVBCZXO1i07r0=.ba6c78dd-28a5-45a5-b367-f3ab7257dfe2@github.com> Message-ID: On Wed, 25 Jun 2025 04:12:52 GMT, David Holmes wrote: >> The unittest.hpp include is clearly improperly ordered, so should be moved. >> The question is, where to. It's very common for it to be the last include. >> And the header itself suggests it is supposed to be last: >> https://github.com/openjdk/jdk/blob/0514cee6c884b6d31735551b8a3ce7a2be661094/test/hotspot/gtest/unittest.hpp#L46-L47 >> >> My recollection is that there used to be documentation (possibly internal or >> preliminatry during development of gtest support) that it needed to be last. >> But that doesn't seem to have made it into the public documentation. It was >> left out of the style guide include order rules because it was still under >> discussion / investigation. > > We should try to get that documented as this arose in another PR last week. https://bugs.openjdk.org/browse/JDK-8360524 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25927#discussion_r2166647205 From rehn at openjdk.org Wed Jun 25 13:54:29 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 25 Jun 2025 13:54:29 GMT Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 09:27:14 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk. > > These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu. > > Thanks! Hey, you can already disable them by adding "--disable-jvm-feature-cds" to your configure line. As they have "@requires vm.cds" they are skipped. (exception is this test: https://bugs.openjdk.org/browse/JDK-8353034) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3004862749 From mdoerr at openjdk.org Wed Jun 25 14:51:33 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 25 Jun 2025 14:51:33 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 09:56:52 GMT, Martin Doerr wrote: >> src/hotspot/share/gc/shared/barrierSetNMethod.hpp line 52: >> >>> 50: >>> 51: public: >>> 52: BarrierSetNMethod() : _current_phase(initial) {} >> >> @fisk: The initial value doesn't match our initialization in the nmethod entry barrier code were we use 0. That causes all new nmethods to run through the barrier code when they are called for the first time. I think that is unnecessary and it slows down the startup a bit. All oops should already be correct after the nmethod got installed. And for ZGC, we call `nmethod_patch_barriers` in `ZNMethod::register_nmethod`. So, I don't see any need to execute the barrier code. We could change the initialization to use `_current_phase`. Do you agree? Should I file a new JBS issue? > > In other words, I think `disarm(nm);` is missing for some GCs. ZGC has it in `ZNMethod::register_nmethod`. I've filed https://bugs.openjdk.org/browse/JDK-8360540. We don't need to discuss it here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2166924488 From kbarrett at openjdk.org Wed Jun 25 15:20:34 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 25 Jun 2025 15:20:34 GMT Subject: RFR: 8360178: TestArguments.atojulong gtest has incorrect format string [v2] In-Reply-To: <7fSFRzcnTVA_BenqAk3LzqzL8tK-VVCDqISK3V5HsvY=.37cb3b6f-555d-44d1-8439-bb0f0ed44b0b@github.com> References: <7fSFRzcnTVA_BenqAk3LzqzL8tK-VVCDqISK3V5HsvY=.37cb3b6f-555d-44d1-8439-bb0f0ed44b0b@github.com> Message-ID: On Wed, 25 Jun 2025 04:13:51 GMT, David Holmes wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> back out jio_snprintf => os::snprintf > > Good - and now trivial. > > Thanks Thanks for review @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/25927#issuecomment-3005165663 From kbarrett at openjdk.org Wed Jun 25 15:20:34 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 25 Jun 2025 15:20:34 GMT Subject: Integrated: 8360178: TestArguments.atojulong gtest has incorrect format string In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 02:05:29 GMT, Kim Barrett wrote: > Please review this fix for the format directive when printing ULLONG_MAX by > TestArguments.atojulong gtest. Instead of using JULONG_FORMAT, which might not > be the proper type (though sized properly), use "%llu" to avoid potential > warning. > > Also changed the test_arguments.cpp file to use os::snprintf instead of > jio_snprintf, and improved checking the results of those calls. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 878497fb Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/878497fb85b9f7d066829b745324028f9f8cdc60 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod 8360178: TestArguments.atojulong gtest has incorrect format string Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25927 From coleenp at openjdk.org Wed Jun 25 15:35:30 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jun 2025 15:35:30 GMT Subject: [jdk25] RFR: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 10:40:17 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [75ce44aa](https://github.com/openjdk/jdk/commit/75ce44aa84ebf0f48dd73b98f2bf2d6077473ed1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Roman Kennke on 25 Jun 2025 and was reviewed by Coleen Phillimore, David Holmes and Paul Hohensee. > > Thanks! The backport looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25974#pullrequestreview-2958678603 From kvn at openjdk.org Wed Jun 25 16:21:30 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 25 Jun 2025 16:21:30 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v3] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 10:13:49 GMT, Aleksey Shipilev wrote: >> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". >> >> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `runtime/cds` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Add bug line > - Merge branch 'master' into JDK-8359436-aot-diagnostic > - Merge branch 'master' into JDK-8359436-aot-diagnostic > - Test > - Fix Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2958846509 From shade at openjdk.org Wed Jun 25 17:42:30 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 25 Jun 2025 17:42:30 GMT Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v3] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 10:13:49 GMT, Aleksey Shipilev wrote: >> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic". >> >> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `runtime/cds` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Add bug line > - Merge branch 'master' into JDK-8359436-aot-diagnostic > - Merge branch 'master' into JDK-8359436-aot-diagnostic > - Test > - Fix Thanks! I think I am going to wait for JDK 25 enhancement request to be approved first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-3005628083 From coleenp at openjdk.org Wed Jun 25 18:06:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jun 2025 18:06:45 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v4] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com> > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use ClassFile API to replace the class name. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/ed342127..b0fe16c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=02-03 Stats: 54 lines in 1 file changed: 15 ins; 38 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From dcubed at openjdk.org Wed Jun 25 18:41:29 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 25 Jun 2025 18:41:29 GMT Subject: RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 23:43:05 GMT, David Holmes wrote: > We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. > > The simple fix is to only walk JavaThreads. > > Testing > - tier 5 JFR tests > - selected tests with JFR explicitly enabled > - tier 1-3 (sanity) > > Thanks Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25963#pullrequestreview-2959250759 From liach at openjdk.org Wed Jun 25 18:52:30 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 25 Jun 2025 18:52:30 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v4] In-Reply-To: <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com> Message-ID: On Wed, 25 Jun 2025 18:06:45 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ClassFile API to replace the class name. test/lib/RedefineClassHelper.java line 95: > 93: ClassDesc newClassDesc = ClassDesc.of(newClassName); > 94: byte[] newBytes = ClassFile.of().build(newClassDesc, > 95: classBuilder -> { Can replace this lambda with `classModel::forEach` method reference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167390696 From dlong at openjdk.org Wed Jun 25 19:28:35 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 25 Jun 2025 19:28:35 GMT Subject: Integrated: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 01:51:09 GMT, Dean Long wrote: > This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. > > We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. > > The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. > > For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. > > This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. This pull request has now been integrated. Changeset: cf75f1f9 Author: Dean Long URL: https://git.openjdk.org/jdk/commit/cf75f1f9c6d2bc70c7133cb81c73a0ce0946dff9 Stats: 603 lines in 43 files changed: 97 ins; 459 del; 47 mod 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead Co-authored-by: Martin Doerr Co-authored-by: Amit Kumar Reviewed-by: mdoerr, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/25764 From mli at openjdk.org Wed Jun 25 20:18:27 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 25 Jun 2025 20:18:27 GMT Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu In-Reply-To: References: Message-ID: <_Ck70rgIeGOX64LkerLC7z3gk6HRxPEP1vPOGHmi1bE=.e18fc885-25d4-4c8d-96dd-22d7727a9c9c@github.com> On Wed, 25 Jun 2025 13:51:46 GMT, Robbin Ehn wrote: > Hey, you can already disable them by adding "--disable-jvm-feature-cds" to your configure line. Yes. But that means disable all related tests, under runtime/cds there are more than 269 "require vm.cds", not all these tests fail. > As they have "@requires vm.cds" they are skipped. (exception is this test: https://bugs.openjdk.org/browse/JDK-8353034) interesting failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3006019922 From coleenp at openjdk.org Wed Jun 25 20:37:28 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jun 2025 20:37:28 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v2] In-Reply-To: <1WAK-jwxvbp541uQys8DQvX0XdWJU4qp6LkqwiqJYvM=.e4adb6be-e910-4639-8836-45eac9037ab3@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com> <1WAK-jwxvbp541uQys8DQvX0XdWJU4qp6LkqwiqJYvM=.e4adb6be-e910-4639-8836-45eac9037ab3@github.com> Message-ID: On Wed, 25 Jun 2025 05:30:18 GMT, Serguei Spitsyn wrote: >> `jdk.internal.classfile.components` has a `ClassRemapper` that may serve this purpose. It updates all internal names and occurrences in descriptors. > > BTW, I've also noticed this issue with returning 0 but forgot to post my question. This suggestion from Alex looks good to me, at least, if the `ClassRemapper` is tricky to borrow. ClassRemapper is a nice way to do this but it requires all the tests and the test jar build to use @modules to access it, so I chose a different way with the ClassFile API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167581218 From coleenp at openjdk.org Wed Jun 25 20:43:17 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jun 2025 20:43:17 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v4] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com> Message-ID: <7j7Xdx2EvvrB9TPVAy-kWwFIpG-kdPiSPCgOdQ5ahU8=.20d49ce8-98a2-446d-9ae4-4d16fdea52ae@github.com> On Wed, 25 Jun 2025 18:50:11 GMT, Chen Liang wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ClassFile API to replace the class name. > > test/lib/RedefineClassHelper.java line 95: > >> 93: ClassDesc newClassDesc = ClassDesc.of(newClassName); >> 94: byte[] newBytes = ClassFile.of().build(newClassDesc, >> 95: classBuilder -> { > > Can replace this lambda with `classModel::forEach` method reference. Thanks for the suggestion! Testing now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167589887 From liach at openjdk.org Wed Jun 25 20:43:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 25 Jun 2025 20:43:18 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v4] In-Reply-To: <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com> Message-ID: On Wed, 25 Jun 2025 18:06:45 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ClassFile API to replace the class name. test/lib/RedefineClassHelper.java line 99: > 97: classBuilder.with(ce); > 98: } > 99: }); Suggestion: byte[] newBytes = ClassFile.of().build(newClassDesc, classModel::forEach); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167585017 From coleenp at openjdk.org Wed Jun 25 20:43:17 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jun 2025 20:43:17 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v5] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Update test/lib/RedefineClassHelper.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/b0fe16c9..a8ed67c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From coleenp at openjdk.org Wed Jun 25 21:00:15 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jun 2025 21:00:15 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Made it even shorter. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/a8ed67c0..3285f4d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From dholmes at openjdk.org Wed Jun 25 21:42:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jun 2025 21:42:27 GMT Subject: RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 18:38:23 GMT, Daniel D. Daugherty wrote: >> We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. >> >> The simple fix is to only walk JavaThreads. >> >> Testing >> - tier 5 JFR tests >> - selected tests with JFR explicitly enabled >> - tier 1-3 (sanity) >> >> Thanks > > Thumbs up! Thanks for the review @dcubed-ojdk ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25963#issuecomment-3006232232 From kbarrett at openjdk.org Thu Jun 26 00:12:28 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 26 Jun 2025 00:12:28 GMT Subject: RFR: 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings In-Reply-To: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> References: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> Message-ID: <_Tsv8GBGdlFc4qQ9bK42obXuTCgLiLetiGSWtRZJgj8=.be77a94f-e18a-4027-9a13-fedeedb8649f@github.com> On Wed, 25 Jun 2025 07:54:16 GMT, David Holmes wrote: > The test creates a `String` with `Integer.MAX_VALUE/2 + 1` characters, where the character encodes as two bytes in UTF-8. That way we test when the UTF-8 length is greater than `Integer.MAX_VALUE`. However, when compact strings are disabled the maximum length of a `String`, in characters, is `Integer.MAX_VALUE/2` so the test throws a (synthetic) OOME. > > The fix I chose was to change the test so that we create a slightly shorter `String` (that will always fit regardless of the compact-strings setting) but to fill it with a character that encodes to three bytes in UTF-8. Hence we still test that the UTF-8 length exceeds `Integer.MAX_LENGTH`. > > Tested on Windows x64, Linux x64 and Aarch64, macOS x64 and Aarch64; on release and fastdebug builds. > > Thanks Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25970#pullrequestreview-2959993017 From dholmes at openjdk.org Thu Jun 26 01:05:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 26 Jun 2025 01:05:34 GMT Subject: RFR: 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings In-Reply-To: <_Tsv8GBGdlFc4qQ9bK42obXuTCgLiLetiGSWtRZJgj8=.be77a94f-e18a-4027-9a13-fedeedb8649f@github.com> References: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> <_Tsv8GBGdlFc4qQ9bK42obXuTCgLiLetiGSWtRZJgj8=.be77a94f-e18a-4027-9a13-fedeedb8649f@github.com> Message-ID: On Thu, 26 Jun 2025 00:10:05 GMT, Kim Barrett wrote: >> The test creates a `String` with `Integer.MAX_VALUE/2 + 1` characters, where the character encodes as two bytes in UTF-8. That way we test when the UTF-8 length is greater than `Integer.MAX_VALUE`. However, when compact strings are disabled the maximum length of a `String`, in characters, is `Integer.MAX_VALUE/2` so the test throws a (synthetic) OOME. >> >> The fix I chose was to change the test so that we create a slightly shorter `String` (that will always fit regardless of the compact-strings setting) but to fill it with a character that encodes to three bytes in UTF-8. Hence we still test that the UTF-8 length exceeds `Integer.MAX_LENGTH`. >> >> Tested on Windows x64, Linux x64 and Aarch64, macOS x64 and Aarch64; on release and fastdebug builds. >> >> Thanks > > Looks good. Thanks for the review @kimbarrett ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25970#issuecomment-3006655458 From dholmes at openjdk.org Thu Jun 26 01:05:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 26 Jun 2025 01:05:36 GMT Subject: Integrated: 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings In-Reply-To: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> References: <8oP4IxFxx-GcYVi1xGFkFkBpgwIz0gOBtHdrqM_7HXY=.eda33581-ac47-4cf8-a036-70df3355adb9@github.com> Message-ID: On Wed, 25 Jun 2025 07:54:16 GMT, David Holmes wrote: > The test creates a `String` with `Integer.MAX_VALUE/2 + 1` characters, where the character encodes as two bytes in UTF-8. That way we test when the UTF-8 length is greater than `Integer.MAX_VALUE`. However, when compact strings are disabled the maximum length of a `String`, in characters, is `Integer.MAX_VALUE/2` so the test throws a (synthetic) OOME. > > The fix I chose was to change the test so that we create a slightly shorter `String` (that will always fit regardless of the compact-strings setting) but to fill it with a character that encodes to three bytes in UTF-8. Hence we still test that the UTF-8 length exceeds `Integer.MAX_LENGTH`. > > Tested on Windows x64, Linux x64 and Aarch64, macOS x64 and Aarch64; on release and fastdebug builds. > > Thanks This pull request has now been integrated. Changeset: 1ca008fd Author: David Holmes URL: https://git.openjdk.org/jdk/commit/1ca008fd02496dc33e2707c102560cae1690fba5 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod 8360255: runtime/jni/checked/TestLargeUTF8Length.java fails with -XX:-CompactStrings Reviewed-by: shade, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/25970 From sspitsyn at openjdk.org Thu Jun 26 05:01:38 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 26 Jun 2025 05:01:38 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Wed, 25 Jun 2025 21:00:15 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Made it even shorter. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2960551515 From sspitsyn at openjdk.org Thu Jun 26 05:01:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 26 Jun 2025 05:01:39 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v4] In-Reply-To: <7j7Xdx2EvvrB9TPVAy-kWwFIpG-kdPiSPCgOdQ5ahU8=.20d49ce8-98a2-446d-9ae4-4d16fdea52ae@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com> <7j7Xdx2EvvrB9TPVAy-kWwFIpG-kdPiSPCgOdQ5ahU8=.20d49ce8-98a2-446d-9ae4-4d16fdea52ae@github.com> Message-ID: On Wed, 25 Jun 2025 20:39:50 GMT, Coleen Phillimore wrote: >> test/lib/RedefineClassHelper.java line 95: >> >>> 93: ClassDesc newClassDesc = ClassDesc.of(newClassName); >>> 94: byte[] newBytes = ClassFile.of().build(newClassDesc, >>> 95: classBuilder -> { >> >> Can replace this lambda with `classModel::forEach` method reference. > > Thanks for the suggestion! Testing now. Final version of this method is nice! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168108584 From lmesnik at openjdk.org Thu Jun 26 05:05:30 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 26 Jun 2025 05:05:30 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Wed, 25 Jun 2025 21:00:15 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Made it even shorter. Looks test/lib/RedefineClassHelper.java line 35: > 33: import jdk.test.lib.helpers.ClassFileInstaller; > 34: > 35: import static jdk.test.lib.Asserts.assertTrue; Is it really needed? I can't see that assertion were added. ------------- Changes requested by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2960558507 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168113468 From dholmes at openjdk.org Thu Jun 26 07:39:32 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 26 Jun 2025 07:39:32 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Wed, 25 Jun 2025 21:00:15 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Made it even shorter. This looks really neat. A couple of nits and a query. test/lib/RedefineClassHelper.java line 29: > 27: import java.lang.classfile.ClassFile; > 28: import java.lang.classfile.ClassModel; > 29: import java.util.Map; Nit: import out of order test/lib/RedefineClassHelper.java line 74: > 72: > 73: private static byte[] getBytecodes(ClassLoader loader, String name) throws Exception { > 74: try(InputStream is = loader.getResourceAsStream(name + ".class")) { Suggestion: try (InputStream is = loader.getResourceAsStream(name + ".class")) { test/lib/RedefineClassHelper.java line 92: > 90: byte[] buf = getBytecodes(loader, oldClassName); > 91: ClassModel classModel = ClassFile.of().parse(buf); > 92: return ClassFile.of().build(ClassDesc.of(newClassName), classModel::forEach); That's cool! I have no idea how to read it to understand what it does, but it is cool it can be done in one line. :) Seriously though, which part of that is doing the actual replace?? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2961031930 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168385540 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168392685 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168399258 From duke at openjdk.org Thu Jun 26 07:54:04 2025 From: duke at openjdk.org (Yagmur Eren) Date: Thu, 26 Jun 2025 07:54:04 GMT Subject: RFR: 8358748: Large page size initialization fails with assert "page_size must be a power of 2" Message-ID: The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`. Before the change: java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946 # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6 After the change: java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version LargePageSizeInBytes ( 6 ) must be a power of 2 Improperly specified VM option 'LargePageSizeInBytes=6' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ------------- Commit messages: - updating year - 8358748: Large page size initialization fails with assert "page_size must be a power of 2" Changes: https://git.openjdk.org/jdk/pull/25994/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25994&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358748 Stats: 17 lines in 4 files changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25994/head:pull/25994 PR: https://git.openjdk.org/jdk/pull/25994 From jsjolen at openjdk.org Thu Jun 26 08:04:28 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jun 2025 08:04:28 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken [v2] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 14:52:09 GMT, Afshin Zafari wrote: >> The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block. >> >> Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > local VMT vs static one. Nice! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25950#pullrequestreview-2961135149 From dholmes at openjdk.org Thu Jun 26 08:12:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 26 Jun 2025 08:12:30 GMT Subject: RFR: 8358748: Large page size initialization fails with assert "page_size must be a power of 2" In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 07:48:43 GMT, Yagmur Eren wrote: > The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`. > > Before the change: > > java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946 > # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6 > > > > After the change: > > java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version > > LargePageSizeInBytes ( 6 ) must be a power of 2 > Improperly specified VM option 'LargePageSizeInBytes=6' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. The `-XX:LargePageSizeInBytes` flag seems poorly specified. You can't use an arbitrary value in bytes as a large page size - that is just non-sensical. But I'm not sure this should be a hard error rather than applying "ergonomics" and rounding the supplied value to the nearest power-of-2 (with a warning this has happened). src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 136: > 134: "LargePageSizeInBytes ( %zu ) must be " > 135: "a power of 2\n", > 136: value); Suggestion: JVMFlag::printError(verbose, "LargePageSizeInBytes ( %zu ) must be " "a power of 2\n", value); src/hotspot/share/runtime/globals.hpp line 245: > 243: product(size_t, LargePageSizeInBytes, 0, \ > 244: "Maximum large page size used (0 will use the default large " \ > 245: "page size for the environment as the maximum)") \ Suggestion: "page size for the environment as the maximum) (must be a power of 2)") \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/25994#issuecomment-3007579028 PR Review Comment: https://git.openjdk.org/jdk/pull/25994#discussion_r2168460392 PR Review Comment: https://git.openjdk.org/jdk/pull/25994#discussion_r2168464564 From mbaesken at openjdk.org Thu Jun 26 09:33:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 26 Jun 2025 09:33:07 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions Message-ID: On Linux ppc64le RHEL 8, we have such a docker version : docker --version Docker version v25.0.3, build 4debf41 Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. Probably we should simply skip the leading 'v' . Also the appended build info has to be considered. Example failure TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 ------------- Commit messages: - JDK-8360533 Changes: https://git.openjdk.org/jdk/pull/25996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360533 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25996/head:pull/25996 PR: https://git.openjdk.org/jdk/pull/25996 From mdoerr at openjdk.org Thu Jun 26 10:14:27 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 26 Jun 2025 10:14:27 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 09:27:20 GMT, Matthias Baesken wrote: > On Linux ppc64le RHEL 8, we have such a docker version : > > docker --version > Docker version v25.0.3, build 4debf41 > > > Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. > > Probably we should simply skip the leading 'v' . > Also the appended build info has to be considered. > > Example failure > > TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 Looks correct. Would be nice to mention the comma in the comment as well. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25996#pullrequestreview-2961520315 From rehn at openjdk.org Thu Jun 26 10:32:27 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 26 Jun 2025 10:32:27 GMT Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu In-Reply-To: <_Ck70rgIeGOX64LkerLC7z3gk6HRxPEP1vPOGHmi1bE=.e18fc885-25d4-4c8d-96dd-22d7727a9c9c@github.com> References: <_Ck70rgIeGOX64LkerLC7z3gk6HRxPEP1vPOGHmi1bE=.e18fc885-25d4-4c8d-96dd-22d7727a9c9c@github.com> Message-ID: On Wed, 25 Jun 2025 20:15:43 GMT, Hamlin Li wrote: > > Hey, you can already disable them by adding "--disable-jvm-feature-cds" to your configure line. > > Yes. But that means disable all related tests, under runtime/cds there are more than 269 "require vm.cds", not all these tests fail. > > > As they have "@requires vm.cds" they are skipped. (exception is this test: https://bugs.openjdk.org/browse/JDK-8353034) > > interesting failure. When using a cross compiled jdk, only class list is generated: checking if the CDS classlist generation should be enabled... enabled, from default 'auto' checking if CDS archive is available... no (not possible with cross compilation) Using a cross compiled jdk on hardware/qemu-system same tests fails, the issue is not related to running inside qemu. I think the require tag is to coarse - as I think we have two cases: - The JDK have a full CDS archive - The JDK can generate a CDS archive Not sure what to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3008003828 From coleenp at openjdk.org Thu Jun 26 11:58:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jun 2025 11:58:11 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Thu, 26 Jun 2025 07:30:13 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Made it even shorter. > > test/lib/RedefineClassHelper.java line 29: > >> 27: import java.lang.classfile.ClassFile; >> 28: import java.lang.classfile.ClassModel; >> 29: import java.util.Map; > > Nit: import out of order I like the imports when they're grouped by things they support. Map isn't being used in the final version though. > test/lib/RedefineClassHelper.java line 92: > >> 90: byte[] buf = getBytecodes(loader, oldClassName); >> 91: ClassModel classModel = ClassFile.of().parse(buf); >> 92: return ClassFile.of().build(ClassDesc.of(newClassName), classModel::forEach); > > That's cool! I have no idea how to read it to understand what it does, but it is cool it can be done in one line. :) > > Seriously though, which part of that is doing the actual replace?? Java's gone overly terse, but if you look at the n-1 commit, the classModel::forEach copies everything in the class to the new class. At least that's what Chen told me and it seems to do. Isn't this cool? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168886521 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168884543 From coleenp at openjdk.org Thu Jun 26 11:58:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jun 2025 11:58:11 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v7] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - Update test/lib/RedefineClassHelper.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Fix imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/3285f4d5..21223e37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=05-06 Stats: 7 lines in 1 file changed: 1 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From mli at openjdk.org Thu Jun 26 12:10:29 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 26 Jun 2025 12:10:29 GMT Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu In-Reply-To: References: <_Ck70rgIeGOX64LkerLC7z3gk6HRxPEP1vPOGHmi1bE=.e18fc885-25d4-4c8d-96dd-22d7727a9c9c@github.com> Message-ID: On Thu, 26 Jun 2025 10:30:17 GMT, Robbin Ehn wrote: > Using a cross compiled jdk on hardware/qemu-system same tests fails, the issue is not related to running inside qemu. Normally we build and run in the same env, so we should be fine? And this mainly avoids reporting "false" failure on qemu. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3008261168 From rkennke at openjdk.org Thu Jun 26 12:35:38 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 26 Jun 2025 12:35:38 GMT Subject: [jdk25] Integrated: 8355319: Update Manpage for Compact Object Headers (Production) In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 10:40:17 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [75ce44aa](https://github.com/openjdk/jdk/commit/75ce44aa84ebf0f48dd73b98f2bf2d6077473ed1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Roman Kennke on 25 Jun 2025 and was reviewed by Coleen Phillimore, David Holmes and Paul Hohensee. > > Thanks! This pull request has now been integrated. Changeset: 658f80e3 Author: Roman Kennke URL: https://git.openjdk.org/jdk/commit/658f80e392f1b675ba6adc2b789e0d0a108d1127 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8355319: Update Manpage for Compact Object Headers (Production) Reviewed-by: coleenp Backport-of: 75ce44aa84ebf0f48dd73b98f2bf2d6077473ed1 ------------- PR: https://git.openjdk.org/jdk/pull/25974 From lucy at openjdk.org Thu Jun 26 13:04:28 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 26 Jun 2025 13:04:28 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 09:27:20 GMT, Matthias Baesken wrote: > On Linux ppc64le RHEL 8, we have such a docker version : > > docker --version > Docker version v25.0.3, build 4debf41 > > > Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. > > Probably we should simply skip the leading 'v' . > Also the appended build info has to be considered. > > Example failure > > TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 LGTM. A comment on why there might be a comma to skip would be helpful. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25996#pullrequestreview-2962037585 From sgehwolf at openjdk.org Thu Jun 26 14:28:28 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 26 Jun 2025 14:28:28 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 09:27:20 GMT, Matthias Baesken wrote: > On Linux ppc64le RHEL 8, we have such a docker version : > > docker --version > Docker version v25.0.3, build 4debf41 > > > Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. > > Probably we should simply skip the leading 'v' . > Also the appended build info has to be considered. > > Example failure > > TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 83: > 81: String versNums = version.split("\\s+", 3)[2]; > 82: // On some docker implementations e.g. RHEL8 ppc64le we have a version v25.0.3 > 83: // with a leading v, skip this Suggestion: // On some docker implementations e.g. RHEL8 ppc64le we have the following version output: // Docker version v25.0.3, build 4debf41 // Trim potentially leading 'v' and trailing ',' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25996#discussion_r2169206063 From gziemski at openjdk.org Thu Jun 26 15:51:28 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 26 Jun 2025 15:51:28 GMT Subject: RFR: 8360048: NMT crash in gtest/NMTGtests.java: fatal error: NMT corruption: Block at 0x0000017748307120: header canary broken [v2] In-Reply-To: References: Message-ID: <91wENHHc4IIHPpdRD_miNZRXwcgQAMOSofsPosEFN10=.35afe9f3-0b1c-46fd-9be9-f304cbbca033@github.com> On Tue, 24 Jun 2025 14:52:09 GMT, Afshin Zafari wrote: >> The canary header test failed since there were concurrent `remove` and `free()` from the tree. The `remove` operations are synch'ed with corresponding NMT lock. The `ReserveMemory::reserve()` uses the same lock internally and is not included in the locked code block. >> >> Tests: tier5 {macosx-aarch64, linux-x64, windows-x64} x {debug, release} > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > local VMT vs static one. LGTM ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25950#pullrequestreview-2962618614 From liach at openjdk.org Thu Jun 26 16:36:37 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 26 Jun 2025 16:36:37 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Thu, 26 Jun 2025 11:52:36 GMT, Coleen Phillimore wrote: >> test/lib/RedefineClassHelper.java line 92: >> >>> 90: byte[] buf = getBytecodes(loader, oldClassName); >>> 91: ClassModel classModel = ClassFile.of().parse(buf); >>> 92: return ClassFile.of().build(ClassDesc.of(newClassName), classModel::forEach); >> >> That's cool! I have no idea how to read it to understand what it does, but it is cool it can be done in one line. :) >> >> Seriously though, which part of that is doing the actual replace?? > > Java's gone overly terse, but if you look at the n-1 commit, the classModel::forEach copies everything in the class to the new class. At least that's what Chen told me and it seems to do. Isn't this cool? > Seriously though, which part of that is doing the actual replace?? `ClassDesc.of(newClassName)` defines a new class with the new name, and the lambda just copies everything over as-is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169460161 From asotona at openjdk.org Thu Jun 26 16:50:29 2025 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 26 Jun 2025 16:50:29 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Thu, 26 Jun 2025 16:34:06 GMT, Chen Liang wrote: >> Java's gone overly terse, but if you look at the n-1 commit, the classModel::forEach copies everything in the class to the new class. At least that's what Chen told me and it seems to do. Isn't this cool? > >> Seriously though, which part of that is doing the actual replace?? > > `ClassDesc.of(newClassName)` defines a new class with the new name, and the lambda just copies everything over as-is. It can be also written as: `return ClassFile.of().transform(classModel, ClassDesc.of(newClassName), ClassTransform.ACCEPT_ALL` But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself. Full class remapping was a job of https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/classfile/components/ClassRemapper.html which unfortunately didn't make it from 23 preview to 24 :( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169481261 From coleenp at openjdk.org Thu Jun 26 18:44:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jun 2025 18:44:29 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Thu, 26 Jun 2025 11:53:43 GMT, Coleen Phillimore wrote: >> test/lib/RedefineClassHelper.java line 29: >> >>> 27: import java.lang.classfile.ClassFile; >>> 28: import java.lang.classfile.ClassModel; >>> 29: import java.util.Map; >> >> Nit: import out of order > > I like the imports when they're grouped by things they support. Map isn't being used in the final version though. fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169712542 From coleenp at openjdk.org Thu Jun 26 18:44:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jun 2025 18:44:29 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Thu, 26 Jun 2025 16:47:35 GMT, Adam Sotona wrote: >>> Seriously though, which part of that is doing the actual replace?? >> >> `ClassDesc.of(newClassName)` defines a new class with the new name, and the lambda just copies everything over as-is. > > It can be also written as: > `return ClassFile.of().transform(classModel, ClassDesc.of(newClassName), ClassTransform.ACCEPT_ALL` > > But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself. > > Full class remapping was a job of https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/classfile/components/ClassRemapper.html which unfortunately didn't make it from 23 preview to 24 :( Yes, I wanted to use the ClassRemapper but all the tests that used RedefineClassHelper would have had to add @modules. We can change it later when ClassRemapper becomes available without adding modules. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169711642 From coleenp at openjdk.org Thu Jun 26 20:35:41 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jun 2025 20:35:41 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: On Wed, 25 Jun 2025 02:45:39 GMT, David Holmes wrote: > You could use a ThreadLocal for the current method being printed. Oh yes that would be better, but I hate to add things to Thread for just one use. Actually, reprinting the method name probably helps with readability if multiple threads are interleaving output. Thanks for the review @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/25915#issuecomment-3006207216 From dholmes at openjdk.org Thu Jun 26 21:51:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 26 Jun 2025 21:51:49 GMT Subject: Integrated: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 23:43:05 GMT, David Holmes wrote: > We started observing these occasional crashes involving the JfrSamplerThread (which is a NonJavaThread) during JFR's termination thread dump. Examination of the `print_info_on` code showed that it was making an invalid assumption that it is safe to walk the thread's thread-list at a safepoint, as that is not true when you are dealing with a NonJavaThread, as it is not held at the safepoint and so the list you are walking can disappear whilst you examine it. I added some test code to make this more likely and was able to trigger similar crashes - see JBS for details. > > The simple fix is to only walk JavaThreads. > > Testing > - tier 5 JFR tests > - selected tests with JFR explicitly enabled > - tier 1-3 (sanity) > > Thanks This pull request has now been integrated. Changeset: 334683e6 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/334683e634c23a3672585e4309a528d0944d942e Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump Reviewed-by: fbredberg, shade, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/25963 From ccheung at openjdk.org Thu Jun 26 23:01:57 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 26 Jun 2025 23:01:57 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump Message-ID: This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. Passed tiers 1 - 5 testing. ------------- Commit messages: - 8360743: Enables regeneration of JLI holder classes for CDS static dump Changes: https://git.openjdk.org/jdk/pull/26007/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26007&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360743 Stats: 124 lines in 12 files changed: 104 ins; 3 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26007/head:pull/26007 PR: https://git.openjdk.org/jdk/pull/26007 From iklam at openjdk.org Thu Jun 26 23:48:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 26 Jun 2025 23:48:06 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() Message-ID: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis. This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed. ------------- Commit messages: - Use JVM_Halt instead - 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() Changes: https://git.openjdk.org/jdk/pull/26008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360164 Stats: 10 lines in 2 files changed: 6 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26008/head:pull/26008 PR: https://git.openjdk.org/jdk/pull/26008 From kvn at openjdk.org Thu Jun 26 23:59:40 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 26 Jun 2025 23:59:40 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() In-Reply-To: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: On Thu, 26 Jun 2025 23:41:40 GMT, Ioi Lam wrote: > `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis. > > This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26008#pullrequestreview-2964143551 From dholmes at openjdk.org Fri Jun 27 00:10:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jun 2025 00:10:40 GMT Subject: [jdk25] RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump Message-ID: Hi all, This pull request contains a backport of commit [334683e6](https://github.com/openjdk/jdk/commit/334683e634c23a3672585e4309a528d0944d942e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by David Holmes on 26 Jun 2025 and was reviewed by Fredrik Bredberg, Aleksey Shipilev and Daniel D. Daugherty. Thanks! ------------- Commit messages: - Backport 334683e634c23a3672585e4309a528d0944d942e Changes: https://git.openjdk.org/jdk/pull/26010/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26010&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358645 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26010.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26010/head:pull/26010 PR: https://git.openjdk.org/jdk/pull/26010 From ccheung at openjdk.org Fri Jun 27 00:52:10 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 27 Jun 2025 00:52:10 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: References: Message-ID: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> > This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. > > Passed tiers 1 - 5 testing. Calvin Cheung 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 two additional commits since the last revision: - Merge branch 'master' into 8360743-enables-regen-JLI-holder - 8360743: Enables regeneration of JLI holder classes for CDS static dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26007/files - new: https://git.openjdk.org/jdk/pull/26007/files/00dfdabf..c6771691 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26007&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26007&range=00-01 Stats: 9286 lines in 444 files changed: 4413 ins; 2716 del; 2157 mod Patch: https://git.openjdk.org/jdk/pull/26007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26007/head:pull/26007 PR: https://git.openjdk.org/jdk/pull/26007 From dholmes at openjdk.org Fri Jun 27 04:12:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jun 2025 04:12:38 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: On Wed, 25 Jun 2025 21:32:25 GMT, Coleen Phillimore wrote: > > You could use a ThreadLocal for the current method being printed. > > Oh yes that would be better, but I hate to add things to Thread for just one use. No I literally meant a THREAD_LOCAL ie. static THREAD_LOCAL Method* _method_currently_being_printed = nullptr; ------------- PR Comment: https://git.openjdk.org/jdk/pull/25915#issuecomment-3011566930 From dholmes at openjdk.org Fri Jun 27 04:23:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jun 2025 04:23:39 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Thu, 26 Jun 2025 18:40:59 GMT, Coleen Phillimore wrote: >> It can be also written as: >> `return ClassFile.of().transform(classModel, ClassDesc.of(newClassName), ClassTransform.ACCEPT_ALL` >> >> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself. >> >> Full class remapping was a job of https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/classfile/components/ClassRemapper.html which unfortunately didn't make it from 23 preview to 24 :( > > Yes, I wanted to use the ClassRemapper but all the tests that used RedefineClassHelper would have had to add @modules. We can change it later when ClassRemapper becomes available without adding modules. > the lambda just copies everything over as-is. .. > But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself. @coleenp don't we need to class name to be changed everywhere it appears in the classfile? Or do we know these classes are trivial enough that there is only a single occurrence of the name (and everything else is symbolic via the constant pool) ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2170732353 From dholmes at openjdk.org Fri Jun 27 04:23:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jun 2025 04:23:40 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Fri, 27 Jun 2025 04:19:49 GMT, David Holmes wrote: >> Yes, I wanted to use the ClassRemapper but all the tests that used RedefineClassHelper would have had to add @modules. We can change it later when ClassRemapper becomes available without adding modules. > >> the lambda just copies everything over as-is. > .. >> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself. > > @coleenp don't we need to class name to be changed everywhere it appears in the classfile? Or do we know these classes are trivial enough that there is only a single occurrence of the name (and everything else is symbolic via the constant pool) ? And `replaceAllStrings` is incorrectly named in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2170733258 From dholmes at openjdk.org Fri Jun 27 04:46:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jun 2025 04:46:38 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() In-Reply-To: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: On Thu, 26 Jun 2025 23:41:40 GMT, Ioi Lam wrote: > `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis. > > This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed. Changes requested by dholmes (Reviewer). src/hotspot/share/cds/metaspaceShared.cpp line 846: > 844: } > 845: ThreadToNativeFromVM ttnfv(THREAD); > 846: JVM_Halt(0); `JVM_Halt` is the native backend for the JDK's `System.halt()` method. Whilst it might do what you need under-the-covers, I think it would be clearer to not actually call it, but just call `before_exit` and `vm_exit` directly. Even then you need to be careful as to how the `halt` parameter will be interpreted - in particular the affect on `Jfr::on_vm_shutdown`. In fact `before_exit` needs detailed examination to see if everything it does truly makes sense in this context. src/hotspot/share/runtime/java.cpp line 435: > 433: // Dynamic CDS dumping must happen whilst we can still reliably > 434: // run Java code. > 435: if (CDSConfig::is_dumping_dynamic_archive()) { I assume requesting a dynamic dump is mutually exclusive to the use of `-XX:AOTMode=create`? ------------- PR Review: https://git.openjdk.org/jdk/pull/26008#pullrequestreview-2964713236 PR Review Comment: https://git.openjdk.org/jdk/pull/26008#discussion_r2170765111 PR Review Comment: https://git.openjdk.org/jdk/pull/26008#discussion_r2170766001 From ccheung at openjdk.org Fri Jun 27 04:49:49 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 27 Jun 2025 04:49:49 GMT Subject: RFR: 8310831: Some methods are missing from CDS regenerated JLI holder class Message-ID: Per the [suggested fix](https://bugs.openjdk.org/browse/JDK-8310831?focusedId=14788065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14788065), this patch doesn't issue a warning if the missing method is the constructor of a holder class. Sanity tier1 tested. Manually tested by building the `images` with the `-Xlog:cds=off` removed from the `GenerateLinkOptData.gmk` and with build logging enabled (`LOG=info`). ------------- Commit messages: - revert unneeded include - 8310831: Some methods are missing from CDS regenerated JLI holder class Changes: https://git.openjdk.org/jdk/pull/26011/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26011&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310831 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26011/head:pull/26011 PR: https://git.openjdk.org/jdk/pull/26011 From dholmes at openjdk.org Fri Jun 27 05:05:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jun 2025 05:05:39 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 09:27:20 GMT, Matthias Baesken wrote: > On Linux ppc64le RHEL 8, we have such a docker version : > > docker --version > Docker version v25.0.3, build 4debf41 > > > Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. > > Probably we should simply skip the leading 'v' . > Also the appended build info has to be considered. > > Example failure > > TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 I guess if this is only for testing purposes then this is okay. It is painful to have to accommodate such arbitrary differences. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25996#pullrequestreview-2964748612 From mbaesken at openjdk.org Fri Jun 27 05:36:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 05:36:55 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions [v2] In-Reply-To: References: Message-ID: <0kaOvhfP72bMjs09ExO2pAnMqJi2E2ezEzeR4nzNp-g=.3099d0c5-7e5e-4466-9c13-46820d4dba24@github.com> > On Linux ppc64le RHEL 8, we have such a docker version : > > docker --version > Docker version v25.0.3, build 4debf41 > > > Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. > > Probably we should simply skip the leading 'v' . > Also the appended build info has to be considered. > > Example failure > > TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Update test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java Co-authored-by: Severin Gehwolf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25996/files - new: https://git.openjdk.org/jdk/pull/25996/files/a1d49a48..b1ee1387 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25996&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25996/head:pull/25996 PR: https://git.openjdk.org/jdk/pull/25996 From mbaesken at openjdk.org Fri Jun 27 05:36:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 05:36:55 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions In-Reply-To: References: Message-ID: <0Kugmllul6SNS7jno7QR1shD9ElqS9OK33uDPM1hmxA=.16a7b337-d059-4029-8cb8-64387140d37b@github.com> On Thu, 26 Jun 2025 09:27:20 GMT, Matthias Baesken wrote: > On Linux ppc64le RHEL 8, we have such a docker version : > > docker --version > Docker version v25.0.3, build 4debf41 > > > Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. > > Probably we should simply skip the leading 'v' . > Also the appended build info has to be considered. > > Example failure > > TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 Hi Severin, I changed the comment / took your suggestion ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25996#issuecomment-3011731815 From iklam at openjdk.org Fri Jun 27 05:59:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jun 2025 05:59:38 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() In-Reply-To: References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: On Fri, 27 Jun 2025 04:41:50 GMT, David Holmes wrote: >> `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis. >> >> This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed. > > src/hotspot/share/runtime/java.cpp line 435: > >> 433: // Dynamic CDS dumping must happen whilst we can still reliably >> 434: // run Java code. >> 435: if (CDSConfig::is_dumping_dynamic_archive()) { > > I assume requesting a dynamic dump is mutually exclusive to the use of `-XX:AOTMode=create`? Yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26008#discussion_r2170861163 From shade at openjdk.org Fri Jun 27 06:39:41 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 27 Jun 2025 06:39:41 GMT Subject: [jdk25] RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 00:03:58 GMT, David Holmes wrote: > Hi all, > > This pull request contains a backport of commit [334683e6](https://github.com/openjdk/jdk/commit/334683e634c23a3672585e4309a528d0944d942e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by David Holmes on 26 Jun 2025 and was reviewed by Fredrik Bredberg, Aleksey Shipilev and Daniel D. Daugherty. > > Thanks! Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26010#pullrequestreview-2964955022 From dholmes at openjdk.org Fri Jun 27 06:46:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jun 2025 06:46:37 GMT Subject: [jdk25] RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 06:37:05 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> This pull request contains a backport of commit [334683e6](https://github.com/openjdk/jdk/commit/334683e634c23a3672585e4309a528d0944d942e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by David Holmes on 26 Jun 2025 and was reviewed by Fredrik Bredberg, Aleksey Shipilev and Daniel D. Daugherty. >> >> Thanks! > > Marked as reviewed by shade (Reviewer). Thanks for the review @shipilev ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26010#issuecomment-3011887243 From lucy at openjdk.org Fri Jun 27 07:29:38 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 27 Jun 2025 07:29:38 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions [v2] In-Reply-To: <0kaOvhfP72bMjs09ExO2pAnMqJi2E2ezEzeR4nzNp-g=.3099d0c5-7e5e-4466-9c13-46820d4dba24@github.com> References: <0kaOvhfP72bMjs09ExO2pAnMqJi2E2ezEzeR4nzNp-g=.3099d0c5-7e5e-4466-9c13-46820d4dba24@github.com> Message-ID: On Fri, 27 Jun 2025 05:36:55 GMT, Matthias Baesken wrote: >> On Linux ppc64le RHEL 8, we have such a docker version : >> >> docker --version >> Docker version v25.0.3, build 4debf41 >> >> >> Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. >> >> Probably we should simply skip the leading 'v' . >> Also the appended build info has to be considered. >> >> Example failure >> >> TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java >> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Update test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java > > Co-authored-by: Severin Gehwolf LGTM. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25996#pullrequestreview-2965105138 From mbaesken at openjdk.org Fri Jun 27 07:40:43 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 07:40:43 GMT Subject: RFR: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions [v2] In-Reply-To: <0kaOvhfP72bMjs09ExO2pAnMqJi2E2ezEzeR4nzNp-g=.3099d0c5-7e5e-4466-9c13-46820d4dba24@github.com> References: <0kaOvhfP72bMjs09ExO2pAnMqJi2E2ezEzeR4nzNp-g=.3099d0c5-7e5e-4466-9c13-46820d4dba24@github.com> Message-ID: On Fri, 27 Jun 2025 05:36:55 GMT, Matthias Baesken wrote: >> On Linux ppc64le RHEL 8, we have such a docker version : >> >> docker --version >> Docker version v25.0.3, build 4debf41 >> >> >> Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. >> >> Probably we should simply skip the leading 'v' . >> Also the appended build info has to be considered. >> >> Example failure >> >> TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java >> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Update test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java > > Co-authored-by: Severin Gehwolf Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25996#issuecomment-3012025794 From mbaesken at openjdk.org Fri Jun 27 07:40:43 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Jun 2025 07:40:43 GMT Subject: Integrated: 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 09:27:20 GMT, Matthias Baesken wrote: > On Linux ppc64le RHEL 8, we have such a docker version : > > docker --version > Docker version v25.0.3, build 4debf41 > > > Unfortunately, the leading 'v' is not expected in ContainerRuntimeVersionTestUtils fromVersionString so we get an exception. > > Probably we should simply skip the leading 'v' . > Also the appended build info has to be considered. > > Example failure > > TEST: jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed to parse container runtime version: Docker version v25.0.3, build 4debf41 This pull request has now been integrated. Changeset: 97ec9d3e Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/97ec9d3e0a6e3455579b567e1f58026f5b168c09 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod 8360533: ContainerRuntimeVersionTestUtils fromVersionString fails with some docker versions Reviewed-by: lucy, mdoerr, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25996 From coleenp at openjdk.org Fri Jun 27 11:24:48 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 11:24:48 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: On Tue, 24 Jun 2025 12:30:11 GMT, Coleen Phillimore wrote: >> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: >> >> [490166] static void java.lang.String.() >> [490166] 13 18 putstatic 613 >> [490166] 14 21 return >> >> [490166] static void java.lang.System.() >> [490166] 15 0 invokestatic 471 >> [490166] 16 3 aconst_null >> [490166] 17 4 putstatic 474 >> >> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. >> Also ran tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some renaming and more comments and a load_acquire. Oh yes, we don't use THREAD_LOCAL that much. I still think we want to repeat the method name if the threads become interweaved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25915#issuecomment-3012662180 From coleenp at openjdk.org Fri Jun 27 11:37:30 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 11:37:30 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v8] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com> > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/21223e37..17b3b77b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=06-07 Stats: 18 lines in 2 files changed: 13 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From coleenp at openjdk.org Fri Jun 27 11:37:30 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 11:37:30 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v7] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <4nEIX_JybFufkCDd80OxD99ToKBEZP15k7qtXlRCPr4=.94c33ec8-faf7-485b-a923-ccb8ae4e0d37@github.com> On Thu, 26 Jun 2025 11:58:11 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/lib/RedefineClassHelper.java > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Fix imports Also added back the byte[] version of the method that I inadvertently deleted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25857#issuecomment-3012689944 From coleenp at openjdk.org Fri Jun 27 11:37:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 11:37:31 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Thu, 26 Jun 2025 05:03:14 GMT, Leonid Mesnik wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Made it even shorter. > > test/lib/RedefineClassHelper.java line 35: > >> 33: import jdk.test.lib.helpers.ClassFileInstaller; >> 34: >> 35: import static jdk.test.lib.Asserts.assertTrue; > > Is it really needed? I can't see that assertion were added. fixed imports. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2171715106 From coleenp at openjdk.org Fri Jun 27 11:37:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 11:37:31 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v6] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Fri, 27 Jun 2025 04:21:01 GMT, David Holmes wrote: >>> the lambda just copies everything over as-is. >> .. >>> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself. >> >> @coleenp don't we need to class name to be changed everywhere it appears in the classfile? Or do we know these classes are trivial enough that there is only a single occurrence of the name (and everything else is symbolic via the constant pool) ? > > And `replaceAllStrings` is incorrectly named in that case. I think if we add less trivial classes to be redefined, we might need to upgrade this to the ClassRemapper. For now this only renames the classfile. I've renamed the method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2171711787 From mdoerr at openjdk.org Fri Jun 27 13:02:47 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 27 Jun 2025 13:02:47 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com> References: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com> Message-ID: On Tue, 24 Jun 2025 16:13:26 GMT, Dean Long wrote: >> Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc. > > Thanks @RealFYang. @dean-long: Are you planning to do a jdk25 backport? We still see the crashes, there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3013002469 From liach at openjdk.org Fri Jun 27 13:29:41 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 27 Jun 2025 13:29:41 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> Message-ID: <8oJswCVl2W59guKZL6jaZNhZPq4eJ94VCPDzOhV31G0=.c4644130-2db9-4bf9-a2fb-7b16fdb62e9d@github.com> On Fri, 27 Jun 2025 00:52:10 GMT, Calvin Cheung wrote: >> This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. >> >> Passed tiers 1 - 5 testing. > > Calvin Cheung 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 two additional commits since the last revision: > > - Merge branch 'master' into 8360743-enables-regen-JLI-holder > - 8360743: Enables regeneration of JLI holder classes for CDS static dump Does this not require any change from the jlink/GenerateJLIClassesHelper side? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26007#issuecomment-3013091250 From matsaave at openjdk.org Fri Jun 27 15:15:45 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 27 Jun 2025 15:15:45 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: On Tue, 24 Jun 2025 12:30:11 GMT, Coleen Phillimore wrote: >> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: >> >> [490166] static void java.lang.String.() >> [490166] 13 18 putstatic 613 >> [490166] 14 21 return >> >> [490166] static void java.lang.System.() >> [490166] 15 0 invokestatic 471 >> [490166] 16 3 aconst_null >> [490166] 17 4 putstatic 474 >> >> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. >> Also ran tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some renaming and more comments and a load_acquire. Should the test also include the simple serial version? ------------- PR Review: https://git.openjdk.org/jdk/pull/25915#pullrequestreview-2966962071 From coleenp at openjdk.org Fri Jun 27 15:33:28 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 15:33:28 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: On Fri, 27 Jun 2025 15:13:27 GMT, Matias Saavedra Silva wrote: > Should the test also include the simple serial version? Since we don't really verify the output, I don't think one would be needed. The test was originally added when there was a safepointing lock around BytecodeTracer in JDK 7 and the Method* moved, so all the test did was verify that tracing bytecodes didn't crash. With the concurrency I added, it did crash and found a bug that I fixed in BytecodeTracer::trace function. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25915#issuecomment-3013466481 From dcubed at openjdk.org Fri Jun 27 15:41:31 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 27 Jun 2025 15:41:31 GMT Subject: [jdk25] RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: <0LmHOk3QgxKclP9xy5OOj_Bqp5lrHhQeRHcSPXboaQM=.21318dfb-1aab-40fe-829a-4e7d460df200@github.com> On Fri, 27 Jun 2025 00:03:58 GMT, David Holmes wrote: > Hi all, > > This pull request contains a backport of commit [334683e6](https://github.com/openjdk/jdk/commit/334683e634c23a3672585e4309a528d0944d942e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by David Holmes on 26 Jun 2025 and was reviewed by Fredrik Bredberg, Aleksey Shipilev and Daniel D. Daugherty. > > Thanks! Thumbs up. This patch is identical to the main-line version. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26010#pullrequestreview-2967031469 From matsaave at openjdk.org Fri Jun 27 16:00:43 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 27 Jun 2025 16:00:43 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: <9CuSUGiOvf06VY5QCUcHEOFzfv5ohwZQGGpKtwzn-Ao=.97f1a207-60c2-476c-badd-a8f745d28397@github.com> On Tue, 24 Jun 2025 12:30:11 GMT, Coleen Phillimore wrote: >> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: >> >> [490166] static void java.lang.String.() >> [490166] 13 18 putstatic 613 >> [490166] 14 21 return >> >> [490166] static void java.lang.System.() >> [490166] 15 0 invokestatic 471 >> [490166] 16 3 aconst_null >> [490166] 17 4 putstatic 474 >> >> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. >> Also ran tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some renaming and more comments and a load_acquire. Thanks for the clarification, LGTM! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25915#pullrequestreview-2967048146 From ccheung at openjdk.org Fri Jun 27 16:03:05 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 27 Jun 2025 16:03:05 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: <8oJswCVl2W59guKZL6jaZNhZPq4eJ94VCPDzOhV31G0=.c4644130-2db9-4bf9-a2fb-7b16fdb62e9d@github.com> References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> <8oJswCVl2W59guKZL6jaZNhZPq4eJ94VCPDzOhV31G0=.c4644130-2db9-4bf9-a2fb-7b16fdb62e9d@github.com> Message-ID: On Fri, 27 Jun 2025 13:27:24 GMT, Chen Liang wrote: > Does this not require any change from the jlink/GenerateJLIClassesHelper side? Do you mean `./java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java`? The CDS class calls the `generateHolderClasses()` method. Do you think the method needs to be changed? If so, what would be your suggestions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26007#issuecomment-3013545259 From iklam at openjdk.org Fri Jun 27 16:07:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jun 2025 16:07:06 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() [v2] In-Reply-To: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: > `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis. > > This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Reverted to calling before_exit() directly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26008/files - new: https://git.openjdk.org/jdk/pull/26008/files/deed0c9d..e0e5e308 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26008&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26008&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26008/head:pull/26008 PR: https://git.openjdk.org/jdk/pull/26008 From coleenp at openjdk.org Fri Jun 27 16:14:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 16:14:46 GMT Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v4] In-Reply-To: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> References: <_u_zjgvAK-OqWSwf2MPUBcFbDiWZgMR7WuVB86FhOqA=.21f2ed10-977f-48d1-8b61-26a08c281d3b@github.com> Message-ID: On Tue, 24 Jun 2025 12:30:11 GMT, Coleen Phillimore wrote: >> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: >> >> [490166] static void java.lang.String.() >> [490166] 13 18 putstatic 613 >> [490166] 14 21 return >> >> [490166] static void java.lang.System.() >> [490166] 15 0 invokestatic 471 >> [490166] 16 3 aconst_null >> [490166] 17 4 putstatic 474 >> >> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. >> Also ran tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some renaming and more comments and a load_acquire. Thanks Matias and David for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25915#issuecomment-3013578203 From coleenp at openjdk.org Fri Jun 27 16:14:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jun 2025 16:14:47 GMT Subject: Integrated: 8295851: Do not use ttyLock in BytecodeTracer::trace In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 11:50:49 GMT, Coleen Phillimore wrote: > This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like: > > [490166] static void java.lang.String.() > [490166] 13 18 putstatic 613 > [490166] 14 21 return > > [490166] static void java.lang.System.() > [490166] 15 0 invokestatic 471 > [490166] 16 3 aconst_null > [490166] 17 4 putstatic 474 > > Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is. > Also ran tier1-4. This pull request has now been integrated. Changeset: 4edf791a Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/4edf791aecd432ecde00652acfaabddf136f4ca7 Stats: 67 lines in 2 files changed: 37 ins; 12 del; 18 mod 8295851: Do not use ttyLock in BytecodeTracer::trace Reviewed-by: dholmes, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/25915 From iklam at openjdk.org Fri Jun 27 16:19:18 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jun 2025 16:19:18 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() [v3] In-Reply-To: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: > `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis. > > This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Use vm_direct_exit instead, as at this point we have not finished Threads::create_vm() yet, so we may not have done all the initialization to be able to call before_exit() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26008/files - new: https://git.openjdk.org/jdk/pull/26008/files/e0e5e308..f8222e38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26008&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26008&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26008/head:pull/26008 PR: https://git.openjdk.org/jdk/pull/26008 From iklam at openjdk.org Fri Jun 27 16:55:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jun 2025 16:55:33 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() [v3] In-Reply-To: References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: On Fri, 27 Jun 2025 04:40:51 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Use vm_direct_exit instead, as at this point we have not finished Threads::create_vm() yet, so we may not have done all the initialization to be able to call before_exit() > > src/hotspot/share/cds/metaspaceShared.cpp line 846: > >> 844: } >> 845: ThreadToNativeFromVM ttnfv(THREAD); >> 846: JVM_Halt(0); > > `JVM_Halt` is the native backend for the JDK's `System.halt()` method. Whilst it might do what you need under-the-covers, I think it would be clearer to not actually call it, but just call `before_exit` and `vm_exit` directly. Even then you need to be careful as to how the `halt` parameter will be interpreted - in particular the affect on `Jfr::on_vm_shutdown`. In fact `before_exit` needs detailed examination to see if everything it does truly makes sense in this context. I changed the code to call `vm_direct_exit()` instead. At this point, we are still in the middle of `JNI_CreateJavaVM_inner` 0 vm_direct_exit 1 MetaspaceShared::preload_and_dump 2 Threads::create_vm 3 JNI_CreateJavaVM_inner 4 JNI_CreateJavaVM 5 start_thread 6 clone3 so we may not have finished all the initialization that `before_exit()` may rely on. Here's the code that's not yet executed: https://github.com/openjdk/jdk/blob/da7080fffb2389465dc9afca6d02e9085fe15302/src/hotspot/share/prims/jni.cpp#L3591-L3635 To be honest, I am not sure where is the starting point where it's safe to call `before_exit()` or `System.exit()`. At this point a lot of Java code has been executed (for setting up the module graph, etc), but I am not sure what happens when some of that Java code calls `System.exit()`, or whether such a scenario has been (sufficiently) tested. BTW, JFR is disabled when we are dumping CDS: https://github.com/openjdk/jdk/blob/da7080fffb2389465dc9afca6d02e9085fe15302/src/hotspot/share/jfr/recorder/jfrRecorder.cpp#L198-L206 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26008#discussion_r2172422372 From lmesnik at openjdk.org Fri Jun 27 16:55:37 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 27 Jun 2025 16:55:37 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v8] In-Reply-To: <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com> Message-ID: On Fri, 27 Jun 2025 11:37:30 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2967240011 From iklam at openjdk.org Fri Jun 27 18:02:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jun 2025 18:02:50 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> Message-ID: <0apZSbgw6cj3-WGcM5XgWDAX_kjuuFn5V3FJDWvbkpE=.c13cf954-1b98-4d3c-bcdd-08690a7b9dfa@github.com> On Fri, 27 Jun 2025 00:52:10 GMT, Calvin Cheung wrote: >> This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. >> >> Passed tiers 1 - 5 testing. > > Calvin Cheung 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 two additional commits since the last revision: > > - Merge branch 'master' into 8360743-enables-regen-JLI-holder > - 8360743: Enables regeneration of JLI holder classes for CDS static dump LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26007#pullrequestreview-2967444461 From iklam at openjdk.org Fri Jun 27 18:06:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jun 2025 18:06:38 GMT Subject: RFR: 8310831: Some methods are missing from CDS regenerated JLI holder class In-Reply-To: References: Message-ID: <81muYuspmcwbC7EbdhKgyKGCZUSVUwuR-6rSZd8ysVA=.af2560a2-2234-457d-b72c-88b124d6bbab@github.com> On Fri, 27 Jun 2025 04:22:01 GMT, Calvin Cheung wrote: > Per the [suggested fix](https://bugs.openjdk.org/browse/JDK-8310831?focusedId=14788065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14788065), this patch doesn't issue a warning if the missing method is the constructor of a holder class. > > Sanity tier1 tested. > > Manually tested by building the `images` with the `-Xlog:cds=off` removed from the `GenerateLinkOptData.gmk` and with build logging enabled (`LOG=info`). Changes requested by iklam (Reviewer). src/hotspot/share/cds/regeneratedClasses.cpp line 60: > 58: if (regen_m == nullptr) { > 59: ResourceMark rm; > 60: if (strstr(orig_m->external_name(), "$Holder.") == nullptr) { I think it's better to use `orig_m->name() != vmSymbols::object_initializer_name()`. Also, we should have a comment that explain why it's OK for `` to be skipped. ------------- PR Review: https://git.openjdk.org/jdk/pull/26011#pullrequestreview-2967455441 PR Review Comment: https://git.openjdk.org/jdk/pull/26011#discussion_r2172578550 From liach at openjdk.org Fri Jun 27 19:02:40 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 27 Jun 2025 19:02:40 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> Message-ID: On Fri, 27 Jun 2025 00:52:10 GMT, Calvin Cheung wrote: >> This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. >> >> Passed tiers 1 - 5 testing. > > Calvin Cheung 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 two additional commits since the last revision: > > - Merge branch 'master' into 8360743-enables-regen-JLI-holder > - 8360743: Enables regeneration of JLI holder classes for CDS static dump Thanks for pointing that to me. I see it is done in `LambdaFormInvokers::regenerate_holder_classes` now. Everything looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26007#issuecomment-3014093250 From ccheung at openjdk.org Fri Jun 27 21:01:54 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 27 Jun 2025 21:01:54 GMT Subject: RFR: 8310831: Some methods are missing from CDS regenerated JLI holder class [v2] In-Reply-To: References: Message-ID: > Per the [suggested fix](https://bugs.openjdk.org/browse/JDK-8310831?focusedId=14788065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14788065), this patch doesn't issue a warning if the missing method is the constructor of a holder class. > > Sanity tier1 tested. > > Manually tested by building the `images` with the `-Xlog:cds=off` removed from the `GenerateLinkOptData.gmk` and with build logging enabled (`LOG=info`). Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @iklam comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26011/files - new: https://git.openjdk.org/jdk/pull/26011/files/47f43d7e..487d1122 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26011&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26011&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26011/head:pull/26011 PR: https://git.openjdk.org/jdk/pull/26011 From ccheung at openjdk.org Fri Jun 27 21:01:54 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 27 Jun 2025 21:01:54 GMT Subject: RFR: 8310831: Some methods are missing from CDS regenerated JLI holder class [v2] In-Reply-To: <81muYuspmcwbC7EbdhKgyKGCZUSVUwuR-6rSZd8ysVA=.af2560a2-2234-457d-b72c-88b124d6bbab@github.com> References: <81muYuspmcwbC7EbdhKgyKGCZUSVUwuR-6rSZd8ysVA=.af2560a2-2234-457d-b72c-88b124d6bbab@github.com> Message-ID: <3Pir6wv0K2PaNuvPoDVVzcubj1kYENpAF8ENdkJGgs4=.a8b16ab1-ff28-47ae-9d4c-7ee60c3fe64d@github.com> On Fri, 27 Jun 2025 18:03:48 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @iklam comments > > src/hotspot/share/cds/regeneratedClasses.cpp line 60: > >> 58: if (regen_m == nullptr) { >> 59: ResourceMark rm; >> 60: if (strstr(orig_m->external_name(), "$Holder.") == nullptr) { > > I think it's better to use `orig_m->name() != vmSymbols::object_initializer_name()`. > > Also, we should have a comment that explain why it's OK for `` to be skipped. Fix updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26011#discussion_r2172866982 From dlong at openjdk.org Fri Jun 27 21:22:57 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 27 Jun 2025 21:22:57 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com> References: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com> Message-ID: On Tue, 24 Jun 2025 16:13:26 GMT, Dean Long wrote: >> Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc. > > Thanks @RealFYang. > @dean-long: Are you planning to do a jdk25 backport? We still see the crashes, there. I was going to let it bake in jdk26 for a while before deciding. It seems a bit risky to me. I am leaning towards not backporting it to Oracle JDK. For OpenJDK 25, it might make more sense to do a PPC-specific fix like adding a NOP at the verified entry point. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3014307981 From mdoerr at openjdk.org Fri Jun 27 21:22:57 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 27 Jun 2025 21:22:57 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com> Message-ID: <8NphJ347zBj0q5YG-K0Mq_vh9LPfhM_Jo-mcH94re3o=.0830a87e-7d9c-4907-86b2-c13a29893c7d@github.com> On Fri, 27 Jun 2025 20:43:30 GMT, Dean Long wrote: > > @dean-long: Are you planning to do a jdk25 backport? We still see the crashes, there. > > I was going to let it bake in jdk26 for a while before deciding. It seems a bit risky to me. I am leaning towards not backporting it to Oracle JDK. For OpenJDK 25, it might make more sense to do a PPC-specific fix like adding a NOP at the verified entry point. What do you think? I'm not convinced that only PPC64 is affected. [JDK-8258229](https://bugs.openjdk.org/browse/JDK-8258229) looks wrong for all platforms except x86 and may be even problematic on that platform as you had mentioned (due to NMethodState_lock). Would it make sense to backout JDK-8258229 in jdk25 and live with it? That issue doesn't look so critical. Or maybe guard the code with #ifdef x86? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3014360978 From iklam at openjdk.org Sat Jun 28 02:06:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 28 Jun 2025 02:06:51 GMT Subject: RFR: 8310831: Some methods are missing from CDS regenerated JLI holder class [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 21:01:54 GMT, Calvin Cheung wrote: >> Per the [suggested fix](https://bugs.openjdk.org/browse/JDK-8310831?focusedId=14788065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14788065), this patch doesn't issue a warning if the missing method is the constructor of a holder class. >> >> Sanity tier1 tested. >> >> Manually tested by building the `images` with the `-Xlog:cds=off` removed from the `GenerateLinkOptData.gmk` and with build logging enabled (`LOG=info`). > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comments LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26011#pullrequestreview-2968316385 From dholmes at openjdk.org Mon Jun 30 01:09:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 30 Jun 2025 01:09:54 GMT Subject: [jdk25] RFR: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: <0LmHOk3QgxKclP9xy5OOj_Bqp5lrHhQeRHcSPXboaQM=.21318dfb-1aab-40fe-829a-4e7d460df200@github.com> References: <0LmHOk3QgxKclP9xy5OOj_Bqp5lrHhQeRHcSPXboaQM=.21318dfb-1aab-40fe-829a-4e7d460df200@github.com> Message-ID: On Fri, 27 Jun 2025 15:39:03 GMT, Daniel D. Daugherty wrote: >> Hi all, >> >> This pull request contains a backport of commit [334683e6](https://github.com/openjdk/jdk/commit/334683e634c23a3672585e4309a528d0944d942e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by David Holmes on 26 Jun 2025 and was reviewed by Fredrik Bredberg, Aleksey Shipilev and Daniel D. Daugherty. >> >> Thanks! > > Thumbs up. This patch is identical to the main-line version. Thanks for the review @dcubed-ojdk ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26010#issuecomment-3017402505 From dholmes at openjdk.org Mon Jun 30 01:09:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 30 Jun 2025 01:09:54 GMT Subject: [jdk25] Integrated: 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 00:03:58 GMT, David Holmes wrote: > Hi all, > > This pull request contains a backport of commit [334683e6](https://github.com/openjdk/jdk/commit/334683e634c23a3672585e4309a528d0944d942e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by David Holmes on 26 Jun 2025 and was reviewed by Fredrik Bredberg, Aleksey Shipilev and Daniel D. Daugherty. > > Thanks! This pull request has now been integrated. Changeset: 0dc9e844 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/0dc9e8447b42c032c6892053e31021054adcc5e5 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8358645: Access violation in ThreadsSMRSupport::print_info_on during thread dump Reviewed-by: shade, dcubed Backport-of: 334683e634c23a3672585e4309a528d0944d942e ------------- PR: https://git.openjdk.org/jdk/pull/26010 From dholmes at openjdk.org Mon Jun 30 06:00:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 30 Jun 2025 06:00:55 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v8] In-Reply-To: <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com> Message-ID: On Fri, 27 Jun 2025 11:37:30 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function. Changes requested by dholmes (Reviewer). test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java line 56: > 54: // redefining the original version of "TestClassXXX" (i.e. "TestClassOld"). > 55: buf = RedefineClassHelper.replaceClassName(cvar, "TestClassNew", "TestClassXXX"); > 56: // Now redine the original version of "TestClassXXX" (i.e. "TestClassOld"). Suggestion: // Now redefine the original version of "TestClassXXX" (i.e. "TestClassOld"). Pre-existing test/lib/RedefineClassHelper.java line 85: > 83: * @param bytes in original class file. > 84: * @param oldClassName old class name. > 85: * @param newClassName new class name to replace with old class name. Suggestion: * @param newClassName new class name to replace the old class name. test/lib/RedefineClassHelper.java line 87: > 85: * @param newClassName new class name to replace with old class name. > 86: */ > 87: public static byte[] replaceClassName(byte[] bytes, String oldClassName, String newClassName) throws Exception { Just realized that `oldClassName` is not actually used. Suggestion: /* * Copy the class defined by `bytes`, replacing the name of the class with `newClassName`, so that both * old and new classes can be compiled by jtreg for the test. * * @param bytes the bytes presenting the original classfile * @param newClassName the new class name for the returned class representation * @ return a copy of the class represented by `bytes` but with the name `newClassName` */ public static byte[] replaceClassName(byte[] bytes, String newClassName) throws Exception { ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2969920311 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174234229 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174235361 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174242441 From dholmes at openjdk.org Mon Jun 30 06:33:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 30 Jun 2025 06:33:38 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() [v3] In-Reply-To: References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: On Fri, 27 Jun 2025 16:37:29 GMT, Ioi Lam wrote: > I am not sure what happens when some of that Java code calls System.exit(), or whether such a scenario has been (sufficiently) tested. Initialization Java code should not be calling System.exit - ever. If something goes wrong it should throw an exception which is seen by the main thread doing the VM init and that in turn will lead to `vm_exit_during_initialization`. To me the simplest model to use here would be to act as-if AOT creation was done by a small Java class such that you know the VM is fully initialized when you create the cache and then you can do a normal Java-level termination afterwards. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26008#discussion_r2174322202 From dholmes at openjdk.org Mon Jun 30 06:42:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 30 Jun 2025 06:42:38 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() [v3] In-Reply-To: References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: On Fri, 27 Jun 2025 16:19:18 GMT, Ioi Lam wrote: >> `java -XX:AOTMode=create` calls `vm_exit(0)` to terminate the JVM (see [this e-mail thread](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-August/072122.html) for the reason for doing so). However, at this point, the JVM has executed quite a lot of Java code and there are many threads in the JVM that would require a proper shutdown. See [comments by @kimbarrett](https://bugs.openjdk.org/browse/JDK-8360164?focusedId=14792754&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14792754) for a detailed analysis. >> >> This fix calls `JVM_Halt(0)` instead of `vm_exit(0)` so that the proper shutdown code is executed. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Use vm_direct_exit instead, as at this point we have not finished Threads::create_vm() yet, so we may not have done all the initialization to be able to call before_exit() Okay so the proposal now is that instead of trying to do a more "refined" termination process by calling `before_exit` etc (which is problematic because we are only partly initialized), we instead do a more abrupt termination by using `vm_direct_exit`. This seems "safe" with regards to the issues Kim was commenting on. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26008#pullrequestreview-2970072112 From iklam at openjdk.org Mon Jun 30 06:58:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 30 Jun 2025 06:58:40 GMT Subject: RFR: 8360164: AOT cache creation crashes in ~ThreadTotalCPUTimeClosure() [v3] In-Reply-To: References: <0ngnvAd9W2v2J4DakBiym9GCrnnpNZbJjflZuHIIbBo=.77887a82-44a8-44a9-9c71-c42f98b330a5@github.com> Message-ID: On Mon, 30 Jun 2025 06:31:08 GMT, David Holmes wrote: >> I changed the code to call `vm_direct_exit()` instead. At this point, we are still in the middle of `JNI_CreateJavaVM_inner` >> >> >> 0 vm_direct_exit >> 1 MetaspaceShared::preload_and_dump >> 2 Threads::create_vm >> 3 JNI_CreateJavaVM_inner >> 4 JNI_CreateJavaVM >> 5 start_thread >> 6 clone3 >> >> >> so we may not have finished all the initialization that `before_exit()` may rely on. >> >> Here's the code that's not yet executed: >> >> https://github.com/openjdk/jdk/blob/da7080fffb2389465dc9afca6d02e9085fe15302/src/hotspot/share/prims/jni.cpp#L3591-L3635 >> >> >> To be honest, I am not sure where is the starting point where it's safe to call `before_exit()` or `System.exit()`. At this point a lot of Java code has been executed (for setting up the module graph, etc), but I am not sure what happens when some of that Java code calls `System.exit()`, or whether such a scenario has been (sufficiently) tested. >> >> BTW, JFR is disabled when we are dumping CDS: >> >> https://github.com/openjdk/jdk/blob/da7080fffb2389465dc9afca6d02e9085fe15302/src/hotspot/share/jfr/recorder/jfrRecorder.cpp#L198-L206 > >> I am not sure what happens when some of that Java code calls System.exit(), or whether such a scenario has been (sufficiently) tested. > > Initialization Java code should not be calling System.exit - ever. If something goes wrong it should throw an exception which is seen by the main thread doing the VM init and that in turn will lead to `vm_exit_during_initialization`. > > To me the simplest model to use here would be to act as-if AOT creation was done by a small Java class such that you know the VM is fully initialized when you create the cache and then you can do a normal Java-level termination afterwards. I tried doing that, but it's not straight-forward. At this point, some internal VM states have been zero-ed out by the AOT cache dumping code. As a result, it's no longer possible to resolve a new class. We get a crash when System.exit() resolves the Logger class: [....] V [libjvm.so+0xf27aa2] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x116 (interpreterRuntime.cpp:1001) j java.lang.System.getLogger(Ljava/lang/String;)Ljava/lang/System$Logger;+28 java.base at 26-internal j java.lang.Shutdown.logRuntimeExit(I)V+2 java.base at 26-internal j java.lang.Shutdown.exit(I)V+1 java.base at 26-internal j java.lang.Runtime.exit(I)V+1 java.base at 26-internal j java.lang.System.exit(I)V+4 java.base at 26-internal v ~StubRoutines::call_stub 0x00007f392ae6072e Since we need to backport this fix to JDK 25, I think we should go with the `vm_direct_exit()` now, and perhaps fix the AOT dumping code to avoid zeroing out VM states in a follow-up RFE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26008#discussion_r2174357577 From amitkumar at openjdk.org Mon Jun 30 07:00:40 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 30 Jun 2025 07:00:40 GMT Subject: RFR: 8358748: Large page size initialization fails with assert "page_size must be a power of 2" In-Reply-To: References: Message-ID: <2Z18RjlX3JWlVJG0Y2-GpStZjTdrNUqXDAbQsE7vpPs=.9b91989c-ceac-4630-b458-4170579041b8@github.com> On Thu, 26 Jun 2025 07:48:43 GMT, Yagmur Eren wrote: > The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`. > > Before the change: > > java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946 > # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6 > > > > After the change: > > java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version > > LargePageSizeInBytes ( 6 ) must be a power of 2 > Improperly specified VM option 'LargePageSizeInBytes=6' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 141: > 139: return JVMFlag::SUCCESS; > 140: } > 141: } I don't think you need `else` part here. Suggestion: } return JVMFlag::SUCCESS; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25994#discussion_r2174361693 From duke at openjdk.org Mon Jun 30 07:49:54 2025 From: duke at openjdk.org (Yagmur Eren) Date: Mon, 30 Jun 2025 07:49:54 GMT Subject: RFR: 8358748: Large page size initialization fails with assert "page_size must be a power of 2" [v2] In-Reply-To: References: Message-ID: > The VM now exits gracefully if `-XX:LargePageSizeInBytes` is set to a non power of two value, instead of asserting. After this change, `SizeTTest.java` failed because the tested values are not valid for `-XX:LargePageSizeInBytes` (`LargePageSizeInBytesConstraintFunc` returns `JVMFlag::VIOLATES_CONSTRAINT`). Therefore, I updated the test to use `NUMASpaceResizeRate`, since I believe that it only requires a flag of type `size_t`. > > Before the change: > > java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (workspace/open/src/hotspot/share/runtime/os.cpp:2449), pid=1885945, tid=1885946 > # assert(is_power_of_2(page_size)) failed: page_size must be a power of 2: 0x6 > > > > After the change: > > java -XX:+UseLargePages -XX:LargePageSizeInBytes=6 -version > > LargePageSizeInBytes ( 6 ) must be a power of 2 > Improperly specified VM option 'LargePageSizeInBytes=6' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. Yagmur Eren has updated the pull request incrementally with one additional commit since the last revision: some fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25994/files - new: https://git.openjdk.org/jdk/pull/25994/files/22c33b71..f16b9a57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25994&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25994&range=00-01 Stats: 7 lines in 2 files changed: 2 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25994/head:pull/25994 PR: https://git.openjdk.org/jdk/pull/25994 From duke at openjdk.org Mon Jun 30 07:53:39 2025 From: duke at openjdk.org (Yagmur Eren) Date: Mon, 30 Jun 2025 07:53:39 GMT Subject: RFR: 8358748: Large page size initialization fails with assert "page_size must be a power of 2" [v2] In-Reply-To: References: Message-ID: <21qfD8JSbsOQWE1SPw0V-dnEw_z5MAINOLwK7Br4B6g=.a6fb1e8f-37fe-445b-9f51-060cedd91072@github.com> On Thu, 26 Jun 2025 08:07:29 GMT, David Holmes wrote: >> Yagmur Eren has updated the pull request incrementally with one additional commit since the last revision: >> >> some fixes > > src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 136: > >> 134: "LargePageSizeInBytes ( %zu ) must be " >> 135: "a power of 2\n", >> 136: value); > > Suggestion: > > JVMFlag::printError(verbose, "LargePageSizeInBytes ( %zu ) must be " > "a power of 2\n", value); I actually did this in the same format with the other power-of-two example in the same file but this looks better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25994#discussion_r2174446743 From duke at openjdk.org Mon Jun 30 07:53:40 2025 From: duke at openjdk.org (Yagmur Eren) Date: Mon, 30 Jun 2025 07:53:40 GMT Subject: RFR: 8358748: Large page size initialization fails with assert "page_size must be a power of 2" [v2] In-Reply-To: <2Z18RjlX3JWlVJG0Y2-GpStZjTdrNUqXDAbQsE7vpPs=.9b91989c-ceac-4630-b458-4170579041b8@github.com> References: <2Z18RjlX3JWlVJG0Y2-GpStZjTdrNUqXDAbQsE7vpPs=.9b91989c-ceac-4630-b458-4170579041b8@github.com> Message-ID: On Mon, 30 Jun 2025 06:58:22 GMT, Amit Kumar wrote: >> Yagmur Eren has updated the pull request incrementally with one additional commit since the last revision: >> >> some fixes > > src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 141: > >> 139: return JVMFlag::SUCCESS; >> 140: } >> 141: } > > I don't think you need `else` part here. > > Suggestion: > > } > > return JVMFlag::SUCCESS; > } Makes sense. I was trying out stuff and no clue why I left it like this. Thanks for highlighting! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25994#discussion_r2174448281 From mbaesken at openjdk.org Mon Jun 30 07:54:15 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 30 Jun 2025 07:54:15 GMT Subject: RFR: 8361043: [ubsan] os::print_hex_dump runtime error: applying non-zero offset 8 to null pointer Message-ID: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com> When running jtreg test runtime/cds/DeterministicDump with ubsan-enabled binaries (opt) on macOS aarch64, the following issue is reported : /jdk/src/hotspot/share/runtime/os.cpp:1045:15: runtime error: applying non-zero offset 8 to null pointer #0 0x106156ad4 in os::print_hex_dump(outputStream*, unsigned char const*, unsigned char const*, int, bool, int, unsigned char const*, unsigned char const*) os.cpp:1045 #1 0x10524685c in ArchiveBuilder::CDSMapLogger::log(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*, char*, unsigned long) archiveBuilder.cpp:1573 #2 0x105245e60 in ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*) archiveBuilder.cpp:1634 #3 0x106084fd4 in MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) metaspaceShared.cpp:1053 #4 0x10608411c in MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*) metaspaceShared.cpp:1030 #5 0x1060837b8 in MetaspaceShared::preload_and_dump(JavaThread*) metaspaceShared.cpp:812 #6 0x10660457c in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:892 #7 0x105ca60dc in JNI_CreateJavaVM jni.cpp:3680 #8 0x100fbe4d0 in JavaMain java.c:494 #9 0x100fc54fc in ThreadJavaMain java_md_macosx.m:679 #10 0x197372f90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) #11 0x19736dd30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) ------------- Commit messages: - JDK-8361043 Changes: https://git.openjdk.org/jdk/pull/26037/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26037&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361043 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26037.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26037/head:pull/26037 PR: https://git.openjdk.org/jdk/pull/26037 From dholmes at openjdk.org Mon Jun 30 08:16:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 30 Jun 2025 08:16:44 GMT Subject: RFR: 8361043: [ubsan] os::print_hex_dump runtime error: applying non-zero offset 8 to null pointer In-Reply-To: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com> References: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com> Message-ID: On Mon, 30 Jun 2025 07:49:45 GMT, Matthias Baesken wrote: > When running jtreg test > runtime/cds/DeterministicDump > with ubsan-enabled binaries (opt) on macOS aarch64, the following issue is reported : > > > /jdk/src/hotspot/share/runtime/os.cpp:1045:15: runtime error: applying non-zero offset 8 to null pointer > #0 0x106156ad4 in os::print_hex_dump(outputStream*, unsigned char const*, unsigned char const*, int, bool, int, unsigned char const*, unsigned char const*) os.cpp:1045 > #1 0x10524685c in ArchiveBuilder::CDSMapLogger::log(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*, char*, unsigned long) archiveBuilder.cpp:1573 > #2 0x105245e60 in ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*) archiveBuilder.cpp:1634 > #3 0x106084fd4 in MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) metaspaceShared.cpp:1053 > #4 0x10608411c in MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*) metaspaceShared.cpp:1030 > #5 0x1060837b8 in MetaspaceShared::preload_and_dump(JavaThread*) metaspaceShared.cpp:812 > #6 0x10660457c in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:892 > #7 0x105ca60dc in JNI_CreateJavaVM jni.cpp:3680 > #8 0x100fbe4d0 in JavaMain java.c:494 > #9 0x100fc54fc in ThreadJavaMain java_md_macosx.m:679 > #10 0x197372f90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #11 0x19736dd30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) src/hotspot/share/runtime/os.cpp line 1045: > 1043: print_hex_location(st, p, unitsize, ascii_form); > 1044: p += unitsize; > 1045: logical_p = (const_address) ((uintptr_t)logical_p + unitsize); Forcing unsigned arithmetic doesn't seem right if `unitsize` is a signed int - it will work here as `unitsize` is always positive, but it looks weird to me. Does this compile okay on all platforms e.g. Windows? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26037#discussion_r2174490545 From mdoerr at openjdk.org Mon Jun 30 09:12:40 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 30 Jun 2025 09:12:40 GMT Subject: RFR: 8361043: [ubsan] os::print_hex_dump runtime error: applying non-zero offset 8 to null pointer In-Reply-To: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com> References: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com> Message-ID: On Mon, 30 Jun 2025 07:49:45 GMT, Matthias Baesken wrote: > When running jtreg test > runtime/cds/DeterministicDump > with ubsan-enabled binaries (opt) on macOS aarch64, the following issue is reported : > > > /jdk/src/hotspot/share/runtime/os.cpp:1045:15: runtime error: applying non-zero offset 8 to null pointer > #0 0x106156ad4 in os::print_hex_dump(outputStream*, unsigned char const*, unsigned char const*, int, bool, int, unsigned char const*, unsigned char const*) os.cpp:1045 > #1 0x10524685c in ArchiveBuilder::CDSMapLogger::log(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*, char*, unsigned long) archiveBuilder.cpp:1573 > #2 0x105245e60 in ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*) archiveBuilder.cpp:1634 > #3 0x106084fd4 in MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) metaspaceShared.cpp:1053 > #4 0x10608411c in MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*) metaspaceShared.cpp:1030 > #5 0x1060837b8 in MetaspaceShared::preload_and_dump(JavaThread*) metaspaceShared.cpp:812 > #6 0x10660457c in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:892 > #7 0x105ca60dc in JNI_CreateJavaVM jni.cpp:3680 > #8 0x100fbe4d0 in JavaMain java.c:494 > #9 0x100fc54fc in ThreadJavaMain java_md_macosx.m:679 > #10 0x197372f90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #11 0x19736dd30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) Looks correct. Not sure if a comment mentioning that `logical_p` can be `nullptr` would be helpful. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26037#pullrequestreview-2970484658 From coleenp at openjdk.org Mon Jun 30 11:22:57 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 30 Jun 2025 11:22:57 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v9] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - Update test/lib/RedefineClassHelper.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/17b3b77b..8f360d65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=07-08 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From coleenp at openjdk.org Mon Jun 30 11:38:24 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 30 Jun 2025 11:38:24 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v8] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com> Message-ID: On Mon, 30 Jun 2025 05:22:11 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function. > > test/lib/RedefineClassHelper.java line 87: > >> 85: * @param newClassName new class name to replace with old class name. >> 86: */ >> 87: public static byte[] replaceClassName(byte[] bytes, String oldClassName, String newClassName) throws Exception { > > Just realized that `oldClassName` is not actually used. Suggestion: > > /* > * Copy the class defined by `bytes`, replacing the name of the class with `newClassName`, so that both > * old and new classes can be compiled by jtreg for the test. > * > * @param bytes the bytes presenting the original classfile > * @param newClassName the new class name for the returned class representation > * @ return a copy of the class represented by `bytes` but with the name `newClassName` > */ > public static byte[] replaceClassName(byte[] bytes, String newClassName) throws Exception { Thanks David for the comment text, I changed it slightly because I didn't understand what the word presenting meant in that sentence. Also removed the parameter. We can add it back when the class file remapper API is available without having to add --add-modules to all the tests. If we need to make the old classfiles substitute more than the name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174862057 From coleenp at openjdk.org Mon Jun 30 11:38:23 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 30 Jun 2025 11:38:23 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v10] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Upgraded comment, and removed oldClassName from the bytes version. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/8f360d65..3fc05102 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=08-09 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From dholmes at openjdk.org Mon Jun 30 12:32:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 30 Jun 2025 12:32:42 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v10] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Mon, 30 Jun 2025 11:38:23 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Upgraded comment, and removed oldClassName from the bytes version. Update looks good. Just a couple of typos - sorry. test/lib/RedefineClassHelper.java line 80: > 78: > 79: /* > 80: * Copy the class defined by `bytes`, replacing the nameof the class with `newClassName`, Suggestion: * Copy the class defined by `bytes`, replacing the name of the class with `newClassName`, test/lib/RedefineClassHelper.java line 85: > 83: * @param bytes read from the original class file. > 84: * @param newClassName new class name for the returned class representation > 85: * @return a copy of the class representated by `bytes` but with the name `newClassName` Suggestion: * @return a copy of the class represented by `bytes` but with the name `newClassName` test/lib/RedefineClassHelper.java line 99: > 97: * @param oldClassName old class name. > 98: * @param newClassName new class name to replace with old class name. > 99: * @return a copy of the class representated by `bytes` but with the name `newClassName` Suggestion: * @return a copy of the class represented by `bytes` but with the name `newClassName` ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2971040481 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174957181 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174958951 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174960419 From duke at openjdk.org Mon Jun 30 13:35:23 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 30 Jun 2025 13:35:23 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v10] In-Reply-To: References: Message-ID: > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time - Implement CollectedHeap::before_exit() as suggested by @stefank - Remove incorrect is_gc_operation call after rebase - More clean up, remove virtual - Fixes after feedback from @stefank - Remove extra whitespace - operation_is_gc -> is_gc_operation per @stefank suggestion - Only sample if needed - Remove explicit super call and minor fixes - Add CPU time tracking for string deduplication to log_gc_vtime - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f ------------- Changes: https://git.openjdk.org/jdk/pull/25779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=09 Stats: 265 lines in 17 files changed: 253 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Mon Jun 30 13:35:23 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 30 Jun 2025 13:35:23 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v9] In-Reply-To: <_FhdGlOiiWqN_Jpx_7kJZgamyXtgQTUw54t1w38SjxY=.609da7e0-39f9-4525-9836-b56a71c488f6@github.com> References: <_FhdGlOiiWqN_Jpx_7kJZgamyXtgQTUw54t1w38SjxY=.609da7e0-39f9-4525-9836-b56a71c488f6@github.com> Message-ID: On Mon, 23 Jun 2025 18:57:51 GMT, Stefan Karlsson wrote: >> I think it makes sense. We want to log the total GC CPU time before exiting. The latest point we can do that is right before we terminate threads, which we do in when we call `ConcurrentGCThread::stop`. I am open for any suggestions to rename `log_gc_vtime` in case that would help. > > I'd also prefer to see a small adjustment here. With this change all GCs have to add a back call to `CollectedHeap::stop()`. I think it makes the could a tiny bit less clean. > > I wonder if an alternative could be to split `CollectedHeap::stop()` into two functions: > > virtual void CollectedHeap::stop() = 0; // Now pure virtual > > void CollectedHeap::before_exit() { > // Log GC CPU usage. > log_gc_vtime(); > > // Stop any on-going concurrent work and prepare for exit. > stop(); > } > > And revert the added calls to `CollectedHeap::stop()`. That's a great suggestion, thanks! I have now implemented these changes :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175091875 From stefank at openjdk.org Mon Jun 30 13:57:43 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 30 Jun 2025 13:57:43 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v10] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 13:35:23 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time > - Implement CollectedHeap::before_exit() as suggested by @stefank > - Remove incorrect is_gc_operation call after rebase > - More clean up, remove virtual > - Fixes after feedback from @stefank > - Remove extra whitespace > - operation_is_gc -> is_gc_operation per @stefank suggestion > - Only sample if needed > - Remove explicit super call and minor fixes > - Add CPU time tracking for string deduplication to log_gc_vtime > - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f I've listed a couple more nits. Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch? I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime? src/hotspot/share/gc/shared/vtimeScope.hpp line 37: > 35: bool _enabled; > 36: bool _is_gc_operation; > 37: Thread* _thread; Suggestion: jlong _start; bool _enabled; bool _is_gc_operation; Thread* _thread; src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 44: > 42: > 43: inline VTimeScope::~VTimeScope() { > 44: if (!_enabled) return; This is a style that most HotSpot GC devs try to avoid. Suggestion: if (!_enabled) { return; } ------------- PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2971280145 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175108401 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175113990 From stefank at openjdk.org Mon Jun 30 14:05:42 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 30 Jun 2025 14:05:42 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v10] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 13:35:23 GMT, Jonas Norlinder wrote: >> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. >> >> >> [1.500s][info ][gc] GC CPU cost: 1.75% >> >> >> Additionally, detailed information may be retrieved with `-Xlog:gc=trace` >> >> >> [1.500s][trace][gc] Process CPU time: 4.945370s >> [1.500s][trace][gc] GC CPU time: 0.086382s >> [1.500s][info ][gc] GC CPU cost: 1.75% > > Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time > - Implement CollectedHeap::before_exit() as suggested by @stefank > - Remove incorrect is_gc_operation call after rebase > - More clean up, remove virtual > - Fixes after feedback from @stefank > - Remove extra whitespace > - operation_is_gc -> is_gc_operation per @stefank suggestion > - Only sample if needed > - Remove explicit super call and minor fixes > - Add CPU time tracking for string deduplication to log_gc_vtime > - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f I missed that you hadn't changed this: LogTarget(Info, gc) out; I would prefer to see this getting moved over to gc+cpu (alt. gc+cpu+exit). src/hotspot/share/gc/shared/collectedHeap.cpp line 70: > 68: size_t CollectedHeap::_filler_array_max_size = 0; > 69: size_t CollectedHeap::_stack_chunk_max_size = 0; > 70: jlong CollectedHeap::_vm_vtime = 0; I'm not sure that the `vm` prefix is fitting for this name. ------------- PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2971365591 PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175161128 From duke at openjdk.org Mon Jun 30 14:12:42 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 30 Jun 2025 14:12:42 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v10] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 14:02:53 GMT, Stefan Karlsson wrote: >> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: >> >> - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time >> - Implement CollectedHeap::before_exit() as suggested by @stefank >> - Remove incorrect is_gc_operation call after rebase >> - More clean up, remove virtual >> - Fixes after feedback from @stefank >> - Remove extra whitespace >> - operation_is_gc -> is_gc_operation per @stefank suggestion >> - Only sample if needed >> - Remove explicit super call and minor fixes >> - Add CPU time tracking for string deduplication to log_gc_vtime >> - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f > > src/hotspot/share/gc/shared/collectedHeap.cpp line 70: > >> 68: size_t CollectedHeap::_filler_array_max_size = 0; >> 69: size_t CollectedHeap::_stack_chunk_max_size = 0; >> 70: jlong CollectedHeap::_vm_vtime = 0; > > I'm not sure that the `vm` prefix is fitting for this name. It is the time we spend on doing GC activities inside the VM thread, hence `vm`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175174704 From duke at openjdk.org Mon Jun 30 14:26:04 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 30 Jun 2025 14:26:04 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v11] In-Reply-To: References: Message-ID: <_zPHIAMLNTOQ4uZw_VlgM7i44DnasKtalJe0glruAn4=.4a5d505e-60db-479e-9d0f-718450846397@github.com> > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fixes after review from @stefank ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/0993931f..293fbe95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=09-10 Stats: 31 lines in 6 files changed: 2 ins; 23 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From tschatzl at openjdk.org Mon Jun 30 14:53:41 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 30 Jun 2025 14:53:41 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v10] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 13:55:24 GMT, Stefan Karlsson wrote: > I've listed a couple more nits. > > Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch? > > I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime? I concur with @stefank: we just removed `vtime` in other gc code, simply using `cpu_time`. `_vmthread_cpu_time` seems to be a lot more descriptive than `_vm_vtime`. At least add `thread` - the name of that thread is `VMThread` after all (as opposed to the whole VM what the current name implies to me). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3019468123 From duke at openjdk.org Mon Jun 30 15:58:07 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 30 Jun 2025 15:58:07 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v12] In-Reply-To: References: Message-ID: <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com> > Add support to log CPU cost for GC during VM exit with `-Xlog:gc`. > > > [1.500s][info ][gc] GC CPU cost: 1.75% > > > Additionally, detailed information may be retrieved with `-Xlog:gc=trace` > > > [1.500s][trace][gc] Process CPU time: 4.945370s > [1.500s][trace][gc] GC CPU time: 0.086382s > [1.500s][info ][gc] GC CPU cost: 1.75% Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision: - Update closure name - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25779/files - new: https://git.openjdk.org/jdk/pull/25779/files/293fbe95..35a74668 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=10-11 Stats: 234 lines in 12 files changed: 102 ins; 102 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/25779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779 PR: https://git.openjdk.org/jdk/pull/25779 From duke at openjdk.org Mon Jun 30 15:58:07 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Mon, 30 Jun 2025 15:58:07 GMT Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit [v10] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 14:50:43 GMT, Thomas Schatzl wrote: >> I've listed a couple more nits. >> >> Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch? >> >> I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime? > >> I've listed a couple more nits. >> >> Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch? >> >> I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime? > > I concur with @stefank: we just removed `vtime` in other gc code, simply using `cpu_time`. > > `_vmthread_cpu_time` seems to be a lot more descriptive than `_vm_vtime`. At least add `thread` - the name of that thread is `VMThread` after all (as opposed to the whole VM what the current name implies to me). Thanks @tschatzl, I have updated the PR with your suggestions ------------- PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3019748061 From lucy at openjdk.org Mon Jun 30 16:05:38 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 30 Jun 2025 16:05:38 GMT Subject: RFR: 8361043: [ubsan] os::print_hex_dump runtime error: applying non-zero offset 8 to null pointer In-Reply-To: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com> References: <_4x8AWT92UYqk8EnSmkl0esIdl9-0N99eOcRgjBlqwU=.316ac846-8072-449c-a147-2b8bf41e950b@github.com> Message-ID: On Mon, 30 Jun 2025 07:49:45 GMT, Matthias Baesken wrote: > When running jtreg test > runtime/cds/DeterministicDump > with ubsan-enabled binaries (opt) on macOS aarch64, the following issue is reported : > > > /jdk/src/hotspot/share/runtime/os.cpp:1045:15: runtime error: applying non-zero offset 8 to null pointer > #0 0x106156ad4 in os::print_hex_dump(outputStream*, unsigned char const*, unsigned char const*, int, bool, int, unsigned char const*, unsigned char const*) os.cpp:1045 > #1 0x10524685c in ArchiveBuilder::CDSMapLogger::log(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*, char*, unsigned long) archiveBuilder.cpp:1573 > #2 0x105245e60 in ArchiveBuilder::write_archive(FileMapInfo*, ArchiveHeapInfo*) archiveBuilder.cpp:1634 > #3 0x106084fd4 in MetaspaceShared::write_static_archive(ArchiveBuilder*, FileMapInfo*, ArchiveHeapInfo*) metaspaceShared.cpp:1053 > #4 0x10608411c in MetaspaceShared::preload_and_dump_impl(StaticArchiveBuilder&, JavaThread*) metaspaceShared.cpp:1030 > #5 0x1060837b8 in MetaspaceShared::preload_and_dump(JavaThread*) metaspaceShared.cpp:812 > #6 0x10660457c in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:892 > #7 0x105ca60dc in JNI_CreateJavaVM jni.cpp:3680 > #8 0x100fbe4d0 in JavaMain java.c:494 > #9 0x100fc54fc in ThreadJavaMain java_md_macosx.m:679 > #10 0x197372f90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #11 0x19736dd30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) LGTM. David's (@dholmes-ora) comment touches a widespread inconsistency. Historically, almost nobody cared about distinguishing between naturally signed and unsigned entities. A clean solution would be to declare `unitsize` as `unsigned int` and adapt all callers. I'm not sure if widening the scope of this otherwise trivial change is justified. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26037#pullrequestreview-2971842726 From liach at openjdk.org Mon Jun 30 16:16:44 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 30 Jun 2025 16:16:44 GMT Subject: RFR: 8310831: Some methods are missing from CDS regenerated JLI holder class [v2] In-Reply-To: References: Message-ID: <5h93sQ5L-3zs4mfauO0_ickIXCeKZ7_Iop_tJWzNNfg=.333582ae-6a13-4249-9fe7-37c0a0d3ea8f@github.com> On Fri, 27 Jun 2025 21:01:54 GMT, Calvin Cheung wrote: >> Per the [suggested fix](https://bugs.openjdk.org/browse/JDK-8310831?focusedId=14788065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14788065), this patch doesn't issue a warning if the missing method is the constructor of a holder class. >> >> Sanity tier1 tested. >> >> Manually tested by building the `images` with the `-Xlog:cds=off` removed from the `GenerateLinkOptData.gmk` and with build logging enabled (`LOG=info`). > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @iklam comments Reasonable improvement. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26011#pullrequestreview-2971879247 From kbarrett at openjdk.org Mon Jun 30 16:25:54 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 30 Jun 2025 16:25:54 GMT Subject: RFR: 8361085: MemoryReserver log_on_large_pages_failure has incorrect format usage Message-ID: Please review this fix of an incorrect format usage. The function calls `jio_snprintf` to format a message into a buffer. That message includes printing a pointer using `PTR_FORMAT`, but isn't using the `p2i` helper function. Fixing that is just a matter of using that helper. However, there's no need to use `jio_snprintf` here, as the resulting message is then just passed to `warning`, which can handle output formatting directly. So we also move the formatting to the `warning` call, and remove the use of `jio_snprintf`. Note that calling `warning` without the `p2i` would have produced a compiler warning about the incorrect format usage. Testing: mach5 tier1 ------------- Commit messages: - cleanup memoryServer large pages failure warning Changes: https://git.openjdk.org/jdk/pull/26050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361085 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26050/head:pull/26050 PR: https://git.openjdk.org/jdk/pull/26050 From liach at openjdk.org Mon Jun 30 16:27:42 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 30 Jun 2025 16:27:42 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> Message-ID: On Fri, 27 Jun 2025 00:52:10 GMT, Calvin Cheung wrote: >> This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. >> >> Passed tiers 1 - 5 testing. > > Calvin Cheung 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 two additional commits since the last revision: > > - Merge branch 'master' into 8360743-enables-regen-JLI-holder > - 8360743: Enables regeneration of JLI holder classes for CDS static dump src/hotspot/share/cds/aotArtifactFinder.cpp line 251: > 249: } > 250: > 251: InstanceKlass* nest_host = ik->nest_host_or_null(); Just curious, what is this nest host treatment for? I don't think the generated Holder classes have the NestHost attribute, despite them being listed in NestMembers of their top level classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26007#discussion_r2175468162 From stefank at openjdk.org Mon Jun 30 16:48:38 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 30 Jun 2025 16:48:38 GMT Subject: RFR: 8361085: MemoryReserver log_on_large_pages_failure has incorrect format usage In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 16:11:47 GMT, Kim Barrett wrote: > Please review this fix of an incorrect format usage. > > The function calls `jio_snprintf` to format a message into a buffer. That > message includes printing a pointer using `PTR_FORMAT`, but isn't using the > `p2i` helper function. Fixing that is just a matter of using that helper. > > However, there's no need to use `jio_snprintf` here, as the resulting message > is then just passed to `warning`, which can handle output formatting directly. > So we also move the formatting to the `warning` call, and remove the use of > `jio_snprintf`. Note that calling `warning` without the `p2i` would have > produced a compiler warning about the incorrect format usage. > > Testing: mach5 tier1 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26050#pullrequestreview-2971971802 From coleenp at openjdk.org Mon Jun 30 16:49:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 30 Jun 2025 16:49:02 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v11] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision: - Update test/lib/RedefineClassHelper.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/lib/RedefineClassHelper.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/lib/RedefineClassHelper.java Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/3fc05102..791f2146 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=09-10 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From coleenp at openjdk.org Mon Jun 30 16:49:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 30 Jun 2025 16:49:02 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v10] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Mon, 30 Jun 2025 11:38:23 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Upgraded comment, and removed oldClassName from the bytes version. Thanks David for the suggested changes for the typos, and for the suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25857#issuecomment-3019949813 From ccheung at openjdk.org Mon Jun 30 17:20:40 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 30 Jun 2025 17:20:40 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> Message-ID: On Mon, 30 Jun 2025 16:25:20 GMT, Chen Liang wrote: >> Calvin Cheung 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 two additional commits since the last revision: >> >> - Merge branch 'master' into 8360743-enables-regen-JLI-holder >> - 8360743: Enables regeneration of JLI holder classes for CDS static dump > > src/hotspot/share/cds/aotArtifactFinder.cpp line 251: > >> 249: } >> 250: >> 251: InstanceKlass* nest_host = ik->nest_host_or_null(); > > Just curious, what is this nest host treatment for? I don't think the generated Holder classes have the NestHost attribute, despite them being listed in NestMembers of their top level classes. This handles the nest host of hidden classes. During investigation, I encountered a null `GenerateJLIClassesHelper` class during dumping and causes a crash. This change, which is suggested by Ioi, fixes the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26007#discussion_r2175552655 From liach at openjdk.org Mon Jun 30 17:32:42 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 30 Jun 2025 17:32:42 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> Message-ID: On Fri, 27 Jun 2025 00:52:10 GMT, Calvin Cheung wrote: >> This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. >> >> Passed tiers 1 - 5 testing. > > Calvin Cheung 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 two additional commits since the last revision: > > - Merge branch 'master' into 8360743-enables-regen-JLI-holder > - 8360743: Enables regeneration of JLI holder classes for CDS static dump Thanks for the explanation of the nest host part. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26007#pullrequestreview-2972098621 From ccheung at openjdk.org Mon Jun 30 17:53:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 30 Jun 2025 17:53:52 GMT Subject: Integrated: 8360743: Enables regeneration of JLI holder classes for CDS static dump In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 22:41:58 GMT, Calvin Cheung wrote: > This patch enables regeneration of JLI holder classes when dumping method handles, i.e. when dumping heap and aot linked classes. It also addresses an issue if the nest host of a class is excluded during dumping, the class should also be excluded. > > Passed tiers 1 - 5 testing. This pull request has now been integrated. Changeset: 1dda79cf Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/1dda79cfab597782e0a7bb63af6dcc30aeff62d1 Stats: 124 lines in 12 files changed: 104 ins; 3 del; 17 mod 8360743: Enables regeneration of JLI holder classes for CDS static dump Reviewed-by: iklam, liach ------------- PR: https://git.openjdk.org/jdk/pull/26007 From ccheung at openjdk.org Mon Jun 30 17:53:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 30 Jun 2025 17:53:52 GMT Subject: RFR: 8360743: Enables regeneration of JLI holder classes for CDS static dump [v2] In-Reply-To: <0apZSbgw6cj3-WGcM5XgWDAX_kjuuFn5V3FJDWvbkpE=.c13cf954-1b98-4d3c-bcdd-08690a7b9dfa@github.com> References: <8V4YQY3_U6i0lmkAl-9qGub8zWF6bYviipzPlb5BkkM=.47e4df22-f0b7-4dd1-8e2c-1c5a6900a2fd@github.com> <0apZSbgw6cj3-WGcM5XgWDAX_kjuuFn5V3FJDWvbkpE=.c13cf954-1b98-4d3c-bcdd-08690a7b9dfa@github.com> Message-ID: On Fri, 27 Jun 2025 18:00:23 GMT, Ioi Lam wrote: >> Calvin Cheung 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 two additional commits since the last revision: >> >> - Merge branch 'master' into 8360743-enables-regen-JLI-holder >> - 8360743: Enables regeneration of JLI holder classes for CDS static dump > > LGTM Thanks @iklam @liach for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26007#issuecomment-3020174343 From ccheung at openjdk.org Mon Jun 30 17:55:44 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 30 Jun 2025 17:55:44 GMT Subject: RFR: 8310831: Some methods are missing from CDS regenerated JLI holder class [v2] In-Reply-To: References: Message-ID: On Sat, 28 Jun 2025 02:03:49 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @iklam comments > > LGTM. Thanks @iklam @liach for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26011#issuecomment-3020178528 From ccheung at openjdk.org Mon Jun 30 17:55:45 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 30 Jun 2025 17:55:45 GMT Subject: Integrated: 8310831: Some methods are missing from CDS regenerated JLI holder class In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 04:22:01 GMT, Calvin Cheung wrote: > Per the [suggested fix](https://bugs.openjdk.org/browse/JDK-8310831?focusedId=14788065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14788065), this patch doesn't issue a warning if the missing method is the constructor of a holder class. > > Sanity tier1 tested. > > Manually tested by building the `images` with the `-Xlog:cds=off` removed from the `GenerateLinkOptData.gmk` and with build logging enabled (`LOG=info`). This pull request has now been integrated. Changeset: 9d518b32 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/9d518b3213af7c60cb604138a2c4022181bb2daa Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8310831: Some methods are missing from CDS regenerated JLI holder class Reviewed-by: iklam, liach ------------- PR: https://git.openjdk.org/jdk/pull/26011 From dlong at openjdk.org Mon Jun 30 22:05:49 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 30 Jun 2025 22:05:49 GMT Subject: RFR: 8358821: patch_verified_entry causes problems, use nmethod entry barriers instead [v9] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long wrote: >> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier. >> >> We used to patch the verified entry point to make sure it was not_entrant. The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler. The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant. We can do the same thing with a permanently armed nmethod entry barrier. >> >> The solution I went with reserves one bit of the entry barrier guard value. This bit must remain set, so I call it a "sticky" bit. Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it. The alternative would be to change the platform-specific code to do compare-and-swap. >> >> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic. For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod(). I suspect we could do the same for Shenandoah, if needed for performance. >> >> This change also makes it a bit clearer that the nmethod entry barrier effectively has two levels. Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier(). This could be generalized if we decide we need more flavors of entry barriers. The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels. > > Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8358821-patch-verified-entry > - 2nd try at arm fix > - rename arm_with to guard_with > - arm32 fix > - s390 fix courtesy of Amit Kumar > - remove is_sigill_not_entrant > - more cleanup > - more TheRealMDoerr suggestions > - TheRealMDoerr suggestions > - remove trailing space > - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c I would be OK with JDK-8258229 being backed out. I sent a message to @mhaessig asking what he things. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3020951767 From lmesnik at openjdk.org Mon Jun 30 23:12:38 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 30 Jun 2025 23:12:38 GMT Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu In-Reply-To: References: Message-ID: <0Im1TXEP66tejiuNh7TcwwPeW2wsRtM8LY51BCwxAng=.871e86c1-51d4-4269-81cb-8b6f14cb82fe@github.com> On Fri, 20 Jun 2025 09:27:14 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk. > > These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu. > > Thanks! You can add new property for your condition in VMProps, saying vm.cds.archive.available that is true is archive is generated for JDK. Since the classes.jsa is mandatory the property should check if classes.jsa exists and if current configuration allows to miss classes.jsa. You could start with adding risc+qemu as a first configuration with optional cds archive. Later it could be extended. Alternatively you could just throw SkippedException in the tests, assuming that number of them is small. There is an example with isCOHArchiveAvailable() check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25913#issuecomment-3021115071 From lmesnik at openjdk.org Mon Jun 30 23:28:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 30 Jun 2025 23:28:41 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v11] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Mon, 30 Jun 2025 16:49:02 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision: > > - Update test/lib/RedefineClassHelper.java > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update test/lib/RedefineClassHelper.java > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update test/lib/RedefineClassHelper.java > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java line 45: > 43: ClassVersionAfterRedefine cvar = new ClassVersionAfterRedefine(); > 44: > 45: // Poor man's renaming of class "TestClassOld" to "TestClassXXX" It is not "poor man's" renaming anymore and RedefineClassHelper.replaceClassName() is self-explanable. So this comment could be just removed. ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2973056824 PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2176137182